@event4u/agent-config 14.7.0 → 14.8.0

package/src/config/estate-count-budget.json

@@ -16,9 +16,9 @@
     ]
   },
   "baseline": {
-    "active_roadmaps": 14,
+    "active_roadmaps": 3,
     "later_roadmaps": 55,
-    "open_blockers": 47
+    "open_blockers": 26
   },
   "baseline_history": [
     {
@@ -475,6 +475,279 @@
       "later_roadmaps": 55,
       "open_blockers": 47,
       "why": "WALKED DOWN by 1 active and nothing else: road-to-ci-native-release-first-run is archived by this branch (present under agents/roadmaps/ on main, added under agents/roadmaps/archive/ here). open_blockers is UNCHANGED at 47, which is the check that says this closure bought nothing by relocating an open decision -- the roadmap carried no blocker that moved, and the part it could not finish went to stubs/road-to-ci-native-release-live-label-path.md with its own probe. later_roadmaps unchanged at 55: a stub is not a park, so the open work stays counted where a probe can decide it rather than in later/."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 60,
+      "why": "RE-MEASURED AT MERGE, not argued. Branch drain/road-to-orchestration-scope-decision merged origin/main during the autonomous roadmap-drain run; the trunk had moved (sibling drain PRs archiving roadmaps and resolving blockers in parallel), so neither side's numbers described the merged tree. These values are what `check_estate_count` MEASURED after the merge: {'active_roadmaps': 23, 'later_roadmaps': 52, 'open_blockers': 60}, from {'active_roadmaps': 24, 'later_roadmaps': 52, 'open_blockers': 61}. No part of the drop is attributed to this branch, deliberately: its own earned share is recorded in its roadmap and its PR body, and crediting a parallel session's drawdown to this change is exactly how a ratchet loosens without anyone noticing. Walked DOWN only \u2014 this entry never raises a number, and a lower measurement is the new ceiling."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 13,
+      "later_roadmaps": 55,
+      "open_blockers": 46,
+      "why": "WALKED DOWN by 1 active and 1 blocker. road-to-orchestration-scope-decision archived (under agents/roadmaps/ on main, under archive/ here) and its single blocker real-orchestration-usage, open on the trunk, is closed here as 'resolved -- transferred' on disposition B, with the obligation carried by stubs/road-to-task-completion-observability.md created in this same change. Transferred rather than completed: the blocker wanted evidence of real orchestration usage, which no change-set can manufacture, so the honest close is a stub with a probe rather than a claim that the evidence arrived. later_roadmaps unchanged at 55 -- a stub is not a park."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 22,
+      "later_roadmaps": 52,
+      "open_blockers": 60,
+      "why": "RE-MEASURED AT MERGE, not argued. Branch drain/road-to-skill-ecosystem-gate-integrity merged origin/main during the autonomous roadmap-drain run; the trunk had moved (sibling drain PRs archiving roadmaps and resolving blockers in parallel), so neither side's numbers described the merged tree. These values are what `check_estate_count` MEASURED after the merge: {'active_roadmaps': 22, 'later_roadmaps': 52, 'open_blockers': 60}, from {'active_roadmaps': 23, 'later_roadmaps': 52, 'open_blockers': 61}. No part of the drop is attributed to this branch, deliberately: its own earned share is recorded in its roadmap and its PR body, and crediting a parallel session's drawdown to this change is exactly how a ratchet loosens without anyone noticing. Walked DOWN only \u2014 this entry never raises a number, and a lower measurement is the new ceiling."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 12,
+      "later_roadmaps": 55,
+      "open_blockers": 45,
+      "why": "WALKED DOWN by 1 active and 1 blocker. road-to-skill-ecosystem-gate-integrity archived (under agents/roadmaps/ on main, under archive/ here) and its single blocker kernel-cross-link-soak, open on the trunk, is closed here as 'resolved -- transferred, not done' -- the branch's own wording, which is the honest one: a soak needs elapsed time, so no change-set can finish it. The obligation is carried by stubs/road-to-kernel-cross-link-soak.md created in this same change. later_roadmaps unchanged at 55: a stub is not a park, and the soak stays counted where a probe can decide it."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 59,
+      "why": "RE-MEASURED AT MERGE, not argued. Branch drain/road-to-context-fidelity merged origin/main during the autonomous roadmap-drain run; the trunk had moved (sibling drain PRs archiving roadmaps and resolving blockers in parallel), so neither side's numbers described the merged tree. These values are what `check_estate_count` MEASURED after the merge: {'active_roadmaps': 23, 'later_roadmaps': 52, 'open_blockers': 59}, from {'active_roadmaps': 24, 'later_roadmaps': 52, 'open_blockers': 61}. No part of the drop is attributed to this branch, deliberately: its own earned share is recorded in its roadmap and its PR body, and crediting a parallel session's drawdown to this change is exactly how a ratchet loosens without anyone noticing. Walked DOWN only \u2014 this entry never raises a number, and a lower measurement is the new ceiling."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 11,
+      "later_roadmaps": 55,
+      "open_blockers": 43,
+      "why": "WALKED DOWN by 1 active and 2 blockers. road-to-context-fidelity archived (under agents/roadmaps/ on main, under archive/ here). Two of its three blockers are open on the trunk and closed here on council dispositions dated 2026-08-20: compaction-census-session and prominence-gate-skills-corpus. The third, memory-sweep-instrument, was already resolved on the trunk by a 2026-08-19 council and is excluded from the delta -- the kind of pre-existing closure that would otherwise be banked as this change's drawdown. later_roadmaps unchanged at 55: the part that could not be finished went to stubs/road-to-compaction-survival-census.md with its own probe, so the open work stays counted rather than parked."
+    },
+    {
+      "at": "2026-08-20",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 60,
+      "why": "WALKED DOWN by 2 blockers, and NOTHING IN THE REPOSITORY EARNED THE DROP - a transfer lowers this number by construction, which is the one case where a falling measurement is not progress. The drain run that closed road-to-rule-coherence-followup resolved its two entries (default-flip-release-gate, bench-spend-and-methodology) under the council's B and D dispositions: the shipped-default flip and the human-judged A/B run both left for stubs/road-to-discipline-default-flip.md with verbatim criteria, complete moved-step lists, a named producer and probes measured at transfer. The work is not done and is not gone; it is counted in the stub instead of here, exactly as the 2026-08-20 phase3-harness-deltas-9-10 entry above records for its own transfer. Written as `resolved` because that is the ONLY closed token lint_roadmap_blockers reads - `transferred` scans as open to every gate - so the outcome state lives in the resolution prose, the stub and the stubs/README row rather than in the status token. Anyone reading this series as a drawdown curve should discount these 2 the way they discount the parking entries: the estate got smaller, the obligation did not. Re-measured over the merged tree after merging origin/main, not carried over from before the merge. Active roadmaps also fall 25 -> 24 in the same change, and that half IS earned in the ordinary way: road-to-rule-coherence-followup reached zero open steps and `agent-config roadmap:progress` archived it. The two halves of this entry are therefore different kinds of movement and are recorded separately on purpose - the roadmap genuinely left the active tree, while the 2 blockers only changed which file counts them. RE-BASED ON MERGE with origin/main, 2026-08-21. Authored against a different base; the trunk moved in parallel, so neither side's number describes the merged tree and the gate MEASURED it at 23 active / 60 open_blockers. What THIS branch earned is -1 active (road-to-rule-coherence-followup reached 0 open and was archived by the roadmap:progress sweep) and -2 open_blockers (both of its entries closed, each with outcome state transferred rather than satisfied). The blocker half of that is a RELOCATION, not a discharge: the criteria moved into stubs/road-to-discipline-default-flip.md and stubs/road-to-declared-protocol-cap.md, and the metric counts entries, so it falls whether or not a line of the transferred work exists. Any remaining delta came from the trunk and is banked rather than attributed."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 10,
+      "later_roadmaps": 55,
+      "open_blockers": 41,
+      "why": "WALKED DOWN by 1 active and 2 blockers. road-to-rule-coherence-followup archived (under agents/roadmaps/ on main, under archive/ here) and both of its blockers, default-flip-release-gate and bench-spend-and-methodology, are open on origin/main and resolved here -- verified per blocker against the trunk. later_roadmaps unchanged at 55, and that is the load-bearing part of this entry: the two items the roadmap could not finish went to TWO stubs created in this same change, stubs/road-to-declared-protocol-cap.md and stubs/road-to-discipline-default-flip.md, each with its own probe. Nothing was parked into later/ and nothing was dropped, so the -2 is a relocation into probe-carrying stubs rather than work completed."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 9,
+      "later_roadmaps": 55,
+      "open_blockers": 41,
+      "why": "RE-MEASURED after a SECOND merge of origin/main, not a second drawdown. The trunk moved while this branch waited for CI (PR #1507 landed and walked open_blockers to 41 itself), so the entry this branch wrote earlier -- active 11 -> 10, blockers 43 -> 41 -- was measured against a tree that no longer exists. Against the merged tree the only delta still owned by this branch is active_roadmaps 10 -> 9, the archival of road-to-rule-coherence-followup. open_blockers is left at 41 rather than claimed again: its two closures are already recorded, once, in the earlier entry, and re-counting them here is exactly how a ratchet double-books a single piece of work. later_roadmaps unchanged at 55."
+    },
+    {
+      "at": "2026-08-20",
+      "active_roadmaps": 32,
+      "later_roadmaps": 52,
+      "open_blockers": 65,
+      "why": "open_blockers 70 -> 65 by the road-to-always-on-orchestration drain: all five of that roadmap's entries were RESOLVED in one change \u2014 four transferred to probe-keyed stubs under council disposition B (2026-08-20, anthropic + openai, quorum 2/2) and one satisfied by shipping the cross-vendor direction policy the criterion asked for. active_roadmaps and later_roadmaps are unchanged at 32 and 52: the roadmap stays in the active tree because this run was instructed not to archive it, and the four stubs land under agents/roadmaps/stubs/, which collect() does not count. So this is a pure blocker drawdown with no estate movement behind it. Worth recording honestly: FOUR of the five closures are transfers, not achievements \u2014 the work moved to a stub because this repository cannot produce the evidence it needs (an unset experimental host flag, an unverified live Stop-slot delivery, an unverified transport soak, and a main-vs-subagent identity upstream closed NOT_PLANNED). The blocker count fell by five; the amount of unfinished work fell by one. A future reader comparing this metric against progress should read \u00a7 Outcome in that roadmap, which states the same thing at length."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 8,
+      "later_roadmaps": 55,
+      "open_blockers": 36,
+      "why": "WALKED DOWN by 1 active and 5 blockers -- the largest single drawdown of this drain, so the composition matters. road-to-always-on-orchestration archived (under agents/roadmaps/ on main, under archive/ here). All five of its blockers are open on origin/main and closed here, and FOUR of the five are 'resolved -- transferred', each to a stub created in this same change: gate-council-auto-dispatch, point-of-action-carrier, f4-full-stop-block and team-telemetry-behind-flag. Only ONE, cross-vendor-worker-slices, is 'resolved -- satisfied', i.e. actually finished. So this -5 is mostly relocation into probe-carrying stubs rather than completed work, and reading it as five closed problems would be wrong. later_roadmaps unchanged at 55: stubs, not parks."
+    },
+    {
+      "at": "2026-08-20",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 60,
+      "why": "open_blockers 64 -> 62: the two blockers of road-to-user-out-of-the-loop resolved on the autonomous drain run. autonomy-defaults-sheet closed SATISFIED (AI council disposition D -- all four reversible policy values named and implemented or recorded at the site that carries them); kernel-soak-window closed TRANSFERRED (disposition B -- only the ask-when-uncertain arm crosses the locked-kernel boundary, and it moved to agents/roadmaps/stubs/road-to-batch-elicitation-kernel-delta.md). Both under the 2/2 council record agents/evidence/council/drain-blocker-dispositions-a.md.\n\nRead the two halves of this walk-down differently, because they are not the same kind of movement. autonomy-defaults-sheet is a real discharge: the four values are decided and three of them are implemented in the tree (roadmap-process-loop 3a splits the wrapper row so /roadmap:next preselects phase-checkpoints; roadmap-execution-contract 2a ships late_artifacts with halt as the default; 2b plus the roadmap-progress-sync delta ship deferred_policy with both exits). The fourth, the lane cap of 2, is recorded rather than implemented -- lanes are staged behind ten clean serial set runs, measured 0 today and unobtainable until a set entry point exists.\n\nkernel-soak-window is the other kind, and it lowers this number by construction while NOTHING in the repository earned the drop. src/rules/ask-when-uncertain.md is byte-identical to its state before the run; it is row 2 of the locked nine in docs/contracts/kernel-membership.md section 4; block-kernel-rule-writes remains bound blocking with fail_closed: true at hook_manifest.yaml:924; and authorization records for the batch-elicitation delta number ZERO, read live on 2026-08-20. The metric counts open blocker ENTRIES, so a transfer to a stub lowers it whether or not a single line of the transferred work exists. The stub carries the original criterion verbatim, the complete list of dependent steps moved, and a named re-entry producer (the kernel-rule maintainer) with a two-conjunct probe pinned to those readings -- a recorded authorization plus the >= 24 h kernel-rule-edits soak completing without rollback -- so the movement stays detectable instead of dissolving into the count.\n\nactive_roadmaps unchanged at 32 and later_roadmaps unchanged at 52 is deliberate and is what separates this from a disposal. The drained roadmap reached 44/44 with count_deferred 0, and archival is not this run's to perform by hand: it happens deterministically in the PR that completes it, via the archive sweep. Until then the file stays in the active tree, which is why the active count did not move.\n\nRE-BASED on merge with origin/main, 2026-08-20. This entry was authored against a baseline of 68 and walked to 66. main moved in parallel -- it archived roadmaps (active_roadmaps 32 -> 25) and resolved blockers of its own (open_blockers 68 -> 64) -- so neither side's number describes the merged tree. The merged tree was MEASURED by the gate at 62, and the arithmetic for this change is unchanged at -2: the same two blockers of road-to-user-out-of-the-loop, from whatever base the trunk had reached. later_roadmaps is carried from main untouched, because this change parked nothing.\n\nactive_roadmaps 25 -> 24, and this one is a REAL disposal rather than a relocation: road-to-user-out-of-the-loop reached 44/44 with count_deferred 0 and was archived to agents/roadmaps/archive/ by `agent-config roadmap:progress` itself -- the auto-archive that landed on main in PR #1493, not a hand `git mv`. The earlier draft of this entry said the active count did not move because archival was out of this run's scope; that was true of the run and false of the tooling, and the sentence is corrected rather than deleted so the reason for the difference stays readable. Inbound links from the two new stubs were re-depthed to ../archive/ in the same change, because the archival sweep does not re-depth moved links. RE-BASED AGAIN at the final merge with origin/main, 2026-08-21, and the earlier re-base note above is kept rather than rewritten so the sequence stays readable. The gate MEASURED the merged tree at 23 active / 60 open_blockers and those are the recorded values. This branch's own arithmetic is unchanged: -1 active (road-to-user-out-of-the-loop archived at 44/44, count_deferred 0) and -2 open_blockers, of which autonomy-defaults-sheet is a real discharge and kernel-soak-window is a transfer that lowers the count while nothing in the repository earned the drop -- src/rules/ask-when-uncertain.md is byte-identical to its pre-run state, it is row 2 of the locked nine, block-kernel-rule-writes stays bound blocking with fail_closed: true at hook_manifest.yaml:924, and authorization records for the transferred delta number ZERO. Any further movement in these numbers came from the trunk in parallel and is banked, not attributed."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 7,
+      "later_roadmaps": 55,
+      "open_blockers": 34,
+      "why": "WALKED DOWN by 1 active and 2 blockers. road-to-user-out-of-the-loop archived (under agents/roadmaps/ on main, under archive/ here) and both of its blockers, kernel-soak-window and autonomy-defaults-sheet, are open on origin/main and resolved here -- verified per blocker against the trunk. The two items the roadmap could not finish went to stubs created in this same change, stubs/road-to-batch-elicitation-kernel-delta.md and stubs/road-to-roadmap-set-front-doors.md, each with its own probe, which is why later_roadmaps stays 55: relocation into probe-carrying stubs, not a park and not a drop."
+    },
+    {
+      "at": "2026-08-20",
+      "active_roadmaps": 24,
+      "later_roadmaps": 52,
+      "open_blockers": 63,
+      "why": "LOWERED by 1 on active_roadmaps (25 -> 24) and 1 on open_blockers (64 -> 63), and NOTHING IN THE REPOSITORY EARNED THE DROP. road-to-gated-reach-followup reached zero open steps and zero deferred items and was archived, and its `legacy` blocker was resolved -- but resolved with outcome state `transferred`, not `satisfied`: the condition it named (a human installing yt-dlp plus a JavaScript runtime) did not clear. It moved to stubs/road-to-youtube-channel-exercise.md behind a named producer (the host owner) and a two-part probe measured on the transfer date. Nine of the roadmap's fifteen lines went with it; the six that had no dependency on the absent backend were completed in place. So the estate is one roadmap and one blocker smaller while the underlying capability is exactly as unmeasured as before, and that is the honest reading of these two numbers. Walked down anyway, for the reason the 2026-08-19 entry gives from the other side: a baseline left above a lower measurement is headroom a later change can spend with no gate objecting, and the count half compares the live tree against this file irrespective of the diff, so leaving it high would hand free growth to whoever comes next. later_roadmaps is unchanged at 52, which is the check that distinguishes a terminal disposition from a park -- a stub under stubs/ is explicitly not counted as estate by this metric's own not_gated note, so the honest caveat is that this drawdown moves work into a surface the ratchet cannot see. Recorded here rather than left implicit, because a reader comparing only the numbers would read a transfer as a completion."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 60,
+      "why": "RE-MEASURED AT MERGE, not argued. Branch drain/road-to-gated-reach-followup merged origin/main during the autonomous roadmap-drain run; the trunk had moved (sibling drain PRs archiving roadmaps and resolving blockers in parallel), so neither side's numbers described the merged tree. These values are what `check_estate_count` MEASURED after the merge: {'active_roadmaps': 23, 'later_roadmaps': 52, 'open_blockers': 60}, from {'active_roadmaps': 24, 'later_roadmaps': 52, 'open_blockers': 61}. No part of the drop is attributed to this branch, deliberately: its own earned share is recorded in its roadmap and its PR body, and crediting a parallel session's drawdown to this change is exactly how a ratchet loosens without anyone noticing. Walked DOWN only \u2014 this entry never raises a number, and a lower measurement is the new ceiling."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 6,
+      "later_roadmaps": 55,
+      "open_blockers": 33,
+      "why": "WALKED DOWN by 1 active and 1 blocker, and the blocker half took real digging rather than a status-line count -- the driver reported ZERO open-to-resolved transitions, which is true and misleading. active_roadmaps 7 -> 6 is the archival of road-to-gated-reach-followup. open_blockers 34 -> 33 comes from a LEGACY marker: on origin/main that file carries '> Blocked until yt-dlp and a JavaScript runtime are installed by a human', which the parser counts as one open blocker via its legacy Blocked-until form, and this branch converts it into a structured '### blocker: legacy' entry with Status resolved and Owner user. So no status line changed from open to resolved; a legacy note became a structured, closed one. The obligation itself is preserved in stubs/road-to-youtube-channel-exercise.md, which is why later_roadmaps stays 55."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 61,
+      "why": "WALK-DOWN, earned by one archival and nothing else, RE-MEASURED AT MERGE. road-to-solution-minimalism reached 0 open / 0 deferred / 0 open blockers and `roadmap:progress` archived it, so active_roadmaps measures 23 against a trunk ceiling of 24. The one point is a real termination, not an accounting move: nothing was parked, re-classified `draft`, or split, and later_roadmaps is unchanged at 52. Its residue did move to a stub (the ~30 oracles and the full-tier run, transferred 2026-08-20 in PR #1480), but that transfer was counted then and this entry adds nothing for it. RECONCILIATION: this entry first read open_blockers 62, measured against d0fad2ccd before origin/main moved 11 commits ahead; the trunk has since measured 61, so that NUMBER is superseded and only the active_roadmaps claim it carried still stands. The baseline above was re-measured against the merged tree rather than taken from either side, and every history entry from both sides is retained -- main's 38 in main's order, plus this one. A lower measurement is the new ceiling, never headroom to spend later."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 22,
+      "later_roadmaps": 52,
+      "open_blockers": 61,
+      "why": "RE-MEASURED AT MERGE, not argued. Branch drain/road-to-solution-minimalism merged origin/main during the autonomous roadmap-drain run; the trunk had moved (sibling drain PRs archiving roadmaps and resolving blockers in parallel), so neither side's numbers described the merged tree. These values are what `check_estate_count` MEASURED after the merge: {'active_roadmaps': 22, 'later_roadmaps': 52, 'open_blockers': 61}, from {'active_roadmaps': 23, 'later_roadmaps': 52, 'open_blockers': 61}. No part of the drop is attributed to this branch, deliberately: its own earned share is recorded in its roadmap and its PR body, and crediting a parallel session's drawdown to this change is exactly how a ratchet loosens without anyone noticing. Walked DOWN only \u2014 this entry never raises a number, and a lower measurement is the new ceiling."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 5,
+      "later_roadmaps": 55,
+      "open_blockers": 33,
+      "why": "WALKED DOWN by 1 active and nothing else: road-to-solution-minimalism is archived by this branch (under agents/roadmaps/ on main, under agents/roadmaps/archive/ here). This is the roadmap PR #1480 left open earlier in this same drain on exactly one acceptance step -- all quality gates pass -- which was deliberately NOT flipped then because a green CI run is what closes it, not an agent's assertion. That step is closed here and the archive follows. open_blockers unchanged at 33: its blockers were already resolved before this change, so nothing is claimed twice. later_roadmaps unchanged at 55."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 6,
+      "later_roadmaps": 55,
+      "open_blockers": 34,
+      "why": "Raised by one for `merge-authority` in road-to-drain-commands. The blocker is not deferred work: it records that activating a `--merge` flag lowers a recorded safety floor (ADR-237 s4 excludes merging and says no invocation extends it), which docs the decision-revisit-gate reserves to the owner. Three independent reviews reached that same verdict before the blocker was written - the AI council, the committed road-to-gate-preauth-authorization stub, and the runtime classifier, which refused this branch's own attempt to edit the prohibition out of the canonical loop. Writing it as a blocker is what keeps the estate honest here: the alternative was to ship the flag active with an amendment the agent authored for itself, which would have left the count unchanged and the floor lowered. Also raised active_roadmaps 10 -> 11 for the same file. It ships 27 of its 29 steps closed in the change that adds it, and stays active only because that one owner decision is outstanding; its frontmatter carries the matching estate_offset_exempt line rather than parking an unrelated roadmap to balance the books. Rebased onto main's drawdown during the merge: main lowered active_roadmaps to 10 and open_blockers to 43 while this branch was open, so the +1 for this roadmap is applied to THAT floor (11 / 44) rather than to the 11 / 43 this branch started from. Taking our own higher numbers would have silently undone someone else's drawdown, which is the one thing a ratchet must never let a merge do."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 7,
+      "later_roadmaps": 55,
+      "open_blockers": 36,
+      "why": "REBASED ONTO THE TRUNK'S WALK-DOWN (FIFTH time on this branch -- main moved five times across the review rounds, twice while CI was running on this branch). Re-measured from the tree: with main's file in place `check_estate_count` reported `active_roadmaps 7 (baseline 6, +1)` and `open_blockers 36 (baseline 34, +2)`, which is exactly this branch's contribution. main's lineage is kept whole (85 history entries, baseline 6/55/34) and only that delta rides on top, giving 7/55/36.\n\nFive identical resolutions is worth naming as a PATTERN rather than five accidents: the trunk is being drained continuously, a CI cycle here takes about twenty minutes, and main moved 45 commits during the last one. The drain's own run summary records the same shape from the other side -- 'the merge-authorization window is shorter than a drain takes'. So this conflict is structural for any branch that is not merged within one CI cycle, and the resolution is mechanical each time: take main's lineage, re-measure the delta, never carry the numbers. The one time they were carried, the entry shipped a `why` naming 12 -> 13 while its own field read 10.\n\nThe +2 open blockers are both on road-to-evidence-based-adr-governance and both are maintainer decisions put in front of the maintainer rather than drift: `owner-autonomy-batch` (three Hard-Floor rulings the source instruction did not authorize) and `authority-coupling-decision` (whether an independently validated evidence grade may ever reduce authorization burden -- deferred on a unanimous two-seat council ruling that fusing evidence metadata with authority is the design's central defect, because the party assigning the grade would also be the party gaining authority from it AND would be self-classifying the transition as reversible-internal). The active_roadmaps side is covered by the roadmap's own estate_offset_exempt, which records why no one-in-one-out offset is taken: the other active roadmaps belong to other sessions, and this ledger's own 67 -> 69 entry names 'closing someone else's work to buy the number back' as the incentive the ratchet must never create. 7 and 36 are the measured trunk-plus-this-change values and are now the numbers that must walk down."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 61,
+      "why": "WALKED DOWN by 1 active roadmap: road-to-estate-drawdown archived, all eight steps terminal. EARNED vs BANKED, because the trunk moved under this branch and the split matters: this change earned the ENTIRE -1 on active_roadmaps and NONE of the movement on the other two. When this branch fast-forwarded to 52cfb4bb8 the tree measured exactly 24/52/61, i.e. already at the baseline the trunk had just set, so open_blockers 62->61 was the previous entry's drawdown and not this one's. later_roadmaps unchanged at 52 -- nothing was parked. open_blockers unchanged at 61 and that is the honest number even though this change closed a roadmap: its single blocker b-consolidated-decision-sheet was ALREADY resolved on the trunk by PR #1492, so archiving the file removed no open record from the count. ACCOUNTING WARNING, recorded rather than absorbed: two of the five closures were TRANSFERS into agents/roadmaps/stubs/, which neither metric counts -- steps 2.1 and 2.2 plus AC-2 went to road-to-estate-triage-remaining-batches.md, and the draft-status ratchet hole went to road-to-draft-status-ratchet-boundary.md. So a reader must not read -1 active as -1 unit of work: the stub carries a probe measured at 71 untriaged files, and 71 files of scope left the counted estate by being renamed rather than by being done. That is exactly the accounting move this history array exists to make visible."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 22,
+      "later_roadmaps": 52,
+      "open_blockers": 61,
+      "why": "MERGE RESOLUTION, and the number is MEASURED on the merged tree rather than taken from either side. Both sides of this conflict had independently walked active_roadmaps to 23 and BOTH were right about their own tree: the trunk archived road-to-session-closeout, this branch archived road-to-estate-drawdown. Adopting either 23 would have silently banked one archival and lost the other, which is why this array is resolved by union and the baseline by re-measurement. EARNED vs BANKED on the -2 from 24: exactly HALF is this branch's. This change earned the road-to-estate-drawdown archival; the road-to-session-closeout archival arrived from origin/main in the same merge and is banked, not earned. later_roadmaps 52 and open_blockers 61 are unchanged by both sides. baseline_history: 39 entries on this branch + 2 trunk-only entries = 41 before this one; every entry from both sides is kept, because a dropped entry is a lost reason and the array is append-only. The stubs accounting warning from this branch's previous entry still stands and is not restated: two closures were transfers into agents/roadmaps/stubs/, which neither metric counts, so 71 files of triage scope left the counted estate by being renamed rather than finished."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 6,
+      "later_roadmaps": 55,
+      "open_blockers": 36,
+      "why": "WALKED DOWN by 1 active and nothing else: road-to-estate-drawdown is archived by this branch (under agents/roadmaps/ on main, under agents/roadmaps/archive/ here). Fitting, since it is the roadmap this ratchet was registered to serve. open_blockers unchanged at 36 and later_roadmaps unchanged at 55, which together are the check that nothing was bought by relocating an open decision: the two items the roadmap could not finish went to stubs created in this same change (road-to-draft-status-ratchet-boundary, road-to-estate-triage-remaining-batches), each with its own probe, and a stub is not a park."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 61,
+      "why": "active_roadmaps 24 -> 23 and open_blockers 62 -> 61, both walked down by the close of road-to-standing-context-40k. NOTHING IN THE REPOSITORY EARNED EITHER DROP, and the two are one accounting event rather than two: the roadmap left the active tree for archive/ and its one blocker (b-rules-efficiency-signal) left the active estate with it, reappearing as an item in stubs/road-to-instructions-loaded-observer.md that this metric does not scan. No question was answered and no work finished -- the roadmap closed with outcome state `transferred`, five of its nine lines moved to two stubs and one sibling roadmap, and the registered 40k destination is not reached. The blocker's own Correction B had already concluded it was a transfer under the framework's rule 4; PR #1484 held the `Status: open` token only because the roadmap was still active, so writing `resolved` here applies a recorded disposition rather than making a new one. later_roadmaps is unchanged at 52 on purpose: the council explicitly rejected parking this roadmap in later/, on the ground that its four open lines shared no producer and three unrelated resume triggers in one parked file is the ownerless queue the framework warns against. For whoever merges next: main is moving fast and this file collides the same way every time. Keep every history entry from both sides and RE-MEASURE the baseline against the merged tree -- never adopt one side's number. Measured on this branch against d0fad2ccd."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 60,
+      "why": "MERGE RECONCILIATION, and the number is MEASURED against the merged tree rather than taken from either side. Both sides walked open_blockers 62 -> 61 for a different blocker: origin/main for road-to-subagent-lifecycle-integrity's raw-capture-needs-host-env, this branch for road-to-standing-context-40k's b-rules-efficiency-signal. Neither number describes the merged tree, which reads 60 = 62 - 1 - 1. Adopting one side's 61 would have claimed a count no tree has, and would have left a -1 drawdown for the next PR to fail on. active_roadmaps stays 23: this branch's archival is the only one in the merge. NOTHING IN THE REPOSITORY EARNED THE DROP on either side -- both blockers left the active estate by transfer to a stub this metric does not scan. Every history entry from both sides is preserved; none was collapsed. For whoever merges next: keep every entry and RE-MEASURE; never adopt one side's number."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 22,
+      "later_roadmaps": 52,
+      "open_blockers": 60,
+      "why": "RE-MEASURED AT MERGE, not argued. Branch drain/road-to-standing-context-40k merged origin/main during the autonomous roadmap-drain run; the trunk had moved (sibling drain PRs archiving roadmaps and resolving blockers in parallel), so neither side's numbers described the merged tree. These values are what `check_estate_count` MEASURED after the merge: {'active_roadmaps': 22, 'later_roadmaps': 52, 'open_blockers': 60}, from {'active_roadmaps': 23, 'later_roadmaps': 52, 'open_blockers': 61}. No part of the drop is attributed to this branch, deliberately: its own earned share is recorded in its roadmap and its PR body, and crediting a parallel session's drawdown to this change is exactly how a ratchet loosens without anyone noticing. Walked DOWN only \u2014 this entry never raises a number, and a lower measurement is the new ceiling."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 5,
+      "later_roadmaps": 55,
+      "open_blockers": 35,
+      "why": "WALKED DOWN by 1 active and 1 blocker. road-to-standing-context-40k is archived by this branch (under agents/roadmaps/ on main, under agents/roadmaps/archive/ here) and its single blocker b-rules-efficiency-signal, open on origin/main, is resolved here -- checked against the trunk rather than read off the branch's prose. later_roadmaps unchanged at 55: the two items it could not finish went to stubs created in this same change (road-to-instructions-loaded-observer, road-to-standing-rule-delivery-per-machine), each with its own probe, so the open work stays counted where a probe can decide it instead of being parked."
+    },
+    {
+      "at": "2026-08-22",
+      "active_roadmaps": 5,
+      "later_roadmaps": 55,
+      "open_blockers": 35,
+      "why": "REBASED ONTO THE TRUNK'S LINEAGE, then re-measured -- main moved from 66b3dc993 to c298a6aba while this branch was being built (PR #1505, drain/road-to-estate-drawdown, landed in that window). main's history is kept whole (89 entries, baseline 6/55/36) and only this branch's delta rides on top, per ADR-239-no-union-merge-for-ratchet-baselines: take main's lineage, re-measure from the tree, never carry the numbers forward.\n\nThis branch's contribution is -1 active and -1 open blocker, both earned by closing `road-to-drain-commands` (37 done / 2 cancelled / 0 open / 0 deferred) and archiving it. The blocker decrement is `merge-authority` moving to Status: resolved -- closed as NOT AUTHORIZED IN THIS ROADMAP by a 2-of-2 convergent AI-council pass (2026-08-22), which is a real disposition rather than a dropped item: steps 4.4 and 4.7 are `[-]` cancelled, `--merge` is REMOVED from `/roadmap:process-full` rather than left inert so an archived roadmap leaves no latent executable authority behind a documented switch, and ADR-239 gains a dated Disposition section with an explicit non-rejection clause plus the reopening condition (owner approval AND a target-bound, head-SHA-bound, tamper-resistant, agent-unwritable, kill-switch-subject authorization).\n\nNo offset is taken and none is due: this change disposes of one roadmap and creates none. 5 and 35 are the measured trunk-plus-this-change values and are now the numbers that must walk down."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 4,
+      "later_roadmaps": 55,
+      "open_blockers": 34,
+      "why": "WALKED DOWN by 1 active and 1 blocker. road-to-drain-commands is archived by this branch (under agents/roadmaps/ on main, under agents/roadmaps/archive/ here) and its single blocker merge-authority, open on origin/main, is resolved here -- checked against the trunk rather than taken from the branch's prose. Worth a note given what this run is: merge-authority is the blocker about who may press merge, and it is closed in the same run whose every merge needed a fresh human authorization. later_roadmaps unchanged at 55 and nothing was parked."
+    },
+    {
+      "at": "2026-08-20",
+      "active_roadmaps": 25,
+      "later_roadmaps": 52,
+      "open_blockers": 59,
+      "why": "open_blockers 65 -> 59: all SIX open blockers of road-to-per-turn-hook-economy resolved on the autonomous drain run, every one under AI-council disposition D (decide now; 2/2 quorum, anthropic + openai; record agents/evidence/council/drain-blocker-dispositions-b.md). Four of the six were SPLIT verdicts and each dissent is recorded at its blocker and inline at the step it touches. The trunk recorded the same six answers independently via road-to-estate-drawdown's consolidated decision sheet, and the merge kept both records: the sheet's `Answer: ACCEPTED` line states the choice, this branch's `Resolution` paragraph states what shipped for it. They agree because they read the same council record.\\n\\nRead the -6 honestly, because it hides three different kinds of movement. FOUR were discharged by shipped code: b-stdin-read-failure-policy (a failed payload read now DENIES on a block-capable slot carrying a fail-closed blocking concern, where it previously allowed silently), b-injection-scan-unwrap-security (output contract written first, then the unwrap narrowed against 14 fixtures; restoring the pre-fix extraction fails 11 of them), b-payload-read-parse-dominates (a read-and-exit bench cell that produced the number the roadmap had been assuming: ~70 percent of the large-payload delta is the dispatcher's own read plus parse, 69 and 74 percent over two rounds at --runs 50), and b-stop-async-split-prerequisites' P3 (three state files made safe under concurrent dispatch; pre-fix survival measured against 8 real processes at 3 of 96 log lines, 3 of 24 increments, 1 of 8 rollups). ONE is a decline with no code by design (b-guard-tool-partition, option (c): the zero-dispatch goal is abandoned, the Phase 4 measurement and the in-process tools: filter retained). ONE is a decision to NOT set a number for one release (b-per-turn-composite-bar, option (b)): the composite row stays observe-only and now carries its arming procedure and precondition, so there is still no ceiling on the per-turn cost and that is deliberate rather than forgotten.\\n\\nactive_roadmaps unchanged at 25 and later_roadmaps unchanged at 52, and both are load-bearing rather than incidental. The parent was NOT archived (out of scope for this run) even though its count_open reached 0, so it stays in the active tree. And its three Phase-0 steps were TRANSFERRED rather than cancelled -- to agents/roadmaps/stubs/road-to-per-turn-hook-economy-host-repro.md, which sits under stubs/ and is therefore counted by neither metric. That is the honest shape of a capability-gated transfer: it moves no number, which is exactly why the stub carries the three criteria verbatim, the complete moved list, and a named producer (the reporter of the original slowdown, on their own machine at the version installed when they reported it) with three probes measured on the transfer date as the wrong-machine control -- AGENT_CONFIG_HOOKS_ISOLATED unset, installed 14.6.0, and zero turn-end-gate refusal records against a schema that carries no refusal counter at all."
+    },
+    {
+      "at": "2026-08-20",
+      "active_roadmaps": 25,
+      "later_roadmaps": 52,
+      "open_blockers": 58,
+      "why": "open_blockers 64 -> 58, RE-ANCHORED AT MERGE. Measured at the merged tree rather than taken from either side: main had walked to 64 for its own closures while this branch walked to 59 for the six per-turn-hook-economy decisions, and 58 is what the merged tree actually reads. Adopting one side's number would have claimed a figure describing no tree. Every history entry from both sides is preserved; none was collapsed. The -6 on this branch mixes three kinds of movement and is not six pieces of finished work: four blockers were discharged by shipped code, one was a decline (the guard-tool partition, where the decision is that nothing ships), and one was a decision NOT to set a number (the composite bar, marked observe-only for a release). The transfer of steps 0.1-0.3 moves NO metric at all, because agents/roadmaps/stubs/ is counted by neither active_roadmaps nor open_blockers. Also worth recording rather than deduplicating: the trunk reached the SAME six decisions independently through road-to-estate-drawdown's consolidated decision sheet, because both read the same council record. The merge kept both, so each blocker now carries the sheet's choice and this branch's account of what shipped for it."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 24,
+      "later_roadmaps": 52,
+      "open_blockers": 55,
+      "why": "RE-MEASURED AT MERGE, not argued. Branch drain/road-to-per-turn-hook-economy merged origin/main during the autonomous roadmap-drain run; the trunk had moved (sibling drain PRs archiving roadmaps and resolving blockers in parallel), so neither side's numbers described the merged tree. These values are what `check_estate_count` MEASURED after the merge: {'active_roadmaps': 24, 'later_roadmaps': 52, 'open_blockers': 55}, from {'active_roadmaps': 24, 'later_roadmaps': 52, 'open_blockers': 61}. No part of the drop is attributed to this branch, deliberately: its own earned share is recorded in its roadmap and its PR body, and crediting a parallel session's drawdown to this change is exactly how a ratchet loosens without anyone noticing. Walked DOWN only \u2014 this entry never raises a number, and a lower measurement is the new ceiling."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 23,
+      "later_roadmaps": 52,
+      "open_blockers": 55,
+      "why": "WALKED DOWN by 6 blockers, all on road-to-per-turn-hook-economy and each verified open on origin/main and resolved on this branch rather than taken from the branch's prose: b-per-turn-composite-bar, b-stdin-read-failure-policy, b-guard-tool-partition, b-payload-read-parse-dominates, b-injection-scan-unwrap-security, b-stop-async-split-prerequisites. Two further blockers on the same roadmap (b-payload-mis-nested-readers, b-concern-load-taxes-every-slot) were already resolved on the trunk and are deliberately excluded from the delta. active_roadmaps stays 23 and later_roadmaps 52 on purpose: the roadmap reaches 11/11 done but carries 2 unresolved [~] deferred items, so Iron Law 3 refuses the archive and the regen correctly left it in the active tree. One of those items (4.2) states in its own text that the bar is the maintainer's to pre-register, so resolving them is not an agent call and they were NOT flipped to make the count fall."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 4,
+      "later_roadmaps": 55,
+      "open_blockers": 28,
+      "why": "WALKED DOWN by 6 blockers, all on road-to-per-turn-hook-economy and each verified open on origin/main and resolved here: b-per-turn-composite-bar, b-stdin-read-failure-policy, b-guard-tool-partition, b-payload-read-parse-dominates, b-injection-scan-unwrap-security, b-stop-async-split-prerequisites. Two further blockers on the same roadmap were already resolved on the trunk and are excluded. active_roadmaps stays 4 ON PURPOSE and this is the honest half: the roadmap reaches 11/11 done but carries 2 unresolved [~] items, so Iron Law 3 refuses the archive and the regen left it in the active tree. Item 4.2 states in its own text that the bar is the maintainer's to pre-register, so those boxes were NOT flipped to let the file archive itself. later_roadmaps unchanged at 55."
+    },
+    {
+      "at": "2026-08-22",
+      "active_roadmaps": 4,
+      "later_roadmaps": 55,
+      "open_blockers": 26,
+      "why": "REBASED ONTO THE TRUNK'S LINEAGE (third time on this branch -- main moved through PR #1517, then #1495 and #1523 while this branch was open). main's history is kept whole (100 entries, baseline 4/55/28) and only this branch's delta rides on top, per ADR-239-no-union-merge-for-ratchet-baselines: take main's lineage, re-measure from the tree, never carry the numbers forward.\n\nThis branch's contribution is -2 open blockers, both on road-to-evidence-based-adr-governance: `owner-autonomy-batch` and `authority-coupling-decision`, resolved on a 2-of-2 convergent AI-council pass. Each is closed as `AUTHORITY UNAVAILABLE -- FLOOR PRESERVED` rather than `RE-AFFIRMED (no)` -- the first records an operational act a council may take, the second would assert a policy rejection no owner made. `commit-policy.md:37` and ADR-005 section 1 both remain operative and grade-derived authority stays disabled; the three owner-reserved policy questions are transferred to agents/roadmaps/stubs/road-to-owner-authority-decisions.md with per-question reopening conditions.\n\nactive_roadmaps is unchanged and that is deliberate: the roadmap is NOT archived, because 13 steps remain genuinely open (2.4, 3.4, 4.3, 4.4 and the acceptance criteria). Archiving it to buy the number down would be the silent-green this ledger's own 67 -> 69 entry names as the incentive the ratchet must never create."
+    },
+    {
+      "at": "2026-08-22",
+      "active_roadmaps": 3,
+      "later_roadmaps": 55,
+      "open_blockers": 28,
+      "why": "REBASED ONTO THE TRUNK'S LINEAGE (second time on this branch -- main moved through #1517, then #1495 and #1523, while this branch waited on review). main's history is kept whole and only this branch's delta rides on top, per ADR-239-no-union-merge-for-ratchet-baselines: take main's lineage, re-measure from the tree, never carry the numbers forward.\n\nThis branch's contribution is -1 active, earned by closing `road-to-condensed-link-repair` (6 done / 1 cancelled-as-null / 0 open / 0 deferred) and archiving it. open_blockers is unchanged: this roadmap carried none.\n\nThe cancelled item is AC-2, closed as an HONEST NULL rather than weakened -- it required both links to resolve in `src/` AND in the projection, and `docs/` exists in neither tree, so no implementation satisfies it. Replacement criterion AC-2R was approved by the same 2-of-2 AI-council ruling and is met. AC-3 was held deferred until workflow run 32546466190 proved the newly wired `check-condensed-paths` step ran green remotely -- closed on the observed run, not on the wiring.\n\nNo offset taken and none due: one roadmap disposed, none created."
+    },
+    {
+      "at": "2026-08-21",
+      "active_roadmaps": 3,
+      "later_roadmaps": 55,
+      "open_blockers": 26,
+      "why": "WALKED DOWN by 1 active and nothing else: road-to-condensed-link-repair is archived by this branch (under agents/roadmaps/ on main, under agents/roadmaps/archive/ here). open_blockers unchanged at 26 and later_roadmaps unchanged at 55 \u2014 nothing was parked and no blocker moved, so the drawdown is the archival alone and is not padded with a closure this change did not earn."
+    },
+    {
+      "at": "2026-08-22",
+      "active_roadmaps": 4,
+      "later_roadmaps": 55,
+      "open_blockers": 26,
+      "why": "NET ZERO, and the number is MEASURED against the merged tree rather than carried from either side. road-to-single-rule-layer was authored AND archived in this same change, so it never joins the active estate: it opened at 7 on this branch's base, origin/main independently walked the floor to 4 active and 28 open blockers while this branch was being built, and the merged tree measures both because the roadmap this branch added is in archive/. Re-anchored at the second merge per ADR-239: main's lineage is kept whole (100 entries) and only this branch's delta rides on top, measured from the tree rather than carried from either side. An earlier revision of this entry recorded 'GREW by 1 active' and was true only between the roadmap landing and its closure hours later \u2014 leaving it would have raised a floor nothing in the tree justifies, which is the silent-give-back this ratchet exists to refuse. What the change did to the estate is nothing; what it did to the repository is close a live ADR-236 regression on four of five hosts."
     }
   ],
   "target": {

package/src/config/evaluator-budgets.json

@@ -58,11 +58,11 @@
       "deterministic": false
     },
     "cli_help_command_count": {
-      "max": 101,
-      "last_measured": 101,
+      "max": 102,
+      "last_measured": 102,
       "last_measured_at": "2026-08-19",
       "method": "registry enumeration — count of `{ name: '...', disposition` entries in src/cli/registry.ts (NOT --help prose parsing; methods historically disagreed 74 vs 76 vs 79)",
-      "baseline_note": "80 → 81 on 2026-08-03 (release 9.15.0 gate). This RECORDS growth that already shipped through its own reviewed PR; it does not authorize new surface. The +1 is f02db54c2 (fix(cli): register routing:doctor in the CLI registry) — the command existed, only its registry entry was missing, and the registering PR did not move this budget. The gate did its job again: breach WARNS on main and BLOCKS on release, which is the conscious-decision point rather than a silently raised cap. Re-measured 2026-08-03 via the pinned method: 81. Headroom stays zero by design — the next registry addition must move this number in its own PR. 81 → 82 on 2026-08-04: the `handoff` subcommand (road-to-agent-handoff-resume Phase 4) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 82. 82 → 84 on 2026-08-04: the `route:explain` + `route:audit` verbs (routing-correctness validation surface) register in the same PR that adds the surface. Re-measured via the pinned method: 84. 84 → 85 on 2026-08-05: the `settings:set` verb (road-to-zero-ceremony-settings Phase 2 — the one agent-reachable settings writer) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 85. 85 → 86 on 2026-08-06: the `conformance:behavior` verb (road-to-agent-behavior-conformance Phase 5 — replays the local transcript store through the four mechanised conformance checks) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 86. 86 → 88 on 2026-08-07: the `sessions:list` + `sessions:claim` verbs (road-to-parallel-session-coordination — the shell surface of the shared session register, needed because /roadmap:next is command markdown and can only reach the register through a shell call) register in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 88. 88 → 89 on 2026-08-08: the `council:status` verb registers in the same PR that adds the surface, per this record's own contract. It exists because an agent in a consumer project announced \"kein Council konfiguriert (keine .agent-settings.yml)\" and substituted a weaker path while the council was configured user-globally the whole time — there was no verb that answered availability, so the only route was an inference from a filename, and the intuitive filename is the one location ADR-104 guarantees is never consulted. Re-measured via the pinned method: 89. 89 → 91 on 2026-08-08: the `self-repair:status` + `self-repair:release` verbs (the queued-defect reader and the single Hard-Floor-gated outward step of the self-repair loop — the loop is deliberately unable to publish unless a human runs the release command) register in the same PR that adds the surface, per this record's own contract. Landed alongside the +1 council:status move in the same branch. Re-measured via the pinned method: 91. 91 → 94 on 2026-08-08: the `packs:active`, `settings:get` and `mcp:available` verbs (road-to-capability-answerability Phase 2 — the three capability probes for the gaps that had none) register in the same PR that adds the surface, per this record's own contract. Each answers a question that was previously only inferable from a filename: which packs are active and from which file, what a setting resolves to and which file set it, and what is declared in mcp.json versus what can actually launch. 94 -> 95 in the same PR: `brand:status` (Phase 2.4 — brand-layer presence, which the rule depended on and no surface could answer). Re-measured twice via the pinned method on the unchanged tree: 95/95. 95 → 96 on 2026-08-10: the `session:recycle` verb (road-to-token-economy-recycling Phase 2.2 — the deterministic producer of the main-session recycle envelope; the recycle advisory names this exact verb, so it must exist as a shell surface) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 96. 96 -> 97 on 2026-08-10: the `gates` verb registers in the same PR that adds the surface, per this record's own contract. It exists because the blocker fields the dashboard already parses (Owner, What to do, Resolved when — CI-enforced by lint_roadmap_blockers) had no owner-filtered reader: the dashboard counts the open blockers across a 600-line file and links each to a per-roadmap anchor, so \"which of these are mine\" was a manual read of every anchor. The same inference-from-a-filename shape as the council:status entry above, one layer up. This branch and the session:recycle branch each measured 96 independently and landed on the same number for different verbs; the merge makes it 97, re-measured twice via the pinned method on the merged tree: 97/97. 97 -> 98 on 2026-08-15: the `workspace:doctor` verb (road-to-inbox-harvest-2026-08-c-workspace-identity Phase 3 — the read-only report over the new `workspaceIdentity()` resolver) registers in the same PR that adds the surface, per this record's own contract. It exists for the same inference-from-a-filename shape as the council:status and gates entries above, one layer down: the tree answered \"where am I\" in eight ad-hoc places across six files, and the 12.0.0 span shipped the same worktree misclassification twice, so no verb could be asked which checkout is the main one. Read-only by construction — the roadmap's Non-goals put worktree disposal out of scope and its Risk 3 names \"the pressure read becomes a disposal path by accident\" as the failure to design against, so the command carries no --fix and no --prune. Re-measured twice via the pinned method on the unchanged tree: 98/98. 98 -> 99 on 2026-08-17: the `council:quota` verb (road-to-council-quota-accounting-truth Phase 2) registers in the same PR that adds the surface, per this record's own contract. Exactly the inference-from-a-filename shape as the council:status entry above, one layer down: `cmd_quota` had existed in council_cli.ts and been reachable only via `scripts-run`, so the documented recovery path for an exhausted shared counter -- read the usage, reset one provider -- did not resolve through `agent-config`, and an operator debugging a quota failure met `unknown command`. The verb is read-only apart from the pre-existing `--reset <provider>`, which already required `--confirm`. Re-measured twice via the pinned method on the unchanged tree: 99/99. 99 -> 100 on 2026-08-19: the `decision:memo` verb (road-to-long-horizon-execution Phase 2.2, sequencing UOTL Phase 4.3 -- the decision-memo channel) registers in the same PR that adds the surface, per this record's own contract. It exists because the question ladder gained a rung between \"halt and ask\" and \"decide silently\": a resolution the run makes without contacting the operator is only legitimate if it is reviewable afterwards, and there was no surface that wrote such a record with a fixed shape. Write-and-list only, local-only (agents/runtime/ is gitignored), and it gates nothing -- the locked decision classes are refused at the config schema, never in the ledger. 100 -> 101 in the same PR: `run:supervise` (Phase 3.1 -- the out-of-process watcher for runs whose session died with open steps left). It is the operator-facing half of session continuity: nothing anywhere had the job of noticing that a claimed run stopped moving, so a roadmap 40% done and a roadmap finished looked identical from outside the dead session. Report-only by default and it NEVER merges, pushes or closes -- the auto-merge the reference design carries is a named rejection in the roadmap's harvest section, not an unbuilt feature. Re-measured twice via the pinned method on the unchanged tree: 101/101."
+      "baseline_note": "80 → 81 on 2026-08-03 (release 9.15.0 gate). This RECORDS growth that already shipped through its own reviewed PR; it does not authorize new surface. The +1 is f02db54c2 (fix(cli): register routing:doctor in the CLI registry) — the command existed, only its registry entry was missing, and the registering PR did not move this budget. The gate did its job again: breach WARNS on main and BLOCKS on release, which is the conscious-decision point rather than a silently raised cap. Re-measured 2026-08-03 via the pinned method: 81. Headroom stays zero by design — the next registry addition must move this number in its own PR. 81 → 82 on 2026-08-04: the `handoff` subcommand (road-to-agent-handoff-resume Phase 4) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 82. 82 → 84 on 2026-08-04: the `route:explain` + `route:audit` verbs (routing-correctness validation surface) register in the same PR that adds the surface. Re-measured via the pinned method: 84. 84 → 85 on 2026-08-05: the `settings:set` verb (road-to-zero-ceremony-settings Phase 2 — the one agent-reachable settings writer) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 85. 85 → 86 on 2026-08-06: the `conformance:behavior` verb (road-to-agent-behavior-conformance Phase 5 — replays the local transcript store through the four mechanised conformance checks) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 86. 86 → 88 on 2026-08-07: the `sessions:list` + `sessions:claim` verbs (road-to-parallel-session-coordination — the shell surface of the shared session register, needed because /roadmap:next is command markdown and can only reach the register through a shell call) register in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 88. 88 → 89 on 2026-08-08: the `council:status` verb registers in the same PR that adds the surface, per this record's own contract. It exists because an agent in a consumer project announced \"kein Council konfiguriert (keine .agent-settings.yml)\" and substituted a weaker path while the council was configured user-globally the whole time — there was no verb that answered availability, so the only route was an inference from a filename, and the intuitive filename is the one location ADR-104 guarantees is never consulted. Re-measured via the pinned method: 89. 89 → 91 on 2026-08-08: the `self-repair:status` + `self-repair:release` verbs (the queued-defect reader and the single Hard-Floor-gated outward step of the self-repair loop — the loop is deliberately unable to publish unless a human runs the release command) register in the same PR that adds the surface, per this record's own contract. Landed alongside the +1 council:status move in the same branch. Re-measured via the pinned method: 91. 91 → 94 on 2026-08-08: the `packs:active`, `settings:get` and `mcp:available` verbs (road-to-capability-answerability Phase 2 — the three capability probes for the gaps that had none) register in the same PR that adds the surface, per this record's own contract. Each answers a question that was previously only inferable from a filename: which packs are active and from which file, what a setting resolves to and which file set it, and what is declared in mcp.json versus what can actually launch. 94 -> 95 in the same PR: `brand:status` (Phase 2.4 — brand-layer presence, which the rule depended on and no surface could answer). Re-measured twice via the pinned method on the unchanged tree: 95/95. 95 → 96 on 2026-08-10: the `session:recycle` verb (road-to-token-economy-recycling Phase 2.2 — the deterministic producer of the main-session recycle envelope; the recycle advisory names this exact verb, so it must exist as a shell surface) registers in the same PR that adds the surface, per this record's own contract. Re-measured via the pinned method: 96. 96 -> 97 on 2026-08-10: the `gates` verb registers in the same PR that adds the surface, per this record's own contract. It exists because the blocker fields the dashboard already parses (Owner, What to do, Resolved when — CI-enforced by lint_roadmap_blockers) had no owner-filtered reader: the dashboard counts the open blockers across a 600-line file and links each to a per-roadmap anchor, so \"which of these are mine\" was a manual read of every anchor. The same inference-from-a-filename shape as the council:status entry above, one layer up. This branch and the session:recycle branch each measured 96 independently and landed on the same number for different verbs; the merge makes it 97, re-measured twice via the pinned method on the merged tree: 97/97. 97 -> 98 on 2026-08-15: the `workspace:doctor` verb (road-to-inbox-harvest-2026-08-c-workspace-identity Phase 3 — the read-only report over the new `workspaceIdentity()` resolver) registers in the same PR that adds the surface, per this record's own contract. It exists for the same inference-from-a-filename shape as the council:status and gates entries above, one layer down: the tree answered \"where am I\" in eight ad-hoc places across six files, and the 12.0.0 span shipped the same worktree misclassification twice, so no verb could be asked which checkout is the main one. Read-only by construction — the roadmap's Non-goals put worktree disposal out of scope and its Risk 3 names \"the pressure read becomes a disposal path by accident\" as the failure to design against, so the command carries no --fix and no --prune. Re-measured twice via the pinned method on the unchanged tree: 98/98. 98 -> 99 on 2026-08-17: the `council:quota` verb (road-to-council-quota-accounting-truth Phase 2) registers in the same PR that adds the surface, per this record's own contract. Exactly the inference-from-a-filename shape as the council:status entry above, one layer down: `cmd_quota` had existed in council_cli.ts and been reachable only via `scripts-run`, so the documented recovery path for an exhausted shared counter -- read the usage, reset one provider -- did not resolve through `agent-config`, and an operator debugging a quota failure met `unknown command`. The verb is read-only apart from the pre-existing `--reset <provider>`, which already required `--confirm`. Re-measured twice via the pinned method on the unchanged tree: 99/99. 99 -> 100 on 2026-08-19: the `decision:memo` verb (road-to-long-horizon-execution Phase 2.2, sequencing UOTL Phase 4.3 -- the decision-memo channel) registers in the same PR that adds the surface, per this record's own contract. It exists because the question ladder gained a rung between \"halt and ask\" and \"decide silently\": a resolution the run makes without contacting the operator is only legitimate if it is reviewable afterwards, and there was no surface that wrote such a record with a fixed shape. Write-and-list only, local-only (agents/runtime/ is gitignored), and it gates nothing -- the locked decision classes are refused at the config schema, never in the ledger. 100 -> 101 in the same PR: `run:supervise` (Phase 3.1 -- the out-of-process watcher for runs whose session died with open steps left). It is the operator-facing half of session continuity: nothing anywhere had the job of noticing that a claimed run stopped moving, so a roadmap 40% done and a roadmap finished looked identical from outside the dead session. Report-only by default and it NEVER merges, pushes or closes -- the auto-merge the reference design carries is a named rejection in the roadmap's harvest section, not an unbuilt feature. Re-measured twice via the pinned method on the unchanged tree: 101/101. 101 → 102 on 2026-08-22: the `adr:effective` verb (road-to-evidence-based-adr-governance step 2.2 — the effective-state projection over one decision record) registers in the same PR that adds the surface, per this record's own contract. It exists because current truth about an ADR was only reconstructable from linear prose: an agent had to read the body, then every amendment, and decide for itself which clauses still stand. The verb reports status, the Decision verbatim, clauses the record's own amendments superseded, active amendments, the three descriptive axes and the review-trigger state. It AUTHORIZES NOTHING — Phase 2 of that roadmap is titled \"surfacing only; no authority\" and its AC-7 forbids any authority consequence, so the verb reports an absent axis as absent (`— (no provenance axis)`, `— (ungraded)`, `absent → evidence`) and an unresolvable trigger as `indeterminate` rather than inferring one. Re-measured twice via the pinned method on the unchanged tree: 102/102."
     },
     "mcp_public_tool_count": {
       "max": 20,