Section 9 compliance checklist: comprehensive normative alignment audit

[mickdarling]

Background

PR #213 (Sprint 7 — Safety Model Phase 1) went through 15 review rounds. Starting around round 10, the findings converged on a recurring pattern: the informative document's Section 9 compliance checklist (docs/security/execution-safety-loop.md) repeatedly fell out of alignment with normative MUST/SHOULD/MAY requirements in docs/versions/v1.0.0-draft.md.

Each fix to a MUST/SHOULD/MAY conflict surfaced 1-2 more similar gaps in subsequent reviews, creating a cascading fix cycle.

Scope

Perform a deep, systematic audit of the Section 9 compliance checklist against ALL normative requirements in Sections 8.6, 8.7, and 8.8 of the core specification. Specifically:

1. MUST completeness: Every normative MUST in Sections 8.6–8.8 must have a corresponding bullet in Section 9.1
2. SHOULD completeness: Every normative SHOULD must have a corresponding bullet in Section 9.2
3. MAY completeness: Every normative MAY must have a corresponding bullet in Section 9.3
4. No cross-level conflicts: No capability should appear at different normative levels across sections (e.g., MAY in 9.3 and SHOULD in 9.2 for the same thing)
5. No implicit dependencies: If a MUST presupposes a capability (e.g., generating verificationId presupposes challenge generation), the presupposed capability should not be classified at a weaker level

Related Issues

Issues found during the PR #213 review cycle:

• Informative doc Section 9.3 classifies step limits as MAY — normative spec says MUST #214 — Step limits classified as MAY, normative says MUST (fixed in PR feat: Sprint 7 — Safety Model (Phase 1) #213)
• Informative doc Section 9.2 verify tier carve-out is over-broad #215 — Verify tier carve-out over-broad in Section 9.2 (fixed in PR feat: Sprint 7 — Safety Model (Phase 1) #213)

The last review round (15) also noted:

• Section 9.3 "MAY support out-of-band verification" conflicting with Section 9.2 "SHOULD implement verify_challenge" — already fixed in commit f546c1a but reviewer processed the older state
• Section 9.2 missing Stage 2 Previous Outcome SHOULD — already fixed in commit f546c1a

Acceptance Criteria

• Every normative keyword (MUST/SHOULD/MAY) in Sections 8.6–8.8 is mapped to a Section 9 bullet
• No normative level conflicts exist between Section 9 bullets
• No implicit dependency gaps where a MUST presupposes a capability listed at weaker level
• Cross-reference table documenting the mapping between normative requirements and Section 9 bullets