---
name: review
description: Give one behavior or a whole dossier an independent second read in a fresh context. Examine each claim against the evidence it maps to, test the scope of the explanation, and assess the formal abstraction and the recorded answers. Record the findings, and what was examined, in one review file. Use for a second opinion or an independent review. Not for adding claims, running new trials or making the owner's decisions.
argument-hint: <part|composition> [behavior]
context: fork
allowed-tools: Bash(dossier verify *), Bash(dossier show *), Bash(dossier where *), Bash(dossier recheck *), Bash(dossier review-basis *)
---

# Review

`dossier` is [`bin/dossier`](../../bin/dossier) at the root of this plugin. Where it is not on the PATH, run it by that path.

Review the subject named in `$ARGUMENTS` in a fresh context, with none of the keeper's conversation. Read the artifacts yourself. A behavior explains a mechanism through precise claims. Assess those claims against their evidence, and do not adopt the author's interpretation.

Follow [the review contract](../../spec/review.md) for the subject, the coverage, the binding of the exact inputs, the assessment of each mapping and the status of each finding. Verify checks the record and its current basis. It does not make your assessment.

1. Run `dossier verify --brief <dossier>` and record its lines, leaving out the `read:` line, which names a path on this machine. Read the dossier's README and the selected behavior, or every behavior for a dossier review. A focused review follows what the selected behavior depends on. A review of the whole dossier also considers what the collection covers, and the formal work that no behavior is associated with.
2. Run `dossier review-basis <dossier> --json`, adding `--behavior <id>` for a focused review. Read the issues, the required files and the coverage items it reports. The helper reads nothing on your behalf and assesses no mapping. Resolve any missing input before you rely on its basis. Read [semantics](../../spec/semantics.md), [behaviors](../../spec/behaviors.md) and [evidence](../../spec/evidence.md). Follow each mapping to its exact formal target or knowledge record, and to its current published answer. Read the prose, the models, the actors' assumptions, the wiring, the scenarios and the source pins you need to assess it. Use `decisions.log` to find what the owner actually decided.
3. Work through every review item that applies. Record what you examined and what you did not. Judge whether each assertion fits its evidence, whether each assumption is warranted, and whether the model, the source and the deployment have been kept apart as scopes. Retell traces yourself, from the entries, before you compare them with the keeper's readings.
4. Where the toolchain is installed, run `dossier recheck` for the dossier. Report which answers came back the same, which came back different and which did not run. The comparison writes nothing and creates no new evidence. `dossier show <dossier> <entry>` prints an entry's trace. `dossier where <dossier>` locates the formal objects. Use `dossier verify --json` for the facts the tool derives from the evidence, not the ledger, which may be stale. External cases alone do not establish correspondence to the source. Inspect the pinned knowledge backing, and assess that connection separately.
5. Write one new file under `reviews/`. It begins with the JSON record that [record formats](../../spec/artifacts.md#record-formats) defines, and binds the complete set of resolved dependencies that review-basis returned, as [specified](../../spec/review.md#scope-and-binding). Copy its entries unchanged, the claim and explanation digests of each behavior file included, so that a later change to one claim takes only that claim's assessments out of effect. Add the coverage, each mapping's assessment and the findings, in [the required form](../../spec/review.md#findings-and-status). A review of one behavior cannot count as a review of the whole dossier. Add, with `role: "additional"`, the files you inspected that your judgment depends on and the resolver cannot infer. Bind only files that another clone can have again byte for byte: the files version control keeps, and source checked out at a fixed commit. A checkout of a branch moves when it is fetched again, and a review that binds it reads as stale there, so name such a file in the findings by its repository, commit and path instead. A ledger or the index binds nothing, since every render rewrites them. Do not abbreviate the binding to a prose hash. Run verify again to confirm that the review parses and that its basis is still current. If an input changed while you examined it, assess what changed before you issue a new current review.
6. Report the subject, the limits of the coverage and the findings, each with the status of its support. Keep the reviewer's assessment apart from the tool's evidence and the owner's decision. A verified finding may describe a defect, and an accepted violation stays violated.

An entry holds the question, the prediction, the answer with any trace, the answer's basis and the last answer that differed. What the checker returned is in that entry, not only in the keeper's reading. A trial's local bundle may hold further diagnostics, but the review cannot require it to recover the published conclusion. A trial id identifies a past execution. Current support must resolve the current answer.

That new review is the only file you intend to write. Do not edit an input, the evidence or an earlier review, and do not record a decision, set a mark or run a new trial. Record a new concern or a correction with its references. The keeper can act on it in separate authorized work. No count of findings is a target. Include every supported finding, and say what remains uncertain.