@agenttrail/guardrails 0.0.1 → 0.1.0

package/dist/guardrails.d.cts

@@ -3,28 +3,23 @@ export { Action, FixtureInput, Fixtures, Match, RuleInput, Severity } from './sc
 import 'zod';
 
 /**
- * The eight packs, and the order they are presented in.
+ * The eleven packs, and the order they are presented in.
  *
  * These ids are authoritative and shared with the rules authored against them,
- * and with the guard's `config.json` `enabledPacks` (spec 11). An earlier design
- * named ten differently-titled packs; the two could not both have been right.
- * Renaming one of these is a breaking change to a user's config file, not a
- * tidy-up — `safety-bypass` was `guardrail-bypass` until the rename, and that move
- * was only free because nothing was published yet.
- *
- * Working-tree destruction leads deliberately. Destructive git commands are the
- * most frequently documented real-world coding-agent failure, with filed
- * incidents across Claude Code, Gemini CLI and Codex — while our own real-trace
- * mining found production destructive-SQL at zero.
- *
- * The per-pack counts in spec 7.1 are a budget, not a quota: trim or extend at
- * authoring time. They are deliberately NOT encoded here, because a rule count
- * asserted in code becomes a reason to write a weak rule to hit a number.
+ * and with the guard's `config.json` `enabledPacks`. Renaming one of these is a
+ * breaking change to a user's config file.
+ *
+ * Working-tree destruction leads: destructive git commands are the most frequently
+ * documented coding-agent failure, with public incident reports across Claude
+ * Code, Gemini CLI and Codex.
+ *
+ * Per-pack rule counts are deliberately NOT encoded here: a rule count asserted in
+ * code becomes a reason to write a weak rule to hit a number.
  */
-declare const PACKS: readonly ["working-tree", "destructive-data", "prod-infra", "secret-exposure", "rce-supply-chain", "safety-bypass", "privilege-supply-chain", "file-scope"];
-/** One of the eight pack ids. A rule's `category` is always one of these. */
+declare const PACKS: readonly ["working-tree", "destructive-data", "prod-infra", "secret-exposure", "rce-supply-chain", "safety-bypass", "privilege-supply-chain", "file-scope", "agent-context", "test-integrity", "exfiltration"];
+/** One of the eleven pack ids. A rule's `category` is always one of these. */
 type Pack = (typeof PACKS)[number];
