@event4u/agent-config 9.7.0 → 9.8.0

package/src/config/reach-prescriptions-intake.yml

@@ -0,0 +1,200 @@
+# Reach prescription intake record — committed supply-chain evidence
+# (road-to-internet-reach Phase 3, Step 2).
+#
+# WHAT THIS FILE IS. The offline substitute for a network lookup at lint time.
+# `src/scripts/validate_reach_prescriptions.ts` (gate:
+# `task check-reach-prescriptions`) reads THIS file to answer "does the package
+# this prescription names exist, is its pin the one we checked, and was it
+# CVE-reviewed" — it never fetches a registry. That is a hard architectural
+# constraint, not a convenience: the Class A boundary
+# (docs/contracts/no-runtime-boundary.md, ADR-124) forbids network access in the
+# build path, and a lint that phones a third party is a flaky lint.
+#
+# CONSEQUENCE. Every claim below is a HUMAN-RUN check frozen at `checked_on`.
+# Freshness is a maintenance duty, not a guarantee this file can make about
+# itself: re-run the recorded commands, update `pinned_version` +
+# `verified_on`, and change the registry pin in the same commit.
+#
+# WHAT AN ENTRY IS FOR. `tools:` carries exactly one entry per EXTERNALLY
+# INSTALLED third-party tool named by an install prescription in
+# src/config/reach-channels.yml. A prescription whose backend has no entry
+# here cannot ship — the validator fails closed on it.
+#
+# WHY `os_baseline:` IS A SEPARATE CLASS, NOT A THIN `tools:` ENTRY. `curl`,
+# `node` and `jq` are not package installs this project prescribes: they ship
+# with the OS or the developer's base image. Writing a fake intake entry for
+# them — "existence verified: it is curl" — would launder an assumption into
+# evidence and put a registry/CVE claim on this project's ledger that nobody
+# actually checked per platform. They are declared as baselines instead, with
+# the reason, and the validator exempts them from the `tools:` requirement
+# while still enforcing the pinning rules on any string they do carry.
+#
+# EXECUTION HONESTY. `asdf` and `pipx` are ABSENT on the authoring machine
+# (`which asdf` / `which pipx` → not found), so no install command below was
+# ever executed here. That is the design: prescription-first, human-performed,
+# no auto-install (roadmap `## Non-goals`). Existence was verified against the
+# registries' own metadata APIs, which is what the pin depends on.
+#
+# ISO DATES MUST STAY QUOTED — unquoted, YAML parses them as timestamps and
+# the validator's string check fails loudly.
+schema_version: reach-prescriptions-intake-v1
+
+# The date every `verification.command` below was last executed by a human.
+checked_on: "2026-07-24"
+
+tools:
+  # ── gh ────────────────────────────────────────────────────────────────────
+  # Backend of the `github` channel. Two package identities because no
+  # single registry offers an exactly-pinnable `gh` on every platform:
+  # Homebrew ships only an unversioned `gh` formula (a pin there would be a
+  # lie), so macOS/Linux go through asdf, and Windows through winget.
+  - backend: gh
+    tool: gh
+    pinned_version: "2.96.0"
+    packages:
+      - registry: asdf
+        package: github-cli
+      - registry: winget
+        package: GitHub.cli
+    intake:
+      existence_verified: >-
+        Three independent confirmations at the pin. (1) The binary itself
+        reports 2.96.0 on the authoring machine. (2) The asdf plugin index
+        contains plugins/github-cli (blob sha
+        b8ab100243bc01e361a61c50d11d4ab66b790c92). (3) The winget-pkgs manifest
+        tree lists exactly 2.96.0 under manifests/g/GitHub/cli. Not a
+        model-produced name: every identifier came out of a registry response.
+      pinned: >-
+        Exact, both platforms — `asdf install github-cli 2.96.0` and
+        `winget install --id GitHub.cli --version 2.96.0`. No range, no
+        `latest`, no branch, no archive URL. Homebrew was rejected as the
+        macOS/Linux path precisely because its unversioned `gh` formula admits
+        no exact pin at all — a pinned-looking Homebrew line would be fiction.
+      lockfile_note: >-
+        No project lockfile applies — gh is an external CLI a human installs,
+        never a dependency of this package (absent from package.json, and this
+        repo ships no .tool-versions). The lock equivalent is the exact pin in
+        this record plus asdf's own .tool-versions in the operator's
+        environment, if they use one. Nothing in this repo can pin it for them.
+      cve_note: >-
+        GitHub Advisory Database, ecosystem `go`, package
+        github.com/cli/cli/v2: 6 advisories, newest first_patched_version
+        2.93.0 (GHSA-8xvp-7hj6-mcj9, TUF-mirror auth header). 2.93.0 <= 2.96.0,
+        so no listed advisory affects the pin. Reviewed by advisory listing, not
+        by a scanner — osv-scanner and pip-audit are not installed here, and
+        neither covers a system CLI install anyway.
+    verified_on: "2026-07-24"
+    verification:
+      - command: gh --version
+        source: local PATH on the authoring machine
+        observed: "gh version 2.96.0 (2026-07-02)"
+      - command: gh api repos/asdf-vm/asdf-plugins/contents/plugins/github-cli --jq '.sha + " " + .path'
+        source: https://api.github.com/repos/asdf-vm/asdf-plugins
+        observed: "b8ab100243bc01e361a61c50d11d4ab66b790c92 plugins/github-cli"
+      - command: gh api repos/microsoft/winget-pkgs/contents/manifests/g/GitHub/cli --jq '[.[].name] | map(select(startswith("2.96")))'
+        source: https://api.github.com/repos/microsoft/winget-pkgs
+        observed: '["2.96.0"]'
+      - command: gh api "/advisories?ecosystem=go&affects=github.com%2Fcli%2Fcli%2Fv2&per_page=100" --jq '[.[].vulnerabilities[] | select(.package.name=="github.com/cli/cli/v2") | .first_patched_version] | unique | sort'
+        source: https://api.github.com/advisories
+        observed: '["2.62.0","2.63.0","2.63.1","2.67.0","2.92.0","2.93.0"]'
+
+  # ── yt-dlp ────────────────────────────────────────────────────────────────
+  # Backend of the `youtube` channel, and NOT installed here — the roadmap
+  # blocker `yt-dlp-not-installed` is open by design. An intake record is
+  # about whether the prescription is safe to hand a human, which is a
+  # different question from whether the tool is present locally; the probe
+  # layer owns the second one.
+  - backend: yt-dlp
+    tool: yt-dlp
+    pinned_version: "2026.7.4"
+    packages:
+      - registry: PyPI
+        package: yt-dlp
+    intake:
+      existence_verified: >-
+        PyPI JSON API reports .info.version 2026.7.4 for the project, and the
+        per-release endpoint /pypi/yt-dlp/2026.7.4/json resolves with 2 upload
+        files — so the exact pinned release exists, not merely the project name.
+        Typo-adjacency checked deliberately: `yt-dlp` is the hyphenated form,
+        the shape most prone to hallucinated variants (`ytdlp`, `yt_dlp`,
+        `youtube-dl`); the identifier used here is the one PyPI returned.
+      pinned: >-
+        Exact PyPI equality pin — `pipx install yt-dlp==2026.7.4` (Windows:
+        `py -m pipx install yt-dlp==2026.7.4`). yt-dlp publishes date-shaped
+        versions, so a `latest`-style install would silently roll forward
+        every few days; the schema rejects that form outright.
+      lockfile_note: >-
+        No project lockfile applies — an isolated pipx application, not a
+        dependency of this package. pipx records the exact spec in its own
+        venv metadata; the pin above is the only lock this repo controls.
+      cve_note: >-
+        GitHub Advisory Database, ecosystem `pip`, package yt-dlp: 11
+        advisories, newest first_patched_version 2026.6.9 (GHSA-69qj-pvh9-c5wg
+        `--exec` command injection, plus three siblings patched in the same
+        release). 2026.6.9 < 2026.7.4, so no listed advisory affects the pin.
+        Worth carrying forward: the tool's own history is dominated by
+        argument-injection and filename-sanitization classes, which is one more
+        reason its output is untrusted content, never instructions
+        (src/rules/untrusted-input-defense.md).
+    verified_on: "2026-07-24"
+    verification:
+      - command: curl -fsSL https://pypi.org/pypi/yt-dlp/json | jq -r '.info.version'
+        source: https://pypi.org/pypi/yt-dlp/json
+        observed: "2026.7.4"
+      - command: curl -fsSL https://pypi.org/pypi/yt-dlp/2026.7.4/json | jq -r '.info.version + " files=" + (.urls|length|tostring)'
+        source: https://pypi.org/pypi/yt-dlp/2026.7.4/json
+        observed: "2026.7.4 files=2"
+      - command: gh api "/advisories?ecosystem=pip&affects=yt-dlp&per_page=100" --jq '[.[].vulnerabilities[] | select(.package.name=="yt-dlp") | .first_patched_version] | unique | sort'
+        source: https://api.github.com/advisories
+        observed: '["2023.09.24","2023.11.14","2023.7.06","2024.04.09","2024.07.01","2024.07.07","2026.02.21","2026.6.9"]'
+
+# ── OS baselines — declared non-installs ──────────────────────────────────
+# Present because the registry names them as backends, NOT because this
+# project prescribes installing them. Each entry states why a pin is not
+# meaningful; the validator exempts these from the `tools:` requirement and
+# still enforces "pinned or explicit os-baseline sentinel" on every string
+# they carry.
+os_baseline:
+  - tool: curl
+    os_baseline: true
+    rationale: >-
+      Ships with macOS (/usr/bin/curl) and Windows 10+ (System32\curl.exe),
+      and is a distro package on Linux whose version tracks the distro. There
+      is no cross-platform version this project could pin without prescribing
+      a source it does not control — so the registry carries `os-baseline:`
+      sentinels and no version, deliberately.
+    verification:
+      - command: curl --version | head -1
+        source: local PATH on the authoring machine
+        observed: "curl 8.7.1 (x86_64-apple-darwin24.0) libcurl/8.7.1"
+
+  - tool: node
+    os_baseline: true
+    rationale: >-
+      A Node runtime is this package's own execution baseline
+      (package.json engines >=20.11.0), so any environment that can run the
+      validator already has it. The one platform where a pin IS meaningful —
+      Homebrew's versioned major-line formula — carries a real pin
+      (`brew install node@22`), verified below; the remaining platforms track
+      their own LTS channel and stay unpinned behind an explicit sentinel.
+    verification:
+      - command: curl -fsSL https://formulae.brew.sh/api/formula/node@22.json | jq -r '.versions.stable'
+        source: https://formulae.brew.sh/api/formula/node@22.json
+        observed: "22.23.1 (versioned formula node@22 exists)"
+      - command: node --version
+        source: local PATH on the authoring machine
+        observed: "v25.9.0"
+
+  - tool: jq
+    os_baseline: true
+    rationale: >-
+      Named nowhere in the registry as a backend on purpose — JSON shaping
+      happens inside the operator's own recipe, downstream of retrieval, so jq
+      never satisfies a channel. Recorded here so its absence from `tools:` is
+      a documented decision rather than an omission: if jq ever becomes a
+      backend it inherits curl's `os-baseline:` treatment, not a fabricated
+      pin.
+    verification:
+      - command: jq --version
+        source: local PATH on the authoring machine
+        observed: "jq-1.7.1-apple"

