plumbbob 0.9.3 → 0.10.0

package/node_modules/checkride/dist/pm/launch.js

@@ -0,0 +1,108 @@
+/**
+ * Launch refusals — the package manager declining to start the script at all.
+ *
+ * Every caller that runs the repo's `check` script reads a non-zero exit as
+ * "the pipeline is red". That reading is wrong for a whole class of exits,
+ * because a package manager refuses *before* the script runs and still exits
+ * non-zero: pnpm answers an `engines.node` mismatch with
+ * `ERR_PNPM_UNSUPPORTED_ENGINE` and exit 1, exactly as it answers a failing
+ * test. The difference is invisible in the status code and obvious in the
+ * output, so the output is what is read here.
+ *
+ * The distinction is not cosmetic. A pipeline red is cleared by fixing code and
+ * points at `.check/`; a launch refusal cannot be cleared by any code change and
+ * points at nothing, because nothing ran and no artifact was written. Reporting
+ * the second as the first sends the reader — human or agent — to an artifact
+ * that does not describe this run, which is the failure this table exists to
+ * prevent.
+ *
+ * Each refusal also carries {@link RefusalFix}, because "no code change clears
+ * it" is true of only *some* of them. That field is what lets the gate block on
+ * the ones an agent can fix and stand down on the ones it cannot, instead of
+ * blocking on both and looping forever on the second.
+ *
+ * **Every pattern here must be one a check's own output cannot contain.** A
+ * false positive is worse than the bug being fixed: it would tell someone their
+ * environment is broken while their code is what failed. The patterns are all
+ * package-manager error *codes*, and the one caller-supplied sentinel checkride
+ * writes itself; callers additionally gate on "this run wrote no summary", so a
+ * pipeline that demonstrably ran can never be reclassified by a tool that merely
+ * printed one of these strings.
+ */
+/** The sentinel a caller writes when the package-manager binary itself never started. */
+export const SPAWN_FAILED_MARKER = 'checkride: could not start';
+/**
+ * Markers that mean the script never started, most specific first.
+ *
+ * npm is the delicate one: it prints `EBADENGINE` as a *warning* on a version
+ * mismatch and runs the script anyway, and only `engine-strict` turns it into an
+ * error. Matching the bare code would reclassify a genuine red in any repo whose
+ * dependency tree carries one stale `engines` field — so the two error spellings
+ * npm has shipped are matched, and the warning is not.
+ *
+ * Only pnpm's and npm's spellings are listed, because those are the two the
+ * behavior above was verified against. Yarn's and bun's equivalents are
+ * deliberately absent rather than guessed: an unmatched refusal degrades to
+ * today's report (a red), while a wrong pattern degrades to a false diagnosis.
+ * Add one when a real output line is in hand, not before.
+ */
+const REFUSALS = [
+    {
+        marker: 'ERR_PNPM_UNSUPPORTED_ENGINE',
+        cause: "the repo's `engines` pin does not match the Node or pnpm running this process, and pnpm refuses to run a script under it",
+        fixable: 'environment',
+    },
+    {
+        marker: 'npm error code EBADENGINE',
+        cause: "the repo's `engines` pin does not match the Node running this process, and npm is configured `engine-strict`",
+        fixable: 'environment',
+    },
+    {
+        marker: 'npm ERR! code EBADENGINE',
+        cause: "the repo's `engines` pin does not match the Node running this process, and npm is configured `engine-strict`",
+        fixable: 'environment',
+    },
+    {
+        // `repo`, and deliberately: a missing `check` script is one edit away, and it
+        // is the one refusal an agent could otherwise *create* to escape the gate.
+        // Standing down here would make "delete the check script" a way out.
+        marker: 'ERR_PNPM_NO_SCRIPT',
+        cause: 'this repo has no `check` script for the gate to run',
+        fixable: 'repo',
+    },
+    {
+        marker: 'Missing script:',
+        cause: 'this repo has no `check` script for the gate to run',
+        fixable: 'repo',
+    },
+    {
+        marker: 'ERR_PNPM_NO_IMPORTER_MANIFEST_FOUND',
+        cause: 'there is no package.json here, so the package manager has nothing to run',
+        fixable: 'repo',
+    },
+    {
+        // corepack verifying a `packageManager` field against its bundled signing
+        // keys. Common after a corepack upgrade, and total: nothing runs.
+        marker: 'Cannot find matching keyid',
+        cause: 'corepack could not verify the package manager named in `packageManager`, so it never launched',
+        fixable: 'environment',
+    },
+    {
+        marker: SPAWN_FAILED_MARKER,
+        cause: 'the package-manager binary is not on this process’s PATH',
+        fixable: 'environment',
+    },
+];
+/**
+ * Classify `output` — whatever the child printed on either stream — as a launch
+ * refusal, or `null` when nothing in it says the script failed to start.
+ *
+ * `null` is the safe answer and the common one: an unrecognized refusal reads as
+ * a pipeline red, which is the behavior that predates this module. A new package
+ * manager or a reworded error therefore degrades to today's report rather than
+ * to a wrong one.
+ */
+export function launchRefusal(output) {
+    return REFUSALS.find((r) => output.includes(r.marker)) ?? null;
+}
+//# sourceMappingURL=launch.js.map

