From 714adf7c80a97a04e69332278b197cd073046991 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Sun, 26 Jul 2026 17:56:34 -0700
Subject: [PATCH 01/15] =?UTF-8?q?docs(openspec):=20add-vale-rule-engine=20?=
 =?UTF-8?q?=E2=80=94=20Vale=20as=20a=20second=20static-tier=20engine?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LdEhGzeQfSGJM3nKKNj7Bp
---
 .../add-vale-rule-engine/.openspec.yaml       |  2 +
 .../changes/add-vale-rule-engine/design.md    | 97 ++++++++++++++++++
 .../changes/add-vale-rule-engine/proposal.md  | 34 +++++++
 .../specs/cli-check/spec.md                   | 52 ++++++++++
 .../specs/cli-rule-format/spec.md             | 75 ++++++++++++++
 .../specs/cli-runtime-rule-execution/spec.md  | 23 +++++
 .../specs/cli-vale-rule-engine/spec.md        | 98 +++++++++++++++++++
 .../changes/add-vale-rule-engine/tasks.md     | 45 +++++++++
 8 files changed, 426 insertions(+)
 create mode 100644 openspec/changes/add-vale-rule-engine/.openspec.yaml
 create mode 100644 openspec/changes/add-vale-rule-engine/design.md
 create mode 100644 openspec/changes/add-vale-rule-engine/proposal.md
 create mode 100644 openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md
 create mode 100644 openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
 create mode 100644 openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md
 create mode 100644 openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md
 create mode 100644 openspec/changes/add-vale-rule-engine/tasks.md

