Oko/Docs

Command reference

oko rulings list

Reads the ruling that stands on each subject — the newest operator message recorded as deciding that task or defect that no later decision of his superseded — for the named subjects or for every ruled subject, and beside it every ruling of those subjects a later decision superseded.

Invocation#

Command
oko rulings list [--subject ID ... | --role ROLE] [--json]

Inputs and options#

  • --subject, repeatable: a task identity (task- and sixteen hex digits) or a defect id.
  • --role supervisor|executor instead of --subject: every standing ruling on how a session holding that role works, newest first — all of them, not the newest only, since each role ruling is its own subject `role:<role>:<session>#<ordinal>` and stands until the operator supersedes it.

Output and state effect#

  • Prints one line per standing ruling: the subject, the ruling's short id, the session and message number it was said in, `by <email> (<role>)` — the member who said it as the organization's register held them, or `an author not recorded` on a ruling recorded before authors were kept — and the first line of the words; with none it prints `no ruling stands on these subjects in <register path>`.
  • Then one line per superseded ruling: `<subject> <id> superseded by <session> #<n> by <email> (<role>) (<first line of the replacing message>): <cause>`. A ruling is superseded when `oko rulings supersede` verified a later, repeated decision on the same matter in the standing-rule ledger whose author the organization's register gives steering, and, when the earlier ruling is an owner's, whose author is an owner too; it stays in the register with `supersededBy {at, replacement, repeated, cause, author, rule}` — `rule` is the precedence that decided it — and no longer counts as standing. A later message from a member without steering is kept pending with that cause and replaces nothing.
  • --json prints `[{subject, ruling, standing}]`, `standing` false for a superseded ruling, `ruling.author {member, email, organization, role}`. Oko Desktop's Rulings screen reads the same list through the native API, labels each ruling `Said by <email> · <role>`, and marks a superseded ruling `· superseded` with the replacing message, its cause, its author and the rule.
  • With --role it prints, per ruling, its short id, the session and message number and `by <email> (<role>)`, then the operator's whole words indented; with none, `no ruling stands on the <role> role in <register path>`. --json gives the same rows, each under its role subject. Oko Desktop → Agent sessions shows them beside each session's role chip, under `The operator's rulings on the <role> role (<n>)`.
  • Role rulings reach sessions through the register itself: Tama's inject-operator-rules reads every standing ruling in `rulings.json` at session start and after each compaction and prints it under its subject, so a `role:supervisor:…` line stands in front of every session, labelled with the role it binds.

Refusals and safe exits#

  • `oko rulings list does not take <flags>; it takes --subject, --role, --json` (exit 2).
  • `oko rulings list takes --role or --subject, not both: a role ruling is listed by its role` (exit 2).
  • `<role> is not a session role; oko sessions role records supervisor or executor`.

CLI reference#