package/node_modules/checkride/dist/pm/launch.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"launch.js","sourceRoot":"","sources":["../../src/pm/launch.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA8BG;AAEH,yFAAyF;AACzF,MAAM,CAAC,MAAM,mBAAmB,GAAG,4BAA4B,CAAC;AA4BhE;;;;;;;;;;;;;;GAcG;AACH,MAAM,QAAQ,GAA6B;IACzC;QACE,MAAM,EAAE,6BAA6B;QACrC,KAAK,EAAE,0HAA0H;QACjI,OAAO,EAAE,aAAa;KACvB;IACD;QACE,MAAM,EAAE,2BAA2B;QACnC,KAAK,EAAE,8GAA8G;QACrH,OAAO,EAAE,aAAa;KACvB;IACD;QACE,MAAM,EAAE,0BAA0B;QAClC,KAAK,EAAE,8GAA8G;QACrH,OAAO,EAAE,aAAa;KACvB;IACD;QACE,8EAA8E;QAC9E,2EAA2E;QAC3E,qEAAqE;QACrE,MAAM,EAAE,oBAAoB;QAC5B,KAAK,EAAE,qDAAqD;QAC5D,OAAO,EAAE,MAAM;KAChB;IACD;QACE,MAAM,EAAE,iBAAiB;QACzB,KAAK,EAAE,qDAAqD;QAC5D,OAAO,EAAE,MAAM;KAChB;IACD;QACE,MAAM,EAAE,qCAAqC;QAC7C,KAAK,EAAE,0EAA0E;QACjF,OAAO,EAAE,MAAM;KAChB;IACD;QACE,0EAA0E;QAC1E,kEAAkE;QAClE,MAAM,EAAE,4BAA4B;QACpC,KAAK,EAAE,+FAA+F;QACtG,OAAO,EAAE,aAAa;KACvB;IACD;QACE,MAAM,EAAE,mBAAmB;QAC3B,KAAK,EAAE,0DAA0D;QACjE,OAAO,EAAE,aAAa;KACvB;CACF,CAAC;AAEF;;;;;;;;GAQG;AACH,MAAM,UAAU,aAAa,CAAC,MAAc;IAC1C,OAAO,QAAQ,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,MAAM,CAAC,QAAQ,CAAC,CAAC,CAAC,MAAM,CAAC,CAAC,IAAI,IAAI,CAAC;AACjE,CAAC"}

package/node_modules/checkride/dist/pm/tools.d.ts

@@ -0,0 +1,73 @@
+/**
+ * Slot-tool resolution — where a check's tool has to be for the gate to run it,
+ * and how to install it when it isn't.
+ *
+ * `translate.ts` decides *how* a tool is spawned; this decides *whether it may
+ * be*. The two are deliberately separate. `--no-install` bounds the download
+ * but not the launcher's per-user cache, so the spawn alone cannot promise the
+ * tool came from this repo: a copy an unrelated `npx` left behind months ago
+ * satisfies the launcher just as well as a declared dependency. Resolving the
+ * binary in the local tree first is what makes a slot's verdict depend on the
+ * committed lockfile rather than on one machine's accumulated cache — the
+ * property that lets a green run mean the same thing locally and in CI.
+ */
+import type { PackageManager } from './detect.js';
+/**
+ * The `<tool>` in a canonical `pnpm exec <tool> …` adapter invocation, or `null`
+ * for anything else — `pnpm audit`, `pnpm run <script>`, a built-in, or a config
+ * custom check's own command. Those either have no tool to resolve or resolve it
+ * themselves, so they are never pre-flighted.
+ *
+ * This is the same prefix test {@link translateExec} keys on, named once so the
+ * run path, the fix path and `doctor` cannot drift on what counts as a tool.
+ */
+export declare function execTool(command: string, args: readonly string[]): string | null;
+/** The command that would declare `tool` as a dev dependency under `pm`. */
+export declare function installCommand(pm: PackageManager, tool: string): string;
+/**
+ * Find `tool`'s binary in the local tree, walking `cwd` upward the way the
+ * package managers themselves do — and stopping at the repo root.
+ *
+ * The walk is what makes this correct in a workspace: pnpm and npm both hoist a
+ * shared tool's bin to the workspace root, so a check running in
+ * `packages/web` finds it two directories up and a root-only check finds it
+ * immediately. Checking `cwd` alone would report every hoisted tool missing in
+ * every monorepo — which is most of the repos with a workspace preset.
+ *
+ * The boundary matters as much as the walk. An unbounded search would accept a
+ * `node_modules/.bin/<tool>` sitting in some parent of the checkout — a stray
+ * install in a home or projects directory — and that is the same defect as
+ * trusting the launcher cache, reached by a different route: the slot passes for
+ * whoever happens to have that directory above their clone and fails on the
+ * clean checkout. Stopping at the root keeps the verdict a property of the repo.
+ * The root itself is searched before the walk ends; a tree with no marker at all
+ * (a synthetic one, or a directory outside any repo) walks to the filesystem
+ * root as before.
+ *
+ * `exists` is injected so the walk is testable against a synthetic tree.
+ */
+export declare function resolveSlotTool(cwd: string, tool: string, exists?: (p: string) => boolean): string | null;
+/**
+ * Whether this project is installed under Yarn PnP, where there is no
+ * `node_modules/` tree at all.
+ *
+ * Every path-based test for "is it installed" is wrong here: a healthy PnP repo
+ * has no `node_modules/` and no `node_modules/.bin/<tool>`, so asserting either
+ * reports a correctly installed project as broken. Callers use this to pick a
+ * different question — the install artifact rather than the directory, and the
+ * package manager's own resolution rather than a path — instead of guessing.
+ */
+export declare function isPnPInstall(cwd: string, exists?: (p: string) => boolean): boolean;
+/**
+ * Whether `pm`'s exec launcher can supply a tool this repo never declared.
+ *
+ * True for exactly the two launchers that keep a per-user package cache: `npx`
+ * and `bunx` will run a cached copy even under `--no-install`. `pnpm exec` and
+ * `yarn` resolve from the project tree only, so they already give the stronger
+ * guarantee and need no pre-flight — and Yarn PnP has no `node_modules/.bin`
+ * to resolve against at all, so pre-flighting it would report every tool
+ * missing. Kept in lockstep with `translate.ts`'s `EXEC` table by a test: any
+ * PM carrying `--no-install` must be listed here.
+ */
+export declare function execUsesGlobalCache(pm: PackageManager): boolean;
+//# sourceMappingURL=tools.d.ts.map