package/src/scripts/_dispatch.bash

@@ -205,6 +205,15 @@ Tier 2 — maintenance / internal (hooks, MCP, memory, telemetry):
                              Usage: hooks:replay --platform <name> --event <event>
                                     --payload <path|event-name> [--native-event <native>]
                                     [--manifest <path>] [--json] [--dry-run]
+  reach:doctor               Health report over the reach channel registry: per channel
+                             the active backend, lifecycle, and the pinned install command
+                             for this platform when a backend is missing/broken.
+                             Read-only — no writes, no installs; NOT a router and NOT an
+                             agent-facing recommendation.
+                             Flags: --format json|table, --strict (CI), --channel <id>,
+                             --registry <path>, --deep (⚠️  opt-in NETWORK: one real
+                             read-only request per declared backend; never runs in CI,
+                             writes nothing)
   memory:lookup              Retrieve memory entries (text or JSON envelope)
   linked-projects:list       List opted-in IDE-attached sibling repos (path · detected_via · large)
                              Flags: --all (show undecided too), --format json
@@ -636,6 +645,11 @@ cmd_hooks_replay() {
   exec_hook "src/scripts/hooks/replay_hook" "$@"
 }
 
+# Read-only reach-channel health report. Never installs, never writes.
+cmd_reach_doctor() {
+  exec_hook "src/scripts/reach_doctor" "$@"
+}
+
 cmd_chat_history_checkpoint() {
   local script
   script="$(resolve_script "src/scripts/chat_history.ts")" || return 1
@@ -1085,6 +1099,7 @@ main() {
     hooks:status)            cmd_hooks_status "$@" ;;
     hooks:doctor)            cmd_hooks_doctor "$@" ;;
     hooks:replay)            cmd_hooks_replay "$@" ;;
