Misc doc updates

Co-Authored-By: Roberto Abdelkader Martínez Pérez <robertomartinezp@gmail.com>

docs/source/theory/request_life_cycle.rst

@@ -8,26 +8,31 @@ answered by the User HTTP Interface.
 
 #. The request is matched against the route table
 
-#. Kapow! provides a `HANDLER_ID` to identify this request
+#. ``kapow`` provides a `HANDLER_ID` to identify this request and don't mix it
+   with other requests that could be running concurrently.
 
-#. Kapow! spawns the binary specified as entrypoint in the matching route
+#. ``kapow`` spawns the binary specified as entrypoint in the matching route
 
    The default entrypoint is /bin/sh; we'll explain this workflow for now.
 
-   The spawned entrypoint is run with the following variables added to its environment:
+   The spawned entrypoint is run with the following variables added to its
+   environment:
 
    - ``KAPOW_HANDLER_ID``: Containing the `HANDLER_ID`
    - ``KAPOW_DATAAPI_URL``: With the URL of the `data interface`
    - ``KAPOW_CONTROLAPI_URL``: With the URL of the `control interface`
 
-#.  During the lifetime of the shell, the request and response resources are available via these commands:
+#. During the lifetime of the shell, the request and response resources are
+   available via these commands:
 
    - ``kapow get /request/...``
    - ``kapow set /response/...``
 
    These commands use the aforementioned environment variables to read
-   data of the user request and to write the response.
+   data from the user request and to write the response.
 
-TODO: link to resource tree
+   .. todo::
 
-#. When the shell dies, Kapow! finalizes the original request
+      link to resource tree
+
+#. When the shell dies, ``kapow`` finalizes the original request