package/node_modules/checkride/dist/pm/tools.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"tools.d.ts","sourceRoot":"","sources":["../../src/pm/tools.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAKH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,aAAa,CAAC;AAGlD;;;;;;;;GAQG;AACH,wBAAgB,QAAQ,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,SAAS,MAAM,EAAE,GAAG,MAAM,GAAG,IAAI,CAGhF;AAaD,4EAA4E;AAC5E,wBAAgB,cAAc,CAAC,EAAE,EAAE,cAAc,EAAE,IAAI,EAAE,MAAM,GAAG,MAAM,CAEvE;AAcD;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,eAAe,CAAC,GAAG,EAAE,MAAM,EAAE,IAAI,EAAE,MAAM,EAAE,MAAM,GAAE,CAAC,CAAC,EAAE,MAAM,KAAK,OAAoB,GAAG,MAAM,GAAG,IAAI,CAUrH;AASD;;;;;;;;;GASG;AACH,wBAAgB,YAAY,CAAC,GAAG,EAAE,MAAM,EAAE,MAAM,GAAE,CAAC,CAAC,EAAE,MAAM,KAAK,OAAoB,GAAG,OAAO,CAE9F;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,mBAAmB,CAAC,EAAE,EAAE,cAAc,GAAG,OAAO,CAE/D"}

package/node_modules/checkride/dist/pm/tools.js

@@ -0,0 +1,124 @@
+/**
+ * Slot-tool resolution — where a check's tool has to be for the gate to run it,
+ * and how to install it when it isn't.
+ *
+ * `translate.ts` decides *how* a tool is spawned; this decides *whether it may
+ * be*. The two are deliberately separate. `--no-install` bounds the download
+ * but not the launcher's per-user cache, so the spawn alone cannot promise the
+ * tool came from this repo: a copy an unrelated `npx` left behind months ago
+ * satisfies the launcher just as well as a declared dependency. Resolving the
+ * binary in the local tree first is what makes a slot's verdict depend on the
+ * committed lockfile rather than on one machine's accumulated cache — the
+ * property that lets a green run mean the same thing locally and in CI.
+ */
+import { existsSync } from 'node:fs';
+import { dirname, join } from 'node:path';
+import { LOCKFILE_NAMES } from './detect.js';
+/**
+ * The `<tool>` in a canonical `pnpm exec <tool> …` adapter invocation, or `null`
+ * for anything else — `pnpm audit`, `pnpm run <script>`, a built-in, or a config
+ * custom check's own command. Those either have no tool to resolve or resolve it
+ * themselves, so they are never pre-flighted.
+ *
+ * This is the same prefix test {@link translateExec} keys on, named once so the
+ * run path, the fix path and `doctor` cannot drift on what counts as a tool.
+ */
+export function execTool(command, args) {
+    if (command !== 'pnpm' || args[0] !== 'exec')
+        return null;
+    return args[1] ?? null;
+}
+/**
+ * How each PM installs a tool as a dev dependency — the remediation a missing
+ * tool points at. `bun` spells the flag `-d`; the rest take `-D`.
+ */
+const INSTALL = {
+    pnpm: 'pnpm add -D',
+    npm: 'npm install -D',
+    yarn: 'yarn add -D',
+    bun: 'bun add -d',
+};
+/** The command that would declare `tool` as a dev dependency under `pm`. */
+export function installCommand(pm, tool) {
+    return `${INSTALL[pm]} ${tool}`;
+}
+/**
+ * What marks the top of a repository: its VCS directory, or a lockfile. `.git`
+ * is a file rather than a directory inside a worktree, which `existsSync`
+ * answers the same either way.
+ */
+const ROOT_MARKERS = ['.git', ...LOCKFILE_NAMES];
+/** Is `dir` the top of a repository — the last directory a tool search may look in? */
+function isRepoRoot(dir, exists) {
+    return ROOT_MARKERS.some((m) => exists(join(dir, m)));
+}
+/**
+ * Find `tool`'s binary in the local tree, walking `cwd` upward the way the
+ * package managers themselves do — and stopping at the repo root.
+ *
+ * The walk is what makes this correct in a workspace: pnpm and npm both hoist a
+ * shared tool's bin to the workspace root, so a check running in
+ * `packages/web` finds it two directories up and a root-only check finds it
+ * immediately. Checking `cwd` alone would report every hoisted tool missing in
+ * every monorepo — which is most of the repos with a workspace preset.
+ *
+ * The boundary matters as much as the walk. An unbounded search would accept a
+ * `node_modules/.bin/<tool>` sitting in some parent of the checkout — a stray
+ * install in a home or projects directory — and that is the same defect as
+ * trusting the launcher cache, reached by a different route: the slot passes for
+ * whoever happens to have that directory above their clone and fails on the
+ * clean checkout. Stopping at the root keeps the verdict a property of the repo.
+ * The root itself is searched before the walk ends; a tree with no marker at all
+ * (a synthetic one, or a directory outside any repo) walks to the filesystem
+ * root as before.
+ *
+ * `exists` is injected so the walk is testable against a synthetic tree.
+ */
+export function resolveSlotTool(cwd, tool, exists = existsSync) {
+    let dir = cwd;
+    for (;;) {
+        const bin = join(dir, 'node_modules', '.bin', tool);
+        if (exists(bin))
+            return bin;
+        if (isRepoRoot(dir, exists))
+            return null;
+        const parent = dirname(dir);
+        if (parent === dir)
+            return null;
+        dir = parent;
+    }
+}
+/**
+ * The artifacts a Yarn Plug'n'Play install writes in place of `node_modules/`.
+ * `.pnp.cjs` is the current name, `.pnp.js` the Yarn 2 one; `.pnp.data.json`
+ * rides alongside the loader when the manifest is split out.
+ */
+const PNP_FILES = ['.pnp.cjs', '.pnp.js', '.pnp.data.json'];
+/**
+ * Whether this project is installed under Yarn PnP, where there is no
+ * `node_modules/` tree at all.
+ *
+ * Every path-based test for "is it installed" is wrong here: a healthy PnP repo
+ * has no `node_modules/` and no `node_modules/.bin/<tool>`, so asserting either
+ * reports a correctly installed project as broken. Callers use this to pick a
+ * different question — the install artifact rather than the directory, and the
+ * package manager's own resolution rather than a path — instead of guessing.
+ */
+export function isPnPInstall(cwd, exists = existsSync) {
+    return PNP_FILES.some((f) => exists(join(cwd, f)));
+}
+/**
+ * Whether `pm`'s exec launcher can supply a tool this repo never declared.
+ *
+ * True for exactly the two launchers that keep a per-user package cache: `npx`
+ * and `bunx` will run a cached copy even under `--no-install`. `pnpm exec` and
+ * `yarn` resolve from the project tree only, so they already give the stronger
+ * guarantee and need no pre-flight — and Yarn PnP has no `node_modules/.bin`
+ * to resolve against at all, so pre-flighting it would report every tool
+ * missing. Kept in lockstep with `translate.ts`'s `EXEC` table by a test: any
+ * PM carrying `--no-install` must be listed here.
+ */
+export function execUsesGlobalCache(pm) {
+    return pm === 'npm' || pm === 'bun';
+}
+//# sourceMappingURL=tools.js.map

