@event4u/agent-config 14.1.0 → 14.4.0

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

@@ -1,66 +1,66 @@
 {
-  "$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 — 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": {
-    "ci-parity:local-only": {
-      "count": 166,
-      "landed": "2026-08-13",
-      "note": "Gates that `task ci` runs and no workflow does — 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 → 106, undeclared_local_only 0 → 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 — 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 — 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.",
-      "falsifier": "./scripts-run src/scripts/check_ci_local_parity"
-    },
-    "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(...)` — 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 → 147 string-literal lines → 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 — 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 — 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→51 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→49 by the gate-hardening adoption PR: skill_collision_clusters and skill_overlap were repointed at the live skills tree via the shared resolver — two gates that had been reading the retired container and scoring 0 of 288 skills. Lowered 49→48 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 — a scorer reading the retired container and scoring 0 of 288 skills — 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→47 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 — 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."
-    },
-    "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` — 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."
-    },
-    "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') — e.g. build-buy-partner → adr-create, customer-research → po-discovery, gated-reach → 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 → 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_roadmap_blockers:decidability": {
-      "count": 26,
-      "landed": "2026-08-16",
-      "note": "Open blocker entries that are not yet DECIDABLE by the person who owns them — 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 — 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 — 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→37 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 — 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→34 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→29 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 — 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 — 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 → 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 — 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 → 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 — 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.",
-      "falsifier": "./scripts-run src/scripts/lint_roadmap_blockers --quiet"
-    },
-    "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 — 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 — top bucket 22%, no single systematic cause — 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."
-    },
-    "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 — 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 — `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 — 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 — 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) — 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_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 — 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."
-    },
-    "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 — 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 — 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 — 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_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` — the mechanism can decide from the situation, so the key should not exist — 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 — 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_source_size_budget": {
-      "count": 19611,
-      "landed": "2026-08-17",
-      "note": "Lowered 19,626 → 19,611 on 2026-08-17 by the release-gh-transient branch, and it is a LOWERING through extraction, never a raise — the −15 is against the trunk value, reproducible with `git stash && npx tsx src/scripts/check_source_size_budget.ts`. That branch hardened `release.ts` against GitHub's 5xx responses, which is exactly the kind of change that grows an already over-ceiling file: release.ts sits at 2,819 and carries 1,319 of this total. The retry loop, the transient classifier and the argv elider therefore went into a NEW module (`_lib/gh_transient.ts`, 74 lines, under the ceiling and contributing nothing here), leaving release.ts a 20-line wrapper. The payback came from the five call sites the wrapper replaced: each was a `run(['gh', …], {check, capture})` block spread over up to 17 lines, and each collapses to one `gh([…])` call. The ordering is the lesson and it matches the two entries below: extract, then measure — a wrapper written inline would have added ~20 lines and turned a hardening commit into a ratchet regression. Second lesson, learned the hard way on this same branch: pin the baseline ONCE, at the end. Two intermediate pins (19,606 then 19,612) made subsequent legitimate edits read as `N new` against numbers that had never been on the trunk.",
-      "falsifier": "./scripts-run src/scripts/check_source_size_budget --quiet"
+    "$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 — 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": {
+        "ci-parity:local-only": {
+            "count": 166,
+            "landed": "2026-08-13",
+            "note": "Gates that `task ci` runs and no workflow does — 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 → 106, undeclared_local_only 0 → 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 — 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 — 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.",
+            "falsifier": "./scripts-run src/scripts/check_ci_local_parity"
+        },
+        "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(...)` — 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 → 147 string-literal lines → 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 — 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 — 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→51 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→49 by the gate-hardening adoption PR: skill_collision_clusters and skill_overlap were repointed at the live skills tree via the shared resolver — two gates that had been reading the retired container and scoring 0 of 288 skills. Lowered 49→48 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 — a scorer reading the retired container and scoring 0 of 288 skills — 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→47 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 — 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."
+        },
+        "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` — 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."
+        },
+        "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') — e.g. build-buy-partner → adr-create, customer-research → po-discovery, gated-reach → 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 → 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_roadmap_blockers:decidability": {
+            "count": 20,
+            "landed": "2026-08-19",
+            "note": "Open blocker entries that are not yet DECIDABLE by the person who owns them — 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 — 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 — 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→37 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 — 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→34 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→29 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 — 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 — 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 → 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 — 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 → 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 — 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 → 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 …` 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** — the same failure the 34→29 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 — 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.",
+            "falsifier": "./scripts-run src/scripts/lint_roadmap_blockers --quiet"
+        },
+        "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 — 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 — top bucket 22%, no single systematic cause — 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."
+        },
+        "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 — 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 — `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 — 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 — 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) — 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_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 — 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."
+        },
+        "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 — 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 — 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 — 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_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` — the mechanism can decide from the situation, so the key should not exist — 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 — 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_source_size_budget": {
+            "count": 19571,
+            "landed": "2026-08-19",
+            "note": "Lowered 19,626 → 19,611 on 2026-08-17 by the release-gh-transient branch, and it is a LOWERING through extraction, never a raise — the −15 is against the trunk value, reproducible with `git stash && npx tsx src/scripts/check_source_size_budget.ts`. That branch hardened `release.ts` against GitHub's 5xx responses, which is exactly the kind of change that grows an already over-ceiling file: release.ts sits at 2,819 and carries 1,319 of this total. The retry loop, the transient classifier and the argv elider therefore went into a NEW module (`_lib/gh_transient.ts`, 74 lines, under the ceiling and contributing nothing here), leaving release.ts a 20-line wrapper. The payback came from the five call sites the wrapper replaced: each was a `run(['gh', …], {check, capture})` block spread over up to 17 lines, and each collapses to one `gh([…])` call. The ordering is the lesson and it matches the two entries below: extract, then measure — a wrapper written inline would have added ~20 lines and turned a hardening commit into a ratchet regression. Second lesson, learned the hard way on this same branch: pin the baseline ONCE, at the end. Two intermediate pins (19,606 then 19,612) made subsequent legitimate edits read as `N new` against numbers that had never been on the trunk. Lowered 19,611 -> 19,604 on 2026-08-19 by the long-horizon branch, and it is again a LOWERING through extraction rather than a raise. Worth recording because the branch is the first case the gate met that it had no answer for: two roadmaps of new behaviour whose footprint landed in three files that were ALREADY 3,962 lines over the ceiling before the work started, so the initial reading was +759 new. The council (2/2 seats, 2026-08-19) split between extracting and escalating and agreed on two negatives -- raising the baseline contradicts the gate's own words, and a preparatory refactor PR creates no headroom because lowering the baseline by N and then adding N back trips the gate at the same number. What closed it was seven extractions, each a cohesive unit moved UNCHANGED: mid_flight_fallback, fallback_config, response_render, py_parity, _lib/council_fallback_posture, _lib/council_fallback_wiring, _lib/council_settings_block (+ _lib/map_to_object, which had to move so the settings block could stop importing back into council_cli). Four duplicated call sites collapsed on the way -- the split/ask branch appeared three times and the projected-spend comparison twice, which is how a metered retry could have come to gate on different rules than the round it ran inside. The lesson the previous entry states holds and is now tested at scale: extract, then measure, and pin ONCE at the end -- an intermediate de-duplication briefly RAISED the total by 5, because in an over-ceiling file a shared helper's own docblock can cost more than the duplication it removes. Lowered 19,604 -> 19,571 on 2026-08-19, and this entry records a RED GATE before it records a lowering. The pin at 19,604 was taken at the end of the long-horizon extraction pass; the R2 completion review of that very branch then produced fixes that grew orchestrator.ts by 53 lines, and the gate went red at 19,656 -- 52 new, against a note in this file that claimed a lowering the tree no longer showed. The review caught it, not the author, which is the argument for reviewing a fix pass rather than only the work it fixes. Repaired the way this file's own text demands: by extracting, never by re-pinning. The spend gate came out whole into ai_council/spend_gate.ts -- CostBudget (the ceilings), _breach (the decision), OverrunEvent (what a crossing hands the operator) and the _total_usd arithmetic all three share, re-exported so no caller changed. Cohesive on its own terms: nothing in it calls a provider or knows what a round is. The refusal path of the unmetered escalation moved to mid_flight_fallback.refuseUnmeteredEscalation in the same pass, next to the runGatedRetry it mirrors. Second lesson, and it is the reason the first attempt only bought 5 lines: moving code INTO another over-ceiling file buys nothing, so check which files are actually over the line before choosing a destination -- the same shape as the note below where de-duplication briefly RAISED the total by 5.",
+            "falsifier": "./scripts-run src/scripts/check_source_size_budget --quiet"
+        }
     }