-/** Is this string one of the eight pack ids? */
+/** Is this string one of the eleven pack ids? */
 declare function isPack(value: string): value is Pack;
 
 /**
@@ -42,17 +37,9 @@ declare function isPack(value: string): value is Pack;
  *     echo "never run rm -rf /"                       -> DENY  dd.rm-rf-absolute
  *     curl --data "we ran rm -rf /tmp/x" https://…    -> DENY  dd.rm-rf-absolute
  *
- * A person documenting this tool is blocked by this tool. Measured on the
- * shipped bundle, **48 of the 56 rules had it — every command-channel rule.**
- * The eight that did not are the `file_glob` rules, which never see a command.
- *
- * It was NOT found by the 438 fixtures or the 307-entry quiet corpus, and could
- * not have been: every entry in both is a command somebody wrote on purpose. It
- * took 997 real transcripts, where an automated `curl` posting an issue-tracker comment
- * whose BODY discussed `rm -rf` was labelled "rm -rf against an absolute path".
- * That is why the quoted-mention family is now generated as a cross-product over
- * the whole corpus (`guardrails-quoted-mention.test.ts`) rather than listed by
- * hand: a hand-written list only covers the rules somebody remembered.
+ * Without an exemption, a person documenting this tool is blocked by this tool.
+ * That applies to every command-channel rule — 62 of the 74. The twelve `file_glob`
+ * rules never see a command.
  *
  * ── Why exemption by CARRIER VERB, and not by "the payload is quoted" ────────
  *
@@ -73,17 +60,14 @@ declare function isPack(value: string): value is Pack;
  *     echo "rm -rf /" | bash          -> NOT exempt: `|` is outside the quotes
  *     echo "$(rm -rf /var)"           -> NOT exempt: the shell expands `$( )`
  *
- * This is stricter than the `block-destructive-sql` treatment it generalises.
- * That rule — the ONLY one that had this exclusion, which is the defect — excluded
- * any command whose text NAMED a search tool, anywhere, and so left a documented
- * hole on compound commands: `grep x . && rm -rf /` was exempt. Anchoring closes
- * it. Its loose condition is KEPT alongside the anchored one rather than replaced:
- * the loose form still covers a search that is not the FIRST word — measured,
- * `cat runbook.md | grep -n TRUNCATE` is exempt only because of it — and a fix is
- * not allowed to regress what the rule already allowed. The other four rules with a pre-existing `none_of`
+ * `block-destructive-sql` also keeps a looser condition of its own: it exempts any
+ * command whose text NAMES a search or history tool, anywhere. That covers a search
+ * that is not the FIRST word, such as `cat runbook.md | grep -n TRUNCATE`, and it is
+ * why that rule misses a compound command that both searches and executes, as its
+ * description states. The other four rules with their own `none_of`
  * (`se.env-print`, `require-approval-rm-rf`, `wt.clean-fdx`, `wt.restore-path`)
  * exclude something else entirely — a dry run, a build directory, `--staged` —
- * and are likewise appended to, never replaced.
+ * and have these conditions appended, not replaced.
  *
  * ── The character classes, and why each character is in them ─────────────────
  *
@@ -204,8 +188,8 @@ declare const QUOTED_MENTION: readonly MatchCondition[];
  * harness reads `"command" in fixture`.
  *
  * Writing every fixture out longhand would work and would be unreadable, so
- * these exist instead. They are also more honest than the shorthand was: the
- * CHANNEL is now visible at every single fixture, and the channel is the thing
+ * these exist instead. They also make the CHANNEL visible at every single
+ * fixture, and the channel is the thing
  * that silently makes a fixture vacuous — a `file_glob` rule handed a command
  * fixture matches nothing, and an `allow` fixture that matches nothing passes.
  */
@@ -254,35 +238,31 @@ declare function mentions(text: string): Fixture[];
  * The catalog's own version and publication date.
  *
  * These are the two facts the offline guard needs in order to tell someone how old
- * their protection is. The guard has no update check and no network path for rules
- * (spec 8.4), so a user's rules are frozen on the day they installed and nothing
- * else in the system can tell them that.
+ * their protection is. The guard has no update check and no network path for rules,
+ * so a user's rules are frozen on the day they installed and nothing else can tell
+ * them that.
  *
  * ── Why the stamp lives HERE and not in `@agenttrail/guard` ──────────────────
- * The guard BUNDLES this package at build time (spec 11.1.1), so it is *this*
- * package's version that determines which rules a user is actually running. The
- * guard's own version answers a different question and would be the wrong number:
- * `guard@0.4.1` may ship an unchanged catalog, and two different guard versions may
- * carry the same rules. Spec 11.1.1 states it outright — "that is exactly why C6
- * has `status` print the bundled catalog version rather than the guard's."
+ * The guard BUNDLES this package at build time, so it is *this* package's version
+ * that determines which rules a user is actually running. The guard's own version
+ * answers a different question and would be the wrong number: `guard@0.4.1` may ship
+ * an unchanged catalog, and two different guard versions may carry the same rules.
  *
  * ── This module imports nothing, and that is load-bearing ───────────────────
- * It is exported from `rules.ts`, the zod-free entry `packages/guard` bundles into the
+ * It is exported from `rules.ts`, the zod-free entry the guard bundles into the
  * file Claude Code runs before every tool call. Two string constants add nothing to
  * that bundle; an import of `schema.ts` here would add zod to it. Add no imports here.
  *
  * ── Both constants are hand-written, and that is deliberate ──────────────────
