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`.
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..7729d390
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/design.md
@@ -0,0 +1,126 @@
+## Context
+
+`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.
+
+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:
+
+- **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.
+- **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:** 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.
+
+**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 — 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.
+
+### 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.)
+
+### 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**:
+
+- 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.
+
+### 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.
+
+### 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 `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.
+
+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.
+
+### 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.
+
+### 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 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:
+
+- **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` 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.
+
+## 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.
+- **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
+
+`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
+
+**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).
+
+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..cee34e2e
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/proposal.md
@@ -0,0 +1,49 @@
+## Why
+
+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
+
+- 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-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-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`)**: 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.
+
+## 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                                                      |
+| ---- | ---------------------------------------------------------- |
+| 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
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..9709db19
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-check/spec.md
@@ -0,0 +1,17 @@
+## 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
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
new file mode 100644
index 00000000..485dd052
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-rule-format/spec.md
@@ -0,0 +1,10 @@
+## ADDED Requirements
+
+### 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`
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/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..89a213be
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/specs/cli-vale-rule-engine/spec.md
@@ -0,0 +1,110 @@
+## 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`, 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 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: A later matcher overrides an earlier one
+
+- **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.
+
+#### 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..3f7fb130
--- /dev/null
+++ b/openspec/changes/add-vale-rule-engine/tasks.md
@@ -0,0 +1,35 @@
+## 0. Prerequisites
+
+- [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
+
+- [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. **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
+
+- [ ] 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
+
+## 3. Engine-selection knowledge topic
+
+- [ ] 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
+- [ ] 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** 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
+
+- [ ] 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
diff --git a/packages/cli/src/rules/platform-binary.ts b/packages/cli/src/rules/platform-binary.ts
new file mode 100644
index 00000000..eb90374a
--- /dev/null
+++ b/packages/cli/src/rules/platform-binary.ts
@@ -0,0 +1,218 @@
+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.
+   *
+   * The first name is the canonical one: it is the only spelling probed inside
+   * the platform package, and it is the name error messages tell the user to put
+   * on PATH. The rest are alternative link names, tried *first* at the
+   * link-based tiers — see {@link resolvePlatformBinary}.
+   */
+  binaryNames: string[];
+  /** Pattern the candidate's own `--version` output must match. */
+  identity: RegExp;
+}
+
+/** The npm package carrying this host's prebuilt binary. */
+export 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;
+}
+
+/**
+ * The spellings tried at the link-based tiers (`node_modules/.bin`, `PATH`), in
+ * order — the reverse of {@link PlatformBinarySpec.binaryNames}.
+ *
+ * Reversed deliberately, preserving ast-grep's original resolver: it tried `sg`
+ * before `ast-grep` at both tiers. Nothing observable hangs on it today, since
+ * both names link to the same target and {@link isPlatformBinary} verifies
+ * whichever one answers, so this is about keeping a documented ordering rather
+ * than repairing a behavioural bug. It is kept because the ordering is the only
+ * record of which spelling we expect to find, and the same list decides which
+ * name a failure message tells the user to put on PATH.
+ */
+function linkNames(spec: PlatformBinarySpec): string[] {
+  return spec.binaryNames.toReversed();
+}
+
+/**
+ * The command name to tell a user to put on PATH, spelled for this platform
+ * (`sg.exe` on Windows). It is the first spelling the PATH search itself tries,
+ * so the advice and the search cannot drift apart.
+ */
+export function pathCommandName(spec: PlatformBinarySpec): string {
+  return executableName(linkNames(spec)[0] ?? spec.label);
+}
+
+/** 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 ?? ""}`);
+}
+
+/** One place to look, paired with the label `tried` reports it under. */
+type Candidate = [label: string, path: string | undefined];
+
+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.
+ *
+ * The platform package is probed under one name only. Its contents are ours to
+ * predict — the package ships the binary under its canonical name — so trying
+ * the alternative spellings there buys nothing but an extra `require.resolve`
+ * and a duplicate entry in `tried`, which reads to the user as the same
+ * location searched twice. The link-based tiers do try every spelling, because
+ * which one exists there is the installer's choice, not ours.
+ *
+ * Returns rather than throws. The two callers want different things from a
+ * miss: ast-grep cannot run at all without it, while a missing Vale binary
+ * makes one engine unavailable and must not abort the others (D6b). Encoding
+ * "not found" as a value rather than an exception is what lets each decide.
+ */
+export function resolvePlatformBinary(
+  spec: PlatformBinarySpec
+): PlatformBinaryResolution {
+  const localBin = resolve(
+    dirname(fileURLToPath(import.meta.url)),
+    "..",
+    "node_modules",
+    ".bin"
+  );
+
+  const links = linkNames(spec);
+  const candidates: Candidate[] = [
+    [
+      platformPackageName(spec),
+      platformPackageBinary(
+        spec,
+        executableName(spec.binaryNames[0] ?? spec.label)
+      ),
+    ],
+    ...links.map(
+      (name): Candidate => [
+        "node_modules/.bin",
+        resolve(localBin, executableName(name)),
+      ]
+    ),
+    ...links.map(
+      (name): Candidate => ["PATH", findOnPath(executableName(name))]
+    ),
+  ];
+
+  // `tried` names *locations*, not candidates: a tier searched under two
+  // spellings is still one place the user can look, and repeating its label
+  // makes "Looked in: …" read as if we searched it twice.
+  const tried = [...new Set(candidates.map(([label]) => label))];
+
+  for (const [, path] of candidates) {
+    if (path !== undefined && isPlatformBinary(spec, path)) {
+      return { path, tried };
+    }
+  }
+
+  return { path: undefined, tried };
+}
diff --git a/packages/cli/src/rules/scan.ts b/packages/cli/src/rules/scan.ts
index 584ca7c5..107d5070 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,12 @@ 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,
+  pathCommandName,
+  resolvePlatformBinary,
+  type PlatformBinarySpec,
+} from "./platform-binary";
 
 export interface ScanResult {
   results: CheckResult[];
@@ -30,42 +34,27 @@ 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. `ast-grep`
+ * leads because it is the name the platform package ships the binary under; the
+ * resolver reverses the list at the link-based tiers, so `sg` is still tried
+ * first there and named in the PATH advice, as it was before the shared
+ * resolver existed.
+ */
+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 +67,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 +96,22 @@ 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.
+  //
+  // The PATH advice is spelled for the platform — `sg.exe` on Windows — rather
+  // than hardcoded, so a Windows user is not told to install a name that would
+  // not be found there.
   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 \`${pathCommandName(AST_GREP_BINARY)}\` 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..ea3d7b0d
--- /dev/null
+++ b/packages/cli/src/rules/vale/binary.ts
@@ -0,0 +1,64 @@
+import {
+  resolvePlatformBinary,
+  type PlatformBinaryResolution,
+  type PlatformBinarySpec,
+} from "../platform-binary";
+
+/**
+ * Vale's per-platform packaging.
+ *
+ * `toolchainSuffix: false` is the whole reason this spec exists separately from
+ * ast-grep's. `add-vale-binary-packages` publishes `@taskless/vale-<os>-<cpu>`
+ * — `@taskless/vale-linux-x64`, not `-linux-x64-gnu`. ast-grep's resolver
+ * appends `-gnu` on every Linux, so reusing its naming here would resolve
+ * nothing on Linux while reporting the ordinary "Vale is unavailable" message,
+ * making a naming bug indistinguishable from a host without the binary.
+ *
+ * One binary name, unlike ast-grep's two: these packages ship `vale` (or
+ * `vale.exe`) as pure payload, with no `bin` entry and no lifecycle script, so
+ * there is no wrapper spelling to also try.
+ */
+export 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: PlatformBinaryResolution | 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(): PlatformBinaryResolution {
+  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/src/rules/vale/map.ts b/packages/cli/src/rules/vale/map.ts
new file mode 100644
index 00000000..08edc307
--- /dev/null
+++ b/packages/cli/src/rules/vale/map.ts
@@ -0,0 +1,190 @@
+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 *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.
+ *
+ * `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.
+ *
+ * Both are converted down by one. `CheckResult.range` is 0-indexed — ast-grep's
+ * native range is passed straight through by `toCheckResult`, the runtime
+ * harness converts its 1-based `Finding` down the same way, and `format.ts` adds
+ * 1 back for every source when it displays. Vale's `Line` and `Span` are both
+ * 1-based, so emitting them verbatim would report every finding one line and one
+ * column further into the file than it is. Clamped at 0 because a 0 from Vale
+ * (unset, rather than a real position) must not become -1.
+ */
+export function toValeCheckResult(
+  file: string,
+  finding: ValeFinding
+): CheckResult {
+  const [spanStart, spanEnd] = finding.Span;
+  const line = Math.max(0, finding.Line - 1);
+  const startColumn = Math.max(0, spanStart - 1);
+  const endColumn = Math.max(0, spanEnd - 1);
+  return {
+    source: "vale",
+    ruleId: stripRulesPrefix(finding.Check),
+    severity: normalizeSeverity(finding.Severity),
+    message: finding.Message,
+    note: toNote(finding),
+    file,
+    range: {
+      start: { line, column: startColumn },
+      end: { 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]) =>
+    // 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
new file mode 100644
index 00000000..110d7d21
--- /dev/null
+++ b/packages/cli/src/rules/vale/run.ts
@@ -0,0 +1,242 @@
+import { spawn } from "node:child_process";
+import { join } from "node:path";
+import { StringDecoder } from "node:string_decoder";
+
+import type { CheckResult } from "../../types/check";
+import { ENGINE_LAYOUTS } from "../engines";
+import { buildPath } from "../scan";
+import { findValeBinary, valeUnavailableMessage } from "./binary";
+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}`;
+
+/**
+ * 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.
+ *
+ * `blocking` says whether the outcome should fail the check, as opposed to
+ * being reported and moved past. It is carried **on the outcome** rather than
+ * derived by a helper the caller must remember to call: every engine we add
+ * follows the same shape — run a binary, return a self-describing outcome — and
+ * severity is a property of what happened, not knowledge the orchestration
+ * layer has to hold about each engine. Literal-typed per variant, so a call
+ * site that builds an outcome by hand cannot mislabel it.
+ *
+ * The three non-ok cases are not equivalent, and collapsing them would be wrong
+ * in both directions:
+ *
+ * - `unavailable` is **non-blocking**. 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 **blocking**. 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.
+ *
+ * `ok` is non-blocking even when it carries findings: severity decides the exit
+ * code there, the same as for every other engine.
+ */
+export type ValeRunOutcome =
+  | { status: "ok"; blocking: false; results: CheckResult[] }
+  | { status: "unavailable"; blocking: false; message: string }
+  | { status: "timeout"; blocking: true; message: string }
+  | { status: "failed"; blocking: true; 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",
+      blocking: false,
+      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() },
+    });
+
+    // One decoder per stream, not `chunk.toString()` per chunk. A multi-byte
+    // UTF-8 sequence split across a chunk boundary would otherwise have each
+    // half independently replaced with U+FFFD, and Vale lints free-form prose
+    // full of curly quotes, em dashes and accented characters. The damage is
+    // not limited to a mangled `Match`: corruption landing inside JSON string
+    // escaping makes `JSON.parse` throw, reporting a clean Vale run as
+    // `failed`. `runAstGrepScan` in `scan.ts` avoids the same trap by reading
+    // stdout through `node:readline`, which decodes for us.
+    const stdoutDecoder = new StringDecoder("utf8");
+    const stderrDecoder = new StringDecoder("utf8");
+    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",
+        blocking: true,
+        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(stdoutDecoder.write(chunk));
+    });
+    child.stderr.on("data", (chunk: Buffer) => {
+      stderrChunks.push(stderrDecoder.write(chunk));
+    });
+
+    child.on("error", (error) => {
+      // Near-unreachable, and a real failure rather than a skip when it does
+      // happen. `findValeBinary` proved this binary runs by executing
+      // `--version` during resolution, so an `error` here means it vanished,
+      // lost its permissions, or was quarantined between resolution and
+      // execution — not that Vale is uninstalled. Calling that `unavailable`
+      // would file a broken host under the advisory skip and let the check
+      // pass. `runAstGrepScan` rejects outright on the same event.
+      settle({
+        status: "failed",
+        blocking: true,
+        message: `Vale could not be executed at ${binary}: ${error.message}`,
+      });
+    });
+
+    child.on("close", (code) => {
+      // Flush whatever partial multi-byte sequence each decoder is holding, so
+      // a stream that ends mid-character contributes its replacement char once
+      // rather than leaving bytes unaccounted for.
+      stdoutChunks.push(stdoutDecoder.end());
+      stderrChunks.push(stderrDecoder.end());
+
+      // 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",
+          blocking: true,
+          message: `Vale exited ${String(code)}${stderr === "" ? "" : `: ${stderr}`}`,
+        });
+        return;
+      }
+
+      const stdout = stdoutChunks.join("").trim();
+      if (stdout === "") {
+        // 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", blocking: false, results: [] });
+        return;
+      }
+
+      try {
+        const parsed: unknown = JSON.parse(stdout);
+
+        // Defensive, not a live path. Measured against the real binary (a rule
+        // with an out-of-vocabulary `level`), a config error goes to stderr
+        // with exit 2 and an empty stdout, so the non-zero branch above has
+        // already reported it and this shape never arrives here. The guard
+        // stays because the cost of being wrong is a crash rather than a wrong
+        // answer: mapping a config error walks `Object.entries` over
+        // `Line`/`Path`/`Code` and calls `.map` on a number.
+        const configError = asValeConfigError(parsed);
+        if (configError !== undefined) {
+          settle({
+            status: "failed",
+            blocking: true,
+            message: `Vale rejected the configuration (${configError.Code}): ${configError.Text}${
+              configError.Path === undefined ? "" : ` in ${configError.Path}`
+            }`,
+          });
+          return;
+        }
+
+        settle({
+          status: "ok",
+          blocking: false,
+          results: toValeCheckResults(parsed as ValeOutput),
+        });
+      } catch (error) {
+        settle({
+          status: "failed",
+          blocking: true,
+          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/platform-binary.test.ts b/packages/cli/test/platform-binary.test.ts
new file mode 100644
index 00000000..36cdf8ad
--- /dev/null
+++ b/packages/cli/test/platform-binary.test.ts
@@ -0,0 +1,212 @@
+import {
+  chmodSync,
+  mkdtempSync,
+  readFileSync,
+  rmSync,
+  writeFileSync,
+} from "node:fs";
+import { tmpdir } from "node:os";
+import { join } from "node:path";
+
+import { afterEach, describe, expect, it } from "vitest";
+
+import { AST_GREP_BINARY } from "../src/rules/scan";
+import {
+  pathCommandName,
+  platformPackageName,
+  resolvePlatformBinary,
+  type PlatformBinarySpec,
+} 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());
+  });
+});
+
+/**
+ * The order candidates are tried in, which no existing case pinned.
+ *
+ * Every other test here asserts that resolution succeeds or fails, and that is
+ * exactly why extracting the shared resolver could silently reverse ast-grep's
+ * `sg`-before-`ast-grep` ordering without a single failure: both names link to
+ * the same target, so either answer is "resolved". These pin the ordering
+ * itself, using a spec whose identity nothing on the host satisfies except the
+ * fakes planted for the test.
+ */
+describe("candidate order", () => {
+  const workspaces: string[] = [];
+
+  afterEach(() => {
+    for (const workspace of workspaces.splice(0)) {
+      rmSync(workspace, { recursive: true, force: true });
+    }
+  });
+
+  /** Two identically-behaving executables, differing only in name. */
+  function plantOnPath(names: string[]): string {
+    const directory = mkdtempSync(join(tmpdir(), "candidate-order-"));
+    workspaces.push(directory);
+    for (const name of names) {
+      const path = join(directory, name);
+      writeFileSync(path, "#!/bin/sh\necho 'fake-tool 1.0.0'\n");
+      chmodSync(path, 0o755);
+    }
+    return directory;
+  }
+
+  const FAKE: PlatformBinarySpec = {
+    label: "fake-tool",
+    // Deliberately unresolvable, so the platform-package and node_modules/.bin
+    // tiers miss and the PATH tier is what decides.
+    packagePrefix: "@taskless/fake-tool-that-does-not-exist",
+    toolchainSuffix: false,
+    binaryNames: ["ast-grep", "sg"],
+    identity: /fake-tool/i,
+  };
+
+  const onUnix = process.platform === "win32" ? it.skip : it;
+
+  onUnix("tries the alternative name before the canonical one on PATH", () => {
+    // ast-grep's original resolver looked for `sg` first at both link-based
+    // tiers, with a comment marking it deliberate. Nothing observable rides on
+    // it today — both names point at the same target and `isPlatformBinary`
+    // verifies whichever answers — so only a test can keep the documented
+    // ordering from being quietly reversed by a refactor.
+    const directory = plantOnPath(["ast-grep", "sg"]);
+    const originalPath = process.env.PATH;
+    process.env.PATH = directory;
+    try {
+      expect(resolvePlatformBinary(FAKE).path).toBe(join(directory, "sg"));
+    } finally {
+      process.env.PATH = originalPath;
+    }
+  });
+
+  onUnix("still resolves the canonical name when it is the only one", () => {
+    const directory = plantOnPath(["ast-grep"]);
+    const originalPath = process.env.PATH;
+    process.env.PATH = directory;
+    try {
+      expect(resolvePlatformBinary(FAKE).path).toBe(
+        join(directory, "ast-grep")
+      );
+    } finally {
+      process.env.PATH = originalPath;
+    }
+  });
+
+  it("names each searched location once, however many spellings it tried", () => {
+    // The platform package is probed under one name, and a tier searched under
+    // two spellings is still one place to look; repeating a label makes
+    // "Looked in: …" read as if we searched the same directory twice.
+    const { tried } = resolvePlatformBinary(FAKE);
+    expect(tried).toEqual([...new Set(tried)]);
+    expect(tried).toEqual([
+      platformPackageName(FAKE),
+      "node_modules/.bin",
+      "PATH",
+    ]);
+  });
+
+  it("advises the PATH name the search actually looks for first", () => {
+    // `sg`, not `ast-grep`, and `.exe`-suffixed on Windows — telling a Windows
+    // user to install a name we would not find there is worse than silence.
+    expect(pathCommandName(AST_GREP_BINARY)).toBe(
+      process.platform === "win32" ? "sg.exe" : "sg"
+    );
+    expect(pathCommandName(VALE_BINARY)).toBe(
+      process.platform === "win32" ? "vale.exe" : "vale"
+    );
+  });
+});
diff --git a/packages/cli/test/vale-map.test.ts b/packages/cli/test/vale-map.test.ts
new file mode 100644
index 00000000..91362bcc
--- /dev/null
+++ b/packages/cli/test/vale-map.test.ts
@@ -0,0 +1,205 @@
+import { describe, expect, it } from "vitest";
+
+import {
+  asValeConfigError,
+  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", () => {
+    // Vale's `Line: 3` / `Span: [1, 7]` are 1-based; `CheckResult.range` is
+    // 0-indexed for every source, so each drops by one on the way in.
+    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: 2, column: 0 },
+        end: { line: 2, column: 6 },
+      },
+      matchedText: "simply",
+      fix: undefined,
+    });
+  });
+
+  it("clamps at 0 rather than emitting a negative position", () => {
+    // A 0 from Vale means "unset", not "one before the first column".
+    const result = toValeCheckResult("docs/a.md", {
+      ...example,
+      Line: 0,
+      Span: [0, 0],
+    });
+    expect(result.range).toEqual({
+      start: { line: 0, column: 0 },
+      end: { line: 0, column: 0 },
+    });
+  });
+
+  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([]);
+  });
+});
+
+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
new file mode 100644
index 00000000..02bdf3bc
--- /dev/null
+++ b/packages/cli/test/vale-run.test.ts
@@ -0,0 +1,294 @@
+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();
+  for (const workspace of workspaces.splice(0)) {
+    rmSync(workspace, { 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",
+    });
+    // The match is on the document's third line; `range` is 0-indexed, so 2.
+    expect(result.range.start.line).toBe(2);
+    expect(result.range.end.line).toBe(2);
+  });
+
+  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", blocking: false, 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 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,
+        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("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`,
+      { "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");
+  });
+});
+
+describe("ValeRunOutcome.blocking", () => {
+  it("marks an absent binary non-blocking", async () => {
+    // An unsupported arch is an ordinary state, not evidence that the user's
+    // rules are wrong. Blocking here would make `check` unrunnable on a machine
+    // where ast-grep and runtime rules report perfectly well.
+    const binary = await import("../src/rules/vale/binary");
+    vi.spyOn(binary, "findValeBinary").mockReturnValue({
+      path: undefined,
+      tried: ["@taskless/vale-darwin-arm64", "node_modules/.bin", "PATH"],
+    });
+
+    expect(await runVale({ cwd: process.cwd() })).toMatchObject({
+      status: "unavailable",
+      blocking: false,
+    });
+  });
+});
+
+withVale("ValeRunOutcome.blocking against the real binary", () => {
+  it("marks a timeout blocking", async () => {
+    // Vale was present and asked to work. Reporting this 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.
+    const cwd = makeProject(
+      `${header}\n[*.md]\nrules.no-simply = YES\n`,
+      { "no-simply": existenceRule("simply", "Avoid 'simply'") },
+      { "doc.md": "Just simply do it.\n" }
+    );
+
+    expect(
+      await runVale({ cwd, paths: ["doc.md"], timeoutMs: 1 })
+    ).toMatchObject({ status: "timeout", blocking: true });
+  });
+
+  it("marks a rejected configuration blocking", async () => {
+    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" }
+    );
+
+    expect(await runVale({ cwd, paths: ["doc.md"] })).toMatchObject({
+      status: "failed",
+      blocking: true,
+    });
+  });
+
+  it("marks findings non-blocking; severity decides the exit code", 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" }
+    );
+
+    expect(await runVale({ cwd, paths: ["doc.md"] })).toMatchObject({
+      status: "ok",
+      blocking: false,
+    });
+  });
+});
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..a90f7d2e
--- /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(() => {
+  for (const workspace of workspaces.splice(0)) {
+    rmSync(workspace, { 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);
+  });
+});