tama assignment show

Prints one session's newest operator instruction verbatim together with Oko's current task ledger, then records that both were read. A question about the task is not itself a replacement task, and a session summary is not a source of task state.

#Invocation

tama assignment show --session SESSION_ID [--json]

--session is required. --json prints the instruction fields and Oko's report under ledger. The readable form also prints how many defects are open in every product and how many of them carry no pushed repair, the commands that list them (oko defects list --unrepaired, and oko defects show ID for one), and then each open defect Oko records this session as owning (oko defects list --open --owner SESSION_ID), with its id, product, title and Oko's repair plan (or the oko defects plan command when none is written). The register itself is not copied: every open defect of every product with its plan made the reading larger than any model's context, and the session read it again on every later call. When Oko cannot be read the section says so and names the failed call. The stop refusal names the companion tama from its own release, so the read uses the same reader version.

After the defects it prints the work other sessions declared on the same repositories: every tama task scope set declaration of another session that shares a repository with this one's and names a task or a defect, newest first, as date, session, shared repositories, task or defect, the operator's words. Work assigned in a parallel or earlier session is the operator's work too, so it is in front of the session before it answers that a task is not on its list. A session that declared nothing sees no such section.

The readable form does not print the standing rules, the rulings or the operator's answers to excuses: inject-operator-rules puts them in front of the session when it starts and after every compaction, so they are already in its context, and printing them again on every reading doubled them. Its last line names oko tasks rules --all for a session that wants the rules printed.

The block inject-operator-rules delivers carries each distinct rule text once (with how many times and since when the operator said it), then the operator's rulings from Oko's ruling register (oko rulings list): one line per message he ruled in, listing every task or defect that message decided, with its session and message number and his words. Each of his sentences is written once in the whole block. The operator rewords a standing rule by inserting words into some of its sentences, so the ledger holds several variants of one instruction; a variant, or a ruling, keeps only the sentences the block has not written yet and ends with [N more sentence(s) of it are written above], or reads [every sentence of it is written above] when none is new. Sentences are compared whole by their words (case and the punctuation around words aside); one changed word, a nie included, makes another sentence, which is written, so no order is merged into a different one and no sentence of any rule is lost. An existing ruling register that cannot be read or decoded refuses restoration with its path and cause; a missing register remains the documented initial state with no recorded rulings.

Standing-rule restoration is required, not a diagnostic substitute. If oko tasks rules --all --json cannot run, fails or returns an invalid report, or the ruling register cannot be read, tama hook inject-operator-rules exits unsuccessfully, emits no context payload and writes TAMA_HOOK_INFRASTRUCTURE: cannot restore operator rules for SessionStart: <operation and cause> to stderr. A successfully read empty ledger remains distinct from an unavailable ledger; standing rules without required rulings are not complete restored context.

tests/operator-rules/distinct.rs covers real-ledger replay (one line per distinct rule text under its newest message with its count, no sentence written twice, and every sentence of every ledger rule present), a genuinely absent Oko executable, a real filesystem refusal when a directory is selected as the ruling-register file, and malformed JSON in an isolated ruling register. Refusal cases run the built hook, retain commands, exit status, stderr and the observed operating-system or parser cause beside the source revision, and check that no replacement or partial context is emitted. Evidence setup refuses a modified tracked source tree.

The reading asks Oko's registers for open items only, and starts no Oko inside a hook: the session's task ledger and every session holding open work come from the snapshot Oko settles outside every hook (oko tasks snapshot --session ID, the answer of oko tasks --open --session ID --read-only --owed --json written to ~/Library/Application Support/Oko/open-work/<ID>.json), which Tama's core asks for after each prompt and stop of the session it answers, recording when the prompt arrived (open-work.<ID>.json in the session-control directory). A snapshot settled before the session's last prompt does not hold that prompt's work and is refused naming both times; a missing one is refused naming the command that writes it; neither is ever read as no open work, so a gate refuses rather than passes. The open defects are read from the snapshot Oko writes beside its defect register at every write of it (<register>.open.json, oko defects snapshot writes it on demand), so the closed and withdrawn records never travel; a missing snapshot is refused naming that command. The real test is tests/assignment/show_registers.rs (cargo test -p tama-cli --test assignment_show_registers, with TAMA_TEST_ASSIGNMENT_SESSION naming a session whose instruction this machine captured): it runs both forms against the machine's own Oko, checks that the count equals what oko defects list --open holds, that the listed defects are exactly those oko defects list --open --owner names for the session and that the standing rules are not repeated, and writes each form's wall time and size to its report beside the source revision.

#Output and state

Each session has its own captured instruction and separate read receipt under the Tama state root. TAMA_ASSIGNMENT_STATE selects a base filename for this namespace, not a shared assignment file. An older machine-wide record is not adopted as another session's instruction. The capture preserves whitespace, and even an identical instruction submitted in a new turn requires a new read.

The ledger is the one Oko settled into the session's open-work snapshot, its unread messages included; Tama's core runs oko tasks snapshot --session SESSION_ID with the Oko program TAMA_OKO_CLI names, and OKO_OPEN_WORK moves the snapshot directory as it moves Oko's. Oko reads the selected transcript and the shared ledger's recorded classifications, evidence and relations as the signed-in member. A local transcript alone does not replace those shared records. Human-attributed OMP steering is an operator message; runtime steering is not. See Oko's task reader for the supported command group and refusal details.

A successful read exits 0 and writes a receipt only after delivering the output. The receipt binds both the captured turn and the Oko report. block-stale-assignment reads Oko again before allowing the turn to end: a new instruction, changed task state or changed selected index invalidates the receipt. One session cannot acknowledge another, and a slow read cannot overwrite a newer instruction.

#Code authors and later batch tests

Writing code ends with commit, push and an accepted oko tasks submit handoff. Oko retains separate author and qualification states: an unmet acceptance check or recorded blocker keeps the task open even after a handoff is accepted. Tama reads that state through the existing ledger; it does not demand a per-task build or treat queued tests as passed. The later Stado batch covers the accumulated revisions. Failed qualification reopens the affected task, so the next ledger read again reports executable work. oko tasks qualification refreshes recorded results without starting a build. A commit string alone is not an accepted handoff or a successful qualification.

#Refusals and failures

• An unknown command, unknown option, missing session or missing option value exits 2 and explains the required invocation.
• A missing or unreadable instruction exits 1 and names the session; check record-current-assignment. Another session's record is never a fallback.
• An unavailable Oko executable, unknown session, unreadable index or transcript, failed process or invalid report exits 1. The diagnostic identifies the actual operation and error. A failed standing-rule read is not converted into an empty rule list or a successful readable assignment.
• A new instruction arriving during the read requires another read. Failed output delivery or receipt writing exits 1 without acknowledging the new state.
• The stop guard refuses when it cannot verify the current state, rather than accepting a stale receipt. With no captured instruction it preserves the existing no-record policy; a stop event without a session identifier is refused.

Return to the complete CLI tree.