Forge Project Plan 6 — Check Revisions

Scope: Revisions arising from the Check phase: evaluation disposition rename, Plan mutability change, per-Plan State files, Check→Implement loop, and sidebar reordering.
Spec: Forge Project Spec
Prior plan: Forge Project Plan 5 — Revisions

---

Task 1 — Rename evaluation disposition “accept” → “update”

The user wants the word “accept” replaced with “update” throughout the evaluation protocol. “Update” better conveys that Requirements, Spec, and Plan are being retroactively changed to match reality.

Update these files:

1. Spec §6.1 (Evaluate) — change “accept” to “update” in the user disposition list and its description. The description should say: update: For accepted variances: update Requirements, Spec, and/or Plan retroactively to match reality.
2. Spec §6.2 (Check) — same change if “accept” appears there.
3. Project_Evaluate SKILL.md — change “accept” to “update” in the disposition list and description.
4. Project_Check SKILL.md — change “accept” to “update” in the disposition list and description.
5. Project_Fix SKILL.md — no change needed (Fix doesn’t use dispositions).

---

Task 2 — Change Plan mutability: frozen when next Plan starts

Currently Plans are “frozen once implementation begins.” The user wants Plans to remain mutable during their own Implement/Evaluate/Fix cycle, and only freeze when the next Plan’s implementation starts. This allows correcting mistakes and outdated info without creating separate fix tasks.

Update these files:

1. Spec §2 (Document Types table) — change Plan mutability from “Frozen once implementation starts” to “Frozen once the next Plan’s implementation starts”.
2. Spec §3.7 (Plan definition) — replace “Frozen once implementation begins” with: “Frozen once the next Plan’s implementation begins. During a Plan’s own Implement/Evaluate/Fix cycle, the Plan can be updated to correct mistakes or outdated information.”
3. Spec §4 (Agent Context Boundaries table) — change Fix row: remove “Must NOT read: Requirements, Spec” since Fix now updates Plans too. Agent reads Evaluation, Plan (current), State (current), Learnings, Requirements, Spec.
4. Project_Plan SKILL.md — update the rule about frozen Plans.
5. Project_Implement SKILL.md — update any reference to Plan immutability.
6. Project_Evaluate SKILL.md — change “Plans are never modified” to “The current Plan can be updated during the Evaluate/Fix cycle. It is frozen once the next Plan’s implementation starts.”
7. Project_Fix SKILL.md — change “Plans are still never modified” to reflect that the current Plan can be updated during Fix.
8. Project_Check SKILL.md — update references to Plan immutability if any.

---

Task 3 — Per-Plan State files and sidebar ordering

The Spec already says “one State per Plan” (§3.8) and the Project_Implement skill creates {Project}_State_{N}.md. But the Forge_Project project uses a single consolidated State. This task ensures the system is consistent: one State per Plan, named {Project}_State_{N}, and in the sidebar each State follows its Plan.

Update these files:

1. Spec §3.8 (State definition) — clarify naming: {Project}_State_{N}.md where N matches the Plan number. Add: “In the sidebar, each State follows its corresponding Plan: Plan 1 → State 1 → Plan 2 → State 2, etc.”
2. Spec §8 (Sidebar Order Convention) — change item 7–8 from separate Plan and State groups to interleaved: “Plan 1, State 1, Plan 2, State 2, etc.”
3. Project_Implement SKILL.md — already names files correctly ({Project}_State_{N}.md). Verify and ensure the sidebar step adds State right after its Plan.
4. Project_Evaluate SKILL.md — verify State references use the per-Plan naming.
5. State_Template.md — update the title and heading from {Project} State to {Project} State {N}.

---

Task 4 — Update lifecycle diagram (Mermaid): Check can loop back to Implement

The Project Lifecycle diagram should show that Check can either proceed to Extract or loop back to Implement (via a new Plan). This reflects the existing Project_Check skill behavior: “fix (substantial): Create a new Plan and loop back to Implement → Evaluate → Check.” Convert the ASCII diagram to Mermaid.

Update these files:

1. Spec §1 (Project Lifecycle) — replace the ASCII diagram with a Mermaid diagram that shows an arrow from Check back to Implement (with a new Plan). The flow should be:

flowchart TD
    A[1. Create] --> B[2. Requirements]
    B --> C[3. Research]
    C --> D[4. Spec]
    D --> E[5. Plan - 1 or more]
    E --> F[6. Implement]
    F --> G[7. Evaluate]
    G --> H[8. Fix]
    H -->|9. Repeat for remaining Plans| F
    H --> I[10. Check]
    I -->|Issues found - new Plan| F
    I --> J[11. Extract]
    J --> K[12. Complete]

2. Spec §1 Phase 10 description — update to: “A fresh agent verifies the complete implementation against Requirements and Spec. If substantial issues are found, a new Plan is created and the project loops back to Implement. Otherwise, proceeds to Extract.”
3. Project_Flow SKILL.md — update the Mermaid diagram to show the Check→Implement loop.
4. Project_Flow SKILL.md Phase Detection table — add entries for Check that show both possible next actions.

---

Task 5 — Sidebar and Index Registration, Build Verification, Commit

Standard final task: verify sidebar and index are consistent, build, and commit.

1. Verify all new/changed files are in the sidebar
2. Verify Forge/Skills/index.md is correct
3. Verify Forge/Configs/FORGE.md skills list is correct
4. Run cd .internal && npm run build
5. Commit all changes