@taskless/cli 0.11.0 → 0.11.1

package/dist/rules/ast-grep-binary.d.ts

@@ -0,0 +1,26 @@
+import type { PlatformBinarySpec } from "./platform-binary";
+/**
+ * ast-grep's per-platform packaging, as the shared resolver understands it.
+ *
+ * `toolchainSuffix: true` is what produces `@ast-grep/cli-linux-x64-gnu` and
+ * `-win32-x64-msvc`. The Vale packages set it false; see
+ * {@link PlatformBinarySpec} for why that distinction is load-bearing.
+ *
+ * Both `ast-grep` and `sg` are listed because the wrapper declares them as bin
+ * entries for the same target, so either may be what got linked. `ast-grep`
+ * leads because it is the name the platform package ships the binary under; the
+ * resolver reverses the list at the link-based tiers, so `sg` is still tried
+ * first there and named in the PATH advice, as it was before the shared
+ * resolver existed.
+ *
+ * ## Why this sits in its own module rather than in `scan.ts`
+ *
+ * The spec is data: five fields describing how a package is named and how the
+ * binary identifies itself. `scan.ts` is the scanner — it reaches
+ * `rules/engines.ts`, and through it `node:fs/promises` and the CLI's error
+ * type. `@taskless/cli/node/runtimes` publishes this spec so a consumer can
+ * resolve the same binary the CLI executes, and a consumer that wants a path
+ * has no business loading a scanner to get one. Vale's spec is already a leaf
+ * for the same reason: `rules/vale/binary.ts` imports nothing but the resolver.
+ */
+export declare const AST_GREP_BINARY: PlatformBinarySpec;

package/dist/rules/capabilities.d.ts

@@ -123,13 +123,21 @@ export declare function resolveAstGrepLanguage(spelling: string): AstGrepLanguag
 export declare const AST_GREP_TSX_SPLIT: Readonly<Partial<Record<AstGrepLanguage, string>>>;
 /**
  * The Vale release carried by the `@taskless/vale-<platform>` packages pinned
- * in `packages/cli/package.json`. Their npm versions append a build stamp
- * (`3.17.1-20260810052605`); this is the version Vale itself reports.
+ * in `packages/cli/package.json`. Their npm versions append a build stamp,
+ * `<valeVersion>-<yyyymmddhhmmss>`, minted per publish by
+ * `.github/workflows/release-vale.yml`; this is the version Vale itself
+ * reports.
+ *
+ * The SHAPE rather than an example, deliberately. A literal stamp here has to
+ * be hand-carried on every bump, and it has gone one release out of date twice
+ * now, which is worse than no example: it reads as the current pin and is not
+ * one. The real value lives in `packages/cli/package.json`, where a reader can
+ * see all six at once and cannot be told a stale one.
  *
  * Pinned against the binary by `test/vale-vendor-contract.test.ts`
  * ("engine capabilities" → "reports the pinned version").
  */