diff --git a/openspec/changes/add-vale-rule-engine/.openspec.yaml b/openspec/changes/add-vale-rule-engine/.openspec.yaml
new file mode 100644
index 00000000..9e5b8a19
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-07-23
diff --git a/openspec/changes/add-vale-rule-engine/design.md b/openspec/changes/add-vale-rule-engine/design.md
new file mode 100644
index 00000000..d44200bf
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/design.md
@@ -0,0 +1,97 @@
+## Context
+
+Taskless rules run today through one engine, ast-grep: `commands/check.ts` writes an ephemeral `sgconfig.yml` (`ruleDirs: [rules]`) and runs `sg scan --config … --json=stream`; rules live as bare ast-grep YAML at `.taskless/rules/*.yml`. A separate **runtime** tier (`runtime-rules/<name>/`: capture YAML + signed `check.ts`) runs only after an authenticated server reconcile. A `.taskless/` migration system exists (`filesystem/migrate.ts`→`runMigrations`, keyed on `taskless.json`'s `version`, invoked via `ensureTasklessDirectory`).
+
+We add **Vale**, a markup-aware prose linter, because ast-grep can't lint prose. The design was derived empirically against `vale 3.15.1` and `sg 0.41.0`; the facts that shaped it:
+
+- **Each tool already has a native, committed config that expresses everything we need** — ast-grep: a rule's native `files`/`ignores` scope it, `metadata` holds extra data; Vale: a `.vale.ini` **matcher** (a `[<glob>]` section) scopes rules by path glob and, because Vale accepts and silently ignores unknown keys, holds arbitrary Taskless data _within that matcher_. So Taskless needs **no separate metadata/sidecar layer** — each engine's own config is the source of truth.
+- **Vale `.vale.ini` scoping composes cleanly and predictably** (all verified): `[<glob>] Style.Rule = YES` enables a rule for a path (no `BasedOnStyles` needed); overlapping enables **union**; `[<glob>] Style.Rule = NO` **disables** and wins over an enable, order-independent; globs support brace alternation with slashes (`[{marketing/**,docs/**}]`) and whole-section negation (`[!x]`). So arbitrary per-rule include/exclude lives in the `.ini` itself.
+- **Vale requires a StyleName directory level** (`StylesPath/<Style>/<rule>.yml`) — a flat rule errors `E100 style does not exist`; a `rules/` dir _is_ that StyleName.
+- **Both tools read rules from disk via `--config` with no size ceiling** — so committed per-engine configs scale to hundreds of rules where `--inline-rules` (`ARG_MAX`) and `sg --rule` (single file) can't.
+
+The result: engines are partitioned **by top-level directory**, each holding its tool's native, **committed** config + rules + tests. Check is pure execution — no sidecars, no materialization, no generation, nothing to cache.
+
+## Goals / Non-Goals
+
+**Goals:** add Vale as a second **static-tier** engine; store each engine's rules + config in its own directory using the tool's native format; make `check`/`verify` pure execution over committed configs (zero construction); ride the existing migration ladder.
+
+**Non-Goals:** generating Vale rules and authoring the committed configs — split across **two downstream changes**: a CLI-side change (the `taskless/skills` rule-authoring commands that _write_ `.vale.ini`/`sgconfig.yml`) and a `taskless`-repo change (server rule generation + prose-request classification). Also out of scope: changing runtime _execution_ (harness/reconcile/signing are untouched — only the runtime directory moves); restricting Vale's feature set (Tengo `script` is sandboxed — D7).
+
+## Directory layout (target)
+
+```
+.taskless/
+  sg/       sgconfig.yml            rules/<rule>.yml            rule-tests/<name>.yml
+  vale/     .vale.ini               rules/<rule>.yml            rule-tests/<name>.yml
+  runtime/  rules/<rule>/{<capture>.yml, check.ts}   rule-tests/<rule>/<fixture>/
+  taskless.json
+```
+
+This change implements all three: `sg/`, `vale/`, and the `runtime/` realignment (safe now — no one uses runtime rules yet, and the move is content-preserving so runtime hashes are unaffected). Every scaffolded directory (each engine dir and its `rules/`/`rule-tests/`) carries a `.gitkeep` so the structure is tracked reliably even when empty.
+
+## Decisions
+
+### D1 — Engines partition by top-level directory; each holds a native, committed config
+
+`.taskless/<engine>/` contains `{config, rules/, rule-tests/}` in that engine's native format. Directory = engine (dispatch is which dir, no parsing); the config is **committed and persisted**, not generated. This is what makes `check` construction-free and sidesteps cross-parse (Vale's StylesPath never sees `.sg.yml`).
+
+- **Why not co-located rules + a sidecar/envelope** (earlier designs): every co-located approach forced either an in-file marker Vale rejects (`E201`) or a generated config + materialization at check time. Per-engine native configs delete that entire layer — the tool's own config already carries scoping and (via ignored keys / `metadata` / comments) any Taskless breadcrumbs.
+
+### D2 — The native config is the source of truth; no sidecars, no generation at check time
+
+- **ast-grep** (`sg/`): `sgconfig.yml` (`ruleDirs: [rules]`, `testConfigs: [{testDir: rule-tests}]`) + native rule files whose `files`/`ignores` scope them and `metadata` holds Taskless data.
+- **Vale** (`vale/`): `.vale.ini` (`StylesPath = .`, `BasedOnStyles = rules`, per-rule scoping sections, plus Taskless breadcrumbs as `tskl) <name> = <value>` keys — Vale's ini parser accepts and silently drops them, verified) + native styles under `rules/` (the StyleName). Vale check names are `rules.<name>`, normalized to `ruleId = <name>`. ast-grep, by contrast, carries any Taskless data in its native `metadata` field.
+
+Construction of these configs happens at **rule-authoring time** (the downstream generator, or a human editing a committed config) — never at check time.
+
+### D3 — Scoping is native per engine
+
+- **ast-grep** — a rule's `files` (include) / `ignores` (exclude), verified to path-scope an inline/config rule.
+- **Vale** — each `.vale.ini` **matcher** (a `[<glob>]` section) scopes by path and lists which rules run there: include = `rules.<name> = YES` (enables union across matchers), exclude = `rules.<name> = NO` (disable wins). Deterministic and order-independent (verified), so generation is a straight emit of YES/NO matchers — no cascade to reason about.
+
+**Repeat matchers are allowed and merge** — Vale unions duplicate `[<glob>]` headers (verified: `[*.md]` twice fired both rules). Because one rule's scoping can therefore be scattered across several matchers, each Taskless-owned matcher carries a `tskl) rule = <id>` breadcrumb naming its owning rule — a **canonical id** so tooling can find and update the right rule's matchers later rather than guessing from globs.
+
+### D4 — Vale layout maps to StylesPath via the `rules/` StyleName
+
+`.vale.ini` lives at `.taskless/vale/.vale.ini` with `StylesPath = .`, so `.taskless/vale/rules/` is the required StyleName directory (`BasedOnStyles = rules`). Styles are pure-native Vale files; the `rules.` check-name prefix is stripped for `ruleId`. (Flat rules without the StyleName level fail — verified.)
+
+### D5 — Check and verify are pure execution over committed configs
+
+`check` runs each engine's tool with its committed config over the resolved paths, concurrently, and merges `CheckResult`s — **no materialization, no sidecar reads, no config generation, nothing to cache**:
+
+- ast-grep — `sg scan --config .taskless/sg/sgconfig.yml <paths> --json=stream`.
+- Vale — `vale --config .taskless/vale/.vale.ini <paths> --output=JSON --no-exit`.
+
+`verify` likewise runs native runners: `sg test -c .taskless/sg/sgconfig.yml` (ast-grep's native tests, matched by rule `id`), and a Vale **fixture runner** over `.taskless/vale/rule-tests/<rule>/` — a per-rule subdirectory of `pass/` and `fail/` fixture documents. Because verify is one-time (not per-check), the isolating `.vale.ini` (StylesPath + only that rule enabled) is **generated** at verify time rather than committed; conceptually this mirrors ast-grep's `valid`/`invalid` (pass/fail), asserting every `fail/` fixture yields a finding and every `pass/` fixture none. Because `generateSgConfig` no longer runs on the check path, `check` calls `ensureTasklessDirectory` directly to preserve the migration trigger.
+
+### D6 — Vale runs in the static tier, unmodified, bounded by a subprocess timeout
+
+Vale's Tengo `script` sandbox exposes only `text`/`math`/`fmt` (verified: `os`/`io`/`exec` → "module not found"), so a Vale rule can't reach the host — trust equals ast-grep static. Vale is always-run, anonymous-safe, no reconcile/signing; a subprocess timeout bounds a runaway Tengo loop. Vale is used as-is.
+
+### D7 — One scaffold version in `taskless.json`; migration `0004` reorganizes into `sg/` + `vale/`
+
+`taskless.json.version` is the single format version. Migration `0004-*` is a **mechanical move**: the existing `.taskless/rules/` and `rule-tests/` are all known-ast-grep, so it moves `rules/ → sg/rules/`, `rule-tests/ → sg/rule-tests/`, and `sgconfig.yml → sg/sgconfig.yml` — and because `ruleDirs: [rules]` is _relative to the config_, it survives the move unchanged (no path edits). It then scaffolds `vale/` (`.vale.ini` + `rules/` + `rule-tests/`) and moves the runtime tier into the same shape: `runtime-rules/<name>/ → runtime/rules/<name>/` and `runtime-rule-tests/<name>/ → runtime/rule-tests/<name>/`. The runtime move is content-preserving — capture-rule bytes (and thus their reconciliation hashes) are unchanged; only `discover.ts`'s search path updates. Legacy bare rules keep working (they become `sg/` rules). **Version gating:** `runMigrations` currently returns silently when `version > maxVersion`; change it to **throw** ("upgrade the CLI") unless `--allow-version-mismatches` is passed.
+
+### D8 — Metadata surfaces through `CheckResult`; identity from the rule name
+
+`CheckResult { source, ruleId, severity, message, note, file, range, matchedText, fix }` is the contract each engine maps into. `ruleId` is the rule's basename (ast-grep native `id`; Vale's `rules.<name>` stripped to `<name>`). Severity is engine-native, normalized on the client — Vale `error/warning/suggestion → error/warning/hint` (`info` unused; `.vale.ini` sets `MinAlertLevel = suggestion`). Vale mapping: `message←Message`, `note←Description/Link`, `range←Line+Span`, `matchedText←Match`, `fix←Action` when populated. Provenance is a generation-time server wrapper, never on disk.
+
+## Risks / Trade-offs
+
+- **Committed configs are maintained artifacts** — the `.vale.ini` scoping sections and native `files`/`ignores` must be authored/updated when rules change. Construction doesn't vanish; it moves to rule-authoring time (mostly the downstream generator). Trade: check-time simplicity + transparent, versioned configs for author-time maintenance.
+- **Per-engine (not uniform) metadata** — fine for check (findings carry the rule name); any "list/describe rules" tooling parses each engine's native format.
+- **Vale `StyleName = rules`** yields `rules.<name>` internally → stripped for `ruleId`; keep the strip consistent.
+- **Losing auto-migration when `generateSgConfig` leaves check** → `check` calls `ensureTasklessDirectory` directly (D5).
+- **Vale DoS (runaway Tengo)** → subprocess timeout (D6).
+- **New `vale` binary dependency** → shell out like `sg`; degrade clearly if absent.
+- **Runtime realignment** → `runtime-rules/ → runtime/rules/` moves the directory only; execution (harness/reconcile/signing) and capture-rule content are untouched, so hashes are stable. Safe now because runtime rules have no live users; the downstream generator's write path updates separately.
+
+## Migration Plan
+
+`migrations/0004-vale-engine.ts`: bump the scaffold version; move `rules/`, `rule-tests/`, `sgconfig.yml` under `sg/`; scaffold `vale/`; move `runtime-rules/ → runtime/rules/` and `runtime-rule-tests/ → runtime/rule-tests/`. Back-compat — legacy rules become `sg/` rules unchanged; runtime content is byte-identical after the move. On the next `check`/`verify`, `runMigrations` applies it. Rollback is safe until a `vale/` rule exists; thereafter a Vale-aware CLI is required (version gating makes that explicit).
+
+## Open Questions
+
+_None outstanding._ The three revisited items are resolved: Vale rule-tests use per-rule `pass/`/`fail/` subdirectories with a verify-time-**generated** isolating `.vale.ini` (mirroring ast-grep's valid/invalid); Taskless breadcrumbs in `.vale.ini` use the `tskl) <name> = <value>` namespace (all namespaced key syntaxes verified tolerated); and the runtime tier is **realigned** to `runtime/` in this change (content-preserving move).
+
+All hard mechanisms are verified against `vale 3.15.1` / `sg 0.41.0`: native-config scoping, `.vale.ini` enable/disable composition, StyleName requirement, `--config` scale path, ignored `tskl)` keys, Vale sandbox.
diff --git a/openspec/changes/add-vale-rule-engine/proposal.md b/openspec/changes/add-vale-rule-engine/proposal.md
new file mode 100644
index 00000000..7d13ae7c
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -0,0 +1,34 @@
+## Why
+
+Taskless rules today are ast-grep only — structural AST matching that fits code but cannot lint prose. A large, wanted class of rules (terminology, banned/weasel words, inclusive language, readability, heading/style consistency) targets Markdown and prose, which ast-grep structurally cannot express: its text nodes are opaque, and it has no dictionaries, NLP, or code-vs-prose scoping. Vale is a mature, markup-aware prose linter that covers exactly this gap. This change makes the CLI multi-engine by partitioning rules **per engine directory**, each using the tool's own native, committed config — so engines never cross-parse one another's rules, hundreds of rules run without command-line limits, and `check` is pure execution.
+
+## What Changes
+
+- **Engine-top-down layout**: `.taskless/<engine>/` holds `{config, rules/, rule-tests/}` in that engine's native format — `sg/` (`sgconfig.yml` + native ast-grep rules) and `vale/` (`.vale.ini` + native Vale styles). Directory = engine; dispatch is which directory.
+- **The native config is the source of truth — no sidecars, no generation at check time.** Each engine's committed config already carries everything: ast-grep rules scope via native `files`/`ignores` and hold Taskless data in `metadata`; Vale scopes via `.vale.ini` sections and (since Vale ignores unknown keys) carries Taskless breadcrumbs as `tskl) <name> = <value>` keys.
+- **Vale scoping lives in `.vale.ini` matchers**: each `[<glob>]` section is a **matcher** — a globbable block whose parameters name which rule(s) run there (`rules.<name> = YES`/`NO`; enables union, disable wins), our `tskl)`-prefixed keys, and any other Vale config for that matcher. Styles live under `rules/` (Vale's required StyleName; `StylesPath = .`, `BasedOnStyles = rules`).
+- **Check is pure execution over committed configs**: `sg scan --config sg/sgconfig.yml` / `vale --config vale/.vale.ini` — no materialization, no sidecar reads, no config generation, nothing to cache.
+- **Verify works differently from check** (both engines isolate each rule against known fixtures): `sg test` runs ast-grep's native tests; the Vale verifier **generates a temporary `.vale.ini`** to test each rule against its `pass/`/`fail/` fixtures.
+- **Add Vale as a static-tier engine**: always-run, anonymous-safe, no reconcile/signing. Vale's Tengo `script` is sandboxed (only `text`/`math`/`fmt`; no `os`/`io`/`exec`) — not a code-execution vector — so it stays static; a subprocess timeout bounds it.
+- **Realign runtime to the same shape**: move `runtime-rules/ → runtime/rules/` and `runtime-rule-tests/ → runtime/rule-tests/` (content-preserving — no live users, hashes stable). Runtime _execution_ (harness/reconcile/signing) is unchanged; only the directory and `discover.ts`'s search path move.
+- **Ship as migration `0004`** on the existing `runMigrations` ladder — moves `rules/`/`rule-tests/`/`sgconfig.yml` under `sg/`, scaffolds `vale/`, and moves the runtime dirs under `runtime/`. No new `upgrade` command; `runMigrations` gains version-mismatch gating (throw + `--allow-version-mismatches`).
+
+## Capabilities
+
+### New Capabilities
+
+- `cli-rule-format`: The engine-top-down on-disk layout — `.taskless/<engine>/{config, rules/, rule-tests/}` with each engine's native, committed config as the source of truth (no sidecars, no generated config). Directory-based dispatch; the extension point for future engines.
+- `cli-vale-rule-engine`: Vale as a concrete static engine — static-tier trust (sandboxed Tengo), the `.vale.ini` **matcher** scoping model (per-`[<glob>]` enable/disable + `tskl)` keys) and StyleName mapping, the `--config` check runner, a **verify that generates a temporary `.vale.ini`** per rule against `pass/`/`fail/` fixtures, and findings→`CheckResult` mapping (incl. `rules.` prefix stripping).
+
+### Modified Capabilities
+
+- `cli-check`: Check runs each engine's native tool with its committed config (`sg scan --config sg/…`, `vale --config vale/…`) over the resolved paths, concurrently, and merges results; verify runs `sg test` (ast-grep) and a Vale fixture runner. The ephemeral `sgconfig.yml` generation is removed from the check path (configs are committed under `sg/`), and `check` calls `ensureTasklessDirectory` directly to preserve the migration trigger.
+- `cli-runtime-rule-execution`: Runtime rules are discovered under `.taskless/runtime/rules/<name>/` (and fixtures under `runtime/rule-tests/<name>/`) instead of `runtime-rules/` — a directory move only; execution semantics are unchanged.
+
+## Impact
+
+- **CLI (`packages/cli`)**: `commands/check.ts` (per-engine execution over committed configs + migration trigger), `rules/scan.ts` (`--config` over `sg/`), `rules/verify.ts` (`sg test` over `sg/`), new `rules/vale/*` (`--config` runner, `CheckResult` mapping, fixture verify), removal of ephemeral `filesystem/sgconfig.ts` generation from the check path, new `filesystem/migrations/0004-*.ts`.
+- **On-disk layout**: `.taskless/sg/{sgconfig.yml, rules/, rule-tests/}` and `.taskless/vale/{.vale.ini, rules/, rule-tests/}`; legacy bare `.taskless/rules/*.yml` migrate under `sg/`. `taskless.json` scaffold version bumps.
+- **Dependency**: adds `vale` as an external binary the CLI shells out to (like `sg`).
+- **Runtime execution unchanged** (reconcile/signing/harness) — only the directory moves `runtime-rules/ → runtime/rules/` (updating `discover.ts`'s path); Vale is explicitly static. **No new `upgrade` command** — the migration ladder suffices (now with version-mismatch gating).
+- **Downstream (separate change, taskless repo)**: generating Vale rules + authoring the committed `.vale.ini`/`sgconfig.yml`, the verification-sandbox path, and prose-request classification build on this foundation.
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md
new file mode 100644
index 00000000..36ea32d7
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md
@@ -0,0 +1,52 @@
+## ADDED Requirements
+
+### Requirement: Check runs engines concurrently and merges their results
+
+`taskless check` SHALL run its per-engine executors concurrently and merge their `CheckResult`s into a single result set. A missing or unavailable engine SHALL NOT abort the others; its absence SHALL be reported while the remaining engines still produce results.
+
+#### Scenario: ast-grep and Vale run concurrently and merge
+
+- **WHEN** `.taskless/sg/` and `.taskless/vale/` both contain rules
+- **THEN** the CLI runs both engines concurrently and returns one merged result set whose findings count toward the exit code identically
+
+#### Scenario: One engine unavailable, others proceed
+
+- **WHEN** the `vale` binary is unavailable but `.taskless/sg/` has rules
+- **THEN** the CLI reports the Vale engine as unavailable and still returns ast-grep results
+
+## MODIFIED Requirements
+
+### Requirement: Check subcommand executes ast-grep scan
+
+The CLI SHALL execute `sg scan --config .taskless/sg/sgconfig.yml --json=stream` using `child_process.spawn` with `shell: true` for cross-platform binary resolution, reading the **committed** ast-grep config at `.taskless/sg/sgconfig.yml`. No `sgconfig.yml` is generated at check time. The `sg` binary SHALL be resolved from the `@ast-grep/cli` dependency via PATH. Reconciliation/run-set semantics for runtime rules are unchanged.
+
+#### Scenario: ast-grep scan runs with the committed config
+
+- **WHEN** the CLI executes the ast-grep scanner
+- **THEN** it SHALL invoke `sg scan` with `--config .taskless/sg/sgconfig.yml` and `--json=stream`
+- **AND** it SHALL NOT write or generate a config file
+- **AND** the working directory for the spawned process SHALL be the resolved project directory
+
+#### Scenario: ast-grep binary is not found
+
+- **WHEN** the `sg` binary cannot be resolved from PATH
+- **THEN** the CLI SHALL print an error message indicating ast-grep is not available
+- **AND** the CLI SHALL exit with code 1
+
+### Requirement: Check dispatches static and runtime rules to distinct executors
+
+`taskless check` SHALL dispatch rules to distinct executors by their engine directory: **ast-grep** rules under `.taskless/sg/` via the ast-grep scanner, **Vale** rules under `.taskless/vale/` via the Vale runner (per the `cli-vale-rule-engine` capability), and **runtime** rules under `.taskless/runtime/rules/` via the runtime harness (per the `cli-runtime-rule-execution` capability). Findings from all executors SHALL be aggregated into the same result set and SHALL count toward the exit code identically.
+
+#### Scenario: Mixed corpus runs all executors
+
+- **WHEN** `.taskless/sg/` contains ast-grep rules, `.taskless/vale/` contains Vale rules, and `.taskless/runtime/rules/` contains runtime rules
+- **THEN** the CLI SHALL run ast-grep rules through `sg scan`, Vale rules through the Vale runner, and runtime rules through the runtime harness
+- **AND** SHALL merge their findings into one result set
+
+## REMOVED Requirements
+
+### Requirement: Check subcommand generates ephemeral sgconfig.yml
+
+**Reason**: Engine configs are now committed per-engine directory (`.taskless/sg/sgconfig.yml`), not generated at check time — check reads the committed config directly.
+
+**Migration**: Migration `0004` moves the existing `.taskless/sgconfig.yml` to `.taskless/sg/sgconfig.yml` (its relative `ruleDirs: [rules]` remains valid). No config is written at check time thereafter.
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
new file mode 100644
index 00000000..3b9b0aff
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
@@ -0,0 +1,75 @@
+## ADDED Requirements
+
+### Requirement: Rules are partitioned into per-engine directories
+
+The system SHALL store rules under a top-level engine directory `.taskless/<engine>/`, each with a `rules/` directory and a `rule-tests/` directory. The `sg` engine SHALL use `sgconfig.yml`; the `vale` engine SHALL use `.vale.ini`; the `runtime` engine SHALL store each rule as a directory `rules/<rule>/` (capture `*.yml` + `check.ts`) with fixtures under `rule-tests/<rule>/`.
+
+#### Scenario: ast-grep engine directory
+
+- **WHEN** the CLI resolves `.taskless/`
+- **THEN** ast-grep rules are found under `.taskless/sg/rules/`, the config is `.taskless/sg/sgconfig.yml`, and tests are under `.taskless/sg/rule-tests/`
+
+#### Scenario: Vale engine directory
+
+- **WHEN** the CLI resolves `.taskless/`
+- **THEN** Vale styles are found under `.taskless/vale/rules/`, the config is `.taskless/vale/.vale.ini`, and tests are under `.taskless/vale/rule-tests/`
+
+### Requirement: A rule's engine is determined by its containing directory
+
+The system SHALL dispatch each rule to the engine named by its top-level `.taskless/<engine>/` directory, and SHALL NOT parse a rule file to determine its engine.
+
+#### Scenario: Directory-based dispatch
+
+- **WHEN** a rule file exists at `.taskless/sg/rules/no-eval.yml` and another at `.taskless/vale/rules/no-simply.yml`
+- **THEN** the first is executed by ast-grep and the second by Vale, based solely on directory
+
+### Requirement: Each engine's committed native config is the source of truth
+
+The system SHALL treat each engine's committed native config as the authoritative definition of its rules, their scoping, and their metadata. The system SHALL NOT require a separate Taskless sidecar or metadata file for a rule, and SHALL NOT generate an engine config at check time.
+
+#### Scenario: No sidecar or generated config
+
+- **WHEN** the CLI runs a check
+- **THEN** it reads the committed `sg/sgconfig.yml` and `vale/.vale.ini` as-is, and neither writes nor generates an engine config
+
+#### Scenario: Native scoping is applied by the engine
+
+- **WHEN** an ast-grep rule declares native `files`/`ignores`, or a Vale `.vale.ini` declares per-rule include/exclude sections
+- **THEN** the engine applies that scoping directly, with no Taskless-side rule transformation
+
+### Requirement: Vale styles live under the rules StyleName
+
+The system SHALL place Vale styles under `.taskless/vale/rules/` so that `rules` is Vale's StyleName, with `.vale.ini` configured `StylesPath = .` and `BasedOnStyles = rules`. The Vale check identifier `rules.<name>` SHALL be normalized to `ruleId = <name>` in results.
+
+#### Scenario: Style resolution and identity
+
+- **WHEN** a Vale style exists at `.taskless/vale/rules/no-simply.yml`
+- **THEN** Vale loads it as `rules.no-simply`, and the CLI reports its findings with `ruleId` `no-simply`
+
+### Requirement: Migration preserves existing ast-grep rules by moving them under sg
+
+The migration to the engine-partitioned layout SHALL move the existing `.taskless/rules/`, `.taskless/rule-tests/`, and `.taskless/sgconfig.yml` under `.taskless/sg/` without editing file contents, relying on `sgconfig.yml`'s relative `ruleDirs: [rules]` remaining valid after the move. It SHALL scaffold `.taskless/vale/` and SHALL move `.taskless/runtime-rules/` to `.taskless/runtime/rules/` and `.taskless/runtime-rule-tests/` to `.taskless/runtime/rule-tests/` without editing file contents (preserving runtime capture-rule hashes). Every scaffolded directory that would otherwise be empty SHALL contain a `.gitkeep` file so the structure is tracked reliably.
+
+#### Scenario: Mechanical move of legacy rules
+
+- **WHEN** the migration runs against a `.taskless/` containing `rules/`, `rule-tests/`, and `sgconfig.yml`
+- **THEN** those become `sg/rules/`, `sg/rule-tests/`, and `sg/sgconfig.yml`, and `sg scan --config .taskless/sg/sgconfig.yml` runs the same rules as before the move
+
+#### Scenario: Vale scaffolded, runtime moved
+
+- **WHEN** the migration runs
+- **THEN** `.taskless/vale/` is created with empty `rules/` and `rule-tests/`, and `.taskless/runtime-rules/` becomes `.taskless/runtime/rules/` with byte-identical contents
+
+### Requirement: The CLI refuses a scaffold newer than it understands unless overridden
+
+When `taskless.json`'s `version` exceeds the highest migration the installed CLI knows, the system SHALL exit with an error instructing the user to upgrade the CLI, unless `--allow-version-mismatches` is passed, in which case it SHALL proceed without applying migrations.
+
+#### Scenario: Newer scaffold blocks
+
+- **WHEN** `taskless.json` has a `version` greater than the CLI's maximum known migration
+- **THEN** the CLI exits with an error telling the user to upgrade the CLI
+
+#### Scenario: Override proceeds
+
+- **WHEN** the same condition holds and `--allow-version-mismatches` is set
+- **THEN** the CLI proceeds without applying migrations
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md
new file mode 100644
index 00000000..7eb1447f
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md
@@ -0,0 +1,23 @@
+## MODIFIED Requirements
+
+### Requirement: Runtime rules are directories recognized by metadata
+
+The CLI SHALL recognize a **runtime rule** as a directory under `.taskless/runtime/rules/<name>/`
+containing one or more ast-grep capture `*.yml` (one per capture rule) and a single `check.ts`,
+its capture rules declaring `metadata.taskless.kind: runtime`. The rule's check file SHALL be
+the `check.ts` in the rule directory. The CLI SHALL read **each capture rule's**
+`metadata.taskless.match` (`anchor` or `broad`) to select that capture rule's ast-grep
+invocation mode; capture rules within one runtime rule MAY mix modes (each is independent).
+Rule files under `.taskless/sg/rules/` SHALL continue to be treated as static ast-grep rules,
+not runtime rules. `.taskless/runtime/rule-tests/<name>/` holds `valid/` and `invalid/`
+verification fixtures and SHALL NOT be executed by `check`.
+
+#### Scenario: A runtime directory entry is a runtime rule
+
+- **WHEN** `.taskless/runtime/rules/<name>/` contains capture `*.yml` with `metadata.taskless.kind: runtime` and a `check.ts`
+- **THEN** the CLI SHALL treat it as a runtime rule with `check.ts` as its check file and route it to the runtime harness
+
+#### Scenario: Rules under sg remain static
+
+- **WHEN** a rule file lives under `.taskless/sg/rules/`
+- **THEN** the CLI SHALL treat it as a static rule and SHALL NOT route it to the runtime harness
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md
new file mode 100644
index 00000000..2c93da9a
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md
@@ -0,0 +1,98 @@
+## ADDED Requirements
+
+### Requirement: Vale runs in the static tier without reconciliation or signing
+
+The system SHALL treat Vale as a static-tier engine — always run, with no server reconciliation or signature verification. Vale's `script` checks execute in a sandbox that exposes only pure-computation modules (`text`/`math`/`fmt`) with no host access, so a Vale rule is inert data equivalent in trust to a static ast-grep rule.
+
+#### Scenario: Vale runs when anonymous
+
+- **WHEN** the CLI runs a check while logged out or anonymous
+- **THEN** Vale rules are executed the same as ast-grep static rules, with no reconcile or signing step
+
+### Requirement: Vale check executes against the committed config over the target paths
+
+The system SHALL run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit` over the resolved target paths, reading the committed config and styles as-is. The `.vale.ini` SHALL set `MinAlertLevel = suggestion` so that every finding surfaces to the client for normalization and filtering.
+
+#### Scenario: Check runs Vale via the committed config
+
+- **WHEN** the CLI runs a check and `.taskless/vale/` contains rules
+- **THEN** it invokes Vale with `--config .taskless/vale/.vale.ini` over the target paths and parses the JSON output
+
+#### Scenario: No Vale rules present
+
+- **WHEN** `.taskless/vale/rules/` is empty
+- **THEN** the CLI does not invoke Vale and produces no Vale findings
+
+### Requirement: Per-rule scoping is expressed via Vale config matchers
+
+The system SHALL express a Vale rule's scope through `.vale.ini` **matchers** — `[<glob>]` sections. Include is `rules.<name> = YES` (unioning across matching matchers); exclude is `rules.<name> = NO` (a disable takes precedence over an enable, independent of order). Duplicate `[<glob>]` matchers SHALL be treated as merged, since Vale unions them.
+
+#### Scenario: Duplicate matchers merge
+
+- **WHEN** two `[*.md]` matchers each enable a different rule
+- **THEN** both rules run on a matching `.md` file (Vale unions the matchers)
+
+#### Scenario: Include scopes a rule to a path
+
+- **WHEN** a rule is enabled only under `[marketing/**]`
+- **THEN** the rule produces findings in `marketing/` files and none in `api/` files
+
+#### Scenario: Exclude removes a subpath from an included scope
+
+- **WHEN** a rule is enabled under `[marketing/**]` and disabled under `[marketing/legacy/**]`
+- **THEN** the rule fires in `marketing/` but not in `marketing/legacy/`
+
+### Requirement: Vale findings map to the scanner-agnostic CheckResult
+
+The system SHALL map each Vale finding to a `CheckResult` with `source` `"vale"` and `ruleId` equal to the Vale check name with its `rules.` prefix stripped. Severity SHALL be normalized `error → error`, `warning → warning`, `suggestion → hint`. The system SHALL map `message` from `Message`, `note` from `Description`/`Link`, `range` from `Line`/`Span`, `matchedText` from `Match`, and `fix` from `Action` only when the action is populated.
+
+#### Scenario: Finding maps to CheckResult
+
+- **WHEN** Vale reports a finding `{Check: "rules.no-simply", Severity: "warning", Line: 3, Span: [1,7], Message: "Avoid 'simply'", Match: "simply"}` in `docs/a.md`
+- **THEN** the CLI emits a `CheckResult` with `source` `"vale"`, `ruleId` `"no-simply"`, `severity` `"warning"`, `message` `"Avoid 'simply'"`, `file` `"docs/a.md"`, and a `range` derived from line 3 / span 1–7
+
+### Requirement: A Vale check is bounded by a subprocess timeout
+
+The system SHALL bound each Vale invocation with a timeout and, on expiry, terminate the process and report the timeout rather than hanging.
+
+#### Scenario: Runaway Vale invocation is terminated
+
+- **WHEN** a Vale invocation exceeds its timeout
+- **THEN** the CLI terminates the process and reports a timeout for the Vale engine without hanging the overall check
+
+### Requirement: A missing Vale binary is reported without failing other engines
+
+When the `vale` binary cannot be found or invoked, the system SHALL report that the Vale engine is unavailable and continue running other engines, rather than aborting the entire check.
+
+#### Scenario: Vale binary absent
+
+- **WHEN** `.taskless/vale/` has rules but the `vale` binary is not installed
+- **THEN** the CLI reports the Vale engine as unavailable with an actionable message and still returns ast-grep results
+
+### Requirement: Vale rules are verified with per-rule fixture subdirectories
+
+The system SHALL verify a Vale rule from a `.taskless/vale/rule-tests/<rule>/` subdirectory containing `pass/` and `fail/` fixture documents. Because verification is one-time (not per-check), the system SHALL **generate** an ephemeral `.vale.ini` at verify time (StylesPath plus only that rule enabled) rather than requiring a committed one — the subdirectory holds fixtures only. Verification SHALL assert that every `fail/` fixture produces at least one finding for the rule and every `pass/` fixture produces none (mirroring ast-grep's `invalid`/`valid`).
+
+#### Scenario: Fail fixture triggers, pass fixture does not
+
+- **WHEN** verify runs for a rule and generates an isolating `.vale.ini` enabling only that rule
+- **THEN** verification passes because every `fail/` fixture yields a finding and every `pass/` fixture yields none
+
+#### Scenario: Verification fails when a fail fixture does not trigger
+
+- **WHEN** a `fail/` fixture for a rule produces no finding
+- **THEN** verification reports a failure for that rule
+
+### Requirement: Taskless breadcrumbs use a namespaced ignored key in the Vale config
+
+Any Taskless-owned breadcrumb the system records in `.vale.ini` SHALL use a `tskl) <name> = <value>` key. The system SHALL NOT rely on Vale enforcing these keys; they are read only by Taskless tooling, and Vale's ini parser accepts and ignores them. Each Taskless-owned matcher SHALL carry a `tskl) rule = <id>` key naming its owning rule, so tooling can locate and update the right rule's matchers even when its scoping is split across multiple (possibly duplicate) matchers.
+
+#### Scenario: Breadcrumb key is ignored by Vale
+
+- **WHEN** `.vale.ini` contains a `tskl) rule = no-simply` key
+- **THEN** Vale runs normally, ignoring the key, and Taskless tooling can read it back
+
+#### Scenario: Canonical id locates a rule's matchers
+
+- **WHEN** a rule's scoping spans several matchers each tagged `tskl) rule = no-simply`
+- **THEN** tooling can find every matcher owned by `no-simply` by its `tskl) rule` id rather than by glob
diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
new file mode 100644
index 00000000..6d4131ee
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -0,0 +1,45 @@
+## 1. Migration and directory layout
+
+- [ ] 1.1 Add `filesystem/migrations/0004-vale-engine.ts`: move `.taskless/rules/`, `rule-tests/`, and `sgconfig.yml` under `.taskless/sg/` (content-preserving; `ruleDirs: [rules]` is relative and stays valid)
+- [ ] 1.2 Extend `0004` to move `.taskless/runtime-rules/ → runtime/rules/` and `runtime-rule-tests/ → runtime/rule-tests/` byte-for-byte (runtime hashes unchanged)
+- [ ] 1.3 Extend `0004` to scaffold `.taskless/vale/` (`.vale.ini` + `rules/` + `rule-tests/`), writing a `.gitkeep` into every otherwise-empty scaffolded directory, and bump `taskless.json` `version`
+- [ ] 1.4 Register `0004` in `filesystem/migrate.ts` and confirm `runMigrations` applies it via `ensureTasklessDirectory`
+- [ ] 1.5 Add version-mismatch gating: `runMigrations` throws when `taskless.json.version > maxVersion` with an "upgrade the CLI" message, unless a global `--allow-version-mismatches` flag is set
+- [ ] 1.6 Tests: `0004` moves each tree correctly, `.gitkeep` present, runtime contents byte-identical; gating throws and the flag overrides
+
+## 2. Engine dispatch (directory model)
+
+- [ ] 2.1 Implement directory-based engine discovery: enumerate `.taskless/<engine>/` (`sg`, `vale`, `runtime`) and route rules by directory, no per-file parsing
+- [ ] 2.2 In `commands/check.ts`, call `ensureTasklessDirectory(cwd)` directly (preserving the migration trigger now that `generateSgConfig` leaves the check path)
+- [ ] 2.3 Tests: a rule under `sg/rules/` dispatches to ast-grep and one under `vale/rules/` to Vale, by directory alone
+
+## 3. Runtime discovery path
+
+- [ ] 3.1 Update `rules/runtime/discover.ts` to read `.taskless/runtime/rules/<name>/` and fixtures from `runtime/rule-tests/<name>/` (was `runtime-rules/`)
+- [ ] 3.2 Confirm rules under `.taskless/sg/rules/` are treated as static, not runtime
+- [ ] 3.3 Tests: runtime discovery at the new path; execution/reconcile/signing behavior unchanged
+
+## 4. ast-grep engine over the committed config
+
+- [ ] 4.1 Update `rules/scan.ts` to run `sg scan --config .taskless/sg/sgconfig.yml --json=stream` and remove ephemeral `sgconfig.yml` generation from the check path
+- [ ] 4.2 Update `rules/verify.ts` to run `sg test -c .taskless/sg/sgconfig.yml` over `sg/rule-tests/`
+- [ ] 4.3 Tests: scan/verify run against the committed `sg/` config; `sg` binary-not-found prints an error and exits 1
+
+## 5. Vale engine
+
+- [ ] 5.1 Add `rules/vale/binary.ts`: resolve the `vale` binary; when absent, report the Vale engine unavailable without aborting other engines
+- [ ] 5.2 Add `rules/vale/run.ts`: run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit <paths>`, bounded by a subprocess timeout that terminates and reports on expiry
+- [ ] 5.3 Map Vale JSON findings → `CheckResult`: `source: "vale"`, `ruleId` = check name with `rules.` stripped, severity `error/warning/suggestion → error/warning/hint`, and `message`/`note`/`range`/`matchedText`/`fix` per the mapping
+- [ ] 5.4 Add `rules/vale/verify.ts`: for each `vale/rule-tests/<rule>/`, generate an ephemeral `.vale.ini` enabling only that rule, run Vale over `pass/`/`fail/` fixtures, assert every `fail/` yields a finding and every `pass/` none
+- [ ] 5.5 Tests: `rules.` stripping + severity mapping; committed-config scoping respected (include union, exclude disable, duplicate matchers merge); verify pass/fail; missing-binary and timeout paths
+
+## 6. Check orchestration
+
+- [ ] 6.1 Dispatch to distinct executors by engine directory — ast-grep (`sg/`) → scanner, Vale (`vale/`) → runner, runtime (`runtime/rules/`) → harness
+- [ ] 6.2 Run engines concurrently, merge `CheckResult`s into one set, derive the exit code from merged severities, and keep an unavailable engine from aborting the others
+- [ ] 6.3 Tests: a mixed `sg`+`vale`+`runtime` corpus runs all executors and merges; with the `vale` binary absent, ast-grep results still return
+
+## 7. Quality gates
+
+- [ ] 7.1 `pnpm --filter @taskless/cli typecheck && lint && test` clean
+- [ ] 7.2 Update CLI help/onboarding text and `.taskless/.gitignore` handling for the engine-partitioned layout

From 924102730a23891e34894b0bbe93d6e020664334 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Sun, 26 Jul 2026 23:07:50 -0700
Subject: [PATCH 02/15] docs(openspec): specify engine defaulting for
 service-delivered rules
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The ingest writer hardcodes .taskless/rules, so 0004 would relayout
existing rules under sg/ while the next `rule create` wrote back into
a directory no engine dispatches from.

The API carries no engine discriminator, so an engine-less payload is
ast-grep by definition — the default is permanent, matching what the
migration does to the same rules on disk. An unrecognized engine
fails loudly instead, since filing a Vale rule under sg/ surfaces as
a broken rule rather than version skew.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDv57zHq7abms3RReSQw6q
---
 .../changes/add-vale-rule-engine/design.md    | 17 ++++++++++
 .../changes/add-vale-rule-engine/proposal.md  |  2 +-
 .../specs/cli-rule-format/spec.md             | 32 +++++++++++++++++++
 .../changes/add-vale-rule-engine/tasks.md     | 13 ++++++++
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/openspec/changes/add-vale-rule-engine/design.md b/openspec/changes/add-vale-rule-engine/design.md
index d44200bf..ff47bd8f 100644
--- a/openspec/changes/add-vale-rule-engine/design.md
+++ b/openspec/changes/add-vale-rule-engine/design.md
@@ -72,6 +72,22 @@ Vale's Tengo `script` sandbox exposes only `text`/`math`/`fmt` (verified: `os`/`
 
 `taskless.json.version` is the single format version. Migration `0004-*` is a **mechanical move**: the existing `.taskless/rules/` and `rule-tests/` are all known-ast-grep, so it moves `rules/ → sg/rules/`, `rule-tests/ → sg/rule-tests/`, and `sgconfig.yml → sg/sgconfig.yml` — and because `ruleDirs: [rules]` is _relative to the config_, it survives the move unchanged (no path edits). It then scaffolds `vale/` (`.vale.ini` + `rules/` + `rule-tests/`) and moves the runtime tier into the same shape: `runtime-rules/<name>/ → runtime/rules/<name>/` and `runtime-rule-tests/<name>/ → runtime/rule-tests/<name>/`. The runtime move is content-preserving — capture-rule bytes (and thus their reconciliation hashes) are unchanged; only `discover.ts`'s search path updates. Legacy bare rules keep working (they become `sg/` rules). **Version gating:** `runMigrations` currently returns silently when `version > maxVersion`; change it to **throw** ("upgrade the CLI") unless `--allow-version-mismatches` is passed.
 
+### D7b — Ingest defaults an engine-less payload to `sg`, permanently; unrecognized fails loudly
+
+`0004` relayouts what is already on disk, but the **ingest** path writes rules that arrive from the service, and it is a separate hazard: `writeRuleFile`/`writeRuleTestFile` (`rules/files.ts:11,26`) hardcode `.taskless/rules` and `.taskless/rule-tests`. Left untouched, the migration would move existing rules to `sg/` and the next `taskless rule create` would write straight back into `.taskless/rules/` — a directory no engine dispatches from under D1. Silent, and it reads as a vanished rule.
+
+The API offers nothing to switch on: there is no `engine`, `analysisType`, or `ruleType` field anywhere in `src/generated/api.d.ts`, and `/cli/api/rule/{ruleId}` documents `rules[].content` as "The ast-grep rule definition". The `filename` fields that do exist are **client→server** (`references[].filename` on `rule improve`; `files[].file` on reconcile) — the CLI tells the service where things live, not the reverse. So the CLI owns the destination decision, and today every delivered rule is ast-grep.
+
+Hence: **no engine identified ⇒ `sg`**, and permanently rather than for a migration window — published CLIs keep receiving engine-less payloads. This is the same judgment `0004` makes about on-disk state, so ingest and migration land a rule in the same place.
+
+**Absence and unrecognized are not the same.** An unrecognized engine means the payload is newer than the CLI; falling back to `sg` would file a Vale rule where ast-grep parses it, surfacing as a broken rule rather than version skew. Ingest errors and writes nothing, mirroring D7's scaffold-version gating. Server-side, the existing `x-taskless-cli-version` header (`api/client.ts`) lets the service avoid sending engine-typed payloads to a CLI that predates them; that half is the platform's.
+
+- **Alternative — sniff the rule body to guess its engine:** rejected; contradicts D1 (directory decides engine, no per-file parsing) and guesses where an explicit default is correct and knowable.
+
+### D7c — Reconcile is path-independent, so the relayout is transparent
+
+Reported reconcile paths are repo-relative POSIX and derived from wherever a rule was discovered (`rules/runtime/run-set.ts:57`), so they follow the moved trees automatically. The server joins reported files **by content signature, not path** — "content-based, so a moved-but-unchanged rule resolves" — and `0004` is byte-preserving. A migrated rule therefore reconciles to the same server-side rule with no coordinated release. The schema description "Delivered rule filename under `.taskless/rules/` on the client" goes stale on the platform side and is worth a follow-up there, but nothing depends on it.
+
 ### D8 — Metadata surfaces through `CheckResult`; identity from the rule name
 
 `CheckResult { source, ruleId, severity, message, note, file, range, matchedText, fix }` is the contract each engine maps into. `ruleId` is the rule's basename (ast-grep native `id`; Vale's `rules.<name>` stripped to `<name>`). Severity is engine-native, normalized on the client — Vale `error/warning/suggestion → error/warning/hint` (`info` unused; `.vale.ini` sets `MinAlertLevel = suggestion`). Vale mapping: `message←Message`, `note←Description/Link`, `range←Line+Span`, `matchedText←Match`, `fix←Action` when populated. Provenance is a generation-time server wrapper, never on disk.
@@ -84,6 +100,7 @@ Vale's Tengo `script` sandbox exposes only `text`/`math`/`fmt` (verified: `os`/`
 - **Losing auto-migration when `generateSgConfig` leaves check** → `check` calls `ensureTasklessDirectory` directly (D5).
 - **Vale DoS (runaway Tengo)** → subprocess timeout (D6).
 - **New `vale` binary dependency** → shell out like `sg`; degrade clearly if absent.
+- **Hardcoded `.taskless/rules` literals outside the ingest writer** — `rules/verify.ts:246`, `rules/files.ts:99`, `commands/check.ts:314`, `commands/rules.ts:661`, and the `detect/scan.ts:428` layout probe all name the pre-migration path. Each is the same class of defect as the ingest writer and is audited in task 2b.4; a missed one silently reads or writes outside the engine directories.
 - **Runtime realignment** → `runtime-rules/ → runtime/rules/` moves the directory only; execution (harness/reconcile/signing) and capture-rule content are untouched, so hashes are stable. Safe now because runtime rules have no live users; the downstream generator's write path updates separately.
 
 ## Migration Plan
diff --git a/openspec/changes/add-vale-rule-engine/proposal.md b/openspec/changes/add-vale-rule-engine/proposal.md
index 7d13ae7c..d01ec91f 100644
--- a/openspec/changes/add-vale-rule-engine/proposal.md
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -27,7 +27,7 @@ Taskless rules today are ast-grep only — structural AST matching that fits cod
 
 ## Impact
 
-- **CLI (`packages/cli`)**: `commands/check.ts` (per-engine execution over committed configs + migration trigger), `rules/scan.ts` (`--config` over `sg/`), `rules/verify.ts` (`sg test` over `sg/`), new `rules/vale/*` (`--config` runner, `CheckResult` mapping, fixture verify), removal of ephemeral `filesystem/sgconfig.ts` generation from the check path, new `filesystem/migrations/0004-*.ts`.
+- **CLI (`packages/cli`)**: `commands/check.ts` (per-engine execution over committed configs + migration trigger), `rules/scan.ts` (`--config` over `sg/`), `rules/verify.ts` (`sg test` over `sg/`), new `rules/vale/*` (`--config` runner, `CheckResult` mapping, fixture verify), removal of ephemeral `filesystem/sgconfig.ts` generation from the check path, new `filesystem/migrations/0004-*.ts`, and `rules/files.ts` (ingest writes into `sg/`, defaulting an engine-less service payload to ast-grep).
 - **On-disk layout**: `.taskless/sg/{sgconfig.yml, rules/, rule-tests/}` and `.taskless/vale/{.vale.ini, rules/, rule-tests/}`; legacy bare `.taskless/rules/*.yml` migrate under `sg/`. `taskless.json` scaffold version bumps.
 - **Dependency**: adds `vale` as an external binary the CLI shells out to (like `sg`).
 - **Runtime execution unchanged** (reconcile/signing/harness) — only the directory moves `runtime-rules/ → runtime/rules/` (updating `discover.ts`'s path); Vale is explicitly static. **No new `upgrade` command** — the migration ladder suffices (now with version-mismatch gating).
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
index 3b9b0aff..ce498df1 100644
--- a/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
@@ -60,6 +60,38 @@ The migration to the engine-partitioned layout SHALL move the existing `.taskles
 - **WHEN** the migration runs
 - **THEN** `.taskless/vale/` is created with empty `rules/` and `rule-tests/`, and `.taskless/runtime-rules/` becomes `.taskless/runtime/rules/` with byte-identical contents
 
+### Requirement: Service-delivered rules without an engine are written as ast-grep
+
+The rule ingest path SHALL write a service-delivered rule into the engine directory its payload identifies. The current API carries **no** engine discriminator — `/cli/api/rule/{ruleId}` returns `rules[].content` documented as an ast-grep rule definition — so a payload that does not identify an engine SHALL be written as ast-grep, under `.taskless/sg/rules/<id>.yml`, with its tests under `.taskless/sg/rule-tests/`.
+
+This default is permanent, not a migration window: published CLIs and stored payloads without an engine field continue to exist indefinitely, and the default matches what the migration does to the same rules already on disk.
+
+Absence of an engine and an **unrecognized** engine are distinct. If a payload identifies an engine the installed CLI does not know, ingest SHALL fail with an error naming the engine and instructing the user to upgrade, and SHALL NOT fall back to ast-grep.
+
+#### Scenario: Engine-less payload is filed under sg
+
+- **WHEN** a rule is delivered by the service with no engine identified in its payload
+- **THEN** it is written to `.taskless/sg/rules/<id>.yml` and its tests to `.taskless/sg/rule-tests/`, and a subsequent `check` dispatches it to ast-grep
+
+#### Scenario: Ingest and migration agree on destination
+
+- **WHEN** a rule that predates the engine-partitioned layout is migrated, and an equivalent rule is delivered fresh by the service
+- **THEN** both come to rest at the same path under `.taskless/sg/rules/`
+
+#### Scenario: Unrecognized engine fails loudly
+
+- **WHEN** a payload identifies an engine the installed CLI does not support
+- **THEN** ingest exits with an error naming the engine and directing the user to upgrade, and no rule file is written under any engine directory
+
+### Requirement: Reconciliation survives the relayout
+
+The CLI SHALL report rule files to the reconcile endpoint at their post-migration repo-relative paths. Because the server joins reported files by content signature rather than by path, moving a rule without editing it SHALL NOT change its reconciled state.
+
+#### Scenario: Moved rules reconcile unchanged
+
+- **WHEN** `check` reconciles after the migration has moved rules from `.taskless/rules/` to `.taskless/sg/rules/` and runtime rules to `.taskless/runtime/rules/`
+- **THEN** each file's signature is unchanged, the server resolves it to the same rule, and no rule is reported as new or missing
+
 ### Requirement: The CLI refuses a scaffold newer than it understands unless overridden
 
 When `taskless.json`'s `version` exceeds the highest migration the installed CLI knows, the system SHALL exit with an error instructing the user to upgrade the CLI, unless `--allow-version-mismatches` is passed, in which case it SHALL proceed without applying migrations.
diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
index 6d4131ee..39d0dd1a 100644
--- a/openspec/changes/add-vale-rule-engine/tasks.md
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -13,6 +13,19 @@
 - [ ] 2.2 In `commands/check.ts`, call `ensureTasklessDirectory(cwd)` directly (preserving the migration trigger now that `generateSgConfig` leaves the check path)
 - [ ] 2.3 Tests: a rule under `sg/rules/` dispatches to ast-grep and one under `vale/rules/` to Vale, by directory alone
 
+## 2b. Service-delivered rule ingest
+
+- [ ] 2b.1 Update `rules/files.ts` — `writeRuleFile` writes `.taskless/sg/rules/<id>.yml` and `writeRuleTestFile` writes `.taskless/sg/rule-tests/`, replacing the hardcoded `.taskless/rules` / `.taskless/rule-tests` (both call sites are `commands/rules.ts:241,245,482,486`)
+- [ ] 2b.2 Resolve the destination from an engine the payload identifies, defaulting to `sg` when the payload identifies none — permanently, since the API carries no engine discriminator today
+- [ ] 2b.3 Fail loudly on an engine the CLI does not recognize: error naming the engine, instruct upgrade, write nothing (do NOT fall back to `sg`)
+- [ ] 2b.4 Audit the remaining `.taskless/rules` string literals for the same defect — at minimum `rules/verify.ts:246`, `rules/files.ts:99`, `commands/check.ts:314`, `commands/rules.ts:661`, and the `detect/scan.ts:428` layout probe
+- [ ] 2b.5 Tests: an engine-less payload lands in `sg/rules/` and is dispatched to ast-grep by `check`; a migrated rule and a freshly delivered one come to rest at the same path; an unrecognized engine errors and writes nothing
+
+## 2c. Reconcile compatibility
+
+- [ ] 2c.1 Confirm reported reconcile paths follow the moved trees (`rules/runtime/run-set.ts:57` builds repo-relative POSIX paths from the discovered location)
+- [ ] 2c.2 Test: after `0004`, signatures are unchanged and the signature-based join resolves every moved rule — nothing reports as new or missing
+
 ## 3. Runtime discovery path
 
 - [ ] 3.1 Update `rules/runtime/discover.ts` to read `.taskless/runtime/rules/<name>/` and fixtures from `runtime/rule-tests/<name>/` (was `runtime-rules/`)

From 962baea7e6e36bd20ef323c2b517dc4dcd14a5d9 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 27 Jul 2026 12:52:06 -0700
Subject: [PATCH 03/15] docs(openspec): add engine-selection topic, path
 tolerance, binary resolution
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Three additions to the Vale change:

The engine-selection knowledge topic ships here rather than as a
follow-on, since it names the engine directories this change creates.
Written engine-shaped, kept distinct from route's authoring
destination and from trust tier — sg and vale are both static-tier,
and conflating those axes is what the platform's binary classifier
got wrong.

Legacy .taskless/rules/ stays dispatchable alongside sg/rules/, so a
producer can keep using the pre-migration layout and its rules keep
running. That decouples this release from any consumer's.

Vale's binary resolves the way findSgBinary already does — resolve the
platform package from our own module context and exec beside it, no
lifecycle script. That code exists because the upstream postinstall
hardlink breaks under pnpm dlx, leaving a placeholder text file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDv57zHq7abms3RReSQw6q
---
 .../changes/add-vale-rule-engine/design.md    | 55 ++++++++++++++-
 .../changes/add-vale-rule-engine/proposal.md  |  2 +
 .../specs/cli-help/spec.md                    | 24 +++++++
 .../specs/cli-rule-format/spec.md             | 16 +++++
 .../specs/cli-rule-routing/spec.md            | 67 +++++++++++++++++++
 .../changes/add-vale-rule-engine/tasks.md     | 19 +++++-
 6 files changed, 181 insertions(+), 2 deletions(-)
 create mode 100644 openspec/changes/add-vale-rule-engine/specs/cli-help/spec.md
 create mode 100644 openspec/changes/add-vale-rule-engine/specs/cli-rule-routing/spec.md

diff --git a/openspec/changes/add-vale-rule-engine/design.md b/openspec/changes/add-vale-rule-engine/design.md
index ff47bd8f..3ada44c1 100644
--- a/openspec/changes/add-vale-rule-engine/design.md
+++ b/openspec/changes/add-vale-rule-engine/design.md
@@ -68,6 +68,41 @@ Construction of these configs happens at **rule-authoring time** (the downstream
 
 Vale's Tengo `script` sandbox exposes only `text`/`math`/`fmt` (verified: `os`/`io`/`exec` → "module not found"), so a Vale rule can't reach the host — trust equals ast-grep static. Vale is always-run, anonymous-safe, no reconcile/signing; a subprocess timeout bounds a runaway Tengo loop. Vale is used as-is.
 
+### D6b — The CLI resolves the Vale binary itself; how it is delivered stays open
+
+Two separable concerns. **Resolution** — where the CLI looks — is settled here. **Delivery** — how the binary arrives — is deliberately not, because the resolution code is identical either way and nothing downstream depends on the answer.
+
+Resolution follows the pattern **already in production for ast-grep**: `findSgBinary()` (`rules/scan.ts:38-61`) resolves the platform package from our own module context with `createRequire(import.meta.url).resolve('<pkg>/package.json')`, execs the binary beside it, and falls back to `PATH`. Vale gets the same shape; the two should share one helper rather than diverge.
+
+That code exists because the upstream postinstall already failed here: its comment records that `@ast-grep/cli`'s hardlink step breaks under `pnpm dlx`'s strict dependency isolation, **leaving a placeholder text file where the binary should be**. Resolving the platform package ourselves sidesteps the lifecycle script entirely — nothing to approve, nothing a package-manager policy can block, nothing to fail silently.
+
+Order: **platform package → `PATH` → a clear "Vale engine unavailable" report** that leaves the other engines running (D6).
+
+Delivery is **per-platform npm packages carrying the binary in the tarball**, declared as `optionalDependencies` filtered by `os`/`cpu`, so exactly one matching package installs (verified: only `@ast-grep+cli-darwin-arm64` is present in this repo's store, shipping `ast-grep` at mode `-rwxr-xr-x` — the executable bit survives the npm tarball). Vale is MIT; redistribution needs attribution and nothing more.
+
+Note this is ast-grep's _packaging_ without ast-grep's _installation_: upstream ships the binary in a platform package **and** hardlinks it into place via postinstall, because it exposes `bin: {sg, ast-grep}` for humans. We never need that copy — we exec Vale as a subprocess with an explicit path — so the packages need no `bin`, no scripts, and no install-time step of any kind.
+
+Vale is load-bearing, and that is what settles it. An engine the product depends on cannot have its availability decided by install-time network access, an upstream project's release hosting, or a policy set in the consumer's repository.
+
+The decisive comparison is **binary-in-tarball vs. download-at-postinstall**, not who publishes it. Against the only existing npm distribution, `@vvago/vale` (maintainer `zeropaper`, not the Vale project), which ships a `postinstall` that fetches the release archive (deps `tar`/`unzipper`/`rimraf`):
+
+| Property                                 | postinstall-download | binary-in-tarball |
+| ---------------------------------------- | -------------------- | ----------------- |
+| Binary covered by an npm integrity hash  | no                   | yes               |
+| Pinned by the consumer's lockfile        | no                   | yes               |
+| Resolves offline / via a registry mirror | no                   | yes               |
+| Requires lifecycle scripts to be enabled | yes                  | no                |
+
+The last row is not a preference. pnpm 10 does not run dependency lifecycle scripts without an `onlyBuiltDependencies` allowlist, and that script would execute during a **consumer's** install under a policy we cannot set — allowlisting it here changes nothing for them. `npx @taskless/cli` under npm would work; a team adding the CLI as a devDependency under pnpm would get a silently binary-less prose engine. The same objection would stand if the Vale project published this package itself.
+
+- **Alternative — depend on `@vvago/vale`:** rejected on mechanism per above, and secondarily on putting a third party in the critical path of a load-bearing engine.
+- **Alternative — require Vale on `PATH` only:** rejected once Vale is load-bearing; it makes the prose engine work only where someone independently installed it, which is a worse outcome than the publish pipeline it avoids. `PATH` stays as a fallback, not the delivery.
+- **Alternative — download at runtime into `node_modules`:** rejected; the canonical invocation is `npx @taskless/cli` (`util/invocation.ts:7`), so the install is ephemeral and the binary would be re-fetched on essentially every run. It is also unsafe generally — pnpm's store is content-addressable and hard-linked, so writing into `node_modules` can corrupt unrelated projects sharing it, and it breaks under read-only installs and in Docker layers.
+
+If a download is ever wanted despite this, the only acceptable form is a **user cache directory** (surviving `npx`, never `node_modules`) with a pinned version and a verified checksum.
+
+**Cost, stated plainly:** roughly seven packages, each a binary plus a `package.json` declaring `os`/`cpu` and containing no code, produced by a CI job that pulls Vale's release assets and republishes them under our scope. The recurring cost is a version bump per upstream Vale release.
+
 ### D7 — One scaffold version in `taskless.json`; migration `0004` reorganizes into `sg/` + `vale/`
 
 `taskless.json.version` is the single format version. Migration `0004-*` is a **mechanical move**: the existing `.taskless/rules/` and `rule-tests/` are all known-ast-grep, so it moves `rules/ → sg/rules/`, `rule-tests/ → sg/rule-tests/`, and `sgconfig.yml → sg/sgconfig.yml` — and because `ruleDirs: [rules]` is _relative to the config_, it survives the move unchanged (no path edits). It then scaffolds `vale/` (`.vale.ini` + `rules/` + `rule-tests/`) and moves the runtime tier into the same shape: `runtime-rules/<name>/ → runtime/rules/<name>/` and `runtime-rule-tests/<name>/ → runtime/rule-tests/<name>/`. The runtime move is content-preserving — capture-rule bytes (and thus their reconciliation hashes) are unchanged; only `discover.ts`'s search path updates. Legacy bare rules keep working (they become `sg/` rules). **Version gating:** `runMigrations` currently returns silently when `version > maxVersion`; change it to **throw** ("upgrade the CLI") unless `--allow-version-mismatches` is passed.
@@ -92,6 +127,22 @@ Reported reconcile paths are repo-relative POSIX and derived from wherever a rul
 
 `CheckResult { source, ruleId, severity, message, note, file, range, matchedText, fix }` is the contract each engine maps into. `ruleId` is the rule's basename (ast-grep native `id`; Vale's `rules.<name>` stripped to `<name>`). Severity is engine-native, normalized on the client — Vale `error/warning/suggestion → error/warning/hint` (`info` unused; `.vale.ini` sets `MinAlertLevel = suggestion`). Vale mapping: `message←Message`, `note←Description/Link`, `range←Line+Span`, `matchedText←Match`, `fix←Action` when populated. Provenance is a generation-time server wrapper, never on disk.
 
+### D9 — The engine-selection topic ships with the engines it names
+
+Making the CLI multi-engine creates a decision that did not previously exist: **which engine enforces a given rule**. Today that knowledge lives only in the platform's generator, as a binary `static | runtime` classifier prompt that predates Vale; no `help/*.txt` recipe states it. Adding a third engine without also stating the choice would leave every local authoring path assuming ast-grep.
+
+The topic therefore belongs to this change rather than a follow-on. It names `sg`/`vale`/`runtime` — the directories D1 introduces — so shipping it separately would either describe engines that do not yet exist or leave a window where the layout is engine-partitioned and the guidance is not. Task 7.2 already puts help and onboarding text in this change's scope; this is that work carried to its conclusion.
+
+Three constraints shape the text, each from a real failure mode:
+
+- **Engine selection is not authoring destination.** `route` decides `existing`/`static`/`remote` and is a pre-service, local decision. This topic decides only the engine. Locally they compose (route, then engine); the service runs only the second half. A sentence that would only make sense to an agent standing in a user's repo belongs in `route`.
+- **Engine selection is not trust tier.** `sg` and `vale` are both static-tier; only `runtime` involves login, reconcile, and signing. Conflating the two axes is precisely what the platform's binary prompt got wrong, and it is why "static vs runtime" cannot simply be renamed.
+- **The ambiguity default must name an available engine.** Stated as that property rather than as a bare fact about `sg`. With both binaries shipped as dependencies (D6b), `sg` and `vale` are normally both available locally, and the property is satisfied rather than strained — but it still binds on an unsupported architecture or a blocked install, where the `PATH` fallback may find nothing. On the service the same conclusion follows from a different cause: `sg` is the only ungated route. Writing the rule as a property keeps one sentence correct across all three situations.
+
+Exporting the topic through `@taskless/cli/prompts` is deliberately **not** coupled to this change: the export mechanism is a separate change, and the topic file is useful to the local `help` flow with or without it. Whichever lands second adds the one-line `TOPICS` entry.
+
+- **Alternative — a separate follow-on change for the topic:** rejected; it either ships guidance for engines that do not exist yet, or leaves a release where `check` dispatches three engines while every recipe still assumes ast-grep.
+
 ## Risks / Trade-offs
 
 - **Committed configs are maintained artifacts** — the `.vale.ini` scoping sections and native `files`/`ignores` must be authored/updated when rules change. Construction doesn't vanish; it moves to rule-authoring time (mostly the downstream generator). Trade: check-time simplicity + transparent, versioned configs for author-time maintenance.
@@ -109,6 +160,8 @@ Reported reconcile paths are repo-relative POSIX and derived from wherever a rul
 
 ## Open Questions
 
-_None outstanding._ The three revisited items are resolved: Vale rule-tests use per-rule `pass/`/`fail/` subdirectories with a verify-time-**generated** isolating `.vale.ini` (mirroring ast-grep's valid/invalid); Taskless breadcrumbs in `.vale.ini` use the `tskl) <name> = <value>` namespace (all namespaced key syntaxes verified tolerated); and the runtime tier is **realigned** to `runtime/` in this change (content-preserving move).
+**Vale binary packaging** — the per-platform packages (D6b) are their own release-engineering task: which architectures to cover beyond the ast-grep set, and the CI job that mirrors upstream Vale releases. It does not block the engine work; resolution falls back to `PATH` while the packages are being stood up, and the missing-binary path degrades cleanly throughout.
+
+The three revisited items are resolved: Vale rule-tests use per-rule `pass/`/`fail/` subdirectories with a verify-time-**generated** isolating `.vale.ini` (mirroring ast-grep's valid/invalid); Taskless breadcrumbs in `.vale.ini` use the `tskl) <name> = <value>` namespace (all namespaced key syntaxes verified tolerated); and the runtime tier is **realigned** to `runtime/` in this change (content-preserving move).
 
 All hard mechanisms are verified against `vale 3.15.1` / `sg 0.41.0`: native-config scoping, `.vale.ini` enable/disable composition, StyleName requirement, `--config` scale path, ignored `tskl)` keys, Vale sandbox.
diff --git a/openspec/changes/add-vale-rule-engine/proposal.md b/openspec/changes/add-vale-rule-engine/proposal.md
index d01ec91f..ca15c7a2 100644
--- a/openspec/changes/add-vale-rule-engine/proposal.md
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -24,6 +24,8 @@ Taskless rules today are ast-grep only — structural AST matching that fits cod
 
 - `cli-check`: Check runs each engine's native tool with its committed config (`sg scan --config sg/…`, `vale --config vale/…`) over the resolved paths, concurrently, and merges results; verify runs `sg test` (ast-grep) and a Vale fixture runner. The ephemeral `sgconfig.yml` generation is removed from the check path (configs are committed under `sg/`), and `check` calls `ensureTasklessDirectory` directly to preserve the migration trigger.
 - `cli-runtime-rule-execution`: Runtime rules are discovered under `.taskless/runtime/rules/<name>/` (and fixtures under `runtime/rule-tests/<name>/`) instead of `runtime-rules/` — a directory move only; execution semantics are unchanged.
+- `cli-rule-routing`: Gains an **engine-selection** topic — which engine (`sg`/`vale`/`runtime`) can enforce a requested rule — as a distinct axis from `route`'s authoring destination and from trust tier. Ambiguity defaults to an engine known to be available.
+- `cli-help`: The engine-selection topic is registered in the help index, and the `route`/`static` recipes cross-reference it so the local flow applies the same engine test the service does.
 
 ## Impact
 
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-help/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-help/spec.md
new file mode 100644
index 00000000..0d03f407
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-help/spec.md
@@ -0,0 +1,24 @@
+## ADDED Requirements
+
+### Requirement: The engine-selection topic is registered in the help system
+
+The help system SHALL register the engine-selection recipe as an embedded help topic, retrievable via `taskless help <topic>` and listed in the help index, consistent with the existing topic embedding and format requirements.
+
+#### Scenario: Engine-selection topic resolves
+
+- **WHEN** `taskless help` is run for the engine-selection topic
+- **THEN** the recipe text SHALL be returned and an unknown-topic error SHALL NOT be raised
+
+#### Scenario: Engine-selection topic appears in the index
+
+- **WHEN** `taskless help` is run with no arguments
+- **THEN** the topic index SHALL include the engine-selection topic so an agent can discover it
+
+### Requirement: Routing recipes reference engine selection
+
+The `route` and `static` recipes SHALL reference the engine-selection topic so an agent following the local authoring flow applies the same engine test the service applies, rather than assuming ast-grep.
+
+#### Scenario: Local flow reaches engine selection
+
+- **WHEN** an agent follows `route` to a destination that authors a Taskless rule
+- **THEN** the recipe directs it to the engine-selection topic before the rule is authored
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
index ce498df1..2a8b4933 100644
--- a/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
@@ -83,6 +83,22 @@ Absence of an engine and an **unrecognized** engine are distinct. If a payload i
 - **WHEN** a payload identifies an engine the installed CLI does not support
 - **THEN** ingest exits with an error naming the engine and directing the user to upgrade, and no rule file is written under any engine directory
 
+### Requirement: Both the legacy and engine-partitioned layouts are readable
+
+The CLI SHALL dispatch rules found at the legacy `.taskless/rules/` path as ast-grep, in addition to `.taskless/sg/rules/`, so a checkout that has not yet been migrated — or a rule delivered by a service that still names the legacy location — is executed rather than ignored.
+
+This tolerance is what decouples the CLI's release from any consumer's: a producer may continue to use the pre-migration layout indefinitely and its rules keep running.
+
+#### Scenario: Unmigrated checkout still runs its rules
+
+- **WHEN** `check` runs against a `.taskless/` containing `rules/` but no `sg/`
+- **THEN** those rules are dispatched to ast-grep and reported, not silently skipped
+
+#### Scenario: Both layouts present
+
+- **WHEN** rules exist under both `.taskless/rules/` and `.taskless/sg/rules/`
+- **THEN** both are dispatched to ast-grep and their findings merged, with no duplicate reporting of the same rule
+
 ### Requirement: Reconciliation survives the relayout
 
 The CLI SHALL report rule files to the reconcile endpoint at their post-migration repo-relative paths. Because the server joins reported files by content signature rather than by path, moving a rule without editing it SHALL NOT change its reconciled state.
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-rule-routing/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-rule-routing/spec.md
new file mode 100644
index 00000000..d16df5bb
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-rule-routing/spec.md
@@ -0,0 +1,67 @@
+## ADDED Requirements
+
+### Requirement: An engine-selection topic states which engine can enforce a rule
+
+The CLI SHALL provide a knowledge topic that decides, for a requested rule, **which engine can enforce it** — `sg`, `vale`, or `runtime` — valued as the engine's on-disk directory name. The topic SHALL define each engine by the information a rule fundamentally needs:
+
+- **`sg`** — expressible as a pattern over a single file's syntax tree, including correlation between constructs within that same file via relational operators.
+- **`vale`** — the target is prose or markup content rather than code structure.
+- **`runtime`** — needs information no single file's syntax tree contains: cross-file consistency, import or call graph, comparison against a non-code file, file metadata, or values requiring normalization a static pattern cannot express.
+
+The topic SHALL instruct that the decision follow from what the rule fundamentally needs rather than how the request was phrased, and that the reasoning be stated before the engine is named.
+
+#### Scenario: Engine named for a single-file structural rule
+
+- **WHEN** the topic is applied to a request expressible as a pattern over one file's syntax tree
+- **THEN** it selects `sg`
+
+#### Scenario: Engine named for a prose rule
+
+- **WHEN** the topic is applied to a request targeting prose or markup content
+- **THEN** it selects `vale`
+
+#### Scenario: Engine named for a cross-file rule
+
+- **WHEN** the topic is applied to a request requiring information beyond a single file's syntax tree
+- **THEN** it selects `runtime`
+
+### Requirement: Engine selection is a separate axis from authoring destination
+
+The engine-selection topic SHALL decide only which engine enforces a rule, and SHALL NOT decide where the rule is authored — that remains the `route` topic's concern. Locally the two compose, `route` first and engine selection second.
+
+The topic SHALL NOT describe login, reconciliation, or signing as inputs to the engine choice: `sg` and `vale` are both static-tier, and only `runtime` carries those concerns, so trust tier is a distinct axis from engine selection.
+
+#### Scenario: Topic stays clear of authoring destination
+
+- **WHEN** the engine-selection topic is applied
+- **THEN** it names an engine and does not select among `existing`, `static`, or `remote` authoring destinations
+
+#### Scenario: Trust tier is not an engine-selection input
+
+- **WHEN** the topic distinguishes `sg` from `vale`
+- **THEN** it does so on the prose-versus-structure axis, not on any auth, reconcile, or signing property, since both are static-tier
+
+### Requirement: Available code context outranks the phrasing of the request
+
+Where code or diff context is available, the engine-selection topic SHALL weigh the concrete syntactic form present in the repository above the wording of the request, since the same request routes differently depending on the form the code actually takes.
+
+#### Scenario: Concrete form changes the engine
+
+- **WHEN** a rule is statically correlatable in the form the repository actually contains
+- **THEN** the topic selects `sg`
+- **AND WHEN** the equivalent rule requires normalizing a captured value to match a declaration elsewhere
+- **THEN** it selects `runtime`, despite an identically phrased request
+
+### Requirement: Ambiguity defaults to an engine known to be available
+
+When no engine is clearly indicated, the engine-selection topic SHALL default to `sg` and record why the call was close. The topic SHALL state this as a property — the default names an engine known to be available — rather than as a bare fact about `sg`, so it stays correct wherever an engine can be unavailable or a route withheld.
+
+#### Scenario: Ambiguous request defaults to sg
+
+- **WHEN** the available context does not disambiguate which engine can enforce a rule
+- **THEN** the topic selects `sg` and states the reasoning that made the call close
+
+#### Scenario: The default is never an unavailable engine
+
+- **WHEN** an engine is unavailable in the current environment, such as the Vale binary being absent
+- **THEN** the ambiguity default SHALL NOT name it
diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
index 39d0dd1a..c89da334 100644
--- a/openspec/changes/add-vale-rule-engine/tasks.md
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -12,6 +12,8 @@
 - [ ] 2.1 Implement directory-based engine discovery: enumerate `.taskless/<engine>/` (`sg`, `vale`, `runtime`) and route rules by directory, no per-file parsing
 - [ ] 2.2 In `commands/check.ts`, call `ensureTasklessDirectory(cwd)` directly (preserving the migration trigger now that `generateSgConfig` leaves the check path)
 - [ ] 2.3 Tests: a rule under `sg/rules/` dispatches to ast-grep and one under `vale/rules/` to Vale, by directory alone
+- [ ] 2.4 Treat the legacy `.taskless/rules/` path as an ast-grep source alongside `sg/rules/`, so an unmigrated checkout still runs; de-duplicate when both are present
+- [ ] 2.5 Tests: a `.taskless/` with only `rules/` dispatches to ast-grep; with both `rules/` and `sg/rules/`, findings merge without duplicates
 
 ## 2b. Service-delivered rule ingest
 
@@ -40,7 +42,11 @@
 
 ## 5. Vale engine
 
-- [ ] 5.1 Add `rules/vale/binary.ts`: resolve the `vale` binary; when absent, report the Vale engine unavailable without aborting other engines
+- [ ] 5.1 Extract the platform-binary resolution in `findSgBinary()` (`rules/scan.ts:38-61`) into a shared helper — resolve `<pkg>/package.json` via `createRequire(import.meta.url)`, exec the binary beside it, fall back to `PATH` — and use it for both `sg` and `vale`. When nothing resolves, report the Vale engine unavailable without aborting other engines (D6b)
+- [ ] 5.1b Publish per-platform Vale binary packages under the Taskless scope: binary in the tarball, `os`/`cpu` declared, **no `bin`, no code, no scripts** (we exec by path, so nothing needs hardlinking into place). Add them to `packages/cli` as `optionalDependencies`. Include Vale's MIT attribution. Do NOT depend on a download-at-postinstall package: the script runs under the consumer's package-manager policy, and pnpm 10 blocks it by default, yielding no binary and no error
+- [ ] 5.1c CI job to mirror upstream Vale releases into those packages; decide the architecture set (ast-grep's seven is the starting point) and pin the Vale version the CLI expects
+- [ ] 5.1d Handle musl: `findSgBinary()` maps every Linux to `-gnu`, so Alpine falls through to `PATH` today. Detect libc for the Vale lookup (upstream ast-grep uses `detect-libc`) and decide whether to publish a musl variant or leave the `PATH` fallback deliberately
+- [ ] 5.1e Confirm the Vite build externalizes the platform packages rather than bundling them, and that `createRequire(import.meta.url)` resolves correctly from `dist/` — the same context `findSgBinary()` already relies on
 - [ ] 5.2 Add `rules/vale/run.ts`: run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit <paths>`, bounded by a subprocess timeout that terminates and reports on expiry
 - [ ] 5.3 Map Vale JSON findings → `CheckResult`: `source: "vale"`, `ruleId` = check name with `rules.` stripped, severity `error/warning/suggestion → error/warning/hint`, and `message`/`note`/`range`/`matchedText`/`fix` per the mapping
 - [ ] 5.4 Add `rules/vale/verify.ts`: for each `vale/rule-tests/<rule>/`, generate an ephemeral `.vale.ini` enabling only that rule, run Vale over `pass/`/`fail/` fixtures, assert every `fail/` yields a finding and every `pass/` none
@@ -52,6 +58,17 @@
 - [ ] 6.2 Run engines concurrently, merge `CheckResult`s into one set, derive the exit code from merged severities, and keep an unavailable engine from aborting the others
 - [ ] 6.3 Tests: a mixed `sg`+`vale`+`runtime` corpus runs all executors and merges; with the `vale` binary absent, ast-grep results still return
 
+## 6b. Engine-selection knowledge topic
+
+- [ ] 6b.1 Author `packages/cli/src/help/<engine-selection>.txt` from the seed prose in `tmp/SEED-engine-selection-prose.md`: the three engine definitions (`sg` in-file syntax tree incl. relational correlation, `vale` prose/markup, `runtime` cross-file/graph/metadata/normalization), the reason-before-answer procedure, and the worked example table
+- [ ] 6b.2 State the ambiguity default as a property — the default names an engine known to be available — and note that `@ast-grep/cli` ships as a dependency while the Vale binary is external, so `sg` satisfies it locally
+- [ ] 6b.3 Carry the three boundary cases: prose-about-code vs structure, Vale is per-document (cross-document prose consistency is `runtime`), and `sg`/`vale` are both static-tier so trust tier is a separate axis
+- [ ] 6b.4 Keep the topic scoped to engine choice — no authoring-destination guidance, no tool-calling mechanics from the seed's source prompt
+- [ ] 6b.5 Register the topic in the help index and add `route`/`static` cross-references to it
+- [ ] 6b.6 Tests: the topic resolves via `taskless help` and appears in the index; the topic file matches the established recipe header/format convention
+
+> Export via `@taskless/cli/prompts` is not part of this change (see D9). Whichever of this change and `export-knowledge-prompts` lands second adds the one-line `TOPICS` entry.
+
 ## 7. Quality gates
 
 - [ ] 7.1 `pnpm --filter @taskless/cli typecheck && lint && test` clean

From 7165b896dca0aee2b2a534f9e1708568e8ebfac8 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 27 Jul 2026 17:09:28 -0700
Subject: [PATCH 04/15] docs(openspec): link add-vale-rule-engine to OSS-21

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDv57zHq7abms3RReSQw6q
---
 openspec/changes/add-vale-rule-engine/proposal.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/openspec/changes/add-vale-rule-engine/proposal.md b/openspec/changes/add-vale-rule-engine/proposal.md
index ca15c7a2..eb81cb56 100644
--- a/openspec/changes/add-vale-rule-engine/proposal.md
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -34,3 +34,5 @@ Taskless rules today are ast-grep only — structural AST matching that fits cod
 - **Dependency**: adds `vale` as an external binary the CLI shells out to (like `sg`).
 - **Runtime execution unchanged** (reconcile/signing/harness) — only the directory moves `runtime-rules/ → runtime/rules/` (updating `discover.ts`'s path); Vale is explicitly static. **No new `upgrade` command** — the migration ladder suffices (now with version-mismatch gating).
 - **Downstream (separate change, taskless repo)**: generating Vale rules + authoring the committed `.vale.ini`/`sgconfig.yml`, the verification-sandbox path, and prose-request classification build on this foundation.
+
+**Tracking:** OSS-21

From f5ef9c37a947350482e17bd03b5c5667bb2c5159 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Tue, 28 Jul 2026 12:08:07 -0700
Subject: [PATCH 05/15] docs(openspec): scope add-vale-rule-engine to the Vale
 engine
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

An OpenSpec change has to land complete in one PR — the archive gate
requires a tip PR to leave openspec/changes/ empty — and this one had
grown to 44 tasks across ten groups. The layout half moved to
partition-rules-by-engine.

What stays is the engine and the knowledge about it: the Vale runner
and its scoping model, fixture verify, findings mapping, concurrent
multi-engine orchestration, and the engine-selection topic. 22 tasks.

The topic stays here rather than with the layout because it names
sg/vale/runtime as things an agent can actually choose between, which
is only true once Vale executes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDv57zHq7abms3RReSQw6q
---
 .../changes/add-vale-rule-engine/design.md    |  81 +++----------
 .../changes/add-vale-rule-engine/proposal.md  |  37 +++---
 .../specs/cli-check/spec.md                   |  35 ------
 .../specs/cli-rule-format/spec.md             | 113 ------------------
 .../specs/cli-runtime-rule-execution/spec.md  |  23 ----
 .../changes/add-vale-rule-engine/tasks.md     |  91 +++++---------
 6 files changed, 62 insertions(+), 318 deletions(-)
 delete mode 100644 openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md

diff --git a/openspec/changes/add-vale-rule-engine/design.md b/openspec/changes/add-vale-rule-engine/design.md
index 3ada44c1..a8870db5 100644
--- a/openspec/changes/add-vale-rule-engine/design.md
+++ b/openspec/changes/add-vale-rule-engine/design.md
@@ -1,61 +1,34 @@
 ## Context
 
-Taskless rules run today through one engine, ast-grep: `commands/check.ts` writes an ephemeral `sgconfig.yml` (`ruleDirs: [rules]`) and runs `sg scan --config … --json=stream`; rules live as bare ast-grep YAML at `.taskless/rules/*.yml`. A separate **runtime** tier (`runtime-rules/<name>/`: capture YAML + signed `check.ts`) runs only after an authenticated server reconcile. A `.taskless/` migration system exists (`filesystem/migrate.ts`→`runMigrations`, keyed on `taskless.json`'s `version`, invoked via `ensureTasklessDirectory`).
+`partition-rules-by-engine` established the layout this change executes: `.taskless/<engine>/{config, rules/, rule-tests/}`, dispatch by directory rather than by parsing files, each engine's committed native config as the source of truth, and a scaffolded but inert `vale/`. Read that change's design for the layout, migration `0004`, ingest defaulting, and legacy-path tolerance — none of it is restated here.
 
-We add **Vale**, a markup-aware prose linter, because ast-grep can't lint prose. The design was derived empirically against `vale 3.15.1` and `sg 0.41.0`; the facts that shaped it:
+What remains is the engine itself. The design was derived empirically against `vale 3.15.1` and `sg 0.41.0`; the facts that shaped it:
 
-- **Each tool already has a native, committed config that expresses everything we need** — ast-grep: a rule's native `files`/`ignores` scope it, `metadata` holds extra data; Vale: a `.vale.ini` **matcher** (a `[<glob>]` section) scopes rules by path glob and, because Vale accepts and silently ignores unknown keys, holds arbitrary Taskless data _within that matcher_. So Taskless needs **no separate metadata/sidecar layer** — each engine's own config is the source of truth.
 - **Vale `.vale.ini` scoping composes cleanly and predictably** (all verified): `[<glob>] Style.Rule = YES` enables a rule for a path (no `BasedOnStyles` needed); overlapping enables **union**; `[<glob>] Style.Rule = NO` **disables** and wins over an enable, order-independent; globs support brace alternation with slashes (`[{marketing/**,docs/**}]`) and whole-section negation (`[!x]`). So arbitrary per-rule include/exclude lives in the `.ini` itself.
 - **Vale requires a StyleName directory level** (`StylesPath/<Style>/<rule>.yml`) — a flat rule errors `E100 style does not exist`; a `rules/` dir _is_ that StyleName.
-- **Both tools read rules from disk via `--config` with no size ceiling** — so committed per-engine configs scale to hundreds of rules where `--inline-rules` (`ARG_MAX`) and `sg --rule` (single file) can't.
-
-The result: engines are partitioned **by top-level directory**, each holding its tool's native, **committed** config + rules + tests. Check is pure execution — no sidecars, no materialization, no generation, nothing to cache.
+- **Vale accepts and silently ignores unknown ini keys**, so Taskless breadcrumbs ride inside the matcher that owns them rather than in a sidecar.
+- **Vale's Tengo `script` sandbox exposes only `text`/`math`/`fmt`** (`os`/`io`/`exec` → "module not found"), so a Vale rule cannot reach the host — trust equals ast-grep static.
 
 ## Goals / Non-Goals
 
-**Goals:** add Vale as a second **static-tier** engine; store each engine's rules + config in its own directory using the tool's native format; make `check`/`verify` pure execution over committed configs (zero construction); ride the existing migration ladder.
-
-**Non-Goals:** generating Vale rules and authoring the committed configs — split across **two downstream changes**: a CLI-side change (the `taskless/skills` rule-authoring commands that _write_ `.vale.ini`/`sgconfig.yml`) and a `taskless`-repo change (server rule generation + prose-request classification). Also out of scope: changing runtime _execution_ (harness/reconcile/signing are untouched — only the runtime directory moves); restricting Vale's feature set (Tengo `script` is sandboxed — D7).
-
-## Directory layout (target)
+**Goals:** run Vale as a second static-tier engine over its committed config; map its findings into the shared `CheckResult`; verify Vale rules from fixtures; run all engines concurrently and merge; state which engine can enforce a given rule.
 
-```
-.taskless/
-  sg/       sgconfig.yml            rules/<rule>.yml            rule-tests/<name>.yml
-  vale/     .vale.ini               rules/<rule>.yml            rule-tests/<name>.yml
-  runtime/  rules/<rule>/{<capture>.yml, check.ts}   rule-tests/<rule>/<fixture>/
-  taskless.json
-```
-
-This change implements all three: `sg/`, `vale/`, and the `runtime/` realignment (safe now — no one uses runtime rules yet, and the move is content-preserving so runtime hashes are unaffected). Every scaffolded directory (each engine dir and its `rules/`/`rule-tests/`) carries a `.gitkeep` so the structure is tracked reliably even when empty.
+**Non-Goals:** the engine-partitioned layout, migration, ingest defaulting, and legacy tolerance — all delivered by `partition-rules-by-engine`. Also excluded: generating Vale rules and authoring the committed `.vale.ini`, and restricting Vale's feature set.
 
 ## Decisions
 
-### D1 — Engines partition by top-level directory; each holds a native, committed config
-
-`.taskless/<engine>/` contains `{config, rules/, rule-tests/}` in that engine's native format. Directory = engine (dispatch is which dir, no parsing); the config is **committed and persisted**, not generated. This is what makes `check` construction-free and sidesteps cross-parse (Vale's StylesPath never sees `.sg.yml`).
-
-- **Why not co-located rules + a sidecar/envelope** (earlier designs): every co-located approach forced either an in-file marker Vale rejects (`E201`) or a generated config + materialization at check time. Per-engine native configs delete that entire layer — the tool's own config already carries scoping and (via ignored keys / `metadata` / comments) any Taskless breadcrumbs.
-
-### D2 — The native config is the source of truth; no sidecars, no generation at check time
-
-- **ast-grep** (`sg/`): `sgconfig.yml` (`ruleDirs: [rules]`, `testConfigs: [{testDir: rule-tests}]`) + native rule files whose `files`/`ignores` scope them and `metadata` holds Taskless data.
-- **Vale** (`vale/`): `.vale.ini` (`StylesPath = .`, `BasedOnStyles = rules`, per-rule scoping sections, plus Taskless breadcrumbs as `tskl) <name> = <value>` keys — Vale's ini parser accepts and silently drops them, verified) + native styles under `rules/` (the StyleName). Vale check names are `rules.<name>`, normalized to `ruleId = <name>`. ast-grep, by contrast, carries any Taskless data in its native `metadata` field.
-
-Construction of these configs happens at **rule-authoring time** (the downstream generator, or a human editing a committed config) — never at check time.
-
-### D3 — Scoping is native per engine
+### D1 — Scoping is native per engine
 
 - **ast-grep** — a rule's `files` (include) / `ignores` (exclude), verified to path-scope an inline/config rule.
 - **Vale** — each `.vale.ini` **matcher** (a `[<glob>]` section) scopes by path and lists which rules run there: include = `rules.<name> = YES` (enables union across matchers), exclude = `rules.<name> = NO` (disable wins). Deterministic and order-independent (verified), so generation is a straight emit of YES/NO matchers — no cascade to reason about.
 
 **Repeat matchers are allowed and merge** — Vale unions duplicate `[<glob>]` headers (verified: `[*.md]` twice fired both rules). Because one rule's scoping can therefore be scattered across several matchers, each Taskless-owned matcher carries a `tskl) rule = <id>` breadcrumb naming its owning rule — a **canonical id** so tooling can find and update the right rule's matchers later rather than guessing from globs.
 
-### D4 — Vale layout maps to StylesPath via the `rules/` StyleName
+### D2 — Vale layout maps to StylesPath via the `rules/` StyleName
 
 `.vale.ini` lives at `.taskless/vale/.vale.ini` with `StylesPath = .`, so `.taskless/vale/rules/` is the required StyleName directory (`BasedOnStyles = rules`). Styles are pure-native Vale files; the `rules.` check-name prefix is stripped for `ruleId`. (Flat rules without the StyleName level fail — verified.)
 
-### D5 — Check and verify are pure execution over committed configs
+### D3 — Check and verify are pure execution over committed configs
 
 `check` runs each engine's tool with its committed config over the resolved paths, concurrently, and merges `CheckResult`s — **no materialization, no sidecar reads, no config generation, nothing to cache**:
 
@@ -64,13 +37,13 @@ Construction of these configs happens at **rule-authoring time** (the downstream
 
 `verify` likewise runs native runners: `sg test -c .taskless/sg/sgconfig.yml` (ast-grep's native tests, matched by rule `id`), and a Vale **fixture runner** over `.taskless/vale/rule-tests/<rule>/` — a per-rule subdirectory of `pass/` and `fail/` fixture documents. Because verify is one-time (not per-check), the isolating `.vale.ini` (StylesPath + only that rule enabled) is **generated** at verify time rather than committed; conceptually this mirrors ast-grep's `valid`/`invalid` (pass/fail), asserting every `fail/` fixture yields a finding and every `pass/` fixture none. Because `generateSgConfig` no longer runs on the check path, `check` calls `ensureTasklessDirectory` directly to preserve the migration trigger.
 
-### D6 — Vale runs in the static tier, unmodified, bounded by a subprocess timeout
+### D4 — Vale runs in the static tier, unmodified, bounded by a subprocess timeout
 
 Vale's Tengo `script` sandbox exposes only `text`/`math`/`fmt` (verified: `os`/`io`/`exec` → "module not found"), so a Vale rule can't reach the host — trust equals ast-grep static. Vale is always-run, anonymous-safe, no reconcile/signing; a subprocess timeout bounds a runaway Tengo loop. Vale is used as-is.
 
-### D6b — The CLI resolves the Vale binary itself; how it is delivered stays open
+### D5 — The CLI resolves the Vale binary itself; delivery belongs to another change
 
-Two separable concerns. **Resolution** — where the CLI looks — is settled here. **Delivery** — how the binary arrives — is deliberately not, because the resolution code is identical either way and nothing downstream depends on the answer.
+Two separable concerns. **Resolution** — where the CLI looks — is settled here. **Delivery** — how the binary arrives — is `add-vale-binary-packages`, a prerequisite of this change.
 
 Resolution follows the pattern **already in production for ast-grep**: `findSgBinary()` (`rules/scan.ts:38-61`) resolves the platform package from our own module context with `createRequire(import.meta.url).resolve('<pkg>/package.json')`, execs the binary beside it, and falls back to `PATH`. Vale gets the same shape; the two should share one helper rather than diverge.
 
@@ -103,35 +76,15 @@ If a download is ever wanted despite this, the only acceptable form is a **user
 
 **Cost, stated plainly:** roughly seven packages, each a binary plus a `package.json` declaring `os`/`cpu` and containing no code, produced by a CI job that pulls Vale's release assets and republishes them under our scope. The recurring cost is a version bump per upstream Vale release.
 
-### D7 — One scaffold version in `taskless.json`; migration `0004` reorganizes into `sg/` + `vale/`
-
-`taskless.json.version` is the single format version. Migration `0004-*` is a **mechanical move**: the existing `.taskless/rules/` and `rule-tests/` are all known-ast-grep, so it moves `rules/ → sg/rules/`, `rule-tests/ → sg/rule-tests/`, and `sgconfig.yml → sg/sgconfig.yml` — and because `ruleDirs: [rules]` is _relative to the config_, it survives the move unchanged (no path edits). It then scaffolds `vale/` (`.vale.ini` + `rules/` + `rule-tests/`) and moves the runtime tier into the same shape: `runtime-rules/<name>/ → runtime/rules/<name>/` and `runtime-rule-tests/<name>/ → runtime/rule-tests/<name>/`. The runtime move is content-preserving — capture-rule bytes (and thus their reconciliation hashes) are unchanged; only `discover.ts`'s search path updates. Legacy bare rules keep working (they become `sg/` rules). **Version gating:** `runMigrations` currently returns silently when `version > maxVersion`; change it to **throw** ("upgrade the CLI") unless `--allow-version-mismatches` is passed.
-
-### D7b — Ingest defaults an engine-less payload to `sg`, permanently; unrecognized fails loudly
-
-`0004` relayouts what is already on disk, but the **ingest** path writes rules that arrive from the service, and it is a separate hazard: `writeRuleFile`/`writeRuleTestFile` (`rules/files.ts:11,26`) hardcode `.taskless/rules` and `.taskless/rule-tests`. Left untouched, the migration would move existing rules to `sg/` and the next `taskless rule create` would write straight back into `.taskless/rules/` — a directory no engine dispatches from under D1. Silent, and it reads as a vanished rule.
-
-The API offers nothing to switch on: there is no `engine`, `analysisType`, or `ruleType` field anywhere in `src/generated/api.d.ts`, and `/cli/api/rule/{ruleId}` documents `rules[].content` as "The ast-grep rule definition". The `filename` fields that do exist are **client→server** (`references[].filename` on `rule improve`; `files[].file` on reconcile) — the CLI tells the service where things live, not the reverse. So the CLI owns the destination decision, and today every delivered rule is ast-grep.
-
-Hence: **no engine identified ⇒ `sg`**, and permanently rather than for a migration window — published CLIs keep receiving engine-less payloads. This is the same judgment `0004` makes about on-disk state, so ingest and migration land a rule in the same place.
-
-**Absence and unrecognized are not the same.** An unrecognized engine means the payload is newer than the CLI; falling back to `sg` would file a Vale rule where ast-grep parses it, surfacing as a broken rule rather than version skew. Ingest errors and writes nothing, mirroring D7's scaffold-version gating. Server-side, the existing `x-taskless-cli-version` header (`api/client.ts`) lets the service avoid sending engine-typed payloads to a CLI that predates them; that half is the platform's.
-
-- **Alternative — sniff the rule body to guess its engine:** rejected; contradicts D1 (directory decides engine, no per-file parsing) and guesses where an explicit default is correct and knowable.
-
-### D7c — Reconcile is path-independent, so the relayout is transparent
-
-Reported reconcile paths are repo-relative POSIX and derived from wherever a rule was discovered (`rules/runtime/run-set.ts:57`), so they follow the moved trees automatically. The server joins reported files **by content signature, not path** — "content-based, so a moved-but-unchanged rule resolves" — and `0004` is byte-preserving. A migrated rule therefore reconciles to the same server-side rule with no coordinated release. The schema description "Delivered rule filename under `.taskless/rules/` on the client" goes stale on the platform side and is worth a follow-up there, but nothing depends on it.
-
-### D8 — Metadata surfaces through `CheckResult`; identity from the rule name
+### D6 — Metadata surfaces through `CheckResult`; identity from the rule name
 
 `CheckResult { source, ruleId, severity, message, note, file, range, matchedText, fix }` is the contract each engine maps into. `ruleId` is the rule's basename (ast-grep native `id`; Vale's `rules.<name>` stripped to `<name>`). Severity is engine-native, normalized on the client — Vale `error/warning/suggestion → error/warning/hint` (`info` unused; `.vale.ini` sets `MinAlertLevel = suggestion`). Vale mapping: `message←Message`, `note←Description/Link`, `range←Line+Span`, `matchedText←Match`, `fix←Action` when populated. Provenance is a generation-time server wrapper, never on disk.
 
-### D9 — The engine-selection topic ships with the engines it names
+### D7 — The engine-selection topic ships with the engines it names
 
 Making the CLI multi-engine creates a decision that did not previously exist: **which engine enforces a given rule**. Today that knowledge lives only in the platform's generator, as a binary `static | runtime` classifier prompt that predates Vale; no `help/*.txt` recipe states it. Adding a third engine without also stating the choice would leave every local authoring path assuming ast-grep.
 
-The topic therefore belongs to this change rather than a follow-on. It names `sg`/`vale`/`runtime` — the directories D1 introduces — so shipping it separately would either describe engines that do not yet exist or leave a window where the layout is engine-partitioned and the guidance is not. Task 7.2 already puts help and onboarding text in this change's scope; this is that work carried to its conclusion.
+The topic belongs with the engine rather than with the layout. It names `sg`/`vale`/`runtime` as things an agent can actually choose between, which is only true once Vale executes — shipping it alongside `partition-rules-by-engine` would have described an engine that existed as an empty directory.
 
 Three constraints shape the text, each from a real failure mode:
 
@@ -141,10 +94,12 @@ Three constraints shape the text, each from a real failure mode:
 
 Exporting the topic through `@taskless/cli/prompts` is deliberately **not** coupled to this change: the export mechanism is a separate change, and the topic file is useful to the local `help` flow with or without it. Whichever lands second adds the one-line `TOPICS` entry.
 
-- **Alternative — a separate follow-on change for the topic:** rejected; it either ships guidance for engines that do not exist yet, or leaves a release where `check` dispatches three engines while every recipe still assumes ast-grep.
+- **Alternative — a separate follow-on change for the topic:** rejected; it would leave a release where `check` dispatches three engines while every recipe still assumes ast-grep, and the topic is knowledge about the engine rather than a deliverable of its own.
 
 ## Risks / Trade-offs
 
+- **Landing before its prerequisites** → this change executes `.taskless/vale/`, which `partition-rules-by-engine` creates, and resolves a binary that `add-vale-binary-packages` publishes. Task group 0 checks both before any implementation starts.
+
 - **Committed configs are maintained artifacts** — the `.vale.ini` scoping sections and native `files`/`ignores` must be authored/updated when rules change. Construction doesn't vanish; it moves to rule-authoring time (mostly the downstream generator). Trade: check-time simplicity + transparent, versioned configs for author-time maintenance.
 - **Per-engine (not uniform) metadata** — fine for check (findings carry the rule name); any "list/describe rules" tooling parses each engine's native format.
 - **Vale `StyleName = rules`** yields `rules.<name>` internally → stripped for `ruleId`; keep the strip consistent.
diff --git a/openspec/changes/add-vale-rule-engine/proposal.md b/openspec/changes/add-vale-rule-engine/proposal.md
index eb81cb56..8bfe3a6d 100644
--- a/openspec/changes/add-vale-rule-engine/proposal.md
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -1,38 +1,35 @@
 ## Why
 
-Taskless rules today are ast-grep only — structural AST matching that fits code but cannot lint prose. A large, wanted class of rules (terminology, banned/weasel words, inclusive language, readability, heading/style consistency) targets Markdown and prose, which ast-grep structurally cannot express: its text nodes are opaque, and it has no dictionaries, NLP, or code-vs-prose scoping. Vale is a mature, markup-aware prose linter that covers exactly this gap. This change makes the CLI multi-engine by partitioning rules **per engine directory**, each using the tool's own native, committed config — so engines never cross-parse one another's rules, hundreds of rules run without command-line limits, and `check` is pure execution.
+Taskless rules are ast-grep only — structural AST matching that fits code but cannot lint prose. A large, wanted class of rules (terminology, banned and weasel words, inclusive language, readability, heading and style consistency) targets Markdown and prose, which ast-grep structurally cannot express: its text nodes are opaque, and it has no dictionaries, no NLP, and no code-vs-prose scoping. Vale is a mature, markup-aware prose linter that covers exactly that gap.
+
+`partition-rules-by-engine` builds the layout this plugs into — `.taskless/<engine>/` with directory-based dispatch and a scaffolded but inert `vale/`. This change makes that directory execute, and adds the knowledge an agent needs to decide when a rule belongs there at all.
 
 ## What Changes
 
-- **Engine-top-down layout**: `.taskless/<engine>/` holds `{config, rules/, rule-tests/}` in that engine's native format — `sg/` (`sgconfig.yml` + native ast-grep rules) and `vale/` (`.vale.ini` + native Vale styles). Directory = engine; dispatch is which directory.
-- **The native config is the source of truth — no sidecars, no generation at check time.** Each engine's committed config already carries everything: ast-grep rules scope via native `files`/`ignores` and hold Taskless data in `metadata`; Vale scopes via `.vale.ini` sections and (since Vale ignores unknown keys) carries Taskless breadcrumbs as `tskl) <name> = <value>` keys.
-- **Vale scoping lives in `.vale.ini` matchers**: each `[<glob>]` section is a **matcher** — a globbable block whose parameters name which rule(s) run there (`rules.<name> = YES`/`NO`; enables union, disable wins), our `tskl)`-prefixed keys, and any other Vale config for that matcher. Styles live under `rules/` (Vale's required StyleName; `StylesPath = .`, `BasedOnStyles = rules`).
-- **Check is pure execution over committed configs**: `sg scan --config sg/sgconfig.yml` / `vale --config vale/.vale.ini` — no materialization, no sidecar reads, no config generation, nothing to cache.
-- **Verify works differently from check** (both engines isolate each rule against known fixtures): `sg test` runs ast-grep's native tests; the Vale verifier **generates a temporary `.vale.ini`** to test each rule against its `pass/`/`fail/` fixtures.
-- **Add Vale as a static-tier engine**: always-run, anonymous-safe, no reconcile/signing. Vale's Tengo `script` is sandboxed (only `text`/`math`/`fmt`; no `os`/`io`/`exec`) — not a code-execution vector — so it stays static; a subprocess timeout bounds it.
-- **Realign runtime to the same shape**: move `runtime-rules/ → runtime/rules/` and `runtime-rule-tests/ → runtime/rule-tests/` (content-preserving — no live users, hashes stable). Runtime _execution_ (harness/reconcile/signing) is unchanged; only the directory and `discover.ts`'s search path move.
-- **Ship as migration `0004`** on the existing `runMigrations` ladder — moves `rules/`/`rule-tests/`/`sgconfig.yml` under `sg/`, scaffolds `vale/`, and moves the runtime dirs under `runtime/`. No new `upgrade` command; `runMigrations` gains version-mismatch gating (throw + `--allow-version-mismatches`).
+- Add Vale as a second **static-tier** engine: resolve its binary, run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit` over the target paths, and map findings into the scanner-agnostic `CheckResult` (stripping the `rules.` check-name prefix, normalizing severities).
+- Express per-rule scoping through `.vale.ini` **matchers** (`[<glob>] rules.<name> = YES/NO`; enables union across matchers, disable wins, order-independent), with Taskless breadcrumbs carried as `tskl)`-namespaced keys Vale accepts and silently ignores.
+- Verify Vale rules against per-rule `pass/`/`fail/` fixture directories, generating an isolating `.vale.ini` at verify time rather than committing one.
+- Run engines concurrently and merge their results into one set, with an unavailable engine reported rather than aborting the others.
+- Add an **engine-selection** knowledge topic — which engine (`sg` / `vale` / `runtime`) can enforce a requested rule — kept distinct from `route`'s authoring destination and from trust tier.
 
 ## Capabilities
 
 ### New Capabilities
 
-- `cli-rule-format`: The engine-top-down on-disk layout — `.taskless/<engine>/{config, rules/, rule-tests/}` with each engine's native, committed config as the source of truth (no sidecars, no generated config). Directory-based dispatch; the extension point for future engines.
-- `cli-vale-rule-engine`: Vale as a concrete static engine — static-tier trust (sandboxed Tengo), the `.vale.ini` **matcher** scoping model (per-`[<glob>]` enable/disable + `tskl)` keys) and StyleName mapping, the `--config` check runner, a **verify that generates a temporary `.vale.ini`** per rule against `pass/`/`fail/` fixtures, and findings→`CheckResult` mapping (incl. `rules.` prefix stripping).
+- `cli-vale-rule-engine`: Vale as a concrete static engine — static-tier trust (its Tengo `script` sandbox exposes only `text`/`math`/`fmt`), the `.vale.ini` matcher scoping model, the `--config` check runner bounded by a subprocess timeout, fixture-based verify, and findings → `CheckResult` mapping.
 
 ### Modified Capabilities
 
-- `cli-check`: Check runs each engine's native tool with its committed config (`sg scan --config sg/…`, `vale --config vale/…`) over the resolved paths, concurrently, and merges results; verify runs `sg test` (ast-grep) and a Vale fixture runner. The ephemeral `sgconfig.yml` generation is removed from the check path (configs are committed under `sg/`), and `check` calls `ensureTasklessDirectory` directly to preserve the migration trigger.
-- `cli-runtime-rule-execution`: Runtime rules are discovered under `.taskless/runtime/rules/<name>/` (and fixtures under `runtime/rule-tests/<name>/`) instead of `runtime-rules/` — a directory move only; execution semantics are unchanged.
-- `cli-rule-routing`: Gains an **engine-selection** topic — which engine (`sg`/`vale`/`runtime`) can enforce a requested rule — as a distinct axis from `route`'s authoring destination and from trust tier. Ambiguity defaults to an engine known to be available.
-- `cli-help`: The engine-selection topic is registered in the help index, and the `route`/`static` recipes cross-reference it so the local flow applies the same engine test the service does.
+- `cli-rule-format`: Vale's layout maps to `StylesPath` via the `rules/` StyleName — the directory `partition-rules-by-engine` scaffolds becomes the style Vale actually loads.
+- `cli-check`: Engines run concurrently and their results merge into one set; an unavailable engine is reported without aborting the rest.
+- `cli-rule-routing`: Gains an engine-selection topic, as an axis distinct from authoring destination and from trust tier. Ambiguity defaults to an engine known to be available.
+- `cli-help`: The engine-selection topic is registered in the help index, and `route`/`static` cross-reference it so the local flow applies the same engine test the service does.
 
 ## Impact
 
-- **CLI (`packages/cli`)**: `commands/check.ts` (per-engine execution over committed configs + migration trigger), `rules/scan.ts` (`--config` over `sg/`), `rules/verify.ts` (`sg test` over `sg/`), new `rules/vale/*` (`--config` runner, `CheckResult` mapping, fixture verify), removal of ephemeral `filesystem/sgconfig.ts` generation from the check path, new `filesystem/migrations/0004-*.ts`, and `rules/files.ts` (ingest writes into `sg/`, defaulting an engine-less service payload to ast-grep).
-- **On-disk layout**: `.taskless/sg/{sgconfig.yml, rules/, rule-tests/}` and `.taskless/vale/{.vale.ini, rules/, rule-tests/}`; legacy bare `.taskless/rules/*.yml` migrate under `sg/`. `taskless.json` scaffold version bumps.
-- **Dependency**: adds `vale` as an external binary the CLI shells out to (like `sg`).
-- **Runtime execution unchanged** (reconcile/signing/harness) — only the directory moves `runtime-rules/ → runtime/rules/` (updating `discover.ts`'s path); Vale is explicitly static. **No new `upgrade` command** — the migration ladder suffices (now with version-mismatch gating).
-- **Downstream (separate change, taskless repo)**: generating Vale rules + authoring the committed `.vale.ini`/`sgconfig.yml`, the verification-sandbox path, and prose-request classification build on this foundation.
+- **CLI (`packages/cli`)**: new `rules/vale/*` (binary resolution, runner, `CheckResult` mapping, fixture verify); `commands/check.ts` (concurrent multi-engine execution and merge); new `src/help/<engine-selection>.txt` plus help-index registration and `route`/`static` cross-references.
+- **Prerequisites**: `partition-rules-by-engine` must land first — this executes a directory that change creates. `add-vale-binary-packages` must land first as well, or there is no binary to resolve.
+- **New external dependency**: the Vale binary, delivered as per-platform packages rather than assumed on `PATH`.
+- **Deliberately excluded**: generating Vale rules and authoring the committed `.vale.ini`. That is rule-generation work, split between a CLI-side authoring change and server-side generation in the platform repo.
 
 **Tracking:** OSS-21
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md
index 36ea32d7..9709db19 100644
--- a/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md
@@ -15,38 +15,3 @@
 - **THEN** the CLI reports the Vale engine as unavailable and still returns ast-grep results
 
 ## MODIFIED Requirements
-
-### Requirement: Check subcommand executes ast-grep scan
-
-The CLI SHALL execute `sg scan --config .taskless/sg/sgconfig.yml --json=stream` using `child_process.spawn` with `shell: true` for cross-platform binary resolution, reading the **committed** ast-grep config at `.taskless/sg/sgconfig.yml`. No `sgconfig.yml` is generated at check time. The `sg` binary SHALL be resolved from the `@ast-grep/cli` dependency via PATH. Reconciliation/run-set semantics for runtime rules are unchanged.
-
-#### Scenario: ast-grep scan runs with the committed config
-
-- **WHEN** the CLI executes the ast-grep scanner
-- **THEN** it SHALL invoke `sg scan` with `--config .taskless/sg/sgconfig.yml` and `--json=stream`
-- **AND** it SHALL NOT write or generate a config file
-- **AND** the working directory for the spawned process SHALL be the resolved project directory
-
-#### Scenario: ast-grep binary is not found
-
-- **WHEN** the `sg` binary cannot be resolved from PATH
-- **THEN** the CLI SHALL print an error message indicating ast-grep is not available
-- **AND** the CLI SHALL exit with code 1
-
-### Requirement: Check dispatches static and runtime rules to distinct executors
-
-`taskless check` SHALL dispatch rules to distinct executors by their engine directory: **ast-grep** rules under `.taskless/sg/` via the ast-grep scanner, **Vale** rules under `.taskless/vale/` via the Vale runner (per the `cli-vale-rule-engine` capability), and **runtime** rules under `.taskless/runtime/rules/` via the runtime harness (per the `cli-runtime-rule-execution` capability). Findings from all executors SHALL be aggregated into the same result set and SHALL count toward the exit code identically.
-
-#### Scenario: Mixed corpus runs all executors
-
-- **WHEN** `.taskless/sg/` contains ast-grep rules, `.taskless/vale/` contains Vale rules, and `.taskless/runtime/rules/` contains runtime rules
-- **THEN** the CLI SHALL run ast-grep rules through `sg scan`, Vale rules through the Vale runner, and runtime rules through the runtime harness
-- **AND** SHALL merge their findings into one result set
-
-## REMOVED Requirements
-
-### Requirement: Check subcommand generates ephemeral sgconfig.yml
-
-**Reason**: Engine configs are now committed per-engine directory (`.taskless/sg/sgconfig.yml`), not generated at check time — check reads the committed config directly.
-
-**Migration**: Migration `0004` moves the existing `.taskless/sgconfig.yml` to `.taskless/sg/sgconfig.yml` (its relative `ruleDirs: [rules]` remains valid). No config is written at check time thereafter.
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
index 2a8b4933..485dd052 100644
--- a/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
@@ -1,42 +1,5 @@
 ## ADDED Requirements
 
-### Requirement: Rules are partitioned into per-engine directories
-
-The system SHALL store rules under a top-level engine directory `.taskless/<engine>/`, each with a `rules/` directory and a `rule-tests/` directory. The `sg` engine SHALL use `sgconfig.yml`; the `vale` engine SHALL use `.vale.ini`; the `runtime` engine SHALL store each rule as a directory `rules/<rule>/` (capture `*.yml` + `check.ts`) with fixtures under `rule-tests/<rule>/`.
-
-#### Scenario: ast-grep engine directory
-
-- **WHEN** the CLI resolves `.taskless/`
-- **THEN** ast-grep rules are found under `.taskless/sg/rules/`, the config is `.taskless/sg/sgconfig.yml`, and tests are under `.taskless/sg/rule-tests/`
-
-#### Scenario: Vale engine directory
-
-- **WHEN** the CLI resolves `.taskless/`
-- **THEN** Vale styles are found under `.taskless/vale/rules/`, the config is `.taskless/vale/.vale.ini`, and tests are under `.taskless/vale/rule-tests/`
-
-### Requirement: A rule's engine is determined by its containing directory
-
-The system SHALL dispatch each rule to the engine named by its top-level `.taskless/<engine>/` directory, and SHALL NOT parse a rule file to determine its engine.
-
-#### Scenario: Directory-based dispatch
-
-- **WHEN** a rule file exists at `.taskless/sg/rules/no-eval.yml` and another at `.taskless/vale/rules/no-simply.yml`
-- **THEN** the first is executed by ast-grep and the second by Vale, based solely on directory
-
-### Requirement: Each engine's committed native config is the source of truth
-
-The system SHALL treat each engine's committed native config as the authoritative definition of its rules, their scoping, and their metadata. The system SHALL NOT require a separate Taskless sidecar or metadata file for a rule, and SHALL NOT generate an engine config at check time.
-
-#### Scenario: No sidecar or generated config
-
-- **WHEN** the CLI runs a check
-- **THEN** it reads the committed `sg/sgconfig.yml` and `vale/.vale.ini` as-is, and neither writes nor generates an engine config
-
-#### Scenario: Native scoping is applied by the engine
-
-- **WHEN** an ast-grep rule declares native `files`/`ignores`, or a Vale `.vale.ini` declares per-rule include/exclude sections
-- **THEN** the engine applies that scoping directly, with no Taskless-side rule transformation
-
 ### Requirement: Vale styles live under the rules StyleName
 
 The system SHALL place Vale styles under `.taskless/vale/rules/` so that `rules` is Vale's StyleName, with `.vale.ini` configured `StylesPath = .` and `BasedOnStyles = rules`. The Vale check identifier `rules.<name>` SHALL be normalized to `ruleId = <name>` in results.
@@ -45,79 +8,3 @@ The system SHALL place Vale styles under `.taskless/vale/rules/` so that `rules`
 
 - **WHEN** a Vale style exists at `.taskless/vale/rules/no-simply.yml`
 - **THEN** Vale loads it as `rules.no-simply`, and the CLI reports its findings with `ruleId` `no-simply`
-
-### Requirement: Migration preserves existing ast-grep rules by moving them under sg
-
-The migration to the engine-partitioned layout SHALL move the existing `.taskless/rules/`, `.taskless/rule-tests/`, and `.taskless/sgconfig.yml` under `.taskless/sg/` without editing file contents, relying on `sgconfig.yml`'s relative `ruleDirs: [rules]` remaining valid after the move. It SHALL scaffold `.taskless/vale/` and SHALL move `.taskless/runtime-rules/` to `.taskless/runtime/rules/` and `.taskless/runtime-rule-tests/` to `.taskless/runtime/rule-tests/` without editing file contents (preserving runtime capture-rule hashes). Every scaffolded directory that would otherwise be empty SHALL contain a `.gitkeep` file so the structure is tracked reliably.
-
-#### Scenario: Mechanical move of legacy rules
-
-- **WHEN** the migration runs against a `.taskless/` containing `rules/`, `rule-tests/`, and `sgconfig.yml`
-- **THEN** those become `sg/rules/`, `sg/rule-tests/`, and `sg/sgconfig.yml`, and `sg scan --config .taskless/sg/sgconfig.yml` runs the same rules as before the move
-
-#### Scenario: Vale scaffolded, runtime moved
-
-- **WHEN** the migration runs
-- **THEN** `.taskless/vale/` is created with empty `rules/` and `rule-tests/`, and `.taskless/runtime-rules/` becomes `.taskless/runtime/rules/` with byte-identical contents
-
-### Requirement: Service-delivered rules without an engine are written as ast-grep
-
-The rule ingest path SHALL write a service-delivered rule into the engine directory its payload identifies. The current API carries **no** engine discriminator — `/cli/api/rule/{ruleId}` returns `rules[].content` documented as an ast-grep rule definition — so a payload that does not identify an engine SHALL be written as ast-grep, under `.taskless/sg/rules/<id>.yml`, with its tests under `.taskless/sg/rule-tests/`.
-
-This default is permanent, not a migration window: published CLIs and stored payloads without an engine field continue to exist indefinitely, and the default matches what the migration does to the same rules already on disk.
-
-Absence of an engine and an **unrecognized** engine are distinct. If a payload identifies an engine the installed CLI does not know, ingest SHALL fail with an error naming the engine and instructing the user to upgrade, and SHALL NOT fall back to ast-grep.
-
-#### Scenario: Engine-less payload is filed under sg
-
-- **WHEN** a rule is delivered by the service with no engine identified in its payload
-- **THEN** it is written to `.taskless/sg/rules/<id>.yml` and its tests to `.taskless/sg/rule-tests/`, and a subsequent `check` dispatches it to ast-grep
-
-#### Scenario: Ingest and migration agree on destination
-
-- **WHEN** a rule that predates the engine-partitioned layout is migrated, and an equivalent rule is delivered fresh by the service
-- **THEN** both come to rest at the same path under `.taskless/sg/rules/`
-
-#### Scenario: Unrecognized engine fails loudly
-
-- **WHEN** a payload identifies an engine the installed CLI does not support
-- **THEN** ingest exits with an error naming the engine and directing the user to upgrade, and no rule file is written under any engine directory
-
-### Requirement: Both the legacy and engine-partitioned layouts are readable
-
-The CLI SHALL dispatch rules found at the legacy `.taskless/rules/` path as ast-grep, in addition to `.taskless/sg/rules/`, so a checkout that has not yet been migrated — or a rule delivered by a service that still names the legacy location — is executed rather than ignored.
-
-This tolerance is what decouples the CLI's release from any consumer's: a producer may continue to use the pre-migration layout indefinitely and its rules keep running.
-
-#### Scenario: Unmigrated checkout still runs its rules
-
-- **WHEN** `check` runs against a `.taskless/` containing `rules/` but no `sg/`
-- **THEN** those rules are dispatched to ast-grep and reported, not silently skipped
-
-#### Scenario: Both layouts present
-
-- **WHEN** rules exist under both `.taskless/rules/` and `.taskless/sg/rules/`
-- **THEN** both are dispatched to ast-grep and their findings merged, with no duplicate reporting of the same rule
-
-### Requirement: Reconciliation survives the relayout
-
-The CLI SHALL report rule files to the reconcile endpoint at their post-migration repo-relative paths. Because the server joins reported files by content signature rather than by path, moving a rule without editing it SHALL NOT change its reconciled state.
-
-#### Scenario: Moved rules reconcile unchanged
-
-- **WHEN** `check` reconciles after the migration has moved rules from `.taskless/rules/` to `.taskless/sg/rules/` and runtime rules to `.taskless/runtime/rules/`
-- **THEN** each file's signature is unchanged, the server resolves it to the same rule, and no rule is reported as new or missing
-
-### Requirement: The CLI refuses a scaffold newer than it understands unless overridden
-
-When `taskless.json`'s `version` exceeds the highest migration the installed CLI knows, the system SHALL exit with an error instructing the user to upgrade the CLI, unless `--allow-version-mismatches` is passed, in which case it SHALL proceed without applying migrations.
-
-#### Scenario: Newer scaffold blocks
-
-- **WHEN** `taskless.json` has a `version` greater than the CLI's maximum known migration
-- **THEN** the CLI exits with an error telling the user to upgrade the CLI
-
-#### Scenario: Override proceeds
-
-- **WHEN** the same condition holds and `--allow-version-mismatches` is set
-- **THEN** the CLI proceeds without applying migrations
diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md
deleted file mode 100644
index 7eb1447f..00000000
--- a/openspec/changes/add-vale-rule-engine/specs/cli-runtime-rule-execution/spec.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Runtime rules are directories recognized by metadata
-
-The CLI SHALL recognize a **runtime rule** as a directory under `.taskless/runtime/rules/<name>/`
-containing one or more ast-grep capture `*.yml` (one per capture rule) and a single `check.ts`,
-its capture rules declaring `metadata.taskless.kind: runtime`. The rule's check file SHALL be
-the `check.ts` in the rule directory. The CLI SHALL read **each capture rule's**
-`metadata.taskless.match` (`anchor` or `broad`) to select that capture rule's ast-grep
-invocation mode; capture rules within one runtime rule MAY mix modes (each is independent).
-Rule files under `.taskless/sg/rules/` SHALL continue to be treated as static ast-grep rules,
-not runtime rules. `.taskless/runtime/rule-tests/<name>/` holds `valid/` and `invalid/`
-verification fixtures and SHALL NOT be executed by `check`.
-
-#### Scenario: A runtime directory entry is a runtime rule
-
-- **WHEN** `.taskless/runtime/rules/<name>/` contains capture `*.yml` with `metadata.taskless.kind: runtime` and a `check.ts`
-- **THEN** the CLI SHALL treat it as a runtime rule with `check.ts` as its check file and route it to the runtime harness
-
-#### Scenario: Rules under sg remain static
-
-- **WHEN** a rule file lives under `.taskless/sg/rules/`
-- **THEN** the CLI SHALL treat it as a static rule and SHALL NOT route it to the runtime harness
diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
index c89da334..98c7c164 100644
--- a/openspec/changes/add-vale-rule-engine/tasks.md
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -1,75 +1,38 @@
-## 1. Migration and directory layout
+## 0. Prerequisites
 
-- [ ] 1.1 Add `filesystem/migrations/0004-vale-engine.ts`: move `.taskless/rules/`, `rule-tests/`, and `sgconfig.yml` under `.taskless/sg/` (content-preserving; `ruleDirs: [rules]` is relative and stays valid)
-- [ ] 1.2 Extend `0004` to move `.taskless/runtime-rules/ → runtime/rules/` and `runtime-rule-tests/ → runtime/rule-tests/` byte-for-byte (runtime hashes unchanged)
-- [ ] 1.3 Extend `0004` to scaffold `.taskless/vale/` (`.vale.ini` + `rules/` + `rule-tests/`), writing a `.gitkeep` into every otherwise-empty scaffolded directory, and bump `taskless.json` `version`
-- [ ] 1.4 Register `0004` in `filesystem/migrate.ts` and confirm `runMigrations` applies it via `ensureTasklessDirectory`
-- [ ] 1.5 Add version-mismatch gating: `runMigrations` throws when `taskless.json.version > maxVersion` with an "upgrade the CLI" message, unless a global `--allow-version-mismatches` flag is set
-- [ ] 1.6 Tests: `0004` moves each tree correctly, `.gitkeep` present, runtime contents byte-identical; gating throws and the flag overrides
+- [ ] 0.1 Confirm `partition-rules-by-engine` has landed: `.taskless/vale/` is scaffolded, dispatch routes by engine directory, and `check` runs ast-grep over the committed `sg/sgconfig.yml`. This change extends that layout; it does not create it
+- [ ] 0.2 Confirm the Vale platform packages from `add-vale-binary-packages` are published and declared, so there is a binary to resolve
 
-## 2. Engine dispatch (directory model)
+## 1. Vale engine
 
-- [ ] 2.1 Implement directory-based engine discovery: enumerate `.taskless/<engine>/` (`sg`, `vale`, `runtime`) and route rules by directory, no per-file parsing
-- [ ] 2.2 In `commands/check.ts`, call `ensureTasklessDirectory(cwd)` directly (preserving the migration trigger now that `generateSgConfig` leaves the check path)
-- [ ] 2.3 Tests: a rule under `sg/rules/` dispatches to ast-grep and one under `vale/rules/` to Vale, by directory alone
-- [ ] 2.4 Treat the legacy `.taskless/rules/` path as an ast-grep source alongside `sg/rules/`, so an unmigrated checkout still runs; de-duplicate when both are present
-- [ ] 2.5 Tests: a `.taskless/` with only `rules/` dispatches to ast-grep; with both `rules/` and `sg/rules/`, findings merge without duplicates
+- [ ] 1.1 Extract the platform-binary resolution in `findSgBinary()` (`rules/scan.ts:38-61`) into a shared helper — resolve `<pkg>/package.json` via `createRequire(import.meta.url)`, exec the binary beside it, fall back to `PATH` — and use it for both `sg` and `vale`. When nothing resolves, report the Vale engine unavailable without aborting other engines (D6b)
+- [ ] 1.1b Publish per-platform Vale binary packages under the Taskless scope: binary in the tarball, `os`/`cpu` declared, **no `bin`, no code, no scripts** (we exec by path, so nothing needs hardlinking into place). Add them to `packages/cli` as `optionalDependencies`. Include Vale's MIT attribution. Do NOT depend on a download-at-postinstall package: the script runs under the consumer's package-manager policy, and pnpm 10 blocks it by default, yielding no binary and no error
+- [ ] 1.1c CI job to mirror upstream Vale releases into those packages; decide the architecture set (ast-grep's seven is the starting point) and pin the Vale version the CLI expects
+- [ ] 1.1d Handle musl: `findSgBinary()` maps every Linux to `-gnu`, so Alpine falls through to `PATH` today. Detect libc for the Vale lookup (upstream ast-grep uses `detect-libc`) and decide whether to publish a musl variant or leave the `PATH` fallback deliberately
+- [ ] 1.1e Confirm the Vite build externalizes the platform packages rather than bundling them, and that `createRequire(import.meta.url)` resolves correctly from `dist/` — the same context `findSgBinary()` already relies on
+- [ ] 1.2 Add `rules/vale/run.ts`: run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit <paths>`, bounded by a subprocess timeout that terminates and reports on expiry
+- [ ] 1.3 Map Vale JSON findings → `CheckResult`: `source: "vale"`, `ruleId` = check name with `rules.` stripped, severity `error/warning/suggestion → error/warning/hint`, and `message`/`note`/`range`/`matchedText`/`fix` per the mapping
+- [ ] 1.4 Add `rules/vale/verify.ts`: for each `vale/rule-tests/<rule>/`, generate an ephemeral `.vale.ini` enabling only that rule, run Vale over `pass/`/`fail/` fixtures, assert every `fail/` yields a finding and every `pass/` none
+- [ ] 1.5 Tests: `rules.` stripping + severity mapping; committed-config scoping respected (include union, exclude disable, duplicate matchers merge); verify pass/fail; missing-binary and timeout paths
 
-## 2b. Service-delivered rule ingest
+## 2. Check orchestration
 
-- [ ] 2b.1 Update `rules/files.ts` — `writeRuleFile` writes `.taskless/sg/rules/<id>.yml` and `writeRuleTestFile` writes `.taskless/sg/rule-tests/`, replacing the hardcoded `.taskless/rules` / `.taskless/rule-tests` (both call sites are `commands/rules.ts:241,245,482,486`)
-- [ ] 2b.2 Resolve the destination from an engine the payload identifies, defaulting to `sg` when the payload identifies none — permanently, since the API carries no engine discriminator today
-- [ ] 2b.3 Fail loudly on an engine the CLI does not recognize: error naming the engine, instruct upgrade, write nothing (do NOT fall back to `sg`)
-- [ ] 2b.4 Audit the remaining `.taskless/rules` string literals for the same defect — at minimum `rules/verify.ts:246`, `rules/files.ts:99`, `commands/check.ts:314`, `commands/rules.ts:661`, and the `detect/scan.ts:428` layout probe
-- [ ] 2b.5 Tests: an engine-less payload lands in `sg/rules/` and is dispatched to ast-grep by `check`; a migrated rule and a freshly delivered one come to rest at the same path; an unrecognized engine errors and writes nothing
+- [ ] 2.1 Dispatch to distinct executors by engine directory — ast-grep (`sg/`) → scanner, Vale (`vale/`) → runner, runtime (`runtime/rules/`) → harness
+- [ ] 2.2 Run engines concurrently, merge `CheckResult`s into one set, derive the exit code from merged severities, and keep an unavailable engine from aborting the others
+- [ ] 2.3 Tests: a mixed `sg`+`vale`+`runtime` corpus runs all executors and merges; with the `vale` binary absent, ast-grep results still return
 
-## 2c. Reconcile compatibility
+## 3. Engine-selection knowledge topic
 
-- [ ] 2c.1 Confirm reported reconcile paths follow the moved trees (`rules/runtime/run-set.ts:57` builds repo-relative POSIX paths from the discovered location)
-- [ ] 2c.2 Test: after `0004`, signatures are unchanged and the signature-based join resolves every moved rule — nothing reports as new or missing
-
-## 3. Runtime discovery path
-
-- [ ] 3.1 Update `rules/runtime/discover.ts` to read `.taskless/runtime/rules/<name>/` and fixtures from `runtime/rule-tests/<name>/` (was `runtime-rules/`)
-- [ ] 3.2 Confirm rules under `.taskless/sg/rules/` are treated as static, not runtime
-- [ ] 3.3 Tests: runtime discovery at the new path; execution/reconcile/signing behavior unchanged
-
-## 4. ast-grep engine over the committed config
-
-- [ ] 4.1 Update `rules/scan.ts` to run `sg scan --config .taskless/sg/sgconfig.yml --json=stream` and remove ephemeral `sgconfig.yml` generation from the check path
-- [ ] 4.2 Update `rules/verify.ts` to run `sg test -c .taskless/sg/sgconfig.yml` over `sg/rule-tests/`
-- [ ] 4.3 Tests: scan/verify run against the committed `sg/` config; `sg` binary-not-found prints an error and exits 1
-
-## 5. Vale engine
-
-- [ ] 5.1 Extract the platform-binary resolution in `findSgBinary()` (`rules/scan.ts:38-61`) into a shared helper — resolve `<pkg>/package.json` via `createRequire(import.meta.url)`, exec the binary beside it, fall back to `PATH` — and use it for both `sg` and `vale`. When nothing resolves, report the Vale engine unavailable without aborting other engines (D6b)
-- [ ] 5.1b Publish per-platform Vale binary packages under the Taskless scope: binary in the tarball, `os`/`cpu` declared, **no `bin`, no code, no scripts** (we exec by path, so nothing needs hardlinking into place). Add them to `packages/cli` as `optionalDependencies`. Include Vale's MIT attribution. Do NOT depend on a download-at-postinstall package: the script runs under the consumer's package-manager policy, and pnpm 10 blocks it by default, yielding no binary and no error
-- [ ] 5.1c CI job to mirror upstream Vale releases into those packages; decide the architecture set (ast-grep's seven is the starting point) and pin the Vale version the CLI expects
-- [ ] 5.1d Handle musl: `findSgBinary()` maps every Linux to `-gnu`, so Alpine falls through to `PATH` today. Detect libc for the Vale lookup (upstream ast-grep uses `detect-libc`) and decide whether to publish a musl variant or leave the `PATH` fallback deliberately
-- [ ] 5.1e Confirm the Vite build externalizes the platform packages rather than bundling them, and that `createRequire(import.meta.url)` resolves correctly from `dist/` — the same context `findSgBinary()` already relies on
-- [ ] 5.2 Add `rules/vale/run.ts`: run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit <paths>`, bounded by a subprocess timeout that terminates and reports on expiry
-- [ ] 5.3 Map Vale JSON findings → `CheckResult`: `source: "vale"`, `ruleId` = check name with `rules.` stripped, severity `error/warning/suggestion → error/warning/hint`, and `message`/`note`/`range`/`matchedText`/`fix` per the mapping
-- [ ] 5.4 Add `rules/vale/verify.ts`: for each `vale/rule-tests/<rule>/`, generate an ephemeral `.vale.ini` enabling only that rule, run Vale over `pass/`/`fail/` fixtures, assert every `fail/` yields a finding and every `pass/` none
-- [ ] 5.5 Tests: `rules.` stripping + severity mapping; committed-config scoping respected (include union, exclude disable, duplicate matchers merge); verify pass/fail; missing-binary and timeout paths
-
-## 6. Check orchestration
-
-- [ ] 6.1 Dispatch to distinct executors by engine directory — ast-grep (`sg/`) → scanner, Vale (`vale/`) → runner, runtime (`runtime/rules/`) → harness
-- [ ] 6.2 Run engines concurrently, merge `CheckResult`s into one set, derive the exit code from merged severities, and keep an unavailable engine from aborting the others
-- [ ] 6.3 Tests: a mixed `sg`+`vale`+`runtime` corpus runs all executors and merges; with the `vale` binary absent, ast-grep results still return
-
-## 6b. Engine-selection knowledge topic
-
-- [ ] 6b.1 Author `packages/cli/src/help/<engine-selection>.txt` from the seed prose in `tmp/SEED-engine-selection-prose.md`: the three engine definitions (`sg` in-file syntax tree incl. relational correlation, `vale` prose/markup, `runtime` cross-file/graph/metadata/normalization), the reason-before-answer procedure, and the worked example table
-- [ ] 6b.2 State the ambiguity default as a property — the default names an engine known to be available — and note that `@ast-grep/cli` ships as a dependency while the Vale binary is external, so `sg` satisfies it locally
-- [ ] 6b.3 Carry the three boundary cases: prose-about-code vs structure, Vale is per-document (cross-document prose consistency is `runtime`), and `sg`/`vale` are both static-tier so trust tier is a separate axis
-- [ ] 6b.4 Keep the topic scoped to engine choice — no authoring-destination guidance, no tool-calling mechanics from the seed's source prompt
-- [ ] 6b.5 Register the topic in the help index and add `route`/`static` cross-references to it
-- [ ] 6b.6 Tests: the topic resolves via `taskless help` and appears in the index; the topic file matches the established recipe header/format convention
+- [ ] 3.1 Author `packages/cli/src/help/<engine-selection>.txt` from the seed prose in `tmp/SEED-engine-selection-prose.md`: the three engine definitions (`sg` in-file syntax tree incl. relational correlation, `vale` prose/markup, `runtime` cross-file/graph/metadata/normalization), the reason-before-answer procedure, and the worked example table
+- [ ] 3.2 State the ambiguity default as a property — the default names an engine known to be available — and note that `@ast-grep/cli` ships as a dependency while the Vale binary is external, so `sg` satisfies it locally
+- [ ] 3.3 Carry the three boundary cases: prose-about-code vs structure, Vale is per-document (cross-document prose consistency is `runtime`), and `sg`/`vale` are both static-tier so trust tier is a separate axis
+- [ ] 3.4 Keep the topic scoped to engine choice — no authoring-destination guidance, no tool-calling mechanics from the seed's source prompt
+- [ ] 3.5 Register the topic in the help index and add `route`/`static` cross-references to it
+- [ ] 3.6 Tests: the topic resolves via `taskless help` and appears in the index; the topic file matches the established recipe header/format convention
 
 > Export via `@taskless/cli/prompts` is not part of this change (see D9). Whichever of this change and `export-knowledge-prompts` lands second adds the one-line `TOPICS` entry.
 
-## 7. Quality gates
+## 4. Quality gates
 
-- [ ] 7.1 `pnpm --filter @taskless/cli typecheck && lint && test` clean
-- [ ] 7.2 Update CLI help/onboarding text and `.taskless/.gitignore` handling for the engine-partitioned layout
+- [ ] 4.1 `pnpm --filter @taskless/cli typecheck && lint && test` clean
+- [ ] 4.2 With the Vale binary absent, confirm ast-grep and runtime results still return and only Vale reports unavailable

From 58f667c7967e6d1e622f3f81f6617663feaf3bfc Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Wed, 29 Jul 2026 12:04:08 -0700
Subject: [PATCH 06/15] docs(openspec): declare add-vale-rule-engine as a
 merge-down stack

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDv57zHq7abms3RReSQw6q
---
 openspec/changes/add-vale-rule-engine/proposal.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/openspec/changes/add-vale-rule-engine/proposal.md b/openspec/changes/add-vale-rule-engine/proposal.md
index 8bfe3a6d..516baaeb 100644
--- a/openspec/changes/add-vale-rule-engine/proposal.md
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -32,4 +32,16 @@ Taskless rules are ast-grep only — structural AST matching that fits code but
 - **New external dependency**: the Vale binary, delivered as per-platform packages rather than assumed on `PATH`.
 - **Deliberately excluded**: generating Vale rules and authoring the committed `.vale.ini`. That is rule-generation work, split between a CLI-side authoring change and server-side generation in the platform repo.
 
+## Delivery shape
+
+**Stacked, merging down.** The Vale engine is only correct once `check` can dispatch to it: the runner without the multi-engine orchestration ships an engine that never executes, and the orchestration without the runner dispatches to nothing.
+
+| Unit | Scope                                                      |
+| ---- | ---------------------------------------------------------- |
+| 1    | Binary resolution, Vale runner, `CheckResult` mapping      |
+| 2    | Fixture-based verify                                       |
+| 3    | Concurrent multi-engine orchestration and merge            |
+| 4    | Engine-selection knowledge topic and its help registration |
+
+Unit 4 is the arguable exception — a knowledge topic is inert and would be safe alone — but it describes `vale` as an engine an agent can choose, which is only true once units 1–3 exist. It rides the same stack rather than shipping guidance ahead of the capability.
 **Tracking:** OSS-21

From 65d03e7f3a3927c3efcf2c7aea123094834a9483 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Sat, 1 Aug 2026 08:18:03 -0700
Subject: [PATCH 07/15] docs(openspec): record add-vale-rule-engine as a minor
 release

Every one of these PRs carried skip-changeset while it was spec-only,
which becomes wrong the moment implementation lands. Stating the impact
in the proposal means the tip PR needs a changeset written, not a label
kept.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDv57zHq7abms3RReSQw6q
---
 openspec/changes/add-vale-rule-engine/proposal.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/openspec/changes/add-vale-rule-engine/proposal.md b/openspec/changes/add-vale-rule-engine/proposal.md
index 516baaeb..cee34e2e 100644
--- a/openspec/changes/add-vale-rule-engine/proposal.md
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -34,6 +34,8 @@ Taskless rules are ast-grep only — structural AST matching that fits code but
 
 ## Delivery shape
 
+**Release impact: minor.** Adds a second rule engine and a new knowledge topic. Nothing existing breaks; ast-grep rules behave exactly as before. A whole new capability is a feature.
+
 **Stacked, merging down.** The Vale engine is only correct once `check` can dispatch to it: the runner without the multi-engine orchestration ships an engine that never executes, and the orchestration without the runner dispatches to nothing.
 
 | Unit | Scope                                                      |

From 32dce95de8a7ddec9808c1688a4be990e46af03e Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Sun, 9 Aug 2026 23:07:27 -0700
Subject: [PATCH 08/15] docs(openspec): drop the Vale packaging subtasks now
 that the packages ship

add-vale-binary-packages published all six @taskless/vale-<os>-<cpu>
packages and pinned them as optionalDependencies, so tasks 1.1b-1.1e
(publishing, the mirror CI job, the musl decision, and the Vite
externalization check) are done elsewhere. Section 1 reduces to the
runtime resolution in task 1.1, which now carries the one detail the
removed subtasks held: the Vale packages have no libc suffix, so the
shared helper must not apply findSgBinary()'s -gnu mapping to them.

Closes task 7.3 of add-vale-binary-packages.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 openspec/changes/add-vale-rule-engine/design.md | 2 +-
 openspec/changes/add-vale-rule-engine/tasks.md  | 6 +-----
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/openspec/changes/add-vale-rule-engine/design.md b/openspec/changes/add-vale-rule-engine/design.md
index a8870db5..991924c7 100644
--- a/openspec/changes/add-vale-rule-engine/design.md
+++ b/openspec/changes/add-vale-rule-engine/design.md
@@ -115,7 +115,7 @@ Exporting the topic through `@taskless/cli/prompts` is deliberately **not** coup
 
 ## Open Questions
 
-**Vale binary packaging** — the per-platform packages (D6b) are their own release-engineering task: which architectures to cover beyond the ast-grep set, and the CI job that mirrors upstream Vale releases. It does not block the engine work; resolution falls back to `PATH` while the packages are being stood up, and the missing-binary path degrades cleanly throughout.
+**Vale binary packaging** — resolved by `add-vale-binary-packages`. Six packages (`@taskless/vale-{darwin,linux,win32}-{arm64,x64}`) are published at `3.17.1-20260810052605` and pinned as `optionalDependencies`, with a CI job mirroring upstream Vale releases. No musl variant is published, so Alpine keeps the `PATH` fallback deliberately. Only the runtime resolution (task 1.1) remains here.
 
 The three revisited items are resolved: Vale rule-tests use per-rule `pass/`/`fail/` subdirectories with a verify-time-**generated** isolating `.vale.ini` (mirroring ast-grep's valid/invalid); Taskless breadcrumbs in `.vale.ini` use the `tskl) <name> = <value>` namespace (all namespaced key syntaxes verified tolerated); and the runtime tier is **realigned** to `runtime/` in this change (content-preserving move).
 
diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
index 98c7c164..e69f8a72 100644
--- a/openspec/changes/add-vale-rule-engine/tasks.md
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -5,11 +5,7 @@
 
 ## 1. Vale engine
 
-- [ ] 1.1 Extract the platform-binary resolution in `findSgBinary()` (`rules/scan.ts:38-61`) into a shared helper — resolve `<pkg>/package.json` via `createRequire(import.meta.url)`, exec the binary beside it, fall back to `PATH` — and use it for both `sg` and `vale`. When nothing resolves, report the Vale engine unavailable without aborting other engines (D6b)
-- [ ] 1.1b Publish per-platform Vale binary packages under the Taskless scope: binary in the tarball, `os`/`cpu` declared, **no `bin`, no code, no scripts** (we exec by path, so nothing needs hardlinking into place). Add them to `packages/cli` as `optionalDependencies`. Include Vale's MIT attribution. Do NOT depend on a download-at-postinstall package: the script runs under the consumer's package-manager policy, and pnpm 10 blocks it by default, yielding no binary and no error
-- [ ] 1.1c CI job to mirror upstream Vale releases into those packages; decide the architecture set (ast-grep's seven is the starting point) and pin the Vale version the CLI expects
-- [ ] 1.1d Handle musl: `findSgBinary()` maps every Linux to `-gnu`, so Alpine falls through to `PATH` today. Detect libc for the Vale lookup (upstream ast-grep uses `detect-libc`) and decide whether to publish a musl variant or leave the `PATH` fallback deliberately
-- [ ] 1.1e Confirm the Vite build externalizes the platform packages rather than bundling them, and that `createRequire(import.meta.url)` resolves correctly from `dist/` — the same context `findSgBinary()` already relies on
+- [ ] 1.1 Extract the platform-binary resolution in `findSgBinary()` (`rules/scan.ts:38-61`) into a shared helper — resolve `<pkg>/package.json` via `createRequire(import.meta.url)`, exec the binary beside it, fall back to `PATH` — and use it for both `sg` and `vale`. Parameterize the package name rather than reusing ast-grep's: `add-vale-binary-packages` ships `@taskless/vale-<os>-<cpu>` with no libc suffix, so the `-gnu` mapping `findSgBinary()` applies to every Linux must not be applied to the Vale lookup. When nothing resolves, report the Vale engine unavailable without aborting other engines (D6b)
 - [ ] 1.2 Add `rules/vale/run.ts`: run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit <paths>`, bounded by a subprocess timeout that terminates and reports on expiry
 - [ ] 1.3 Map Vale JSON findings → `CheckResult`: `source: "vale"`, `ruleId` = check name with `rules.` stripped, severity `error/warning/suggestion → error/warning/hint`, and `message`/`note`/`range`/`matchedText`/`fix` per the mapping
 - [ ] 1.4 Add `rules/vale/verify.ts`: for each `vale/rule-tests/<rule>/`, generate an ephemeral `.vale.ini` enabling only that rule, run Vale over `pass/`/`fail/` fixtures, assert every `fail/` yields a finding and every `pass/` none

From 88f6b6b3918a1119713fd9eb35916a6023d44c1e Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 10 Aug 2026 12:44:26 -0700
Subject: [PATCH 09/15] docs(openspec): tick the satisfied prerequisites, drop
 the missing seed path

0.1 and 0.2 both hold now: partition-rules-by-engine is archived on main as
2026-08-02-partition-rules-by-engine, and all six @taskless/vale-* packages are
published at 3.17.1-20260810052605 and pinned in packages/cli
optionalDependencies. Record what satisfies them rather than leaving the boxes
open for someone to re-derive.

Task 3.1 sourced the topic from tmp/SEED-engine-selection-prose.md, which no
longer exists. Treating a missing file as a prerequisite would block the unit on
recovering it; the content requirements are already stated in 3.1-3.4, so name
those as the authority and rebuild the examples.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 openspec/changes/add-vale-rule-engine/tasks.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
index e69f8a72..20a7d8da 100644
--- a/openspec/changes/add-vale-rule-engine/tasks.md
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -1,7 +1,7 @@
 ## 0. Prerequisites
 
-- [ ] 0.1 Confirm `partition-rules-by-engine` has landed: `.taskless/vale/` is scaffolded, dispatch routes by engine directory, and `check` runs ast-grep over the committed `sg/sgconfig.yml`. This change extends that layout; it does not create it
-- [ ] 0.2 Confirm the Vale platform packages from `add-vale-binary-packages` are published and declared, so there is a binary to resolve
+- [x] 0.1 Confirm `partition-rules-by-engine` has landed: `.taskless/vale/` is scaffolded, dispatch routes by engine directory, and `check` runs ast-grep over the committed `sg/sgconfig.yml`. This change extends that layout; it does not create it. Archived on `main` as `openspec/changes/archive/2026-08-02-partition-rules-by-engine`
+- [x] 0.2 Confirm the Vale platform packages from `add-vale-binary-packages` are published and declared, so there is a binary to resolve. All six `@taskless/vale-*` are published at `3.17.1-20260810052605` and pinned in `packages/cli` `optionalDependencies`
 
 ## 1. Vale engine
 
@@ -19,7 +19,7 @@
 
 ## 3. Engine-selection knowledge topic
 
-- [ ] 3.1 Author `packages/cli/src/help/<engine-selection>.txt` from the seed prose in `tmp/SEED-engine-selection-prose.md`: the three engine definitions (`sg` in-file syntax tree incl. relational correlation, `vale` prose/markup, `runtime` cross-file/graph/metadata/normalization), the reason-before-answer procedure, and the worked example table
+- [ ] 3.1 Author `packages/cli/src/help/<engine-selection>.txt` covering: the three engine definitions (`sg` in-file syntax tree incl. relational correlation, `vale` prose/markup, `runtime` cross-file/graph/metadata/normalization), the reason-before-answer procedure, and a worked example table. The original seed (`tmp/SEED-engine-selection-prose.md`) no longer exists — rebuild the examples rather than treating the file as a prerequisite; the content requirements are stated here and in 3.2–3.4, which is the authority
 - [ ] 3.2 State the ambiguity default as a property — the default names an engine known to be available — and note that `@ast-grep/cli` ships as a dependency while the Vale binary is external, so `sg` satisfies it locally
 - [ ] 3.3 Carry the three boundary cases: prose-about-code vs structure, Vale is per-document (cross-document prose consistency is `runtime`), and `sg`/`vale` are both static-tier so trust tier is a separate axis
 - [ ] 3.4 Keep the topic scoped to engine choice — no authoring-destination guidance, no tool-calling mechanics from the seed's source prompt

From fd4bb6d853ed6c2b7065af94ee74bbc7787b2ae7 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 10 Aug 2026 12:58:37 -0700
Subject: [PATCH 10/15] docs(openspec): settle the prompt export as TOPICS and
 fix the dangling ref
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

tasks.md deferred the export decision to "D9", which does not exist — the
design records D1-D7 and the reasoning lives in D7. Point at D7.

The conditional it carried ("whichever of this change and
export-knowledge-prompts lands second adds the entry") has resolved:
export-knowledge-prompts landed first, so the entry falls here. Restate it as
fact and add task 3.7 for it.

3.7 is not bookkeeping. TOPICS union INTERNAL_TOPICS must account for every
canonical recipe on disk, and test/prompts.test.ts asserts that in both
directions, so adding help/<engine-selection>.txt without classifying it turns
the suite red. The registration therefore belongs in the same unit as the topic
file rather than a later one.

D7 now records why TOPICS rather than INTERNAL_TOPICS, since the difference is
functional rather than a label: TOPICS generates the exported PromptTopic union,
the argument getPrompt() accepts, and the keys of the published PROMPTS record,
so an entry there is what makes the topic renderable outside this package.
INTERNAL_TOPICS has no runtime effect — it is a ledger for the completeness
check. Neither affects `taskless help`. The consumer is the reason: engine
selection currently lives in the platform generator as a binary static|runtime
classifier that predates Vale, and exporting the entry is what lets the
generator render the same text instead of drifting from it. The accepted cost is
that an exported name is a promise held for a major version.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 openspec/changes/add-vale-rule-engine/design.md | 6 +++++-
 openspec/changes/add-vale-rule-engine/tasks.md  | 3 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/openspec/changes/add-vale-rule-engine/design.md b/openspec/changes/add-vale-rule-engine/design.md
index 991924c7..7729d390 100644
--- a/openspec/changes/add-vale-rule-engine/design.md
+++ b/openspec/changes/add-vale-rule-engine/design.md
@@ -92,7 +92,11 @@ Three constraints shape the text, each from a real failure mode:
 - **Engine selection is not trust tier.** `sg` and `vale` are both static-tier; only `runtime` involves login, reconcile, and signing. Conflating the two axes is precisely what the platform's binary prompt got wrong, and it is why "static vs runtime" cannot simply be renamed.
 - **The ambiguity default must name an available engine.** Stated as that property rather than as a bare fact about `sg`. With both binaries shipped as dependencies (D6b), `sg` and `vale` are normally both available locally, and the property is satisfied rather than strained — but it still binds on an unsupported architecture or a blocked install, where the `PATH` fallback may find nothing. On the service the same conclusion follows from a different cause: `sg` is the only ungated route. Writing the rule as a property keeps one sentence correct across all three situations.
 
-Exporting the topic through `@taskless/cli/prompts` is deliberately **not** coupled to this change: the export mechanism is a separate change, and the topic file is useful to the local `help` flow with or without it. Whichever lands second adds the one-line `TOPICS` entry.
+Exporting the topic through `@taskless/cli/prompts` was deliberately **not** coupled to this change: the export mechanism is a separate change, and the topic file is useful to the local `help` flow with or without it. That ordering has since resolved — `export-knowledge-prompts` landed first, so the one-line entry falls here.
+
+It goes in `TOPICS`, not `INTERNAL_TOPICS`, and the distinction is functional rather than a label. `TOPICS` generates the exported `PromptTopic` union, the argument `getPrompt()` accepts, and the keys of the published `PROMPTS` record — so an entry there is what makes the topic renderable by a consumer outside this package. `INTERNAL_TOPICS` has no runtime effect at all; it is a ledger that lets the completeness check account for a recipe deliberately withheld. Neither list affects `taskless help`, which resolves recipes directly.
+
+The consumer is the reason. This topic exists because engine selection currently lives in the platform generator as a binary `static | runtime` classifier that predates Vale — that is, a second copy of this decision, now wrong. Exporting the entry is what lets the generator render the same text `help` serves rather than maintaining its own; withholding it would leave the two free to drift, which is the failure the prompts module exists to prevent. The cost accepted in exchange: an exported name is a promise held for a major version, so removing it later is a breaking change.
 
 - **Alternative — a separate follow-on change for the topic:** rejected; it would leave a release where `check` dispatches three engines while every recipe still assumes ast-grep, and the topic is knowledge about the engine rather than a deliverable of its own.
 
diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
index 20a7d8da..a6666e1e 100644
--- a/openspec/changes/add-vale-rule-engine/tasks.md
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -25,8 +25,9 @@
 - [ ] 3.4 Keep the topic scoped to engine choice — no authoring-destination guidance, no tool-calling mechanics from the seed's source prompt
 - [ ] 3.5 Register the topic in the help index and add `route`/`static` cross-references to it
 - [ ] 3.6 Tests: the topic resolves via `taskless help` and appears in the index; the topic file matches the established recipe header/format convention
+- [ ] 3.7 Add the topic to `TOPICS` in `packages/cli/src/prompts/index.ts`, in the **same unit as the topic file**. This is not optional bookkeeping: `TOPICS ∪ INTERNAL_TOPICS` must account for every canonical recipe on disk, and `test/prompts.test.ts` asserts that in both directions — so a recipe file added without a classification turns the suite red. `TOPICS` rather than `INTERNAL_TOPICS` per D7: the platform generator is the intended consumer, and exporting the entry is what lets it render the same text `taskless help` serves instead of keeping its own copy
 
-> Export via `@taskless/cli/prompts` is not part of this change (see D9). Whichever of this change and `export-knowledge-prompts` lands second adds the one-line `TOPICS` entry.
+> Export via `@taskless/cli/prompts` **is** part of this change (D7). `export-knowledge-prompts` landed first, so the one-line `TOPICS` entry falls here — see task 3.7.
 
 ## 4. Quality gates
 

From 2c6d5dfa362fddfa9201ab484f191e4bf57b725e Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 10 Aug 2026 14:03:32 -0700
Subject: [PATCH 11/15] ref(cli): share the platform-binary resolver between
 ast-grep and Vale
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Task 1.1. `findSgBinary()` hard-coded ast-grep's packaging: the `@ast-grep/cli`
prefix, the `-gnu`/`-msvc` suffixes, the two bin spellings, and an `ast-grep`
identity check. Vale needs the same search with different answers to all four,
so the search moves to `rules/platform-binary.ts` and each engine supplies a
spec.

The parameter that matters is `toolchainSuffix`. ast-grep publishes
`@ast-grep/cli-linux-x64-gnu`; add-vale-binary-packages publishes
`@taskless/vale-linux-x64` with no libc suffix at all. Reusing ast-grep's naming
for Vale would resolve nothing on Linux and surface as the ordinary "Vale is
unavailable" message — a naming bug wearing the costume of a host that never
installed it. test/platform-binary.test.ts pins the naming for both engines
across every published platform, and cross-checks the Vale names against the
optionalDependencies actually declared in package.json so a rename on either
side fails there rather than at runtime.

The resolver returns `{path, tried}` instead of throwing, because the two
callers need different things from a miss: ast-grep is the only executor for
`sg` rules, so `findSgBinary()` keeps throwing, while `findValeBinary()` returns
undefined per D6b — a missing Vale binary makes one engine unavailable and must
not abort the others. `findValeBinary()` caches the miss as well as the hit,
since an absent Vale is the common case and each resolution spawns a subprocess
per candidate.

ast-grep behaviour is unchanged: `isAstGrepBinary` and `findSgBinary` keep their
signatures and their existing tests, all 456 green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 packages/cli/src/rules/platform-binary.ts | 168 ++++++++++++++++++++++
 packages/cli/src/rules/scan.ts            | 106 +++++---------
 packages/cli/src/rules/vale/binary.ts     |  66 +++++++++
 packages/cli/test/platform-binary.test.ts | 103 +++++++++++++
 4 files changed, 370 insertions(+), 73 deletions(-)
 create mode 100644 packages/cli/src/rules/platform-binary.ts
 create mode 100644 packages/cli/src/rules/vale/binary.ts
 create mode 100644 packages/cli/test/platform-binary.test.ts

diff --git a/packages/cli/src/rules/platform-binary.ts b/packages/cli/src/rules/platform-binary.ts
new file mode 100644
index 00000000..bdb5232f
--- /dev/null
+++ b/packages/cli/src/rules/platform-binary.ts
@@ -0,0 +1,168 @@
+import { spawnSync } from "node:child_process";
+import { existsSync } from "node:fs";
+import { createRequire } from "node:module";
+import { dirname, resolve } from "node:path";
+import { fileURLToPath } from "node:url";
+
+/**
+ * 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.
+   */
+  binaryNames: string[];
+  /** Pattern the candidate's own `--version` output must match. */
+  identity: RegExp;
+}
+
+/** The npm package carrying this host's prebuilt binary. */
+export function platformPackageName(spec: PlatformBinarySpec): string {
+  const parts: string[] = [process.platform, process.arch];
+  if (spec.toolchainSuffix) {
+    if (process.platform === "linux") {
+      parts.push("gnu");
+    } else if (process.platform === "win32") {
+      parts.push("msvc");
+    }
+  }
+  return `${spec.packagePrefix}-${parts.join("-")}`;
+}
+
+/** Executable name for this platform. */
+function executableName(name: string): string {
+  return process.platform === "win32" ? `${name}.exe` : name;
+}
+
+/** Absolute path to a binary inside the resolved platform package, if any. */
+function platformPackageBinary(
+  spec: PlatformBinarySpec,
+  binary: string
+): string | undefined {
+  try {
+    const require = createRequire(import.meta.url);
+    const packageJsonPath = require.resolve(
+      `${platformPackageName(spec)}/package.json`
+    );
+    return resolve(dirname(packageJsonPath), binary);
+  } catch {
+    // Not installed for this host: an unsupported arch, or musl, where neither
+    // project publishes a build and `os`/`cpu` filtering skips the package.
+    return undefined;
+  }
+}
+
+/** First entry on PATH that holds a file named `command`. */
+export function findOnPath(command: string): string | undefined {
+  const separator = process.platform === "win32" ? ";" : ":";
+  for (const directory of (process.env.PATH ?? "").split(separator)) {
+    if (directory === "") continue;
+    const candidate = resolve(directory, command);
+    if (existsSync(candidate)) return candidate;
+  }
+  return 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 function isPlatformBinary(
+  spec: PlatformBinarySpec,
+  path: string
+): boolean {
+  if (!existsSync(path)) return false;
+  const result = spawnSync(path, ["--version"], {
+    encoding: "utf8",
+    timeout: 5000,
+  });
+  if (result.error !== undefined || result.status !== 0) return false;
+  return spec.identity.test(`${result.stdout ?? ""}${result.stderr ?? ""}`);
+}
+
+export interface PlatformBinaryResolution {
+  /** Absolute path to the verified binary, or `undefined` when none resolved. */
+  path: string | 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.
+ *
+ * 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 function resolvePlatformBinary(
+  spec: PlatformBinarySpec
+): PlatformBinaryResolution {
+  const localBin = resolve(
+    dirname(fileURLToPath(import.meta.url)),
+    "..",
+    "node_modules",
+    ".bin"
+  );
+
+  const candidates: Array<[label: string, path: string | undefined]> = [
+    ...spec.binaryNames.map((name): [string, string | undefined] => [
+      platformPackageName(spec),
+      platformPackageBinary(spec, executableName(name)),
+    ]),
+    ...spec.binaryNames.map((name): [string, string | undefined] => [
+      "node_modules/.bin",
+      resolve(localBin, executableName(name)),
+    ]),
+    ...spec.binaryNames.map((name): [string, string | undefined] => [
+      "PATH",
+      findOnPath(executableName(name)),
+    ]),
+  ];
+
+  for (const [, path] of candidates) {
+    if (path !== undefined && isPlatformBinary(spec, path)) {
+      return { path, tried: candidates.map(([label]) => label) };
+    }
+  }
+
+  return { path: undefined, tried: candidates.map(([label]) => label) };
+}
diff --git a/packages/cli/src/rules/scan.ts b/packages/cli/src/rules/scan.ts
index 584ca7c5..7c4efd9b 100644
--- a/packages/cli/src/rules/scan.ts
+++ b/packages/cli/src/rules/scan.ts
@@ -1,6 +1,4 @@
-import { existsSync } from "node:fs";
-import { createRequire } from "node:module";
-import { spawn, spawnSync } from "node:child_process";
+import { spawn } from "node:child_process";
 import { dirname, resolve } from "node:path";
 import { createInterface } from "node:readline";
 import { fileURLToPath } from "node:url";
@@ -8,6 +6,11 @@ import { fileURLToPath } from "node:url";
 import type { AstGrepMatch } from "../types/check";
 import { toCheckResult, type CheckResult } from "../types/check";
 import { COMMITTED_SG_CONFIG } from "./engines";
+import {
+  isPlatformBinary,
+  resolvePlatformBinary,
+  type PlatformBinarySpec,
+} from "./platform-binary";
 
 export interface ScanResult {
   results: CheckResult[];
@@ -30,42 +33,23 @@ export function buildPath(): string {
   return `${binDirectory}${separator}${process.env.PATH ?? ""}`;
 }
 
-/** The npm package carrying this host's prebuilt ast-grep binary. */
-function platformPackageName(): string {
-  const parts: string[] = [process.platform, process.arch];
-  if (process.platform === "linux") {
-    parts.push("gnu");
-  } else if (process.platform === "win32") {
-    parts.push("msvc");
-  }
-  return `@ast-grep/cli-${parts.join("-")}`;
-}
-
-/** Absolute path to the binary inside the resolved platform package, if any. */
-function platformPackageBinary(binary: string): string | undefined {
-  try {
-    const require = createRequire(import.meta.url);
-    const packageJsonPath = require.resolve(
-      `${platformPackageName()}/package.json`
-    );
-    return resolve(dirname(packageJsonPath), binary);
-  } catch {
-    // Not installed for this host (unsupported arch, or musl — upstream
-    // publishes no musl package and marks the gnu ones `libc: [glibc]`).
-    return undefined;
-  }
-}
-
-/** First entry on PATH that holds a file named `command`. */
-function findOnPath(command: string): string | undefined {
-  const separator = process.platform === "win32" ? ";" : ":";
-  for (const directory of (process.env.PATH ?? "").split(separator)) {
-    if (directory === "") continue;
-    const candidate = resolve(directory, command);
-    if (existsSync(candidate)) return candidate;
-  }
-  return undefined;
-}
+/**
+ * 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.
+ */
+export const AST_GREP_BINARY: PlatformBinarySpec = {
+  label: "ast-grep",
+  packagePrefix: "@ast-grep/cli",
+  toolchainSuffix: true,
+  binaryNames: ["ast-grep", "sg"],
+  identity: /ast-grep/i,
+};
 
 /**
  * Whether `path` is really ast-grep, established by running it.
@@ -78,13 +62,7 @@ function findOnPath(command: string): string | undefined {
  * binary from a file merely sitting where the binary belongs.
  */
 export function isAstGrepBinary(path: string): boolean {
-  if (!existsSync(path)) return false;
-  const result = spawnSync(path, ["--version"], {
-    encoding: "utf8",
-    timeout: 5000,
-  });
-  if (result.error !== undefined || result.status !== 0) return false;
-  return /ast-grep/i.test(`${result.stdout ?? ""}${result.stderr ?? ""}`);
+  return isPlatformBinary(AST_GREP_BINARY, path);
 }
 
 /**
@@ -113,36 +91,18 @@ let cachedSgBinary: string | undefined;
 export function findSgBinary(): string {
   if (cachedSgBinary !== undefined) return cachedSgBinary;
 
-  const binary = process.platform === "win32" ? "ast-grep.exe" : "ast-grep";
-  const alternative = process.platform === "win32" ? "sg.exe" : "sg";
-  const localBin = resolve(
-    dirname(fileURLToPath(import.meta.url)),
-    "..",
-    "node_modules",
-    ".bin"
-  );
-
-  const candidates: Array<[label: string, path: string | undefined]> = [
-    [platformPackageName(), platformPackageBinary(binary)],
-    // Both names, matching the PATH search below: the wrapper declares `sg` and
-    // `ast-grep` as bin entries for the same target, so either may be linked.
-    ["node_modules/.bin", resolve(localBin, alternative)],
-    ["node_modules/.bin", resolve(localBin, binary)],
-    ["PATH", findOnPath(alternative)],
-    ["PATH", findOnPath(binary)],
-  ];
-
-  for (const [, path] of candidates) {
-    if (path !== undefined && isAstGrepBinary(path)) {
-      cachedSgBinary = path;
-      return path;
-    }
+  const { path, tried } = resolvePlatformBinary(AST_GREP_BINARY);
+  if (path !== undefined) {
+    cachedSgBinary = path;
+    return path;
   }
 
-  const tried = candidates.map(([label]) => label).join(", ");
+  // ast-grep, unlike Vale, has no degraded mode: it is the executor for every
+  // `sg` rule, so a miss is fatal for this command rather than one engine
+  // reporting itself unavailable.
   throw new Error(
-    `ast-grep binary not found. Looked in: ${tried}. Install a supported ` +
-      `platform build, or put \`${alternative}\` on your PATH.`
+    `ast-grep binary not found. Looked in: ${tried.join(", ")}. Install a ` +
+      `supported platform build, or put \`sg\` on your PATH.`
   );
 }
 
diff --git a/packages/cli/src/rules/vale/binary.ts b/packages/cli/src/rules/vale/binary.ts
new file mode 100644
index 00000000..c0b0c883
--- /dev/null
+++ b/packages/cli/src/rules/vale/binary.ts
@@ -0,0 +1,66 @@
+import {
+  resolvePlatformBinary,
+  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 const VALE_BINARY: PlatformBinarySpec = {
+  label: "vale",
+  packagePrefix: "@taskless/vale",
+  toolchainSuffix: false,
+  binaryNames: ["vale"],
+  identity: /vale/i,
+};
+
+/**
+ * Resolution is cached for the process, including a miss.
+ *
+ * Caching the miss matters as much as caching the hit: resolution spawns a
+ * subprocess per candidate, and an absent Vale is the common case on a host
+ * that never installed it. Without this, every rule would re-run the whole
+ * search to rediscover the same nothing.
+ */
+let cached: { path: string | undefined; tried: string[] } | undefined;
+
+/**
+ * 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 function findValeBinary(): {
+  path: string | undefined;
+  tried: string[];
+} {
+  cached ??= resolvePlatformBinary(VALE_BINARY);
+  return cached;
+}
+
+/** Reset the process cache. Tests only. */
+export function resetValeBinaryCache(): void {
+  cached = undefined;
+}
+
+/** An actionable message naming where we looked. */
+export function valeUnavailableMessage(tried: string[]): string {
+  return (
+    `Vale binary not found. Looked in: ${tried.join(", ")}. Install a ` +
+    `supported platform build, or put \`vale\` on your PATH. Other engines ` +
+    `still ran.`
+  );
+}
diff --git a/packages/cli/test/platform-binary.test.ts b/packages/cli/test/platform-binary.test.ts
new file mode 100644
index 00000000..bdcf2288
--- /dev/null
+++ b/packages/cli/test/platform-binary.test.ts
@@ -0,0 +1,103 @@
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+import { describe, expect, it } from "vitest";
+
+import { AST_GREP_BINARY } from "../src/rules/scan";
+import { platformPackageName } from "../src/rules/platform-binary";
+import { VALE_BINARY } from "../src/rules/vale/binary";
+
+/**
+ * The two engines' packages are named differently, and the difference is not
+ * cosmetic: ast-grep publishes a libc/toolchain suffix and Vale does not.
+ * Sharing one resolver made that a parameter, and a parameter is exactly the
+ * kind of thing a later refactor "simplifies" back into a single naming rule.
+ *
+ * These assert the naming for every platform the packages are published for,
+ * because the failure they guard against is silent — a Vale lookup that appends
+ * `-gnu` resolves nothing on Linux and reports the ordinary "Vale is
+ * unavailable" message, so a naming bug is indistinguishable from a host that
+ * never installed it.
+ */
+
+/** Run `body` as if the process were on `platform`/`arch`. */
+function onPlatform<T>(platform: string, arch: string, body: () => T): T {
+  const originalPlatform = Object.getOwnPropertyDescriptor(
+    process,
+    "platform"
+  ) as PropertyDescriptor;
+  const originalArch = Object.getOwnPropertyDescriptor(
+    process,
+    "arch"
+  ) as PropertyDescriptor;
+  Object.defineProperty(process, "platform", { value: platform });
+  Object.defineProperty(process, "arch", { value: arch });
+  try {
+    return body();
+  } finally {
+    Object.defineProperty(process, "platform", originalPlatform);
+    Object.defineProperty(process, "arch", originalArch);
+  }
+}
+
+describe("platform package naming", () => {
+  it("gives Vale no libc suffix on linux", () => {
+    // The trap: `@taskless/vale-linux-x64-gnu` does not exist and never will.
+    expect(
+      onPlatform("linux", "x64", () => platformPackageName(VALE_BINARY))
+    ).toBe("@taskless/vale-linux-x64");
+    expect(
+      onPlatform("linux", "arm64", () => platformPackageName(VALE_BINARY))
+    ).toBe("@taskless/vale-linux-arm64");
+  });
+
+  it("gives Vale no toolchain suffix on win32", () => {
+    expect(
+      onPlatform("win32", "x64", () => platformPackageName(VALE_BINARY))
+    ).toBe("@taskless/vale-win32-x64");
+  });
+
+  it("still appends ast-grep's gnu/msvc suffixes", () => {
+    expect(
+      onPlatform("linux", "x64", () => platformPackageName(AST_GREP_BINARY))
+    ).toBe("@ast-grep/cli-linux-x64-gnu");
+    expect(
+      onPlatform("win32", "x64", () => platformPackageName(AST_GREP_BINARY))
+    ).toBe("@ast-grep/cli-win32-x64-msvc");
+  });
+
+  it("appends no suffix for either engine on darwin", () => {
+    expect(
+      onPlatform("darwin", "arm64", () => platformPackageName(AST_GREP_BINARY))
+    ).toBe("@ast-grep/cli-darwin-arm64");
+    expect(
+      onPlatform("darwin", "arm64", () => platformPackageName(VALE_BINARY))
+    ).toBe("@taskless/vale-darwin-arm64");
+  });
+
+  it("names a package the CLI actually declares, for every Vale platform", () => {
+    // Ties the naming rule to the pins in package.json rather than restating
+    // it, so a rename on either side fails here instead of at runtime.
+    const manifest = JSON.parse(
+      readFileSync(join(import.meta.dirname, "..", "package.json"), "utf8")
+    ) as { optionalDependencies: Record<string, string> };
+    const declared = Object.keys(manifest.optionalDependencies).filter((name) =>
+      name.startsWith("@taskless/vale-")
+    );
+
+    const generated = (
+      [
+        ["darwin", "arm64"],
+        ["darwin", "x64"],
+        ["linux", "arm64"],
+        ["linux", "x64"],
+        ["win32", "arm64"],
+        ["win32", "x64"],
+      ] as const
+    ).map(([platform, arch]) =>
+      onPlatform(platform, arch, () => platformPackageName(VALE_BINARY))
+    );
+
+    expect(generated.toSorted()).toEqual(declared.toSorted());
+  });
+});

From 89ba25f8df37d4fb5cc1f214a76f4626b3e68874 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 10 Aug 2026 14:50:47 -0700
Subject: [PATCH 12/15] feat(cli): run Vale over the committed config and map
 its findings
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Tasks 1.2 and 1.3. `rules/vale/run.ts` invokes the resolved binary with
`--config .taskless/vale/.vale.ini --output=JSON --no-exit`, and
`rules/vale/map.ts` turns what comes back into CheckResults.

`--no-exit` is what makes the exit code readable: without it Vale exits non-zero
merely for having found something, which is indistinguishable from failing to
run. With it, non-zero means Vale itself failed.

The result is an outcome union rather than "results or throw". Three of its four
cases — unavailable, timeout, failed — are things the caller reports and keeps
going from, and under D6b the orchestration layer has to tell "Vale found
nothing" from "Vale never ran", a distinction an empty array erases.

Mapping decisions worth naming:

- `rules.` is stripped from the check name. The style directory is called
  `rules`, so Vale reports `rules.no-simply` for what a user wrote as
  `no-simply`; the prefix is an artifact of config layout, not part of the id.
- An unrecognized severity becomes `warning` rather than being dropped. A
  finding whose level we cannot read is still a finding.
- `fix` comes only from a `replace` action's replacement. Vale's other actions
  describe an edit whose result is not in the payload, so putting the action
  name there would offer to replace the user's match with the word "remove".

The JSON shape was captured from the real binary rather than assumed —
`Action: {Name: "", Params: null}`, `Span`, `Line`, capitalized keys — and the
tests run the real Vale rather than a stub, since what is being asserted is what
Vale does with a config. It ships as an optionalDependency for every platform we
publish, so those cases run in CI too; they skip only on an unsupported arch,
where a stub would be asserting our own mock.

Covers the non-verify half of 1.5: stripping and severity mapping, all three
scoping cases (include, exclude-wins, duplicate matchers merge), missing-binary,
and timeout. The verify half needs 1.4 and lands in unit 2; 1.5 is annotated
rather than ticked so that stays visible.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 .../changes/add-vale-rule-engine/tasks.md     |   8 +-
 packages/cli/src/rules/vale/map.ts            | 131 ++++++++++++
 packages/cli/src/rules/vale/run.ts            | 161 ++++++++++++++
 packages/cli/test/vale-map.test.ts            | 151 +++++++++++++
 packages/cli/test/vale-run.test.ts            | 202 ++++++++++++++++++
 5 files changed, 649 insertions(+), 4 deletions(-)
 create mode 100644 packages/cli/src/rules/vale/map.ts
 create mode 100644 packages/cli/src/rules/vale/run.ts
 create mode 100644 packages/cli/test/vale-map.test.ts
 create mode 100644 packages/cli/test/vale-run.test.ts

diff --git a/openspec/changes/add-vale-rule-engine/tasks.md b/openspec/changes/add-vale-rule-engine/tasks.md
index a6666e1e..3f7fb130 100644
--- a/openspec/changes/add-vale-rule-engine/tasks.md
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -5,11 +5,11 @@
 
 ## 1. Vale engine
 
-- [ ] 1.1 Extract the platform-binary resolution in `findSgBinary()` (`rules/scan.ts:38-61`) into a shared helper — resolve `<pkg>/package.json` via `createRequire(import.meta.url)`, exec the binary beside it, fall back to `PATH` — and use it for both `sg` and `vale`. Parameterize the package name rather than reusing ast-grep's: `add-vale-binary-packages` ships `@taskless/vale-<os>-<cpu>` with no libc suffix, so the `-gnu` mapping `findSgBinary()` applies to every Linux must not be applied to the Vale lookup. When nothing resolves, report the Vale engine unavailable without aborting other engines (D6b)
-- [ ] 1.2 Add `rules/vale/run.ts`: run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit <paths>`, bounded by a subprocess timeout that terminates and reports on expiry
-- [ ] 1.3 Map Vale JSON findings → `CheckResult`: `source: "vale"`, `ruleId` = check name with `rules.` stripped, severity `error/warning/suggestion → error/warning/hint`, and `message`/`note`/`range`/`matchedText`/`fix` per the mapping
+- [x] 1.1 Extract the platform-binary resolution in `findSgBinary()` (`rules/scan.ts:38-61`) into a shared helper — resolve `<pkg>/package.json` via `createRequire(import.meta.url)`, exec the binary beside it, fall back to `PATH` — and use it for both `sg` and `vale`. Parameterize the package name rather than reusing ast-grep's: `add-vale-binary-packages` ships `@taskless/vale-<os>-<cpu>` with no libc suffix, so the `-gnu` mapping `findSgBinary()` applies to every Linux must not be applied to the Vale lookup. When nothing resolves, report the Vale engine unavailable without aborting other engines (D6b)
+- [x] 1.2 Add `rules/vale/run.ts`: run `vale --config .taskless/vale/.vale.ini --output=JSON --no-exit <paths>`, bounded by a subprocess timeout that terminates and reports on expiry
+- [x] 1.3 Map Vale JSON findings → `CheckResult`: `source: "vale"`, `ruleId` = check name with `rules.` stripped, severity `error/warning/suggestion → error/warning/hint`, and `message`/`note`/`range`/`matchedText`/`fix` per the mapping
 - [ ] 1.4 Add `rules/vale/verify.ts`: for each `vale/rule-tests/<rule>/`, generate an ephemeral `.vale.ini` enabling only that rule, run Vale over `pass/`/`fail/` fixtures, assert every `fail/` yields a finding and every `pass/` none
-- [ ] 1.5 Tests: `rules.` stripping + severity mapping; committed-config scoping respected (include union, exclude disable, duplicate matchers merge); verify pass/fail; missing-binary and timeout paths
+- [ ] 1.5 Tests: `rules.` stripping + severity mapping; committed-config scoping respected (include union, exclude disable, duplicate matchers merge); verify pass/fail; missing-binary and timeout paths. **Partially complete — the verify half belongs with 1.4 and lands in unit 2.** Done in unit 1: `rules.` stripping and severity mapping (`test/vale-map.test.ts`), and against the real binary (`test/vale-run.test.ts`) all three scoping cases, the missing-binary path, and the timeout path
 
 ## 2. Check orchestration
 
diff --git a/packages/cli/src/rules/vale/map.ts b/packages/cli/src/rules/vale/map.ts
new file mode 100644
index 00000000..3bbda649
--- /dev/null
+++ b/packages/cli/src/rules/vale/map.ts
@@ -0,0 +1,131 @@
+import type { CheckResult } from "../../types/check";
+
+/**
+ * One finding as Vale emits it under `--output=JSON`.
+ *
+ * Field names are Vale's, capitalized, and are kept verbatim rather than
+ * normalized on the way in — a renamed field then fails to parse here instead
+ * of silently arriving as `undefined` three layers down.
+ */
+export interface ValeFinding {
+  Check: string;
+  Severity: string;
+  Message: string;
+  Description?: string;
+  Link?: string;
+  Line: number;
+  /** `[start, end]` columns, 1-based. */
+  Span: [number, number];
+  Match: string;
+  Action?: { Name?: string; Params?: string[] | null };
+}
+
+/** Vale's whole payload: findings keyed by the path they were found in. */
+export type ValeOutput = Record<string, ValeFinding[]>;
+
+/**
+ * Vale's severities, normalized to the scanner-agnostic set.
+ *
+ * `suggestion → hint` is the only one that renames. Vale's three levels do not
+ * include `info`, so nothing maps to it; a level we do not recognize becomes
+ * `warning` rather than being dropped, because a finding whose severity we
+ * cannot read is still a finding.
+ */
+export function normalizeSeverity(severity: string): CheckResult["severity"] {
+  switch (severity.toLowerCase()) {
+    case "error": {
+      return "error";
+    }
+    case "warning": {
+      return "warning";
+    }
+    case "suggestion": {
+      return "hint";
+    }
+    default: {
+      return "warning";
+    }
+  }
+}
+
+/**
+ * Strip the `rules.` prefix Vale prepends to every check in our StylesPath.
+ *
+ * The style directory is named `rules`, so Vale reports `rules.no-simply` for
+ * what Taskless calls `no-simply`. Stripping it here keeps `ruleId` the same
+ * identity a user wrote, filed under, and sees from ast-grep — the prefix is an
+ * artifact of Vale's config layout, not part of the rule's name.
+ */
+export function stripRulesPrefix(check: string): string {
+  return check.startsWith("rules.") ? check.slice("rules.".length) : check;
+}
+
+/**
+ * `Description` and `Link` both carry supporting detail, and either may be
+ * empty. Joined rather than picked so a rule that sets only one still surfaces
+ * it, and `undefined` when neither is set so the field stays absent rather than
+ * empty-stringed.
+ */
+function toNote(finding: ValeFinding): string | undefined {
+  const parts = [finding.Description, finding.Link].filter(
+    (part): part is string => typeof part === "string" && part.trim() !== ""
+  );
+  return parts.length > 0 ? parts.join(" ") : undefined;
+}
+
+/**
+ * A fix, but only from an action that actually carries a replacement.
+ *
+ * Vale's actions are a small vocabulary (`replace`, `remove`, `edit`, …) and
+ * only `replace` names the text to substitute. The others describe an edit
+ * whose result is not in the payload, so there is nothing honest to put in
+ * `fix`; emitting the action's name there would offer the user a "fix" that
+ * replaces their match with the word "remove".
+ */
+function toFix(finding: ValeFinding): string | undefined {
+  const action = finding.Action;
+  if (action?.Name !== "replace") return undefined;
+  const replacement = action.Params?.[0];
+  return typeof replacement === "string" ? replacement : undefined;
+}
+
+/**
+ * Map one Vale finding to the scanner-agnostic {@link CheckResult}.
+ *
+ * `range` collapses to a single line: Vale reports `Line` plus a `Span` of
+ * columns within it, and has no concept of a finding that crosses lines, so
+ * start and end share the line number. `Span` is 1-based and inclusive, which
+ * matches what ast-grep already emits for `column`.
+ */
+export function toValeCheckResult(
+  file: string,
+  finding: ValeFinding
+): CheckResult {
+  const [startColumn, endColumn] = finding.Span;
+  return {
+    source: "vale",
+    ruleId: stripRulesPrefix(finding.Check),
+    severity: normalizeSeverity(finding.Severity),
+    message: finding.Message,
+    note: toNote(finding),
+    file,
+    range: {
+      start: { line: finding.Line, column: startColumn },
+      end: { line: finding.Line, column: endColumn },
+    },
+    matchedText: finding.Match,
+    fix: toFix(finding),
+  };
+}
+
+/**
+ * Flatten Vale's whole payload into `CheckResult`s.
+ *
+ * Vale keys findings by path, so the file name lives on the outside and has to
+ * be pushed down onto each finding.
+ */
+export function toValeCheckResults(output: ValeOutput): CheckResult[] {
+  return Object.entries(output).flatMap(([file, findings]) =>
+    (findings ?? []).map((finding) => toValeCheckResult(file, finding))
+  );
+}
diff --git a/packages/cli/src/rules/vale/run.ts b/packages/cli/src/rules/vale/run.ts
new file mode 100644
index 00000000..695493ab
--- /dev/null
+++ b/packages/cli/src/rules/vale/run.ts
@@ -0,0 +1,161 @@
+import { spawn } from "node:child_process";
+import { join } from "node:path";
+
+import type { CheckResult } from "../../types/check";
+import { ENGINE_LAYOUTS } from "../engines";
+import { buildPath } from "../scan";
+import { findValeBinary, valeUnavailableMessage } from "./binary";
+import { toValeCheckResults, type ValeOutput } from "./map";
+
+/** The committed Vale config, relative to the project root. */
+export const COMMITTED_VALE_CONFIG = `.taskless/${ENGINE_LAYOUTS.vale.configFile}`;
+
+/**
+ * How long a single Vale invocation may run before it is killed.
+ *
+ * Vale is fast on ordinary corpora; a run that reaches this has found something
+ * pathological (a runaway `script` check, a file that never ends). The number
+ * is a ceiling on damage, not a performance target.
+ */
+export const VALE_TIMEOUT_MS = 60_000;
+
+/**
+ * What a Vale run produced.
+ *
+ * Modeled as an outcome rather than "results or exception" because three of the
+ * four cases are things the caller reports and keeps going from. Under D6b an
+ * unavailable Vale must not abort the other engines, so the orchestration layer
+ * needs to tell "Vale found nothing" from "Vale never ran" — a distinction an
+ * empty array erases.
+ */
+export type ValeRunOutcome =
+  | { status: "ok"; results: CheckResult[] }
+  | { status: "unavailable"; message: string }
+  | { status: "timeout"; message: string }
+  | { status: "failed"; message: string };
+
+export interface ValeRunOptions {
+  /** Project root. Vale runs here, so its config paths resolve as committed. */
+  cwd: string;
+  /** Target paths, relative to `cwd`. Empty means Vale's own default set. */
+  paths?: string[];
+  /** Config path relative to `cwd`. Defaults to the committed engine config. */
+  configPath?: string;
+  timeoutMs?: number;
+}
+
+/**
+ * Run Vale over `paths` using the committed config, and map what it reports.
+ *
+ * `--no-exit` is what makes the exit code readable: without it Vale exits
+ * non-zero merely because it found something, which is indistinguishable from
+ * failing to run. With it, a non-zero exit means Vale itself failed.
+ *
+ * The config is read as committed rather than generated per run — it is the
+ * source of truth for scoping (matchers), and rewriting it at check time would
+ * mean the file a user edits is not the file that executes.
+ */
+export async function runVale(
+  options: ValeRunOptions
+): Promise<ValeRunOutcome> {
+  const { path: binary, tried } = findValeBinary();
+  if (binary === undefined) {
+    return { status: "unavailable", message: valeUnavailableMessage(tried) };
+  }
+
+  const configPath = options.configPath ?? COMMITTED_VALE_CONFIG;
+  const paths = options.paths ?? [];
+  const timeoutMs = options.timeoutMs ?? VALE_TIMEOUT_MS;
+
+  // `--` separates flags from positional paths, so a path beginning with `-`
+  // is not read as a flag.
+  const argv = [
+    "--config",
+    configPath,
+    "--output=JSON",
+    "--no-exit",
+    ...(paths.length > 0 ? ["--", ...paths] : []),
+  ];
+
+  return new Promise<ValeRunOutcome>((resolve) => {
+    const child = spawn(binary, argv, {
+      cwd: options.cwd,
+      stdio: ["ignore", "pipe", "pipe"],
+      env: { ...process.env, PATH: buildPath() },
+    });
+
+    const stdoutChunks: string[] = [];
+    const stderrChunks: string[] = [];
+    let settled = false;
+
+    /** Resolve once. A timeout kill also fires `close`, which must not win. */
+    const settle = (outcome: ValeRunOutcome): void => {
+      if (settled) return;
+      settled = true;
+      clearTimeout(timer);
+      resolve(outcome);
+    };
+
+    const timer = setTimeout(() => {
+      child.kill("SIGKILL");
+      settle({
+        status: "timeout",
+        message: `Vale exceeded ${String(timeoutMs)}ms and was terminated. The Vale engine reported a timeout; other engines were unaffected.`,
+      });
+    }, timeoutMs);
+    // Do not hold the event loop open on account of the timeout alone.
+    timer.unref?.();
+
+    child.stdout.on("data", (chunk: Buffer) => {
+      stdoutChunks.push(chunk.toString());
+    });
+    child.stderr.on("data", (chunk: Buffer) => {
+      stderrChunks.push(chunk.toString());
+    });
+
+    child.on("error", (error) => {
+      // Near-unreachable: the binary was verified by running it during
+      // resolution, so this means it vanished in between.
+      settle({
+        status: "unavailable",
+        message: `Vale could not be executed at ${binary}: ${error.message}`,
+      });
+    });
+
+    child.on("close", (code) => {
+      // With --no-exit, a non-zero code is Vale failing, not Vale finding.
+      if (code !== null && code !== 0) {
+        const stderr = stderrChunks.join("").trim();
+        settle({
+          status: "failed",
+          message: `Vale exited ${String(code)}${stderr === "" ? "" : `: ${stderr}`}`,
+        });
+        return;
+      }
+
+      const stdout = stdoutChunks.join("").trim();
+      if (stdout === "") {
+        // Vale prints nothing at all when it has no findings.
+        settle({ status: "ok", results: [] });
+        return;
+      }
+
+      try {
+        const parsed = JSON.parse(stdout) as ValeOutput;
+        settle({ status: "ok", results: toValeCheckResults(parsed) });
+      } catch (error) {
+        settle({
+          status: "failed",
+          message: `Vale produced output that is not JSON: ${
+            error instanceof Error ? error.message : String(error)
+          }`,
+        });
+      }
+    });
+  });
+}
+
+/** Absolute path of the committed Vale config for `cwd`. */
+export function valeConfigPath(cwd: string): string {
+  return join(cwd, COMMITTED_VALE_CONFIG);
+}
diff --git a/packages/cli/test/vale-map.test.ts b/packages/cli/test/vale-map.test.ts
new file mode 100644
index 00000000..dbfc50f4
--- /dev/null
+++ b/packages/cli/test/vale-map.test.ts
@@ -0,0 +1,151 @@
+import { describe, expect, it } from "vitest";
+
+import {
+  normalizeSeverity,
+  stripRulesPrefix,
+  toValeCheckResult,
+  toValeCheckResults,
+  type ValeFinding,
+} from "../src/rules/vale/map";
+
+/** The finding from the spec's worked example, as Vale emits it. */
+const example: ValeFinding = {
+  Check: "rules.no-simply",
+  Severity: "warning",
+  Line: 3,
+  Span: [1, 7],
+  Message: "Avoid 'simply'",
+  Match: "simply",
+};
+
+describe("stripRulesPrefix", () => {
+  it("strips the StylesPath prefix Vale prepends", () => {
+    expect(stripRulesPrefix("rules.no-simply")).toBe("no-simply");
+  });
+
+  it("leaves a check that carries no prefix alone", () => {
+    expect(stripRulesPrefix("no-simply")).toBe("no-simply");
+  });
+
+  it("strips only the leading occurrence", () => {
+    // A rule may legitimately contain the substring; only the prefix is ours.
+    expect(stripRulesPrefix("rules.rules.thing")).toBe("rules.thing");
+    expect(stripRulesPrefix("house-rules.thing")).toBe("house-rules.thing");
+  });
+});
+
+describe("normalizeSeverity", () => {
+  it("maps Vale's three levels", () => {
+    expect(normalizeSeverity("error")).toBe("error");
+    expect(normalizeSeverity("warning")).toBe("warning");
+    // The only one that renames.
+    expect(normalizeSeverity("suggestion")).toBe("hint");
+  });
+
+  it("is case-insensitive", () => {
+    expect(normalizeSeverity("Suggestion")).toBe("hint");
+    expect(normalizeSeverity("ERROR")).toBe("error");
+  });
+
+  it("keeps an unrecognized level as a finding rather than dropping it", () => {
+    expect(normalizeSeverity("catastrophe")).toBe("warning");
+  });
+});
+
+describe("toValeCheckResult", () => {
+  it("maps the spec's worked example", () => {
+    expect(toValeCheckResult("docs/a.md", example)).toEqual({
+      source: "vale",
+      ruleId: "no-simply",
+      severity: "warning",
+      message: "Avoid 'simply'",
+      note: undefined,
+      file: "docs/a.md",
+      range: {
+        start: { line: 3, column: 1 },
+        end: { line: 3, column: 7 },
+      },
+      matchedText: "simply",
+      fix: undefined,
+    });
+  });
+
+  it("keeps a finding on one line, since Vale has no multi-line span", () => {
+    const result = toValeCheckResult("docs/a.md", example);
+    expect(result.range.start.line).toBe(result.range.end.line);
+  });
+
+  it("joins Description and Link into note, and omits it when both are empty", () => {
+    expect(
+      toValeCheckResult("a.md", { ...example, Description: "Say it plainly." })
+        .note
+    ).toBe("Say it plainly.");
+    expect(
+      toValeCheckResult("a.md", { ...example, Link: "https://example.test" })
+        .note
+    ).toBe("https://example.test");
+    expect(
+      toValeCheckResult("a.md", {
+        ...example,
+        Description: "Say it plainly.",
+        Link: "https://example.test",
+      }).note
+    ).toBe("Say it plainly. https://example.test");
+    expect(
+      toValeCheckResult("a.md", { ...example, Description: "", Link: "" }).note
+    ).toBeUndefined();
+  });
+
+  describe("fix", () => {
+    it("comes from a replace action's replacement", () => {
+      expect(
+        toValeCheckResult("a.md", {
+          ...example,
+          Action: { Name: "replace", Params: ["plainly"] },
+        }).fix
+      ).toBe("plainly");
+    });
+
+    it("is absent for an unpopulated action", () => {
+      expect(
+        toValeCheckResult("a.md", {
+          ...example,
+          Action: { Name: "", Params: null },
+        }).fix
+      ).toBeUndefined();
+    });
+
+    it("is absent for an action that carries no replacement text", () => {
+      // `remove` describes an edit whose result is not in the payload. Putting
+      // the action's name in `fix` would offer to replace the match with the
+      // word "remove".
+      expect(
+        toValeCheckResult("a.md", {
+          ...example,
+          Action: { Name: "remove", Params: [] },
+        }).fix
+      ).toBeUndefined();
+    });
+  });
+});
+
+describe("toValeCheckResults", () => {
+  it("pushes the file key down onto each finding", () => {
+    const results = toValeCheckResults({
+      "docs/a.md": [example],
+      "docs/b.md": [{ ...example, Check: "rules.no-very", Match: "very" }],
+    });
+    expect(results.map((result) => [result.file, result.ruleId])).toEqual([
+      ["docs/a.md", "no-simply"],
+      ["docs/b.md", "no-very"],
+    ]);
+  });
+
+  it("returns nothing for an empty payload", () => {
+    expect(toValeCheckResults({})).toEqual([]);
+  });
+
+  it("tolerates a file key with no findings", () => {
+    expect(toValeCheckResults({ "docs/a.md": [] })).toEqual([]);
+  });
+});
diff --git a/packages/cli/test/vale-run.test.ts b/packages/cli/test/vale-run.test.ts
new file mode 100644
index 00000000..64c55694
--- /dev/null
+++ b/packages/cli/test/vale-run.test.ts
@@ -0,0 +1,202 @@
+import { mkdtempSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+import { afterEach, describe, expect, it, vi } from "vitest";
+
+import { findValeBinary } from "../src/rules/vale/binary";
+import { runVale } from "../src/rules/vale/run";
+
+/**
+ * These run the real Vale binary. It ships as an `optionalDependency` for the
+ * host platform, so it is present on every platform we publish for — including
+ * CI — and absent only on an unsupported arch. Skipping there is the honest
+ * option: a stub would be asserting our own mock's behaviour, and the whole
+ * point of these cases is what Vale actually does with a config.
+ */
+const valeAvailable = findValeBinary().path !== undefined;
+const withVale = valeAvailable ? describe : describe.skip;
+
+const workspaces: string[] = [];
+
+afterEach(() => {
+  vi.restoreAllMocks();
+  while (workspaces.length > 0) {
+    rmSync(workspaces.pop() as string, { recursive: true, force: true });
+  }
+});
+
+/** A project with the committed Vale layout: `config` plus rule files. */
+function makeProject(
+  config: string,
+  rules: Record<string, string>,
+  documents: Record<string, string>
+): string {
+  const cwd = mkdtempSync(join(tmpdir(), "vale-run-"));
+  workspaces.push(cwd);
+  mkdirSync(join(cwd, ".taskless", "vale", "rules"), { recursive: true });
+  writeFileSync(join(cwd, ".taskless", "vale", ".vale.ini"), config);
+  for (const [name, body] of Object.entries(rules)) {
+    writeFileSync(join(cwd, ".taskless", "vale", "rules", `${name}.yml`), body);
+  }
+  for (const [path, body] of Object.entries(documents)) {
+    const full = join(cwd, path);
+    mkdirSync(join(full, ".."), { recursive: true });
+    writeFileSync(full, body);
+  }
+  return cwd;
+}
+
+const existenceRule = (token: string, message: string) =>
+  `extends: existence\nmessage: "${message}"\nlevel: warning\ntokens:\n  - ${token}\n`;
+
+/** StylesPath is relative to the config file, so `.` is `.taskless/vale/`. */
+const header = "StylesPath = .\nMinAlertLevel = suggestion\n";
+
+describe("runVale when the binary is missing", () => {
+  it("reports the engine unavailable instead of throwing", async () => {
+    // D6b: a missing Vale must not abort the run. The message has to name
+    // where we looked, or the user has nothing to act on.
+    const binary = await import("../src/rules/vale/binary");
+    vi.spyOn(binary, "findValeBinary").mockReturnValue({
+      path: undefined,
+      tried: ["@taskless/vale-darwin-arm64", "node_modules/.bin", "PATH"],
+    });
+
+    const outcome = await runVale({ cwd: process.cwd() });
+    expect(outcome.status).toBe("unavailable");
+    if (outcome.status !== "unavailable") return;
+    expect(outcome.message).toContain("Vale binary not found");
+    expect(outcome.message).toContain("PATH");
+  });
+});
+
+withVale("runVale against the real binary", () => {
+  it("maps a finding to a CheckResult", async () => {
+    const cwd = makeProject(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existenceRule("simply", "Avoid 'simply'") },
+      { "doc.md": "One\nTwo\nJust simply do it.\n" }
+    );
+
+    const outcome = await runVale({ cwd, paths: ["doc.md"] });
+    expect(outcome.status).toBe("ok");
+    if (outcome.status !== "ok") return;
+    expect(outcome.results).toHaveLength(1);
+    const result = outcome.results[0];
+    if (result === undefined) throw new Error("expected a finding");
+    expect(result).toMatchObject({
+      source: "vale",
+      // `rules.` stripped: the prefix is Vale's StylesPath artifact.
+      ruleId: "no-simply",
+      severity: "warning",
+      message: "Avoid 'simply'",
+      file: "doc.md",
+      matchedText: "simply",
+    });
+    expect(result.range.start.line).toBe(3);
+    expect(result.range.end.line).toBe(3);
+  });
+
+  it("produces no findings, and no error, on a clean document", async () => {
+    const cwd = makeProject(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existenceRule("simply", "Avoid 'simply'") },
+      { "doc.md": "Nothing objectionable here.\n" }
+    );
+
+    const outcome = await runVale({ cwd, paths: ["doc.md"] });
+    // Vale prints nothing at all when it finds nothing; that must read as an
+    // empty result rather than as unparseable output.
+    expect(outcome).toEqual({ status: "ok", results: [] });
+  });
+
+  it("normalizes suggestion to hint", async () => {
+    const cwd = makeProject(
+      `${header}\n[*.md]\nrules.soft = YES\n`,
+      {
+        soft: `extends: existence\nmessage: "Consider rewording"\nlevel: suggestion\ntokens:\n  - perhaps\n`,
+      },
+      { "doc.md": "It is perhaps fine.\n" }
+    );
+
+    const outcome = await runVale({ cwd, paths: ["doc.md"] });
+    expect(outcome.status).toBe("ok");
+    if (outcome.status !== "ok") return;
+    expect(outcome.results[0]?.severity).toBe("hint");
+  });
+
+  describe("committed-config scoping", () => {
+    const rules = {
+      "no-simply": existenceRule("simply", "Avoid 'simply'"),
+      "no-very": existenceRule("very", "Avoid 'very'"),
+    };
+    const documents = {
+      "marketing/a.md": "Just simply do it.\n",
+      "marketing/legacy/b.md": "Just simply do it.\n",
+      "api/c.md": "Just simply do it.\n",
+    };
+
+    it("scopes a rule to the paths its matcher includes", async () => {
+      const cwd = makeProject(
+        `${header}\n[marketing/**]\nrules.no-simply = YES\n`,
+        rules,
+        documents
+      );
+      const outcome = await runVale({
+        cwd,
+        paths: ["marketing", "api"],
+      });
+      expect(outcome.status).toBe("ok");
+      if (outcome.status !== "ok") return;
+      const files = outcome.results.map((result) => result.file);
+      expect(files).toContain("marketing/a.md");
+      expect(files).not.toContain("api/c.md");
+    });
+
+    it("lets a disable win over an enable, regardless of order", async () => {
+      const cwd = makeProject(
+        `${header}\n[marketing/**]\nrules.no-simply = YES\n\n[marketing/legacy/**]\nrules.no-simply = NO\n`,
+        rules,
+        documents
+      );
+      const outcome = await runVale({ cwd, paths: ["marketing"] });
+      expect(outcome.status).toBe("ok");
+      if (outcome.status !== "ok") return;
+      const files = outcome.results.map((result) => result.file);
+      expect(files).toContain("marketing/a.md");
+      expect(files).not.toContain("marketing/legacy/b.md");
+    });
+
+    it("merges duplicate matchers rather than letting the last one win", async () => {
+      // Two `[*.md]` sections each enabling a different rule. Vale unions
+      // them, so a document matching the glob runs both.
+      const cwd = makeProject(
+        `${header}\n[*.md]\nrules.no-simply = YES\n\n[*.md]\nrules.no-very = YES\n`,
+        rules,
+        { "doc.md": "Just simply do it, very quickly.\n" }
+      );
+      const outcome = await runVale({ cwd, paths: ["doc.md"] });
+      expect(outcome.status).toBe("ok");
+      if (outcome.status !== "ok") return;
+      expect(outcome.results.map((result) => result.ruleId).toSorted()).toEqual(
+        ["no-simply", "no-very"]
+      );
+    });
+  });
+
+  it("terminates and reports a timeout rather than hanging", async () => {
+    const cwd = makeProject(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existenceRule("simply", "Avoid 'simply'") },
+      { "doc.md": "Just simply do it.\n" }
+    );
+
+    // 1ms cannot survive process startup, so this exercises the kill path
+    // without needing a pathological corpus to provoke it.
+    const outcome = await runVale({ cwd, paths: ["doc.md"], timeoutMs: 1 });
+    expect(outcome.status).toBe("timeout");
+    if (outcome.status !== "timeout") return;
+    expect(outcome.message).toContain("terminated");
+  });
+});

From a3e6258a086cfe8cea876975eac5418424361b27 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 10 Aug 2026 15:46:27 -0700
Subject: [PATCH 13/15] feat(cli): separate a skipped Vale from a failed one,
 guard the config shape
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Two review points from unit 1.

`isValeFailure()` names which outcomes fail the check. The three non-ok cases
are not equivalent and collapsing them is wrong in both directions:
`unavailable` is a skip — an unsupported arch is an ordinary state, not evidence
the user's rules are wrong, and failing there makes `check` unrunnable on a
machine where ast-grep and runtime rules report fine. `timeout` and `failed` are
errors: Vale was present and asked to work, and reporting those as a skip lets a
broken rule file read as "no Vale findings", which is indistinguishable from a
clean run. Exported so orchestration (2.2) derives the exit code from one rule
rather than restating it.

The unknown-severity branch is future-proofing, now labelled as such: Vale
enforces its own vocabulary, rejecting anything outside
[suggestion warning error], so nothing reaches the default today.

Establishing that turned up Vale's config-error payload — a flat
{Line, Path, Text, Code, Span} object rather than findings-keyed-by-file.
Measured against the real binary: it goes to stderr with exit 2 and an empty
stdout, so the existing non-zero-exit branch already reports it and the shape
never reaches the mapper. (An earlier reading of "exit 0" was an artifact of
piping through `head`, which reports the pipe's status, with 2>&1 making stderr
look like stdout.)

The guard is kept as defence rather than a fix, because the failure mode if a
future Vale reports config errors on stdout is not a wrong answer but a crash:
mapping walks Object.entries over Line/Path/Code and calls .map on a number, and
an uncaught throw out of runVale would take the other engines with it (D6b).
Both the type guard and an Array.isArray check in the mapper are covered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 packages/cli/src/rules/vale/map.ts | 51 +++++++++++++++++++++++++++++-
 packages/cli/src/rules/vale/run.ts | 47 +++++++++++++++++++++++++--
 packages/cli/test/vale-map.test.ts | 39 +++++++++++++++++++++++
 packages/cli/test/vale-run.test.ts | 46 ++++++++++++++++++++++++++-
 4 files changed, 178 insertions(+), 5 deletions(-)

diff --git a/packages/cli/src/rules/vale/map.ts b/packages/cli/src/rules/vale/map.ts
index 3bbda649..eb2e2348 100644
--- a/packages/cli/src/rules/vale/map.ts
+++ b/packages/cli/src/rules/vale/map.ts
@@ -23,6 +23,50 @@ export interface ValeFinding {
 /** Vale's whole payload: findings keyed by the path they were found in. */
 export type ValeOutput = Record<string, ValeFinding[]>;
 
+/**
+ * Vale's *other* JSON payload: a configuration error.
+ *
+ * When a rule file is malformed, Vale emits one flat object like
+ * `{Line, Path, Text: "'level' must be one of [...]", Code: "E201", Span}`
+ * rather than findings-keyed-by-file.
+ *
+ * Measured against the real binary (a rule with an out-of-vocabulary `level`):
+ * it goes to **stderr** with **exit 2** and an empty stdout, so `runVale`'s
+ * non-zero-exit branch already reports it as a failure and this shape never
+ * reaches the mapper today.
+ *
+ * This guard is therefore defensive, not a fix for a live bug. It is cheap and
+ * worth keeping because the failure mode if Vale ever reports a config error on
+ * stdout is not a wrong answer but a crash: mapping it walks `Object.entries`
+ * over `Line`/`Path`/`Code` and calls `.map` on a number, and an uncaught throw
+ * out of `runVale` would take the other engines down with it (D6b).
+ */
+export interface ValeConfigError {
+  Code: string;
+  Text: string;
+  Path?: string;
+  Line?: number;
+}
+
+/**
+ * Recognize the config-error payload, so the caller can report it as a failure
+ * rather than crashing while mapping it.
+ *
+ * Keyed on `Code` + `Text` because those are what distinguish it: a findings
+ * payload's values are arrays, and its keys are file paths, so a top-level
+ * string `Code` cannot occur in one.
+ */
+export function asValeConfigError(
+  parsed: unknown
+): ValeConfigError | undefined {
+  if (typeof parsed !== "object" || parsed === null) return undefined;
+  const candidate = parsed as Partial<ValeConfigError>;
+  return typeof candidate.Code === "string" &&
+    typeof candidate.Text === "string"
+    ? (candidate as ValeConfigError)
+    : undefined;
+}
+
 /**
  * Vale's severities, normalized to the scanner-agnostic set.
  *
@@ -126,6 +170,11 @@ export function toValeCheckResult(
  */
 export function toValeCheckResults(output: ValeOutput): CheckResult[] {
   return Object.entries(output).flatMap(([file, findings]) =>
-    (findings ?? []).map((finding) => toValeCheckResult(file, finding))
+    // Defence in depth against the shape confusion {@link asValeConfigError}
+    // guards: callers should reject a config-error payload before reaching
+    // here, but a non-array value must never become a `.map` on a number.
+    Array.isArray(findings)
+      ? findings.map((finding) => toValeCheckResult(file, finding))
+      : []
   );
 }
diff --git a/packages/cli/src/rules/vale/run.ts b/packages/cli/src/rules/vale/run.ts
index 695493ab..3bd75bf9 100644
--- a/packages/cli/src/rules/vale/run.ts
+++ b/packages/cli/src/rules/vale/run.ts
@@ -5,7 +5,7 @@ import type { CheckResult } from "../../types/check";
 import { ENGINE_LAYOUTS } from "../engines";
 import { buildPath } from "../scan";
 import { findValeBinary, valeUnavailableMessage } from "./binary";
-import { toValeCheckResults, type ValeOutput } from "./map";
+import { asValeConfigError, toValeCheckResults, type ValeOutput } from "./map";
 
 /** The committed Vale config, relative to the project root. */
 export const COMMITTED_VALE_CONFIG = `.taskless/${ENGINE_LAYOUTS.vale.configFile}`;
@@ -34,6 +34,30 @@ export type ValeRunOutcome =
   | { status: "timeout"; message: string }
   | { status: "failed"; message: string };
 
+/**
+ * Whether an outcome should fail the check, as opposed to being reported and
+ * moved past.
+ *
+ * The three non-ok cases are not equivalent, and collapsing them would be
+ * wrong in both directions:
+ *
+ * - `unavailable` is a **skip**. The host has no Vale binary, which is an
+ *   ordinary state on an unsupported arch and not evidence of anything wrong
+ *   with the user's rules. Failing here would make `check` unrunnable on a
+ *   machine where ast-grep and runtime rules are perfectly able to report.
+ * - `timeout` and `failed` are **errors**. Vale was present and was asked to do
+ *   its job: it hung, crashed, or rejected the configuration. Reporting those
+ *   as a skip would let a broken rule file read as "no Vale findings", which is
+ *   indistinguishable from a clean run and is exactly how a silently disabled
+ *   engine gets shipped.
+ *
+ * Exported here rather than decided at the call site so orchestration (2.2)
+ * derives the exit code from one rule instead of restating it.
+ */
+export function isValeFailure(outcome: ValeRunOutcome): boolean {
+  return outcome.status === "timeout" || outcome.status === "failed";
+}
+
 export interface ValeRunOptions {
   /** Project root. Vale runs here, so its config paths resolve as committed. */
   cwd: string;
@@ -141,8 +165,25 @@ export async function runVale(
       }
 
       try {
-        const parsed = JSON.parse(stdout) as ValeOutput;
-        settle({ status: "ok", results: toValeCheckResults(parsed) });
+        const parsed: unknown = JSON.parse(stdout);
+
+        // A malformed rule makes Vale emit a config error and still exit 0, so
+        // this is the only place the difference is detectable.
+        const configError = asValeConfigError(parsed);
+        if (configError !== undefined) {
+          settle({
+            status: "failed",
+            message: `Vale rejected the configuration (${configError.Code}): ${configError.Text}${
+              configError.Path === undefined ? "" : ` in ${configError.Path}`
+            }`,
+          });
+          return;
+        }
+
+        settle({
+          status: "ok",
+          results: toValeCheckResults(parsed as ValeOutput),
+        });
       } catch (error) {
         settle({
           status: "failed",
diff --git a/packages/cli/test/vale-map.test.ts b/packages/cli/test/vale-map.test.ts
index dbfc50f4..744bd9e9 100644
--- a/packages/cli/test/vale-map.test.ts
+++ b/packages/cli/test/vale-map.test.ts
@@ -1,6 +1,7 @@
 import { describe, expect, it } from "vitest";
 
 import {
+  asValeConfigError,
   normalizeSeverity,
   stripRulesPrefix,
   toValeCheckResult,
@@ -149,3 +150,41 @@ describe("toValeCheckResults", () => {
     expect(toValeCheckResults({ "docs/a.md": [] })).toEqual([]);
   });
 });
+
+describe("asValeConfigError", () => {
+  /**
+   * Captured from the real binary by giving a rule `level: catastrophe`. Vale
+   * sends this to stderr with exit 2, so `runVale` reports it as a failure and
+   * it does not reach the mapper today; these cases pin the guard that keeps a
+   * future stdout-reported config error from crashing instead of reporting.
+   */
+  const configError = {
+    Line: 3,
+    Path: "/x/.taskless/vale/rules/bogus.yml",
+    Text: "'level' must be one of [suggestion warning error]",
+    Code: "E201",
+    Span: 1,
+  };
+
+  it("recognizes the config-error payload", () => {
+    expect(asValeConfigError(configError)?.Code).toBe("E201");
+  });
+
+  it("does not mistake a findings payload for one", () => {
+    expect(asValeConfigError({ "docs/a.md": [example] })).toBeUndefined();
+    expect(asValeConfigError({})).toBeUndefined();
+    expect(asValeConfigError(null)).toBeUndefined();
+  });
+
+  it("does not throw when a config error reaches the mapper anyway", () => {
+    // Without the Array.isArray guard this dies with `(findings ?? []).map is
+    // not a function`: Object.entries walks Line/Path/Code and calls .map on a
+    // number. An uncaught throw here would abort the other engines, which is
+    // precisely what D6b forbids.
+    expect(() =>
+      toValeCheckResults(
+        configError as unknown as Parameters<typeof toValeCheckResults>[0]
+      )
+    ).not.toThrow();
+  });
+});
diff --git a/packages/cli/test/vale-run.test.ts b/packages/cli/test/vale-run.test.ts
index 64c55694..c2a8f31e 100644
--- a/packages/cli/test/vale-run.test.ts
+++ b/packages/cli/test/vale-run.test.ts
@@ -5,7 +5,7 @@ import { join } from "node:path";
 import { afterEach, describe, expect, it, vi } from "vitest";
 
 import { findValeBinary } from "../src/rules/vale/binary";
-import { runVale } from "../src/rules/vale/run";
+import { isValeFailure, runVale } from "../src/rules/vale/run";
 
 /**
  * These run the real Vale binary. It ships as an `optionalDependency` for the
@@ -185,6 +185,29 @@ withVale("runVale against the real binary", () => {
     });
   });
 
+  it("reports a malformed rule as a failure instead of crashing", async () => {
+    // Measured, not assumed: Vale answers a bad rule on stderr with exit 2 and
+    // an empty stdout, so the non-zero-exit branch reports it. The point of the
+    // test is that a broken rule file surfaces as a failure the user can act on
+    // rather than as "no Vale findings", which is indistinguishable from a
+    // clean run and is how a silently disabled engine ships.
+    const cwd = makeProject(
+      `${header}\n[*.md]\nrules.bogus = YES\n`,
+      {
+        bogus: `extends: existence\nmessage: "test"\nlevel: catastrophe\ntokens:\n  - simply\n`,
+      },
+      { "doc.md": "Just simply do it.\n" }
+    );
+
+    const outcome = await runVale({ cwd, paths: ["doc.md"] });
+    expect(outcome.status).toBe("failed");
+    if (outcome.status !== "failed") return;
+    // Vale's own diagnostic is carried through verbatim: the rule file it
+    // rejected and why.
+    expect(outcome.message).toContain("E201");
+    expect(outcome.message).toContain("bogus.yml");
+  });
+
   it("terminates and reports a timeout rather than hanging", async () => {
     const cwd = makeProject(
       `${header}\n[*.md]\nrules.no-simply = YES\n`,
@@ -200,3 +223,24 @@ withVale("runVale against the real binary", () => {
     expect(outcome.message).toContain("terminated");
   });
 });
+
+describe("isValeFailure", () => {
+  it("treats an absent binary as a skip, not a failure", () => {
+    // An unsupported arch is an ordinary state, not evidence that the user's
+    // rules are wrong. Failing here would make `check` unrunnable on a machine
+    // where ast-grep and runtime rules report perfectly well.
+    expect(isValeFailure({ status: "unavailable", message: "x" })).toBe(false);
+  });
+
+  it("treats a timeout or a failure as an error", () => {
+    // Vale was present and asked to work. Reporting these as a skip would let
+    // a broken rule file read as "no Vale findings" — indistinguishable from a
+    // clean run, and how a silently disabled engine ships.
+    expect(isValeFailure({ status: "timeout", message: "x" })).toBe(true);
+    expect(isValeFailure({ status: "failed", message: "x" })).toBe(true);
+  });
+
+  it("treats findings as a success; severity decides the exit code", () => {
+    expect(isValeFailure({ status: "ok", results: [] })).toBe(false);
+  });
+});

From 58a81e5f50d002b8f05162f6d7eae6974189f8c4 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 10 Aug 2026 17:11:26 -0700
Subject: [PATCH 14/15] test(cli): pin Vale's behaviour, and correct the
 matcher precedence spec
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Vale is a vendored binary upgraded on its cadence, not ours, so the assumptions
our mapping rests on are worth asserting directly. vale-vendor-contract.test.ts
invokes Vale rather than runVale — a test through our wrapper would assert our
interpretation, which is what everything else already covers — and each case
names the code that breaks if the behaviour changes.

Writing it found three things that were wrong, two of them mine.

MATCHER PRECEDENCE. The spec said a disable "takes precedence over an enable,
independent of order". Measured against 3.17.1 that is false in both
directions. Precedence is positional: where two matchers both match a file the
LAST wins, and where one matcher assigns the same key twice — including across
duplicate [glob] sections, which Vale merges — the FIRST wins. So
[marketing/**] YES then [marketing/legacy/**] NO excludes legacy, and the same
two matchers in the opposite order do not. The spec now states that, requires a
disable to be declared after the enable it narrows, and warns that a repeated
assignment inside one glob is discarded — which matters for tooling that
appends to an existing matcher.

The unit-1 test covering this was named "lets a disable win over an enable,
regardless of order" and exercised one order. It passed while the claim it
named was false. Renamed to what it actually asserts, with the opposite order
pinned in the contract file.

EXIT CODES. Vale's exit code keys off severity, not off having found anything:
suggestion and warning exit 0 even without --no-exit, only error exits 1. So
--no-exit is load-bearing exactly for error-level rules, which is where dropping
it would hurt most — every check with a real violation reported as a failed
engine instead of as findings.

EMPTY RESULTS. Vale prints `{}`, not nothing, when it finds nothing. runVale's
empty-stdout branch is therefore insurance rather than the live path, and the
comment claiming otherwise is corrected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 .../specs/cli-vale-rule-engine/spec.md        |  20 +-
 packages/cli/src/rules/vale/run.ts            |   5 +-
 packages/cli/test/vale-run.test.ts            |   7 +-
 .../cli/test/vale-vendor-contract.test.ts     | 335 ++++++++++++++++++
 4 files changed, 361 insertions(+), 6 deletions(-)
 create mode 100644 packages/cli/test/vale-vendor-contract.test.ts

diff --git a/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md b/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md
index 2c93da9a..89a213be 100644
--- a/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md
@@ -25,23 +25,35 @@ The system SHALL run `vale --config .taskless/vale/.vale.ini --output=JSON --no-
 
 ### Requirement: Per-rule scoping is expressed via Vale config matchers
 
-The system SHALL express a Vale rule's scope through `.vale.ini` **matchers** — `[<glob>]` sections. Include is `rules.<name> = YES` (unioning across matching matchers); exclude is `rules.<name> = NO` (a disable takes precedence over an enable, independent of order). Duplicate `[<glob>]` matchers SHALL be treated as merged, since Vale unions them.
+The system SHALL express a Vale rule's scope through `.vale.ini` **matchers** — `[<glob>]` sections. Include is `rules.<name> = YES`, exclude is `rules.<name> = NO`.
+
+Precedence is **positional**, and the system SHALL order matchers accordingly rather than relying on a disable to win on its own. Measured against Vale 3.17.1:
+
+- Where two matchers both match a file, the **last** one wins for that rule.
+- Where the same key is assigned twice inside one matcher — including across duplicate `[<glob>]` sections, which Vale merges — the **first** assignment wins.
+
+A disable therefore SHALL be declared **after** the enable it narrows. Duplicate `[<glob>]` matchers SHALL be treated as merged, and a rule's scope SHALL NOT be expressed as a repeated assignment of the same key within one glob, since the later assignment is discarded.
 
 #### Scenario: Duplicate matchers merge
 
 - **WHEN** two `[*.md]` matchers each enable a different rule
-- **THEN** both rules run on a matching `.md` file (Vale unions the matchers)
+- **THEN** both rules run on a matching `.md` file (Vale merges the matchers)
 
 #### Scenario: Include scopes a rule to a path
 
 - **WHEN** a rule is enabled only under `[marketing/**]`
 - **THEN** the rule produces findings in `marketing/` files and none in `api/` files
 
-#### Scenario: Exclude removes a subpath from an included scope
+#### Scenario: A later matcher overrides an earlier one
 
-- **WHEN** a rule is enabled under `[marketing/**]` and disabled under `[marketing/legacy/**]`
+- **WHEN** a rule is enabled under `[marketing/**]` and then disabled under `[marketing/legacy/**]`
 - **THEN** the rule fires in `marketing/` but not in `marketing/legacy/`
 
+#### Scenario: Declaration order is significant
+
+- **WHEN** the same two matchers are declared in the opposite order — `[marketing/legacy/**]` disabling first, `[marketing/**]` enabling second
+- **THEN** the rule fires in `marketing/legacy/` as well, because the later enable wins; a disable does not take precedence on its own
+
 ### Requirement: Vale findings map to the scanner-agnostic CheckResult
 
 The system SHALL map each Vale finding to a `CheckResult` with `source` `"vale"` and `ruleId` equal to the Vale check name with its `rules.` prefix stripped. Severity SHALL be normalized `error → error`, `warning → warning`, `suggestion → hint`. The system SHALL map `message` from `Message`, `note` from `Description`/`Link`, `range` from `Line`/`Span`, `matchedText` from `Match`, and `fix` from `Action` only when the action is populated.
diff --git a/packages/cli/src/rules/vale/run.ts b/packages/cli/src/rules/vale/run.ts
index 3bd75bf9..dcb56206 100644
--- a/packages/cli/src/rules/vale/run.ts
+++ b/packages/cli/src/rules/vale/run.ts
@@ -159,7 +159,10 @@ export async function runVale(
 
       const stdout = stdoutChunks.join("").trim();
       if (stdout === "") {
-        // Vale prints nothing at all when it has no findings.
+        // Measured: Vale prints `{}` when it finds nothing, which parses and
+        // maps to [] below. This branch is for a Vale that says nothing at all
+        // — cheap insurance against JSON.parse("") reporting a clean run as a
+        // failure.
         settle({ status: "ok", results: [] });
         return;
       }
diff --git a/packages/cli/test/vale-run.test.ts b/packages/cli/test/vale-run.test.ts
index c2a8f31e..d33676ac 100644
--- a/packages/cli/test/vale-run.test.ts
+++ b/packages/cli/test/vale-run.test.ts
@@ -154,7 +154,12 @@ withVale("runVale against the real binary", () => {
       expect(files).not.toContain("api/c.md");
     });
 
-    it("lets a disable win over an enable, regardless of order", async () => {
+    it("lets a later matcher override an earlier one", async () => {
+      // Order is significant, and this asserts only the working order. The
+      // opposite order is pinned in vale-vendor-contract.test.ts, where it
+      // documents that a disable does NOT win on its own — the earlier name of
+      // this test claimed "regardless of order" while testing one order, which
+      // would have kept passing while the claim was false.
       const cwd = makeProject(
         `${header}\n[marketing/**]\nrules.no-simply = YES\n\n[marketing/legacy/**]\nrules.no-simply = NO\n`,
         rules,
diff --git a/packages/cli/test/vale-vendor-contract.test.ts b/packages/cli/test/vale-vendor-contract.test.ts
new file mode 100644
index 00000000..d9352c6c
--- /dev/null
+++ b/packages/cli/test/vale-vendor-contract.test.ts
@@ -0,0 +1,335 @@
+import { spawnSync } from "node:child_process";
+import { mkdtempSync, mkdirSync, rmSync, writeFileSync } from "node:fs";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+import { afterEach, describe, expect, it } from "vitest";
+
+import { findValeBinary } from "../src/rules/vale/binary";
+
+/**
+ * Vale's observable behaviour, pinned.
+ *
+ * Everything here is a property of a **vendored third-party binary** that we
+ * upgrade on Vale's cadence, not ours. `vale-run.test.ts` asserts that our code
+ * behaves correctly *given* these; this file asserts the givens, so a Vale
+ * upgrade that changes one fails here — naming the assumption and the code that
+ * rests on it — instead of surfacing as a mysterious mapping bug.
+ *
+ * Each case says what breaks if it changes. That is the point of the file: a
+ * red test here is a instruction to go change specific code, not a puzzle.
+ *
+ * These invoke Vale directly rather than through `runVale`, deliberately. A
+ * test that went through our wrapper would be asserting our interpretation of
+ * Vale, which is the thing under test everywhere else.
+ */
+
+const binary = findValeBinary().path;
+const withVale = binary === undefined ? describe.skip : describe;
+
+const workspaces: string[] = [];
+afterEach(() => {
+  while (workspaces.length > 0) {
+    rmSync(workspaces.pop() as string, { recursive: true, force: true });
+  }
+});
+
+function project(
+  config: string,
+  rules: Record<string, string>,
+  documents: Record<string, string>
+): string {
+  const cwd = mkdtempSync(join(tmpdir(), "vale-contract-"));
+  workspaces.push(cwd);
+  mkdirSync(join(cwd, ".taskless", "vale", "rules"), { recursive: true });
+  writeFileSync(join(cwd, ".taskless", "vale", ".vale.ini"), config);
+  for (const [name, body] of Object.entries(rules)) {
+    writeFileSync(join(cwd, ".taskless", "vale", "rules", `${name}.yml`), body);
+  }
+  for (const [path, body] of Object.entries(documents)) {
+    writeFileSync(join(cwd, path), body);
+  }
+  return cwd;
+}
+
+/** Invoke Vale exactly as `runVale` does, but capture the raw streams. */
+function runRaw(cwd: string, paths: string[], extraArguments: string[] = []) {
+  return spawnSync(
+    binary as string,
+    [
+      "--config",
+      ".taskless/vale/.vale.ini",
+      "--output=JSON",
+      ...extraArguments,
+      "--",
+      ...paths,
+    ],
+    { cwd, encoding: "utf8" }
+  );
+}
+
+const header = "StylesPath = .\nMinAlertLevel = suggestion\n";
+const existence = (token: string, level = "warning") =>
+  `extends: existence\nmessage: "Avoid '${token}'"\nlevel: ${level}\ntokens:\n  - ${token}\n`;
+
+/** A project whose single document trips its single rule. */
+const findingProject = (level = "warning") =>
+  project(
+    `${header}\n[*.md]\nrules.no-simply = YES\n`,
+    { "no-simply": existence("simply", level) },
+    { "doc.md": "Just simply do it.\n" }
+  );
+
+/** Exit status of a run at `level`, without `--no-exit`. */
+const exitStatusAtLevel = (level: string) =>
+  runRaw(findingProject(level), ["doc.md"]).status;
+
+withVale("Vale vendor contract", () => {
+  it("reports its own name in --version", () => {
+    // Depended on by: PlatformBinarySpec.identity (/vale/i). If Vale stops
+    // saying "vale" here, resolution rejects the real binary as a placeholder
+    // and the engine silently reports unavailable.
+    const result = spawnSync(binary as string, ["--version"], {
+      encoding: "utf8",
+    });
+    expect(result.status).toBe(0);
+    expect(`${result.stdout}${result.stderr}`).toMatch(/vale/i);
+  });
+
+  describe("exit codes", () => {
+    it("exits 0 with --no-exit despite findings", () => {
+      // Depended on by: runVale treating any non-zero exit as Vale failing.
+      // Without --no-exit Vale exits non-zero merely for finding something, and
+      // every run with a finding would be reported as a failed engine.
+      const result = runRaw(findingProject(), ["doc.md"], ["--no-exit"]);
+      expect(result.status).toBe(0);
+      expect(result.stdout).not.toBe("");
+    });
+
+    it("exits non-zero WITHOUT --no-exit only for error-level findings", () => {
+      // Measured, and narrower than expected: Vale's exit code keys off
+      // SEVERITY, not off having found something. suggestion and warning exit
+      // 0 even without --no-exit; only error exits 1. So --no-exit is
+      // load-bearing exactly for error-level rules, which is precisely where
+      // dropping it would be most damaging — every check with a real violation
+      // would be reported as a failed engine rather than as findings.
+      expect(exitStatusAtLevel("suggestion")).toBe(0);
+      expect(exitStatusAtLevel("warning")).toBe(0);
+      expect(exitStatusAtLevel("error")).not.toBe(0);
+    });
+  });
+
+  it("prints an empty JSON object when there are no findings", () => {
+    // Depended on by: runVale parsing stdout and mapping `{}` to no results.
+    // Measured — it is `{}`, not an empty stream, so the empty-stdout branch in
+    // runVale is insurance rather than the live path. If Vale ever printed a
+    // human-readable "no issues" line instead, JSON.parse would fail and a
+    // clean run would be reported as a failure.
+    const cwd = project(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existence("simply") },
+      { "doc.md": "Nothing objectionable.\n" }
+    );
+    const result = runRaw(cwd, ["doc.md"], ["--no-exit"]);
+    expect(result.status).toBe(0);
+    expect(result.stdout.trim()).toBe("{}");
+  });
+
+  it("keys findings by path, with the documented field names", () => {
+    // Depended on by: the ValeFinding interface and toValeCheckResults, which
+    // pushes the outer key down as `file`. A rename on any of these arrives as
+    // `undefined` in a CheckResult rather than as an error.
+    const cwd = project(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existence("simply") },
+      { "doc.md": "One\nTwo\nJust simply do it.\n" }
+    );
+    const result = runRaw(cwd, ["doc.md"], ["--no-exit"]);
+    const parsed = JSON.parse(result.stdout) as Record<
+      string,
+      Array<Record<string, unknown>>
+    >;
+
+    expect(Object.keys(parsed)).toEqual(["doc.md"]);
+    const finding = parsed["doc.md"]?.[0];
+    expect(finding).toBeDefined();
+    expect(Object.keys(finding ?? {}).toSorted()).toEqual([
+      "Action",
+      "Check",
+      "Description",
+      "Line",
+      "Link",
+      "Match",
+      "Message",
+      "Severity",
+      "Span",
+    ]);
+  });
+
+  it("prefixes check names with the StylesPath directory", () => {
+    // Depended on by: stripRulesPrefix. The prefix is the *directory* name, so
+    // it is `rules.` only because the engine layout puts styles in
+    // `.taskless/vale/rules/`. If that directory is ever renamed, the strip
+    // must be renamed with it.
+    const cwd = project(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existence("simply") },
+      { "doc.md": "Just simply do it.\n" }
+    );
+    const parsed = JSON.parse(
+      runRaw(cwd, ["doc.md"], ["--no-exit"]).stdout
+    ) as Record<string, Array<{ Check: string }>>;
+    expect(parsed["doc.md"]?.[0]?.Check).toBe("rules.no-simply");
+  });
+
+  it("reports Span as 1-based inclusive columns on a single line", () => {
+    // Depended on by: toValeCheckResult building `range` from Line + Span, with
+    // start and end sharing the line. "Just simply do it." puts `simply` at
+    // columns 6-11.
+    const cwd = project(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existence("simply") },
+      { "doc.md": "Just simply do it.\n" }
+    );
+    const parsed = JSON.parse(
+      runRaw(cwd, ["doc.md"], ["--no-exit"]).stdout
+    ) as Record<string, Array<{ Line: number; Span: [number, number] }>>;
+    const finding = parsed["doc.md"]?.[0];
+    expect(finding?.Line).toBe(1);
+    expect(finding?.Span).toEqual([6, 11]);
+  });
+
+  it("accepts exactly [suggestion warning error] as levels", () => {
+    // Depended on by: normalizeSeverity. Its default branch is future-proofing
+    // *because* of this — Vale refuses anything outside the vocabulary, so a
+    // fourth level cannot reach us until Vale adds one. If this test fails
+    // because Vale gained a level, normalizeSeverity needs a real case for it.
+    const cwd = project(
+      `${header}\n[*.md]\nrules.bogus = YES\n`,
+      { bogus: existence("simply", "catastrophe") },
+      { "doc.md": "Just simply do it.\n" }
+    );
+    const result = runRaw(cwd, ["doc.md"], ["--no-exit"]);
+    expect(result.stderr).toContain(
+      "must be one of [suggestion warning error]"
+    );
+  });
+
+  it("emits each accepted level verbatim in Severity", () => {
+    for (const level of ["suggestion", "warning", "error"]) {
+      const cwd = project(
+        `${header}\n[*.md]\nrules.lvl = YES\n`,
+        { lvl: existence("simply", level) },
+        { "doc.md": "Just simply do it.\n" }
+      );
+      const parsed = JSON.parse(
+        runRaw(cwd, ["doc.md"], ["--no-exit"]).stdout
+      ) as Record<string, Array<{ Severity: string }>>;
+      expect(parsed["doc.md"]?.[0]?.Severity).toBe(level);
+    }
+  });
+
+  it("sends a config error to stderr with a non-zero exit", () => {
+    // Depended on by: runVale's non-zero-exit branch reporting `failed`. This
+    // is the measured behaviour — an earlier reading of "exit 0 on stdout" was
+    // an artifact of piping through `head` with 2>&1. If Vale ever moves this
+    // to stdout with exit 0, the asValeConfigError guard in map.ts becomes
+    // load-bearing rather than defensive.
+    const cwd = project(
+      `${header}\n[*.md]\nrules.bogus = YES\n`,
+      { bogus: existence("simply", "catastrophe") },
+      { "doc.md": "Just simply do it.\n" }
+    );
+    const result = runRaw(cwd, ["doc.md"], ["--no-exit"]);
+    expect(result.status).not.toBe(0);
+    expect(result.stdout.trim()).toBe("");
+    const parsed = JSON.parse(result.stderr) as { Code?: string };
+    expect(parsed.Code).toBe("E201");
+  });
+
+  describe("matcher semantics", () => {
+    const rules = {
+      "no-simply": existence("simply"),
+      "no-very": existence("very"),
+    };
+
+    it("unions duplicate matchers rather than last-one-wins", () => {
+      // Depended on by: the spec's "duplicate matchers merge" requirement. If
+      // Vale switched to last-one-wins, a rule scoped across two matchers would
+      // silently stop running.
+      const cwd = project(
+        `${header}\n[*.md]\nrules.no-simply = YES\n\n[*.md]\nrules.no-very = YES\n`,
+        rules,
+        { "doc.md": "Just simply do it, very quickly.\n" }
+      );
+      const parsed = JSON.parse(
+        runRaw(cwd, ["doc.md"], ["--no-exit"]).stdout
+      ) as Record<string, Array<{ Check: string }>>;
+      expect(
+        (parsed["doc.md"] ?? []).map((finding) => finding.Check).toSorted()
+      ).toEqual(["rules.no-simply", "rules.no-very"]);
+    });
+
+    /** `{}` means the rule did not run for that file. */
+    const ran = (config: string, paths: string[] = ["doc.md"]) =>
+      runRaw(
+        project(config, rules, {
+          "doc.md": "Just simply do it.\n",
+        }),
+        paths,
+        ["--no-exit"]
+      ).stdout.trim() !== "{}";
+
+    it("gives a LATER matcher precedence over an earlier one", () => {
+      // The spec originally claimed a disable wins "independent of order".
+      // Measured against 3.17.1 that is false in both directions, and the
+      // spec has been corrected to match. Both orders are asserted here,
+      // because checking only the convenient one is exactly how the wrong
+      // claim survived: a test named "regardless of order" passed while
+      // exercising a single order.
+      expect(
+        ran(
+          `${header}\n[*.md]\nrules.no-simply = YES\n\n[doc.md]\nrules.no-simply = NO\n`
+        )
+      ).toBe(false);
+      expect(
+        ran(
+          `${header}\n[doc.md]\nrules.no-simply = NO\n\n[*.md]\nrules.no-simply = YES\n`
+        )
+      ).toBe(true);
+    });
+
+    it("keeps the FIRST assignment when one matcher sets a key twice", () => {
+      // Duplicate `[glob]` sections are merged, and the merge discards the
+      // later value — the opposite of the across-matcher rule above. Tooling
+      // that appends a disable to an existing matcher would therefore write a
+      // line Vale ignores.
+      expect(
+        ran(
+          `${header}\n[*.md]\nrules.no-simply = YES\n\n[*.md]\nrules.no-simply = NO\n`
+        )
+      ).toBe(true);
+      expect(
+        ran(
+          `${header}\n[*.md]\nrules.no-simply = NO\n\n[*.md]\nrules.no-simply = YES\n`
+        )
+      ).toBe(false);
+    });
+  });
+
+  it("ignores a `tskl)` breadcrumb key in the config", () => {
+    // Depended on by: the spec's breadcrumb requirement — Taskless writes
+    // `tskl) rule = <id>` keys into .vale.ini and relies on Vale's ini parser
+    // accepting and ignoring them. If Vale ever validates unknown keys, every
+    // committed config becomes unreadable at once.
+    const cwd = project(
+      `${header}\n[*.md]\ntskl) rule = no-simply\nrules.no-simply = YES\n`,
+      { "no-simply": existence("simply") },
+      { "doc.md": "Just simply do it.\n" }
+    );
+    const result = runRaw(cwd, ["doc.md"], ["--no-exit"]);
+    expect(result.status).toBe(0);
+    const parsed = JSON.parse(result.stdout) as Record<string, unknown[]>;
+    expect(parsed["doc.md"]).toHaveLength(1);
+  });
+});

From 90c8e50e87d62e8ff43cd9d8629b321b67d00e2e Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 10 Aug 2026 23:21:07 -0700
Subject: [PATCH 15/15] chore(changeset): record the Vale rule engine at the
 bottom of the stack
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

`require-changeset` only ever evaluates the bottom PR's own diff, so a changeset
written on the tip is invisible to the PR that actually merges — removing
`skip-changeset` from this PR turned the check red with the note sitting three
branches above it.

The stack merges down, so nothing lands until everything does and one note
describing the whole change is accurate at the only moment it is read. It is
moved here rather than duplicated; the tip's copy goes away as the units restack
onto this commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jwc9FFroR3mTZ4hLiSkkX3
---
 .changeset/vale-rule-engine.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 .changeset/vale-rule-engine.md

diff --git a/.changeset/vale-rule-engine.md b/.changeset/vale-rule-engine.md
new file mode 100644
index 00000000..11f1e297
--- /dev/null
+++ b/.changeset/vale-rule-engine.md
@@ -0,0 +1,17 @@
+---
+"@taskless/cli": minor
+---
+
+Add Vale as a second static-tier rule engine.
+
+`check` now dispatches by engine directory and runs ast-grep, Vale, and runtime
+rules concurrently, merging their findings into one result set. Vale rules live
+in `.taskless/vale/` and execute against the committed `.vale.ini`; an
+unavailable Vale reports itself and the other engines still return, while a Vale
+that times out or rejects its config fails the check rather than passing as a
+clean run. Vale rules are verified from `rule-tests/<rule>/pass|fail` fixtures
+against a generated per-rule config.
+
+Adds the `engine-selection` knowledge topic — which engine enforces a given
+rule, and why — available from `taskless help engine-selection` and exported
+through `@taskless/cli/prompts`.