-  }
 }

package/src/config/gitignore-block.txt

@@ -102,6 +102,11 @@
 .agent-engagement.jsonl
 .agent-engagement.jsonl.bak
 
+# Agent config — org usage telemetry (Class-A records; default-off and
+# inactive without an org pack, never commit)
+.agent-telemetry.jsonl
+.agent-telemetry.jsonl.bak
+
 # Agent config — volatile runtime artefacts (machine-generated,
 # regenerated on demand, never committed). Single catch-all per the
 # Volatile Runtime policy: everything under agents/runtime/ is

package/src/config/hook-latency-budget.json

@@ -9,9 +9,48 @@
         "floor": "1 vCPU reference container (documented ceiling, not CI-enforced)"
     },
     "budgets_ms": {
-        "pre_tool_use": { "p95_ci": 150, "p95_1vcpu": 400 },
+        "pre_tool_use": { "p95_ci": 175, "p95_1vcpu": 400 },
         "any_hook_event": { "p95_ci": 250 }
     },
+    "gate_remeasure": {
+        "attempts": 1,
+        "_comment": "OFF (attempts 1 = measure once, no re-measure). The mechanism exists in bench_hook_latency.ts: under --gate a slot over its cap is re-measured and the MINIMUM p95 kept, because a load spike inside one 50-run sample moves p95 up and never down. It ships DISABLED because pre_tool_use_cap_derivation.why_not_a_retry_or_best_of_n rejected it as the first move on measured grounds — the spread is between runner CLASSES (p50 111-148 ms), not noise within one machine, so a slow runner measures slow twice. Two CI runs of the mechanism agree: it recovered 151->150 and 160->153, i.e. 1-7 ms against a 42 ms spread. Set attempts to 3 ONLY as the escalation that same block names, if the re-derived 175 cap starts flapping."
+    },
+    "normalized": {
+        "observe_only": true,
+        "p95_excess_ci": null,
+        "control": "node -e 0, measured through the identical spawnSync harness in the same run",
+        "_comment": "Observe-only measurement row, printed on every bench run and gating nothing. Every slot reading is spawn + interpreter start + bundle load + concern work, and only the last term is ours; the control isolates the process-spawn term so excess_ms = slot - control is closer to this tree's own cost than the raw reading. It exists to collect the data a future normalized gate would need, and to sharpen pre_tool_use_cap_derivation.revisit_if — which currently reads runner speed off the p50, a cheaper signal that needs no extra measurement. Arming this row would be a config change (p95_excess_ci + observe_only false), and the limitation below says why that is not justified today.",
+        "_measured_limitation_2026_08_19": "THE CONTROL UNDER-CORRECTS, measured, and this is recorded so nobody arms the row believing a property that was not shown. Same commit, two environments: darwin read slot 101 / control 45 / excess 56 ms; GitHub ubuntu read slot 151 / control 26 / excess 124 ms. The control went DOWN while the slot went UP, because node -e 0 covers interpreter startup only while a dispatch also loads a ~1 MB bundle and runs the concern chain — the dominant and varying term. So excess_ms is NOT portable across hardware classes. Whether it is nonetheless steadier than the absolute WITHIN one runner class is UNMEASURED: two CI runs read control 26/28 ms and excess 124/125 ms against raw first samples of 151/160, which is suggestive but n=2 and computed on post-re-measure values. Collect from the nightly before setting a bar, and keep the row observe-only if it does not hold rather than arming a second flapping gate."
+    },
+    "pre_tool_use_cap_derivation": {
+        "_comment": "Why p95_ci is 175 and not the 150 registered on 2026-07-27. 150 was NOT bent around a red check — it was measured to sit INSIDE the legitimate distribution, which concern-activation-policy.md § Deriving a threshold names as a false-positive generator by construction: `a threshold inside the legitimate distribution`. The gate was flapping on IDENTICAL code, and the flap was already diagnosed in this tree by road-to-per-turn-hook-economy step 0.5 — it names three main runs at 151, 152 and 117 ms and concludes cross-runner variance after step 0.4 excluded the CLI wrapper (2 ms). What was missing was never the diagnosis; it was moving the cap.",
+        "re_derived_at": "2026-08-19",
+        "rule_cited": "concern-activation-policy.md § Deriving a threshold — 'the observed legitimate distribution's 99th percentile, plus one'. The load-bearing half is 'outside the distribution'; a threshold inside it is a false-positive generator by construction.",
+        "rule_applied": "max + ~11%, i.e. 175 — NOT p99+1, and the substitution is deliberate rather than a slip. Over this sample p99+1 is 158 ms, which sits ONE millisecond above the observed max: that satisfies the rule's letter while leaving no room for a tail measured on 10 of 33 runs. The '+1' in the cited rule is calibrated to a shadow window that emits `would_fire` at several candidate thresholds and therefore knows its own distribution densely; this sample is 10 single points from CI logs and does not. Where the rule's precision assumption does not hold, the honest move is more headroom and a stated departure, not a number that borrows an authority it does not have.",
+        "measured_failure_rate": "5 of 33 tests.yml runs on main (15%) failed this step, 2026-08-16..18. Several of those runs carry a failure followed by a success for the SAME step, i.e. the standing workaround was re-running the job by hand.",
+        "observed_p95_ms_gated_cli_leg": {
+            "_comment": "One value per run, pre_tool_use, the `via cli` leg the gate actually compares. Every one is legitimate code — the reds differ from the greens only in which runner drew the job. SELECTION RULE, stated because it bounds the derivation: these 10 are the runs whose Static Checks log was read, not a sample designed for coverage — 6 greens and 4 reds picked from the head of the 33-run window, plus this branch's own PR run. The 5th red main run's value was never captured, so the true max over all 33 runs is UNRECORDED and may exceed 157 ms. That is the main reason the applied formula carries more headroom than p99+1.",
+            "green_main_runs": [115, 120, 146, 150, 150],
+            "red_main_runs_on_the_old_cap": [151, 152, 152, 154],
+            "red_main_runs_not_sampled": 1,
+            "pr_run_comment_only_diff": [157],
+            "spread": "115-157 ms, i.e. 42 ms of run-to-run variance on unchanged code — 24% of the new 175 ms cap and 28% of the old 150 ms one"
+        },
+        "why_not_a_retry_or_best_of_n": "A second bench on the same job would not help: the spread is between runner classes (p50 111-148 ms), not transient noise within one machine, so a slow runner measures slow twice. Retry logic is the escalation if 175 flaps, not the first move.",
+        "revisit_if": "The p50 — not the p95 — of a green run rises above 160 ms. Read the MEDIAN because that is the runner-speed indicator: the observed p50 range is 111-148 ms, so a p50 past 160 is outside every machine this window saw and is the cost itself growing. It then belongs to the owning roadmap (road-to-per-turn-hook-economy, D-2: the dispatcher's own payload read+parse, once per event) rather than to a third cap raise. Raising this number again without a measured distribution beside it is the config-bending this block exists to make visible.",
+        "_revisit_if_correction": "First written as 'a green run measures p95 above 160 ms', which round 2 finding 9 refuted from inside this same block: 160 sits 15 ms BELOW the new cap and 3 ms above the observed max, so the very first green 161 ms run would pass the gate and simultaneously trip a trigger declaring the variance to be over. A trigger has to live outside the spread its own cap absorbs, and on a p95 with 42 ms of runner spread no such point exists below 175. The p50 has a spread of 37 ms and a ceiling of 148, so it does."
+    },
+    "per_turn_composite": {
+        "_comment": "D-1 of road-to-per-turn-hook-economy: the slot budgets above gate per EVENT, and a single tool call fires both pre_tool_use and post_tool_use with their full concern chains. A ten-tool-call turn therefore pays twenty dispatcher cold starts plus the prompt and stop slots while every individual slot stays green — the number the user experiences has no row. This row is that number. Registered by step 4.1; the CEILING is step 4.2 and is the maintainer's, so the row ships observe-only and CANNOT fail a build. Definition before bar, deliberately: two people computing two different composites would both call the row green.",
+        "definition": "(pre_tool_use + post_tool_use) * tool_calls + user_prompt_submit + stop",
+        "aggregation": "p50",
+        "_aggregation_note": "Documentation of the code, not an input to it: the bench reads tool_calls from this file but hardcodes the p50 aggregation and re-implements the formula, so editing `aggregation` or `definition` changes nothing. Kept because a row whose meaning lives only in a TS file is unreadable here; corrected from silence to a stated non-binding after the R2 review flagged both keys as unread.",
+        "tool_calls": 10,
+        "observe_only": true,
+        "p50_ci": null,
+        "_observe_only_note": "While observe_only is true the bench PRINTS the composite on every run, including the CI gate run, and never fails on it. Setting p50_ci to a number and observe_only to false is the whole of step 4.2 — no code change is needed to arm it. Do not arm it from a single run: the composite sums four slot measurements and multiplies two of them by tool_calls, so it accumulates runner variance faster than any single slot (risk 5), which is why the same absolute-cap-plus-pathology-net posture the slots use applies here too."
+    },
     "regression_gate": {
         "max_regression_pct": 200,
         "_comment": "Pathology net only — the ABSOLUTE budgets above are the binding gate for wall-clock. The original 20% window was falsified by measured GitHub-runner variance: two CI runs of IDENTICAL code measured p95 77-89 ms and 92-103 ms (+23% run-to-run, 2026-07-27, runs 30303438480 / round-2 tests.yml). Same rationale as the regression_pct 200 override on the evaluator timing budgets: a tight creep rule on shared-runner wall-clock flaps; sizes/counts keep tight windows, timings get absolute caps."

package/src/config/hook-token-budget.json

@@ -42,6 +42,22 @@
         "pre_compact": 2048,
         "agent_error": 1024
     },