- * A build-time `define` would reach `dist/` only. In this monorepo the guard resolves
- * `@agenttrail/guardrails` to `src/index.ts`, so a defined value would exist in the
- * published tarball and be absent everywhere a test can see it — the shipped value
- * would be the one value never exercised. `guard/src/core/version.ts` sets the same
- * precedent, and `__tests__/stamp.test.ts` pins `CATALOG_VERSION` to `package.json`
- * so the two cannot drift in silence.
+ * A build-time `define` would reach `dist/` only, so the value would exist in the
+ * published tarball and be absent from the source every test imports — the shipped
+ * value would be the one value never exercised. `__tests__/stamp.test.ts` pins
+ * `CATALOG_VERSION` to `package.json` so the two cannot drift in silence.
  *
  * ── AT RELEASE, BUMP BOTH CONSTANTS BELOW, TOGETHER ──────────────────────────
  * Bumping `package.json`'s version alone turns `stamp.test.ts` red, and that is the
  * point: it is what brings whoever cut the release into this file, where the date is
- * a few lines away. Publish order is `guardrails` first, then `guard` (spec 11.1.1);
+ * a few lines away. Publish order is `guardrails` first, then `guard`;
  * a guard release carries whatever stamp was here when it was built.
  *
  * Forgetting to advance the date understates how fresh the rules are, which tells a
@@ -296,36 +276,26 @@ declare function mentions(text: string): Fixture[];
  * Pinned to `package.json`'s `version` by `__tests__/stamp.test.ts` — this is a copy
  * of that value, not an independent one, and the test is what makes the copy safe.
  */
-declare const CATALOG_VERSION = "0.0.1";
+declare const CATALOG_VERSION = "0.1.0";
 /**
- * When this catalog version was cut, as an ISO-8601 instant.
- *
- * For a version published to npm this is its publish date. For a pre-release cut from
- * the monorepo it is the commit that brought the corpus to this state — here,
- * `252c2e2c` ("feat(guardrails): rule schema, pack registry and fixture harness"),
- * which created the package at `0.0.1`. Both readings answer the user's actual
- * question, which is not "when did this reach a registry" but "how old are the rules
- * I am running".
- *
- * It is a real, sourced instant rather than a plausible-looking default. If a future
- * release cannot source one, leave it absent rather than approximate: the renderer in
- * `guard/src/core/catalog-stamp.ts` degrades honestly, and a wrong date that looks
- * right is worse than a missing one in a tool whose whole proposition is candour
- * about its own coverage.
+ * When the rules in this catalog reached their current state, as an ISO-8601
+ * instant. The question it answers is not "when did this reach a registry" but "how
+ * old are the rules I am running".
+ *
+ * If a release cannot source a real date, leave it absent rather than approximate:
+ * the guard handles a missing date, and a wrong date that looks right is worse than
+ * a missing one.
  */
