Immutable. This exact content is served forever at /api/v1/blob/60e874b127f5cb54.
---
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 artifact, and a row whose named artifact is not on disk. Artifacts live under `/tmp/zforge/artifacts/{feature}/`, cited by their full path — open the path rather than searching the tree. A feature already closed has dropped that directory; there, the row's finding is what stands.
**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.