step2-harden-plan

Step 2: Harden the Plan

Pipeline: Step 2 of 5 (Session 1 — Plan Hardening) When: After pre-flight passes (Step 1) Model suggestion: Claude (best at structured plan generation and scope contract design) Next Step: step3-execute-slice.prompt.md (new session)

⚠️ Do not harden plans with headless gh copilot (meta-bug #86). gh copilot in -p / --autopilot mode runs in a sandboxed session that cannot write to your repository regardless of the flags you pass (--allow-all, --allow-all-tools --allow-all-paths --no-ask-user, --yolo --no-ask-user all fail the same way). The CLI will either exit 1 with Permission denied and could not request permission from user, or exit 0 with the edits written to ~/.copilot/session-state/<sid>/files/ instead of your repo.

Use interactive hardening instead: open this prompt in VS Code Copilot chat (agent mode), or call forge_master_ask with mode: "harden". Both can write to the workspace directly.

Replace <YOUR-PLAN> with your plan filename (without path or .md extension).

---

Read these files first:

1. docs/plans/AI-Plan-Hardening-Runbook.md
2. docs/plans/.md
3. docs/plans/DEPLOYMENT-ROADMAP.md
4. .github/copilot-instructions.md

Also check for prior phase lessons (if they exist — skip if not found):

• /memories/repo/conventions.md — patterns and conventions from earlier phases
• /memories/repo/lessons-learned.md — past mistakes to avoid
• /memories/repo/forbidden-patterns.md — patterns that caused regressions

Prior plan postmortems (Phase-25 L5 closed loop): Before hardening, also scan .forge/plans/<plan-basename>/postmortem-*.json for the plan you are hardening (same basename as the draft). If any exist, read the newest 3 and factor them into the Scope Contract:

• If retriesPerSlice shows a slice that flapped 3+ times, strengthen its validation gate or split it into smaller slices.
• If gateFlaps > 0 on multiple prior runs, your gate commands are unstable — replace grep/pipe-based gates with allowlisted node assertions.
• If topFailureReason repeats across postmortems, add a mitigation in the current plan's Risks section and reference the prior failure.
• If costDelta.delta trends upward across runs, flag a budget risk in the plan's Budget section.
• If no postmortems exist, note "No prior postmortems — first execution."

This is a READ of the postmortems — do NOT modify them. Pure signal for the hardener.

Now act as a PLAN HARDENING AGENT (see the Plan Hardening Prompt in the runbook).

CLARIFICATION CHECK: Before hardening, scan the plan for [NEEDS CLARIFICATION] markers. If any exist, list them all and wait for the user to resolve them before proceeding.

Harden .md by adding all 6 Mandatory Template Blocks from the runbook:

• Scope Contract (in-scope, out-of-scope, forbidden actions)
• Required Decisions (flag anything implicit as TBD)
• Acceptance Criteria (use MUST: and SHOULD: prefixes for each criterion — the analyzer scores these)
• Execution Slices (30-120 min each, with Depends On + Context Files + Parallelism tag)
• Re-anchor Checkpoints
• Definition of Done (must include Reviewer Gate checkbox)
• Stop Conditions

IMPORTANT: Format Acceptance Criteria as:

- **MUST**: Description of required criterion
- **SHOULD**: Description of recommended criterion

Do NOT use - [ ] checkbox format — the analyzer cannot score checkboxes as effectively.

For each Execution Slice:

• Tag as [parallel-safe] (with Parallel Group) or [sequential]
• Include relevant .github/instructions/*.instructions.md files in Context Files
• List only instruction files whose domain matches the slice (not all 17 — each consumes context budget)
• Add a Parallel Merge Checkpoint after each parallel group
• Validation gates MUST be executable commands, not prose descriptions:
  • Good: **Validation Gate**:\n\``bash\ndotnet test\n````
  • Good: **Validation Gate**: \dotnet build``
  • Bad: **Validation Gate**: Files compile, DTOs have correct properties
  • For manual checks that can't be automated, prefix with [manual]: **Validation Gate**: [manual] UI layout matches mockup