-declare const CATALOG_PUBLISHED_AT = "2026-09-07T12:44:09Z";
+declare const CATALOG_PUBLISHED_AT = "2026-09-15T07:13:18Z";
 
 /**
  * The corpus itself — rules only, and **deliberately free of zod**.
  *
  * ── Why this is a separate entry point from `index.ts` ───────────────────────
  *
- * `packages/guard` bundles this catalog into `plugin/scripts/guard-hook.mjs`, the
- * file Claude Code executes before EVERY tool call, in a fresh Node process, under
- * a 10s ceiling. `built-artifact.test.ts` asserts that bundle contains no
- * `ZodError` and no `ZodType`, captioned "the whole point of not importing
- * ./context" — because the guard "cannot afford to parse a validator it never
- * calls" (`guard/src/core/normalize.ts`).
+ * The guard bundles this catalog into its hook script, the file Claude Code
+ * executes before EVERY tool call, in a fresh Node process, under a 10s ceiling.
+ * That bundle must not carry a validator it never calls.
  *
  * The package ROOT cannot satisfy that: `index.ts` re-exports `./schema.js`, which
  * value-imports zod. So the guard imports `@agenttrail/guardrails/guardrails` — this
@@ -334,19 +304,15 @@ declare const CATALOG_PUBLISHED_AT = "2026-09-07T12:44:09Z";
  * reference to `./schema.js`, which esbuild erases. Everyone else keeps using the
  * root and gets the schema with it.
  *
- * Measured on this machine, best-of-N cold `node`: an empty process is 20ms; a cold
- * import of the package root, validating 56 rules through `defineRule`, is 40ms.
- * The subpath gives that 20ms back on every tool call, forever.
+ * A cold import of the package root, validating every rule through `defineRule`,
+ * takes about twice as long as an empty Node process. The subpath avoids that on
+ * every tool call.
  *
- * ── Where validation went ───────────────────────────────────────────────────
+ * ── Where validation runs ───────────────────────────────────────────────────
  *
- * This package used to validate at module load via `defineRule()`, on the stated
- * reasoning that "an authoring mistake fails at import — which is to say, at TEST
- * TIME."
- * A test IS test time: `__tests__/corpus.test.ts` runs `parseRule()` over all 56
- * and fails on any invalid one, and proves that sweep bites with a deliberately
- * malformed rule. The guarantee is unchanged; only the mechanism moved off the
- * hook's hot path. `defineRule` stays exported for contributors authoring locally.
+ * At test time: `__tests__/corpus.test.ts` runs `parseRule()` over every rule and
+ * fails on any invalid one, and proves that sweep bites with a deliberately
+ * malformed rule. `defineRule` is exported for contributors authoring locally.
  *
  * So every rule file exports a plain object literal typed `satisfies Rule` with a
  * TYPE-only schema import. `corpus.test.ts` is what stops one from drifting.

package/dist/guardrails.d.ts

@@ -3,28 +3,23 @@ export { Action, FixtureInput, Fixtures, Match, RuleInput, Severity } from './sc
 import 'zod';
 
 /**
- * The eight packs, and the order they are presented in.
+ * The eleven packs, and the order they are presented in.
  *
  * These ids are authoritative and shared with the rules authored against them,
- * and with the guard's `config.json` `enabledPacks` (spec 11). An earlier design
- * named ten differently-titled packs; the two could not both have been right.
- * Renaming one of these is a breaking change to a user's config file, not a
- * tidy-up — `safety-bypass` was `guardrail-bypass` until the rename, and that move
- * was only free because nothing was published yet.
- *
- * Working-tree destruction leads deliberately. Destructive git commands are the
- * most frequently documented real-world coding-agent failure, with filed
- * incidents across Claude Code, Gemini CLI and Codex — while our own real-trace
- * mining found production destructive-SQL at zero.
- *
- * The per-pack counts in spec 7.1 are a budget, not a quota: trim or extend at
- * authoring time. They are deliberately NOT encoded here, because a rule count
- * asserted in code becomes a reason to write a weak rule to hit a number.
+ * and with the guard's `config.json` `enabledPacks`. Renaming one of these is a
+ * breaking change to a user's config file.
+ *
+ * Working-tree destruction leads: destructive git commands are the most frequently
+ * documented coding-agent failure, with public incident reports across Claude
+ * Code, Gemini CLI and Codex.
+ *
+ * Per-pack rule counts are deliberately NOT encoded here: a rule count asserted in
+ * code becomes a reason to write a weak rule to hit a number.
  */
-declare const PACKS: readonly ["working-tree", "destructive-data", "prod-infra", "secret-exposure", "rce-supply-chain", "safety-bypass", "privilege-supply-chain", "file-scope"];
-/** One of the eight pack ids. A rule's `category` is always one of these. */
+declare const PACKS: readonly ["working-tree", "destructive-data", "prod-infra", "secret-exposure", "rce-supply-chain", "safety-bypass", "privilege-supply-chain", "file-scope", "agent-context", "test-integrity", "exfiltration"];
+/** One of the eleven pack ids. A rule's `category` is always one of these. */
 type Pack = (typeof PACKS)[number];
