Command reference
oko tasks add
Records an operator message Oko’s model did not read as work as the task it is, or, with --part N, one of several instructions in one message as a task of its own, so its name, statement, contract, status and relations can be written like any other task’s.
Invocation#
oko tasks add <session> <number> [--part N] --by (operator | <session>)Inputs and options#
- <session> and <number> name the message by its place among the session’s stored operator messages, the number oko tasks kind and oko tasks unread print beside it.
- --part N names instruction N of a message that carries several: “dodaj zadanie A. dodaj kolejne zadanie B” is one message and two tasks. Parts are recorded in order, part 1 first, so N is always the next part (Oko Desktop offers it as Add instruction N); there is no upper bound. Each part gets its own identity beside the message’s task, whether or not the message itself reads as work, and the session writes what that part asks for with oko tasks state <task-id> --statement.
- --by names who reads the message as work: a session id records that session’s judgement, and the literal word operator records his.
Output and state effect#
- Reads the message from the session’s stored operator messages, as oko tasks kind does (its live transcript only when nothing is stored, or when the live copy has grown past the stored one), writes one task_additions row keyed by the task identity the message derives, and registers that task object in `tasks`. From then on every reader derives the message as a task under that identity — the listing and its JSON, oko tasks show, state, check, relate, map and control, Oko Desktop’s Tasks screen, and `tama assignment show` — with `classifiedBy` “added by <who>”, and a reindex that moves its number keeps it.
- Prints “added: message #<n> of <session> is task <task-id>, added by <who>: <first line>”, then the oko tasks state commands that name the task and write what it asks for. The operator’s text is not changed.
- With --part N the addition is keyed by the part’s own identity (the message’s identity plus the part number), and the ledger lists that task right after the message’s own, with `part: N` in JSON and `classifiedBy` “part N, added by <who>”. Claim, evidence, state, check, submit, verdict and defect name a part by its task identity, and their rows are kept per part, so its status, claim, evidence and verdict are its own. An operator acknowledgement names a message number and settles only the message’s own task; a part closes on its own verdict. A part that is not the next one — already recorded, skipped ahead, or 0 — refuses with “part <N> of message #<n> of <session> cannot be recorded: parts are recorded in order, and the next one is part <next>”, and a value that is not a whole number with “--part takes the instruction's number; got <value>”. Recording the message itself again when it is already a task names --part N as the way to record its second instruction.
Refusals and safe exits#
- Refuses without a session, a number and a nonempty --by, or with a task identity in place of a session and number, and prints the usage. A number the session does not hold refuses with “session <session> has no operator message #<n>; it has <count>”. A message that is already a task — every message nobody has read yet is — refuses with “message #<n> of <session> is already task <task-id>; a second instruction in it is recorded with --part N”. A message the model read as work, replaced by a later restatement, refuses with “message #<n> of <session> already reads as work, and a later message that restates it carries the task”. A message the model read as a resume refuses with “message #<n> of <session> is the ledger’s own handover or a resume, not an instruction the operator gave”. A session with nothing stored and no live transcript on this machine refuses with “session <session> has no stored operator messages and no live transcript on this machine”.