reviewing-phase-results

Review Phase Results

After each phase finishes, use this phase to review the results. After all phases pass, a spec-level final review must also be done.

Roles

• cc: Decides which artifacts to review; if it fails, decides whether to go back to tasking or execution; if it passes, advances to the next phase
• worker: Performs an in-depth review against the planning artifact and the result log

Rules

• Every completed phase must be reviewed before starting the next dependent phase
• The review must be against the phase plan, not just the diff
• After all phases pass, the complete spec must be reviewed once more
• When a review fails, reopen only the minimal necessary scope

Process

Phase Review

1. Read the phase plan, phase task list, and phase result
2. Dispatch a worker to do a complete phase review
3. Require the worker to check:
   • All planned deliverables exist
   • The task results are sufficient to support the claimed results
   • The verification evidence is sufficient
   • The phase has not deviated from the original goal
   • Follow-up work is clear
4. Persist the phase review output, with the verdict being pass or fail
5. If the review fails:
   • Return to task generation or execution depending on the type of issue
6. If the review passes and the next phase is ready:
   • Return to executing-phase-tasks

Final Spec Review

1. After all phase reviews pass, dispatch a worker to do a final review against the original spec
2. Save the final spec review
3. If the final spec review fails:
   • Return to the minimally affected phase
4. If the final spec review passes:

• Proceed to reporting-results

Review Output Must Include

• verdict
• evidence reviewed
• findings
• required follow-ups, or explicitly none
• Conclusion aligned with the target artifact

Exit Conditions

There are only two cases in which you can leave:

• The current phase review has passed, and the workflow can proceed to the next step
• The final spec review has passed, and the workflow can proceed to reporting

Anti-patterns

• Looking only at code, not at the plan/spec
• A phase review fails but work still secretly rolls forward
• Skipping the final spec-level review