Spec 50 — Consolidated roadmap & work-package graph (WP-RM-*)

Date: 2026-09-27 · Status: Gate-B draft · Binding decisions: **D11** (t3code migration + functionality coverage first; testing infrastructure and packaging follow), **D21** (rename phase-1 packages+binaries precede migration WPs that land renamed units), constrained by D4 (spec only), D10 (one break train), D13 (mobile deferred), D16 (Gate B verifies against 00-intent.md verbatim) — docs/specs/platform-gaps/00-intent.md:19-46.

Inputs consumed in full: 10-t3code-migration.md (WP-T3-01…33), 15-private-isolation-rename.md (WP-RN-01…13), 20-functionality-coverage.md (WP-FN-01…24), 30-testing.md (WP-TEST-01…09), 40-packaging.md (WP-PKG-01…14) — **93 sibling work packages, referenced here, never redefined**; the Gate-A proposal research/synthesis-adoption-proposal.md (§4 planned inventories, §4.5 roadmap WPs R-01…03, §5 risks 1–6).

**ID conventions.** Short forms used across the spec set map one-to-one: T-nn ≡ WP-T3-nn, F-nn ≡ WP-FN-nn, Q-nn ≡ WP-TEST-nn, P-nn ≡ WP-PKG-nn, and R-nn ≡ **WP-RM-nn** (this spec's own three packages, §7 — matching the proposal's §4.5 inventory of 3). Sibling references to "R-01"/"R-03" (spec 10 §8, spec 20 §3.3/§6, spec 30 §7, spec 15 §7, spec 40 §8) resolve to WP-RM-01/WP-RM-03 below.

