@event4u/agent-config 14.21.0 → 14.23.0

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

@@ -1,110 +1,117 @@
 {
-    "_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)"
-        ],
-        "excluded_buckets": [
-            "user-scope rules (~/.claude/rules/*.md) \u2014 ALREADY COUNTED, inside the `project-scope rules` gated bucket; excluded here only to avoid double-counting. CORRECTED 2026-08-30 (road-to-agent-turnaround 4.2, AI council 2/2 over two rounds). The previous reason read \"machine-dependent, not CI-checkable\", and that was FALSE in both halves: the layer is written by this package's own installer out of dist/agent-src/rules/, and which rules reach the GLOBAL layer rather than the project one is decided by frontmatter (`workspaces:` naming the maintainer workspace), not by anything on the developer's machine. `preamble_byte_census.censusDeliveredRulePayload` computes it from the projection alone, reading nothing under ~/. Measured 2026-08-30: 119 projected \u2212 15 package-only = 104 delivered, matching the installed file count exactly; the 1.5 % char gap against the machine reading is install drift. Round 1 of the council voted to GATE the bucket on the premise that its bytes were invisible to CI; round 2 was given the checker's bucket definitions, found the 104 are a SUBSET of the 119 the gate already measures in full, and chose (a\u2032): correct the reason, add the reconciliation test, leave the baseline alone. Adding the bucket would have moved the baseline ~111k for zero additional delivered payload. What remains genuinely unreported by this GATE is the 104 / 13 / 2 destination split, which the CENSUS now prints \u2014 the council placed it there until distinct destinations need independent budget enforcement.",
-            "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"
-        },
-        {
-            "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."
-        }
+  "_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)"
     ],
