@event4u/agent-config 14.8.0 → 14.10.0

package/src/config/gate-violation-baselines.json

@@ -1,76 +1,76 @@
 {
-  "$comment": "Violation ratchet for gates whose dead scan root was repaired. A repair REVEALS pre-existing debt; it does not create it. Each entry records the count revealed at repair time \u2014 the gate fails only when its count RISES. Lowering a count is a normal commit; raising one is a defect. Entries expire: a baseline that has not dropped within 56 days of `landed` (or of `reaffirmed.date`) fails its gate, because a number that never moves is suppression with extra steps. Mechanism + rationale: src/scripts/_lib/gate_baseline.ts. Decision: AI council 2026-08-02, roadmap road-to-gates-that-can-fail blocker `dead-gate-finding-triage`.",
-  "gates": {
-    "audit_user_type_axis": {
-      "count": 1,
-      "landed": "2026-08-02",
-      "note": "One orphan user-type value: `legal`. Five legal-review-prep skills (contract-review, dpa-review, nda-triage, legal-intake-triage, legal-practice-profile) declare `recommended_for_user_types: [legal]`, but there is no `user-types/legal.yml` \u2014 the pack shipped an axis value with no user-type definition behind it, and the dead scan root hid it (the audit reported used=0 orphans=0 while reading zero skills; it now reads 288 and reports used=8). Clearing this entry is a product call, not a copy edit: either author `user-types/legal.yml` (tagline, recommended packs, install-path hint) or drop `legal` from those five skills. Not decided here because both options change shipped pack behaviour."
+    "$comment": "Violation ratchet for gates whose dead scan root was repaired. A repair REVEALS pre-existing debt; it does not create it. Each entry records the count revealed at repair time \u2014 the gate fails only when its count RISES. Lowering a count is a normal commit; raising one is a defect. Entries expire: a baseline that has not dropped within 56 days of `landed` (or of `reaffirmed.date`) fails its gate, because a number that never moves is suppression with extra steps. Mechanism + rationale: src/scripts/_lib/gate_baseline.ts. Decision: AI council 2026-08-02, roadmap road-to-gates-that-can-fail blocker `dead-gate-finding-triage`.",
+    "gates": {
+        "audit_user_type_axis": {
+            "count": 1,
+            "landed": "2026-08-02",
+            "note": "One orphan user-type value: `legal`. Five legal-review-prep skills (contract-review, dpa-review, nda-triage, legal-intake-triage, legal-practice-profile) declare `recommended_for_user_types: [legal]`, but there is no `user-types/legal.yml` \u2014 the pack shipped an axis value with no user-type definition behind it, and the dead scan root hid it (the audit reported used=0 orphans=0 while reading zero skills; it now reads 288 and reports used=8). Clearing this entry is a product call, not a copy edit: either author `user-types/legal.yml` (tagline, recommended packs, install-path hint) or drop `legal` from those five skills. Not decided here because both options change shipped pack behaviour."
+        },
+        "check_depth_budget": {
+            "count": 4,
+            "landed": "2026-08-06",
+            "note": "Four depth files exceed the 16,000-char per-file ceiling: rule-body-migration-inventory.md (23,782), design-antipatterns.md (20,707), roadmap-process-loop.md (20,360), orchestration-telemetry.md (16,155). Recorded rather than fixed because splitting four large reference documents is unrelated to the change that introduced the ceiling, and a gate that lands as four instant blockers is the shape this repository has already recorded as a failure. Shrink-only from here: a FIFTH over-ceiling file reds. roadmap-process-loop.md is the file that motivated the gate \u2014 it states 'Size budget: <= 4,000 chars' in its own header and is 5x over it, which is what a declared budget with nothing measuring it decays into. The ceiling is a GROWTH RATCHET, not a measured quality threshold: the 7,308-trajectory study behind the 3,500-token skill ceiling (ADR-217) was taken on procedural always-co-loaded skills, and this layer is declarative and loaded one or two files at a time. Replace the number when someone measures comprehension on THIS layer."
+        },
+        "check_gate_completeness": {
+            "count": 215,
+            "landed": "2026-08-17",
+            "note": "Ledger adoption ratchet. Gates registered under the CI task roots that carry neither per-target completeness accounting (`_lib/gate_ledger.ts`) nor a `// ledger-exempt:` marker. This is deliberately NOT a sweep: road-to-skill-ecosystem-gate-integrity Phase 1 adopts exactly three gates (lint_framework_leakage, check_references, lint_roadmap_complexity) plus the checker itself to prove the interface, and the remainder migrates as gates are touched. Shrink-only from here \u2014 the number may not grow, so a NEW gate must adopt or exempt. Lowered 216 -> 215 on 2026-08-17 by discharging the obligation three NEW arrivals had incurred, which is the standing rule being enforced rather than a drain: the registered population grew 244 -> 258 and three of the fourteen arrivals adopted nothing \u2014 `build_archive_index`, `check_gate_coverage`, `check_pr_ci_current`. The reading was 218 against this baseline of 216, and the missing arithmetic is that one PRE-existing gate (`lint_rule_skill_pack_reach`) had adopted in the meantime: 216 + 3 - 1 = 218. All three adopted a real ledger. `check_pr_ci_current` first took a reasoned exemption claiming no target population; the completion review refuted it from the file itself \u2014 the check rows ARE a population, and rows whose `state` is not a string were being dropped before any verdict ran, so a dropped row could be the failing one. The exemption was withdrawn and the ledger adopted, counting kept rows as read, dropped rows as skips, and rows a pre-row verdict never reached as out of scope. The denominator in this note was 14 stale (it said 244) and is now expressed without one, because a count pinned to a population that grows weekly rots faster than the count itself. Note what this lowering does NOT buy: headroom is zero either way, so the next un-adopted arrival reds this gate immediately \u2014 which is the intended behaviour and the reason the number is not padded. The refreshed `landed` is load-bearing rather than bookkeeping: `checkRatchet` returns `improved` BEFORE it evaluates staleness, so an entry left at 216 while the tree measures 215 would never expire at any age (pinned by tests/lib/gate_baseline.test.ts, which asserts `improved` at landed + STALE_AFTER_DAYS + 400 days) \u2014 the greenest available state and the worst, since it switches off the anti-fossilization clause exactly when someone has done real work.",
+            "falsifier": "./scripts-run src/scripts/check_gate_completeness"
+        },
+        "check_no_new_legacy_path:hardcoded-scan-roots": {
+            "count": 47,
+            "landed": "2026-08-13",
+            "note": "Lines under src/scripts/**/*.{ts,mts,mjs} that pass the retired `.agent-src.uncondensed` directory into `path.join(...)` \u2014 a filesystem path CONSTRUCTED against the tree ADR-051 abandoned, which is the exact shape of all 14 dead gates. Deliberately narrow so the number is signal, not noise: 236 raw mentions under src/scripts \u2192 147 string-literal lines \u2192 67 path-constructing lines when the pass was written, after exempting src/scripts/_lib/agent_src.ts (the shared resolver, whose job IS owning the constant \u2014 gates that route through it survived the move). Detectors holding the literal as data to match, strip, or print are not counted, and no prose, docs, tests or fixtures are read: that full-tree shape was measured at 44 files / 213 hits and rejected as the wrong lint (see the note in check_no_new_legacy_path.ts::find_offenders). Recorded at 58 rather than 67 because Phase 1's scan-root repairs were landing on this branch while the pass was being written and had already removed 9 \u2014 a baseline above the truth silently permits new violations. This count goes to ZERO as the remaining repairs land; every repair is a lowering commit. Lowered 56\u219251 by the road-to-renewal-foundation Phase 1 dead-root sweep (check_always_budget, check_portability, check_references, lint_framework_leakage, lint_agents_md). Lowered 51\u219249 by the gate-hardening adoption PR: skill_collision_clusters and skill_overlap were repointed at the live skills tree via the shared resolver \u2014 two gates that had been reading the retired container and scoring 0 of 288 skills. Lowered 49\u219248 by road-to-rule-delivery-integrity P2.2: score_skill_selection was repointed at the live skills tree via the shared resolver. It is the same shape as the two gates lowered before it \u2014 a scorer reading the retired container and scoring 0 of 288 skills \u2014 and here the consequence was sharper than a dead gate: the roadmap's pre-registered selection-accuracy criteria would have been compared against a baseline of silent zeros. Lowered 48\u219247 on 2026-08-13, and this one is a catch-up rather than a repair: the pass reported 47 against a baseline of 48, so a gain had already landed without the ratchet following it. Attributed to 455160160 (fix(evals): resolve the eval orchestrator against the live skills tree), the most recent repair in this branch's base that removes a path-constructing line \u2014 SKILLS_ROOT repointed through _lib/agent_src.ts::SRC_SKILLS(). A loose ratchet is not harmless: it silently permits one new violation to be added back without any gate noticing, which is the shape this entry exists to prevent."
+        },
+        "check_source_size_budget": {
+            "count": 19363,
+            "landed": "2026-08-22",
+            "note": "Lowered 19,395 -> 19,363 on 2026-08-22 by road-to-council-seat-selection, and the -32 is the residue of a LOWERING THROUGH EXTRACTION that had to pay for its own feature first. The branch adds the verified_at member stamp and the check_council_pin_staleness gate, whose 74 new lines landed in two files already far above the ceiling -- ai_council/config.ts (+63, at 2,272) and ai_council/clients.ts (+11, at 2,862). This gate refused it, correctly, and the debt could not be paid out of the additions themselves: of the 63 only a ~48-line validation block is a movable unit, and the 11 are a comment on a one-line constant. So the payment came from the cleanest pre-existing unit in the same file -- the already-labelled, already-self-contained 'Python-format helpers' section (114 lines) moved whole to ai_council/py_format.ts, which config.ts now imports. Net -32 past zero rather than exactly to it, because the section is a section and splitting it to hit a number would leave a worse file than moving it.",
+            "falsifier": "./scripts-run src/scripts/check_source_size_budget --quiet"
+        },
+        "ci-parity:local-only": {
+            "count": 165,
+            "landed": "2026-08-13",
+            "note": "Gates that `task ci` runs and no workflow does \u2014 the direction this manifest's own header calls the one that let real defects merge (16 stale index rows reached the trunk behind a local-only check-index). Revealed, not created, by repairing the checker's extraction: check_ci_local_parity built its CI-side set by regexing RAW workflow text for `task <name>` and expanding each closure, comments included. Several workflow comments contain the literal string `task ci` while stating that no workflow invokes it, so `ci` was read as an invocation and its full 247-gate closure entered the 'runs in CI' set. The count was therefore 0 BY CONSTRUCTION, and the prose documenting the gap was what suppressed it. Measured at the repair: CI-side 273 \u2192 106, undeclared_local_only 0 \u2192 167 of 247 local gates (68%). Baselined rather than hard-failed because 167 findings nobody can clear in the change that reveals them is the gate-that-lands-as-N-instant-blockers failure this repository has refused before; shrink-only keeps the property that matters, namely that a NEW gate registered in `task ci` with no workflow reds immediately. Lowering happens by wiring gates into workflows or declaring them under `local_only:` with a reason. Note the punchline, because it bounds the risk of this entry: check_ci_local_parity ITSELF runs in no workflow, so it is its own finding and this ratchet has no remote reach either \u2014 clearing the backlog is what gives it teeth. DRAINED BY ONE, 2026-08-13: check_ci_local_parity itself was wired into consistency.yml, so it left the set it exists to report. That is the whole shape of a legitimate drain here \u2014 the gate stops being local-only because a workflow now runs it, not because the declaration list grew. The floor in gate-coverage.yml moved in the same change and for the same reason: wiring two gates raised the parsed population 357 -> 360 (109 CI + 251 local). The intermediate 359 was the reading after the CI-side wiring alone and before check_gate_coverage joined the local `ci` chain; it was committed here by mistake and is corrected rather than left as a second number for the same measurement. WALKED DOWN 166 -> 165 on 2026-08-20 (road-to-session-closeout 5.2): check_ci_local_parity reported `ci-parity:local-only: 165 violation(s), baseline 166 - ratchet is loose` and asked for exactly this, so the gain cannot be silently given back. The measurement is the gate's own output on the merged tree, not a branch. What is NOT done here is the classification the same step asks for: 165 gates each need a recorded class (belongs-in-CI / developer-aid / dead), which is per-gate judgement, and migrating them would red the trunk on the landing day - the step forbids it for that reason.",
+            "falsifier": "./scripts-run src/scripts/check_ci_local_parity"
+        },
+        "gate-self-test:registered-non-adopters": {
+            "count": 24,
+            "landed": "2026-08-06",
+            "note": "Self-test adoption ratchet, expressed as a shrink-only NON-adopter count. 24 of the 32 gates registered enforced in gate-coverage.yml carry neither a `--self-test` (`_lib/gate_self_test.ts`) nor a `// self-test-exempt: <reason>` marker, so nothing proves they DISCRIMINATE \u2014 an enforced `scanned:` floor proves a gate read something, only a self-test proves the reading changes the verdict. Deliberately NOT an adoption column ratcheted upward: check_gate_coverage.ts's own report_hardening_ratchet rejects that shape in this same file (\"grades the solution instead of the problem\"), and the sibling adoption ratchet (check_gate_completeness) is already a non-adopter count. Population is the manifest, not every script under src/scripts: padding the manifest to move this number would mean adding a floor per row. Shrink-only from here \u2014 a NEW registered gate must adopt or exempt. Migration mechanism, same as the ledger ratchet above: gates adopt as they are touched, not in a sweep \u2014 the eight current adopters were each added alongside a real change to that gate. The 56-day non-stagnation clause applies unchanged, so a count parked here fails on its own.",
+            "falsifier": "./scripts-run src/scripts/check_gate_coverage"
+        },
+        "lint_handoffs": {
+            "count": 18,
+            "landed": "2026-08-02",
+            "note": "All 18 are `handoff_tier_mismatch`: a senior-tier skill links to a peer whose frontmatter carries no `tier` (reported as tier='unset') \u2014 e.g. build-buy-partner \u2192 adr-create, customer-research \u2192 po-discovery, gated-reach \u2192 threat-modeling. This is a tier-metadata backfill backlog on the LINKED-TO skills, not a broken link. The one genuinely dangling link revealed by the same repair (competitive-positioning \u2192 a non-existent ../analyze-reference-repo/SKILL.md; it is a command, not a skill) was FIXED in the repairing commit rather than baselined. Clearing this entry means backfilling `tier` on the linked-to skills, or deciding that `tier: unset` on a link target is not a violation and narrowing the rule."
+        },
+        "lint_pack_boundaries": {
+            "count": 337,
+            "landed": "2026-08-02",
+            "note": "Markdown links between source artefacts that cross a pack boundary the source pack's `requires` graph does not reach \u2014 revealed when the scan root moved off the deleted packages/ tree to the live corpus (0 -> 753 artefacts scanned). 82 distinct pack pairs across 131 source files; largest single class is engineering-base -> meta (73), skills in a consumer-installable pack citing this package's own maintenance skills. Each is a link that dangles for a consumer who installs the source pack without the target's. Judged real drift rather than an over-strict gate because it is long-tailed \u2014 top bucket 22%, no single systematic cause \u2014 unlike the lint_artefact_frontmatter case, where one required shape had 0-of-288 adoption. Fix per finding: add the edge to packs.yml requires, retarget the link, or move the artefact."
+        },
+        "lint_provenance_vocabulary:permanence-language": {
+            "count": 5,
+            "landed": "2026-08-22",
+            "note": "Permanence language in an ADR record's load-bearing positions -- its `# ` title, its `decision:` frontmatter slug, its `## Decision` section, or an `Addendum` heading. Revealed by adding rule 4 to lint_provenance_vocabulary, not created by it: ADR-240 section 6 states the doctrine (`forever`, `permanently`, `never revisit`, `never reconsider` and their kin do not belong in a mechanism decision's title, slug or Decision section) and the corpus had five records violating it on the day the rule landed. Baselined rather than hard-failed because a gate that lands as five instant blockers is the shape this repository has already refused (see ci-parity:local-only and lint_roadmap_blockers:decidability above), and every one of the five is a content decision rather than a copy edit: ADR-208 (slug `dist-agent-src-keep-forever`, title \"kept forever\", Decision \"KEEP -- permanently\") is the standing self-contradiction ADR-240 cites, since lines 10-11 of its own frontmatter carry the conditions under which it should be reopened; ADR-107:37 and ADR-108:5/12/24/29 are owner PURPOSE statements (\"open-source forever\", \"now or in the future\", \"liability disclaimer is permanent\") whose fix is the escape ADR-240 names -- record `authority_basis: owner_intent` -- which is an owner ruling, not an agent edit; ADR-122:77/154 and ADR-124:229 assert a permanently-off default whose honest form is a default-off setting plus a reopen condition. The rule is deliberately SCOPED and the scoping is the gate: the same word list applied to whole files matches many more, and the large majority are legitimate. The comparison figure is given with its method because 'unscoped' has two readings and an earlier version of this note picked one without saying which, giving 41 lines across 30 records which reproduces neither way: the bare word list over both ADR surfaces matches 45 lines in 26 records, and the word list PLUS the lint's own line filters (code fences, quoted spans, table rows, in-sentence negation, attributive `permanent`, hyphen compounds) but WITHOUT position scoping matches 29 in 17. Scoping to the four load-bearing positions takes it to 11 in 5. The 29-to-11 step is what the scoping buys; the 45 is what a naive grep would report -- an `## Alternatives considered` entry rejecting a permanence option (ADR-105:97, ADR-137:148-151, ADR-212:133), a `## Consequences` line reporting one (ADR-136:90, ADR-208:73, ADR-216:278/298), a `## Context` recounting one (ADR-042:36, ADR-232:34), a quoted open question (ADR-201:342/343) and a table rationale cell bounding a failure mode (ADR-074:41, ADR-225:64) are all describing a permanence claim rather than making one. Shrink-only from here, which is the property that matters: a NEW record asserting permanence in any of the four positions reds this gate immediately, and headroom is zero. Lowering happens one record at a time -- convert an owner purpose statement to `authority_basis: owner_intent`, or restate a mechanism decision with the reopen condition it already carries. The 56-day expiry is the point rather than a hazard: if this number has not moved in two months, the doctrine is not being applied and the gate should fail until someone decides whether it is real.\n\nWALKED 11 -> 5 on 2026-08-22 by road-to-evidence-based-adr-governance 4.3, and the split is exactly the one this note predicted: the six AGENT-EXECUTABLE hits are fixed and the five OWNER-RESERVED ones are untouched. ADR-208's slug is now `dist-agent-src-is-the-shipped-projection-tree`, its title says \"until its `review_trigger` fires\", and its Decision reads \"KEEP, until `review_trigger` (a), (b) or (c) fires\" -- the escape ADR-240 section 6 names, taken against reopen conditions the record's own frontmatter already carried, which is why it needed no new judgement. ADR-122:77/154 and ADR-124:229 asserted a permanently-off default; each now states default-off plus the reopen condition its own measurement supplies (for ADR-122, a re-run clearing both locked thresholds with the FP control held; for ADR-124, the category limit behind the null being shown not to hold). Those two carry no `review_trigger` at all -- both predate the 2026-07-25 requirement -- so the condition was derived from the measurement in the record rather than restated from frontmatter, and that difference is recorded because it is the weaker of the two moves. The FILE NAME of ADR-208 is deliberately unchanged: no gate couples the `decision:` slug to the filename (regenerate_index reads the slug only as a fallback when `decision:` is absent), and renaming would rewrite eight inbound references, two of them inside frozen review-input diffs and one inside an archived roadmap whose path was correct when written -- rewriting history to fix a name, which is the trade this tree already refused for out-of-directory decision records. The remaining five are ADR-107:37 and ADR-108:5/12/24/29, owner PURPOSE statements whose fix is `authority_basis: owner_intent`; they are routed to stubs/road-to-owner-authority-decisions.md and are not agent-editable. Zero headroom still holds for the four load-bearing positions.",
+            "falsifier": "./scripts-run src/scripts/lint_provenance_vocabulary"
+        },
+        "lint_settings_classes:derivable-surface": {
+            "count": 83,
+            "landed": "2026-08-12",
+            "note": "Anti-regrowth ratchet for the settings disposition axis. 83 of 134 template leaves are classified `derivable` \u2014 the mechanism can decide from the situation, so the key should not exist \u2014 and each names the replacement that would decide instead (`lint_settings_classes` rejects the bare label, which is what keeps the class from becoming a synonym for \"inconvenient to keep\"). This is a DELETION QUEUE, not 83 deletions: a row stays until the mechanism it names actually exists, and deleting a key ahead of its mechanism is a silently-changed default rather than a simplification. Shrink-only from here, which is the anti-regrowth half \u2014 a NEW key classified `derivable` raises the number and reds, so a key whose answer the situation already carries cannot be added at all. The 56-day non-stagnation clause is the other half and is wanted here rather than tolerated: a queue that never drains is a stated direction nobody is walking. The queue opened at 88 of 140 on 2026-08-12 and drained to 83 of 134 the same day: six keys had no reader whatsoever (telegraph.speak_scope, chat_history.max_size_kb, chat_history.on_overflow, quality.wait_for_remote_ci, screenshots.data_bearing_gate, legal_review_prep.consented_at), five of them `derivable` and one a `consent` row reclassified because a published-egress confirmation is a Hard Floor no setting may lift. An unread key is the only deletion that cannot silently change a default, which is why that batch went first. The classification itself is docs/contracts/settings-classes.md.",
+            "falsifier": "./scripts-run src/scripts/lint_settings_classes"
+        }
     },
-    "check_depth_budget": {
-      "count": 4,
-      "landed": "2026-08-06",
-      "note": "Four depth files exceed the 16,000-char per-file ceiling: rule-body-migration-inventory.md (23,782), design-antipatterns.md (20,707), roadmap-process-loop.md (20,360), orchestration-telemetry.md (16,155). Recorded rather than fixed because splitting four large reference documents is unrelated to the change that introduced the ceiling, and a gate that lands as four instant blockers is the shape this repository has already recorded as a failure. Shrink-only from here: a FIFTH over-ceiling file reds. roadmap-process-loop.md is the file that motivated the gate \u2014 it states 'Size budget: <= 4,000 chars' in its own header and is 5x over it, which is what a declared budget with nothing measuring it decays into. The ceiling is a GROWTH RATCHET, not a measured quality threshold: the 7,308-trajectory study behind the 3,500-token skill ceiling (ADR-217) was taken on procedural always-co-loaded skills, and this layer is declarative and loaded one or two files at a time. Replace the number when someone measures comprehension on THIS layer."
-    },
-    "check_gate_completeness": {
-      "count": 215,
-      "landed": "2026-08-17",
-      "note": "Ledger adoption ratchet. Gates registered under the CI task roots that carry neither per-target completeness accounting (`_lib/gate_ledger.ts`) nor a `// ledger-exempt:` marker. This is deliberately NOT a sweep: road-to-skill-ecosystem-gate-integrity Phase 1 adopts exactly three gates (lint_framework_leakage, check_references, lint_roadmap_complexity) plus the checker itself to prove the interface, and the remainder migrates as gates are touched. Shrink-only from here \u2014 the number may not grow, so a NEW gate must adopt or exempt. Lowered 216 -> 215 on 2026-08-17 by discharging the obligation three NEW arrivals had incurred, which is the standing rule being enforced rather than a drain: the registered population grew 244 -> 258 and three of the fourteen arrivals adopted nothing \u2014 `build_archive_index`, `check_gate_coverage`, `check_pr_ci_current`. The reading was 218 against this baseline of 216, and the missing arithmetic is that one PRE-existing gate (`lint_rule_skill_pack_reach`) had adopted in the meantime: 216 + 3 - 1 = 218. All three adopted a real ledger. `check_pr_ci_current` first took a reasoned exemption claiming no target population; the completion review refuted it from the file itself \u2014 the check rows ARE a population, and rows whose `state` is not a string were being dropped before any verdict ran, so a dropped row could be the failing one. The exemption was withdrawn and the ledger adopted, counting kept rows as read, dropped rows as skips, and rows a pre-row verdict never reached as out of scope. The denominator in this note was 14 stale (it said 244) and is now expressed without one, because a count pinned to a population that grows weekly rots faster than the count itself. Note what this lowering does NOT buy: headroom is zero either way, so the next un-adopted arrival reds this gate immediately \u2014 which is the intended behaviour and the reason the number is not padded. The refreshed `landed` is load-bearing rather than bookkeeping: `checkRatchet` returns `improved` BEFORE it evaluates staleness, so an entry left at 216 while the tree measures 215 would never expire at any age (pinned by tests/lib/gate_baseline.test.ts, which asserts `improved` at landed + STALE_AFTER_DAYS + 400 days) \u2014 the greenest available state and the worst, since it switches off the anti-fossilization clause exactly when someone has done real work.",
-      "falsifier": "./scripts-run src/scripts/check_gate_completeness"
-    },
-    "check_no_new_legacy_path:hardcoded-scan-roots": {
-      "count": 47,
-      "landed": "2026-08-13",
-      "note": "Lines under src/scripts/**/*.{ts,mts,mjs} that pass the retired `.agent-src.uncondensed` directory into `path.join(...)` \u2014 a filesystem path CONSTRUCTED against the tree ADR-051 abandoned, which is the exact shape of all 14 dead gates. Deliberately narrow so the number is signal, not noise: 236 raw mentions under src/scripts \u2192 147 string-literal lines \u2192 67 path-constructing lines when the pass was written, after exempting src/scripts/_lib/agent_src.ts (the shared resolver, whose job IS owning the constant \u2014 gates that route through it survived the move). Detectors holding the literal as data to match, strip, or print are not counted, and no prose, docs, tests or fixtures are read: that full-tree shape was measured at 44 files / 213 hits and rejected as the wrong lint (see the note in check_no_new_legacy_path.ts::find_offenders). Recorded at 58 rather than 67 because Phase 1's scan-root repairs were landing on this branch while the pass was being written and had already removed 9 \u2014 a baseline above the truth silently permits new violations. This count goes to ZERO as the remaining repairs land; every repair is a lowering commit. Lowered 56\u219251 by the road-to-renewal-foundation Phase 1 dead-root sweep (check_always_budget, check_portability, check_references, lint_framework_leakage, lint_agents_md). Lowered 51\u219249 by the gate-hardening adoption PR: skill_collision_clusters and skill_overlap were repointed at the live skills tree via the shared resolver \u2014 two gates that had been reading the retired container and scoring 0 of 288 skills. Lowered 49\u219248 by road-to-rule-delivery-integrity P2.2: score_skill_selection was repointed at the live skills tree via the shared resolver. It is the same shape as the two gates lowered before it \u2014 a scorer reading the retired container and scoring 0 of 288 skills \u2014 and here the consequence was sharper than a dead gate: the roadmap's pre-registered selection-accuracy criteria would have been compared against a baseline of silent zeros. Lowered 48\u219247 on 2026-08-13, and this one is a catch-up rather than a repair: the pass reported 47 against a baseline of 48, so a gain had already landed without the ratchet following it. Attributed to 455160160 (fix(evals): resolve the eval orchestrator against the live skills tree), the most recent repair in this branch's base that removes a path-constructing line \u2014 SKILLS_ROOT repointed through _lib/agent_src.ts::SRC_SKILLS(). A loose ratchet is not harmless: it silently permits one new violation to be added back without any gate noticing, which is the shape this entry exists to prevent."
-    },
-    "check_source_size_budget": {
-      "count": 19397,
-      "landed": "2026-08-22",
-      "note": "Lowered 19,427 -> 19,397 on 2026-08-22 by road-to-single-rule-layer Phase 4, and the -30 is again a LOWERING THROUGH EXTRACTION rather than a comment trim -- the same shape and for the same reason as the previous entry. The branch had to wire a per-host partition decision into condense.ts (2,735), which is the worst file here, and a first pass added 105 lines above the ceiling: this gate correctly refused it. Two extractions carried it. The partition decision itself -- the fail-safe ordering, the measurement it was derived from, and why the classification source is dist/ rather than src/ -- went to src/install/ruleLayerPartition.ts, leaving a 10-line adapter behind. Then the older, weaker duplicate-avoidance mechanism moved with it: USER_SCOPE_RULE_DIRS and _dedupable_rules (projection.scope_dedup, default off, byte-identity keyed) are the same subject as the partition, and having one of the two in a 2,700-line generator and the other in src/install/ is how a reader ends up reading only one. Behaviour is unchanged there; only the MODULE_STATE reads became parameters. condense.ts ends at 2,705 -- 30 lines below where this branch found it, while carrying four new call sites for the partition and the .windsurfrules legacy surface. Lowered 19,570 -> 19,427 on 2026-08-20 by road-to-single-delivery Phase 5, and the -143 is a LOWERING THROUGH EXTRACTION in the sense this note's own convention requires -- reproducible with `git stash && npx tsx src/scripts/check_source_size_budget.ts`. The branch had to WIRE a feature into the two worst files here: the delivery partition (ADR-236) needs a decision point in condense.ts (2,885) and a fingerprint stamp in install.ts (5,461), and a first pass added 191 lines above the ceiling -- a straight regression this gate correctly refused. The fix was not to shrink the comments until the number fit. Three extractions carried it: the partition decision, its memo, its fail-safe ordering and its printed reason went to src/install/partitionEligibility.ts (325 lines, under the ceiling, contributing nothing here); the fingerprint itself to hostLayerFingerprint.ts; and then the one that produced the surplus -- the whole Claude `paths:` emission plan (_claude_paths_plan, _has_non_path_trigger, derive_trigger_globs, _is_unresolved_placeholder, _escape_claude_bracket, _expanded_pattern_count, the budget constant and the plan type, 169 lines) moved to src/install/claudePathsPlan.ts. That last move is not opportunistic: Phase 5.1 removed the path triggers from four package-only rules so they load unconditionally, which is a change ABOUT that plan, and the plan is host-activation-key logic that belongs beside emit_host_rules_cli.ts rather than inside the orchestrator that calls it. condense.ts ends at 2,735 -- 150 lines BELOW where the branch found it, while carrying four new call sites. Every consumer that imported the moved symbols from condense.ts still can: they are re-exported, so the extraction is invisible to callers and visible to this ratchet. Previous entry: lowered 19,626 -> 19,611 on 2026-08-17 by the release-gh-transient branch, same shape (retry loop and transient classifier extracted to _lib/gh_transient.ts, leaving release.ts a 20-line wrapper).",
-      "falsifier": "./scripts-run src/scripts/check_source_size_budget --quiet"
-    },
-    "ci-parity:local-only": {
-      "count": 165,
-      "landed": "2026-08-13",
-      "note": "Gates that `task ci` runs and no workflow does \u2014 the direction this manifest's own header calls the one that let real defects merge (16 stale index rows reached the trunk behind a local-only check-index). Revealed, not created, by repairing the checker's extraction: check_ci_local_parity built its CI-side set by regexing RAW workflow text for `task <name>` and expanding each closure, comments included. Several workflow comments contain the literal string `task ci` while stating that no workflow invokes it, so `ci` was read as an invocation and its full 247-gate closure entered the 'runs in CI' set. The count was therefore 0 BY CONSTRUCTION, and the prose documenting the gap was what suppressed it. Measured at the repair: CI-side 273 \u2192 106, undeclared_local_only 0 \u2192 167 of 247 local gates (68%). Baselined rather than hard-failed because 167 findings nobody can clear in the change that reveals them is the gate-that-lands-as-N-instant-blockers failure this repository has refused before; shrink-only keeps the property that matters, namely that a NEW gate registered in `task ci` with no workflow reds immediately. Lowering happens by wiring gates into workflows or declaring them under `local_only:` with a reason. Note the punchline, because it bounds the risk of this entry: check_ci_local_parity ITSELF runs in no workflow, so it is its own finding and this ratchet has no remote reach either \u2014 clearing the backlog is what gives it teeth. DRAINED BY ONE, 2026-08-13: check_ci_local_parity itself was wired into consistency.yml, so it left the set it exists to report. That is the whole shape of a legitimate drain here \u2014 the gate stops being local-only because a workflow now runs it, not because the declaration list grew. The floor in gate-coverage.yml moved in the same change and for the same reason: wiring two gates raised the parsed population 357 -> 360 (109 CI + 251 local). The intermediate 359 was the reading after the CI-side wiring alone and before check_gate_coverage joined the local `ci` chain; it was committed here by mistake and is corrected rather than left as a second number for the same measurement. WALKED DOWN 166 -> 165 on 2026-08-20 (road-to-session-closeout 5.2): check_ci_local_parity reported `ci-parity:local-only: 165 violation(s), baseline 166 - ratchet is loose` and asked for exactly this, so the gain cannot be silently given back. The measurement is the gate's own output on the merged tree, not a branch. What is NOT done here is the classification the same step asks for: 165 gates each need a recorded class (belongs-in-CI / developer-aid / dead), which is per-gate judgement, and migrating them would red the trunk on the landing day - the step forbids it for that reason.",
-      "falsifier": "./scripts-run src/scripts/check_ci_local_parity"
-    },
-    "gate-self-test:registered-non-adopters": {
-      "count": 24,
-      "landed": "2026-08-06",
-      "note": "Self-test adoption ratchet, expressed as a shrink-only NON-adopter count. 24 of the 32 gates registered enforced in gate-coverage.yml carry neither a `--self-test` (`_lib/gate_self_test.ts`) nor a `// self-test-exempt: <reason>` marker, so nothing proves they DISCRIMINATE \u2014 an enforced `scanned:` floor proves a gate read something, only a self-test proves the reading changes the verdict. Deliberately NOT an adoption column ratcheted upward: check_gate_coverage.ts's own report_hardening_ratchet rejects that shape in this same file (\"grades the solution instead of the problem\"), and the sibling adoption ratchet (check_gate_completeness) is already a non-adopter count. Population is the manifest, not every script under src/scripts: padding the manifest to move this number would mean adding a floor per row. Shrink-only from here \u2014 a NEW registered gate must adopt or exempt. Migration mechanism, same as the ledger ratchet above: gates adopt as they are touched, not in a sweep \u2014 the eight current adopters were each added alongside a real change to that gate. The 56-day non-stagnation clause applies unchanged, so a count parked here fails on its own.",
-      "falsifier": "./scripts-run src/scripts/check_gate_coverage"
-    },
-    "lint_handoffs": {
-      "count": 18,
-      "landed": "2026-08-02",
-      "note": "All 18 are `handoff_tier_mismatch`: a senior-tier skill links to a peer whose frontmatter carries no `tier` (reported as tier='unset') \u2014 e.g. build-buy-partner \u2192 adr-create, customer-research \u2192 po-discovery, gated-reach \u2192 threat-modeling. This is a tier-metadata backfill backlog on the LINKED-TO skills, not a broken link. The one genuinely dangling link revealed by the same repair (competitive-positioning \u2192 a non-existent ../analyze-reference-repo/SKILL.md; it is a command, not a skill) was FIXED in the repairing commit rather than baselined. Clearing this entry means backfilling `tier` on the linked-to skills, or deciding that `tier: unset` on a link target is not a violation and narrowing the rule."
-    },
-    "lint_pack_boundaries": {
-      "count": 337,
-      "landed": "2026-08-02",
-      "note": "Markdown links between source artefacts that cross a pack boundary the source pack's `requires` graph does not reach \u2014 revealed when the scan root moved off the deleted packages/ tree to the live corpus (0 -> 753 artefacts scanned). 82 distinct pack pairs across 131 source files; largest single class is engineering-base -> meta (73), skills in a consumer-installable pack citing this package's own maintenance skills. Each is a link that dangles for a consumer who installs the source pack without the target's. Judged real drift rather than an over-strict gate because it is long-tailed \u2014 top bucket 22%, no single systematic cause \u2014 unlike the lint_artefact_frontmatter case, where one required shape had 0-of-288 adoption. Fix per finding: add the edge to packs.yml requires, retarget the link, or move the artefact."
-    },
-    "lint_provenance_vocabulary:permanence-language": {
-      "count": 11,
-      "landed": "2026-08-21",
-      "note": "Permanence language in an ADR record's load-bearing positions -- its `# ` title, its `decision:` frontmatter slug, its `## Decision` section, or an `Addendum` heading. Revealed by adding rule 4 to lint_provenance_vocabulary, not created by it: ADR-240 section 6 states the doctrine (`forever`, `permanently`, `never revisit`, `never reconsider` and their kin do not belong in a mechanism decision's title, slug or Decision section) and the corpus had five records violating it on the day the rule landed. Baselined rather than hard-failed because a gate that lands as five instant blockers is the shape this repository has already refused (see ci-parity:local-only and lint_roadmap_blockers:decidability above), and every one of the five is a content decision rather than a copy edit: ADR-208 (slug `dist-agent-src-keep-forever`, title \"kept forever\", Decision \"KEEP -- permanently\") is the standing self-contradiction ADR-240 cites, since lines 10-11 of its own frontmatter carry the conditions under which it should be reopened; ADR-107:37 and ADR-108:5/12/24/29 are owner PURPOSE statements (\"open-source forever\", \"now or in the future\", \"liability disclaimer is permanent\") whose fix is the escape ADR-240 names -- record `authority_basis: owner_intent` -- which is an owner ruling, not an agent edit; ADR-122:77/154 and ADR-124:229 assert a permanently-off default whose honest form is a default-off setting plus a reopen condition. The rule is deliberately SCOPED and the scoping is the gate: the same word list applied to whole files matches many more, and the large majority are legitimate. The comparison figure is given with its method because 'unscoped' has two readings and an earlier version of this note picked one without saying which, giving 41 lines across 30 records which reproduces neither way: the bare word list over both ADR surfaces matches 45 lines in 26 records, and the word list PLUS the lint's own line filters (code fences, quoted spans, table rows, in-sentence negation, attributive `permanent`, hyphen compounds) but WITHOUT position scoping matches 29 in 17. Scoping to the four load-bearing positions takes it to 11 in 5. The 29-to-11 step is what the scoping buys; the 45 is what a naive grep would report -- an `## Alternatives considered` entry rejecting a permanence option (ADR-105:97, ADR-137:148-151, ADR-212:133), a `## Consequences` line reporting one (ADR-136:90, ADR-208:73, ADR-216:278/298), a `## Context` recounting one (ADR-042:36, ADR-232:34), a quoted open question (ADR-201:342/343) and a table rationale cell bounding a failure mode (ADR-074:41, ADR-225:64) are all describing a permanence claim rather than making one. Shrink-only from here, which is the property that matters: a NEW record asserting permanence in any of the four positions reds this gate immediately, and headroom is zero. Lowering happens one record at a time -- convert an owner purpose statement to `authority_basis: owner_intent`, or restate a mechanism decision with the reopen condition it already carries. The 56-day expiry is the point rather than a hazard: if this number has not moved in two months, the doctrine is not being applied and the gate should fail until someone decides whether it is real.",
-      "falsifier": "./scripts-run src/scripts/lint_provenance_vocabulary"
-    },
-    "lint_settings_classes:derivable-surface": {
-      "count": 83,
-      "landed": "2026-08-12",
-      "note": "Anti-regrowth ratchet for the settings disposition axis. 83 of 134 template leaves are classified `derivable` \u2014 the mechanism can decide from the situation, so the key should not exist \u2014 and each names the replacement that would decide instead (`lint_settings_classes` rejects the bare label, which is what keeps the class from becoming a synonym for \"inconvenient to keep\"). This is a DELETION QUEUE, not 83 deletions: a row stays until the mechanism it names actually exists, and deleting a key ahead of its mechanism is a silently-changed default rather than a simplification. Shrink-only from here, which is the anti-regrowth half \u2014 a NEW key classified `derivable` raises the number and reds, so a key whose answer the situation already carries cannot be added at all. The 56-day non-stagnation clause is the other half and is wanted here rather than tolerated: a queue that never drains is a stated direction nobody is walking. The queue opened at 88 of 140 on 2026-08-12 and drained to 83 of 134 the same day: six keys had no reader whatsoever (telegraph.speak_scope, chat_history.max_size_kb, chat_history.on_overflow, quality.wait_for_remote_ci, screenshots.data_bearing_gate, legal_review_prep.consented_at), five of them `derivable` and one a `consent` row reclassified because a published-egress confirmation is a Hard Floor no setting may lift. An unread key is the only deletion that cannot silently change a default, which is why that batch went first. The classification itself is docs/contracts/settings-classes.md.",
-      "falsifier": "./scripts-run src/scripts/lint_settings_classes"
-    }
-  },
-  "retired": {
-    "lint_roadmap_blockers:decidability": {
-      "count": 0,
-      "landed": "2026-08-22",
-      "note": "Open blocker entries that are not yet DECIDABLE by the person who owns them \u2014 missing `Recommendation:` (which option and why), missing `If you do nothing:` (the cost of the non-decision), or a `What to do:` carrying no command, path or enumerated option set. Revealed by adding the decidability half to lint_roadmap_blockers, not created by it: the five original fields describe a situation and never made it actionable, so a blocker could pass the contract while handing the analysis back to the person least equipped to redo it. Measured at introduction: 36 open entries, ALL 36 undecidable, and 14 of the 46 total entries carry no command/path/option at all in `What to do`. Baselined rather than hard-failed because 36 findings nobody can clear in the change that reveals them is the gate-that-lands-as-N-instant-blockers failure this repository has refused before \u2014 the same reasoning as ci-parity:local-only above. First measured at 34 rather than 36 because the two blockers on the branch that introduced this (`ac3-false-positive-reading`, `publish-side-marker-invariant`) were rewritten to the new standard and then closed in the same change; a baseline above the truth silently permits new violations. Re-measured at 38 when the branch was re-pointed at current main, and the +4 is population growth rather than a loosening: main gained the four `road-to-inbox-harvest-2026-08-d-*` roadmaps (context-ledger, runtime-skill-routing, scheduled-deprecation, top-band-model-economy), each carrying one open blocker authored before this requirement existed. That is the honest number for the population this gate now scans \u2014 recording 34 against a 38-entry tree would have failed the gate on its own introducing commit and taught the next reader to distrust it. Lowering happens one blocker at a time, and every roadmap touched for other reasons is a chance to lower it. Lowered 38\u219237 by the scheduled-deprecation PR, which is exactly that shape: code-graph-removal-authorisation was rewritten to the new standard because the roadmap was being touched anyway. Its `If you do nothing:` was one of the few that was not the common no-cost answer \u2014 the release gate that PR ships would have refused the next major cut while the blocker stayed open. Recorded in the past tense because the maintainer then RESOLVED that blocker on the trunk by withdrawing the commitment, so nothing refuses a cut today. The lowering stands on the rewrite, not on the consequence, and the sentence is corrected rather than deleted because a baseline note arguing from a retracted state is how a ratchet's rationale rots. The 56-day expiry is the point, not a hazard: if this number has not moved in two months, the fields are not being written and the gate should fail until someone decides whether the requirement is real. Lowered 37\u219234 when the scheduled-deprecation branch merged current main: three blockers were resolved or rewritten on the trunk in the meantime, so the drop is a genuine drain plus a merge, not a loosening. Re-tightened here rather than left loose because a ratchet that lags its own tree permits violations back in silently. Lowered 34\u219229 on 2026-08-16 by rewriting six entries to the new standard (raw-capture-needs-host-env, telemetry-sample-size, repo-admin-and-usage, benchmark-spend, measurement-a-no-per-arm-builder-tier, measurement-b-no-renderable-lane-pair) in a PR whose only purpose was the drain \u2014 the first lowering not taken on the back of another change, which the note above says is the usual shape. Two findings from that pass are worth keeping. The tree measured 35 against a baseline of 34 BEFORE the drain, i.e. the ratchet was already red on main and nobody knew: this gate runs in `task ci`, no workflow invokes `task ci`, and the local run that would have shown it was read through a `tail`, which hid every row above the last six. And four of the six `If you do nothing:` answers are honestly that nothing degrades \u2014 that is the true answer for a held measurement, and writing it is what makes the entry decidable, so the field earns its place by being cheap to answer truthfully rather than by always carrying a cost. Lowered 29 \u2192 27 on 2026-08-16 by the merge of this branch and the trunk drain above, and the arithmetic matters more than the delta: both sides rewrote entries from the same tree of 35 independently \u2014 the trunk six (recorded above), this branch two (deferred-finding-decision-reopen, spent-inbox-artifacts-await-deletion, rewritten because road-to-inbox-harvest-residuals was being touched anyway). The sets are disjoint, so the merged tree measures 27 and the gate itself reported the slack. Tightened rather than banked: 29 against a 27-entry tree would absorb the next two undecidable blockers without anything noticing, which is the lag this note has now corrected twice. Lowered 27 \u2192 26 on 2026-08-16 by rewriting `picktier-wire-or-archive` (road-to-inbox-harvest-2026-08-d-top-band-model-economy), and this one is the usual shape the note describes rather than the dedicated-drain shape: the roadmap was being worked for its own Step 4.1 and the entry was rewritten because it was open on the desk. Worth recording for what writing the two fields SURFACED, which is the argument for the requirement: `Recommendation:` forced the question 'which option, and why' and the honest answer turned out not to be one of the three options at all \u2014 the entry defers to a converged council verdict, and the council cannot reach quorum (re-measured 0 of 2 the same day), so the actionable next step is a one-line fix to a user-global config file outside this repository. Five fields had described that situation accurately for two weeks without anyone noticing that the named blocker was infrastructure rather than judgement. Lowered 26 \u2192 22 on 2026-08-18 by road-to-estate-drawdown Step 0.1, which needed the two fields for a different reason and therefore drained six entries as a by-product: the consolidated decision sheet renders a DEFAULT plus that default's provenance per user-owned decision, and 7 of the 21 live entries recorded no `Recommendation:` to derive one from. Six were rewritten to the new standard (skill-activation-window, b-convergence-machine, maintainer-blind-ratings, real-orchestration-usage, human-gated-live-trigger-eval, manual-rubric-rater), each marked `agent-drafted` in the field itself so the sheet can label the provenance rather than presenting a drafted default beside a maintainer-recorded one as the same kind of statement. The seventh, `road-to-gated-reach-followup`'s legacy `> Blocked until \u2026` note, is NOT counted here and was not rewritten: it is a blocked-until note rather than a `### blocker:` entry, so it has no field to carry, and converting it is a roadmap restructure this change did not take. **The tree was RED at 28 against this baseline of 26 before the drain, and again nobody knew** \u2014 the same failure the 34\u219229 paragraph above records, one gate cycle later: two entries had been added on the trunk without the fields, and this gate runs in `task ci`, which no workflow invokes. That is the second recorded instance of this ratchet being red on main undetected, which is an argument about where it runs rather than about its number. `human-gated-live-trigger-eval` also gained a command in `What to do:` (`rule_trigger_eval`, verified to exist at src/scripts/) because the field carried a path-less instruction; the other five needed only the two decidability fields. Lowered 22 -> 20 on 2026-08-19 by road-to-estate-drawdown Phase 2 triage batch 1, and RE-MEASURED after two merges of origin/main rather than carried over: the trunk gained roadmaps in between (the long-horizon pair and the council-fallback set), and the live count over the merged tree is still 20 across 39 roadmaps. Six roadmaps moved to later/, and two of them carried an undecidable open blocker each. The gain is a side effect of parking rather than of drafting a recommendation, so it is recorded as such \u2014 the two entries are unchanged and still undecidable where they sit; they are simply outside the active tree this ratchet scans. Walked down because the gate reported itself loose, and a baseline above the measurement is headroom a later change can spend with nothing objecting. Lowered 20 -> 17 on 2026-08-20 by the road-to-frontend-skill-application closeout, and the shape is the usual one this note describes: the roadmap was being closed for its own reasons and its three open blockers were on the desk anyway. Two (ui-corpus-has-no-ui, enforcement-evidence) left the population by being RESOLVED rather than rewritten, which is the cleanest way to lower this number and the only one that does not add prose; the third (ui-session-capture-window) was rewritten to the new standard. Worth recording what writing the two fields surfaced, since that is the standing argument for the requirement: on ui-corpus-has-no-ui, `Recommendation:` forced the question \"which option, and why\" and the honest answer was that the entry's own premise was false \u2014 it asserted the question could not be answered without a human naming a consumer store, and the stores were already on the machine, readable by the command the entry itself printed. Five fields had described that situation accurately for a week without anyone noticing the blocker was a measurement nobody had run. Tightened rather than banked because 20 against a 17-entry tree is headroom the next three undecidable blockers would spend with nothing objecting, which is the lag the paragraphs above have now corrected three times. Walked 17 -> 12 at the drain/road-to-frontend-skill-application merge, 2026-08-21, on the gate's own loose-ratchet report. Re-measured against the merged tree rather than attributed: sibling drain PRs made entries decidable in parallel, so this branch's share is not separable here and is not claimed. Banked at the measurement rather than left as headroom a later change could spend.\n\nWALKED 12 -> 1 on 2026-08-22 by resolving the two `road-to-evidence-based-adr-governance` blockers (`owner-autonomy-batch`, `authority-coupling-decision`), which were undecidable in exactly the way this ratchet names: each handed a Hard-Floor question to the reader without a landed outcome. Both now carry one. The single remaining violation is `road-to-drain-commands:395` (`merge-authority`), which PR #1517 resolves and archives \u2014 so the honest count for THIS tree is 1 and it is expected to reach 0 once that lands. It is not lowered to 0 here, because a baseline must describe the tree it ships with rather than the tree someone expects next. Lowered 1 -> 0 on 2026-08-22, and the prediction the previous entry made is what closed it: the single remaining violation was `road-to-drain-commands:395` (`merge-authority`), and PR #1517 archived that roadmap, taking the entry out of the scanned population. Nothing was rewritten to reach zero -- the record left the active tree with its blocker RESOLVED, which is the cleanest of the two ways this number goes down and the only one that adds no prose. Zero is now the ceiling: any new open blocker missing `Recommendation:`, `If you do nothing:` or an actionable `What to do:` reds this gate immediately, with no headroom at all.",
-      "falsifier": "./scripts-run src/scripts/lint_roadmap_blockers --quiet",
-      "retired_on": "2026-08-22",
-      "retired_because": "Walked to 0 and therefore removed from `gates`: an entry recording no debt is what gate_baseline.test.ts refuses, and a missing entry is not weaker \u2014 evaluateGate treats an absent baseline as ok only when the live count is 0, which is the same ceiling the note below asked for. Kept here because the note is dated history, not commentary; nothing reads this key at runtime."
+    "retired": {
+        "lint_roadmap_blockers:decidability": {
+            "count": 0,
+            "landed": "2026-08-22",
+            "note": "Open blocker entries that are not yet DECIDABLE by the person who owns them \u2014 missing `Recommendation:` (which option and why), missing `If you do nothing:` (the cost of the non-decision), or a `What to do:` carrying no command, path or enumerated option set. Revealed by adding the decidability half to lint_roadmap_blockers, not created by it: the five original fields describe a situation and never made it actionable, so a blocker could pass the contract while handing the analysis back to the person least equipped to redo it. Measured at introduction: 36 open entries, ALL 36 undecidable, and 14 of the 46 total entries carry no command/path/option at all in `What to do`. Baselined rather than hard-failed because 36 findings nobody can clear in the change that reveals them is the gate-that-lands-as-N-instant-blockers failure this repository has refused before \u2014 the same reasoning as ci-parity:local-only above. First measured at 34 rather than 36 because the two blockers on the branch that introduced this (`ac3-false-positive-reading`, `publish-side-marker-invariant`) were rewritten to the new standard and then closed in the same change; a baseline above the truth silently permits new violations. Re-measured at 38 when the branch was re-pointed at current main, and the +4 is population growth rather than a loosening: main gained the four `road-to-inbox-harvest-2026-08-d-*` roadmaps (context-ledger, runtime-skill-routing, scheduled-deprecation, top-band-model-economy), each carrying one open blocker authored before this requirement existed. That is the honest number for the population this gate now scans \u2014 recording 34 against a 38-entry tree would have failed the gate on its own introducing commit and taught the next reader to distrust it. Lowering happens one blocker at a time, and every roadmap touched for other reasons is a chance to lower it. Lowered 38\u219237 by the scheduled-deprecation PR, which is exactly that shape: code-graph-removal-authorisation was rewritten to the new standard because the roadmap was being touched anyway. Its `If you do nothing:` was one of the few that was not the common no-cost answer \u2014 the release gate that PR ships would have refused the next major cut while the blocker stayed open. Recorded in the past tense because the maintainer then RESOLVED that blocker on the trunk by withdrawing the commitment, so nothing refuses a cut today. The lowering stands on the rewrite, not on the consequence, and the sentence is corrected rather than deleted because a baseline note arguing from a retracted state is how a ratchet's rationale rots. The 56-day expiry is the point, not a hazard: if this number has not moved in two months, the fields are not being written and the gate should fail until someone decides whether the requirement is real. Lowered 37\u219234 when the scheduled-deprecation branch merged current main: three blockers were resolved or rewritten on the trunk in the meantime, so the drop is a genuine drain plus a merge, not a loosening. Re-tightened here rather than left loose because a ratchet that lags its own tree permits violations back in silently. Lowered 34\u219229 on 2026-08-16 by rewriting six entries to the new standard (raw-capture-needs-host-env, telemetry-sample-size, repo-admin-and-usage, benchmark-spend, measurement-a-no-per-arm-builder-tier, measurement-b-no-renderable-lane-pair) in a PR whose only purpose was the drain \u2014 the first lowering not taken on the back of another change, which the note above says is the usual shape. Two findings from that pass are worth keeping. The tree measured 35 against a baseline of 34 BEFORE the drain, i.e. the ratchet was already red on main and nobody knew: this gate runs in `task ci`, no workflow invokes `task ci`, and the local run that would have shown it was read through a `tail`, which hid every row above the last six. And four of the six `If you do nothing:` answers are honestly that nothing degrades \u2014 that is the true answer for a held measurement, and writing it is what makes the entry decidable, so the field earns its place by being cheap to answer truthfully rather than by always carrying a cost. Lowered 29 \u2192 27 on 2026-08-16 by the merge of this branch and the trunk drain above, and the arithmetic matters more than the delta: both sides rewrote entries from the same tree of 35 independently \u2014 the trunk six (recorded above), this branch two (deferred-finding-decision-reopen, spent-inbox-artifacts-await-deletion, rewritten because road-to-inbox-harvest-residuals was being touched anyway). The sets are disjoint, so the merged tree measures 27 and the gate itself reported the slack. Tightened rather than banked: 29 against a 27-entry tree would absorb the next two undecidable blockers without anything noticing, which is the lag this note has now corrected twice. Lowered 27 \u2192 26 on 2026-08-16 by rewriting `picktier-wire-or-archive` (road-to-inbox-harvest-2026-08-d-top-band-model-economy), and this one is the usual shape the note describes rather than the dedicated-drain shape: the roadmap was being worked for its own Step 4.1 and the entry was rewritten because it was open on the desk. Worth recording for what writing the two fields SURFACED, which is the argument for the requirement: `Recommendation:` forced the question 'which option, and why' and the honest answer turned out not to be one of the three options at all \u2014 the entry defers to a converged council verdict, and the council cannot reach quorum (re-measured 0 of 2 the same day), so the actionable next step is a one-line fix to a user-global config file outside this repository. Five fields had described that situation accurately for two weeks without anyone noticing that the named blocker was infrastructure rather than judgement. Lowered 26 \u2192 22 on 2026-08-18 by road-to-estate-drawdown Step 0.1, which needed the two fields for a different reason and therefore drained six entries as a by-product: the consolidated decision sheet renders a DEFAULT plus that default's provenance per user-owned decision, and 7 of the 21 live entries recorded no `Recommendation:` to derive one from. Six were rewritten to the new standard (skill-activation-window, b-convergence-machine, maintainer-blind-ratings, real-orchestration-usage, human-gated-live-trigger-eval, manual-rubric-rater), each marked `agent-drafted` in the field itself so the sheet can label the provenance rather than presenting a drafted default beside a maintainer-recorded one as the same kind of statement. The seventh, `road-to-gated-reach-followup`'s legacy `> Blocked until \u2026` note, is NOT counted here and was not rewritten: it is a blocked-until note rather than a `### blocker:` entry, so it has no field to carry, and converting it is a roadmap restructure this change did not take. **The tree was RED at 28 against this baseline of 26 before the drain, and again nobody knew** \u2014 the same failure the 34\u219229 paragraph above records, one gate cycle later: two entries had been added on the trunk without the fields, and this gate runs in `task ci`, which no workflow invokes. That is the second recorded instance of this ratchet being red on main undetected, which is an argument about where it runs rather than about its number. `human-gated-live-trigger-eval` also gained a command in `What to do:` (`rule_trigger_eval`, verified to exist at src/scripts/) because the field carried a path-less instruction; the other five needed only the two decidability fields. Lowered 22 -> 20 on 2026-08-19 by road-to-estate-drawdown Phase 2 triage batch 1, and RE-MEASURED after two merges of origin/main rather than carried over: the trunk gained roadmaps in between (the long-horizon pair and the council-fallback set), and the live count over the merged tree is still 20 across 39 roadmaps. Six roadmaps moved to later/, and two of them carried an undecidable open blocker each. The gain is a side effect of parking rather than of drafting a recommendation, so it is recorded as such \u2014 the two entries are unchanged and still undecidable where they sit; they are simply outside the active tree this ratchet scans. Walked down because the gate reported itself loose, and a baseline above the measurement is headroom a later change can spend with nothing objecting. Lowered 20 -> 17 on 2026-08-20 by the road-to-frontend-skill-application closeout, and the shape is the usual one this note describes: the roadmap was being closed for its own reasons and its three open blockers were on the desk anyway. Two (ui-corpus-has-no-ui, enforcement-evidence) left the population by being RESOLVED rather than rewritten, which is the cleanest way to lower this number and the only one that does not add prose; the third (ui-session-capture-window) was rewritten to the new standard. Worth recording what writing the two fields surfaced, since that is the standing argument for the requirement: on ui-corpus-has-no-ui, `Recommendation:` forced the question \"which option, and why\" and the honest answer was that the entry's own premise was false \u2014 it asserted the question could not be answered without a human naming a consumer store, and the stores were already on the machine, readable by the command the entry itself printed. Five fields had described that situation accurately for a week without anyone noticing the blocker was a measurement nobody had run. Tightened rather than banked because 20 against a 17-entry tree is headroom the next three undecidable blockers would spend with nothing objecting, which is the lag the paragraphs above have now corrected three times. Walked 17 -> 12 at the drain/road-to-frontend-skill-application merge, 2026-08-21, on the gate's own loose-ratchet report. Re-measured against the merged tree rather than attributed: sibling drain PRs made entries decidable in parallel, so this branch's share is not separable here and is not claimed. Banked at the measurement rather than left as headroom a later change could spend.\n\nWALKED 12 -> 1 on 2026-08-22 by resolving the two `road-to-evidence-based-adr-governance` blockers (`owner-autonomy-batch`, `authority-coupling-decision`), which were undecidable in exactly the way this ratchet names: each handed a Hard-Floor question to the reader without a landed outcome. Both now carry one. The single remaining violation is `road-to-drain-commands:395` (`merge-authority`), which PR #1517 resolves and archives \u2014 so the honest count for THIS tree is 1 and it is expected to reach 0 once that lands. It is not lowered to 0 here, because a baseline must describe the tree it ships with rather than the tree someone expects next. Lowered 1 -> 0 on 2026-08-22, and the prediction the previous entry made is what closed it: the single remaining violation was `road-to-drain-commands:395` (`merge-authority`), and PR #1517 archived that roadmap, taking the entry out of the scanned population. Nothing was rewritten to reach zero -- the record left the active tree with its blocker RESOLVED, which is the cleanest of the two ways this number goes down and the only one that adds no prose. Zero is now the ceiling: any new open blocker missing `Recommendation:`, `If you do nothing:` or an actionable `What to do:` reds this gate immediately, with no headroom at all.",
+            "falsifier": "./scripts-run src/scripts/lint_roadmap_blockers --quiet",
+            "retired_on": "2026-08-22",
+            "retired_because": "Walked to 0 and therefore removed from `gates`: an entry recording no debt is what gate_baseline.test.ts refuses, and a missing entry is not weaker \u2014 evaluateGate treats an absent baseline as ok only when the live count is 0, which is the same ceiling the note below asked for. Kept here because the note is dated history, not commentary; nothing reads this key at runtime."
+        }
     }
-  }
 }

package/src/config/preamble-payload-budget.json

@@ -1,72 +1,76 @@
 {
-    "_comment": "Per-spawn preamble payload ceiling (road-to-cache-economy Phase 3), unblocked by C-3 measuring 38.0% against a 15% bar. This is a RATCHET, not the roadmap's literal candidate numbers: those (median 40k / p95 50k) were anchored to an upstream ~37k baseline, while this package's own deterministic in-repo payload is ~102.5k tokens — a hard 40k gate would be red on the day it lands and would teach the reader to ignore it. The ratchet fails on GROWTH instead, so the number can only walk down, and the 40k/50k target stays recorded as the destination. Only the deterministic, in-repo buckets are gated: user-scope rules depend on what the developer happens to have installed globally and are therefore not CI-checkable.",
-    "schema_version": 1,
-    "registered_at": "2026-07-30",
-    "owner": "maintainer",
-    "review_by": "2027-07-30",
-    "metric": {
-        "basis": "chars/4 token estimate over the projected tree, produced by src/scripts/preamble_byte_census.ts",
-        "gated_buckets": [
-            "project-scope rules (dist/agent-src/rules/*.md)",
-            "preloaded skills catalog (name + description, dist/agent-src/skills)",
-            "CLAUDE.md hierarchy (project + project-local)"
-        ],
-        "excluded_buckets": [
-            "user-scope rules (~/.claude/rules/*.md) — machine-dependent, not CI-checkable",
-            "tool definitions + dispatch prompt — no local source carries the request payload; the census reports it as an explicit residual"
-        ]
-    },
-    "baseline_tokens": 102520,
-    "baseline_history": [
-        {
-            "tokens": 102599,
-            "at": "2026-07-30",
-            "why": "registered with the gate"
-        },
-        {
-            "tokens": 102520,
-            "at": "2026-07-31",
-            "why": "free tightening: the measured tree came in 79 tok under the registered baseline, so the ratchet walks down to meet it. Not a claimed reduction — nothing was optimised; the point of a ratchet is that a lower measurement becomes the new ceiling instead of becoming unused headroom."
-        }
+  "_comment": "Per-spawn preamble payload ceiling (road-to-cache-economy Phase 3), unblocked by C-3 measuring 38.0% against a 15% bar. This is a RATCHET, not the roadmap's literal candidate numbers: those (median 40k / p95 50k) were anchored to an upstream ~37k baseline, while this package's own deterministic in-repo payload is ~102.5k tokens \u2014 a hard 40k gate would be red on the day it lands and would teach the reader to ignore it. The ratchet fails on GROWTH instead, so the number can only walk down, and the 40k/50k target stays recorded as the destination. Only the deterministic, in-repo buckets are gated: user-scope rules depend on what the developer happens to have installed globally and are therefore not CI-checkable.",
+  "schema_version": 1,
+  "registered_at": "2026-07-30",
+  "owner": "maintainer",
+  "review_by": "2027-07-30",
+  "metric": {
+    "basis": "chars/4 token estimate over the projected tree, produced by src/scripts/preamble_byte_census.ts",
+    "gated_buckets": [
+      "project-scope rules (dist/agent-src/rules/*.md)",
+      "preloaded skills catalog (name + description, dist/agent-src/skills)",
+      "CLAUDE.md hierarchy (project + project-local)"
     ],
-    "headroom_pct": 5,
-    "target_tokens": {
-        "median": 40000,
-        "p95": 50000,
-        "_comment": "The roadmap's candidate numbers, kept as the destination. Reaching them needs reductions this package has not built yet; scope-dedup (C-3) removes a redundant COPY at the consumer, it does not shrink the suite itself."
-    },
-    "target_schedule": {
-        "_comment": "road-to-inbox-harvest-2026-08-d-context-ledger Step 5.3. The target above was a destination with no route: the ratchet fails on GROWTH only, so the corpus can drift away from 40k indefinitely without any gate objecting. These milestones give the destination a schedule. They are DATES WITH NUMBERS, not a derivation - no measurement in this tree says the estate can reach 85k by a given day, and pretending otherwise would be the invented-threshold failure this file's own baseline_history is careful to avoid. What they buy is that a miss becomes a published fact with an owner instead of a silent drift.",
-        "owner": "maintainer",
-        "measured_at_registration": {
-            "tokens": 125593,
-            "at": "2026-08-15",
-            "note": "MEASURED total at registration time, from check_preamble_payload_budget. It is ~23k ABOVE both baseline_tokens (102520) and the derived ceiling, i.e. the gate is red on the tree as it stands. The baseline is deliberately NOT raised to meet it - raising a ratchet baseline to clear a failing check is the config-weakening move this repo blocks by construction. It is recorded here so the milestones below are planned against the real starting point rather than a stale one. Per-rule ranking: agents/evidence/analysis/rule-paths-coverage-census.md"
-        },
-        "milestones": [
-            {
-                "by": "2026-11-10",
-                "tokens": 102520,
-                "why": "Return to the registered baseline. This is a RECOVERY milestone, not progress toward 40k - it undoes drift rather than shrinking the estate. The date is the review_by both budget files already carry, so it needs no new calendar."
-            },
-            {
-                "by": "2027-02-10",
-                "tokens": 85000,
-                "why": "First real reduction. The rule-paths census shows 92.1% of rule weight sits in the auto tier and the top 20 files carry 35.5% of it, so a scoped tranche is the plausible mechanism - GATED on the paths-scoping consumer decision, which is a human call and may resolve against scoping entirely."
-            },
-            {
-                "by": "2027-05-10",
-                "tokens": 60000,
-                "why": "Second reduction. No mechanism is committed for this one; it exists so the destination keeps a date after the first tranche lands, and it is the milestone most likely to be revised on evidence."
-            }
-        ],
-        "on_miss": "A missed milestone is PUBLISHED - recorded here with the measured number and the reason - and never silently re-dated. Two consecutive misses mean the schedule was wrong or the destination is unreachable with the mechanisms available; either outcome is a decision to surface, not a date to move again.",
-        "revisit_if": "The paths-scoping decision resolves against scoping (removing the only named mechanism for the 85k milestone), or a measured reduction lands ahead of schedule and the remaining milestones are re-derived from it."
+    "excluded_buckets": [
+      "user-scope rules (~/.claude/rules/*.md) \u2014 machine-dependent, not CI-checkable",
+      "tool definitions + dispatch prompt \u2014 no local source carries the request payload; the census reports it as an explicit residual",
+      "personas (src/agent-src/personas, 36 files, ~37,181 tok) \u2014 measured ZERO standing cost 2026-08-22: .claude/personas/ is written by this repo's generators (5 in-repo references) and read by no host contract; the host's real subagent surface is .claude/agents/, which this package writes 1 file into. Reversal condition: a host publishing a personas contract, or a generator folding persona prose into an instruction file that IS read. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md",
+      "contexts (src/agent-src/contexts, 58 files, ~114,042 tok) \u2014 measured ON-DEMAND 2026-08-22: 0 rules declare load_context_eager: (17 declare the lazy load_context:), and rule.schema.json:49 documents eager as the variant that counts against the per-rule budget. This records that no eager declaration exists, NOT that eager loading would be free \u2014 nobody has declared one, so nobody has measured it. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md",
+      "skill bodies (src/skills/*/SKILL.md, 290 files, ~595,843 tok) \u2014 measured ON-DEMAND 2026-08-22: censusSkillsCatalog (preamble_byte_census.ts:216-234) builds the gated catalog bucket from `- name: description` per skill and reads no body byte, which is why 290 skills totalling ~595,843 tok report as ~14.4k standing. Corollary: the description cap is the WHOLE skill-side lever, not a fragment of it. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md"
+    ],
+    "_bucket_classification_note": "All three additions above are EXCLUSIONS, not gated buckets, and that is the finding rather than a shortcut. A census bucket over a corpus measured at zero is a permanently green gate certifying nothing. The exclusions carry their measurement so the next pass that proposes one of these corpora as a token lever meets the number instead of the silence."
+  },
+  "baseline_tokens": 102520,
+  "baseline_history": [
+    {
+      "tokens": 102599,
+      "at": "2026-07-30",
+      "why": "registered with the gate"
     },
-    "reference_measurements": {
-        "measured_cold_start_median_tokens": 230930,
-        "c3_scope_dedup_reduction_pct": 38,
-        "c3_condition": "FIXTURE-ONLY as of 2026-07-31: the 38% was measured on a byte-identical two-scope fixture, and that condition is currently unreachable for every consumer because install.ts:2723/2725 stamp package:/source_path: into every installed rule while the in-repo projection stamps nothing. Aligning versions yields 0/110 twins, not 110/110. The figure is the mechanism's ceiling, NOT a realised saving, and this baseline therefore assumes no dedup. Reachability is the subject of road-to-dedup-reachability; run measure_scope_dedup for the live split.",
-        "_comment": "The measured median comes from Claude Code transcripts (deduped by message.id + requestId) and is context for the ratchet, never the gated number — it moves with the developer's own session history."
+    {
+      "tokens": 102520,
+      "at": "2026-07-31",
+      "why": "free tightening: the measured tree came in 79 tok under the registered baseline, so the ratchet walks down to meet it. Not a claimed reduction \u2014 nothing was optimised; the point of a ratchet is that a lower measurement becomes the new ceiling instead of becoming unused headroom."
     }
+  ],
+  "headroom_pct": 5,
+  "target_tokens": {
+    "median": 40000,
+    "p95": 50000,
+    "_comment": "The roadmap's candidate numbers, kept as the destination. Reaching them needs reductions this package has not built yet; scope-dedup (C-3) removes a redundant COPY at the consumer, it does not shrink the suite itself."
+  },
+  "target_schedule": {
+    "_comment": "road-to-inbox-harvest-2026-08-d-context-ledger Step 5.3. The target above was a destination with no route: the ratchet fails on GROWTH only, so the corpus can drift away from 40k indefinitely without any gate objecting. These milestones give the destination a schedule. They are DATES WITH NUMBERS, not a derivation - no measurement in this tree says the estate can reach 85k by a given day, and pretending otherwise would be the invented-threshold failure this file's own baseline_history is careful to avoid. What they buy is that a miss becomes a published fact with an owner instead of a silent drift.",
+    "owner": "maintainer",
+    "measured_at_registration": {
+      "tokens": 125593,
+      "at": "2026-08-15",
+      "note": "MEASURED total at registration time, from check_preamble_payload_budget. It is ~23k ABOVE both baseline_tokens (102520) and the derived ceiling, i.e. the gate is red on the tree as it stands. The baseline is deliberately NOT raised to meet it - raising a ratchet baseline to clear a failing check is the config-weakening move this repo blocks by construction. It is recorded here so the milestones below are planned against the real starting point rather than a stale one. Per-rule ranking: agents/evidence/analysis/rule-paths-coverage-census.md"
+    },
+    "milestones": [
+      {
+        "by": "2026-11-10",
+        "tokens": 102520,
+        "why": "Return to the registered baseline. This is a RECOVERY milestone, not progress toward 40k - it undoes drift rather than shrinking the estate. The date is the review_by both budget files already carry, so it needs no new calendar."
+      },
+      {
+        "by": "2027-02-10",
+        "tokens": 85000,
+        "why": "First real reduction. The rule-paths census shows 92.1% of rule weight sits in the auto tier and the top 20 files carry 35.5% of it, so a scoped tranche is the plausible mechanism - GATED on the paths-scoping consumer decision, which is a human call and may resolve against scoping entirely."
+      },
+      {
+        "by": "2027-05-10",
+        "tokens": 60000,
+        "why": "Second reduction. No mechanism is committed for this one; it exists so the destination keeps a date after the first tranche lands, and it is the milestone most likely to be revised on evidence."
+      }
+    ],
+    "on_miss": "A missed milestone is PUBLISHED - recorded here with the measured number and the reason - and never silently re-dated. Two consecutive misses mean the schedule was wrong or the destination is unreachable with the mechanisms available; either outcome is a decision to surface, not a date to move again.",
+    "revisit_if": "The paths-scoping decision resolves against scoping (removing the only named mechanism for the 85k milestone), or a measured reduction lands ahead of schedule and the remaining milestones are re-derived from it."
+  },
+  "reference_measurements": {
+    "measured_cold_start_median_tokens": 230930,
+    "c3_scope_dedup_reduction_pct": 38,
+    "c3_condition": "FIXTURE-ONLY as of 2026-07-31: the 38% was measured on a byte-identical two-scope fixture, and that condition is currently unreachable for every consumer because install.ts:2723/2725 stamp package:/source_path: into every installed rule while the in-repo projection stamps nothing. Aligning versions yields 0/110 twins, not 110/110. The figure is the mechanism's ceiling, NOT a realised saving, and this baseline therefore assumes no dedup. Reachability is the subject of road-to-dedup-reachability; run measure_scope_dedup for the live split.",
+    "_comment": "The measured median comes from Claude Code transcripts (deduped by message.id + requestId) and is context for the ratchet, never the gated number \u2014 it moves with the developer's own session history."
+  }
 }

package/src/config/publish-surface.json

@@ -0,0 +1,60 @@
+{
+  "_comment": "GENERATED by src/scripts/check_publish_surface.ts --write. Do not hand-edit. It records the resolved publish surface so a change to what ships is a diff a reviewer reads. `files[]` is an ALLOWLIST and it overrides .npmignore for anything under an included root — measured, after an attempt to strip compiled test artefacts via .npmignore had no effect because dist/ is an included root. That is why `negations` exists and why `npmignore_shadowed` is reported: a pattern the live payload contradicts is present and not doing what its author expected.",
+  "roots": [
+    "dist/agent-src/",
+    ".augment-plugin/",
+    ".claude-plugin/",
+    "src/config/",
+    "agents/templates/",
+    "dist/",
+    "docs/guidelines/",
+    "docs/contracts/persona-schema.md",
+    "docs/contracts/provider-lifecycle.md",
+    "docs/contracts/settings-classes.md",
+    "src/scripts/",
+    "src/server/schemas/",
+    "src/server/io/yamlIO.ts",
+    "src/shared/",
+    "src/install/",
+    "src/agent-src/scripts/",
+    "src/agent-src/templates/scripts/",
+    "src/templates/",
+    "tests/fixtures/hooks/",
+    "AGENTS.md",
+    "CHANGELOG.md",
+    "CONTRIBUTING.md",
+    "LICENSE",
+    "MIGRATION.md",
+    "README.md",
+    "llms.txt"
+  ],
+  "negations": [
+    "!dist/**/*.test.js",
+    "!dist/**/*.test.js.map",
+    "!dist/**/*.spec.js",
+    "!dist/**/*.spec.js.map"
+  ],
+  "npmignore": [
+    ".idea/",
+    ".vscode/",
+    ".phpunit.cache/",
+    "**/__pycache__/",
+    "**/*.pyc",
+    "*.swp",
+    "*.swo",
+    "*~",
+    "tmp/",
+    "agents/",
+    ".agent-settings",
+    ".DS_Store",
+    "Thumbs.db",
+    ".git/",
+    ".gitignore",
+    "composer.lock",
+    "vendor/"
+  ],
+  "npmignore_shadowed": [
+    "agents/"
+  ],
+  "shadowed_measured_in": "built tree (payload carries dist/cli/**)"
+}

package/src/config/requirements-trace-budget.json

@@ -0,0 +1,32 @@
+{
+  "_comment": "Growth-only ratchet over the LIVE population of the requirement-to-acceptance-to-evidence inventory (src/scripts/check_requirements_trace.ts). MEASURED AT REGISTRATION, NEVER A TARGET. What each number counts: `unlinked` is a declared trace row with no evidence ref at all; `unresolved` is an evidence ref that does not resolve at the CURRENT head; `dangling_ac` is an `[AC:<id>]` annotation on a verify line with no matching acceptance_id in the same file; `malformed` is an id that is not the reused claim-ledger kebab slug. All four may only walk DOWN. Population is `live` — the active corpus only. The fixture population (synthetic inputs that test the reader) and any frozen cohort (which may include archived files) are deliberately NOT in scope here: a maintainer-authored fixture is evidence about the reader rather than about uptake, and a count over archived roadmaps cannot fall, which would make the ratchet meaningless. Note the interaction the inventory's own header states: a completed roadmap can move from resolved to unresolved with no roadmap edit, because refs are evaluated at head. That is the intended reading and it means this ratchet can red on a deletion elsewhere in the tree — which is the point, not a defect.",
+  "schema_version": 1,
+  "owner": "maintainer",
+  "review_by": "2027-08-22",
+  "registered_at": "2026-08-22",
+  "population": "live",
+  "baseline": {
+    "unlinked": 0,
+    "unresolved": 0,
+    "dangling_ac": 0,
+    "malformed": 0
+  },
+  "measured_at_registration": {
+    "corpus": 25,
+    "files_declaring": 1,
+    "rows": 3,
+    "linked": 3,
+    "refs": 7,
+    "note": "One file declares, and it is this mechanism's own roadmap — dogfooded per its step 0.3 before any other roadmap was asked to carry the fields. Adoption is therefore 1 of 25 and is NOT evidence of uptake: a mechanism's author using it is the floor, not a signal. The three roadmaps step 2.1 originally named for dogfooding were all archived by sibling pull requests in the same drain run before any window opened, which is why the population model above exists at all."
+  },
+  "baseline_history": [
+    {
+      "at": "2026-08-22",
+      "unlinked": 0,
+      "unresolved": 0,
+      "dangling_ac": 0,
+      "malformed": 0,
+      "why": "Registered at the measured live reading on the commit that shipped the inventory. All four are zero because exactly one file declares and its refs all resolve — which is a fact about a corpus of one declarer, not a clean bill over 25 roadmaps. Shrink-only from here: a new trace row with no evidence ref, a ref that stops resolving, a dangling [AC:] annotation or a non-slug id each red this immediately, with no headroom. The honest limit is that a ratchet at zero over a single declarer cannot distinguish compliance from non-adoption, which is exactly the distinction the roadmap's own falsifier set is written to keep separate."
+    }
+  ]
+}

package/src/config/rule-stub-ceilings.json

@@ -44,7 +44,7 @@
         "slash-command-routing-policy": 77,
         "symfony-routing": 129,
         "ui-audit-gate": 1280,
-        "untrusted-input-defense": 845,
+        "untrusted-input-defense": 934,
         "upstream-proposal": 76
     },
     "history": [
@@ -82,6 +82,13 @@
             "from": 2185,
             "to": 2479,
             "reason": "One subsection, +294 tokens, for the `deferred_policy` contract field: a declared policy removes the synchronous options ROUND at closure without moving any row of the preservation test's routing table. It is obligation surface and it cannot live anywhere else. Not in the pointer target -- roadmap-progress-mechanics.md sits at 16,039 chars against check_depth_budget's 16,000-char ceiling, and that gate is a count ratchet whose next failure is a FIFTH over-ceiling file, so prose pushed there is the one move that turns a warn into a red. Not in the contract context either: Iron Law 3 is the gate being amended, and a reader who learns from roadmap-execution-contract that a field exists but never reads this rule would not know that `cancel-with-memo` still stops for the user. The three-row table is the delta in full; the reasoning, both alternatives and the reversibility argument went to the contract context's own decision comment. Condensed once before this raise (2509 -> 2411) by cutting a paragraph that restated the preservation test. AI council 2/2 (anthropic + openai) on the autonomy-defaults-sheet fork of road-to-user-out-of-the-loop, record agents/evidence/council/drain-blocker-dispositions-a.md. RE-BASED on merge with origin/main, 2026-08-20: this entry was authored against a base of 2117 and raised to 2411. main had independently raised the same ceiling 2117 -> 2185 for its own reason, so the merged tree measures 2479 and the honest arithmetic for THIS raise is 2185 -> 2479 -- the same +294 for the same subsection, re-based rather than re-argued. Recorded rather than silently regenerated because the gate's own failure text names a history-versus-ceilings disagreement as the signature of a hand-edited count, and a merge that quietly adopted one side's numbers would produce exactly that signature with nothing saying why."
+        },
+        {
+            "date": "2026-08-22",
+            "rule": "untrusted-input-defense",
+            "from": 845,
+            "to": 934,
+            "reason": "Six lines, +89 tokens, correcting a claim the section itself had made false. It said no content-scanning backstop existed and that a future one would be the first candidate to change enforced_by; injection_scan_hook.ts now exists, so the first half is false, and the second was always wrong because a warn-only hook cannot refuse and therefore cannot enforce. Every sentence left carries one of those claims. The measurement half -- slot, 15 channels, 99.00 percent recall, 0.85 percent false positives, the manifest keys -- did move to the pointer target, which is what cut the overshoot from +194 to +89; what stays is the rule's own enforcement disclosure, and a stub ceiling that forbids correcting a false statement about the rule's own enforcement is the wrong constraint applied to the right file."
         }
     ]
 }

package/src/scripts/_dispatch.bash

@@ -162,6 +162,11 @@ Tier 1 — power-user (release shape, audit, migration):
                              Usage: council:render <responses.json>
   council:status             Report whether an AI council is configured, and from where
                              (no API call, no spend)
+  council:grant-billing      Record the human yes that lets an exhausted plan quota
+                             retry on the metered rung, for ONE run.
+                             Usage: council:grant-billing <run-id>
+  council:revoke-billing     End a run-scoped billing grant (exit 0 when none)
+                             Usage: council:revoke-billing <run-id>
   council:quota              Show today's per-provider CLI-call usage against the
                              enforced cap; --reset <provider> --confirm clears one
                              (no API call, no spend)
@@ -1502,6 +1507,8 @@ main() {
     council:render)          cmd_council render "$@" ;;
     council:status)         cmd_council status "$@" ;;
     council:quota)           cmd_council quota "$@" ;;
+    council:grant-billing)   cmd_council grant-billing "$@" ;;
+    council:revoke-billing)  cmd_council revoke-billing "$@" ;;
     self-repair:status)      cmd_self_repair status "$@" ;;
     self-repair:release)     cmd_self_repair release "$@" ;;
     decision:memo)           cmd_decision_memo "$@" ;;