Program total: **93 sibling WPs + 3 roadmap WPs = 96.** Count deltas vs the Gate-A planned 81: spec 20 carries 24 (+1, WP-FN-24, justified at 20-functionality-coverage.md §3.2); spec 40 carries 14 (+1, WP-PKG-14, justified at 40-packaging.md §1.5 delta item 4 and §7 — the relay production rollout, previously owner-less, now has a work package); specs 10/15/30 match their planned counts (33/13/9; spec 15's 13 were added whole by amendment 2026-09-27b and are not a delta).

---

1. Full work-package index

Every work package in the program, exactly once. Columns: ID · title (abbreviated — the owning spec's §"Work packages" section is normative) · spec · size · roadmap phase (§5). Staged WPs carry a phase range; their stage split is stated in §5.

1.1 Spec 15 — private isolation & rename (13)

1.2 Spec 10 — t3code migration (33)

1.3 Spec 20 — functionality coverage (24)

1.4 Spec 30 — testing (9)

1.5 Spec 40 — packaging (14)

1.6 This spec — roadmap (3)

---

2. Dependency graph

Intra-spec edges are normative in each sibling's own "Dependencies" fields and are not restated. **Every cross-spec edge** in the program is listed here (X depends on Y). Where a sibling stated a soft/coordination edge, it is marked.

2.1 Migration → rename (the D21 spine)

• WP-T3-01 → WP-RN-03, WP-RN-04, WP-RN-08 (spec 15 interaction rule 2; WP-RN-08 explicitly "blocks T-01"). WP-RN-01/02 precede transitively.
• WP-T3-32 (stage 1) → WP-RN-03, WP-RN-04.
• Every WP-T3-02…33 → WP-RN-0x transitively via WP-T3-01 (spec 10 §8).
• No WP-T3-* depends on WP-RN-09…12 (spec 15 interaction rule 3 — later rename phases never block migration).

2.2 Coverage → migration

• WP-FN-10 → WP-T3-14; WP-T3-33 (soft — usage-ingestion data source, static-pricing fallback specified); WP-FN-14.
• WP-FN-11 → WP-T3-02, WP-T3-20 (campaign controller targets the post-migration dispatch path).
• WP-FN-14 → WP-T3-05 (capability flags), WP-T3-23 (checkpoint/approval boundary).
• WP-FN-16 → WP-T3-24, WP-T3-28, WP-T3-29, WP-T3-30, WP-T3-31.
• WP-FN-17 → WP-T3-02, WP-T3-21.
• WP-FN-18 → WP-T3-06…13, WP-T3-15.
• WP-FN-19 → coordination with WP-T3-14 (delta events ride the projection).
• WP-FN-20 → WP-T3-13 (codec disposition order), WP-T3-33 (shared literal guard).
• WP-FN-03 → coordination with WP-T3-17/WP-T3-23 (flipped posture governs the mapped approval surface — spec 20 §5.2).
• Ordering rule (spec 20 §5.1, binding): **WP-FN-01/02 land before or together with WP-T3-16's enforcement suite** so sovereignty tests assert the hardened journal format.

2.3 Coverage → testing / packaging

• WP-FN-09 → WP-TEST-01 (kip suite CI-gated precedes GA); WP-FN-12 → WP-TEST-01.
• WP-FN-18 ↔ WP-TEST-03 (mutual by declared division of labor — resolved by staging, §3 note 2).
• WP-FN-17 → WP-TEST-05.
• WP-FN-02, WP-FN-03 → WP-PKG-04/05 (default run/attestation key provisioning at install — carried directly by WP-PKG-04 AC8 + WP-PKG-05 AC7; §3 note 4, resolved).
• WP-FN-16 (FR-7 runbook-execution leg) → WP-PKG-14 stage 1 (the staging relay deployment FR-7's runbook executes against is pipeline-produced, not hand-rolled — WP-PKG-14 AC2).

2.4 Testing → migration / rename / coverage / packaging

• WP-TEST-03 (full D7(a) exit) → WP-T3-07, 08, 09, 10, 11, 12; WP-FN-18; WP-RN-03/07 (AR retarget of live-stack-published.yml). Stage 1 has no dependencies.
• WP-TEST-04 → WP-RN-03/05/07 + WP-PKG-01 (**AR-resolving product-live lane and release-train Form C only** — the PR-gating product-mock lane installs PR-packed workspace tarballs / a seeded loopback local registry (spec 30 §4.1.1, WP-TEST-04 AC1–2) and needs no registry or rename train); WP-T3-03 **or** WP-TEST-02 (deterministic driver — declared OR-dependency); WP-TEST-05 (**staged edge** — the Phase-2 deterministic lane consumes only the observer-dashboard Playwright assertion subset, whose config exists at HEAD (packages/observer-dashboard/playwright.config.ts); full WP-TEST-05 gating — commander, kradle-web smoke, parity handoff — joins at Phase 4); WP-PKG-03/04 (Form A stage); WP-PKG-09/10 (cluster stage); WP-T3-16 (journal sovereignty leg).
• WP-TEST-05 → WP-TEST-01; handoff leg → WP-T3-25, WP-T3-27.
• WP-TEST-07 → WP-T3-03 (mock agent), WP-T3-19 (environment receipts leg only), WP-RN-07 (smoke wiring); sdk receipts/drain legs dependency-free.
• WP-TEST-08 → WP-FN-01, WP-FN-02, WP-FN-04 (hard).
• WP-TEST-09 → WP-T3-14 (leg a), WP-T3-21 (leg b), WP-T3-24 (leg c), WP-TEST-01.
• WP-TEST-01 → coordination with WP-RN-05 (name sweep keeps suites gating).

2.5 Packaging → rename / migration

• WP-PKG-01 → WP-RN-05, WP-RN-06, WP-RN-07 (**same 7.0.0 train** — spec 15 §5 rule 6); its output is consumed by WP-T3-05's consumers (defined publics precede lane landings).
• WP-PKG-02 → WP-RN-07. WP-PKG-11 → WP-RN-07. WP-PKG-13 → WP-RN-03, WP-RN-04.
• WP-PKG-03 → WP-T3-19, WP-T3-25, WP-T3-32 (stage 2), WP-PKG-13, WP-RN-07; desktop leg → WP-T3-26. Unblocks WP-T3-28's bootstrap-download activation (the one migration→packaging edge: **WP-T3-28 (bootstrap leg) → WP-PKG-03**).
• WP-PKG-04 → WP-PKG-03, WP-PKG-11. WP-PKG-05 → WP-PKG-03/04, WP-T3-19. WP-PKG-06 → WP-PKG-03/05, WP-T3-19, WP-T3-26. WP-PKG-08 → WP-PKG-04/05/06.
• WP-PKG-07 → WP-PKG-03, WP-RN-03/04/07, plus the Gate-B platform-package name amendment (§3 note 8).
• WP-PKG-09 → WP-RN-07, WP-RN-12 (**same train** — one chart-consumer break), WP-PKG-13, WP-PKG-11. WP-PKG-10 → WP-PKG-09, WP-RN-05.
• WP-PKG-12 → WP-T3-01 (license machinery exists); touches WP-PKG-03…09 outputs as they land.
• WP-PKG-14 → WP-T3-31 (relay code + documented ops story), WP-PKG-13 (guard-job framework + PG discipline), WP-PKG-11 (channel vocabulary + exact-commit promotion). **Staged** (§3 note 5): stage 1 (workflow-dispatch staging deploy pipeline with provenance metadata + gated migrations — ACs 2–3) needs only WP-T3-31's sources and co-lands with it in Phase 4; stage 2 (channel promotion, rollback drill, PG1 extension, credential posture, fifth-class endpoint consistency, production rollout — ACs 1, 4–7) follows WP-PKG-11/13 in Phase 7, matching spec 40 §8's sequencing input. Consumed by WP-FN-16 (FR-7 acceptance runs against its staging/prod deployments).

2.6 Roadmap edges

• WP-RM-02 → WP-RM-01, WP-RN-07 (tag scheme exists to map). WP-RM-03 → WP-RM-01.

---

3. Consistency notes — dangling and circular references found in the siblings, with resolutions

Nothing below is silently ignored; each finding carries the roadmap's resolution and, where needed, a Gate-B flag (recorded by WP-RM-03).

1. **WP-FN-05 ↔ WP-FN-07 circular dependency.** Spec 20 lists WP-FN-07 as a dependency of WP-FN-05 ("shared precedence semantics") and WP-FN-05 as a dependency of WP-FN-07 ("shared cancellation path"). *Resolution:* treated as one **co-scheduled pair** — the cancel-vs-complete precedence contract is defined once and both WPs implement against it; they land in the same Phase-2 train (ideally one PR series), and WP-RM-01's cycle detector allowlists exactly this pair. 2. **WP-FN-18 ↔ WP-TEST-03 mutual reference.** WP-TEST-03 depends on F-18 for red-lane remediation; WP-FN-18 depends on Q-03 for matrix infrastructure. Both specs declare the division (infrastructure/gating vs functional outcome). *Resolution:* staged — WP-TEST-03 **stage 1** (OS axis, harness-matrix.yml, auth, flake policy) has no FN dependency and lands Phase 1; WP-FN-18 consumes stage 1 plus the Phase-3 lanes; WP-TEST-03's **completion gate** (six green, quarantine-free) consumes WP-FN-18. No true cycle once staged. 3. **WP-PKG-03 → WP-T3-26 → WP-T3-28 → WP-PKG-03 apparent triangle.** Spec 40 makes desktop artifacts a WP-PKG-03 acceptance item needing WP-T3-26; WP-T3-26's ssh flow needs WP-T3-28; WP-T3-28's bootstrap download activates only after WP-PKG-03. *Resolution:* not a hard cycle — WP-T3-28's core (port-forward/exec/tunnel facade) lands in Phase 2 with bootstrap explicitly capability-gated (spec 10 WP-T3-28 AC5 already stages this); WP-T3-26 consumes the core; WP-PKG-03 then ships archives + desktop artifacts; WP-T3-28's bootstrap leg activates last. The stage order is binding: T3-28(core) → T3-26 → PKG-03 → T3-28(bootstrap activation). 4. **Obligation "spec 40 P-04 provisions a default run key" — RESOLVED in spec 40's final text.** WP-FN-02 AC4 and WP-FN-03's dependency list assign run-key/attestation-key provisioning at install to P-04; spec 40 now carries the acceptance criteria directly: **WP-PKG-04 AC8** (first-boot key generation into $FABRIC_HOME/keys/) plus **WP-PKG-05 AC7** (service start refuses to run key-less by default, with the explicit opt-out preserving the WP-FN-02 AC3 / WP-FN-03 AC1 loud markers) — 40-packaging.md §7/§8. No Gate-B amendment is needed; WP-RM-03's register records the note as accepted-resolved. The scheduling consequence stands: both ACs land in the Phase-6 Form-1 train, and the default-covered posture (WP-FN-03) is not GA until they do. 5. **Relay production rollout — OWNED by WP-PKG-14.** WP-FN-16 FR-7 says relay packaging/rollout "is carried by specs 40/50", and WP-T3-31 documents the ops story "for spec 40/50 consumption"; spec 40 minted **WP-PKG-14** (relay artifact class & production rollout — 40-packaging.md §7) to own it: train-versioned Worker+Postgres+cloudflared deploy pipeline in fabric's private CI, §5-discipline channel promotion with exact-commit staging→prod, executed deploy/rollback runbook procedures, and PG1-extension guard coverage. *Roadmap placement (staged, mirroring notes 2/3):* **stage 1** — the workflow-dispatch staging deploy pipeline with deploy-provenance metadata and gated migrations (WP-PKG-14 AC2–3) — co-lands with WP-T3-31 in Phase 4, so the staging deployment that WP-T3-31 AC1's broker e2e and WP-FN-16 AC7's runbook execution (Phase 5) run against is pipeline-produced, never hand-rolled; **stage 2** — channel promotion, rollback fault-injection drill, PG1 extension + credential posture, relay endpoints as the fifth channel-consistency class, and the production rollout itself (ACs 1, 4–7) — lands in Phase 7 after WP-PKG-11/13, per spec 40 §8's sequencing input. The WP-T3-31/WP-PKG-14-stage-1 co-landing joins WP-RM-01 AC3's cycle allowlist; WP-RM-02's train map carries the relay artifact class with its Phase-7 rollout train. Nothing about this remains open for Gate B beyond the ordinary disposition record. 6. **WP-T3-29 AC4 forward-references WP-T3-30.** The tailscale pairing-equivalence test needs environment auth that lands two phases later. *Resolution:* staged acceptance (spec 10 already notes "equivalence test needs WP-T3-30") — WP-T3-29 closes in Phase 2 with AC4 deferred-and-tracked, discharged in Phase 4 when WP-T3-30 lands. WP-RM-01's index carries the open acceptance item so it cannot be forgotten. 7. **WP-TEST-04's OR-dependency.** "WP-T3-03 (ACP mock agent) or WP-TEST-02 (mock harness)" — legitimate alternative drivers. *Resolution:* the roadmap schedules the deterministic product-mock lane as soon as **either** lands (WP-TEST-02, Phase 1, arrives first), re-pointing to the ACP mock agent when WP-T3-03 lands (Phase 2). The lane installs PR-packed workspace tarballs / a seeded loopback local registry (spec 30 §4.1.1, WP-TEST-04 AC1–2), so its activation waits on no registry and no rename train; AR resolution is proven by the nightly product-live lane and release-train Form C only (WP-TEST-04 AC3). Recorded so the graph tooling does not treat the OR as an AND. 8. **Gate-B-pending names gate two WPs.** WP-PKG-07 must not start before the @fabricstack/environment-<platformKey> matrix amendment is locked; the optional fabric launcher alias (spec 40 §3.6) is proposed but every WP is written to work without it; spec 15 §3.2's retired-shell contingency (console-web-legacy names if WP-T3-27 slips past RN-3) is a conditional amendment. *Resolution:* all three ride the Gate-B name lock; WP-RM-03 tracks them; the Phase-6 plan sequences WP-PKG-07 after the lock. 9. **Planned-inventory scope deltas (proposal §4 vs delivered specs).** (a) F count 23→24 (WP-FN-24 addition, justified spec 20 §3.2); (b) P-01's bin-collision half moved to WP-RN-06/G5; (c) P-02 reversed the proposal's "per-package semver atop lockstep" into lockstep-kept + changesets-removed (decision documented spec 40 §2.2); (d) P-08's public OS package managers dropped as D19-contradicting (spec 40 §1.5); (e) P-11's "nightly train" dropped (spec 40 §5); (f) P-13 narrowed (npm home already settled by spec 15 §4.2); (g) spec 10 resolved oh-my-pi/omp as one harness and enlarged T-13's disposition table to 22 codecs (+qwen); (h) P count 13→14 — **WP-PKG-14** minted (spec 40 §1.5 delta item 4) to own the relay production rollout, previously carried only in prose (note 5); (i) scope delta **SD-PKG-1** (spec 40 §1.6, D3 narrowing: no Windows background service in v1 — desktop app or foreground instead), written by spec 40 for direct citation in WP-RM-03's Gate-B register. *Resolution:* all are documented decisions, not drift; WP-RM-03's matrix records each against its decision source so Gate B approves them explicitly. 10. **Residual triage routed to this spec.** Spec 20 §3.3 routes three docs/harness-features-backlog/gaps/ categories (performance, profile-orchestration, user-experience) to "R-01 triage", and WP-FN-21 hands its ops-capacity prerequisite (GKE/AKS node headroom) to "roadmap R-01". *Resolution:* both are owned by WP-RM-01 (§7): the three categories get a disposition table (routed to an owning WP, deferred-with-reason, or descoped); the capacity item is a named Phase-5 entry criterion (§5, Phase 5 prerequisites). 11. **Dependency-direction wording in WP-PKG-01** ("blocks the public-surface claims of WP-T3-05 consumers"). Not a cycle: WP-PKG-01 rides the Phase-1 RN-1 train, which precedes all migration landings, so publics exist before any lane ships. Recorded to prevent a graph tool reading it as PKG→T3 ordering.

No other dangling or circular references were found: every WP ID cited by any sibling (T-01…33, RN-01…13, F-01…24, Q-01…09, P-01…14, R-01…03) resolves to an existing package, and the 40-ID survivor register is fully absorbed (37 in WP-FN-*, TEST1→WP-TEST-01, TEST2→WP-TEST-08, HYG2→WP-PKG-01/02 — spec 20 §2).

---

4. Sequencing rules — D11 ∩ D21, with justified exceptions

**D11 baseline:** (1) t3code migration and (2) functionality coverage sequence first; testing infrastructure and packaging follow.

**D21 intersection:** WP-RN-01…04 + WP-RN-08 (RN-0) and WP-RN-05/06/07 (RN-1, packages + binaries) precede WP-T3-01 and therefore every migration WP, because migrated units land directly under @fabricstack/* names (spec 15 interaction rules 1–2). Later rename phases (RN-2…RN-5) never block migration (rule 3) and are deliberately deferred to Phases 6–7 so each sweep runs once, over a tree that already contains the migrated units.

**Justified exceptions to D11's "follow" clause** (each is a binding sibling rule or a safety net the migration itself depends on):

• **E1 — packaging pulled into Phase 1:** WP-PKG-01 (exports maps) and WP-PKG-02 (versioning) ride the RN-1 train by binding rule (spec 15 §5 rule 6: publics defined once, under new names, in the single D10 7.0.0 break train). Deferring them would force a second break train, violating D10's one-break posture.
• **E2 — testing debt pulled into Phase 1:** WP-TEST-06/01/02 and WP-TEST-03 stage 1 are declared migration-independent by spec 30 §7 and are the safety net for everything the migration re-platforms — the suites being wired are the only regression guard for consumers the projection/parity bars later assert. Minimal CI wiring early is cheaper than migrating against ungated code. WP-TEST-09's fixture groundwork likewise starts with its first anchor (WP-T3-14, Phase 2) so parity gates exist the moment they can gate.
• **E3 — correctness cluster in parallel from day one:** WP-FN-01…08 live entirely in B4 plain-TS zones with zero WP-T3 dependencies (spec 20 §6) and are scheduled Phases 1–2, satisfying the §5.1 ordering rule (WP-FN-01/02 before WP-T3-16, which is Phase 3). Waiting for the migration to finish before fixing journal integrity would mean building five new lanes on an unverifiable ledger.
• **E4 — fabric-only coverage items early:** WP-FN-13, WP-FN-15, WP-FN-22/23/24 have no migration dependencies and small blast radius; WP-FN-15 is explicitly GA-blocking for WP-FN-09 and is cheapest before kip becomes the platform memory.
• **E5 — packaging-substrate ordering inside Phase 6:** WP-PKG-13 is the declared first mover of spec 40 (WP-PKG-03/07/09/14 depend on it); WP-PKG-11's channel vocabulary precedes the installers that resolve by channel (WP-PKG-04 dependency).

**Gate-B ratification of E1/E2 (decision fidelity).** E1 and E2 pull packaging and testing items into Phase 1, ahead of D11's "testing infrastructure and packaging follow" clause. The justifications above are the roadmap's *case*, not the *decision*: both exceptions are entered in WP-RM-03's open-items register as explicit **Gate-B ratification items**, and the Gate-B session must ratify E1 and E2 alongside the name-matrix lock (D18) before the Phase-1 plan is treated as D11-compliant — the D11 stretch is proposed here, never presumed settled. E3/E4 stretch nothing (functionality coverage is itself a D11 top-2 priority) and need no ratification.

**Standing invariants over the whole graph:** no WP touches the public a5c-ai/babysitter repo (D17, intent criterion 7); all publication targets Artifact Registry (D19, guards G1–G6/PG1–PG5); bulk upstream intake, if wanted, is scheduled before WP-RN-10 executes (spec 15 rule 5); mobile is out of every phase (D13).

---

5. Phases, milestones, and exit criteria

Eight phases, M0–M7. A phase exits when every listed criterion is demonstrably true (each maps to named acceptance criteria in the owning spec — the phase gate is an audit of those ACs, not a re-test). Phases overlap where §4's tracks allow; the WP lists below are primary assignments from §1.

Phase 0 — Hard split, registry, guards (RN-0)

**WPs:** WP-RN-01, WP-RN-02, WP-RN-03, WP-RN-04, WP-RN-08; WP-T3-32 stage 1. **Wall-clock note (M0 gate record vs. Phase-1 start):** The ≥7-day passive propagation watch embedded in exit 1 (WP-RN-01 AC1(b)) runs concurrently with Phase-1 work — Phase-1 execution keys on WP-level dependencies (WP-RN-05+ depend on WP-RN-03/04, never on the watch), so the 7.0.0 rename train may start the moment WP-RN-03/04 land; only the formal M0 gate record waits for the observation window to close, so the watch places its multi-week wall-clock floor on closing Phase 0's record, not on beginning Phase 1. **Exit criteria (M0):** 1. The hard split is proven strictly read-only (WP-RN-01 AC1 — no branch, tag, or commit is ever created on the public repo): the hosting-level mirror transport is confirmed disabled with settings/API evidence captured, and the passive propagation watch (≥7 days containing at least one post-cutover upstream commit) shows no upstream commit entering any fabric ref outside labeled upstream-intake PRs; publish.yml no longer self-describes as a mirror (WP-RN-01 AC2/AC4). 2. npm ping against https://us-central1-npm.pkg.dev/boot-464019/fabric-npm/ succeeds from CI via WIF; the @fabricstack/smoke publish+install rehearsal passes from the written doc alone (WP-RN-03 AC1–2). 3. Guards G1–G6 each demonstrated red-until-green on their negative fixtures; repo secret audit shows no npmjs credential (WP-RN-04). 4. The no-double-rename gate trips on a fixture @t3code/x manifest (WP-RN-08 AC2). 5. npm ls effect resolves a single effect@4.0.0-rc.115 workspace-wide and the patch-regression test passes (WP-T3-32 AC1–2).

Phase 1 — Rename train 7.0.0 + CI safety net (RN-1 + parallel tracks)

**WPs:** WP-RN-05, WP-RN-06, WP-RN-07, WP-PKG-01, WP-PKG-02 (one train); WP-TEST-06, WP-TEST-01, WP-TEST-02, WP-TEST-03 stage 1; WP-FN-01, WP-FN-06, WP-FN-08, WP-FN-22, WP-FN-23, WP-FN-24; WP-RN-13 begins; WP-RM-01, WP-RM-02, WP-RM-03 (initial versions). **Exit criteria (M1):** 1. One staging train tagged fabric/staging/v7.0.1-staging.<sha> publishes all 43 @fabricstack/* packages to AR at that exact version in dependency waves, the staging dist-tag moves to it, and the public repo's tag namespace gains nothing (WP-RN-07 AC1/4; WP-PKG-01 AC4). *Amended 2026-10-04 (WP-RN-07 review M4, owner decision "Spec 15 wins"): the earlier literal fabric/staging/v7.0.0 is rejected by the resolver — spec 15 §4.1 keeps the commit-pinned prerelease scheme on staging, so the staging evidence is the 7.0.1-staging.<sha> tag above; the exact 7.0.0 is published by the later main train and evidenced by fabric/main/v7.0.0 (channel latest, WP-PKG-11 AC1 promotion).* 2. Exports exactness holds: at least one non-exported deep-import probe fails per package in the verifier matrix; the bin-key union is duplicate-free and --version smokes pass (WP-PKG-01 AC1; WP-RN-06 AC1–3). 3. verify-manifests fails on a wildcard internal dep fixture; .changeset/ is gone (WP-PKG-02 AC1–2). 4. Floors registry active with all five negative-fixture gates proven; zero workspaces with tests are workflow-unreachable; regenerated MATURITY-MATRIX.md diffs empty in CI (WP-TEST-06 AC1/4; WP-TEST-01 AC1). 5. A dispatched harness-matrix.yml run executes lanes on ubuntu, macos, and windows in one run; Claude Code and Codex Tier-1 lanes green on all three OSes under native auth with the credential canary passing (WP-TEST-03 AC1–2); individual not-yet-green OS cells satisfy this only as unexpired fixture-blocked declarations per spec 30 §3.3 (WP-TEST-03 AC2). 6. Journal v2 lands: checksum-on-load, hash chain, canonical JSON, with the tamper suite green (WP-FN-01); requiredRootKind in the trust-core verifier with the kind/expiry/revocation matrix (WP-FN-08); session lifecycle residuals closed (WP-FN-06).

Phase 2 — Fork intake + protocol substrate (migration wave 1) + correctness completion

**WPs:** WP-T3-01, WP-T3-02, WP-T3-03, WP-T3-04, WP-T3-05, WP-T3-14, WP-T3-28, WP-T3-29, WP-T3-32 stage 2; WP-FN-02, WP-FN-03, WP-FN-04, WP-FN-05, WP-FN-07 (co-scheduled with WP-FN-05), WP-FN-13, WP-FN-15; WP-TEST-04 deterministic product-mock lane activates (PR-packed tarball install — §3 note 7); WP-TEST-09 groundwork (fixture store + the AC6 legacy-codec baseline corpus). **Exit criteria (M2):** 1. The pristine snapshot branch exists with upstream SHA + MIT license; license-sync fails on a missing-entry fixture; WP-RN-08's gate passes un-waived on the first landed fork (WP-T3-01 AC1–3; WP-RN-08 AC3). 2. Contracts/acp/codex-protocol build with plain tsc, effect as sole runtime dep; both regeneration pipelines reproduce _generated/* byte-identically; the ACP mock agent completes its cycle in CI (WP-T3-02 AC1; WP-T3-03 AC2–3; WP-T3-04 AC2). 3. The WP-T3-05 contract has zero effect imports (architecture-gate rule live) and the fake-lane run/steer/cancel/permission suite passes (WP-T3-05 AC1, tests). 4. Projection goldens green with all four consumer families compiling and passing unmodified; no producer writes AgentEvent outside the normalizer (WP-T3-14 AC1–3). 5. ssh sshd-container integration suite and tailscale secret-scrub fixtures green; T3-29 AC4 recorded as deferred-to-Phase-4 (§3 note 6). 6. Correctness cluster complete: signed journal round-trip with forged-envelope rejection (WP-FN-02); the 8-combination posture matrix + fail-closed dispatch (WP-FN-03, GA pending §3 note 4); replay value-drift detection with golden no-drift corpus (WP-FN-04); orphan-sweep cancellation e2e + SIGTERM-immune-child regression (WP-FN-05); race-order matrix + stray-rejection isolation (WP-FN-07); KIP markers gone (WP-FN-15); scale-to-zero queue-not-drop e2e on GKE staging (WP-FN-13). 7. Console-web production build succeeds on stock Vite with no @voidzero-dev/* in the graph — proven on the imported tree ahead of Phase-4 app landings (WP-T3-32 AC4). 8. The legacy-codec baseline corpus is captured at a pinned pre-lane commit (SHA committed in the corpus manifest), covering every retain-behind-contract codec of WP-T3-13's disposition table — native transcript + legacy-path projected golden per codec, the "before" side of WP-T3-13 AC2, in place **before any Phase-3 codec retirement or migration merge** (WP-TEST-09 AC6).

Phase 3 — Lanes + environment server (migration wave 2)

**WPs:** WP-T3-06, WP-T3-07, WP-T3-08, WP-T3-09, WP-T3-10, WP-T3-11, WP-T3-12, WP-T3-13, WP-T3-15, WP-T3-16, WP-T3-17, WP-T3-18, WP-T3-19, WP-T3-33; WP-TEST-07, WP-TEST-09 leg (a). **Phase entry rule:** WP-FN-01/02 merged (spec 20 §5.1) before WP-T3-16's suite freezes; the WP-TEST-09 AC6 legacy-codec corpus captured (M2 exit 8) before any lane WP retires or migrates a codec. **Exit criteria (M3):** 1. All five drive lanes + observe rebind landed; live-stack push-default lanes (claude-code, codex, pi, antigravity, genty) green post-migration (WP-T3-13 AC4; WP-T3-15 AC3). 2. The 22-codec disposition table is an in-code checked fixture; base-adapter.ts deleted; zero BaseAgentAdapterInterface imports repo-wide (WP-T3-13 AC1/3). 3. environment-server completes dispatchCommand → decider → projector → subscribeThread and replays its event log on restart; checkpoints never touch the user's branch (WP-T3-19 AC1–3). 4. Journal sovereignty mechanical: per-lane journal e2e replays, and deleting the environment SQLite DB loses no run identity (WP-T3-16 AC1–2). 5. Trust gating: forged decisions rejected; no lane resolves a permission callback without the policy bridge (WP-T3-17 AC1/3). 6. grok exists in the agent map and its lane runs with the standard artifact set (WP-T3-08 AC1); Antigravity installer verifies identity + leases versions (WP-T3-09 AC1). 7. Provider maintenance: ownership-proof updates, usage ingestion feeding cost summaries, atlas-fed manifest with zero new hardcoded literals (WP-T3-33 AC1–5). 8. The mock agent replays a committed transcript byte-stably across two CI runs and drives ≥5 formerly sleep-based sdk tests via receipts (WP-TEST-07 AC1/3).

Phase 4 — Control plane, clients, remote (migration wave 3)

**WPs:** WP-T3-20, WP-T3-21, WP-T3-22, WP-T3-23, WP-T3-24, WP-T3-25, WP-T3-26, WP-T3-27, WP-T3-30, WP-T3-31; WP-PKG-14 stage 1 (staging relay deploy pipeline, co-lands with WP-T3-31 — §3 note 5); WP-TEST-05, WP-TEST-09 legs (b)/(c); WP-FN-18. **Exit criteria (M4):** 1. protocol/v1.ts deleted; every §4.5 frame row proven by the equivalence suite; kanban + webhooks live behind typed routes (WP-T3-21 AC1–4). 2. The 81-route disposition ledger is complete and CI-diffed; every surviving route rejects malformed payloads with typed 4xx (WP-T3-22 AC1–2). 3. A tool-permission request round-trips lane → pending approval → AgentApproval(tool-use) → signed decision → resolution on the deployed stack; all 7 actions typed (WP-T3-23 AC1–2). 4. genty-ui's 18 test files pass against the parity layer with import-path-only changes; the reconnect chaos test passes through one supervisor (WP-T3-24 AC1–2). 5. Console-web meets the Playwright parity bar; shells deleted; RETIREMENT-LIST.md matches deletions exactly; the browser-e2e handoff is gap-free in one PR diff (WP-T3-25 AC1; WP-T3-27 AC1/5; WP-TEST-05 AC4). 6. Desktop app drives a full local run via its bundled environment server with no orphan processes (WP-T3-26 AC1). 7. DPoP pairing e2e: one-time, TTL'd, scoped grants; scope×method matrix enforced; zero bearer-token auth in the serving path (WP-T3-30 AC1–4). 8. Relay broker e2e on staging proves broker-not-proxy, org isolation, trust-core envelopes, loopback-only tunnels (WP-T3-31 AC1–6) — run against a staging relay deployed by the WP-PKG-14 stage-1 pipeline, with deploy-provenance metadata (train tag + commit) on the staging Worker and Postgres migrations as an explicit, logged pipeline step (WP-PKG-14 AC2–3). 9. WP-FN-18 closed: six D7(a) lanes green on three consecutive scheduled runs; #562/#945 closed with root-cause notes; MATURITY-MATRIX.md agent rows refreshed.

Phase 5 — Functionality coverage completion

**WPs:** WP-FN-09, WP-FN-10, WP-FN-11, WP-FN-12, WP-FN-14, WP-FN-16, WP-FN-17, WP-FN-19, WP-FN-20, WP-FN-21; WP-TEST-08. **Entry prerequisites:** kip suite CI-gated (WP-TEST-01, done Phase 1); WP-FN-15 done (Phase 2, GA-blocker for WP-FN-09); **ops capacity item** — GKE/AKS node headroom for the realtime e2e provisioned and verified by the WP-FN-21 pre-flight check (owned here per §3 note 10). **Exit criteria (M5):** 1. All 40 survivor-register IDs are closed and each closure PR is recorded in the WP-RM-03 matrix (spec 20 §2 absorption map). 2. Memory unification: ADR committed; one write path proven by the extract→backend→kradle-query round-trip; the CAP1 zero-consumer grep inverts (WP-FN-09 AC1–3). 3. Budget refusal-before-spend with the provider client asserted un-called; campaign preemption e2e (5 items, maxConcurrent: 2, one preemption) with journaled provenance (WP-FN-10 AC1; WP-FN-11 AC5). 4. Improvement loop runs promote+reject deterministically in CI with signed, reversible promotions (WP-FN-12 AC1–4). 5. Pause/resume/fork/rewind e2e across step boundaries; one pause mechanism serving preemption and budget callers (WP-FN-14 AC1–4). 6. FR-1…FR-7 proven: four-route e2e matrix, token-absence capture, two-org denial, local-vs-remote differential journal test, relay runbook executed on staging (WP-FN-16). 7. Disposition tables complete: 47+149 rows routed with zero unrouted; literal residual ≤ allowlist with the CI guard live (WP-FN-19 AC9; WP-FN-20 AC1–4). 8. Realtime: live room join + real video/audio publish asserted receive-side; any descoped tier recorded with reason (WP-FN-21 AC1/6). 9. Commander RealBackend live e2e (or the Gate-B descope ADR executed) (WP-FN-17 AC1–2/5). 10. Adversarial ledger suite CI-gated; every attack class proven to fail pre-fix behavior via the pinned pre-fix-commit worktree proof — the class's test run red at the first parent of its owning F-WP's merge commit and green at HEAD, with the failing evidence archived — or by citing the recorded red→green transition from the F-WP's own PR train (WP-TEST-08 AC1/3; executable at Phase 5 by construction).

Phase 6 — Testing bar (D7) + Form 1/Form 3-residual packaging

**WPs:** WP-TEST-03 completion, WP-TEST-04; WP-PKG-13, WP-PKG-11, WP-PKG-03, WP-PKG-04, WP-PKG-05, WP-PKG-06, WP-PKG-07 (post name-lock), WP-PKG-08, WP-PKG-12; WP-RN-09. **Exit criteria (M6):** 1. **D7(a) exit:** all six Tier-1 harnesses green per their OS-support declarations, quarantine-free; publish.yml blocks on a stale/red matrix (negative rehearsal recorded) (WP-TEST-03 AC5–6). 2. **D7(b) exit:** the deterministic six-stage chain green on a clean runner with zero external credentials and zero remote-registry access for @fabricstack/* — every package installed from PR-packed workspace tarballs (or the seeded loopback local registry), with the PR head SHA stamped into each packed manifest and verified post-install; the nightly live lane green on 3 OS resolving @fabricstack/* **only** from Artifact Registry (the AR-resolution proof lives in the live lane and release-train Form C, never the PR lane); product-mock a required PR check after 14 stable days (WP-TEST-04 AC1–3/6). 3. Form 1 real: clean-VM archive boot per platform (no Node/npm/compiler); tampered-archive aborts; channel rails hold; service lifecycle + problem codes per OS; self-update trial/commit/rollback with byte-identical SQLite snapshot restore; uninstall preserves user data (WP-PKG-03 AC1–2; WP-PKG-04 AC2–3; WP-PKG-05 AC1–5; WP-PKG-06 AC1–2; WP-PKG-08 AC1). 4. Form A joins WP-TEST-04 with stages 2–6 unchanged (product-not-transport proof) (WP-TEST-04 AC4). 5. npm platform packages byte-equal the archives; npx @fabricstack/environment works for authenticated consumers (WP-PKG-07 AC1–2). 6. One version string resolvable by channel across all four artifact classes; stable promotion refuses un-staged commits (WP-PKG-11 AC1–2). 7. PG1–PG5 proven with negative fixtures; the inert ghcr workflow gone; run/attestation default keys provisioned at install — first-boot generation into $FABRIC_HOME/keys/, service start refusing to run key-less by default (§3 note 4, resolved) (WP-PKG-13 AC2–5; WP-PKG-04 AC8; WP-PKG-05 AC7). 8. Env-var sweep clean: zero old-prefix hits outside historical docs and the retirement list; live-stack matrix green post-rename (WP-RN-09 AC1–2). 9. Every shipped artifact class embeds third-party notices (WP-PKG-12 AC2–4).

Phase 7 — Rename completion (RN-3…RN-5) + cluster packaging (Form 2)

**WPs:** WP-RN-10, WP-RN-11, WP-RN-12, WP-PKG-09 (same train as WP-RN-12), WP-PKG-10; WP-RN-13 completes; WP-PKG-14 stage 2 (channel promotion, rollback drill, guards, production rollout — §3 note 5). **Entry gate:** bulk-intake sign-off recorded before WP-RN-10 executes (spec 15 rule 5, WP-RN-10 AC4). **Exit criteria (M7):** 1. Tree matches the spec 15 §3 directory column; migrate-data-dir moves a populated .a5c/ fixture and replay is byte-identical from .fabric/ (WP-RN-10 AC1/3). 2. Identifier greps clean; blueprint surface is orchestrator blueprints:*; rename commits are mechanically logic-free (WP-RN-11 AC1–4). 3. Chart control-plane published at the train version to AR OCI; helm install of the **published** chart succeeds on clean minikube incl. catalog-webui; one chart-consumer break with WP-RN-12 (tag audit) (WP-PKG-09 AC1–3/7). 4. CR migration complete: kubectl get crd | grep kradle.a5c.ai empty on all environments; three GKE envs deploy + smoke green (WP-RN-12 AC1–4). 5. Operator installs chart+CRDs+Envoy from published artifacts with zero source checkout; company CD dogfoods it (publish.yml:1080 replaced) (WP-PKG-10 AC1/4). 6. WP-TEST-04's cluster profile asserts run visibility in kradle-web + observer inside the deployed-stack e2e (WP-TEST-04 AC5). 7. Docs/skills sweep done; docs/NAMING-DECISION-RECORD.md byte-matches the Gate-B-locked matrix (WP-RN-13 AC2–3). 8. WP-PKG-14 closed: the production relay deploys only a build whose exact commit staging already ran (negative promotion test recorded — AC1); the rollback drill proven in staging by fault injection with WP-T3-31's broker e2e green again post-rollback (AC4); the PG1 extension trips on the deliberately-bad relay-deploy fixture and the Cloudflare/DB credentials pass the PG5-pattern audit (AC5–6); relay endpoints resolve per channel as the fifth WP-PKG-11 AC2 consistency class (AC7); the production deployment executed per the FR-7 runbook and recorded in the WP-RM-02 train map.

Critical path narrative

The longest dependency chain runs: **WP-RN-01 → RN-03 → RN-04 → RN-08** (with WP-T3-32 stage 1 in parallel) → **RN-05/06/07 + PKG-01** (the 7.0.0 train) → **T3-01 → T3-02 → T3-05 → T3-14 → T3-06** → the ACP lanes → in parallel **T3-19 → T3-20 → T3-21 → T3-24 → T3-25 → T3-26** (the client chain is the migration's long pole: five consecutive L-sized hard forks) → **PKG-13 → PKG-03 → PKG-04 → PKG-05 → PKG-06** (Form 1) → **WP-TEST-04 Form A** → and finally the Phase-7 pair **RN-12 + PKG-09 → PKG-10**. Slack exists everywhere except that spine: the environment/client chain (T3-19→…→T3-26) and the Form-1 chain (PKG-03→…→06) are strictly serial, so the roadmap's elapsed time is dominated by Phases 3–4 and 6. Anything that shortens T3-19 or parallelizes T3-25/T3-26 (both only need T3-24/T3-19 respectively, and can overlap once console-web's build is proven under WP-T3-32 stage 2) buys calendar time.

Parallelization opportunities

• **Track A (correctness):** WP-FN-01…08 + FN-13/15/22/23/24 run beside Phases 1–2 with zero migration coupling.
• **Track B (test debt):** WP-TEST-06/01/02 + TEST-03 stage 1 beside Phase 1; WP-TEST-09 fixtures beside Phase 2.
• **Tracked forks fan out:** T3-02/03/04 and T3-28/29 are mutually independent after T3-01; five parallel work streams.
• **Lane fan-out:** T3-07…12 are mutually independent behind T3-06/T3-14/T3-17; the environment chain (T3-19→20) runs beside the lane fan-out — they meet only at T3-16/T3-23.
• **Fabric-only coverage:** FN-13 (kradle), FN-21 (realtime), FN-19 (genty-core) touch planes the migration does not, and can start whenever capacity exists (FN-19/21 primary-scheduled Phase 5 for review bandwidth, not for dependencies).
• **Rename sweeps:** RN-09/RN-13 proceed whenever the tree is quiet; only RN-10's bulk-intake gate and RN-12's chart-train pairing are order-sensitive.

---

6. Risks → mitigating phases (synthesis §5 carried forward, plus program-created risks)

---

7. Work packages

WP-RM-01: Roadmap graph & index maintenance + residual triage

• **Objective**: Keep this spec's §1 index and §2 dependency graph authoritative for the life of the program — the "merged cross-spec graph" that specs 10 §8, 20 §6, and 30 §7 delegate to R-01 — as a machine-checkable artifact, not prose; and discharge the two obligations routed to R-01 by the siblings: the triage of the three docs/harness-features-backlog/gaps/ categories spec 20 §3.3 routes here (performance, profile-orchestration, user-experience), and the sequencing of WP-FN-21's ops-capacity prerequisite (20-functionality-coverage.md WP-FN-21 dependencies).
• **Affected paths**: docs/specs/platform-gaps/50-roadmap-workpackages.md (this file — status annotations per phase gate); new docs/specs/platform-gaps/roadmap/index.json (one record per WP: id, spec, size, phase, status, dependency edges incl. the §3 staged/OR/pair annotations, open deferred-acceptance items such as WP-T3-29 AC4); new scripts/check-roadmap-index.cjs wired into the fabric docs-quality CI job (.github/workflows/ci.yml, docs-quality job — R1 §4.1 job map); new docs/specs/platform-gaps/roadmap/residual-triage.md (the three-category disposition table + the ops-capacity item's owner and verification command).
• **Acceptance criteria**: (1) index.json contains exactly 96 WP records (33+13+24+9+14+3), each ID appearing once, and the checker fails on a duplicated or missing ID (negative fixture proves it); (2) every dependency edge in index.json names an existing WP ID — the checker fails on a dangling edge (negative fixture); (3) cycle detection passes with an explicit allowlist containing only the §3-documented pairs (WP-FN-05/07 co-schedule; WP-FN-18/WP-TEST-03 stage split; the T3-26/T3-28/PKG-03 stage triangle; the WP-T3-31/WP-PKG-14-stage-1 co-landing) — an undocumented cycle fails CI; (4) the residual-triage table routes all files of the three named backlog categories to {owning WP | deferred-with-reason | descoped-with-reason} with zero unrouted rows (script-verified row count against the category file listings); (5) the ops-capacity prerequisite carries a named owner and a runnable pre-flight verification (the WP-FN-21 AC5 check) and is recorded as a Phase-5 entry criterion; (6) at each phase gate M0–M7, every WP listed in that phase has status done with its closing PR linked, or the gate record documents the carry-over — the checker validates status-vs-phase consistency.
• **Test requirements**: negative-fixture suite for the checker (duplicate ID, dangling edge, undocumented cycle, unrouted triage row, status/phase mismatch); checker idempotence on the committed index; docs-quality gate green on all three new documents.
• **Dependencies**: none upstream (first roadmap mover; consumes the five sibling specs read-only). Consumed by WP-RM-02 and WP-RM-03.
• **Size**: M

WP-RM-02: Milestone/release-train mapping + tracked-fork upstream-review cadence

• **Objective**: Bind the §5 phases to concrete release trains (the proposal's R-02): the D10 major-bump cutover is fixed as the single 7.0.0 train carrying WP-RN-05/06/07 + WP-PKG-01/02 (spec 15 §5 rule 6; spec 40 §2.2), each phase exit maps to a tagged train under fabric/<branch>/v<version> (spec 15 §4.2), and the two standing cadences the siblings define but nobody schedules are given owners and dates: the quarterly tracked-fork upstream-diff review for the five UPSTREAM.json-pinned units (spec 10 §2.2) and the opportunistic public-fix intake review (spec 15 §1.4), including the bulk-intake-before-RN-10 checkpoint (spec 15 rule 5) and the rc→stable Effect transition watch item (WP-T3-32 AC6). The train map also carries the relay artifact class (owned by WP-PKG-14 — §3 note 5) so the Phase-7 production rollout has a named train.
• **Affected paths**: new docs/specs/platform-gaps/roadmap/train-map.md (phase→train→tag table; cutover record; cadence register with owner + next-due date per item); UPSTREAM.json files of the five tracked forks (review-cadence fields populated — coordinated with WP-T3-01, which creates them); new scripts/check-upstream-cadence.cjs (asserts every tracked-fork UPSTREAM.json carries a non-empty owner and next-review date) wired beside the WP-RM-01 checker.
• **Acceptance criteria**: (1) the train map names, for every milestone M0–M7, the train/tag that evidences it (M1 = fabric/staging/v7.0.1-staging.<sha>, the staging train that publishes all 43 packages at that exact version under dist-tag staging, with fabric/main/v7.0.0 recorded as the promotion train that follows — amended 2026-10-04 from the literal fabric/staging/v7.0.0, which the resolver rejects (WP-RN-07 review M4, spec 15 §4.1); later milestones by scheme, resolved to concrete versions as they ship) and shows no intermediate train between M0 and M1 carrying renamed-but-unbounded packages (mirrors WP-PKG-01 AC4 — audited from the tag list); (2) the cutover record states that exactly one break train exists (D10), **contains the documented abort/rollback procedure for the 7.0.0 train** (§6 risk 7: immutable fabric/<branch>/v* tags retained; abort executed by reverting dist-tags to the pre-train versions and re-pinning consumers — no unpublish, no public-repo touch; the procedure references WP-RN-07 AC3's rehearsed from-tag recovery path), and that RN-2…RN-5 sweeps shipped as non-breaking trains for @fabricstack/* consumers, or documents each additional consumer-visible break with its approval; (3) the cadence register lists all five tracked forks with owner + next-due quarterly review, the intake-review cadence, the bulk-intake checkpoint (closed before WP-RN-10 executes — cross-checked against WP-RN-10 AC4's sign-off note), and the Effect rc→stable watch item with its trigger criteria from docs/EFFECT-BASELINE.md; (4) check-upstream-cadence.cjs fails on a fixture UPSTREAM.json lacking owner or date (negative fixture); (5) the relay artifact class appears in the train map with its Phase-7 rollout train, its WP-PKG-14 ownership reference, and the FR-7 runbook reference.
• **Test requirements**: cadence-checker negative fixture; train-map row-completeness check (8 milestone rows, 5 fork rows) in docs-quality CI; tag-namespace audit script output attached to the M1 gate record.
• **Dependencies**: WP-RM-01 (index/status substrate); WP-RN-07 (tag scheme live before concrete versions can be recorded — the map's schema and cadence register land first, versions fill in at M1); WP-T3-01 (UPSTREAM.json files exist for the cadence fields).
• **Size**: M

WP-RM-03: Gate-B compliance matrix — D1–D21 traceability

• **Objective**: Produce and maintain the compliance matrix Gate B verifies against (the proposal's R-03; intent acceptance criterion 2 requires the specs be compared "against this file verbatim" — 00-intent.md:58): every decision D1–D21 traced to the spec sections and work packages that honor it, every one of the 96 WPs traced to the decisions it implements, the 40-ID survivor-register closure tracked (spec 20 §2), and the open Gate-B items carried to resolution: the platform-package name amendment gating WP-PKG-07, the optional fabric launcher alias, the retired-shell naming contingency (spec 15 §3.2), the **E1/E2 phase-pull ratification** (§4 — the D11-stretch is ratified by the Gate-B session alongside the name matrix, never presumed), scope delta SD-PKG-1 (spec 40 §1.6), and the documented scope deltas (§3 note 9, incl. the WP-PKG-14 addition). The formerly-open §3 notes 4 and 5 are resolved in-spec (WP-PKG-04 AC8 + WP-PKG-05 AC7; WP-PKG-14) and enter the register as accepted resolutions, not open items. WP-RN-08 AC1's naming cross-check and spec 15 §7's "R-03 traces D17–D21 against this spec verbatim" row are rows of this matrix.
• **Affected paths**: new docs/specs/platform-gaps/roadmap/gate-b-compliance-matrix.md (21 decision rows × honoring citations; 96 WP rows × decision citations; survivor-register closure table; open-items register with disposition column); new scripts/check-compliance-matrix.cjs (row-count and citation-shape validation) wired beside the WP-RM-01 checker; cross-link from docs/PACKAGING-DECISIONS.md (WP-PKG-08 AC3 requires it).
• **Acceptance criteria**: (1) the matrix contains exactly 21 decision rows (D1–D21) each citing ≥1 honoring spec section by file+section, and exactly 96 WP rows each citing ≥1 decision — validated by the checker (negative fixtures: a missing decision row, a WP row with no citation); (2) the D17/D19 invariant rows cite the mechanical guards (G1–G6, PG1–PG5, WP-RN-02's push guard, WP-RN-08's gate) rather than prose assurances, and the D21 row records WP-RN-08 AC1's verification that spec 10's final text uses only §3.3 names; (3) the survivor-register table shows all 40 IDs with owning WP and status, matching spec 20 §2's absorption map exactly (37 WP-FN + Q-01 + Q-08 + P-01/P-02); (4) every §3 consistency-note resolution and every §3-note-9 scope delta appears in the open-items register with a Gate-B disposition (accepted | amended, with the amendment reference) — zero rows left undispositioned at Gate-B close; (5) the matrix carries the D7 bar's three-part status (D7(a) WP-TEST-03 AC6, D7(b) WP-TEST-04, D7(c) WP-TEST-01/02/06) and the "recommended, not gating" label for WP-TEST-08 (spec 30 §1), so the bar's satisfaction is auditable at M6.
• **Test requirements**: checker negative fixtures (missing row, citation-free row, undispositioned open item at gate close); docs-quality gate; a Gate-B rehearsal pass over the matrix with the intent file side-by-side, recorded in the WP closing note.
• **Dependencies**: WP-RM-01 (WP inventory + statuses); the Gate-B session itself for dispositions (the matrix lands complete-with-pending dispositions before Gate B and closes them at the gate — pending is a disposition state of the register, not placeholder text in this spec).
• **Size**: M

---

8. Cross-spec obligations honored (D21 checklist)

• Spec 15 §7 row for this spec: **R-01 sequences RN-0/RN-1 ahead of T-01** (§4, §5 Phases 0–2); **R-03 traces D17–D21 against spec 15 verbatim** (WP-RM-03 AC2).
• Spec 10 §8: the merged cross-spec graph is owned here (§2; WP-RM-01); migration is roadmap priority 1 (Phases 2–4 precede coverage-completion and packaging phases per D11).
• Spec 20 §3.3/§6: the R-01 triage categories and the merged graph are owned by WP-RM-01; the §5.1 ordering rule is a Phase-3 entry rule.
• Spec 30 §7: nothing in the testing spec blocks migration; the early-start exceptions are justified in §4 E2 and the D7 exits are M6 criteria.
• Spec 40 §8: the sequencing input (PKG-13 → {03 → 04 → 05 → 06 → 08, 07}, {09 → 10} after RN-12, PKG-14 after T3-31 + PKG-11/13) is encoded in Phases 6–7 with PKG-14's stage split documented in §3 note 5; both Gate-B name items and scope delta SD-PKG-1 are tracked by WP-RM-03.
• No work package in this spec touches the public a5c-ai/babysitter repo (D17; intent acceptance criterion 7); all roadmap tooling lives in fabric's private CI.

Work-package count in this spec: **3** (WP-RM-01 … WP-RM-03). Program total indexed: **96** (33 T3 + 13 RN + 24 FN + 9 TEST + 14 PKG + 3 RM).