-export declare const VALE_VERSION = "3.18.0";
+export declare const VALE_VERSION = "3.20.0";
 /**
  * Which tier Vale routes an extension to.
  *
@@ -186,9 +194,41 @@ export type ValeFormatTier =
  * plain text today, but the moment Vale routes it to a converter the same
  * omission is a crash that takes down every Vale rule in the run.
  *
- * The 3.17.1 → 3.18.0 bump is what that warning looks like in practice. Every
- * row below was re-probed against the 3.18.0 binary, and eight moved, in three
- * different directions — which is why "re-measure" is not boilerplate here:
+ * NOTHING MOVED ACROSS 3.19.0 → 3.20.0, AND THE SECOND HALF OF THAT CLAIM IS
+ * THE ONE THAT COST SOMETHING. Every row below was re-probed against the
+ * 3.20.0 binary and none of them moved, which this table can report. It cannot
+ * report a format Vale *learned*, so that direction was checked at the source
+ * instead: the v3.19.0...v3.20.0 tree adds no `internal/lint/<format>.go` and
+ * no `internal/lint/code/<lang>.go`, and every existing one of those files
+ * changes by a single import line from the org rename. No format was learned,
+ * so there is no new row to add. Do that check on the next bump too — a green
+ * table is silence about the dangerous direction, not evidence against it.
+ *
+ * THE TABLE ALSO HELD ACROSS 3.18.0 → 3.19.0, AND THAT IS NOT THE SAME AS THE
+ * BUMP BEING FREE. Every row below was re-probed against the 3.19.0 binary and
+ * not one of them moved. What moved was a format Vale *learned*, which is
+ * precisely the case a table of existing rows cannot report: `.ex` and `.exs`
+ * gained comment and doc-attribute extraction, so they left the unnamed
+ * plaintext fallback for the `comment` tier and are new rows below.
+ *
+ * Read that direction carefully, because it is a narrowing rather than a gain.
+ * On 3.18.0 an Elixir file was linted as one block of prose, so a rule matching
+ * `[*.ex]` fired on identifiers and string literals as readily as on comments.
+ * On 3.19.0 the code body is invisible and only comments and `@doc` attributes
+ * are read. Findings disappear, no error is raised, and nothing but a re-probe
+ * would have told us. A format Vale learns is never a no-op: the benign version
+ * of it is this one, and the dangerous version is a converter (see `.typ`).
+ *
+ * `.mdx` stayed `markup` and changed underneath the tier: a JSX element's
+ * children are now read as the Markdown they are, so a Vale rule covers prose
+ * inside `<Steps>` or `<Aside>` that it previously skipped, and those children
+ * carry the element name as a `text.class.<name>` scope. The tier is the wrong
+ * instrument for that kind of change — it says a parser exists, not what the
+ * parser sees — which is the second reason a bump needs more than this table.
+ *
+ * The 3.17.1 → 3.18.0 bump is what the dangerous case looks like in practice.
+ * Every row was re-probed against the 3.18.0 binary then too, and eight moved,
+ * in three different directions — which is why "re-measure" is not boilerplate:
  *
  * - `.mdx` gained a native parser: `converter:mdx2vast` → `markup`. It is
  *   supported now, and `[*.{md,mdx}]` is a legitimate matcher again.

package/dist/rules/constraints.d.ts

@@ -0,0 +1,132 @@
+import type { EngineName } from "./layout";
+/**
+ * What `verify` enforces beyond the engine's own schema.
+ *
+ * ## Why this exists
+ *
+ * A rule the engine executes correctly can still be refused. Those refusals are
+ * deliberate, but they are OURS, and a generator that never reads our recipes
+ * cannot know them. Published in the conformance corpus so an external eval can
+ * tell "your rule is wrong about the subject" from "your rule broke a house
+ * rule it was never told about" — two findings that want completely different
+ * responses.
+ *
+ * ## Why every entry has a test that triggers it
+ *
+ * A hand-maintained list of what code does goes stale, and this is not
+ * hypothetical: `create-sg-rule.md` told agents for months that
+ * "`verify` never reads `language`", which stopped being true when
+ * `validateLanguage` landed. Nothing failed, because prose has no test.
+ *
+ * `test/constraints.test.ts` builds a rule that violates each entry and
+ * asserts `verify` rejects it, keyed on `id`. An entry describing a check that
+ * no longer fires fails the suite; a check with no entry is invisible to that
+ * test and is the gap this list is trying to close, so add one when you add a
+ * check.
+ */
+export interface RuleConstraint {
+    /** Stable key. Consumers branch on this; renaming is breaking. */
+    id: string;
+    engine: EngineName;
+    /**
+     * Which command refuses the rule.
+     *
+     * Load-bearing for a consumer's eval ORDER, not a detail. A `verify`
+     * constraint is decided from the files alone and can be checked before
+     * anything runs; a `test` constraint needs the fixtures to execute. Running
+     * the cross-comparison before `verify` passes measures the wrong thing, and
+     * treating a `test`-time refusal as a `verify` gap sends someone to the wrong
+     * layer.
+     *
+     * The split is not always where it looks. `verify` requires that a test FILE
+     * exists, by filename; whether that file is attributed to this rule is
+     * decided later, from the `id:` inside it.
+     */
+    enforcedBy: "verify" | "test";
+    /** One line, for a report that lists several. */
+    summary: string;
+    /** Why it exists, so a reader can tell a house rule from a bug. */
+    rationale: string;
+}
+/**
+ * One constraint a rule broke, paired with the message that reports it.
+ *
+ * Emitted alongside `errors` rather than replacing it. A consumer mapping a
+ * rejection back to the rationale we already wrote had only our wording to
+ * match on, and wording is not a contract: rephrasing an error message is not
+ * a breaking change, so a text match rots without anything reporting it.
+ *
+ * The message is repeated rather than joined to `errors` by index. An index
+ * join is a contract nobody can see, and it breaks the first time either side
+ * filters or reorders. Repeating the string lets a consumer ignore `errors`
+ * entirely.
+ */
+export interface RuleViolation {
+    constraintId: RuleConstraintId;
+    message: string;
+}
+export declare const RULE_CONSTRAINTS: readonly [{
+    readonly id: "sg-id-matches-directory";
+    readonly engine: "sg";
+    readonly enforcedBy: "verify";
+    readonly summary: "A rule's `id:` must equal the directory it lives in.";
+    readonly rationale: "The directory name is the rule id: it is what `check` and `test` address, and what a person types to delete a rule. ast-grep registers the rule under the id in its body. With the two apart, `test` cannot find the rule at all, and `check` does run it but reports findings under a name no directory has, so nobody can locate what produced them.";
+}, {
+    readonly id: "sg-regex-needs-kind";
+    readonly engine: "sg";
+    readonly enforcedBy: "verify";
+    readonly summary: "A `regex` needs a sibling `kind`, in `rule`, `constraints` and `utils`.";
+    readonly rationale: "A regex match with no kind to anchor it is ambiguous and slow: it is applied to every node rather than to the one shape the author meant. ast-grep accepts it, so the engine is not the thing that will tell you.";
+}, {
+    readonly id: "sg-language-accepted";
+    readonly engine: "sg";
+    readonly enforcedBy: "verify";
+    readonly summary: "`language:` must be a spelling ast-grep itself uses; a resolvable but non-canonical one is a notice.";
+    readonly rationale: "An unrecognized name aborts config parsing, which takes every other sg rule in the project down with it and reports nothing. That is the loudest possible failure with the quietest possible symptom: a clean report.";
+}, {
+    readonly id: "sg-files-globs-parse";
+    readonly engine: "sg";
+    readonly enforcedBy: "verify";
+    readonly summary: "`files:` globs must not name `.tsx` under TypeScript, or `.ts` under Tsx.";
+    readonly rationale: "A glob naming an extension the language cannot parse matches nothing, so the rule reports a clean codebase rather than an error. Only the TypeScript/Tsx pair is checked, and deliberately so: they are separate parsers rather than aliases, which is the one language/extension mismatch decidable from the rule file alone. No other extension is compared against `language`, so this is narrower than it first reads.";
+}, {
+    readonly id: "sg-required-fields";
+    readonly engine: "sg";
+    readonly enforcedBy: "verify";
+    readonly summary: "`id`, `language`, `severity`, `message` and `rule` are required.";
+    readonly rationale: "ast-grep needs fewer of these than we do. The extras are what make a finding actionable and a rule addressable once it is on disk.";
+}, {
+    readonly id: "sg-test-file-required";
+    readonly engine: "sg";
+    readonly enforcedBy: "verify";
+    readonly summary: "A rule must ship at least one test file under `.tests/`.";
+    readonly rationale: "A rule with no fixtures has shown neither that it fires nor that it stays quiet. `verify` requires the file; `test` requires the cases inside it to cover both.";
+}, {
+    readonly id: "sg-fixture-id-matches-rule";
+    readonly engine: "sg";
+    readonly enforcedBy: "test";
+    readonly summary: "A test file's own `id:` must equal the rule id.";
+    readonly rationale: "Fixtures are attributed by the id inside the file, not by its name. A fixture carrying another rule's id is silently not counted, so a rule that ships one reads as a rule that shipped none. `verify` passes, because the FILE is there; `test` is where it bites.";
+}];
+/**
+ * The id of a constraint this CLI publishes.
+ *
+ * Derived from the list rather than declared beside it, so a violation can only
+ * name a constraint that is actually published. Attributing a rejection to an
+ * id no consumer can look up would be worse than attributing nothing.
+ */
+export type RuleConstraintId = (typeof RULE_CONSTRAINTS)[number]["id"];
+/**
+ * Record an attributable failure in both places at once.
+ *
+ * `errors` stays the complete list and `violations` the attributable subset, so
+ * a consumer reading only `errors` sees exactly what it saw before this
+ * existed. Written through one call because two arrays maintained separately is
+ * how the message in one comes to differ from the message in the other.
+ */
+export declare function violate(target: {
+    errors: string[];
+    violations: RuleViolation[];
+}, constraintId: RuleConstraintId, message: string): void;
+/** Constraints for one engine. */
+export declare function constraintsFor(engine: EngineName): readonly RuleConstraint[];

