@event4u/agent-config 14.11.0 → 14.12.0

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

@@ -1,76 +1,102 @@
 {
-  "_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 machine-dependent, not CI-checkable",
-      "tool definitions + dispatch prompt \u2014 no local source carries the request payload; the census reports it as an explicit residual",
-      "personas (src/agent-src/personas, 36 files, ~37,181 tok) \u2014 measured ZERO standing cost 2026-08-22: .claude/personas/ is written by this repo's generators (5 in-repo references) and read by no host contract; the host's real subagent surface is .claude/agents/, which this package writes 1 file into. Reversal condition: a host publishing a personas contract, or a generator folding persona prose into an instruction file that IS read. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md",
-      "contexts (src/agent-src/contexts, 58 files, ~114,042 tok) \u2014 measured ON-DEMAND 2026-08-22: 0 rules declare load_context_eager: (17 declare the lazy load_context:), and rule.schema.json:49 documents eager as the variant that counts against the per-rule budget. This records that no eager declaration exists, NOT that eager loading would be free \u2014 nobody has declared one, so nobody has measured it. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md",
-      "skill bodies (src/skills/*/SKILL.md, 290 files, ~595,843 tok) \u2014 measured ON-DEMAND 2026-08-22: censusSkillsCatalog (preamble_byte_census.ts:216-234) builds the gated catalog bucket from `- name: description` per skill and reads no body byte, which is why 290 skills totalling ~595,843 tok report as ~14.4k standing. Corollary: the description cap is the WHOLE skill-side lever, not a fragment of it. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md"
-    ],
-    "_bucket_classification_note": "All three additions above are EXCLUSIONS, not gated buckets, and that is the finding rather than a shortcut. A census bucket over a corpus measured at zero is a permanently green gate certifying nothing. The exclusions carry their measurement so the next pass that proposes one of these corpora as a token lever meets the number instead of the silence."
-  },
-  "baseline_tokens": 102520,
-  "baseline_history": [
-    {
-      "tokens": 102599,
-      "at": "2026-07-30",
-      "why": "registered with the gate"
-    },
-    {
-      "tokens": 102520,
-      "at": "2026-07-31",
-      "why": "free tightening: the measured tree came in 79 tok under the registered baseline, so the ratchet walks down to meet it. Not a claimed reduction \u2014 nothing was optimised; the point of a ratchet is that a lower measurement becomes the new ceiling instead of becoming unused headroom."
-    }
-  ],
-  "headroom_pct": 5,
-  "target_tokens": {
-    "median": 40000,
-    "p95": 50000,
-    "_comment": "The roadmap's candidate numbers, kept as the destination. Reaching them needs reductions this package has not built yet; scope-dedup (C-3) removes a redundant COPY at the consumer, it does not shrink the suite itself."
-  },
-  "target_schedule": {
-    "_comment": "road-to-inbox-harvest-2026-08-d-context-ledger Step 5.3. The target above was a destination with no route: the ratchet fails on GROWTH only, so the corpus can drift away from 40k indefinitely without any gate objecting. These milestones give the destination a schedule. They are DATES WITH NUMBERS, not a derivation - no measurement in this tree says the estate can reach 85k by a given day, and pretending otherwise would be the invented-threshold failure this file's own baseline_history is careful to avoid. What they buy is that a miss becomes a published fact with an owner instead of a silent drift.",
+    "_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",
-    "measured_at_registration": {
-      "tokens": 125593,
-      "at": "2026-08-15",
-      "note": "MEASURED total at registration time, from check_preamble_payload_budget. It is ~23k ABOVE both baseline_tokens (102520) and the derived ceiling, i.e. the gate is red on the tree as it stands. The baseline is deliberately NOT raised to meet it - raising a ratchet baseline to clear a failing check is the config-weakening move this repo blocks by construction. It is recorded here so the milestones below are planned against the real starting point rather than a stale one. Per-rule ranking: agents/evidence/analysis/rule-paths-coverage-census.md"
+    "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 machine-dependent, not CI-checkable",
+            "tool definitions + dispatch prompt \u2014 no local source carries the request payload; the census reports it as an explicit residual",
+            "personas (src/agent-src/personas, 36 files, ~37,181 tok) \u2014 measured ZERO standing cost 2026-08-22: .claude/personas/ is written by this repo's generators (5 in-repo references) and read by no host contract; the host's real subagent surface is .claude/agents/, which this package writes 1 file into. Reversal condition: a host publishing a personas contract, or a generator folding persona prose into an instruction file that IS read. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md",
+            "contexts (src/agent-src/contexts, 58 files, ~114,042 tok) \u2014 measured ON-DEMAND 2026-08-22: 0 rules declare load_context_eager: (17 declare the lazy load_context:), and rule.schema.json:49 documents eager as the variant that counts against the per-rule budget. This records that no eager declaration exists, NOT that eager loading would be free \u2014 nobody has declared one, so nobody has measured it. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md",
+            "skill bodies (src/skills/*/SKILL.md, 290 files, ~595,843 tok) \u2014 measured ON-DEMAND 2026-08-22: censusSkillsCatalog (preamble_byte_census.ts:216-234) builds the gated catalog bucket from `- name: description` per skill and reads no body byte, which is why 290 skills totalling ~595,843 tok report as ~14.4k standing. Corollary: the description cap is the WHOLE skill-side lever, not a fragment of it. Evidence: agents/evidence/analysis/uncounted-prose-corpora-load-semantics.md"
+        ],
+        "_bucket_classification_note": "All three additions above are EXCLUSIONS, not gated buckets, and that is the finding rather than a shortcut. A census bucket over a corpus measured at zero is a permanently green gate certifying nothing. The exclusions carry their measurement so the next pass that proposes one of these corpora as a token lever meets the number instead of the silence."
     },