-    "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 REFUSES. Corrected 2026-08-24 (AC-3): this used to assert the repo blocks it structurally -- the exact phrase is deliberately not reproduced here, because AC-3's check is a grep and quoting a retracted claim would leave the string in the file it was removed from. It over-claimed the mechanism. `block_config_weakening` is a PreToolUse guard that warns from five allowlist entries and blocks past twenty, is honoured only on the one host that denies, and does not gate a baseline edit at all -- a rising count there may be a legitimate ratchet reset the edit alone cannot distinguish. The refusal is real and it is carried by review and by this file's own record, not 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."
-    },
-    "ci_delivery": {
-        "workflow": ".github/workflows/standing-payload-delta.yml",
-        "trigger": "pull_request",
-        "posture": "blocking_on_ceiling_breach_with_grace_ceiling",
-        "design_ceiling": 107646,
-        "grace_ceiling": 138273,
-        "grace_measured_at": "2026-09-02",
-        "grace_end_date": "2026-11-10",
-        "decision": "OPTION (b) of b-preamble-ci-placement: fold into the existing standing-payload-delta.yml rather than add a per-PR job or a scheduled main job. That workflow already computes the neighbouring number and already DECLINED to fail on the premise that this gate 'already fails on growth' -- a premise that was false, because nothing in .github/ ran this gate at all. Making it fail is the smallest change that removes the contradiction instead of adding a third surface. AI council 2026-08-24, 2/2 convergent, on a maintainer delegation.",
-        "why_a_single_ci_run_is_enough": "The 'per-spawn' in this metric's name describes WHERE the cost is paid, not random sampling. The measurement is a deterministic census of revision-controlled inputs -- rules, the skill catalogue and CLAUDE.md, all read from the checkout -- so one CI run represents the checked-out revision exactly. Variation between two runs on the same commit would be a CHECKER DEFECT, never budget noise, and is asserted against by the repeatability test in tests/scripts/check_preamble_payload_budget.test.ts. Both council seats rejected the single-sample objection on this ground.",
-        "why_a_grace_ceiling": "HEAD measures 138,212 against a design ceiling of 107,646 -- 28.4 % over. Making the gate blocking at the design ceiling would fail EVERY pull request from the moment it lands, which is a self-inflicted CI stop rather than a gate: nobody can reduce 30,566 tokens inside the PR that turns the gate on. The grace ceiling is set AT the measurement so growth beyond today reds immediately while today's tree passes, and it ratchets DOWN toward the design ceiling as reductions land. It may never move UP. It expires at the milestone-1 date, at which point the design ceiling applies.",
-        "honest_limit": "Editing this workflow makes it FAIL; it does not make it REQUIRED. Whether a failing check blocks a merge is branch-protection configuration, which is a repo-admin action outside this change and outside an autonomous run. So the claim this record supports is 'the gate can now fail a PR', never 'the gate now blocks a merge'. Verify the latter with `gh api repos/:owner/:repo/rulesets` rather than by reading this file.",
-        "grace_ceiling_history": [
-            {
-                "from": 138212,
-                "to": 138273,
-                "at": "2026-09-02",
-                "why": "code-comment-discipline gained three Iron Law lines: a comment naming where the code came from is evidence in the wrong place, provenance is not a WHY, and a roadmap cannot license a comment the rule forbids. +61 tok after two condensations \u2014 the section was first written at +546, moved to its pointer target (code-clarity.md) at +172, and folded into the existing Iron Law block rather than opening a second one at +61. What remains is obligation surface that preservation-guard forbids condensing further, and it cannot move to the guideline because a rule whose Iron Law is elsewhere is a rule nobody reads. The defect it closes was measured, not argued: 509 German comment lines and 21 report- or provenance-shaped comments across 41 of 45 changed source files in a consumer repository, with both governing rules holding an enforcement hole \u2014 one naming a .md-only validator for a source-file clause, the other naming no enforcer at all. This raises the GRACE ceiling, which is a dated window (expires 2026-11-10), not the design ceiling of 107646, which this tree passed long before this change."
-            }
-        ]
+    "excluded_buckets": [
+      "user-scope rules (~/.claude/rules/*.md) — ALREADY COUNTED, inside the `project-scope rules` gated bucket; excluded here only to avoid double-counting. CORRECTED 2026-08-30 (road-to-agent-turnaround 4.2, AI council 2/2 over two rounds). The previous reason read \"machine-dependent, not CI-checkable\", and that was FALSE in both halves: the layer is written by this package's own installer out of dist/agent-src/rules/, and which rules reach the GLOBAL layer rather than the project one is decided by frontmatter (`workspaces:` naming the maintainer workspace), not by anything on the developer's machine. `preamble_byte_census.censusDeliveredRulePayload` computes it from the projection alone, reading nothing under ~/. Measured 2026-08-30: 119 projected − 15 package-only = 104 delivered, matching the installed file count exactly; the 1.5 % char gap against the machine reading is install drift. Round 1 of the council voted to GATE the bucket on the premise that its bytes were invisible to CI; round 2 was given the checker's bucket definitions, found the 104 are a SUBSET of the 119 the gate already measures in full, and chose (a′): correct the reason, add the reconciliation test, leave the baseline alone. Adding the bucket would have moved the baseline ~111k for zero additional delivered payload. What remains genuinely unreported by this GATE is the 104 / 13 / 2 destination split, which the CENSUS now prints — the council placed it there until distinct destinations need independent budget enforcement.",
+      "tool definitions + dispatch prompt — 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) — 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) — 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 — 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) — 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"
     },
-    "status_2026_08_24": {
-        "state": "at_risk",
-        "measured": 138212,
-        "target": 102520,
-        "target_date": "2026-11-10",
-        "delta_from_target": 35692,
-        "delta_from_registration": 12619,
-        "registration_measurement": 125593,
-        "registered_at": "2026-08-15",
-        "decision": "PUBLISH AND HOLD. The adverse drift is recorded now and the original milestone date is retained. This is an EARLY RISK PUBLICATION, not a milestone miss -- 2026-11-10 has not arrived, and recording a miss before its date would be as wrong as re-dating silently. The file's own on_miss clause ('a missed milestone is PUBLISHED ... and never silently re-dated') applies at the date; this entry is the early warning that keeps the date falsifiable. AI council 2026-08-24, 2/2.",
-        "trajectory": "+12,619 tokens in the nine days from 2026-08-15 to 2026-08-24, i.e. roughly +1,400/day. Reaching 102,520 by 2026-11-10 from 138,212 needs a NET REDUCTION averaged over the remaining 78 days, against a measured net growth. One seat argued the derivative already falsifies the schedule model and that holding for a second miss preserves a signal nobody will act on; the other argued that holding is what keeps the checkpoint falsifiable at all. Recorded unresolved rather than settled, because both readings are defensible and the measurement is what decides between them on 2026-11-10.",
-        "committed_reduction_mechanism": "NONE. Stated explicitly because its absence is the finding: no mechanism in the tree is committed to closing 35,692 tokens by 2026-11-10. road-to-cost-parity-1-rule-payload-diet and road-to-standing-context-40k both name reductions and neither is executing. A schedule with no mechanism is a date, not a plan, and this field exists so the next reader does not have to infer that from silence."
+    {
+      "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."
     }
+  ],
+  "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 REFUSES. Corrected 2026-08-24 (AC-3): this used to assert the repo blocks it structurally -- the exact phrase is deliberately not reproduced here, because AC-3's check is a grep and quoting a retracted claim would leave the string in the file it was removed from. It over-claimed the mechanism. `block_config_weakening` is a PreToolUse guard that warns from five allowlist entries and blocks past twenty, is honoured only on the one host that denies, and does not gate a baseline edit at all -- a rising count there may be a legitimate ratchet reset the edit alone cannot distinguish. The refusal is real and it is carried by review and by this file's own record, not 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 — it moves with the developer's own session history."
+  },
+  "ci_delivery": {
+    "workflow": ".github/workflows/standing-payload-delta.yml",
+    "trigger": "pull_request",
+    "posture": "blocking_on_ceiling_breach_with_grace_ceiling",
+    "design_ceiling": 107646,
+    "grace_ceiling": 138490,
+    "grace_measured_at": "2026-09-08",
+    "grace_end_date": "2026-11-10",
+    "decision": "OPTION (b) of b-preamble-ci-placement: fold into the existing standing-payload-delta.yml rather than add a per-PR job or a scheduled main job. That workflow already computes the neighbouring number and already DECLINED to fail on the premise that this gate 'already fails on growth' -- a premise that was false, because nothing in .github/ ran this gate at all. Making it fail is the smallest change that removes the contradiction instead of adding a third surface. AI council 2026-08-24, 2/2 convergent, on a maintainer delegation.",
+    "why_a_single_ci_run_is_enough": "The 'per-spawn' in this metric's name describes WHERE the cost is paid, not random sampling. The measurement is a deterministic census of revision-controlled inputs -- rules, the skill catalogue and CLAUDE.md, all read from the checkout -- so one CI run represents the checked-out revision exactly. Variation between two runs on the same commit would be a CHECKER DEFECT, never budget noise, and is asserted against by the repeatability test in tests/scripts/check_preamble_payload_budget.test.ts. Both council seats rejected the single-sample objection on this ground.",
+    "why_a_grace_ceiling": "HEAD measures 138,212 against a design ceiling of 107,646 -- 28.4 % over. Making the gate blocking at the design ceiling would fail EVERY pull request from the moment it lands, which is a self-inflicted CI stop rather than a gate: nobody can reduce 30,566 tokens inside the PR that turns the gate on. The grace ceiling is set AT the measurement so growth beyond today reds immediately while today's tree passes, and it ratchets DOWN toward the design ceiling as reductions land. It may never move UP. It expires at the milestone-1 date, at which point the design ceiling applies.",
+    "decision_record": "docs/decisions/ADR-264-standing-payload-grace-ceiling-may-not-rise.md -- resolves the contradiction a reader hits in why_a_grace_ceiling above, which says the ceiling is 'set AT the measurement' AND that 'It may never move UP', while grace_ceiling_history records it moving up twice. ADR-264 decides AGAINST the measurement framing and FOR the cap: the ceiling may not rise, standing-rule growth needs a compensating reduction elsewhere, and the two recorded raises stand as violations caused by the contradictory wording rather than as precedent. It also designs, and deliberately does NOT ship, a 128-token aggregate Iron Law reserve -- because the deciding seat's own condition was that wording without enforcement and protected approval is an exploitable trust gap, and this citation is therefore the whole of this file's edit. No bound here is changed by it.",
+    "honest_limit": "Editing this workflow makes it FAIL; it does not make it REQUIRED. Whether a failing check blocks a merge is branch-protection configuration, which is a repo-admin action outside this change and outside an autonomous run. So the claim this record supports is 'the gate can now fail a PR', never 'the gate now blocks a merge'. Verify the latter with `gh api repos/:owner/:repo/rulesets` rather than by reading this file.",
+    "grace_ceiling_history": [
+      {
+        "from": 138273,
+        "to": 138490,
+        "at": "2026-09-08",
+        "why": "token-efficiency gained the one-command-per-Bash-call section: a permission rule, not a token one, closing a case where the rule ACTIVELY ENCOURAGED the most expensive shape (\"NOT write shorter commands: the long commands are already the batching\"). The host evaluates each segment of a compound command against the allowlist independently, so one unmatched segment sends the whole call down the permission path; chaining converts N cheap authorizations into one expensive one. +290 tok after two condensations — first written at +746, measured, then cut to +353 by migrating the numbers, the substitution table and the carrier limits to token-efficiency-mechanics (loaded on demand, and this file already classifies contexts/ as on-demand rather than standing), then to +290 by migrating the correction note as well. What remains is the Iron Law block plus two paragraphs, and preservation-guard forbids condensing an Iron Law further. It cannot move to the mechanics file either: a rule whose Iron Law lives elsewhere is a rule nobody reads. The defect is measured, not argued — over 40,268 real Bash calls, 97.7% carry a shell metacharacter and 17.9% have a head token matching no allowlist pattern, of which 5,037 are a leading VAR= assignment, a shape no allowlist pattern can express. This raises the GRACE ceiling, a dated window expiring 2026-11-10, never the design ceiling of 107646."
+      },
+      {
+        "from": 138212,
+        "to": 138273,
+        "at": "2026-09-02",
+        "why": "code-comment-discipline gained three Iron Law lines: a comment naming where the code came from is evidence in the wrong place, provenance is not a WHY, and a roadmap cannot license a comment the rule forbids. +61 tok after two condensations — the section was first written at +546, moved to its pointer target (code-clarity.md) at +172, and folded into the existing Iron Law block rather than opening a second one at +61. What remains is obligation surface that preservation-guard forbids condensing further, and it cannot move to the guideline because a rule whose Iron Law is elsewhere is a rule nobody reads. The defect it closes was measured, not argued: 509 German comment lines and 21 report- or provenance-shaped comments across 41 of 45 changed source files in a consumer repository, with both governing rules holding an enforcement hole — one naming a .md-only validator for a source-file clause, the other naming no enforcer at all. This raises the GRACE ceiling, which is a dated window (expires 2026-11-10), not the design ceiling of 107646, which this tree passed long before this change."
+      }
+    ]
+  },
+  "status_2026_08_24": {
+    "state": "at_risk",
+    "measured": 138212,
+    "target": 102520,
+    "target_date": "2026-11-10",
+    "delta_from_target": 35692,
+    "delta_from_registration": 12619,
+    "registration_measurement": 125593,
+    "registered_at": "2026-08-15",
+    "decision": "PUBLISH AND HOLD. The adverse drift is recorded now and the original milestone date is retained. This is an EARLY RISK PUBLICATION, not a milestone miss -- 2026-11-10 has not arrived, and recording a miss before its date would be as wrong as re-dating silently. The file's own on_miss clause ('a missed milestone is PUBLISHED ... and never silently re-dated') applies at the date; this entry is the early warning that keeps the date falsifiable. AI council 2026-08-24, 2/2.",
+    "trajectory": "+12,619 tokens in the nine days from 2026-08-15 to 2026-08-24, i.e. roughly +1,400/day. Reaching 102,520 by 2026-11-10 from 138,212 needs a NET REDUCTION averaged over the remaining 78 days, against a measured net growth. One seat argued the derivative already falsifies the schedule model and that holding for a second miss preserves a signal nobody will act on; the other argued that holding is what keeps the checkpoint falsifiable at all. Recorded unresolved rather than settled, because both readings are defensible and the measurement is what decides between them on 2026-11-10.",
+    "committed_reduction_mechanism": "NONE. Stated explicitly because its absence is the finding: no mechanism in the tree is committed to closing 35,692 tokens by 2026-11-10. road-to-cost-parity-1-rule-payload-diet and road-to-standing-context-40k both name reductions and neither is executing. A schedule with no mechanism is a date, not a plan, and this field exists so the next reader does not have to infer that from silence."
+  }
 }