+    "per_turn_aggregate_bytes": {
+        "_comment": "road-to-standing-context-40k Phase 4 step 4.1 — the sum the USER feels, which no row above could see. The per-slot caps bound ONE fire; a turn fires user_prompt_submit once, pre_tool_use and post_tool_use once per tool call, and stop once, so the number a turn actually injects is a multiple of them and was unregistered. This row is the injection twin of `per_turn_composite` in hook-latency-budget.json: same definition shape, same tool_calls, different unit. bench_hook_injection derives and prints it on every run; the DISPATCHER enforces `ceiling_bytes` at runtime by dropping lowest-severity advisories first (src/scripts/hooks/injection_budget.ts), exempting severity:blocking and fail_closed concerns by construction so the policy can never hide a safety-relevant warning.",
+        "owner": "maintainer",
+        "review_by": "2026-11-10",
+        "definition": "(pre_tool_use + post_tool_use) x tool_calls + user_prompt_submit + stop",
+        "tool_calls": 10,
+        "tool_calls_rationale": "Taken verbatim from hook-latency-budget.json's per_turn_composite rather than re-derived. Two definitions of 'a representative turn' in one repo is how two people compute two different composites and both call their row green.",
+        "slots_counted": ["user_prompt_submit", "pre_tool_use", "post_tool_use", "stop"],
+        "excluded_slots": ["session_start", "session_end", "pre_compact", "agent_error"],
+        "excluded_slots_rationale": "session_start is excluded BY THE STEP: it is the one-shot restore slot that legitimately carries hot-context, handoff-context and the canary contract, and capping it against a per-turn number would evict exactly the payloads it exists to deliver. The other three are not per-turn events at all.",
+        "ceiling_bytes": 47104,
+        "ceiling_derivation": "NOT a fresh number, and deliberately so: it is the arithmetic consequence of the per_slot_sum_caps_bytes rows already registered above — 4096 + (2048 + 2048) x 10 + 2048. A tighter per-turn ceiling would contradict per-slot rows that are already the committed decision, and a looser one would let the composition exceed what every part was capped at. Tightening it is a decision about those rows, taken there, in a PR.",
+        "gate_on_ceiling": false,
+        "gate_on_ceiling_rationale": "The bench REPORTS the aggregate but does not red the build on it yet — the first-reading discipline the latency twin's observe_only flag encodes. Measured 2026-08-19 under the committed fixtures: ~1,142 B against a 47,104 B ceiling, i.e. the row is registered roughly forty times above any reading that exists. The reading MOVES between runs — 922, 1,140 and 1,142 B observed within one hour — and the mechanism is worth naming precisely rather than as 'flaky': the stop-slot end-review-nudge sizes its line from the branch's own mutation volume, and replay skips its writes but not its reads, so the number grows as the working branch grows. That is a pre-existing bench non-determinism this row surfaces rather than introduces, and it is the strongest single reason not to arm the ceiling against it. Arming a ceiling nobody has ever approached would gate on an untested inequality. Runtime enforcement is NOT gated by this flag and is always on: this flag governs CI, the ceiling governs the live session.",
+        "honest_null_consequence": "If the census shows real turns sitting near the ceiling, the per-slot rows move first and this row follows from them. If real turns never approach it, the row is a bound that costs nothing and the finding is published at review date either way."
+    },
     "injection_load_metric": {
         "definition": "Roadmap 3.4: total injected bytes per session and per turn, hook-carried. The census mode of bench_hook_injection (--record) appends counts-only lines to agents/runtime/state/injection-census.jsonl; the caps above are the thresholds; breach trend at review date decides tighten vs relax — by evidence, in a PR. The census is also the repeat-injection-census blocker's instrument (one instrumented week ranks the repeaters for the 3.3 idempotency gate).",
         "privacy": "census lines carry {ts, slot, concern, bytes} — counts and ids only, never content"
@@ -56,6 +72,12 @@
             "instrument": "rule-trips.json warn counters for the skill-route concern (fires) + conformance audits for whether the pointed-at skill was opened (adoption); HONEST GAP: no deterministic counter exists for 'the agent acted on the pointer' - the numerator is audit-carried and registered as such rather than implied to be automatic",
             "threshold": "none committed before data - baseline first, threshold at review date (2026-11-10)"
         },