-    "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."
-      }
+    "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."
+        }
     ],
-    "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."
-  }
+    "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": 138212,
+        "grace_measured_at": "2026-08-24",
+        "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."
+    },
+    "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/routing-coverage-seed.json

@@ -0,0 +1,29 @@
+{
+    "_comment": "Routing-coverage ratchet seeds (road-to-routing-assurance 0.3). Coverage ratio = corpus cases / routed units, per scope, seeded at the MEASURED current value on 2026-08-25. CI fails only on a decrease -- the COUNT-ratchet disposition of lint_trigger_precision.ts. TWO scopes and never one aggregate: a blended figure would read ~0.46 and describe neither surface. Lowering a seed is a defect, not a fix: a ratio falls when a corpus case is removed OR when units are added without cases, and both are things to repair rather than to record.",
+    "schema_version": 1,
+    "registered_at": "2026-08-25",
+    "owner": "maintainer",
+    "review_by": "2027-08-25",
+    "measurement": {
+        "rules": "intersection of tests/eval/routing-matrix/*.yaml stems with the tier_1+tier_2 ids in dist/router.json, over that id count. Intersection rather than the file count, so a fixture naming no routed rule cannot raise the ratio.",
+        "skills": "src/skills/*/evals/triggers.json over src/skills/*/SKILL.md."
+    },
+    "seed": {
+        "rules": 0.8952,
+        "skills": 0.301
+    },
+    "seed_provenance": {
+        "rules": "94 covered of 105 routed rules (tier-1 21/24, tier-2 73/81) on 2026-08-25.",
+        "skills": "76 of 299 skills carry evals/triggers.json on 2026-08-25.",
+        "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)."
+    },
+    "history": [
+        {
+            "date": "2026-08-25",
+            "scope": "skills",
+            "from": 0.2542,
+            "to": 0.301,
+            "reason": "road-to-routing-assurance Phase 2.2 authored 14 high-tier corpus files (76 -> 90 of 299). The seed rises so the gain cannot be given back silently; it may never be LOWERED."
+        }
+    ]
+}

package/src/config/suggestion-capture.json