+    reach:doctor)            cmd_reach_doctor "$@" ;;
     telemetry:record)        cmd_telemetry_record "$@" ;;
     telemetry:status)        cmd_telemetry_status "$@" ;;
     telemetry:report)        cmd_telemetry_report "$@" ;;

package/src/scripts/_lib/exec_evidence.ts

@@ -0,0 +1,251 @@
+/**
+ * `exec:` evidence — the ledger form that re-derives its own claim.
+ *
+ * The other three evidence forms are existence checks: a file is present, a
+ * substring is present, a URL carries a date. None of them can tell a live
+ * claim from a stale one. A ledger entry reading "the suite is green" whose
+ * pointer resolves to a report nobody regenerated stays `backed` forever.
+ *
+ * `exec:<command> -> 0` closes that: the command runs again and its exit code
+ * carries the verdict. Three properties make it safe enough to run in CI, and
+ * all three are the parts that get dropped when this is rebuilt from memory:
+ *
+ *  1. The allowlist is a set of **argv prefix tuples**, never a regex over a
+ *     command string. A regex over shell text is the classic bypass; a tuple
+ *     compared against parsed argv has nothing to hide behind.
+ *  2. Every argument *after* the matched prefix is re-checked — for shell
+ *     metacharacters and for repo escape — including the right-hand side of
+ *     `--flag=value`. Without that split, `--rootdir=/etc` clears an allowlist
+ *     that only ever looked at the flag name.
+ *  3. Execution is `spawnSync` with an argv array and no shell, confined to the
+ *     repo root, and gated to CI. Locally the caller reports UNVERIFIED rather
+ *     than running anything — see `exec_allowed_here()`.
+ *
+ * Scope limit, stated rather than discovered later: this form only covers
+ * claims whose exit code *is* the verdict. A claim resting on a paid model run,
+ * a stochastic benchmark, or a prose contract cannot use it, and is recorded as
+ * unfalsifiable-by-machine instead of quietly omitted.
+ */
+
+import { spawnSync } from 'node:child_process';
+import path from 'node:path';
+
+/** Marker that opens the fourth evidence form. */
+export const EXEC_PREFIX = 'exec:';
+
+/**
+ * Allowlisted argv prefixes. Each entry is matched element-by-element against
+ * the parsed argv — `["skill_eval_coverage"]` admits
+ * `skill_eval_coverage --check` but not `skill_eval_coverage; rm -rf /`,
+ * because the latter never parses into that shape.
+ *
+ * All but one are this repo's own scripts, run through `scripts-run`. That is a
+ * deliberately narrower surface than a general test-runner allowlist: these are
+ * deterministic, model-free, and already run in CI for other reasons.
+ */
+export const ALLOWLIST_PREFIXES: readonly (readonly string[])[] = [
+    ['skill_eval_coverage'],
+    ['domain_soundness_status'],
+    ['check_artefact_count_messaging'],
+    ['check_enforcement_coverage'],
+    ['check_token_regression'],
+    ['lint_agent_security'],
+    ['measure_lexical_ranking'],
+    ['vitest', 'run'],
+];
+
+/** Shell metacharacters plus the control bytes used to smuggle a second command. */
+const UNSAFE_CHARS = new Set(['&', ';', '|', '>', '<', '`', '$', '\n', '\r', '\0']);
+
+const WINDOWS_ABSOLUTE = /^[A-Za-z]:[\\/]/;
+
+/** Commands that are not repo scripts and must not be routed through scripts-run. */
+const NON_SCRIPT_PREFIXES = new Set(['vitest']);
+
+export interface ExecPointer {
+    /** The command as written in the ledger, e.g. `skill_eval_coverage --check`. */
+    command: string;
+    /** The exit code the claim asserts. */
+    expected: number;
+}
+
+export interface ExecOutcome {
+    /** `true` only when the command ran AND matched the asserted exit code. */
+    verified: boolean;
+    /** `true` when the command ran and disagreed — a real finding, not a skip. */
+    mismatch: boolean;
+    /** Human-readable verdict for the report. */
+    reason: string;
+}
+
+/**
+ * Parse `exec:<command> -> <code>`. Accepts `->` and the `→` the docs render.
+ * Returns null when `raw` is not an exec pointer at all, so callers can fall
+ * through to the path/URL forms.
+ */
+export function parse_exec_pointer(raw: string): ExecPointer | { error: string } | null {
+    const ev = raw.trim();
+    if (!ev.startsWith(EXEC_PREFIX)) return null;
+
+    const body = ev.slice(EXEC_PREFIX.length).trim();
+    const arrow = body.match(/\s*(?:->|→)\s*(\d+)\s*$/);
+    if (!arrow) return { error: 'exec pointer missing the `-> <exit-code>` suffix' };
+
+    const command = body.slice(0, arrow.index).trim();
+    if (!command) return { error: 'exec pointer has an empty command' };
+
+    return { command, expected: Number(arrow[1]) };
+}
+
+/**
+ * Split a command into argv without invoking a shell. Deliberately minimal: no
+ * quote handling, no expansion, no substitution. Anything that would *need*
+ * those is rejected by `args_are_safe` anyway, so supporting them would only
+ * widen the surface.
+ */
+export function split_argv(command: string): string[] {
+    return command.split(/\s+/).filter((t) => t.length > 0);
+}
+
+/** Does argv start with an allowlisted prefix? */
+export function command_is_allowlisted(argv: string[]): boolean {
+    return ALLOWLIST_PREFIXES.some(
+        (prefix) => argv.length >= prefix.length && prefix.every((tok, i) => argv[i] === tok),
+    );
+}
+
+/** Would this argument reach outside the repo? */
+function targets_outside_repo(candidate: string): boolean {
+    if (candidate.startsWith('/')) return true;
+    if (WINDOWS_ABSOLUTE.test(candidate)) return true;
+    if (candidate === '..' || candidate.startsWith('../')) return true;
+    return candidate.includes('/../');
+}
+
+/**
+ * Re-check every argument after the allowlisted prefix.
+ *
+ * The `--flag=value` split is the part worth keeping: an allowlist that only
+ * inspects the token as written treats `--rootdir=/etc` as a flag and lets the
+ * path through. Here the right-hand side is extracted and checked on its own.
+ */
+export function args_are_safe(argv: string[]): boolean {
+    for (const arg of argv.slice(1)) {
+        for (const ch of arg) {
+            if (UNSAFE_CHARS.has(ch)) return false;
+        }
+        const eq = arg.indexOf('=');
+        const candidate = arg.startsWith('-') && eq !== -1 ? arg.slice(eq + 1) : arg;
+        if (candidate && targets_outside_repo(candidate)) return false;
+    }
+    return true;
+}
+
+/**
+ * Static validation — everything checkable without running anything.
+ *
+ * Split out from `run_exec_evidence` on purpose: a malformed or non-allowlisted
+ * command is a defect in the *ledger*, so it must fail on a laptop too. Only
+ * the re-execution half is environment-dependent. Returns null when the pointer
+ * is well-formed and admissible, else the reason.
+ */
+export function exec_static_error(pointer: ExecPointer): string | null {
+    const argv = split_argv(pointer.command);
+    if (argv.length === 0) return 'exec pointer has an empty command';
+    if (!command_is_allowlisted(argv)) {
+        return `exec command \`${pointer.command}\` is not in the deterministic allowlist`;
+    }
+    if (!args_are_safe(argv)) {
+        return `exec command \`${pointer.command}\` carries a suspicious argument`;
+    }
+    return null;
+}
+
+/**
+ * May this environment execute evidence commands?
+ *
+ * CI only. A consumer's checkout never re-runs a claim's command — the upstream
+ * package's ledger is not the consumer's business, and "runs in the repository
+ * root with full filesystem access" is a property to confine, not to trust.
+ */
+export function exec_allowed_here(env: NodeJS.ProcessEnv = process.env): boolean {
+    if (env.AGENT_CONFIG_EXEC_EVIDENCE === '1') return true; // maintainer opt-in, one run
+    return env.CI === 'true' || env.CI === '1';
+}
+
+/** Build the real argv: repo scripts go through `scripts-run`, others run directly. */
+function resolve_runner(argv: string[], repo: string): { file: string; args: string[] } {
+    const head = argv[0] as string;
+    if (NON_SCRIPT_PREFIXES.has(head)) {
+        return { file: path.join(repo, 'node_modules', '.bin', head), args: argv.slice(1) };
+    }
+    return {
+        file: path.join(repo, 'scripts-run'),
+        args: [`src/scripts/${head}`, ...argv.slice(1)],
+    };
+}
+
+/**
+ * Run an allowlisted evidence command and compare its exit code to the claim.
+ *
+ * Never throws: every failure path returns an `ExecOutcome` so one bad pointer
+ * cannot take down the whole ledger check. `mismatch` distinguishes "ran and
+ * disagreed" (a finding) from "could not run" (a skip) — collapsing those two
+ * is how a verifier turns into a rubber stamp.
+ */
+export function run_exec_evidence(pointer: ExecPointer, repo: string, timeoutMs = 300_000): ExecOutcome {
+    const argv = split_argv(pointer.command);
+
+    if (argv.length === 0) {
+        return { verified: false, mismatch: false, reason: 'UNVERIFIED: empty command' };
+    }
+    if (!command_is_allowlisted(argv)) {
+        return {
+            verified: false,
+            mismatch: false,
+            reason: `UNVERIFIED: \`${pointer.command}\` is not in the deterministic allowlist`,
+        };
+    }
+    if (!args_are_safe(argv)) {
+        return {
+            verified: false,
+            mismatch: false,
+            reason: `UNVERIFIED: \`${pointer.command}\` carries a suspicious argument`,
+        };
+    }
+
+    const { file, args } = resolve_runner(argv, repo);
+    const result = spawnSync(file, args, {
+        cwd: repo,
+        encoding: 'utf-8',
+        timeout: timeoutMs,
+        shell: false,
+    });
+
+    if (result.error) {
+        return {
+            verified: false,
+            mismatch: false,
+            reason: `UNVERIFIED: could not execute \`${pointer.command}\` (${result.error.message})`,
+        };
+    }
+    if (result.status === null) {
+        return {
+            verified: false,
+            mismatch: false,
+            reason: `UNVERIFIED: \`${pointer.command}\` was killed (timeout or signal)`,
+        };
+    }
+    if (result.status !== pointer.expected) {
+        return {
+            verified: false,
+            mismatch: true,
+            reason: `evidence mismatch — claim asserts exit ${pointer.expected}, \`${pointer.command}\` exited ${result.status}`,
+        };
+    }
+    return {
+        verified: true,
+        mismatch: false,
+        reason: `verified \`${pointer.command}\` (exit ${result.status})`,
+    };
+}

