Project Forge Review
Review the integrated result, not an implementer's summary. Be demanding,
specific, reproducible, legally distinct, and honest about unavailable evidence.
Read references/critic-protocol.md before
reviewing.
Independence Check
Record:
- reviewed slice and revision,
- whether this context authored any reviewed code,
- available runtime and capture capabilities,
- required gates,
- missing evidence.
If this context authored the implementation, do not issue final approval.
Perform a useful self-review, label independence limited, and require another
reviewer for acceptance.
Review Workflow
- Read the project contracts and current assignment.
- Inspect the worktree and identify the exact reviewed revision.
- Build and run the integrated product.
- Exercise the real player, user, or request path.
- Reproduce every required named review state.
- Inspect console, server, lifecycle, and failure behavior.
- Review deterministic captures at representative viewports.
- Inspect motion, audio, and timing when relevant.
- Profile active worst-case scenarios when required.
- Perform a blind A/B comparison when legal references are available.
- Rank defects by severity and player or user impact.
- Return
PASS, REWORK, BLOCKED, or UNVERIFIED.
Do not edit the reviewed subsystem silently. The lead may explicitly assign a
separate correction slice after the report.
Findings
Every finding must include:
- severity:
critical, high, medium, or low,
- observable symptom,
- exact reproduction,
- evidence path or metric,
- likely owning subsystem,
- root-cause hypothesis clearly labeled as a hypothesis,
- observable closing condition.
Aggregate repeated symptoms when one root cause explains them.
Verdict Rules
Return REWORK while any critical or high finding remains.
Return UNVERIFIED when a required claim lacks evidence or the environment
cannot capture it.
Return BLOCKED only for a real external constraint after meaningful available
review work is exhausted.
Return PASS only when:
- all required states were exercised,
- evidence belongs to the reviewed revision,
- all applicable gates pass,
- no critical or high defect remains,
- originality and legal-distinctness checks pass,
- residual risks are explicit.
Rework Loop
After corrections:
- Rebuild the integrated product.
- Reproduce the original defect.
- Capture fresh evidence.
- Rerun affected neighboring states.
- Update rather than erase the finding history.
- Issue a new verdict.
Do not lower the threshold because several iterations were required.
Output
Write or return a report using the schema and template in
references/critic-protocol.md. Keep evidence
status distinct from subjective scoring.
1---2name: project-forge-review3description: Perform an independent adversarial review of an integrated game or software project using reproducible runtime, visual, interaction, accessibility, determinism, and performance evidence. Use after a Project Forge slice enters review, before accepting a baseline, or when a project looks complete but its quality claims have not been independently verified.4license: MIT5---67# Project Forge Review89Review the integrated result, not an implementer's summary. Be demanding,10specific, reproducible, legally distinct, and honest about unavailable evidence.1112Read [references/critic-protocol.md](references/critic-protocol.md) before13reviewing.1415## Independence Check1617Record:1819- reviewed slice and revision,20- whether this context authored any reviewed code,21- available runtime and capture capabilities,22- required gates,23- missing evidence.2425If this context authored the implementation, do not issue final approval.26Perform a useful self-review, label independence `limited`, and require another27reviewer for acceptance.2829## Review Workflow30311. Read the project contracts and current assignment.322. Inspect the worktree and identify the exact reviewed revision.333. Build and run the integrated product.344. Exercise the real player, user, or request path.355. Reproduce every required named review state.366. Inspect console, server, lifecycle, and failure behavior.377. Review deterministic captures at representative viewports.388. Inspect motion, audio, and timing when relevant.399. Profile active worst-case scenarios when required.4010. Perform a blind A/B comparison when legal references are available.4111. Rank defects by severity and player or user impact.4212. Return `PASS`, `REWORK`, `BLOCKED`, or `UNVERIFIED`.4344Do not edit the reviewed subsystem silently. The lead may explicitly assign a45separate correction slice after the report.4647## Findings4849Every finding must include:5051- severity: `critical`, `high`, `medium`, or `low`,52- observable symptom,53- exact reproduction,54- evidence path or metric,55- likely owning subsystem,56- root-cause hypothesis clearly labeled as a hypothesis,57- observable closing condition.5859Aggregate repeated symptoms when one root cause explains them.6061## Verdict Rules6263Return `REWORK` while any critical or high finding remains.6465Return `UNVERIFIED` when a required claim lacks evidence or the environment66cannot capture it.6768Return `BLOCKED` only for a real external constraint after meaningful available69review work is exhausted.7071Return `PASS` only when:7273- all required states were exercised,74- evidence belongs to the reviewed revision,75- all applicable gates pass,76- no critical or high defect remains,77- originality and legal-distinctness checks pass,78- residual risks are explicit.7980## Rework Loop8182After corrections:83841. Rebuild the integrated product.852. Reproduce the original defect.863. Capture fresh evidence.874. Rerun affected neighboring states.885. Update rather than erase the finding history.896. Issue a new verdict.9091Do not lower the threshold because several iterations were required.9293## Output9495Write or return a report using the schema and template in96[references/critic-protocol.md](references/critic-protocol.md). Keep evidence97status distinct from subjective scoring.
moinsen-dev