-/** Is this string one of the eight pack ids? */
+/** Is this string one of the eleven pack ids? */
 declare function isPack(value: string): value is Pack;
 
 /**
@@ -42,17 +37,9 @@ declare function isPack(value: string): value is Pack;
  *     echo "never run rm -rf /"                       -> DENY  dd.rm-rf-absolute
  *     curl --data "we ran rm -rf /tmp/x" https://…    -> DENY  dd.rm-rf-absolute
  *
- * A person documenting this tool is blocked by this tool. Measured on the
- * shipped bundle, **48 of the 56 rules had it — every command-channel rule.**
- * The eight that did not are the `file_glob` rules, which never see a command.
- *
- * It was NOT found by the 438 fixtures or the 307-entry quiet corpus, and could
- * not have been: every entry in both is a command somebody wrote on purpose. It
- * took 997 real transcripts, where an automated `curl` posting an issue-tracker comment
- * whose BODY discussed `rm -rf` was labelled "rm -rf against an absolute path".
- * That is why the quoted-mention family is now generated as a cross-product over
- * the whole corpus (`guardrails-quoted-mention.test.ts`) rather than listed by
- * hand: a hand-written list only covers the rules somebody remembered.
+ * Without an exemption, a person documenting this tool is blocked by this tool.
+ * That applies to every command-channel rule — 62 of the 74. The twelve `file_glob`
+ * rules never see a command.
  *
  * ── Why exemption by CARRIER VERB, and not by "the payload is quoted" ────────
  *
@@ -73,17 +60,14 @@ declare function isPack(value: string): value is Pack;
  *     echo "rm -rf /" | bash          -> NOT exempt: `|` is outside the quotes
  *     echo "$(rm -rf /var)"           -> NOT exempt: the shell expands `$( )`
  *
- * This is stricter than the `block-destructive-sql` treatment it generalises.
- * That rule — the ONLY one that had this exclusion, which is the defect — excluded
- * any command whose text NAMED a search tool, anywhere, and so left a documented
- * hole on compound commands: `grep x . && rm -rf /` was exempt. Anchoring closes
- * it. Its loose condition is KEPT alongside the anchored one rather than replaced:
- * the loose form still covers a search that is not the FIRST word — measured,
- * `cat runbook.md | grep -n TRUNCATE` is exempt only because of it — and a fix is
- * not allowed to regress what the rule already allowed. The other four rules with a pre-existing `none_of`
+ * `block-destructive-sql` also keeps a looser condition of its own: it exempts any
+ * command whose text NAMES a search or history tool, anywhere. That covers a search
+ * that is not the FIRST word, such as `cat runbook.md | grep -n TRUNCATE`, and it is
+ * why that rule misses a compound command that both searches and executes, as its
+ * description states. The other four rules with their own `none_of`
  * (`se.env-print`, `require-approval-rm-rf`, `wt.clean-fdx`, `wt.restore-path`)
  * exclude something else entirely — a dry run, a build directory, `--staged` —
- * and are likewise appended to, never replaced.
+ * and have these conditions appended, not replaced.
  *
  * ── The character classes, and why each character is in them ─────────────────
  *
@@ -204,8 +188,8 @@ declare const QUOTED_MENTION: readonly MatchCondition[];
  * harness reads `"command" in fixture`.
  *
  * Writing every fixture out longhand would work and would be unreadable, so
- * these exist instead. They are also more honest than the shorthand was: the
- * CHANNEL is now visible at every single fixture, and the channel is the thing
+ * these exist instead. They also make the CHANNEL visible at every single
+ * fixture, and the channel is the thing
  * that silently makes a fixture vacuous — a `file_glob` rule handed a command
  * fixture matches nothing, and an `allow` fixture that matches nothing passes.
  */