+        "skill_route_bare_suppression_rate": {
+            "definition": "road-to-catalogue-host-fit Phase 3 step 3.2: of the prompts where skill-route FIRES, the share whose warn reason carries `N suppressed as host-bare` - i.e. how often a skill the ranker wanted to POINT AT is one the current host is KNOWN to have delivered without its description. `N` counts the pointer window (TOP_K of the unfiltered ranking), never the whole ranked list: `rank` returns every non-zero-scoring skill, so counting the tail would let a bare name at rank 40 - never pointable, never a loss - bump the count on nearly every fire (R2 finding 1). Registered beside skill_route_pointer_rate because it measures the same concern's behaviour under the same owner and review date. NO THRESHOLD IS COMMITTED, and the refusal is inherited from the sibling rather than restated: the FILTER is derived from a measurement (all 16 bare entries in the 2026-08-12 claude observation are in the ranker's catalogue, `capture_skill_catalogue --pointable-bare`), the OUTCOME - whether suppressing them changes what the agent does - is not.",
+            "instrument": "the dispatcher's warn reason string for the skill-route concern (`, N suppressed as host-bare`, appended only when non-zero) + agents/evidence/metrics/skill-catalogue.jsonl for the population; TWO HONEST GAPS, both registered as gaps rather than implied to be automatic. (1) rule-trips.json counts fires per concern and does NOT retain the reason, so the numerator is log-carried, not counter-carried - the same posture the sibling metric takes for its own audit-carried numerator. (2) TOTAL suppression is INVISIBLE here by construction (R2 finding 4): when the filter empties the pointer set the concern returns before writing stdout, so no reason line exists for the one case the roadmap calls load-bearing. `RouteDecision.suppressed` carries it at the API boundary and nothing reads that in production.",
+            "threshold": "none committed before data - baseline first, threshold at the shared review date (2026-11-10)",
+            "falsifiers": "For the FILTER half only, never for the outcome. UPPER: a live rate far above the share of the pointer window the host degrades means the ranker preferentially ranks exactly what the host drops - a finding about the projection, which belongs to Phase 2. Name the populations rather than a bare ratio, because three different denominators are in play and an earlier draft of this row conflated them (R2 finding 11): the 2026-08-12 claude observation carries `entries_total` 336, of which only 35 were enumerated at all (16 bare + 19 described), against a ranker catalogue of 338 entries at probe time. The comparable share is 16 of the 35 ENUMERATED entries; 16/336 and 16/338 describe different things and neither is this metric's denominator. LOWER: a rate of 0 does NOT establish that the ranker and the host's bare set fail to intersect - gap (2) above makes complete suppression indistinguishable from no suppression in this instrument. `capture_skill_catalogue --pointable-bare` is the instrument that separates them, and it must be read before any zero here is interpreted."
+        },
         "full_rewrite_small_diff_rate": {
             "definition": "edit-shape fires / Write calls per session (the full-rewrite-with-small-diff rate). Kill criterion per the shipped nudge standard: a nudge whose verdicts are measurably ignored (adoption near zero over the review window, from conformance audits) gets its trigger tightened or the injected line removed.",
             "instrument": "rule-trips.json warn counters (the dispatcher already counts every warn per concern) + conformance audits for adoption"

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

@@ -1,6 +1,6 @@
 {
     "_comment": "Per-rule stub ceilings (road-to-rule-stub-projection Phase 2). One exact-BPE token ceiling per rule carrying a migration pointer. SHRINK-ONLY: a rule may fall below its ceiling freely, and may not rise above it. Raising a ceiling to clear a failing check is the config-weakening move this repo blocks by construction — every raise needs a `history` entry whose `reason` is a real sentence. The ceilings are a floor-plus-residue SNAPSHOT taken at adoption, not a target: a rule at its ceiling is not thereby correct, only not worse. Regenerate with `check_rule_stub_ceiling --write-baseline`; never hand-edit the counts.",
-    "measured_at_commit": "d8e2ee655",
+    "measured_at_commit": "4fae6e5b7",
     "tokens_exact": true,
     "ceilings": {
         "active-remediation": 1601,
@@ -38,7 +38,7 @@
         "provider-lifecycle-discipline": 472,
         "reviewer-awareness": 131,
         "roadmap-ci-steps-policy": 564,
-        "roadmap-progress-sync": 1424,
+        "roadmap-progress-sync": 2117,
         "rule-type-governance": 87,
         "skill-improvement-trigger": 81,
         "skill-quality": 78,
@@ -48,5 +48,13 @@
         "untrusted-input-defense": 845,
         "upstream-proposal": 76
     },
-    "history": []
+    "history": [
+        {
+            "date": "2026-08-19",
+            "rule": "roadmap-progress-sync",
+            "from": 1424,
+            "to": 2117,
+            "reason": "Iron Law 3 gained the preservation test that decides WHO resolves a deferred item — a routing table plus the two council refinements that make it binding (a follow-up naming a roadmap that does not exist yet fails closed to the user; a council resolution is recorded at the item or it did not happen) and the residual limit both authoring seats named. This is obligation surface, not explanation: the table decides a route and the two refinements are the conditions under which the route is legal, so a reader who reaches only the pointer target has already made the decision. It could not move to the pointer target either — roadmap-progress-mechanics.md sits at the 16,000-char check_depth_budget ceiling in this same change, and pushing prose there reds a count ratchet whose whole job is refusing a fifth over-ceiling file. The section was condensed once before this raise (2201 -> 2117) by turning four prose paragraphs into bullets; further cutting would delete substance, which preservation-guard forbids."
+        }
+    ]
 }

package/src/scripts/_dispatch.bash

@@ -170,6 +170,18 @@ Tier 1 — power-user (release shape, audit, migration):
                              pushed, else an issue. Running it is your Hard-Floor
                              confirmation.
                              Usage: self-repair:release <fingerprint> [--dry-run]
+  decision:memo              Record or list a question the run resolved without
+                             asking you, so it stays reviewable afterwards.
+                             Local-only (gitignored); the locked decision
+                             classes are refused at the config schema, not here.
+                             Usage: decision:memo write --run <id> --question <q>
+                             --chosen <c> --reasoning <r> --resolver <who>
+                             --confidence <high|medium|low>
+                                    decision:memo list --run <id>
+  run:supervise              Report runs whose session died with open steps
+                             left. Report-only; --relaunch is the acting path.
+                             NEVER merges, pushes, or closes anything.
+                             Usage: run:supervise --once [--root PATH]
 EOF
   fi
 
@@ -217,7 +229,11 @@ Tier 2 — maintenance / internal (hooks, MCP, memory, telemetry):
                              --json, --reply (reply-close form: the one blocking
                              decision in full, the rest as a count; prints
                              nothing when none are yours), --pending (staged
-                             requires_confirmation actions awaiting you)
+                             requires_confirmation actions awaiting you),
+                             --sheet (ONE consolidated decision sheet: every
+                             user-owned decision, sorted by unblock count, each
+                             with a default and that default's provenance —
+                             accept-all-defaults is a valid answer)
   capabilities:index         Regenerate CAPABILITIES.yaml — the package coverage index
                              (capability area → coverage → backing skills/commands → gaps).
                              Pass --check to fail if stale (for CI). Reads src/ (package repo).