package/src/config/publish-surface.json

@@ -19,6 +19,7 @@
     "src/agent-src/scripts/",
     "src/agent-src/templates/scripts/",
     "src/templates/",
+    "src/vendor/grammars/",
     "tests/fixtures/hooks/",
     "AGENTS.md",
     "CHANGELOG.md",
@@ -61,7 +62,8 @@
     "vendor/"
   ],
   "npmignore_shadowed": [
-    "agents/"
+    "agents/",
+    "vendor/"
   ],
-  "shadowed_measured_in": "built tree (payload carries dist/cli/**)"
+  "shadowed_measured_in": "unbuilt tree (payload carries no dist/cli/**)"
 }

package/src/config/routing-coverage-seed.json

@@ -9,11 +9,11 @@
         "skills": "src/skills/*/evals/triggers.json over src/skills/*/SKILL.md."
     },
     "seed": {
-        "rules": 0.8952,
+        "rules": 0.9619,
         "skills": 0.3344
     },
     "seed_provenance": {
-        "rules": "94 covered of 105 routed rules (tier-1 21/24, tier-2 73/81) on 2026-08-25.",
+        "rules": "101 covered of 105 routed rules on 2026-09-08; was 94 of 105 (tier-1 21/24, tier-2 73/81) on 2026-08-25.",
         "skills": "100 of 299 skills carry evals/triggers.json on 2026-08-30.",
         "finding": "The gap between the two seeds IS the roadmap defect D1, quantified. The rules surface is ~90% covered by a deterministic corpus that can fail a PR; the skills surface -- the one production routes on -- is 25%, covered only by a harness that is advisory only, never gating (rule_trigger_eval.ts:4)."
     },