package/node_modules/checkride/dist/pm/tools.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"tools.js","sourceRoot":"","sources":["../../src/pm/tools.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;GAYG;AAEH,OAAO,EAAE,UAAU,EAAE,MAAM,SAAS,CAAC;AACrC,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAG1C,OAAO,EAAE,cAAc,EAAE,MAAM,aAAa,CAAC;AAE7C;;;;;;;;GAQG;AACH,MAAM,UAAU,QAAQ,CAAC,OAAe,EAAE,IAAuB;IAC/D,IAAI,OAAO,KAAK,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM;QAAE,OAAO,IAAI,CAAC;IAC1D,OAAO,IAAI,CAAC,CAAC,CAAC,IAAI,IAAI,CAAC;AACzB,CAAC;AAED;;;GAGG;AACH,MAAM,OAAO,GAAmC;IAC9C,IAAI,EAAE,aAAa;IACnB,GAAG,EAAE,gBAAgB;IACrB,IAAI,EAAE,aAAa;IACnB,GAAG,EAAE,YAAY;CAClB,CAAC;AAEF,4EAA4E;AAC5E,MAAM,UAAU,cAAc,CAAC,EAAkB,EAAE,IAAY;IAC7D,OAAO,GAAG,OAAO,CAAC,EAAE,CAAC,IAAI,IAAI,EAAE,CAAC;AAClC,CAAC;AAED;;;;GAIG;AACH,MAAM,YAAY,GAAsB,CAAC,MAAM,EAAE,GAAG,cAAc,CAAC,CAAC;AAEpE,uFAAuF;AACvF,SAAS,UAAU,CAAC,GAAW,EAAE,MAA8B;IAC7D,OAAO,YAAY,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC;AACxD,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,MAAM,UAAU,eAAe,CAAC,GAAW,EAAE,IAAY,EAAE,SAAiC,UAAU;IACpG,IAAI,GAAG,GAAG,GAAG,CAAC;IACd,SAAS,CAAC;QACR,MAAM,GAAG,GAAG,IAAI,CAAC,GAAG,EAAE,cAAc,EAAE,MAAM,EAAE,IAAI,CAAC,CAAC;QACpD,IAAI,MAAM,CAAC,GAAG,CAAC;YAAE,OAAO,GAAG,CAAC;QAC5B,IAAI,UAAU,CAAC,GAAG,EAAE,MAAM,CAAC;YAAE,OAAO,IAAI,CAAC;QACzC,MAAM,MAAM,GAAG,OAAO,CAAC,GAAG,CAAC,CAAC;QAC5B,IAAI,MAAM,KAAK,GAAG;YAAE,OAAO,IAAI,CAAC;QAChC,GAAG,GAAG,MAAM,CAAC;IACf,CAAC;AACH,CAAC;AAED;;;;GAIG;AACH,MAAM,SAAS,GAAG,CAAC,UAAU,EAAE,SAAS,EAAE,gBAAgB,CAAU,CAAC;AAErE;;;;;;;;;GASG;AACH,MAAM,UAAU,YAAY,CAAC,GAAW,EAAE,SAAiC,UAAU;IACnF,OAAO,SAAS,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,EAAE,CAAC,CAAC,CAAC,CAAC,CAAC;AACrD,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,mBAAmB,CAAC,EAAkB;IACpD,OAAO,EAAE,KAAK,KAAK,IAAI,EAAE,KAAK,KAAK,CAAC;AACtC,CAAC"}

package/node_modules/checkride/dist/pm/translate.d.ts

