Project Vision Eval

When to Use

After Vision is drafted. Run by a Project Evaluator — not the same agent who wrote the Vision.

Inputs

• Project path ({Dept}/Projects/{Project}/)
• Vision document
• Any existing {Project}_Vision_Eval.md

Context Boundary

Read only: Vision and any existing Vision_Eval report. No other project documents.

Prerequisite

HARD GATE: If you are in the same session that wrote the Vision, STOP. Tell the user: “Vision evaluation requires an independent reviewer — please start a new conversation and run Vision Eval there.” Do NOT proceed with evaluation.

Phase Names

• Start: Vision_Eval_Started
• End: Vision_Eval_Completed

Checklist

1. Clarity — each requirement is unambiguous; a reader can understand it without asking the author

2. Testability — each requirement can be verified as met or not met through inspection, test, or demonstration

3. Non-contradiction — no two requirements conflict with each other

4. Completeness — the set of requirements covers the stated project scope with no obvious omissions

5. Charter considerations — the Vision addresses any relevant charter principles that apply to this project:

   • Stewardship — does this project affect customers, personnel, management, shareholders, or community? If so, the Vision must include a requirement addressing stakeholder impact
   • Security — does this project touch sensitive data, privileged tooling, or access control? If so, the Vision must include a requirement addressing security review or safeguards
   • Privacy — does this project handle user data, personal information, or data sharing? If so, the Vision must include a requirement addressing privacy decisions
   • Performance tracking — does this project involve agent execution, automation, or infrastructure where cost/token/run metadata matters? If so, the Vision must include a requirement addressing performance measurement

   Not every project needs all four. The evaluator judges relevance based on the project’s scope. If none apply, mark ✅ with a note. If one or more apply and the Vision already addresses them, mark ✅. If one or more apply and the Vision does not address them, mark ⚠️ with a finding.

Procedure

1. Read the Vision document and any existing {Project}_Vision_Eval.md
2. Update {Project}_Phase.md: set Phase: Vision_Eval_Started
3. Build, commit, push
4. Run each checklist item, marking ✅ or ⚠️ with a brief note
5. Format findings using Forge/Forge_Project/Skills/Project_Create/templates/Vision_Eval_Template.md:
   • Replace variables with project values
   • No findings: Set Verdict to Approved, omit the Items table
   • Findings exist: Set Verdict to Rejected or Conditionally Approved, populate Items and Resolution Log
6. Write findings to {Project}_Vision_Eval.md (create or overwrite)
7. Add sidebar entry for the report by spawning the Page Manager bot via spawnAgent with { botGroup: 'forge', botHandle: 'page-manager' } (placed under the project’s documents group)
8. Build, commit, push
9. If findings exist — auto-fix loop:
   • Direct the Thinker to fix the specific findings in the Vision document
   • Re-evaluate after fixes; iterate up to 3 rounds
   • Only escalate to the user when Thinker and Evaluator cannot converge (after 3 rounds, or when findings involve genuine ambiguity or trade-off decisions)
   • Update {Project}_Phase.md: set Phase: Vision_Started (return to Vision for revision), then back to Vision_Eval_Started when revision is complete If no findings (or auto-fix converged): Update {Project}_Phase.md: set Phase: Vision_Eval_Completed
10. Update frontmatter status to approved in both the Vision document and the Vision_Eval report
11. Build, commit, push

Rules

• Flag only real issues — not theoretical ones. If a checklist item passes on its own terms, mark ✅ even if the pattern could be a problem in other contexts
• The report file is durable review history — it persists across reruns and is not deleted when the project returns to Vision
• An independent reviewer must run this phase — never the same agent/session that wrote the Vision
• The auto-fix loop should resolve most findings without user involvement. Only genuine ambiguities or creative decisions require human input