R91 — μ Phase 4 Staging — Execution Packet (Step 3 of 5)

Purpose. Specify the ordering rationale + dependency map + dispatch plan that the Step-4 prompt file will record for the future Phase 4 dispatch. This packet does not dispatch anything in R91 — it stages the dispatch surface.

1. Base + branch + worktree

Field Value
Base branch main
Base SHA at audit time 332feb62 (post-#248 R90 hygiene seal)
Feature branch feature/r91-mu-phase-4-staging
Worktree .worktrees/claude/r91-mu-phase-4-staging
Round R91 (autonomous post-mandate follow-up; T3 single-shot)
Effort S (2–3h, docs only)

2. Files to ship (this PR only)

  1. docs/audits/r91-mu-phase-4-staging-audit.md — Step 1, shipped first commit
  2. docs/contracts/r91-mu-phase-4-staging-contract.md — Step 2, shipped second commit
  3. docs/packets/r91-mu-phase-4-staging-packet.md — Step 3, shipped third commit (this file)
  4. docs/guides/implementation/task-prompts/p4.1-mu-integrity.md — Step 4 deliverable (the staging artifact)
  5. docs/guides/implementation/task-prompts/index.md — Step 4 cross-reference update
  6. docs/verification/r91-mu-phase-4-staging-verification.md — Step 5, shipped final commit

Total ≤ 6 git-tracked files. Zero src/ mutation.

3. The 10 slices the prompt file ships

ID Title Effort Depends on Wave Unblocks
P4.1.1 Advisory Record Schema + Envelope S κ P1.5.4 (canonical), κ P1.5.1 (hash) 1 all of P4.2.x, P4.3.1, P4.4.1, P4.5.1
P4.2.1 Circular Logic Detector (DFS) M P4.1.1, ζ P0.7.1 (thought_records), κ P1.2.4 (registry) 2 P4.4.1 (invariant→BLOCK), P4.7.1
P4.2.2 Coercion Trap Detector (option-set) M P4.1.1, κ P1.4.1 (admission), κ P1.3.1 (engine), λ P2.1.2 (compute) 2 P4.4.1, P4.7.1
P4.2.3 Axiom Drift Tracker (sliding window) L P4.1.1, λ P2.2.2 (penalties for parameter-change events), κ P1.1.1 (BPS math) 2 P4.4.1, P4.7.1
P4.3.1 Three Advisory Roles (Translator/Sentinel/Guide) M P4.1.1 3 P4.6.1
P4.4.1 Escalation FSM (4-result + 3 invariant mappings) M P4.1.1, P4.2.1, P4.2.2, P4.2.3, κ P1.4.1 (admission), κ P1.2.4 (registry) 3 P4.6.1, P4.7.1
P4.5.1 Advisory Persistence (mcp_advisories migration) S P4.1.1, P0.2.2 (migration runner) 3 P4.6.1, P4.7.1
P4.6.1 μ MCP Tool Surface (≥4 tools) M P4.3.1, P4.4.1, P4.5.1 4 (closes μ Phase 4)
P4.7.1 Test Corpus + Parity Harness L P4.2.1, P4.2.2, P4.2.3, P4.4.1, P4.5.1 4 (μ Phase 4 seal)
P4.8.1 Fork Hook Subscriber (post-fork invariant sweep) S P4.2.3, θ P3.9.1 (ForkHookRegistry) 4 ι Phase 5 readiness

4. Wave structure (4 waves) 

Wave 1  ─── P4.1.1 (envelope; solo; gates all)
              │
              ├─────────────────┬─────────────────┐
              ▼                 ▼                 ▼
Wave 2  ─── P4.2.1            P4.2.2            P4.2.3
              circular         coercion          axiom drift
              │                 │                 │
              └─────────┬───────┴─────────┬───────┘
                        ▼                 ▼
Wave 3  ─── P4.3.1   P4.4.1   P4.5.1
            roles    escalation persistence
              │         │         │
              └─────┬───┴─────┬───┘
                    ▼         ▼
Wave 4  ─── P4.6.1   P4.7.1   P4.8.1
            MCP      parity   fork-hook
            tools    harness  subscriber

Waves 2, 3, 4 each have 3 parallel slices — fits inside the 3-safe parallel ceiling validated in R87 (κ close) and R89 Phase B (θ close). Total wallclock estimate at AI pace: ~3–4 hours if all 4 waves run back-to-back (vs roadmap’s “~8 weeks” human estimate). Effort budget matches the κ Phase 1 close (R85 → R87, ~1h45m for 20 slices at the similar 3-parallel cadence).

5. Dependency map (upstream closure, by axis)

All Phase 4 μ upstream deps ship at main HEAD 332feb62. Zero unmet upstream blockers; only T0 confirmation remains as the soft gate.

Upstream axis Phase shipped Path Used by μ
κ Rule Engine (Phase 1) R87 (f327936b) src/domains/rules/{engine,canonical,versioning,admission,registry,bps-constants,integer-math,denial-reasons,policy-gate,state-access,parity-harness}.ts All detectors + envelope + escalation
λ Reputation (Phase 2) R89 Phase A (0c858381) src/domains/reputation/{schema,compute,decay,penalties,limits,tokens}.ts D2 coercion (reputation_delta < 0 check); D3 drift (parameter-change events from λ penalties)
θ Consensus (Phase 3) R89 Phase B (332feb62 post-#248) src/domains/consensus/{messages,finality,fork-hook,parity-harness}.ts P4.8.1 fork-hook subscriber; D3 may aggregate over θ events
ζ Decision Trail (Phase 0) R75 src/domains/trail/repository.ts D1 circular-logic edges; PASS results logged here
η Proof Store (Phase 0) R75 src/domains/proof/ Future Merkle-anchoring of advisories
β Task Pipeline (Phase 0) R75 src/domains/tasks/ Slice UUIDs for writeback
α Middleware (Phase 0) R75 src/server.ts (inlined) + src/domains/rules/tool-lock-adapter.ts (P1.4.4) HARD BLOCK lands here when D-class severity = HIGH on coercion-in-admission

5.1 Downstream consumers (post-Phase-4 horizon)

Downstream When
ι State Fork (Phase 5) P4.8.1 stages the subscriber; ι implementation Phase 5
π Governance (Phase 6) P4.4.1’s BLOCK output feeds into π proposal-intake denial when π ships
ξ Identity (Phase 7) (no direct dep)

6. ADR posture

ADR Status Phase 4 impact
ADR-002 (VRF) PROPOSED (R89.C) μ does not consume VRF (μ is observational; no randomness). N/A.
ADR-003 (BFT library) PROPOSED (R89.C, Option C spike) μ subscribes to θ events through θ’s surface; not affected by BFT-library choice. N/A.
ADR-005 (multi-model defer) ACCEPTED μ uses Claude only in Phase 4. N/A.
ADR-006 (concept maturity) ACCEPTED μ stays colibri_code: none until the entire Phase 4 axis ships; graduation to partial lands with the Phase 4 close PR, NOT in this staging PR.

No new ADR is needed for μ Phase 4. The detector algorithms (DFS, option-set, sliding window) are textbook; the schema is pure data; the roles are pure read-side adapters; the MCP tool surface follows the Zod-v3.23 + registerTool pattern already in use across β/ε/ζ/η/λ/θ.

7. Roadmap budget reconciliation

docs/5-time/roadmap.md §Phase 4 line 420 declares ~8 weeks estimated horizon and 15 estimated tasks with 7 file targets.

docs/guides/implementation/task-breakdown.md §Task Summary line 1138 declares 2 sub-tasks.

These disagree. The staging prompt resolves the contradiction by carrying 10 slices that map 1:1 to the spec surface in §2 of the audit (8 spec sections + 2 cross-cutting harness/fork-hook slices). This is the same granularity-refinement that κ went through (task-breakdown.md declared 10 sub-tasks; prompt file shipped 20) and θ went through (declared 7; shipped 13).

The 2-task task-breakdown row is not amended in R91 (out of scope per the dispatch packet’s “no task-breakdown.md mutation” forbid; flagged in audit §Q4 for a separate hygiene round).

8. Writeback for the staging PR itself (this round)

The 5-step chain output for R91 is itself recorded in:

  • Audit, contract, packet, prompt-file, verification — 5 commits (one per step; the index.md edit folds into the prompt-file commit).
  • PR body — full writeback per CLAUDE.md §7, includes:
    • task_id (β task UUID db30d6c2-a751-443e-b71c-9515ce33f8cd)
    • branch + worktree
    • 5 commit SHAs
    • test gate output (build + lint + test all PASS; 3102/3102 unchanged)
    • 1-line summary
    • blockers (specifically: spec divergences flagged in audit §Q1–Q7 do NOT block staging)

No thought_record is recorded in R91 because no live MCP client is attached (CLAUDE.md §4 alt branch: writeback lands in PR body + memory file, not in a live ζ chain). PM may later fold this into ζ on T3’s behalf per CLAUDE.md §8 leaf-helper precedent (the R88.B pattern).

9. Writeback for each Phase 4 slice (when dispatched, NOT now)

Each P4.X.Y slice MUST follow CLAUDE.md §7:

task_update(id="<PM-supplied UUID>", status="done", progress=100)
thought_record(
  thought_type="reflection",
  content="task_id: <UUID>
branch: feature/p4-X-Y-<slug>
worktree: .worktrees/claude/p4-X-Y-<slug>
commit: <SHA>
tests: npm run build && npm run lint && npm test (<N>/<T> pass)
summary: <slice headline>
blockers: <none or details>"
)

For proof-grade slices (any that touch the legitimacy axis or are marked proof_grade: true), the slice MUST also call audit_session_start + audit_verify_chain + merkle_finalize + merkle_root in the order specified in CLAUDE.md §7 (final thought_record BEFORE merkle_finalize).

10. Gates

npm run build && npm run lint && npm test MUST pass against main baseline (3102/3102 tests unchanged). This is a docs-only round; failing this gate means the worktree drifted relative to main.

11. PR description template 

docs(r91-mu-staging): stage P4.1.1–P4.8.1 prompt file for μ Integrity Monitor (R91 autonomous, status: staged)

Phase 4 μ Integrity Monitor staging file. 10 slices across 4 waves,
mirroring the R89.B (λ) + R89.C (θ) staging patterns. Status frontmatter
`staged` (NOT `ready`); future Phase 4 dispatch requires explicit T0
confirmation.

## Writeback (for PM to fold into ζ chain)
task_id: db30d6c2-a751-443e-b71c-9515ce33f8cd
branch: feature/r91-mu-phase-4-staging
worktree: .worktrees/claude/r91-mu-phase-4-staging
commits: <SHA1>, <SHA2>, <SHA3>, <SHA4>, <SHA5>
tests: npm run build && npm run lint && npm test (all PASS; 3102/3102 unchanged, docs-only)
summary: 10 P4.X.Y slices staged in 4 waves over docs/guides/implementation/task-prompts/p4.1-mu-integrity.md (status: staged). Coverage matrix in verification doc confirms every s14 + integrity.md surface row mapped to ≥1 slice and every slice cites ≥1 spec source. μ stays colibri_code: none until Phase 4 ships.
blockers: 7 minor spec-divergences between s14 and integrity.md flagged in audit §Q1–Q7 (resolved by adopting integrity.md as canonical per CLAUDE.md §9.4); do NOT block staging.

12. Forbiddens (re-asserted from dispatch packet)

  • --no-verify, --amend, --force-push
  • Main edits
  • Touching any source code
  • Modifying κ/λ/θ frontmatters
  • Advancing μ to colibri_code: partial
  • ADR-002 / ADR-003 / ADR-005 / ADR-006 mutations
  • Mutating task-breakdown.md §Phase 4 (flag for separate hygiene round)
  • Inventing new ADRs for μ
  • Dispatching any Phase 4 slice in R91

Packet closed 2026-05-13. Base SHA: 332feb62. Next: Step 4 prompt-file authorship.

Back to top

Colibri — documentation-first MCP runtime. Apache 2.0 + Commons Clause.

This site uses Just the Docs, a documentation theme for Jekyll.