@@ -38,6 +38,13 @@
             "from": 0.3144,
             "to": 0.3344,
             "reason": "road-to-governed-harness-evolution Phase 2.4 authored six wave-1 corpus files (94 -> 100 of 299), chosen by 2.2's inbound-confusion-edge ordering rather than picked. The seed rises so the gain cannot be given back silently; it may never be LOWERED. Surfaced by check_routing_coverage.test.ts, which asserts seed == live measurement in BOTH directions -- a seed left below the tree is a red test, not slack, which is the same asymmetry check_source_size_budget uses and for the same reason: nothing else would force the ratchet to follow a gain."
+        },
+        {
+            "date": "2026-09-08",
+            "scope": "rules",
+            "from": 0.8952,
+            "to": 0.9619,
+            "reason": "road-to-delivery-for-every-host authored seven routing-matrix fixtures -- council-availability, evaluator-independence, fix-what-you-see, missing-skill-recovery, playbook-precedence, recurring-criticism, self-repair-loop (94 -> 101 of 105 routed rules). First entry on the RULES scope; the three above are all skills. The seed rises because this file's own test asserts seed == live measurement in both directions, so the gain would otherwise red the suite for doing what the ratchet encourages. It may never be LOWERED."
         }
     ]
 }

package/src/install/claudeLayerCarriage.ts