package/dist/rules/layout.d.ts

@@ -0,0 +1,152 @@
+/**
+ * The rule layout table — the single description of what a rule is made of and
+ * where its files go, for every engine.
+ *
+ * SPLIT OUT OF `engines.ts` SO IT CAN BE PUBLISHED. This module holds data and
+ * nothing else: no filesystem, no network, no command tree. `engines.ts` keeps
+ * the helpers that join these values to a `cwd`, because those import
+ * `node:fs/promises` and a Worker cannot load them.
+ *
+ * The split exists because the Cloud Generator builds rule payloads against
+ * this table. While it lived only in prose, the same layout was described in
+ * seven stale code comments and in `cli-runtime-rule-execution`'s own spec text,
+ * all naming a path two migrations had already moved — and one of those stale
+ * comments put the wrong layout into a cross-team design document. A shape
+ * described in prose drifts in every place it is described, including the one
+ * that is supposed to be authoritative. Published as data, it cannot.
+ *
+ * Re-exported for consumers as `@taskless/cli/layout` (see `src/layout/`).
+ */
+/**
+ * Engines this CLI knows. The directory name under `.taskless/rules/` **is**
+ * the engine: dispatch reads the path and never parses a rule file to decide
+ * who owns it.
+ */
+export declare const ENGINES: readonly ["sg", "vale", "runtime"];
+export type EngineName = (typeof ENGINES)[number];
+/**
+ * How a rule's fixtures group into cases.
+ *
+ * Stated here rather than left implicit in each engine's fixture reader, which
+ * is where it lived: `runtime/fixtures.ts` rejects a loose file because a case
+ * is a directory, `vale/verify.ts` rejects a nested directory because a case is
+ * a document, and `verify.ts` counts ast-grep's own `valid:`/`invalid:` keys.
+ * The fact was recoverable only by reading three rejections, so every consumer
+ * transcribed it — which is what published this table in the first place.
+ *
+ * Each value is pinned beside the rejection that implements it, rather than in
+ * a test of its own: `runtime-fixtures.test.ts` asserts `case-directories`
+ * where it proves a loose file is refused, `vale-verify.test.ts` asserts
+ * `case-documents` where it proves a nested directory is refused, and
+ * `reference.test.ts` asserts `ast-grep-test` publishes no cases. A reader
+ * changing a reader's mind about its layout meets the declaration in the same
+ * test, which a separate file would not have achieved.
+ */
+export type FixtureLayout = 
+/** A case is a directory under `pass/` or `fail/`, handed to the check as its root. */
+"case-directories"
+/** A case is one document under `pass/` or `fail/`. */
+ | "case-documents"
+/** Not a directory layout: `valid:`/`invalid:` keys inside one ast-grep test file. */
+ | "ast-grep-test";
+/** How a rule reaches execution, or `null` when this CLI has no executor yet. */
+export type EngineExecutor = "ast-grep" | "vale-runner" | "runtime-harness" | null;
+export interface EngineLayout {
+    engine: EngineName;
+    /**
+     * The file inside a rule directory that *is* the rule, as a function of the
+     * rule id. `sg` and `vale` name it after the rule; `runtime` always calls it
+     * `check.ts`, because the rule is a program rather than a document.
+     */
+    ruleFile: (ruleId: string) => string;
+    /**
+     * The engine's per-rule config file, or `undefined` where the engine has
+     * nothing to put in one.
+     *
+     * Only Vale has one, and not for symmetry: Vale cannot express a rule's scope
+     * inside the style file — measured, it rejects unknown keys with `E201` — so
+     * scope needs somewhere else to live. ast-grep carries `files`/`ignores`
+     * inside the rule itself, so an `sg` per-rule config would be a file every
+     * author creates, no author fills, and every reader learns to ignore.
+     */
+    ruleConfigFile: string | undefined;
+    /** Subdirectory holding ast-grep capture rules, for engines that use them. */
+    capturesDirectory: string | undefined;
+    /** How this engine's fixtures group into cases. See {@link FixtureLayout}. */
+    fixtureLayout: FixtureLayout;
+    executor: EngineExecutor;
+}
+/**
+ * Everything defining a rule lives in one directory,
+ * `.taskless/rules/<engine>/<id>/`, the same shape for every engine. A rule is
+ * therefore one path — which is what lets `verify` and `test` take a path
+ * instead of an id, and what makes deleting a rule an `rm -rf` of one thing.
+ */
+export declare const RULES_DIRECTORY = "rules";
+/**
+ * The directory the whole tree hangs off, relative to the project root.
+ *
+ * Here rather than beside its callers because the conformance corpus publishes
+ * `.taskless/rules/<engine>/<id>/` as a path a consumer can act on, and a
+ * published path needs one value to be generated from.
+ *
+ * It is not yet the only copy. The literal appears in about fifteen places
+ * behind four constants that do not know about each other — `CANONICAL_DIR` in
+ * `install/install.ts` and `install/canonical.ts`, `TASKLESS_DIR` in
+ * `install/state.ts`, `TASKLESS_DIRECTORY` in `rules/scan.ts` and
+ * `rules/vale/formats.ts`. `rulesRoot` reads this one, so what the corpus
+ * publishes is what the rule commands resolve. Converging the rest is a
+ * tidy-up, and doing it inside a contract change would hide the contract
+ * change inside a rename.
+ */
+export declare const TASKLESS_DIRECTORY = ".taskless";
+/**
+ * A rule's tests, relative to its rule directory. **The dot is load-bearing.**
+ *
+ * ast-grep's `ruleDirs` recurses and parses every `.yml` beneath it as a rule,
+ * so a plain `tests/` directory inside a rule directory fails the entire scan
+ * with `Fail to parse yaml as RuleConfig: missing field 'language'`. Measured
+ * against ast-grep 0.41.0: `tests/` and `__tests__/` both hard-fail,
+ * a dot-directory is skipped by rule discovery, and `sg test` still reads it
+ * when `testDir` names it.
+ *
+ * That is undocumented behavior, and three things make depending on it
+ * acceptable. The failure is loud — a parse error naming the file, never a test
+ * silently reinterpreted as a rule. `ast-grep-vendor-contract.test.ts` pins it
+ * alongside the rest of ast-grep's observed behavior, so it is
+ * checked on every run rather than remembered. And the binary is pinned to an
+ * exact version, so it cannot change without a deliberate bump, which is
+ * exactly where that test fires.
+ *
+ * If it ever does break, the recorded fallback is to materialize a rules-only
+ * tree for ast-grep and point `ruleDirs` at that (design D2).
+ */
+export declare const RULE_TESTS_DIRECTORY = ".tests";
+export declare const ENGINE_LAYOUTS: {
+    sg: {
+        engine: "sg";
+        ruleFile: (ruleId: string) => string;
+        ruleConfigFile: undefined;
+        capturesDirectory: undefined;
+        fixtureLayout: "ast-grep-test";
+        executor: "ast-grep";
+    };
+    vale: {
+        engine: "vale";
+        ruleFile: (ruleId: string) => string;
+        ruleConfigFile: string;
+        capturesDirectory: undefined;
+        fixtureLayout: "case-documents";
+        executor: "vale-runner";
+    };
+    runtime: {
+        engine: "runtime";
+        ruleFile: () => string;
+        ruleConfigFile: undefined;
+        capturesDirectory: string;
+        fixtureLayout: "case-directories";
+        executor: "runtime-harness";
+    };
+};
+/** Whether `value` names an engine this CLI knows. */
+export declare function isKnownEngine(value: string): value is EngineName;

