project-forge-review

name	project-forge-review
description	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.
license	MIT
compatibility	Works with any agent. Browser, screenshot, audio, and profiling capabilities are optional, but unavailable evidence remains unverified.
metadata	{"author":"moinsen-dev","version":"0.1.0"}

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

1. Read the project contracts and current assignment.
2. Inspect the worktree and identify the exact reviewed revision.
3. Build and run the integrated product.
4. Exercise the real player, user, or request path.
5. Reproduce every required named review state.
6. Inspect console, server, lifecycle, and failure behavior.
7. Review deterministic captures at representative viewports.
8. Inspect motion, audio, and timing when relevant.
9. Profile active worst-case scenarios when required.
10. Perform a blind A/B comparison when legal references are available.
11. Rank defects by severity and player or user impact.
12. 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:

1. Rebuild the integrated product.
2. Reproduce the original defect.
3. Capture fresh evidence.
4. Rerun affected neighboring states.
5. Update rather than erase the finding history.
6. 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.