Skip to content
ribhuthe guide

Ribhu guide / 03

Leave a visible seam.

A completion claim says what the author believes. Verification and receipts let you examine what supports it. When a run breaks, the record should show the break—not sand it away.

Separate claim from evidence

The request
The desired result and any acceptance criteria you explicitly stated. Criteria are requirements, not proof that the result exists.
The checks
Tests, builds and other observations tied to that result. Their scope matters: source checks don’t establish installed or live behavior.
The record
Receipts and ledger entries describing the turn and its effects. A coherent history still needs to be read alongside what happened in the workspace.

Verify a turn

The documented verification command checks the newest turn’s receipt for the project: the record’s chain, what the turn did, and whether each changed file still matches.

From the project directory
ribhu verify --last

That is useful evidence of custody and current file agreement. It isn’t a claim that the implementation is correct, the right tests ran, or an external action succeeded.

When the outcome is incomplete, keep that label. “Implemented, unverified” is more useful than a confident summary that quietly drops the missing check.

Understand the witness

The witness is an isolated reviewer for code-editing turns. A fresh, kernel-routed review session receives the user’s request, explicitly stated acceptance criteria, the author’s completion claim, the turn’s diff and the tail of its verification output.

It does not inherit the author’s transcript or reasoning. It returns a pass or bounded concerns about criteria, unsupported claims, correctness, blast radius or verification.

Concerns go back to the author for one repair or rebuttal pass. The author remains under the same approval policy; nothing the reviewer says is executed on its own.

/witness reports its session state. /witness on and /witness off change that state.

Continue after interruption

The documented direct-tool ledger records a running event before the effect, then completion or failure afterward. A process that dies can leave a call interrupted. Unknown effect does not mean “nothing happened.”

Recovery inspects the recorded outcome and, where supported, the files. It does not automatically replay cut-off calls. A handover packet gathers recorded facts—including the prior request, stop cause, changed-file agreement and unanswered asks—rather than asking a model to invent a summary.

Inspect a handover packet
ribhu handover

A continuation can record its link to that packet. Verification can rebuild and check the link, preserving custody across runs.

Join from another seat

ribhu attach joins an already-running window in the project. It is a seat on that session, not a new owner of the work.

  • The terminal must allow an attached seat to drive; typing at the terminal takes control back.
  • Seats can narrow their rights, not widen them.
  • An attached seat can approve once or deny, but cannot grant standing permission.
  • Leaving a seat does not turn an uncertain external result into a safe retry.

Reading basis

Adapted from the project’s project reference documents: witness.md, durable-execution.md, attach.md and commands.md. Older cluster-checkpoint examples are not presented as the current Rust runtime.

No installer or public-release availability is implied. Test the exact build and environment before relying on runtime behavior.

Search the guide

Four guides. Search runs here, in your browser. Nothing is sent.