@@ -254,35 +238,31 @@ declare function mentions(text: string): Fixture[];
  * The catalog's own version and publication date.
  *
  * These are the two facts the offline guard needs in order to tell someone how old
- * their protection is. The guard has no update check and no network path for rules
- * (spec 8.4), so a user's rules are frozen on the day they installed and nothing
- * else in the system can tell them that.
+ * their protection is. The guard has no update check and no network path for rules,
+ * so a user's rules are frozen on the day they installed and nothing else can tell
+ * them that.
  *
  * ── Why the stamp lives HERE and not in `@agenttrail/guard` ──────────────────
- * The guard BUNDLES this package at build time (spec 11.1.1), so it is *this*
- * package's version that determines which rules a user is actually running. The
- * guard's own version answers a different question and would be the wrong number:
- * `guard@0.4.1` may ship an unchanged catalog, and two different guard versions may
- * carry the same rules. Spec 11.1.1 states it outright — "that is exactly why C6
- * has `status` print the bundled catalog version rather than the guard's."
+ * The guard BUNDLES this package at build time, so it is *this* package's version
+ * that determines which rules a user is actually running. The guard's own version
+ * answers a different question and would be the wrong number: `guard@0.4.1` may ship
+ * an unchanged catalog, and two different guard versions may carry the same rules.
  *
  * ── This module imports nothing, and that is load-bearing ───────────────────
- * It is exported from `rules.ts`, the zod-free entry `packages/guard` bundles into the
+ * It is exported from `rules.ts`, the zod-free entry the guard bundles into the
  * file Claude Code runs before every tool call. Two string constants add nothing to
  * that bundle; an import of `schema.ts` here would add zod to it. Add no imports here.
  *
  * ── Both constants are hand-written, and that is deliberate ──────────────────
- * A build-time `define` would reach `dist/` only. In this monorepo the guard resolves
- * `@agenttrail/guardrails` to `src/index.ts`, so a defined value would exist in the
- * published tarball and be absent everywhere a test can see it — the shipped value
- * would be the one value never exercised. `guard/src/core/version.ts` sets the same
- * precedent, and `__tests__/stamp.test.ts` pins `CATALOG_VERSION` to `package.json`
- * so the two cannot drift in silence.
+ * A build-time `define` would reach `dist/` only, so the value would exist in the
+ * published tarball and be absent from the source every test imports — the shipped
+ * value would be the one value never exercised. `__tests__/stamp.test.ts` pins
+ * `CATALOG_VERSION` to `package.json` so the two cannot drift in silence.
  *
  * ── AT RELEASE, BUMP BOTH CONSTANTS BELOW, TOGETHER ──────────────────────────
  * Bumping `package.json`'s version alone turns `stamp.test.ts` red, and that is the
  * point: it is what brings whoever cut the release into this file, where the date is
- * a few lines away. Publish order is `guardrails` first, then `guard` (spec 11.1.1);
+ * a few lines away. Publish order is `guardrails` first, then `guard`;
  * a guard release carries whatever stamp was here when it was built.
  *
  * Forgetting to advance the date understates how fresh the rules are, which tells a
@@ -296,36 +276,26 @@ declare function mentions(text: string): Fixture[];
  * Pinned to `package.json`'s `version` by `__tests__/stamp.test.ts` — this is a copy
  * of that value, not an independent one, and the test is what makes the copy safe.
  */