package/src/scripts/_lib/fixtures/secret-detector/negatives.txt

@@ -0,0 +1,10 @@
+# secret-detector negative fixtures — all benign, must not flag high/medium.
+api_key = "changeme"
+api_key = "xxxxxxxxxxxxxxxx"
+password = "your-password-here"
+build commit d41d8cd98f00b204e9800998ecf8427e5f1a2b3c
+request id 550e8400-e29b-41d4-a716-446655440000
+bundle integrity 3a7bd3e2360a3d29eea436fcfb7e44c735d117c42d1c1835420b6b9942dd4f1b
+data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAAElFTkSuQmCC
+API_KEY=your-key-here
+aws_key = "AKIAZ4Q7WXYT2H9RVBKL"  # secret-allow

package/src/scripts/_lib/fixtures/secret-detector/positives.txt

@@ -0,0 +1,11 @@
+# secret-detector positive fixtures — every value below is FAKE, do not use.
+# Line format: <kind-label>|<fake-secret>
+aws|AKIA1234567890ABCDEF
+github|ghp_0123456789abcdefghijklmnopqrstuvwxyz
+stripe|sk_live_0123456789abcdefABCDEF
+google|AIza0123456789abcdefghijklmnopqrstuvwxy
+slack|xoxb-0123456789-abcdefABCDEF
+pem|-----BEGIN RSA PRIVATE KEY-----
+jwt|eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+dburl|postgres://dbuser:s3cr3tpass@db.internal:5432/app
+assignment|api_key = "s3cr3tV4lu3Abc123"

