Project Verify

When to Use

All Plans have been executed and individually evaluated. The project needs a final holistic review before extraction and completion.

Inputs

• Project path: {Dept}/Projects/{Project}/

Context Boundary

Read only: Vision, Spec, and Changelog. Never read Research, Plans, Learnings, or Execute_State — the Verify evaluates the outcome, not the journey.

Prerequisite

Must be a fresh agent session — new conversation with clean context, no carryover from execution or evaluation.

Procedure

1. Read: Vision, Spec (do NOT read Research, Plans, or Learnings)
2. Update {Project}_Phase.md: set Phase: Verify_Started
3. Build, commit, push
4. Verify every Verification Criterion (V1, V2…) is satisfied
5. Verify the execution matches the Spec as a whole
6. Write findings to the project-level verification report file {Project}_Verification.md:
   • Use Verification_Template.md from Forge/Forge_Project/Skills/Project_Create/templates/
   • If the file already exists, append as a new section with a ## Run — {date} header
   • The Success Criteria should match those in the Vision document, and for every Verification Criterion the status should be set to 🔴 Open or 🟢 Success
   • The Items should list all Defects, Gaps, Variances, and user Changes. There may be more than one per Success Criterion. Each item is one of:
     • Defect — execution doesn’t match Spec or Vision
     • Gap — something in Vision/Spec wasn’t addressed
     • Variance — execution differs from Spec for a reason
     • Change — user-requested modification affecting Vision, Spec, or execution
   • All items start as 🔴 Open
7. Generate {Project}_Runs.md in the project folder, recording available run/cost evidence for the project. Even when exact data is unavailable, record available context such as conversation ids, job ids, dates, commands, and build outputs.
8. Present the report to the user for review
9. For each item, the user decides: fix, update, reject, or defer
10. Process user decisions:
    • Fix: Implement the suggested fix
    • Update: Don’t fix the implementation; update the Spec to match instead. Update Vision, Spec, and/or Plan retroactively to match reality
    • Reject: I disagree with the finding; do nothing
    • Defer: Record for future work. Ask the user if a new Plan or a new Project should be created for deferred items.
    • Change: May require updating Vision, Spec, or just execution — assess scope and act accordingly
11. Only a few minor changes → do the work directly; otherwise → create a new Plan and loop back to Execute. When uncertain ask the user.
12. Iterate until every success criterion has 🟢 Success and the user approves
13. Update frontmatter status to approved in the Verification report and all project work-product documents (Vision, Research, Spec, Plans, Execute_States, Execute_Evals, Changelog, Phase, Learnings, Infrastructure_Inventory, Charter_Alignment, Ambiguities, README, AGENTS)
14. Update {Project}_Phase.md: set Phase: Verify_Completed
15. Build, commit, push

Report File Conventions

• One verification report per project: {Project}_Verification.md in the project folder
• First verification creates the file from the template
• Subsequent verifications (after new Plan execution) append as a new ## Run — {date} section
• The report file is a durable artifact — it persists across the entire project lifecycle
• This file provides a stable target for todo item review links

Post-Verify Prompts

After completing the verification, remind the user:

• Back up .secrets to RoboForm if it was modified during this project
• Back up Railway env vars to RoboForm if they were modified during this project
• Re-index Typesense if any markdown documents were created, modified, or deleted during this project

Rules

• This is a holistic verification — looks at the complete system, not individual Plans
• Vision and Spec should already reflect updated variances from Plan evaluations
• If a new Plan is needed, it follows the normal Execute → Execute_Eval cycle, then Verify runs again
• Context boundary is defined above
• If findings exceed 5 items, create a new Plan by default rather than implementing fixes directly
• Deduplicate findings — when the same issue appears as both a Defect/Variance and a Change, report it once under the most specific category
• Every todo item created for the user that references a work-product must embed the work-product as an artifact block inside the todo body so the user can open it directly from the todo item. Do not include raw URLs, repo paths, or paste instructions. The user records their verdict in the work-product; the system picks it up from there.