Command reference
oko sessions reply
The session a post was sent to answers it: the channel back from an executor to the session that wrote to it, kept and delivered as a send and naming the post it answers, so the thread reads back in `oko sessions posts` and the digest instead of being scanned out of the executor's transcript.
Invocation#
oko sessions reply POST --text TEXT [--socket PATH]Inputs and options#
- POST is a post id as `oko sessions posts` lists it, or a start only one id begins with. --text is the answer.
- The replying session is proven from the machine: the harness above the command that writes a live transcript must be the post's target, or a session that succeeds it.
Output and state effect#
- A post a session sent is answered to that session; a post one of Oko's routines handed (origin) is answered to the replier's recorded supervisor, for whom the routine acts. The reply is queued as `oko sessions send` queues a post — from the replier, bound to the original's defect, submitted, with replyTo the original's id — and delivered by a detached deliverer. Prints what `oko sessions send` prints.
Refusals and safe exits#
- “no post <id> is kept in <folder>; `oko sessions posts` lists them”, “<id> begins the ids of several posts (…); name one whole”, “oko sessions reply --text takes the answer; it was empty” (exit 2).
- “post <id> was sent to <target>, and this command runs in agent session <caller>; only the session a post was sent to answers it”, and outside every agent session “post <id> is answered by the session it was sent to, <target>, and who runs this command cannot be read (<why>)”.
- “post <id> is the operator's; the operator is asked with `oko asks ask --from oko --subject <defect> --question <text>`, never typed to”, “post <id> was handed by Oko's <origin>, which acts for <replier>'s supervisor, and <replier> has no supervisor recorded; …”, and every refusal of `oko sessions send` for the addressee.