package/src/scripts/_lib/kernel_rules.ts

@@ -0,0 +1,46 @@
+/**
+ * The locked kernel set — one definition, imported everywhere.
+ *
+ * These nine rules are the Iron-Law floor (`docs/contracts/kernel-membership.md`
+ * § 4). Before this module the list existed three times — in
+ * `check_kernel_rule_bundle.ts`, `iron_law_sha.ts`, and `measure_rule_budget.ts`
+ * — two of them carrying a "kept in sync with …" comment, which is the standard
+ * way a list drifts: the comment records an intention, nothing enforces it.
+ *
+ * Membership is a governance decision, not a convenience. Adding or removing an
+ * entry changes what may never be overridden, what the prefix-stability snapshot
+ * covers, and what the one-kernel-rule-per-PR gate applies to. Change it here,
+ * once, and let every consumer follow.
+ */
+
+/** Kernel rule ids, stem form (no extension), in stable sorted order. */
+export const KERNEL_RULE_IDS: readonly string[] = [
+    'agent-authority',
+    'ask-when-uncertain',
+    'commit-policy',
+    'direct-answers',
+    'language-and-tone',
+    'no-cheap-questions',
+    'non-destructive-by-default',
+    'scope-control',
+    'verify-before-complete',
+] as const;
+
+/** Same set, `.md` filename form — what path-matching consumers compare against. */
+export const KERNEL_RULE_FILENAMES: ReadonlySet<string> = new Set(
+    KERNEL_RULE_IDS.map((id) => `${id}.md`),
+);
+
+/** Set form of the stems, for membership tests that key on the id. */
+export const KERNEL_RULE_ID_SET: ReadonlySet<string> = new Set(KERNEL_RULE_IDS);
+
+/**
+ * True when `name` names a kernel rule, in either stem or `.md` form.
+ *
+ * Accepts a bare id, a filename, or a path ending in either — callers hold the
+ * name in all three shapes and should not each re-derive the normalisation.
+ */
+export function is_kernel_rule(name: string): boolean {
+    const base = name.replace(/\\/g, '/').split('/').pop() ?? name;
+    return KERNEL_RULE_ID_SET.has(base.replace(/\.md$/, ''));
+}