@@ -2,11 +2,11 @@
  * Exec-prefix translation.
  *
  * The adapter registry keeps its canonical `pnpm exec <tool>` / `pnpm run
- * <script>` form (D5/D13); this is the single seam that rewrites that prefix for
+ * <script>` form; this is the single seam that rewrites that prefix for
  * whichever package manager a repo actually uses. Only the `pnpm exec` and `pnpm
  * run` prefixes are translated — `pnpm audit`, custom-check commands, and
- * built-ins pass through untouched, so the default pnpm run is byte-identical to
- * before.
+ * built-ins pass through untouched. Under pnpm itself the prefix is unchanged
+ * and only {@link VERIFY_DEPS_OFF} is prepended.
  */
 import type { PackageManager } from './detect.js';
 /**
@@ -15,21 +15,47 @@ import type { PackageManager } from './detect.js';
  * check's own command, a built-in) is returned unchanged, and so is every
  * invocation under `pnpm` itself — the default stays exactly as it was.
  *
- * `exec` swaps the launcher and drops the keyword (`pnpm exec oxlint` → `npx
- * oxlint`); `run` keeps its keyword and only swaps the launcher, since all four
- * package managers spell it `<pm> run <script>` (`pnpm run build` → `npm run
- * build`).
+ * `exec` swaps the launcher, drops the keyword, and prepends the launcher's own
+ * flags (`pnpm exec oxlint` → `npx --no-install oxlint`); `run` keeps its
+ * keyword and only swaps the launcher, since all four package managers spell it
+ * `<pm> run <script>` (`pnpm run build` → `npm run build`). Under pnpm the
+ * invocation is unchanged but for `VERIFY_DEPS_OFF`, which keeps pnpm's
+ * dependency-check narration off the tool's stdout.
  */
 export declare function translateExec(command: string, args: readonly string[], pm: PackageManager): {
     command: string;
     args: string[];
 };
+/**
+ * How `pm` invokes a package.json script, as a command line.
+ *
+ * Bare `pnpm <script>` is pnpm's own shorthand and the form checkride's docs
+ * use; the other three need the `run` keyword, and not merely for tidiness —
+ * `npm check` is not a command at all, and `yarn check` resolves to Yarn 1's
+ * built-in integrity checker rather than the repo's script, so both fail in a
+ * way that looks like checkride is broken. `<pm> run <script>` is correct
+ * everywhere, which is why it is the fallback for all of them.
+ */
+export declare function runScript(pm: PackageManager, script: string): string;
+/**
+ * A canonical `pnpm exec <tool> …` rendered as one command line for `pm`.
+ *
+ * `quiet` decides whether {@link VERIFY_DEPS_OFF} survives into the rendered
+ * string, and the two callers want opposite answers. A generated script whose
+ * stdout checkride parses needs it, or pnpm's narration lands in front of the
+ * JSON. Prose — the AGENTS.md stanza, a doc — does not: nothing parses that
+ * output, and a documented command carrying
+ * `--config.verify-deps-before-run=false` is a line nobody wants to retype.
+ */
+export declare function execCommand(pm: PackageManager, args: readonly string[], opts?: {
+    quiet?: boolean;
+}): string;
 /**
  * Can this adapter run under `pm`? Audit is package-manager-specific — its
  * flags and JSON shape don't port — so `pnpm audit` (the `security` slot) is
- * unavailable on a non-pnpm PM until a per-PM audit adapter lands (b5). The
+ * unavailable on a non-pnpm PM until a per-PM audit adapter lands. The
  * `pack` slot's built-in speaks only npm's and pnpm's `pack --dry-run --json`
- * (yarn/bun pack differently) — unavailable-until-adapter, same precedent (D10).
+ * (yarn/bun pack differently) — unavailable-until-adapter, same precedent.
  * Everything else is PM-agnostic once its exec prefix is translated.
  */
 export declare function isAvailableUnder(command: string, args: readonly string[], pm: PackageManager): boolean;

package/node_modules/checkride/dist/pm/translate.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"translate.d.ts","sourceRoot":"","sources":["../../src/pm/translate.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,aAAa,CAAC;AASlD;;;;;;;;;;GAUG;AACH,wBAAgB,aAAa,CAC3B,OAAO,EAAE,MAAM,EACf,IAAI,EAAE,SAAS,MAAM,EAAE,EACvB,EAAE,EAAE,cAAc,GACjB;IAAE,OAAO,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,EAAE,CAAA;CAAE,CAOrC;AAED;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,SAAS,MAAM,EAAE,EAAE,EAAE,EAAE,cAAc,GAAG,OAAO,CAItG"}
+{"version":3,"file":"translate.d.ts","sourceRoot":"","sources":["../../src/pm/translate.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,aAAa,CAAC;AA6BlD;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAC3B,OAAO,EAAE,MAAM,EACf,IAAI,EAAE,SAAS,MAAM,EAAE,EACvB,EAAE,EAAE,cAAc,GACjB;IAAE,OAAO,EAAE,MAAM,CAAC;IAAC,IAAI,EAAE,MAAM,EAAE,CAAA;CAAE,CAQrC;AAED;;;;;;;;;GASG;AACH,wBAAgB,SAAS,CAAC,EAAE,EAAE,cAAc,EAAE,MAAM,EAAE,MAAM,GAAG,MAAM,CAEpE;AAED;;;;;;;;;GASG;AACH,wBAAgB,WAAW,CAAC,EAAE,EAAE,cAAc,EAAE,IAAI,EAAE,SAAS,MAAM,EAAE,EAAE,IAAI,GAAE;IAAE,KAAK,CAAC,EAAE,OAAO,CAAA;CAAO,GAAG,MAAM,CAI/G;AAYD;;;;;;;GAOG;AACH,wBAAgB,gBAAgB,CAAC,OAAO,EAAE,MAAM,EAAE,IAAI,EAAE,SAAS,MAAM,EAAE,EAAE,EAAE,EAAE,cAAc,GAAG,OAAO,CAItG"}

package/node_modules/checkride/dist/pm/translate.js

@@ -2,46 +2,106 @@
  * Exec-prefix translation.
  *
  * The adapter registry keeps its canonical `pnpm exec <tool>` / `pnpm run
- * <script>` form (D5/D13); this is the single seam that rewrites that prefix for
+ * <script>` form; this is the single seam that rewrites that prefix for
  * whichever package manager a repo actually uses. Only the `pnpm exec` and `pnpm
  * run` prefixes are translated — `pnpm audit`, custom-check commands, and
