Immutable. This exact content is served forever at /api/v1/blob/e32ab8f9d2e5271d.
--- name: review description: Check implementation against an existing zforge feature ledger; not for general code review. --- # Ledger vs. Implementation Check what the code does against what the feature's documents say it does. This is not a general code review. Bugs, security, performance and style belong to Codex code review and `$compound-engineering:ce-review`, which are better at them and do not need the ledger. **This review is the one nobody else can run**, because it is the only one holding the plan, the patterns, the decisions and the evidence claims at the same time. ## Arguments - `--feature <name>` — the feature directory to review against. Required; without a ledger there is nothing here to do. ## What to read first 1. `02_plan.md` — schema, contracts, phase decomposition, **Verification Matrix**, **Environment Assumptions**, **Invariants** 2. The core patterns doc, if the Doc Map lists one — the rules agents were told to follow 3. `decision_review.md` §A and §C — the decisions that reached beyond the implementation, and whatever the user has already adjudicated 4. Every phase file's `## Decisions` — the implementation conventions that were not promoted. This is the larger set, and it binds the code just as tightly 5. Every phase file's `## Evidence Required` and `## Acceptance` 6. `05_progress_overview.md` — open standing flags Then read the code those documents describe. ## What to check Four questions, each answerable against a document rather than a judgment call: **1. Do the decisions hold in the code?** Every 🟡 and ✅ entry in `decision_review.md`, and every row in a phase file's `## Decisions`, claims something about how the system works. Check the call sites. A decision recorded once and violated in four places is the common shape, and it is commonest among the unpromoted conventions — the ledger's rows had the user's eye on them, the phase files' rows had nobody's. **2. Are the invariants implemented and re-checked?** `02_plan.md` names invariants with an owner phase and a re-check phase. Verify each is actually established, and actually holds at every call site — not just the one the owning phase wrote. Anything spanning phases is verified by no single phase file, which is why it survives to here. **3. Does the evidence match the artifacts?** For every `## Evidence Required` row, the claimed class must have something behind it. A row claiming E4 with no browser-executed artifact, or E3 with tests that only ever ran in the wrong runtime, is a false claim in the ledger — report it as one. So is a figure presented as a measurement that appears in no committed artifact, and a row whose named artifact is not in the tree. **A row accepted below its required class is a recorded waiver** where `## Acceptance` carries the reasoning that settled it. Check that reasoning rather than the class: does the postcondition really hold without what the missing class rules out, and has a later phase since come to depend on it? A waiver that was sound at acceptance and has been overtaken is a finding, and it opens a standing flag rather than a correction. A **J** row is checked the same way: the method and the referent must both be named, and the walk must have a recorded result. A J2 row whose referent turns out to be the case the design was derived from is a J1 claim wearing a J2 label, because the referent supplied no resistance. **4. Do the environment substitutions still hold?** Each substitution in `## Environment Assumptions` deferred some verification. Check whether the deferral is still true, still recorded, and still visible as a standing flag. ## Method Spawn parallel subagents when the surface is large — one per document-to-code axis above, each returning its findings. Give each the ledger sections it needs and the code paths those sections name. Every finding must cite **both sides**: the document and line that states the rule, and the file and line that departs from it. A finding that cannot cite both is a code-quality opinion and belongs in a different review. ## Output Append to `05_progress/review.md`: | # | Finding | Document says | Code does | Phase | Severity | |---|---------|---------------|-----------|-------|----------| Then report to the user: - Findings, ordered by severity - Any decision entry that should move to ❌ as a result - Any standing flag that should be opened — an evidence claim that did not survive checking is a flag, not just a finding Nothing here is filtered by a confidence score. A mismatch between a document and the code either exists or it does not, and both sides are cited so the user can check in seconds.