/forge-review — the board

You are the review board's chair. The 40-rule validator already proves the documents agree with their ledgers. Your board answers the one question nothing else in this repo asks: does this read like a real firm wrote it?

PY below means the project venv python: .venv/bin/python.

What the board is and is not

• Read-only. Absolutely. You and your reviewers never edit a ledger, a manifest, a DocIR file, a rendered document, or state.json. The only write is review --ingest, which merges findings after validating them. A committed fixture's prose is frozen; findings are how you say something is wrong, not a licence to fix it.
• It gates nothing. No finding fails a build, blocks a commit, or feeds a validator rule. It is a report for a human.
• It is a critic, and critics are weak. A critic shares blind spots with the generator that produced the text. That is why the deterministic metrics in report exist alongside you, and why your scope is exactly what no proxy reaches. Do not re-derive what the metrics already measured.

Precision over recall

An empty board report is a valid, good outcome. Say nothing rather than manufacture a finding to fill a template. A reviewer that reports six findings because six feels like the right number is worse than useless: it buries the real one and teaches the reader to skim.

Every finding must name evidence a human can check in seconds — a doc id and a quoted phrase. "The tone feels generic" is not a finding. "d:0001 and d:0008 both open 'We are pleased to confirm'" is.

Step 0 — the deterministic picture first

Run these and read the output BEFORE dispatching anyone:

PY -m orgsmith validate <slug>
PY -m orgsmith report <slug>
PY -m orgsmith review <slug> --sample
PY -m orgsmith review <slug> --digest

• validate output is what reviewers must NOT re-litigate. If it is green, every planted fact, mention, header, formula and ACL grant is already proven correct. A reviewer claiming "the fee is missing from the letter" is contradicting an oracle and is wrong.
• report prints GENERATION-REPORT.md: lengths against brief, same-genre similarity, and the per-batch generator record.
• review --sample writes the reading list to companies/<slug>-metadata/review/sample.json.
• review --digest prints one hex digest of everything the board may read (recipe, rendered share, ledgers, manifest, DocIR, state). Keep it: Step 2 proves the board left the org exactly as it found it.

If validate FAILS, stop. Fix the org first; a board reading a broken org wastes its findings on symptoms of the break.

Step 1 — dispatch the six dimensions

Spawn one fresh-context worker per dimension (Agent tool, in parallel), with the Agent tool's model and effort set explicitly (xhigh unless the user asked otherwise) and the effort named in the prompt so the reviewer's generator stamp records it. Fresh context per reviewer is the point: a reviewer that has watched you reason about the org inherits your blind spots.

cross_document_voice is the reason this board exists. An authoring worker is briefed its own batch, up to six documents; the rest of the corpus's DocIR is on disk and workers have read across batches, but nothing briefs a worker on it and nothing requires the check. So a worker can self-check a pair it wrote together, but no worker reviews the whole corpus, and a pair two authors and two years apart is beyond it. The n-gram metric only catches literal reuse — two documents can share zero 4-grams and still be visibly the same writer, with the same paragraph shapes and the same rhetorical moves. Give that reviewer the whole sample.

Worker prompt, per dimension:

Review the org <slug> in the repo at <repo-root> on the <dimension> dimension only. Follow .claude/skills/forge-reviewer/SKILL.md exactly. The validator output for this org is:

<paste the validate summary from Step 0>

Step 2 — merge and report

Each worker ingests its own findings. When all six are done:

PY -m orgsmith review <slug> --verify-digest <digest>
PY -m orgsmith report <slug>

<digest> is the value Step 0 printed. --verify-digest exits 1 if anything the board may read changed. If it fails, stop: a reviewer edited the org it was reviewing. Restore the change (git status shows it for a committed org), report it to the user, and do not run report over findings from a board that broke its own rule.

report rewrites GENERATION-REPORT.md with the findings table under Review board.

Step 3 — report to the user

Give the user: the count by severity, the findings you judge worth acting on, and your own read of whether the board is telling them something the metrics did not. If the board found nothing, say so plainly — that is a result, not a failure.

Do not act on the findings. Fixing prose is a separate turn with a separate spec, and for a committed fixture it is not permitted at all.