Generate all 11 phase implementation plans with bullet-level requirement traceability

All phases (0-8) now have detailed implementation plans with:
- Bullet-level requirement extraction from HighLevelReqs sections
- Design constraint traceability (KDD + Component Design)
- Work packages with acceptance criteria mapped to every requirement
- Split-section ownership verified across phases
- Orphan checks (forward, reverse, negative) all passing
- Codex MCP (gpt-5.4) external verification completed per phase

Total: 7,549 lines across 11 plan documents, ~160 work packages,
~400 requirements traced, ~25 open questions logged for follow-up.

docs/plans/generate_plans.md

@@ -16,10 +16,11 @@ This document defines the phased implementation strategy for the ScadaLink SCADA
 3. **Requirements traceability at bullet level** — every individual requirement (each bullet point, sub-bullet, and constraint) in HighLevelReqs.md must map to at least one work package. Section-level mapping is insufficient — a section like "4.4 Script Capabilities" contains ~8 distinct requirements that may land in different phases. See `docs/plans/requirements-traceability.md` for the matrix.
 4. **Design decision traceability** — the Key Design Decisions in CLAUDE.md and detailed design in Component-*.md documents contain implementation constraints not present in HighLevelReqs.md (e.g., Become/Stash pattern, staggered startup, Tell vs Ask conventions, forbidden script APIs). Each must trace to a work package.
 5. **Split-section completeness** — when a HighLevelReqs section spans multiple phases, each phase's plan must explicitly list which bullets from that section it covers. The union across all phases must be the complete section with no gaps.
-6. **Questions are tracked** — any ambiguity discovered during plan generation is logged in `docs/plans/questions.md`.
-7. **Plans are broken into implementable work packages** — each phase is subdivided into epics, each epic into concrete tasks with acceptance criteria.
-8. **Failover and resilience are validated early** — not deferred to a final hardening phase. Each runtime phase includes failover acceptance criteria.
-9. **Persistence/recovery semantics are defined before actor design** — Akka.NET actor protocols depend on recovery behavior.
+6. **Questions are tracked, not blocking** — any ambiguity discovered during plan generation is logged in `docs/plans/questions.md` and generation continues. Do not stop or wait for user input during plan generation.
+7. **Codex MCP is best-effort** — if the Codex MCP tool is unavailable or errors during verification, note the skip in the plan document and continue. Do not block on external tool availability.
+8. **Plans are broken into implementable work packages** — each phase is subdivided into epics, each epic into concrete tasks with acceptance criteria.
+9. **Failover and resilience are validated early** — not deferred to a final hardening phase. Each runtime phase includes failover acceptance criteria.
+10. **Persistence/recovery semantics are defined before actor design** — Akka.NET actor protocols depend on recovery behavior.
 
 ---
 
@@ -509,6 +510,24 @@ After writing a phase plan, perform this verification before considering it comp
 4. **Negative requirement check**: Every "cannot", "does not", "no", "not" constraint has an acceptance criterion that verifies the prohibition (e.g., "Scripts cannot access other instances" → test that cross-instance access fails).
 5. Record the verification result at the bottom of the plan document.
 
+### External Verification (Codex MCP)
+
+After the orphan check passes, submit the plan to the Codex MCP tool (model: `gpt-5.4`) for independent review. This catches blind spots that self-review misses.
+
+**Step 1 — Requirements coverage review**: Submit the following as a single Codex prompt:
+- The complete phase plan document
+- The full text of every HighLevelReqs.md section this phase covers
+- The full text of every Component-*.md document referenced by this phase
+- The relevant Key Design Decisions from CLAUDE.md
+
+Ask Codex: *"Review this implementation plan against the provided requirements, component designs, and design constraints. Identify: (1) any requirement bullet, sub-bullet, or constraint from the source documents that is not covered by a work package or acceptance criterion in the plan, (2) any acceptance criterion that does not actually verify its linked requirement, (3) any contradictions between the plan and the source documents. List each finding with the specific source text and what is missing or wrong."*
+
+**Step 2 — Negative requirement review**: Submit the plan's negative requirements and their acceptance criteria. Ask Codex: *"For each negative requirement ('cannot', 'does not', 'no'), evaluate whether the acceptance criterion would actually catch a violation. Flag any that are too weak or test the wrong thing."*
+
+**Step 3 — Split-section gap review** (only for phases covering split sections): Submit this phase's bullet assignments alongside the other phase(s) that share the section. Ask Codex: *"Verify that the union of bullets assigned across these phases equals the complete section. Identify any bullets that are unassigned or double-assigned."*
+
+**Handling findings**: If Codex identifies gaps, update the plan before finalizing. If a finding is a false positive (e.g., Codex misread the requirement), document why it was dismissed. Record the Codex review outcome (pass / pass with corrections / findings dismissed with rationale) at the bottom of the plan document alongside the orphan check result.
+
 ---
 
 ## File Index