Teamwork Review

Teamwork Review

Review judges one stable candidate against supplied requirements and direct evidence. Prefer an independent Reviewer when the host can provide one. If it cannot, Root may still provide a clearly labelled non-independent review instead of switching workflows or blocking on installation state.

Method

1. Identify the actual candidate, requirements, scope, settled constraints, and direct evidence needed for a verdict. Criteria include standing constraints from the project's always-read instruction surface and the global policy, not only the requirements supplied with the request. A violation of a standing constraint is a finding with severity, even when the supplied requirements do not mention it.
2. Read the candidate and applicable primary evidence. Do not substitute a version, identifier, marker, or test status for semantic inspection.
3. Always judge outcome fit. Judge engineering quality and real-path evidence only where they apply; missing evidence is unknown, not success.
4. Report material findings by severity with precise evidence, impact, and the smallest correction route. Keep unrelated debt separate.
5. Return ACCEPT, REVISE, or BLOCKED, plus residual uncertainty and the next action. A bounded recheck may add evidence only for the unchanged, frozen candidate. If a correction changes candidate content, scope, criteria, or a protected boundary, review it as a successor candidate in a new record.

A protected boundary is a requirement, criterion, candidate identity, or behavior that must remain unchanged for this review record to stay valid. Example: the public API contract or the frozen acceptance criteria. Keep one review record per stable candidate identity. Any correction that changes candidate content, scope, criteria, or a protected boundary creates a successor candidate and a new document rather than overwriting the verdict basis of the old candidate. The old record may receive only an owner-certified successor link; its findings and verdict remain unchanged. Preserve the candidate identity, criteria and protected boundaries, direct evidence, findings and severity, status of each criterion, verdict, residual uncertainty, and evidence-only bounded recheck scope.

A Reviewer handoff names the frozen candidate, requirements, and requested verdict. Reviewer remains read-only and never implements the repair.

Persistence

When a listed checkpoint fires, write in the same response cycle. If separate stable identities each cross a checkpoint, write each to its own path.

Cross-chat memory lives in one Markdown document from references/review.md at docs/teamwork/reviews/<slug>.md. Same identity means the same candidate; reuse that path and name the document you read. A different subject gets a new path.

Checkpoints: a verdict is returned; a bounded recheck adds evidence only for the unchanged frozen candidate; or a successor candidate is opened after a protected-boundary change. Changed content, scope, criteria, or protected boundaries belong to a successor candidate in a new review document.