@@ -1174,6 +1190,29 @@ cmd_self_repair() {
   exec_ts "$script" "$sub" "$@"
 }
 
+# `decision:memo {write,list}` — the decision-memo channel (UOTL Phase 4.3).
+# A question resolved without contacting the user is only legitimate if the
+# resolution is reviewable afterwards; this is where that record goes. Writes
+# under agents/runtime/state/decisions/<run>/, which is gitignored, so a memo
+# never reaches a commit unless a human copies it out.
+cmd_decision_memo() {
+  local sub="$1"; shift || true
+  local script
+  script="$(resolve_script "src/scripts/decision_memo.ts")" || return 1
+  exec_ts "$script" "$sub" "$@"
+}
+
+# `run:supervise` — the out-of-process watcher for runs whose session died
+# with open steps left. Report-only by default; the acting path is behind
+# --relaunch because starting a session spends tokens with nobody watching.
+# It NEVER merges, pushes, or closes anything — the auto-merge the reference
+# design carries is a named rejection, not an unbuilt feature.
+cmd_run_supervise() {
+  local script
+  script="$(resolve_script "src/scripts/run_supervise.ts")" || return 1
+  exec_ts "$script" "$@"
+}
+
 # `use --profile=<id>` — switch the active experience/profile. Writes
 # profile.id into the canonical .agent-settings.yml; the explicit
 # profile-switch seam named by ADR-040 (road-to-6.0.0-a Step 8).