- * built-ins pass through untouched, so the default pnpm run is byte-identical to
- * before.
- */
-/** The exec command each non-pnpm PM uses in place of `pnpm exec`. */
-const EXEC_COMMAND = {
-    npm: 'npx',
-    yarn: 'yarn',
-    bun: 'bunx',
+ * built-ins pass through untouched. Under pnpm itself the prefix is unchanged
+ * and only {@link VERIFY_DEPS_OFF} is prepended.
+ */
+/**
+ * What each non-pnpm PM uses in place of `pnpm exec`, and the flags that ride
+ * along. `--no-install` is load-bearing: `npx` and `bunx` otherwise fetch a
+ * missing tool from the registry and run it, and a check has no TTY to be
+ * prompted through — so the gate would silently execute an unpinned `latest`.
+ * It bounds the download, not every fallback: a copy already in the launcher's
+ * global cache still runs (see `docs/tools.md` §Package managers). `yarn`
+ * neither auto-installs nor accepts the flag.
+ */
+const EXEC = {
+    npm: { command: 'npx', flags: ['--no-install'] },
+    yarn: { command: 'yarn', flags: [] },
+    bun: { command: 'bunx', flags: ['--no-install'] },
 };
+/**
+ * Keeps pnpm's dependency-check narration (`Already up to date`) off **stdout**,
+ * where it would land in front of a tool's JSON and make it unparseable.
+ *
+ * This exact spelling, in this position, is the only form that works — not
+ * `--silent`, not the environment variable, and not after `exec`. Applied to
+ * every supported pnpm rather than version-gated. The full account, including
+ * the failure that found it, is in `docs/tools.md` §Launcher quirks; read it
+ * before touching this line.
+ */
+const VERIFY_DEPS_OFF = '--config.verify-deps-before-run=false';
 /**
  * Rewrite a canonical `pnpm exec <tool> …` or `pnpm run <script>` invocation for
  * `pm`. Anything that is not one of those prefixes (a `pnpm audit`, a custom
  * check's own command, a built-in) is returned unchanged, and so is every
  * invocation under `pnpm` itself — the default stays exactly as it was.
  *
- * `exec` swaps the launcher and drops the keyword (`pnpm exec oxlint` → `npx
- * oxlint`); `run` keeps its keyword and only swaps the launcher, since all four
- * package managers spell it `<pm> run <script>` (`pnpm run build` → `npm run
- * build`).
+ * `exec` swaps the launcher, drops the keyword, and prepends the launcher's own
+ * flags (`pnpm exec oxlint` → `npx --no-install oxlint`); `run` keeps its
+ * keyword and only swaps the launcher, since all four package managers spell it
+ * `<pm> run <script>` (`pnpm run build` → `npm run build`). Under pnpm the
+ * invocation is unchanged but for `VERIFY_DEPS_OFF`, which keeps pnpm's
+ * dependency-check narration off the tool's stdout.
  */
 export function translateExec(command, args, pm) {
-    if (command !== 'pnpm' || pm === 'pnpm')
+    if (command !== 'pnpm')
         return { command, args: [...args] };
-    // Drop 'exec'; keep <tool> and its arguments, e.g. `npx oxlint --type-aware`.
+    if (pm === 'pnpm')
+        return { command, args: quieted(args) };
+    // Drop 'exec'; keep <tool> and its arguments, for example `npx --no-install oxlint --type-aware`.
     if (args[0] === 'exec')
-        return { command: EXEC_COMMAND[pm], args: args.slice(1) };
+        return { command: EXEC[pm].command, args: [...EXEC[pm].flags, ...args.slice(1)] };
     // `<pm> run <script>` is universal; only the launcher changes.
     if (args[0] === 'run')
         return { command: pm, args: [...args] };
     return { command, args: [...args] };
 }
+/**
+ * How `pm` invokes a package.json script, as a command line.
+ *
+ * Bare `pnpm <script>` is pnpm's own shorthand and the form checkride's docs
+ * use; the other three need the `run` keyword, and not merely for tidiness —
+ * `npm check` is not a command at all, and `yarn check` resolves to Yarn 1's
+ * built-in integrity checker rather than the repo's script, so both fail in a
+ * way that looks like checkride is broken. `<pm> run <script>` is correct
+ * everywhere, which is why it is the fallback for all of them.
+ */
+export function runScript(pm, script) {
+    return pm === 'pnpm' ? `${pm} ${script}` : `${pm} run ${script}`;
+}
+/**
+ * A canonical `pnpm exec <tool> …` rendered as one command line for `pm`.
+ *
+ * `quiet` decides whether {@link VERIFY_DEPS_OFF} survives into the rendered
+ * string, and the two callers want opposite answers. A generated script whose
+ * stdout checkride parses needs it, or pnpm's narration lands in front of the
+ * JSON. Prose — the AGENTS.md stanza, a doc — does not: nothing parses that
+ * output, and a documented command carrying
+ * `--config.verify-deps-before-run=false` is a line nobody wants to retype.
+ */
+export function execCommand(pm, args, opts = {}) {
+    const translated = translateExec('pnpm', ['exec', ...args], pm);
+    const rest = opts.quiet === true ? translated.args : translated.args.filter((a) => a !== VERIFY_DEPS_OFF);
+    return [translated.command, ...rest].join(' ');
+}
+/**
+ * Prepend `VERIFY_DEPS_OFF` to the two pnpm subcommands that verify first.
+ * `pnpm audit` and `pnpm pack` never do, so they are left exactly as written —
+ * the flag is added where it changes something, not everywhere it is harmless.
+ */
+function quieted(args) {
+    const verifies = args[0] === 'exec' || args[0] === 'run';
+    return verifies ? [VERIFY_DEPS_OFF, ...args] : [...args];
+}
 /**
  * Can this adapter run under `pm`? Audit is package-manager-specific — its
  * flags and JSON shape don't port — so `pnpm audit` (the `security` slot) is
- * unavailable on a non-pnpm PM until a per-PM audit adapter lands (b5). The
+ * unavailable on a non-pnpm PM until a per-PM audit adapter lands. The
  * `pack` slot's built-in speaks only npm's and pnpm's `pack --dry-run --json`
- * (yarn/bun pack differently) — unavailable-until-adapter, same precedent (D10).
+ * (yarn/bun pack differently) — unavailable-until-adapter, same precedent.
  * Everything else is PM-agnostic once its exec prefix is translated.
  */
 export function isAvailableUnder(command, args, pm) {

package/node_modules/checkride/dist/pm/translate.js.map

@@ -1 +1 @@
-{"version":3,"file":"translate.js","sourceRoot":"","sources":["../../src/pm/translate.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAIH,sEAAsE;AACtE,MAAM,YAAY,GAAoD;IACpE,GAAG,EAAE,KAAK;IACV,IAAI,EAAE,MAAM;IACZ,GAAG,EAAE,MAAM;CACZ,CAAC;AAEF;;;;;;;;;;GAUG;AACH,MAAM,UAAU,aAAa,CAC3B,OAAe,EACf,IAAuB,EACvB,EAAkB;IAElB,IAAI,OAAO,KAAK,MAAM,IAAI,EAAE,KAAK,MAAM;QAAE,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC,GAAG,IAAI,CAAC,EAAE,CAAC;IAC7E,8EAA8E;IAC9E,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM;QAAE,OAAO,EAAE,OAAO,EAAE,YAAY,CAAC,EAAE,CAAC,EAAE,IAAI,EAAE,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,EAAE,CAAC;IAClF,+DAA+D;IAC/D,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,KAAK;QAAE,OAAO,EAAE,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,CAAC,GAAG,IAAI,CAAC,EAAE,CAAC;IAC/D,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC,GAAG,IAAI,CAAC,EAAE,CAAC;AACtC,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,gBAAgB,CAAC,OAAe,EAAE,IAAuB,EAAE,EAAkB;IAC3F,IAAI,OAAO,KAAK,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,OAAO;QAAE,OAAO,EAAE,KAAK,MAAM,CAAC;IACpE,IAAI,OAAO,KAAK,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM;QAAE,OAAO,EAAE,KAAK,MAAM,IAAI,EAAE,KAAK,KAAK,CAAC;IACnF,OAAO,IAAI,CAAC;AACd,CAAC"}
+{"version":3,"file":"translate.js","sourceRoot":"","sources":["../../src/pm/translate.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAIH;;;;;;;;GAQG;AACH,MAAM,IAAI,GAA2F;IACnG,GAAG,EAAE,EAAE,OAAO,EAAE,KAAK,EAAE,KAAK,EAAE,CAAC,cAAc,CAAC,EAAE;IAChD,IAAI,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,KAAK,EAAE,EAAE,EAAE;IACpC,GAAG,EAAE,EAAE,OAAO,EAAE,MAAM,EAAE,KAAK,EAAE,CAAC,cAAc,CAAC,EAAE;CAClD,CAAC;AAEF;;;;;;;;;GASG;AACH,MAAM,eAAe,GAAG,uCAAuC,CAAC;AAEhE;;;;;;;;;;;;GAYG;AACH,MAAM,UAAU,aAAa,CAC3B,OAAe,EACf,IAAuB,EACvB,EAAkB;IAElB,IAAI,OAAO,KAAK,MAAM;QAAE,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC,GAAG,IAAI,CAAC,EAAE,CAAC;IAC5D,IAAI,EAAE,KAAK,MAAM;QAAE,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,OAAO,CAAC,IAAI,CAAC,EAAE,CAAC;IAC3D,kGAAkG;IAClG,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM;QAAE,OAAO,EAAE,OAAO,EAAE,IAAI,CAAC,EAAE,CAAC,CAAC,OAAO,EAAE,IAAI,EAAE,CAAC,GAAG,IAAI,CAAC,EAAE,CAAC,CAAC,KAAK,EAAE,GAAG,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;IAC1G,+DAA+D;IAC/D,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,KAAK;QAAE,OAAO,EAAE,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,CAAC,GAAG,IAAI,CAAC,EAAE,CAAC;IAC/D,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC,GAAG,IAAI,CAAC,EAAE,CAAC;AACtC,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,UAAU,SAAS,CAAC,EAAkB,EAAE,MAAc;IAC1D,OAAO,EAAE,KAAK,MAAM,CAAC,CAAC,CAAC,GAAG,EAAE,IAAI,MAAM,EAAE,CAAC,CAAC,CAAC,GAAG,EAAE,QAAQ,MAAM,EAAE,CAAC;AACnE,CAAC;AAED;;;;;;;;;GASG;AACH,MAAM,UAAU,WAAW,CAAC,EAAkB,EAAE,IAAuB,EAAE,OAA4B,EAAE;IACrG,MAAM,UAAU,GAAG,aAAa,CAAC,MAAM,EAAE,CAAC,MAAM,EAAE,GAAG,IAAI,CAAC,EAAE,EAAE,CAAC,CAAC;IAChE,MAAM,IAAI,GAAG,IAAI,CAAC,KAAK,KAAK,IAAI,CAAC,CAAC,CAAC,UAAU,CAAC,IAAI,CAAC,CAAC,CAAC,UAAU,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,KAAK,eAAe,CAAC,CAAC;IAC1G,OAAO,CAAC,UAAU,CAAC,OAAO,EAAE,GAAG,IAAI,CAAC,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AACjD,CAAC;AAED;;;;GAIG;AACH,SAAS,OAAO,CAAC,IAAuB;IACtC,MAAM,QAAQ,GAAG,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,KAAK,CAAC;IACzD,OAAO,QAAQ,CAAC,CAAC,CAAC,CAAC,eAAe,EAAE,GAAG,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,GAAG,IAAI,CAAC,CAAC;AAC3D,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,gBAAgB,CAAC,OAAe,EAAE,IAAuB,EAAE,EAAkB;IAC3F,IAAI,OAAO,KAAK,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,OAAO;QAAE,OAAO,EAAE,KAAK,MAAM,CAAC;IACpE,IAAI,OAAO,KAAK,MAAM,IAAI,IAAI,CAAC,CAAC,CAAC,KAAK,MAAM;QAAE,OAAO,EAAE,KAAK,MAAM,IAAI,EAAE,KAAK,KAAK,CAAC;IACnF,OAAO,IAAI,CAAC;AACd,CAAC"}

package/node_modules/checkride/dist/proc.d.ts

@@ -0,0 +1,30 @@
+/**
+ * Killing a spawned check, and everything it started.
+ *
+ * Every subprocess checkride spawns is `detached`, so it leads its own process
+ * group and a negated-pid signal reaches the whole tree — a wrapper's
+ * grandchildren included. That is the difference between a timed-out
+ * `sh -c 'slow-tool …'` leaving its real worker orphaned and alive, and taking
+ * the tree down with it.
+ *
+ * Both spawners need the same two-step escalation (SIGTERM, then SIGKILL after
+ * a grace), so it lives here rather than in either of them: the orchestrator's
+ * per-check timeout and fatal-signal reaping (`../orchestrator.ts`), and the
+ * triage reader's gate budget (`./triage/env.ts`).
+ */
+/** Grace between SIGTERM and SIGKILL when a process group won't die politely. */
+export declare const KILL_GRACE_SECONDS = 5;
+/**
+ * Signal a spawned process's whole group. ESRCH is swallowed: the group racing
+ * to exit on its own before we signal is success, not an error (and `pid` is
+ * absent only when the spawn itself failed).
+ */
+export declare function killGroup(pid: number | undefined, signal: NodeJS.Signals): void;
+/**
+ * Ask a process group to stop, then insist. SIGTERM now; SIGKILL after
+ * {@link KILL_GRACE_SECONDS} if it is still there. Returns the escalation
+ * timer so the caller can clear it when the process closes first — a pending
+ * timer would otherwise hold the event loop open past the run.
+ */
+export declare function killGroupEscalating(pid: number | undefined): ReturnType<typeof setTimeout>;
+//# sourceMappingURL=proc.d.ts.map

package/node_modules/checkride/dist/proc.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"proc.d.ts","sourceRoot":"","sources":["../src/proc.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,iFAAiF;AACjF,eAAO,MAAM,kBAAkB,IAAI,CAAC;AAEpC;;;;GAIG;AACH,wBAAgB,SAAS,CAAC,GAAG,EAAE,MAAM,GAAG,SAAS,EAAE,MAAM,EAAE,MAAM,CAAC,OAAO,GAAG,IAAI,CAO/E;AAED;;;;;GAKG;AACH,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,MAAM,GAAG,SAAS,GAAG,UAAU,CAAC,OAAO,UAAU,CAAC,CAG1F"}

package/node_modules/checkride/dist/proc.js

@@ -0,0 +1,42 @@
+/**
+ * Killing a spawned check, and everything it started.
+ *
+ * Every subprocess checkride spawns is `detached`, so it leads its own process
+ * group and a negated-pid signal reaches the whole tree — a wrapper's
+ * grandchildren included. That is the difference between a timed-out
+ * `sh -c 'slow-tool …'` leaving its real worker orphaned and alive, and taking
+ * the tree down with it.
+ *
+ * Both spawners need the same two-step escalation (SIGTERM, then SIGKILL after
+ * a grace), so it lives here rather than in either of them: the orchestrator's
+ * per-check timeout and fatal-signal reaping (`../orchestrator.ts`), and the
+ * triage reader's gate budget (`./triage/env.ts`).
+ */
+/** Grace between SIGTERM and SIGKILL when a process group won't die politely. */
+export const KILL_GRACE_SECONDS = 5;
+/**
+ * Signal a spawned process's whole group. ESRCH is swallowed: the group racing
+ * to exit on its own before we signal is success, not an error (and `pid` is
+ * absent only when the spawn itself failed).
+ */
+export function killGroup(pid, signal) {
+    if (pid === undefined)
+        return;
+    try {
+        process.kill(-pid, signal);
+    }
+    catch {
+        // Group already gone (raced with a clean exit) — nothing left to kill.
+    }
+}
+/**
+ * Ask a process group to stop, then insist. SIGTERM now; SIGKILL after
+ * {@link KILL_GRACE_SECONDS} if it is still there. Returns the escalation
+ * timer so the caller can clear it when the process closes first — a pending
+ * timer would otherwise hold the event loop open past the run.
+ */
+export function killGroupEscalating(pid) {
+    killGroup(pid, 'SIGTERM');
+    return setTimeout(() => { killGroup(pid, 'SIGKILL'); }, KILL_GRACE_SECONDS * 1000);
+}
+//# sourceMappingURL=proc.js.map

package/node_modules/checkride/dist/proc.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"proc.js","sourceRoot":"","sources":["../src/proc.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;GAaG;AAEH,iFAAiF;AACjF,MAAM,CAAC,MAAM,kBAAkB,GAAG,CAAC,CAAC;AAEpC;;;;GAIG;AACH,MAAM,UAAU,SAAS,CAAC,GAAuB,EAAE,MAAsB;IACvE,IAAI,GAAG,KAAK,SAAS;QAAE,OAAO;IAC9B,IAAI,CAAC;QACH,OAAO,CAAC,IAAI,CAAC,CAAC,GAAG,EAAE,MAAM,CAAC,CAAC;IAC7B,CAAC;IAAC,MAAM,CAAC;QACP,uEAAuE;IACzE,CAAC;AACH,CAAC;AAED;;;;;GAKG;AACH,MAAM,UAAU,mBAAmB,CAAC,GAAuB;IACzD,SAAS,CAAC,GAAG,EAAE,SAAS,CAAC,CAAC;IAC1B,OAAO,UAAU,CAAC,GAAG,EAAE,GAAG,SAAS,CAAC,GAAG,EAAE,SAAS,CAAC,CAAC,CAAC,CAAC,EAAE,kBAAkB,GAAG,IAAI,CAAC,CAAC;AACrF,CAAC"}

package/node_modules/checkride/dist/qa/cli.d.ts

@@ -0,0 +1,20 @@
+#!/usr/bin/env node
+/**
+ * Executable form of the quality reader — what the bundled `/checkride:qa`
+ * skill invokes:
+ *
+ * ```
+ * node <plugin-root>/dist/qa/cli.js [cwd]
+ * ```
+ *
+ * It ships in the package's existing `dist/`, so both the published tarball and
+ * an installed plugin cache already carry it and no consumer build step exists.
+ * It adds no CLI command, flag or config to checkride itself: `dist/cli.js`
+ * knows nothing about this file.
+ *
+ * Exit code 0 means *a report was rendered* — including one whose every
+ * artifact is missing, which is a legitimate answer about a repo and not a
+ * reader failure. Unlike the triage reader, this one spawns nothing at all.
+ */
+export {};
+//# sourceMappingURL=cli.d.ts.map

package/node_modules/checkride/dist/qa/cli.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../../src/qa/cli.ts"],"names":[],"mappings":";AACA;;;;;;;;;;;;;;;;GAgBG"}