teamwork-reviewlisted

# 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. 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. Persist the checkpoint under Persistence before closeout; a host plan or question UI does not complete it. 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