@@ -0,0 +1,28 @@
+{
+    "_comment": "Record schema for the suggestion-block capture instrument (road-to-suggestion-block-capture Phase 1.3). Registered BEFORE the hook exists, so the field set is a pre-commitment rather than a description of whatever the code ended up writing. COUNTS-ONLY BY CONSTRUCTION: there is no field able to hold free text — no prompt, no option label, no command name beyond the evidence class. That is the discipline dispatch-economy-metrics.json:27 fixes as 'a count derived from the result object, never its content', and it is the reason a privacy review here is a schema read rather than a scrubber audit. Every budget-shaped config in this tree carries owner and review_by per the budget-ownership lint.",
+    "schema_version": 1,
+    "registered_at": "2026-08-24",
+    "owner": "maintainer",
+    "review_by": "2027-08-24",
+    "sink": "agents/runtime/state/audit/suggestion-capture.jsonl",
+    "record_fields": {
+        "ts": "ISO-8601 UTC second precision. Not a duration and not a correlation key.",
+        "block_emitted": "boolean — the previous assistant turn matched the render signature.",
+        "options_count": "integer — how many numbered options the block carried. A COUNT of options, never their labels.",
+        "evidence_class": "enum: render-signature | latch-consumed | latch-stale | no-latch. WHY the classification was reachable, not what the turn said.",
+        "turn_classification": "enum: option_n | as_is | other | stale_block."
+    },
+    "classification_enum": ["option_n", "as_is", "other", "stale_block"],
+    "evidence_class_enum": ["render-signature", "latch-consumed", "latch-stale", "no-latch"],
+    "field_ban": {
+        "rule": "No record field may hold a prompt, an option label, a command name, a file path, or any other free-form string. The enums above are closed; a value outside them is a defect in the writer, not a new category.",
+        "why_a_ban_and_not_a_scrubber": "A scrubber can fail and leave content in the sink. A type with no field able to carry content cannot. Same reasoning as the telemetry engagement event, which was deliberately built with no payload/notes/extra key.",
+        "checked_by": "tests/scripts/suggestion_capture.test.ts asserts the written line's key set equals record_fields exactly, so an added field fails a test rather than shipping quietly."
+    },
+    "option_n_note": "`option_n` records THAT a numbered option was chosen and, via options_count, out of how many. It deliberately does NOT record WHICH number: the block's option order is content, and the capture-rate question this instrument exists to answer does not need it.",
+    "soak_window": {
+        "length_days": 14,
+        "fixed_at": "2026-08-24",
+        "why_fixed_before_the_window": "A window whose length is chosen after the numbers are in is a window chosen to produce a number. Fixed here, before any capture code ran, per the same pre-registration discipline hook-latency-budget.json records for itself."
+    }
+}

package/src/config/surface-matrix.yml

@@ -167,8 +167,27 @@ tools:
   opencode:
     surface: projection
     scope_path: "~/.opencode/"
-    hooks: none
-    notes: Plain projection (skill bundle); no plugin channel.
+    # CORRECTED 2026-08-24: this row read `hooks: none` and "no plugin channel",
+    # and that was wrong on a shipped host. @opencode-ai/plugin@1.18.21 exposes
+    # `permission.ask`, `tool.execute.before`, `shell.env` and
+    # `experimental.chat.system.transform`. Evidence, with the pin and the type
+    # signatures: agents/evidence/analysis/opencode-plugin-api-verification.md
+    #
+    # `plugin`, and the value is the HOST's channel type rather than a claim that
+    # this suite binds it. An `unbound` value was tried first and rejected by
+    # lint_surface_matrix's enum {managed-settings-block, settings-hooks-opt-in,
+    # plugin, none} — correctly: every other row here describes what the host
+    # offers, and whether this package binds it is hook_manifest.yaml's business,
+    # where opencode still has ZERO entries. The notes below carry the
+    # not-bound-here fact so the row cannot be read as a delivered capability.
+    hooks: plugin
+    notes: >-
+      Plain projection (skill bundle) today. Upstream DOES expose a plugin
+      channel with a real deny (`permission.ask` -> status "deny"), but the deny
+      is narrower than a pre-tool slot: `tool.execute.before` is mutate-only
+      (`{args}`, no refusal), so a concern can only refuse where opencode already
+      stops to ask, and the `Permission` input carries no tool name, arguments or
+      path as typed fields. Nothing in this package is bound to it.
 
   trae:
     surface: projection

package/src/config/web-launch-readiness.json