@@ -0,0 +1,273 @@
+/**
+ * Does the CLAUDE host-global layer already carry a given artefact?
+ *
+ * **Why this module exists — the veto it replaces.**
+ *
+ * ADR-236 partitions artefacts between `~/.claude/**` and `<repo>/.claude/**`.
+ * Its first implementation asked ONE question for the whole run: does
+ * `installed.lock` record the same version as this checkout, and does a content
+ * fingerprint of the host layer still match what the installer stamped? Any
+ * answer but yes fell back to the full projection.
+ *
+ * That veto is repo-wide, and it fires on facts that have nothing to do with any
+ * individual artefact. Measured 2026-09-07 on the maintainer machine, `installed.lock`
+ * at 14.19.0 against a 14.21.0 checkout:
+ *
+ * ```
+ *   rules     global 104 · project  15 · BOTH   0     ← already correct
+ *   skills    global 307 · project 414 · BOTH 261     ← the veto's cost
+ *   personas  global  32 · project  29 · BOTH  29
+ *   commands  global  94 · project   0 · BOTH   0
+ * ```
+ *
+ * The rules row is correct because rules are partitioned by
+ * {@link hostLayerCarries} — per host directory, on that directory's own
+ * contents — while skills, personas and commands hung off the version veto and
+ * were therefore delivered twice, in every session, for as long as the install
+ * lagged a release. A version number is not evidence about an artefact.
+ *
+ * This module supplies the evidence the other three families were missing, in
+ * the shape rules already use: read the host directory, and answer per NAME.
+ *
+ * **Why per-name rather than per-family.**
+ *
+ * A partition is a removal and has no repair path — withholding a name the
+ * surviving layer does not hold deletes it from every session. Asking per name
+ * makes the fail-safe granular: an artefact the host layer lacks stays in the
+ * project layer on its own, and one absent name no longer keeps 300 duplicates
+ * alive with it. That is the property the repo-wide veto could not express.
+ *
+ * **Honest limits.**
+ *
+ * Presence of a NAME, never equality of CONTENT — and never PROVENANCE either.
+ * Two consequences, the second added 2026-09-07 after a neutral review named it.
+ *
+ * **Staleness.** A stale `~/.claude/skills/foo` satisfies this check, so an
+ * install that lags a release delivers that release's older copy of `foo` rather
+ * than two copies. That is the trade the
+ * owner chose on 2026-09-07, stated rather than implied: the remedy for a stale
+ * global layer is `agent-config install`, and {@link verifyHostLayer} still
+ * reports the staleness so a run says so out loud.
+ *
+ * **Shared namespace.** `~/.claude/skills` is not this package's directory. On
+ * the machine this was written, 307 entries = 299 package skills + 8 Cloudflare
+ * PLUGIN skills. No name collides today, but the mechanism needs no collision to
+ * be real: a plugin — or a hand-made `~/.claude/skills/<name>` — whose name
+ * matches a package skill makes this function withhold the package's project-layer
+ * copy, and the session then loads the foreign body under the package's skill
+ * name. The withhold is a removal with no repair path, which is what makes it
+ * worth naming rather than filing.
+ *
+ * **A NEIGHBOURING defect that WAS fixed, 2026-09-07.** This paragraph claimed
+ * "the skill is still delivered, under the right name, from one layer" — and that
+ * was false while `_readLayer` returned every directory name without checking
+ * that `SKILL.md` resolved: an empty `~/.claude/skills/<name>/` withheld the
+ * project copy and the artefact came from neither layer. A name now counts as
+ * carried only when the artefact behind it resolves, so the sentence above is
+ * true as written.
+ *
+ * NOT FIXED here, deliberately: distinguishing a package artefact from a foreign
+ * one needs a provenance marker the installer does not write today, and inventing
+ * one in this module would be a guess dressed as a check. What IS true is that
+ * the failure is loud in the direction that matters — the skill is still
+ * delivered, under the right name, from one layer — and silent only about whose
+ * body it is.
+ *
+ * Contract, same as its siblings in this directory: no `process.exit`, no CLI
+ * entry, node builtins only — it ships inside the consumer installer bundle.
+ */
+
+import * as fs from 'node:fs';
+import * as os from 'node:os';
+import * as path from 'node:path';
+
+import type { CarriesVerdict } from './globalRuleLayers.js';
+
+/**
+ * The artefact families whose project-layer copy is decided here.
+ *
+ * `rules` is deliberately ABSENT. Rules project to five host directories and are
+ * already partitioned per directory by {@link globalRuleLayers.hostLayerCarries};
+ * adding a claude-only row for them would put a second decision on the one
+ * family that does not need it. Skills, personas and the colon-form commands
+ * project to `.claude/` alone, which is why one host is the whole answer for them.
+ */
+export type ClaudeArtefactFamily = 'skills' | 'personas' | 'commands';
+
+/** Family → its directory under the user's home. */
+export const CLAUDE_ARTEFACT_DIRS: Readonly<Record<ClaudeArtefactFamily, string>> = {
+    skills: '.claude/skills',
+    personas: '.claude/personas',
+    commands: '.claude/commands',
+};
+
+const _defaultHome = (): string => process.env['HOME'] ?? os.homedir();
+
+/**
+ * One directory read per (family, home) per process.
+ *
+ * The generators ask per NAME — hundreds of times for skills, ~90 for commands —
+ * and the `commands` read walks a tree. Without the memo the per-name grain that
+ * makes the fail-safe granular would also make it quadratic. `null` is memoised
+ * too: an unreadable layer stays unreadable for the run, and re-probing it once
+ * per name would answer the same thing 300 times.
+ */
+const _memo = new Map<string, ReadonlySet<string> | null>();
+
+/** Test seam — drop the memo so one process can read a layer it just changed. */
+export function _resetClaudeLayerMemoForTest(): void {
+    _memo.clear();
+}
+
+/** Absolute path to the host-global directory for one family. */
+export function claudeLayerPath(family: ClaudeArtefactFamily, home: string = _defaultHome()): string {
+    return path.join(home, CLAUDE_ARTEFACT_DIRS[family]);
+}
+
+/**
+ * The names the host layer holds for one family, or null when it cannot be read.
+ *
+ * Null is a real answer and every caller must read it as "no evidence, withhold
+ * nothing" — not as an empty layer, which would authorise withholding everything.
+ *
+ * The name shape is the family's own, because that is what the caller compares
+ * against: a skill is a directory basename (`design-tokens`), a persona a
+ * filename (`ai-agent.md`), and a command a posix path relative to the commands
+ * root (`roadmap/process-full.md` for the colon form, `agent-status.md` for a
+ * flat one). `commands` therefore walks; the other two list one level.
+ */
+export function claudeLayerNames(
+    family: ClaudeArtefactFamily,
+    home: string = _defaultHome(),
+): ReadonlySet<string> | null {
+    const dir = claudeLayerPath(family, home);
+    const key = `${family}\u0000${dir}`;
+    const hit = _memo.get(key);
+    if (hit !== undefined) {
+        return hit;
+    }
+    const answer = _readLayer(family, dir);
+    _memo.set(key, answer);
+    return answer;
+}
+
+function _readLayer(family: ClaudeArtefactFamily, dir: string): ReadonlySet<string> | null {
+    let entries: fs.Dirent[];
+    try {
+        entries = fs.readdirSync(dir, { withFileTypes: true });
+    } catch {
+        return null;
+    }
+    if (family !== 'commands') {
+        // A name is only CARRIED when the artefact behind it resolves. Corrected
+        // 2026-09-07 after a second neutral review: this returned every dirent
+        // name, so an empty `~/.claude/skills/<name>/` — no `SKILL.md` — made
+        // `claudeLayerHolds` true, the project layer withheld its copy, and the
+        // artefact was then delivered from NEITHER layer. That is the
+        // removal-with-no-repair-path this module's own limits section says it
+        // avoids, and the first fixture written for the wrapper gate created
+        // exactly that state and called the withhold correct.
+        //
+        // Reachable without a crash: a skill directory holding some other file
+        // survives `reap_stale`, and `install.ts` mkdirs before it writes.
+        // `readProjectedCatalogue` already keys on `SKILL.md` for this reason;
+        // the `commands` branch below already required a real `.md`. This is the
+        // same requirement for the two families that lacked it.
+        const carries = (name: string): boolean => {
+            const abs = path.join(dir, name);
+            try {
+                if (fs.statSync(abs).isDirectory()) {
+                    return fs.statSync(path.join(abs, 'SKILL.md')).isFile();
+                }
+                return name.endsWith('.md');
+            } catch {
+                return false;
+            }
+        };
+        return new Set(
+            entries
+                .map((e) => e.name)
+                .filter((n) => n !== 'README.md')
+                .filter(carries),
+        );
+    }
+    const out = new Set<string>();
+    const walk = (abs: string, rel: string): void => {
+        let kids: fs.Dirent[];
+        try {
+            kids = fs.readdirSync(abs, { withFileTypes: true });
+        } catch {
+            return;
+        }
+        for (const k of kids) {
+            const childRel = rel === '' ? k.name : `${rel}/${k.name}`;
+            if (k.isDirectory()) {
+                walk(path.join(abs, k.name), childRel);
+            } else if (k.name.endsWith('.md') && k.name !== 'README.md') {
+                out.add(childRel);
+            }
+        }
+    };
+    walk(dir, '');
+    return out;
+}
+
+/**
+ * Does the host layer hold this one name?
+ *
+ * The single-name form of {@link keepInProjectLayer}, for a caller that decides
+ * inside a loop and already knows the host-side name. `false` on an unreadable
+ * layer — no evidence, so nothing is withheld.
+ */
+export function claudeLayerHolds(
+    family: ClaudeArtefactFamily,
+    name: string,
+    home: string = _defaultHome(),
+): boolean {
+    return claudeLayerNames(family, home)?.has(name) ?? false;
+}
+
+/**
+ * Which of `names` the host layer carries, and which it does not.
+ *
+ * `carries` is the all-or-nothing answer the rules path reports; `missing` is the
+ * one callers act on, because withholding is decided per name. An empty `names`
+ * is vacuously carried — withholding nothing needs no evidence.
+ */
+export function claudeLayerCarries(
+    family: ClaudeArtefactFamily,
+    names: readonly string[],
+    home: string = _defaultHome(),
+): CarriesVerdict {
+    const layerPath = claudeLayerPath(family, home);
+    const have = claudeLayerNames(family, home);
+    if (have === null) {
+        return { carries: false, layerPath, missing: [...names], reason: 'layer-absent' };
+    }
+    const missing = names.filter((n) => !have.has(n));
+    return {
+        carries: missing.length === 0,
+        layerPath,
+        missing,
+        reason: missing.length === 0 ? 'carries' : 'missing-names',
+    };
+}
+
+/**
+ * The subset of `names` the project layer must still deliver.
+ *
+ * The one function the generators call. Returns the names the host layer does
+ * NOT hold, in the order given — so an unreadable layer returns everything
+ * (fail safe) and a complete layer returns nothing.
+ */
+export function keepInProjectLayer(
+    family: ClaudeArtefactFamily,
+    names: readonly string[],
+    home: string = _defaultHome(),
+): string[] {
+    const have = claudeLayerNames(family, home);
+    if (have === null) {
+        return [...names];
+    }
+    return names.filter((n) => !have.has(n));
+}