package/dist/rules/platform-binary.d.ts

@@ -0,0 +1,113 @@
+/**
+ * Resolving a prebuilt binary that ships as a per-platform npm package.
+ *
+ * This was ast-grep's resolver in `scan.ts`, generalized when Vale became a
+ * second engine that needs the same treatment. Both depend on per-platform
+ * packages directly and exec by path, because neither can rely on an
+ * install-time step: `@ast-grep/cli`'s postinstall hardlink fails under pnpm
+ * dlx's strict isolation, and the `@taskless/vale-*` packages deliberately ship
+ * no `bin` and no scripts at all.
+ *
+ * WHAT IS PARAMETERIZED, and why each field exists rather than being derived:
+ *
+ * - `toolchainSuffix` is the one that bites. ast-grep publishes
+ *   `@ast-grep/cli-linux-x64-gnu` and `-win32-x64-msvc`; the Vale packages are
+ *   `@taskless/vale-linux-x64` with **no libc suffix at all**. Reusing
+ *   ast-grep's naming for Vale would look up `@taskless/vale-linux-x64-gnu` and
+ *   miss on every Linux host — a resolution failure that reads as "Vale is not
+ *   installed" rather than as a naming bug.
+ * - `identity` exists because existence is not proof. A file can sit exactly
+ *   where the binary belongs and not be the binary: ast-grep's failed hardlink
+ *   leaves a placeholder text file there. Asking a candidate to identify itself
+ *   is the only check that tells the two apart.
+ */
+export interface PlatformBinarySpec {
+    /** Name used in error messages, e.g. `ast-grep`. */
+    label: string;
+    /** Package name up to the platform suffix, e.g. `@ast-grep/cli`. */
+    packagePrefix: string;
+    /**
+     * Append the platform's toolchain suffix (`-gnu` on Linux, `-msvc` on
+     * Windows). True for ast-grep, false for the Vale packages.
+     */
+    toolchainSuffix: boolean;
+    /**
+     * Executable names to try, in confidence order, spelled for unix. `.exe` is
+     * appended on Windows. More than one because ast-grep declares both
+     * `ast-grep` and `sg` for the same target.
+     *
+     * The first name is the canonical one: it is the only spelling probed inside
+     * the platform package, and it is the name error messages tell the user to put
+     * on PATH. The rest are alternative link names, tried *first* at the
+     * link-based tiers — see {@link resolvePlatformBinary}.
+     */
+    binaryNames: string[];
+    /** Pattern the candidate's own `--version` output must match. */
+    identity: RegExp;
+}
+/** The npm package carrying this host's prebuilt binary. */
+export declare function platformPackageName(spec: PlatformBinarySpec): string;
+/**
+ * The command name to tell a user to put on PATH, spelled for this platform
+ * (`sg.exe` on Windows). It is the first spelling the PATH search itself tries,
+ * so the advice and the search cannot drift apart.
+ */
+export declare function pathCommandName(spec: PlatformBinarySpec): string;
+/** First entry on PATH that holds a file named `command`. */
+export declare function findOnPath(command: string): string | undefined;
+/**
+ * Whether `path` is really this binary, established by running it.
+ *
+ * See {@link PlatformBinarySpec.identity} — existence is not enough, because a
+ * placeholder file left by a failed install sits at exactly the right path and
+ * satisfies `existsSync` happily.
+ */
+export declare function isPlatformBinary(spec: PlatformBinarySpec, path: string): boolean;
+/**
+ * Which tier produced a resolution.
+ *
+ * `platform-package` is the version this CLI pins and installs. The other two
+ * are whatever the host happens to carry, and can be any version.
+ */
+export type PlatformBinarySource = "platform-package" | "node_modules/.bin" | "PATH";
+export interface PlatformBinaryResolution {
+    /** Absolute path to the verified binary, or `undefined` when none resolved. */
+    path: string | undefined;
+    /**
+     * Which tier the path came from, or `undefined` when nothing resolved.
+     *
+     * **Identity is not provenance.** Resolution proves the file exists and
+     * answered `--version` as the right tool; it proves nothing about the
+     * version. Only `platform-package` is the pinned install, so only that tier
+     * entitles a caller to {@link AST_GREP_VERSION}-style constants without
+     * running the binary.
+     *
+     * Reported rather than left to be re-derived. A caller that needs the pinned
+     * engine would otherwise compare the returned path against a package root it
+     * reconstructs itself, which is this resolver's own search order copied into
+     * a consumer, and copies drift.
+     */
+    source: PlatformBinarySource | undefined;
+    /** Locations searched, in order, for an actionable failure message. */
+    tried: string[];
+}
+/**
+ * Search every place the binary could reasonably live, verifying each.
+ *
+ * Candidates are ordered by confidence rather than by convenience — the
+ * platform package first because it is the version we pinned, then a locally
+ * linked binary, then whatever the host provides on PATH.
+ *
+ * The platform package is probed under one name only. Its contents are ours to
+ * predict — the package ships the binary under its canonical name — so trying
+ * the alternative spellings there buys nothing but an extra `require.resolve`
+ * and a duplicate entry in `tried`, which reads to the user as the same
+ * location searched twice. The link-based tiers do try every spelling, because
+ * which one exists there is the installer's choice, not ours.
+ *
+ * Returns rather than throws. The two callers want different things from a
+ * miss: ast-grep cannot run at all without it, while a missing Vale binary
+ * makes one engine unavailable and must not abort the others (D6b). Encoding
+ * "not found" as a value rather than an exception is what lets each decide.
+ */
+export declare function resolvePlatformBinary(spec: PlatformBinarySpec): PlatformBinaryResolution;