-declare const CATALOG_VERSION = "0.0.1";
+declare const CATALOG_VERSION = "0.1.0";
 /**
- * When this catalog version was cut, as an ISO-8601 instant.
- *
- * For a version published to npm this is its publish date. For a pre-release cut from
- * the monorepo it is the commit that brought the corpus to this state — here,
- * `252c2e2c` ("feat(guardrails): rule schema, pack registry and fixture harness"),
- * which created the package at `0.0.1`. Both readings answer the user's actual
- * question, which is not "when did this reach a registry" but "how old are the rules
- * I am running".
- *
- * It is a real, sourced instant rather than a plausible-looking default. If a future
- * release cannot source one, leave it absent rather than approximate: the renderer in
- * `guard/src/core/catalog-stamp.ts` degrades honestly, and a wrong date that looks
- * right is worse than a missing one in a tool whose whole proposition is candour
- * about its own coverage.
+ * When the rules in this catalog reached their current state, as an ISO-8601
+ * instant. The question it answers is not "when did this reach a registry" but "how
+ * old are the rules I am running".
+ *
+ * If a release cannot source a real date, leave it absent rather than approximate:
+ * the guard handles a missing date, and a wrong date that looks right is worse than
+ * a missing one.
  */
-declare const CATALOG_PUBLISHED_AT = "2026-09-07T12:44:09Z";
+declare const CATALOG_PUBLISHED_AT = "2026-09-15T07:13:18Z";
 
 /**
  * The corpus itself — rules only, and **deliberately free of zod**.
  *
  * ── Why this is a separate entry point from `index.ts` ───────────────────────
  *
- * `packages/guard` bundles this catalog into `plugin/scripts/guard-hook.mjs`, the
- * file Claude Code executes before EVERY tool call, in a fresh Node process, under
- * a 10s ceiling. `built-artifact.test.ts` asserts that bundle contains no
- * `ZodError` and no `ZodType`, captioned "the whole point of not importing
- * ./context" — because the guard "cannot afford to parse a validator it never
- * calls" (`guard/src/core/normalize.ts`).
+ * The guard bundles this catalog into its hook script, the file Claude Code
+ * executes before EVERY tool call, in a fresh Node process, under a 10s ceiling.
+ * That bundle must not carry a validator it never calls.
  *
  * The package ROOT cannot satisfy that: `index.ts` re-exports `./schema.js`, which
  * value-imports zod. So the guard imports `@agenttrail/guardrails/guardrails` — this
@@ -334,19 +304,15 @@ declare const CATALOG_PUBLISHED_AT = "2026-09-07T12:44:09Z";
  * reference to `./schema.js`, which esbuild erases. Everyone else keeps using the
  * root and gets the schema with it.
  *
- * Measured on this machine, best-of-N cold `node`: an empty process is 20ms; a cold
- * import of the package root, validating 56 rules through `defineRule`, is 40ms.
- * The subpath gives that 20ms back on every tool call, forever.
+ * A cold import of the package root, validating every rule through `defineRule`,
+ * takes about twice as long as an empty Node process. The subpath avoids that on
+ * every tool call.
  *
- * ── Where validation went ───────────────────────────────────────────────────
+ * ── Where validation runs ───────────────────────────────────────────────────
  *
- * This package used to validate at module load via `defineRule()`, on the stated
- * reasoning that "an authoring mistake fails at import — which is to say, at TEST
- * TIME."
- * A test IS test time: `__tests__/corpus.test.ts` runs `parseRule()` over all 56
- * and fails on any invalid one, and proves that sweep bites with a deliberately
- * malformed rule. The guarantee is unchanged; only the mechanism moved off the
- * hook's hot path. `defineRule` stays exported for contributors authoring locally.
+ * At test time: `__tests__/corpus.test.ts` runs `parseRule()` over every rule and
+ * fails on any invalid one, and proves that sweep bites with a deliberately
+ * malformed rule. `defineRule` is exported for contributors authoring locally.
  *
  * So every rule file exports a plain object literal typed `satisfies Rule` with a
  * TYPE-only schema import. `corpus.test.ts` is what stops one from drifting.

package/dist/guardrails.js

@@ -20,7 +20,7 @@ import {
   mentions,
   pwsh,
   rulesForPack
-} from "./chunk-DKLS2UEL.js";
+} from "./chunk-DBB7HO4T.js";
 export {
   CATALOG_PUBLISHED_AT,
   CATALOG_VERSION,