Plan v2 is NOT foolproof without 5 mitigations added for the premortem…

Decision

Plan v2 is NOT foolproof without 5 mitigations added for the premortem findings before AJ executes: M1 Phase 0.5 census must run in 3 modes (smoke, probe-with-scaffold, schema-only) to avoid false-BROKEN on stateful tools; M2 Phase 3.5 metadata router must declare explicit allow-list + deny-list with locked SOAP fallback patch; M3 Phase 4 pre-registration dedup audit prevents silent duplicates that would trip FastMCP on_duplicate=‘error’; M4 Bible Contract § 3 must document migration-advisory as tier-specific exemption with expiry to preserve compliance while honoring capability-loss invariant; M5 Phase 1.5 Upstream Sync cron gets hot-pause trigger blocking Phase 8 cutover if Summer ‘26 preview drops mid-execution. Plan becomes v2.1 after mitigation integration.

Rationale

Premortem surfaced 5 concrete failure modes across Execution/Assumption/Design/People/External categories. Without M1 the census generates false-BROKEN rows for complex tools (sf_mc_create_journey needs Entry Event + Activities pre-built) corrupting evidence base. Without M2 the zero-SOAP-bug invariant is only probabilistically held (edge metadata types like BotVersion may lack Tooling API coverage, and fallback reintroduces the bug class). Without M3 FastMCP on_duplicate=‘error’ at server.py:91 blocks startup at Phase 9 OR silent overlap violates AJ’s zero-ambiguity mandate. Without M4 the capability-preservation invariant conflicts with Bible Contract § 3 -32006 hard-block expectation and Completion Gate Check 4 fails. Without M5 a Summer ‘26 drop between Phase 1.5 sync and Phase 9 cutover makes ‘latest API everywhere’ stale. Reasoning-quality self-audit returned 29% (weakness: rigor — no hypothesis-evidence loops); acceptable for quick-tier planning session but upgrades to standard-tier ST session when AJ says ‘go’ for full execution approval.

Alternatives Rejected

Outcome

Pending