package/dist/rules/vale/binary.d.ts

@@ -0,0 +1,35 @@
+import { type PlatformBinaryResolution, type PlatformBinarySpec } from "../platform-binary";
+/**
+ * Vale's per-platform packaging.
+ *
+ * `toolchainSuffix: false` is the whole reason this spec exists separately from
+ * ast-grep's. `add-vale-binary-packages` publishes `@taskless/vale-<os>-<cpu>`
+ * — `@taskless/vale-linux-x64`, not `-linux-x64-gnu`. ast-grep's resolver
+ * appends `-gnu` on every Linux, so reusing its naming here would resolve
+ * nothing on Linux while reporting the ordinary "Vale is unavailable" message,
+ * making a naming bug indistinguishable from a host without the binary.
+ *
+ * One binary name, unlike ast-grep's two: these packages ship `vale` (or
+ * `vale.exe`) as pure payload, with no `bin` entry and no lifecycle script, so
+ * there is no wrapper spelling to also try.
+ */
+export declare const VALE_BINARY: PlatformBinarySpec;
+/**
+ * Locate the Vale binary, or report that it is unavailable.
+ *
+ * Returns `undefined` rather than throwing, per D6b: a missing Vale binary
+ * makes the Vale engine unavailable and must not abort the other engines. The
+ * caller turns that into a reported-but-not-fatal outcome; ast-grep's resolver
+ * throws instead, because it has no degraded mode.
+ */
+export declare function findValeBinary(): PlatformBinaryResolution;
+/** Reset the process cache. Tests only. */
+export declare function resetValeBinaryCache(): void;
+/**
+ * An actionable message naming where we looked.
+ *
+ * The PATH advice is spelled for the platform — `vale.exe` on Windows — rather
+ * than hardcoded, so a Windows user is not told to install a name that the
+ * resolver would not find there.
+ */
+export declare function valeUnavailableMessage(tried: string[]): string;

