oko blockers record

Invocation#

oko blockers record --blocks TEXT --failed TEXT --error TEXT --tried TEXT --resumes-when TEXT --session ID [--waits-on TEXT] [--json]

Inputs and options#

• Every flag but --waits-on is required and a blank value is refused by name.
• --resumes-when must be a state somebody can check — a service answering, a release published, a file present — never a decision somebody has to make.
• --waits-on names the task, defect or repository whose repair the refusal waits on: an install refused until a fix is released, a push refused by a gate whose own repair needs that push. It is kept on the blocker as waitsOn and is the edge `oko blockers graph` draws from the blocker to that item; recording the refusal is what adds the edge.

Output and state effect#

• The blocker is appended to the register first, carrying `unjudged` with `Brama's reviewer had not answered when the record was written`, and only then does Brama's reviewer read it against the operator's definition of a blocker. The reading is a typed decision on Brama's `POST /v1/decisions` through Oko's decision alias (`decision-model`): a `choice` between `blocker` and `not_a_blocker`, and the register acts on the option Brama chose, never on a word in a reply. One the reviewer finds is not a blocker is taken out of the register again and refused; one it accepts loses the `unjudged` mark. An Oko that asks a service declared with oko model-service set has no decision endpoint to ask, so its blocker stays `unjudged`, the cause saying that service answers chat completions only and that oko model-service clear returns Oko to Brama.
• When the reviewer does not answer — Brama's route held, refused or unreachable — the blocker stays, its `unjudged` now `Brama's reviewer did not answer: <cause>`; stderr says `blocker review unavailable, the record is kept unjudged: <cause>`. A reviewer that never answers, such as a credential read that stands on a held vault connection, can hold the command, but the record is already in the register: `oko blockers list` shows it `unjudged` with the first mark. `oko tasks state --blocked` keeps the same `unjudged` cause on the task's blocked term.
• Prints `recorded blocker <id> on <what it blocks>`, followed by `, waiting on the repair of <item>` when --waits-on was given.
• When what it blocks and what it waits on are both tasks or registered defects, the wait is also written as the shared relation `<blocks> blocked-by <waits-on>`, by the recording session with `refusal <id> recorded: <failed> answered <error>` as its reason, so every machine's graph and `oko tasks relations` read it. Between anything else (a repository, a host) the edge stays this machine's register's. A write the task graph refuses — a loop, an unknown end, an author that is not a session — follows the recorded blocker as `blocker <id> was recorded, but what it waits on was not written to the shared task graph: <cause>` (exit 1).

Refusals and safe exits#

• `oko blockers requires --blocks <text>` and the same for --failed, --error, --tried, --resumes-when and --session (exit 2); `a blocker needs the task, defect or repository it stops`, `a blocker needs the operation that failed`, `a blocker needs the exact error that operation returned`, `a blocker needs the alternative route that was tried`, `a blocker needs the condition under which work resumes`, `a blocker needs the session that recorded it`, and with --waits-on `a blocker needs the task, defect or repository whose repair it waits on`, for a blank value.
• A resume condition that is a decision, a choice or a pick, in Polish or English, is refused with the operator's rule `Czekanie na decyzje operatora jest ZABRONIONE. Masz pracowac az skonczysz swoje zadanie. Brak decyzji operatora nie jest blockerem.` followed by `A blocker resumes on a state somebody can check (a service answering, a release published, a file present), not on a choice: carry out the recovery yourself. Resume condition given: <text>`.

CLI reference#

• View the complete oko command tree