@@ -0,0 +1,188 @@
+{
+  "_comment": "Site-type axis for the web-launch-readiness skill (road-to-web-launch-readiness 0.2). The design directive this file exists to enforce is CONDITIONAL, NOT FLAT: a check that applies everywhere is a check that gets ignored somewhere. Every entry declares which site types it applies to, so a SaaS app is never asked for opening hours and a docs site is never asked for a cookie banner it does not set. REGISTERED BEFORE ANY SKILL CODE EXISTS, which is the point of Phase 0: the axis is a decision, and deciding it after writing the checks would let the checks pick their own scope. Nothing reads this file yet -- the skill is gated behind b-estate-decision-web-launch.",
+  "schema_version": 1,
+  "registered_at": "2026-08-25",
+  "owner": "maintainer",
+  "review_by": "2027-08-25",
+  "site_types": {
+    "_comment": "The closed enum. A check may not name a type outside it, and a type carries no checks until one lists it -- so adding a type is inert until a check opts in, and removing one is caught by the schema test rather than silently emptying a check's scope.",
+    "values": [
+      "local-business",
+      "marketing-site",
+      "saas-app",
+      "docs",
+      "internal-tool"
+    ]
+  },
+  "tiers": {
+    "_comment": "Report order, and it is the output contract rather than a label: critical first, situational last. A finding's tier is a property of the FINDING, not of the reader's patience -- a staging noindex on a production marketing site is critical whether or not the reader has time for it.",
+    "values": [
+      "critical",
+      "high",
+      "medium",
+      "situational"
+    ]
+  },
+  "checks": [
+    {
+      "id": "staging-noindex-leftover",
+      "title": "A staging `noindex` or `robots.txt` disallow survived into production",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "saas-app",
+        "docs"
+      ],
+      "tier": "critical",
+      "why": "The defect class with ZERO coverage in the estate (G0: `robots` 0 files, `noindex` 0 files) and the highest cost: the site ships, works, looks correct, and is invisible to search. Nothing in the tree looks for it today.",
+      "remediation": "Remove the `noindex` meta tag and the blanket `Disallow: /` from the production build; keep them behind the staging environment's own config rather than in shared source.",
+      "verification": "`curl -sI <prod-url> | grep -i x-robots-tag` returns nothing, `curl -s <prod-url>/robots.txt` carries no blanket disallow, and the rendered HTML has no `noindex` meta."
+    },
+    {
+      "id": "https-enforcement",
+      "title": "HTTP is redirected to HTTPS and no asset is loaded over plain HTTP",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "saas-app",
+        "docs"
+      ],
+      "tier": "critical",
+      "why": "A mixed-content asset silently breaks the padlock and, on a form page, ships a credential over plaintext. Browsers block some of it and load the rest, so the page LOOKS fine while the guarantee is gone -- which is why this is critical rather than high.",
+      "remediation": "Serve every asset over https:// or protocol-relative paths, and redirect http:// at the edge. Never hard-code an http:// origin you control.",
+      "verification": "`curl -sI http://<prod-host>/` returns a 301/308 to https, and the browser console shows no mixed-content warning on the heaviest page."
+    },
+    {
+      "id": "custom-error-route",
+      "title": "A custom 404 route exists and is reachable",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "saas-app",
+        "docs"
+      ],
+      "tier": "high",
+      "why": "A framework default error page leaks stack shape and loses the visitor. `404` matches 19 files in the estate, all HTTP-status tables -- none is a launch check.",
+      "remediation": "Add the framework's custom 404 route and give it a link back into the site.",
+      "verification": "`curl -s -o /dev/null -w '%{http_code}' <prod-url>/<random-path>` returns 404 and the body is the custom page, not the framework default."
+    },
+    {
+      "id": "per-route-metadata",
+      "title": "Every indexable route carries a title and a meta description",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "docs"
+      ],
+      "tier": "high",
+      "why": "`meta description` matches 0 files. Excluded for `saas-app` and `internal-tool` on purpose: an authenticated app's routes are not indexed, so per-route descriptions are work with no consumer.",
+      "remediation": "Add title and description to each route's metadata export; a shared default is a fallback, not a per-route value.",
+      "verification": "Fetch each route in the sitemap and assert a non-empty, non-duplicated title and description."
+    },
+    {
+      "id": "image-alternative-text",
+      "title": "Content images carry alternative text",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "saas-app",
+        "docs",
+        "internal-tool"
+      ],
+      "tier": "high",
+      "why": "The one check that applies to every type, including internal tools -- an internal user with a screen reader is still a user. `alt text` matches 7 files, all accessibility prose rather than a launch check.",
+      "remediation": "Add `alt` to content images; decorative images take `alt=\"\"` explicitly rather than being left without the attribute.",
+      "verification": "Parse the rendered HTML and assert every `<img>` has an `alt` attribute, empty or not."
+    },
+    {
+      "id": "document-head-basics",
+      "title": "Every page declares lang, charset and viewport",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "saas-app",
+        "docs",
+        "internal-tool"
+      ],
+      "tier": "high",
+      "why": "A missing `lang` makes a screen reader guess the pronunciation of the whole page; a missing viewport makes a phone render a desktop layout at 320px. Both are one line, both are invisible on the developer's machine, and both are the kind of default a framework template silently drops when a page is hand-written.",
+      "remediation": "`<html lang=\"..\">`, `<meta charset=\"utf-8\">` and `<meta name=\"viewport\" content=\"width=device-width, initial-scale=1\">` in the shared layout, not per page.",
+      "verification": "View source on two unrelated routes and confirm all three are present on both -- one route proves the layout, two prove it is the layout and not a copy."
+    },
+    {
+      "id": "canonical-and-sitemap-coherence",
+      "title": "Canonical URLs, sitemap and robots.txt agree with each other",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "docs"
+      ],
+      "tier": "medium",
+      "why": "Three sources that can disagree silently: a sitemap listing a route whose canonical points elsewhere, or a robots disallow on a route the sitemap advertises. Note `canonical` matches 115 files in this estate in a completely different sense (\"the canonical rule\"), so its count is NOT coverage evidence.",
+      "remediation": "Make the canonical the same URL the sitemap lists; remove sitemap entries that robots.txt disallows.",
+      "verification": "For each sitemap URL, fetch it and assert the canonical equals the sitemap entry and robots.txt does not disallow it."
+    },
+    {
+      "id": "required-legal-pages",
+      "title": "The legal pages the jurisdiction requires exist and are linked",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "saas-app"
+      ],
+      "tier": "situational",
+      "why": "SITUATIONAL because the requirement is jurisdictional, not universal: a German commercial site needs an Impressum, a US one does not. The skill reports what is missing for the declared region and does not assert a legal conclusion -- that is the domain-safety-disclaimer boundary, not this file's.",
+      "remediation": "Add the pages the declared region requires and link them from the footer of every page.",
+      "verification": "Assert each declared-required page returns 200 and is reachable from the home page in one click."
+    },
+    {
+      "id": "analytics-and-consent-wiring",
+      "title": "Analytics fires only after consent, where consent is required",
+      "applies_to": [
+        "local-business",
+        "marketing-site",
+        "saas-app"
+      ],
+      "tier": "situational",
+      "why": "Also jurisdictional, and the failure is asymmetric: analytics that never fires costs data, analytics that fires before consent costs a regulatory exposure.",
+      "remediation": "Gate the analytics snippet behind the consent state; do not load it on first paint.",
+      "verification": "Load the page with consent declined and assert no request to the analytics origin."
+    }
+  ],
+  "not_in_scope": {
+    "_comment": "Named so a later contributor does not add them by analogy. Performance budgets and Lighthouse scoring are a different instrument with a different failure mode (a score is a gradient, these checks are binary), and `lighthouse` matching 0 files is NOT an argument for adding it here. Accessibility beyond alt text belongs to accessibility-auditor, which already exists and does it properly.",
+    "items": [
+      "performance budgets",
+      "lighthouse scoring",
+      "full WCAG audit",
+      "SEO keyword strategy"
+    ]
+  },
+  "no_import_decision": {
+    "_comment": "Step 0.3, recorded HERE rather than in the skill body, and the relocation is a correction the step needs rather than a liberty taken. 0.3 sits in Phase 0, whose Exit condition reads \"zero skill code written\" -- so its verify line (\"the decision is written in the skill's own body\") names an artefact its own phase forbids. The decision is what the step is about; it is recorded in the earliest durable place that exists, and the skill body restates it at 2.1 when there is a body.",
+    "decision": "no-import",
+    "decided_at": "2026-08-25",
+    "rule": "The external corpus is a STUDY OBJECT and a per-defect harvest source. Its rule set is not imported. Rules enter ONE AT A TIME, each against a named defect, each carrying its own remediation and verification.",
+    "why": "An imported rule set arrives with its authors' assumptions about site type, jurisdiction and stack, and none of those is checked on arrival. The failure is silent: the skill grows to N checks, each individually plausible, and the conditional axis this file exists to enforce is the first thing a bulk import flattens. One-at-a-time keeps the axis honest because every entry has to answer `applies_to` before it lands.",
+    "ceiling": 50,
+    "ceiling_enforced_by": "tests/scripts/web_launch_readiness_config.test.ts asserts checks.length < 50. Currently 7."
+  },
+  "regions": {
+    "_comment": "Region axis (road-to-web-launch-readiness 2.3). Separate from site_types because it answers a different question: site_types decides WHETHER a check applies, regions decides HOW SEVERELY. A DE-targeted site owes Impressum and Datenschutz by law (TMG 5 / DSGVO Art. 13), so `required-legal-pages` is critical there and situational elsewhere -- the same check, a different tier. Modelled as a tier ESCALATION rather than as a second applies_to list, because a legal page is not more or less applicable in Germany, it is more or less optional.",
+    "values": [
+      "de",
+      "eu",
+      "us",
+      "unspecified"
+    ],
+    "default": "unspecified",
+    "escalations": [
+      {
+        "check": "required-legal-pages",
+        "region": "de",
+        "to": "critical",
+        "why": "TMG 5 obliges an Impressum and DSGVO Art. 13 a Datenschutzerklaerung for a DE-targeted commercial site. Abmahnung risk is real and immediate, which is what separates critical from situational here."
+      }
+    ]
+  }
+}