Context
The birds-eye item the release planning lacked (operator dialogue 2026-07-18): a single surface that answers "how many merged PRs stand between here and v13.2?" in ballpark (±50), at any moment, without lying.
The Problem — why ticket counting cannot answer it
Counting open release-scoped tickets (or milestone completion) measures discovery, not distance: we work agile, so the ticket denominator grows precisely when we learn — 400 more in-scope tickets filed next week would move a ticket-based "progress %" backwards while the release moved FORWARD. Any estimator anchored to the filed backlog is structurally dishonest under iteration.
The Model — capability rows × reference-class density
The denominator is CLOSED by the outcome definition, not by tickets: the operator fully operates our own fleet via a downloadable Electron app, at release quality. That decomposes into the capability rows below. Rows change ONLY on deliberate scope change (a visible row edit) — never on ticket discovery. Tickets land IN rows; filing one never changes the distance, it only illuminates it.
Per row, the estimate is reference-class density, not backlog count: how many merged PRs did comparable now-walkable capabilities consume, END to END — including everything nobody foresaw? Empirical anchor: the docking choreography consumed 53 merged PRs in 3 days (2026-07-16 → 07-18, commit-subject count on the epic family) from Discussion graduation to four-of-five beats walkable — the undiscovered tickets (reap race, harness traps, admission truth, contract splits) are INSIDE that number. Discovery is priced in by construction. Sustained fleet velocity for calibration: 694 dev commits since 07-01 (≈25–40 merges/day).
Progress % = walkable-weighted, never ticket-weighted. A row's state is set by WALKING it (cheap, minutes), not by counting its tickets.
The Rows (v13.2 outcome decomposition — re-walked 2026-07-24; prior estimates 2026-07-18)
| # |
Capability row |
Walkable today? |
Remaining-PR ballpark |
Estimate basis |
| 1 |
Multi-window docking choreography (#15239) |
5/5 beats (park lifecycle #15396/#15395 + whole-stack return landed during the dark window); kinetic-witness runs opened a real defect tail (#15664 heap-join, #15648 silent vessel death, #15635 stranded pane) |
8–15 |
53+~10 consumed to 5/5; tail = the heap-join defect class, matrix receipts (#15243 rows 4–7), calibration, e2e legs |
| 2 |
FM cockpit operates the fleet, in-browser (#14560 family) |
mission-control walkable + publicly FILMED (Build Week); first self-use unwalked |
10–20 |
Build Week consumed the mid-band (cockpit + walkthrough + catch-up receipts); remaining = seat/wake control, error-recovery UX, the self-use friction tail |
| 3 |
The packaged shell operates the LIVE fleet (ADR-0034) |
E6 packaging + E8 lifecycle/tray done (#15531); fleet connectivity UNWALKED — activation gate = FIRST SELF-USE (2026-07-24 reframe, operator-aware) |
5–15 |
the walk itself remains the sharpener; the D#15595 parity pilot is the named walk VEHICLE for this row (see note below the number) |
| 4 |
Front door: the FM outward door — storefront repo + minimum site + launch motion (epic #15519) |
entry review chain closed at zero open items (Greenlight); 2/8 subs closed (#15521 topology ADR, #15524 demo authority); clean-consumer probe receipt = FAIL → topology E validated; naming #15520 = critical path (operator pick) |
8–14 |
the D#15498 authority + first two subs' density |
| 5 |
Design conformance / release polish — the GATING subset (#14805) |
partial |
20–40 (widest row) |
#14805's conformance walk separates gating from nice-to-have; the ~design-first backlog must NOT gate by default |
| 6 |
Testing depth: matrix receipts, e2e journeys, component shards (#15243 et al) |
partial (macOS probe-grade; kinetic-witness receipts started — and immediately caught row 1's defect tail, the row doing its job) |
8–15 |
receipts + the queued e2e legs |
| 7 |
Release mechanics: notes (#14800), publish, versioning |
notes epic being re-scoped against THIS meter + the dogfood gate (Grace, 2026-07-24) |
5–8 |
prior release mechanics |
| 8 |
Install/update experience (E7 channel, ADR-0034 §2.5.3) |
not started (named leaf) |
3–8 |
E6's density as the sibling reference |
THE NUMBER (re-walk 2026-07-24): ≈ 67–135 merged PRs remaining, center ≈ 101 (was 77–158, center ≈ 117, on 07-18). Still "closer to 100 than 500" — roughly 2–4 calendar weeks at sustained velocity with review/receipt gating.
Honesty datum from the re-walk: 117 PRs merged fleet-wide in the six days since 07-18 moved the center only ~16 — most of that throughput was institution substrate (the cloud-deployment acute chain #15748–#15773, the Build Week film + video-skill lane, wake infrastructure) OUTSIDE these rows. The meter measures release distance, not activity — exactly the property it was built for.
Row-3 reframe note (operator-aware, 2026-07-24): the activation gate is now FIRST SELF-USE — the operator flies our own fleet via FM. The D#15595 local-parity pilot is a walk vehicle for rows 2/3 (host-mode FM observing the parity stack walks both), deliberately NOT a new row: institution substrate does not gate the release outcome, it carries it.
Update protocol
- Any maintainer re-walks a row when its state visibly moves (a merge sweep, a capability landing) and edits the row + the number — the edit IS the progress report.
- New tickets NEVER touch this body; they land in rows implicitly. A new ROW (scope change) is a deliberate, visible edit with operator awareness.
- The number's tolerance is ±50 by design; arguing single rows to precision is anti-pattern — walk instead.
- Sunset: this epic closes WITH the v13.2 release; a successor is born per release.
Related
#15239 · #14560 · #14805 · #14800 · #14790 (launch playbook) · #14781 (integration journeys — the walk scripts for rows 2/3) · ADR-0034 (shell) · the 2026-07-18 v13.2 gap analysis on #15239 (the leaf-grain view this item deliberately sits ABOVE).
Live latest-open sweep 2026-07-18T17:2xZ: release-titled items checked (#14790 launch playbook = sequence-of-launch, #14800 = notes, #13383 = blog) — no birds-eye distance item exists. A2A sweep: no competing claim.
Retrieval Hint: "release distance capability rows reference-class density walkable ballpark PRs remaining v13.2"
Authored by @neo-fable-clio (Clio, Fable). Session 0c8fc4d9-2456-44fd-b120-048402bb9839.
Context
The birds-eye item the release planning lacked (operator dialogue 2026-07-18): a single surface that answers "how many merged PRs stand between here and v13.2?" in ballpark (±50), at any moment, without lying.
The Problem — why ticket counting cannot answer it
Counting open release-scoped tickets (or milestone completion) measures discovery, not distance: we work agile, so the ticket denominator grows precisely when we learn — 400 more in-scope tickets filed next week would move a ticket-based "progress %" backwards while the release moved FORWARD. Any estimator anchored to the filed backlog is structurally dishonest under iteration.
The Model — capability rows × reference-class density
The denominator is CLOSED by the outcome definition, not by tickets: the operator fully operates our own fleet via a downloadable Electron app, at release quality. That decomposes into the capability rows below. Rows change ONLY on deliberate scope change (a visible row edit) — never on ticket discovery. Tickets land IN rows; filing one never changes the distance, it only illuminates it.
Per row, the estimate is reference-class density, not backlog count: how many merged PRs did comparable now-walkable capabilities consume, END to END — including everything nobody foresaw? Empirical anchor: the docking choreography consumed 53 merged PRs in 3 days (2026-07-16 → 07-18, commit-subject count on the epic family) from Discussion graduation to four-of-five beats walkable — the undiscovered tickets (reap race, harness traps, admission truth, contract splits) are INSIDE that number. Discovery is priced in by construction. Sustained fleet velocity for calibration: 694 dev commits since 07-01 (≈25–40 merges/day).
Progress % = walkable-weighted, never ticket-weighted. A row's state is set by WALKING it (cheap, minutes), not by counting its tickets.
The Rows (v13.2 outcome decomposition — re-walked 2026-07-24; prior estimates 2026-07-18)
THE NUMBER (re-walk 2026-07-24): ≈ 67–135 merged PRs remaining, center ≈ 101 (was 77–158, center ≈ 117, on 07-18). Still "closer to 100 than 500" — roughly 2–4 calendar weeks at sustained velocity with review/receipt gating.
Honesty datum from the re-walk: 117 PRs merged fleet-wide in the six days since 07-18 moved the center only ~16 — most of that throughput was institution substrate (the cloud-deployment acute chain #15748–#15773, the Build Week film + video-skill lane, wake infrastructure) OUTSIDE these rows. The meter measures release distance, not activity — exactly the property it was built for.
Row-3 reframe note (operator-aware, 2026-07-24): the activation gate is now FIRST SELF-USE — the operator flies our own fleet via FM. The D#15595 local-parity pilot is a walk vehicle for rows 2/3 (host-mode FM observing the parity stack walks both), deliberately NOT a new row: institution substrate does not gate the release outcome, it carries it.
Update protocol
Related
#15239 · #14560 · #14805 · #14800 · #14790 (launch playbook) · #14781 (integration journeys — the walk scripts for rows 2/3) · ADR-0034 (shell) · the 2026-07-18 v13.2 gap analysis on #15239 (the leaf-grain view this item deliberately sits ABOVE).
Live latest-open sweep 2026-07-18T17:2xZ: release-titled items checked (#14790 launch playbook = sequence-of-launch, #14800 = notes, #13383 = blog) — no birds-eye distance item exists. A2A sweep: no competing claim.
Retrieval Hint: "release distance capability rows reference-class density walkable ballpark PRs remaining v13.2"
Authored by @neo-fable-clio (Clio, Fable). Session 0c8fc4d9-2456-44fd-b120-048402bb9839.