@@ -1449,6 +1488,8 @@ main() {
     council:quota)           cmd_council quota "$@" ;;
     self-repair:status)      cmd_self_repair status "$@" ;;
     self-repair:release)     cmd_self_repair release "$@" ;;
+    decision:memo)           cmd_decision_memo "$@" ;;
+    run:supervise)           cmd_run_supervise "$@" ;;
     update)                  cmd_update "$@" ;;
     upgrade)                 cmd_upgrade "$@" ;;
     refresh)                 cmd_refresh "$@" ;;

package/src/scripts/_lib/council_fallback_posture.ts

@@ -0,0 +1,81 @@
+/**
+ * council_fallback_posture — "would this seat have an api rung to fall back
+ * to?", for `council:status`.
+ *
+ * Lives here rather than in `council_cli.ts` because that file is 2,700 lines
+ * over the source ceiling and the documented fix is extraction
+ * (`gate-violation-baselines.json` § check_source_size_budget).
+ *
+ * The posture is derived from the SAME two facts the twin factory in
+ * `build_members` uses — the provider has an api constructor, and its key
+ * resolves — so the line `council:status` prints and the retry that actually
+ * happens cannot disagree. It deliberately does not CONSTRUCT the client:
+ * `council:status` is the one command that must stay free of side effects.
+ */
+
+export type FallbackPosture = 'api' | 'none' | 'n/a';
+
+export interface PostureInput {
+    /** Resolved transport for this member; `null` when it did not resolve. */
+    readonly transport: string | null;
+    /** Does the provider have an api constructor at all? */
+    readonly hasApiRung: boolean;
+    /** The member's own `api_key_ref`, or `null` when it sets none. */
+    readonly apiKeyRef: string | null;
+    /** Does that explicit ref resolve? `undefined` when there is no ref. */
+    readonly refResolves: boolean | undefined;
+    /**
+     * The keyless loader for this provider, when one exists. Only anthropic
+     * and openai have one; the strict constructors refuse without an explicit
+     * ref. Probed rather than assumed — the generic loader can come up empty,
+     * and reporting `'api'` on the strength of the provider name would print
+     * a rung that is not there.
+     */
+    readonly keylessResolves: (() => boolean) | undefined;
+}
+
+/**
+ * `'n/a'` for a member that is not on the cli rung: there is nothing to fall
+ * back FROM, and reporting `'none'` there would read as a missing capability
+ * rather than an inapplicable question.
+ */
+export function fallbackPostureFor(input: PostureInput): FallbackPosture {
+    if (input.transport !== 'cli') return 'n/a';
+    if (!input.hasApiRung) return 'none';
+    if (input.apiKeyRef !== null) return input.refResolves === true ? 'api' : 'none';
+    if (input.keylessResolves === undefined) return 'none';
+    try {
+        return input.keylessResolves() ? 'api' : 'none';
+    } catch {
+        return 'none';
+    }
+}
+
+/**
+ * The `council:status` lines for the fallback posture.
+ *
+ * Returns `[]` when no seat is on the cli rung: there is nothing to fall back
+ * FROM, and a heading over an empty list reads as a missing capability.
+ */
+export function renderPostureLines(
+    postures: ReadonlyArray<readonly [string, FallbackPosture]>,
+    apiOnQuota: boolean,
+): string[] {
+    const live = postures.filter(([, p]) => p !== 'n/a');
+    if (live.length === 0) return [];
+    const lines = live.map(
+        ([name, p]) =>
+            `  fallback         ${name}: ` +
+            (p === 'api'
+                ? 'would fall back to api'
+                : 'no api rung — a lost cli transport loses the seat'),
+    );
+    // Separate from the per-seat lines: not a per-seat property but the one
+    // billing-class decision, governing every seat at once.
+    lines.push(
+        `  fallback quota   api_on_quota: ${apiOnQuota ? 'on' : 'off'}` +
+            ` — an exhausted cli quota ${apiOnQuota ? 'MAY' : 'may not'}` +
+            ' retry on the metered rung',
+    );
+    return lines;
+}