package/dist/schemas/index.d.ts

@@ -0,0 +1,93 @@
+/**
+ * Public entry for `@taskless/cli/schemas`.
+ *
+ * The shapes this CLI's `--json` output is produced from, as data. A consumer
+ * parsing `taskless verify --json` validates against the schema the CLI emits
+ * from, rather than against an interface it hand-wrote by reading our output
+ * once.
+ *
+ * ## Why this is published
+ *
+ * This is `@taskless/cli/layout`'s argument applied to the other half of the
+ * contract. A hand-written interface is a copy that nothing checks: the CLI can
+ * add a field, change what one means, or extend an enum, and the copy stays
+ * confidently wrong until something downstream misbehaves. The Cloud eval team
+ * is doing exactly that today against the `verify` envelope.
+ *
+ * ## What this is NOT
+ *
+ * Not an SDK. Nothing here performs verification, and no `verify()` or `test()`
+ * is exported. Both spawn a vendored platform binary — ast-grep or Vale — so
+ * anywhere a function call could run them, `npx @taskless/cli verify --json`
+ * runs too: the export would buy a call site, not a capability, while making
+ * internal signatures public. The CLI stays the execution surface; this
+ * describes what it says.
+ *
+ * Nothing here reaches the filesystem, a process, the network or the command
+ * tree, so a Worker can import it — and the build fails rather than emitting an
+ * entry whose graph reaches a host capability. `writeJsonError` is deliberately
+ * absent for that reason: it writes to stdout, and a consumer asking what shape
+ * an error takes should not thereby acquire something that emits one.
+ *
+ * ## Zod is bundled, and that is the point
+ *
+ * This entry ships its own copy of zod rather than resolving the consumer's.
+ * That follows from the build's standing rule for library entries — everything
+ * but node builtins is bundled — but it is also the behaviour we want, so do
+ * not "fix" it by making zod external.
+ *
+ * **A consumer's zod is not ours.** Marking it external would make validation
+ * depend on whichever version resolved on the other side, so the same payload
+ * could parse there and not here, and the schema would stop being a statement
+ * about what this CLI emits. Bundling makes `parse()` answer with our zod's
+ * semantics wherever it runs.
+ *
+ * **And `parse()` is stronger than a JSON Schema of the same shape.** It
+ * strips: `parse({ ok: true, rules: [], surprise: 1 })` returns
+ * `{ ok: true, rules: [] }`, where a JSON Schema validator hands back the
+ * object it was given, unknown keys included. Every schema here is plain today
+ * — objects, enums, arrays, optionals — so a JSON Schema rendering would lose
+ * little beyond that. It is the moment we add a refinement that the difference
+ * bites, and it would bite silently: the rendering would go on validating a
+ * weaker shape while claiming to describe this one.
+ *
+ * `z.toJSONSchema()` therefore stays unexported, and the criterion is the
+ * TRANSPORT rather than the consumer's language. JSON Schema is what you reach
+ * for when the schema itself has to travel — when the far side can receive JSON
+ * and nothing else, so a description of the shape is the most that fits. That
+ * is not this boundary. A consumer here takes a dependency on our schema files,
+ * which means it can assert the payload rather than assert against a
+ * description of the payload, and rendering ours down to what a JSON transport
+ * could carry would give that up in exchange for nothing.
+ */
+export { 
+/**
+ * `taskless verify --json` and `taskless test --json`.
+ *
+ * One envelope for both, because the commands share an implementation and
+ * differ only in what they run against each rule.
+ */
+outputSchema as verifyTestOutputSchema, } from "./verify-test.js";
+export { 
+/** `taskless rule verify <id> --json`, for an ast-grep rule. */
+verifyOutputSchema, 
+/** The same, for a Vale rule — a different shape, discriminated on `engine`. */
+valeVerifyOutputSchema, } from "./rules-verify.js";
+export type { 
+/**
+ * A constraint `verify` or `test` enforces beyond an engine's own schema.
+ *
+ * The type of the entries in `@taskless/cli/reference.json`'s
+ * `constraints[]`, so a consumer reading the corpus and a consumer reading a
+ * rejection are working from one definition.
+ */
+RuleConstraint, 
+/** One constraint a rule broke, as `violations[]` carries it. */
+RuleViolation, 
+/** The id of a constraint this CLI publishes. */
+RuleConstraintId, } from "../rules/constraints.js";
+export type { 
+/** The stable code an error envelope carries under `--json`. */
+CLIErrorCode, 
+/** The envelope itself. Not every `--json` failure is a rule result. */
+CLIErrorEnvelope, } from "../types/errors.js";

package/dist/schemas/rules-create.d.ts

@@ -11,6 +11,7 @@ export declare const outputSchema: z.ZodObject<{
     ruleId: z.ZodString;
     rules: z.ZodArray<z.ZodString>;
     files: z.ZodArray<z.ZodString>;
+    notices: z.ZodOptional<z.ZodArray<z.ZodString>>;
 }, z.core.$strip>;
 /** Error schema for `taskless rule create --json` on failure */
 export declare const errorSchema: z.ZodObject<{

package/dist/schemas/rules-improve.d.ts

@@ -14,6 +14,7 @@ export declare const outputSchema: z.ZodObject<{
     requestId: z.ZodString;
     rules: z.ZodArray<z.ZodString>;
     files: z.ZodArray<z.ZodString>;
+    notices: z.ZodOptional<z.ZodArray<z.ZodString>>;
 }, z.core.$strip>;
 /** Error schema for `taskless rule improve --json` on failure */
 export declare const errorSchema: z.ZodObject<{