diff --git a/.changeset/vale-recipe-regex-and-fixtures.md b/.changeset/vale-recipe-regex-and-fixtures.md
new file mode 100644
index 00000000..220bb018
--- /dev/null
+++ b/.changeset/vale-recipe-regex-and-fixtures.md
@@ -0,0 +1,7 @@
+---
+"@taskless/cli": patch
+---
+
+`agent create-vale-rule` (topic v13) corrects two claims that cost rule authors work. Vale patterns are not RE2-only: Vale compiles with Go's `regexp` and falls back to `regexp2`, so lookahead, lookbehind and backreferences work, and the recipe no longer tells you to split a rule that one pattern expresses. Two silent limits are measured and documented alongside it: a backreference does nothing as a `swap` key, and the implicit word boundary on `tokens`/`swap` lands after a trailing lookahead, so that lookahead has to peek at a non-word character. `check` on a rule's `.tests/fail` bucket is a supported way to read a rendered message, because `.taskless/` is excluded from the whole-project walk only; when that bucket comes back empty, the recipe now sends you to the rule's own config, specifically a `[.taskless/**]` matcher, before the pattern.
+
+`verify` carried the same imprecision and now states both halves: a `[.taskless/**]` matcher is unnecessary on a whole-project check, AND it silences the rule on a path you name, such as the rule's own fixture bucket. It was previously described as acting only under a bare `vale` invocation, which read as harmless. `agent update` (topic v10) is corrected to match.
diff --git a/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/.openspec.yaml b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/.openspec.yaml
new file mode 100644
index 00000000..1b9acb7f
--- /dev/null
+++ b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-22
diff --git a/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/proposal.md b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/proposal.md
new file mode 100644
index 00000000..6a07c81a
--- /dev/null
+++ b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/proposal.md
@@ -0,0 +1,55 @@
+## Why
+
+taskless/cli#370 and #371 corrected the recipe and the `verify` advisory: a
+`[.taskless/**]` matcher is not harmless. `check` excludes `.taskless/` from a
+_whole-project walk_ only, so the matcher does nothing there — but on a path
+named explicitly, such as the rule's own `.tests/fail` bucket, the matcher is
+live and silences the rule. That is the shape that reproduces "`test` says the
+fixture fired, `check` on the same fixture says nothing".
+
+The recipe, the `update` ledger and the advisory string now all say both halves.
+The standing spec does not. `cli-vale-rule-engine` still reads "`check` excludes
+that tree before Vale runs, so the matcher acts only under a bare `vale`
+invocation", and its scenario still requires `verify` to "report that `check`
+already excludes that tree" — the exact imprecise phrasing the code no longer
+ships. The spec is the source of truth for this capability, so leaving it
+disagreeing with the advisory it describes is how the next author reproduces
+#370 from the spec instead of the recipe.
+
+This change carries no code. The implementation already landed in this PR; the
+spec is what is behind.
+
+## What Changes
+
+- **`cli-vale-rule-engine`** — the advisory bullet and the
+  `.taskless/**` scenario state both halves of the behaviour: unnecessary on a
+  whole-project check, AND silencing on a named path. The scenario also gains
+  the `check`-notices half that the other advisory scenarios already carry, so
+  the two advisory paths are specified alike.
+
+No requirement is added or removed, and no behaviour changes: this is the spec
+catching up to an advisory string and a recipe that already shipped.
+
+## Capabilities
+
+### New Capabilities
+
+None.
+
+### Modified Capabilities
+
+- `cli-vale-rule-engine`: "A rule's Vale config is validated against a schema
+  before it is assembled" — the `.taskless/**` advisory bullet and its scenario
+  are restated to match the shipped advisory.
+
+## Impact
+
+Documentation only. No source file, test, or public surface changes. The bump
+stays `patch` and rides the existing changeset for this PR; no second changeset
+is added.
+
+## Delivery shape
+
+**Single PR.** The spec correction is two edits inside one requirement and
+belongs with the code change that made the standing text wrong, which is this
+PR. It is the tip, so the change is archived here.
diff --git a/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/specs/cli-vale-rule-engine/spec.md b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/specs/cli-vale-rule-engine/spec.md
new file mode 100644
index 00000000..841a7d69
--- /dev/null
+++ b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/specs/cli-vale-rule-engine/spec.md
@@ -0,0 +1,84 @@
+## MODIFIED Requirements
+
+### Requirement: A rule's Vale config is validated against a schema before it is assembled
+
+The system SHALL parse each rule's `.vale.ini` into an ordered, lossless AST and validate that AST against a schema keyed by the rule's directory id, before the config is assembled into the run config and when the rule is verified. Validation SHALL be performed on the parsed structure, never by matching the file's text.
+
+The schema SHALL reject a config that:
+
+- assigns any property above its first matcher (`StylesPath`, `MinAlertLevel`, or anything else; Vale ignores such a line with a `W101` warning and the rule verifies clean while enabled nowhere)
+- declares a matcher without a `tskl) rule = <id>` breadcrumb naming this rule
+- assigns a key other than `<id>.<id>` (a `<style>.<check>` key naming any other rule is a cross-rule override)
+- assigns a value other than `YES` or `NO`
+- assigns `BasedOnStyles`, with any value, empty included (on Vale 3.22.0 an empty value clears every earlier matcher's settings for the file, which in the assembled config silences every other rule whose glob reaches it; a named style loads alongside every overlapping rule; and no rule config ever needed either, since no bundled style loads unless a run-level `BasedOnStyles` names one)
+- declares no matcher
+- never assigns `<id>.<id> = YES` in its final per-matcher verdicts (matchers with the same glob are folded, as Vale merges them, and the last assignment wins, so a `YES` that a later `NO` in the same matcher overrides does not count)
+- declares a `NO`-verdict matcher before every `YES`-verdict matcher (no style is loaded, so a rule is off until a `YES`, and such a `NO` is either dead or overridden by the `YES` that follows; no config means it)
+
+The schema SHALL report, without rejecting, a config that:
+
+- assigns the same key twice inside one matcher (Vale 3.21.0 keeps the last assignment; 3.20.0 kept the first)
+- declares a `[*]` matcher
+- declares a matcher under `.taskless/**` (`check` excludes that tree from a whole-project walk, so the matcher is unnecessary there; it is not harmless, because it silences the rule on a path named explicitly, such as the rule's own fixture bucket under `.taskless/`)
+
+A rejected config SHALL refuse the Vale engine for that `check` run: the engine reports a failure naming the rule and the offending line, that failure SHALL reach the exit code, and other engines SHALL still run. A rule with a rejected config SHALL NOT be silently omitted from the assembled config, because a rule that is present, verifies, and reports nothing is the silent-disable failure this engine's design exists to prevent. Advisories SHALL be surfaced as notices and SHALL NOT affect the exit code.
+
+Assembly SHALL write each accepted config's source verbatim. The parsed structure is read for validation and for the list of matcher patterns; it is not re-serialized.
+
+#### Scenario: A foreign assignment refuses the run
+
+- **WHEN** `no-simply/.vale.ini` assigns `no-hedging.no-hedging = NO` and `check` runs
+- **THEN** the Vale engine SHALL report a failure naming `no-simply` and that line
+- **AND** the exit code SHALL be non-zero
+- **AND** ast-grep results for the same run SHALL still be reported
+
+#### Scenario: A run-level key in a rule config is rejected
+
+- **WHEN** a rule's config places `StylesPath = .` above its first matcher
+- **THEN** `verify` SHALL reject the rule, naming the key and the line
+- **AND** `check` SHALL refuse the Vale engine rather than strip the line
+
+#### Scenario: A matcher without a breadcrumb is rejected
+
+- **WHEN** a rule's config declares `[*.md]` with `<id>.<id> = YES` and no `tskl) rule` key
+- **THEN** `verify` SHALL reject the rule, naming the matcher
+
+#### Scenario: A disable that precedes every enable is rejected
+
+- **WHEN** a rule's config declares `[docs/legacy/**]` with `<id>.<id> = NO` and then `[docs/**]` with `<id>.<id> = YES`
+- **THEN** `verify` SHALL reject the rule, naming the `NO` matcher and the `YES` that re-enables it
+
+#### Scenario: A BasedOnStyles assignment is rejected
+
+- **WHEN** a rule's config sets `BasedOnStyles =` inside a matcher
+- **THEN** `verify` SHALL reject the rule under `vale-config-no-based-on-styles`, naming the line and saying that the line silences the other rules whose globs overlap
+- **AND** a `BasedOnStyles` naming a style SHALL be rejected under the same constraint
+
+#### Scenario: A [formats] section is rejected as a matcher it cannot be
+
+- **WHEN** a rule's config declares a `[formats]` section
+- **THEN** `verify` SHALL reject it for the breadcrumb it lacks and the foreign key it assigns, so no rule config can move a file between parser tiers
+
+#### Scenario: A repeated key is reported, not rejected
+
+- **WHEN** one matcher assigns `<id>.<id> = YES` and then `<id>.<id> = NO`, and an earlier matcher assigns `<id>.<id> = YES`
+- **THEN** `verify` SHALL accept the rule and report the repeat as a notice
+- **AND** `check` SHALL run the Vale engine and carry the same text in its notices
+
+#### Scenario: A rule whose only enable is overridden is rejected
+
+- **WHEN** the only matcher assigning `<id>.<id> = YES` later assigns `<id>.<id> = NO`, in the same section or in a second section with the same glob
+- **THEN** `verify` SHALL reject the rule as present but off, under `vale-config-enabled-somewhere`
+- **AND** the repeat SHALL still be reported as a notice
+
+#### Scenario: A `.taskless/**` matcher is reported as unnecessary
+
+- **WHEN** a rule's config declares a matcher under `.taskless/**`
+- **THEN** `verify` SHALL accept the rule and report both halves: that the matcher is unnecessary on a whole-project check, which excludes `.taskless/` before Vale runs, AND that it silences the rule on a path named explicitly, such as the rule's own fixture bucket
+- **AND** `check` SHALL carry the same text in its notices
+
+#### Scenario: An accepted config is assembled byte-for-byte
+
+- **WHEN** a config passes the schema
+- **THEN** the assembled run config SHALL contain that file's bytes unchanged under the rule's breadcrumb comment
+- **AND** the matcher patterns reported for the run SHALL equal the section names in the parsed structure
diff --git a/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/tasks.md b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/tasks.md
new file mode 100644
index 00000000..f3ab4dfa
--- /dev/null
+++ b/openspec/changes/archive/2026-09-22-vale-taskless-matcher-spec/tasks.md
@@ -0,0 +1,12 @@
+## 1. Spec
+
+- [x] 1.1 Restate the `.taskless/**` advisory bullet in
+      `cli-vale-rule-engine` to say it is unnecessary on a whole-project check
+      AND silencing on a named path.
+- [x] 1.2 Restate the `A .taskless/** matcher is reported as unnecessary`
+      scenario to require both halves, plus the `check`-notices half the other
+      advisory scenarios carry.
+- [x] 1.3 Confirm the MODIFIED block restates the requirement in full: same
+      title, all ten scenarios, and every bullet of both lists.
+- [x] 1.4 Dry-run `openspec archive` and diff the scenario count before and
+      after to prove nothing is dropped.
diff --git a/openspec/specs/cli-vale-rule-engine/spec.md b/openspec/specs/cli-vale-rule-engine/spec.md
index ffdbcb5d..2ad8653a 100644
--- a/openspec/specs/cli-vale-rule-engine/spec.md
+++ b/openspec/specs/cli-vale-rule-engine/spec.md
@@ -233,7 +233,7 @@ The schema SHALL report, without rejecting, a config that:
 
 - assigns the same key twice inside one matcher (Vale 3.21.0 keeps the last assignment; 3.20.0 kept the first)
 - declares a `[*]` matcher
-- declares a matcher under `.taskless/**` (`check` excludes that tree before Vale runs, so the matcher acts only under a bare `vale` invocation)
+- declares a matcher under `.taskless/**` (`check` excludes that tree from a whole-project walk, so the matcher is unnecessary there; it is not harmless, because it silences the rule on a path named explicitly, such as the rule's own fixture bucket under `.taskless/`)
 
 A rejected config SHALL refuse the Vale engine for that `check` run: the engine reports a failure naming the rule and the offending line, that failure SHALL reach the exit code, and other engines SHALL still run. A rule with a rejected config SHALL NOT be silently omitted from the assembled config, because a rule that is present, verifies, and reports nothing is the silent-disable failure this engine's design exists to prevent. Advisories SHALL be surfaced as notices and SHALL NOT affect the exit code.
 
@@ -288,7 +288,8 @@ Assembly SHALL write each accepted config's source verbatim. The parsed structur
 #### Scenario: A `.taskless/**` matcher is reported as unnecessary
 
 - **WHEN** a rule's config declares a matcher under `.taskless/**`
-- **THEN** `verify` SHALL accept the rule and report that `check` already excludes that tree
+- **THEN** `verify` SHALL accept the rule and report both halves: that the matcher is unnecessary on a whole-project check, which excludes `.taskless/` before Vale runs, AND that it silences the rule on a path named explicitly, such as the rule's own fixture bucket
+- **AND** `check` SHALL carry the same text in its notices
 
 #### Scenario: An accepted config is assembled byte-for-byte
 
diff --git a/packages/cli/src/agent/create-vale-rule.md b/packages/cli/src/agent/create-vale-rule.md
index 671a6d03..43c7b434 100644
--- a/packages/cli/src/agent/create-vale-rule.md
+++ b/packages/cli/src/agent/create-vale-rule.md
@@ -1,4 +1,4 @@
-# Topic: create-vale-rule     (CLI v%(CLI_VERSION)s / topic v12)
+# Topic: create-vale-rule     (CLI v%(CLI_VERSION)s / topic v13)
 
 ## You are here
 This is `create-vale-rule`. It helps you write a Vale rule: a check over
@@ -471,15 +471,42 @@ it.
    expect to add to the list.
 
 3. **Know what you are writing: `tokens` and `swap` keys are patterns,
-   not literals.** They compile as **Go RE2** regular expressions.
+   not literals.** They compile as Go regular expressions.
 
    *This step is about `tokens` and `swap` only. A `capitalization`,
    `occurrence` or `metric` rule has neither, skip to step 4.*
 
    - `(?:…)`, `[…]`, `|`, `+`, `?` all work.
-   - **Lookahead and lookbehind do not exist in RE2.** A rule that needs
-     "X but not when followed by Y" cannot be written as a single
-     `substitution`; split it or narrow with `scope`.
+   - **Lookaround and backreferences work, and they are not free.**
+     Vale compiles a pattern with Go's own `regexp` first and falls
+     back to `regexp2` when that engine refuses it, so `(?=…)`,
+     `(?<=…)` and `\1` are all available even though Go's `regexp` has
+     none of them. Measured on Vale v%(VALE_VERSION)s with throwaway
+     rules, each firing on its `fail/` fixture and quiet on `pass/`: a
+     repeated-word `\b(\w+) \1\b`, a `foo(?= bar)` lookahead, and a
+     `(?<=x )y` lookbehind. The fallback engine backtracks and is the
+     slower of the two, so keep lookaround off a pattern that runs
+     over every file in the project, and prove any rule that uses one
+     with a fixture rather than trusting the syntax. "X but not when
+     followed by Y" is therefore writable as a single `substitution`,
+     but splitting it or narrowing with `scope` is still the cheaper
+     rule when either will do.
+
+     Two measured limits sit on top of that, and both are silent:
+
+     - **A backreference does nothing in `swap`.** The same
+       `(\w+) \1` that fires under `tokens` and under `raw` produces
+       no finding as a `swap` key, with nothing on stderr and the
+       rule loading cleanly, so the rule looks healthy and never
+       fires at all. A repeated-word check has to be an `existence`
+       rule; it cannot be a `substitution`.
+     - **A trailing lookahead in `tokens` or `swap` has to peek at a
+       non-word character.** The implicit `\b` is appended after the
+       lookahead (the lookahead is zero-width, so the position is
+       still where the match ended), which puts the boundary between
+       the match and the text peeked at. `foo(?= bar)` fires;
+       `foo(?=bar)` can never match, whatever the document says. Use
+       `raw` when the lookahead has to land on a word character.
    - **Word boundaries are applied for you, around the whole pattern.**
      Measured: `Github` does not fire inside `GithubToken`, and the
      multi-word `click here` does not fire inside `Clicking here`.
@@ -701,8 +728,9 @@ it.
      the rule: if it was the only `YES`, the config is rejected, not
      advised
    - a `[*]` matcher, which reaches every file Vale can read
-   - a matcher under `.taskless/**`, which `check` already excludes
-     before Vale runs, so it acts only under a bare `vale` invocation
+   - a matcher under `.taskless/**`, which a whole-project `check`
+     already excludes, and which silences the rule over a fixture
+     bucket you name on purpose (step 6)
 
    Each advisory has a legitimate reading, which is what separates the
    two lists. Fix a rejection before moving on; read an advisory and
@@ -939,13 +967,35 @@ it.
    reported one entry per rule. `.taskless/rules/vale` covers every Vale
    rule; no argument at all covers the project.
 
-   If you would rather see the raw findings, the message text and the
-   line numbers, run `check` against a bucket instead:
+   **`test` answers pass-or-fail and never shows you the finding**, so
+   it cannot tell you that a `substitution` message renders its two
+   `%%s` slots in the wrong order: the rule fires, the fixture is
+   satisfied, and `test` reports `ok`. To read the rendered message,
+   the line numbers and the matched text, name the bucket to `check`:
 
    ```
    %(TASKLESS_CLI)s check .taskless/rules/vale/<id>/.tests/fail --json
    ```
 
+   **That works because a path you name is honored.** `.taskless/` is
+   excluded from the *whole-project* walk only, so a bare `check` over
+   the project reports nothing from anyone's fixtures while the command
+   above reports every finding in that bucket. Measured on this build:
+   a whole-project `check` returned no result under `.taskless/`, and
+   the same rule's `fail/` bucket named explicitly returned its
+   findings with the message text rendered.
+
+   **If that command returns `results: []` for a rule whose `test` is
+   green, suspect the rule's own config before the pattern.** A
+   `[.taskless/**]` matcher setting `<id>.<id> = NO` turns the bucket
+   off for exactly this invocation, which is the one shape that
+   reproduces "`test` says the fixture fired, `check` on the same
+   fixture says nothing". Measured: adding that matcher to a working
+   rule left `test` at `ok: true` and emptied `results`. The tell is
+   in the same envelope, as a notice reading `matcher [.taskless/**]
+   is unnecessary`. `verify` reports it too, as an advisory. Delete
+   the matcher; step 4 explains why no rule needs one.
+
    Read `results` there. Ignore `success` and the exit code: `success`
    says the run worked rather than that the fixture behaved, and the
    exit code follows severity, so a `level: error` rule exits 1 on
@@ -1005,15 +1055,20 @@ it.
    run `vale` directly, and do not add config to make a bare run
    behave. The matcher that comes from doing so is `[.taskless/**]`
    with the rule set to `NO`, meant to keep a bare run quiet over
-   fixtures that hold violations on purpose. `check` excludes
-   `.taskless/` before Vale runs on a whole-project walk, so that block
-   only ever acts under the invocation this paragraph tells you not to
-   use, and `verify` reports it as unnecessary (step 4 lists the
-   advisory). A rule needs the matchers for the files it is about and
+   fixtures that hold violations on purpose. It does not stay confined
+   to the invocation it was written for: a whole-project `check` skips
+   `.taskless/` without its help, and on a fixture bucket you name it
+   is the one thing acting, which is how it empties the `check` above
+   while `test` stays green. `verify` reports it as an advisory (step 4
+   lists it). A rule needs the matchers for the files it is about and
    no more.
 
    When a `fail/` document does not fire, work down this list before
    touching the pattern. The cause is usually further up:
+   - Read the finding first, with the `check` on the `fail/` bucket
+     above. What the run saw is cheaper than any guess about why it
+     saw nothing, and it separates "no finding" from "a finding whose
+     message is wrong".
    - Does the rule have a `.vale.ini` at all?
    - Is the assignment underneath a `[…]` matcher?
    - Is it spelled `<id>.<id>`, both halves the same?
@@ -1191,7 +1246,7 @@ either:
 
 **The id must be word characters only.** `consistency` is the one
 extension point that compiles the rule's own name into the pattern, as
-a `(?P<id>…)` capture group, and Go RE2 rejects a group name containing
+a `(?P<id>…)` capture group, and Go's `regexp` rejects a group name containing
 a hyphen. Measured: an id of `ize-ise` fails with `E201 … invalid group
 name` and takes **every** Vale rule in the project down with it, because
 Vale reads one config for the whole run. Name this one `izeise` or
diff --git a/packages/cli/src/agent/update.md b/packages/cli/src/agent/update.md
index b1b1d936..195fbd24 100644
--- a/packages/cli/src/agent/update.md
+++ b/packages/cli/src/agent/update.md
@@ -1,4 +1,4 @@
-# Topic: update     (CLI v%(CLI_VERSION)s / topic v9)
+# Topic: update     (CLI v%(CLI_VERSION)s / topic v10)
 
 ## You are here
 This is `update`. It tells you what an upgrade changed for the rules
@@ -324,9 +324,10 @@ Vale was ignoring with a `W101`); a matcher with no `tskl) rule = <id>`
 breadcrumb; a key naming another rule (`no-hedging.no-hedging = NO`
 inside `no-simply`'s config, which was a cross-rule override); and a
 `NO` matcher declared before every `YES`, which the `YES` was
-overriding. A `.taskless/**` matcher is reported as unnecessary rather
-than rejected, since `check` excludes that tree before Vale runs;
-delete it. `%(TASKLESS_CLI)s agent create-vale-rule` lists every
+overriding. A `.taskless/**` matcher is reported as an advisory rather
+than rejected: a whole-project `check` excludes that tree anyway, and
+on a fixture path you name the matcher is what silences the rule.
+Delete it. `%(TASKLESS_CLI)s agent create-vale-rule` lists every
 rejection and advisory.
 
 Vale also moves from 3.21.0 to 3.22.0 in this release. Two things
diff --git a/packages/cli/src/schemas/vale-config.ts b/packages/cli/src/schemas/vale-config.ts
index 48ea4950..b4f43af5 100644
--- a/packages/cli/src/schemas/vale-config.ts
+++ b/packages/cli/src/schemas/vale-config.ts
@@ -425,7 +425,7 @@ function valeRuleConfigSchema(ruleId: string) {
 
 // --- Advisories --------------------------------------------------------------
 
-/** The tree `check` excludes before Vale runs. */
+/** The tree `check` excludes before Vale runs, on a whole-project walk. */
 const TASKLESS_TREE_PREFIX = ".taskless/";
 
 /**
@@ -433,8 +433,18 @@ const TASKLESS_TREE_PREFIX = ".taskless/";
  *
  * Each of these has a legitimate reading, so none is a rejection: a repeated
  * key may be a deliberate override an author is mid-way through, `[*]` may be
- * meant, and a `.taskless/**` matcher is harmless, only unnecessary. They are
- * said rather than refused.
+ * meant, and a `.taskless/**` matcher may be an author keeping a bare `vale`
+ * run quiet over fixtures that hold violations on purpose. They are said
+ * rather than refused.
+ *
+ * The `.taskless/**` advisory used to call that matcher harmless, on the
+ * reasoning that `check` excludes the tree anyway. It does not always: the
+ * exclusion is applied on a whole-project walk only, because an explicit path
+ * is a request (`rules/vale/run.ts`). So the matcher does act on
+ * `check .taskless/rules/vale/<id>/.tests/fail`, which is the one command
+ * that shows an author a rendered message, and it empties the result while
+ * `test` stays green (taskless/cli#370). Still an advisory, since the matcher
+ * has a reading; no longer described as costing nothing.
  */
 function adviseValeRuleConfig(
   ruleId: string,
@@ -460,8 +470,8 @@ function adviseValeRuleConfig(
     }
     if (section.name.startsWith(TASKLESS_TREE_PREFIX)) {
       advisories.push(
-        `${where(ruleId, section)} matcher ${label} is unnecessary: check excludes .taskless/ before Vale runs, ` +
-          `so it acts only under a bare vale invocation.`
+        `${where(ruleId, section)} matcher ${label} is unnecessary on a whole-project check, which excludes .taskless/ before Vale runs, ` +
+          `and it silences the rule on a path you name, such as its own fixture bucket.`
       );
     }
 
diff --git a/packages/cli/test/recipe-cross-references.test.ts b/packages/cli/test/recipe-cross-references.test.ts
index 0ad4a787..412b9e5d 100644
--- a/packages/cli/test/recipe-cross-references.test.ts
+++ b/packages/cli/test/recipe-cross-references.test.ts
@@ -427,4 +427,32 @@ describe("recipes state engine reach from the pinned versions", () => {
     // otherwise is stale the moment it slips.
     expect(recipe).not.toMatch(/\b20\d\d-\d\d\b/);
   });
+
+  it("does not tell a Vale author that lookaround is unavailable", async () => {
+    // The recipe claimed `tokens` and `swap` compile as RE2 and that
+    // lookaround therefore does not exist (taskless/cli#371). It does: Vale
+    // falls back to `regexp2`, measured in `vale-vendor-contract.test.ts`.
+    // The claim is worth pinning as an absence because it does not fail
+    // anything — it only costs an author a rule split into two that one
+    // pattern expresses.
+    const recipe = await rendered("create-vale-rule.md");
+    expect(recipe).not.toMatch(/do not exist in RE2/);
+    expect(recipe).toContain("regexp2");
+    // The two notes that shared that bullet list and did measure true. Losing
+    // them to the rewrite above would be the quiet half of the same edit.
+    expect(recipe).toContain("Word boundaries are applied for you");
+    expect(recipe).toContain("A hyphen is a boundary");
+  });
+
+  it("explains why a named fixture bucket is reachable by check", async () => {
+    // `check` on a `fail/` bucket is the only way to read a rendered `%s`
+    // message, and it works: `.taskless/` is excluded from the whole-project
+    // walk only. taskless/cli#370 read an empty `results` as proof the
+    // command could never work, so the recipe now says which exclusion is
+    // which, and names the rule-local matcher that really does empty it.
+    const recipe = await rendered("create-vale-rule.md");
+    expect(recipe).toContain(".tests/fail --json");
+    expect(recipe).toContain("a path you name is honored");
+    expect(recipe).toContain("matcher [.taskless/**]");
+  });
 });
diff --git a/packages/cli/test/vale-config-schema.test.ts b/packages/cli/test/vale-config-schema.test.ts
index f2c90a49..fa93a2e3 100644
--- a/packages/cli/test/vale-config-schema.test.ts
+++ b/packages/cli/test/vale-config-schema.test.ts
@@ -382,8 +382,14 @@ describe("validateValeRuleConfig advises, without rejecting", () => {
     const result = verdict("taskless-tree");
     expect(result.rejections).toEqual([]);
     expect(result.advisories).toEqual([
-      "no-simply/.vale.ini line 5: matcher [.taskless/**] is unnecessary: check excludes .taskless/ before Vale runs, " +
-        "so it acts only under a bare vale invocation.",
+      // The advisory names both halves deliberately. It said the matcher only
+      // ever acted under a bare `vale`, which is wrong: `check` drops
+      // `.taskless/` on a whole-project walk only, so the matcher does bite on
+      // an explicitly named fixture bucket, and there it empties the one
+      // command that shows a rendered message (taskless/cli#370).
+      "no-simply/.vale.ini line 5: matcher [.taskless/**] is unnecessary on a whole-project check, " +
+        "which excludes .taskless/ before Vale runs, " +
+        "and it silences the rule on a path you name, such as its own fixture bucket.",
     ]);
   });
 });
diff --git a/packages/cli/test/vale-vendor-contract.test.ts b/packages/cli/test/vale-vendor-contract.test.ts
index cff9c2dd..bf727494 100644
--- a/packages/cli/test/vale-vendor-contract.test.ts
+++ b/packages/cli/test/vale-vendor-contract.test.ts
@@ -86,6 +86,7 @@ function runRaw(cwd: string, paths: string[], extraArguments: string[] = []) {
 }
 
 const header = "StylesPath = .\nMinAlertLevel = suggestion\n";
+
 const existence = (token: string, level = "warning") =>
   `extends: existence\nmessage: "Avoid '${token}'"\nlevel: ${level}\ntokens:\n  - ${token}\n`;
 
@@ -171,6 +172,13 @@ const existenceOver = (
 ): string =>
   `extends: existence\nmessage: "%s"\nlevel: warning\n${extra}${key}:\n  - ${pattern}\n`;
 
+/**
+ * A `substitution` rule whose single `swap` key is the pattern under test,
+ * `message: "%s -> %s"` so a finding shows the replacement and the match.
+ */
+const swapPatternRule = (pattern: string): string =>
+  `extends: substitution\nmessage: "%s -> %s"\nlevel: warning\nswap:\n  '${pattern}': REPLACED\n`;
+
 /** A word budget of 8 over whatever `scope` names. */
 const budget = (scope: string) =>
   `extends: metric\nmessage: "%s words"\nlevel: error\nscope: '${scope}'\nformula: words\ncondition: "> 8"\n`;
@@ -743,6 +751,120 @@ withVale("Vale vendor contract", () => {
     });
   });
 
+  describe("lookaround and backreferences compile", () => {
+    // Vale tries Go's own `regexp` first and falls back to `regexp2` when a
+    // pattern will not compile, so constructs Go's engine has never had are
+    // still available. The recipe said the opposite from topic v1 (2026-08-13,
+    // the commit that introduced the claim) through v12, corrected here at v13
+    // (taskless/cli#371), and sent authors off to split a rule that one
+    // pattern expresses, so the correction is pinned against the binary rather
+    // than restated in prose: if a future Vale drops the fallback, these go
+    // red and the recipe's step 3 is wrong again.
+    //
+    // The recipe scopes the claim to `tokens` and `swap`, so those are
+    // measured here too rather than inferred from `raw`. They do not behave
+    // the same, and the two differences below are why the prose now carries
+    // caveats instead of a flat "they work".
+    //
+    // Each case is asserted in both directions. A pattern that fails to
+    // compile produces no findings at all, which is indistinguishable from a
+    // pattern that compiled and did not match, so the negative half alone
+    // would pass for the wrong reason.
+    it("matches a backreference to an earlier group", () => {
+      const repeated = existenceOver("raw", String.raw`'\b(\w+) \1\b'`);
+      expect(lines(repeated, "A the the repeated word.\n").messages).toEqual([
+        "the the",
+      ]);
+      expect(lines(repeated, "A sentence with no repeat.\n").lines).toEqual([]);
+    });
+
+    it("matches a lookahead", () => {
+      const ahead = existenceOver("raw", "'foo(?= bar)'");
+      expect(lines(ahead, "We wrote foo bar here.\n").messages).toEqual([
+        "foo",
+      ]);
+      expect(lines(ahead, "We wrote foo baz here.\n").lines).toEqual([]);
+    });
+
+    it("matches a lookbehind", () => {
+      const behind = existenceOver("raw", "'(?<=x )y'");
+      expect(lines(behind, "Here is x y now.\n").messages).toEqual(["y"]);
+      expect(lines(behind, "Here is z y now.\n").lines).toEqual([]);
+    });
+
+    // A `tokens` entry is wrapped in `\b…\b` (the block below pins that
+    // wrapping directly), and the trailing `\b` lands AFTER a trailing
+    // lookahead, because the lookahead is zero-width and leaves the position
+    // where the match ended. So the boundary is tested between the match and
+    // whatever the lookahead peeked at. With a space there it is a boundary
+    // and the rule fires; with a word character it is not, and the pattern
+    // cannot match at all however the document is written. `raw` is inserted
+    // verbatim and has no such limit, which is the one case where the recipe
+    // has to send an author to `raw` for a lookaround.
+    it("wraps a `tokens` lookahead in the implicit word boundaries", () => {
+      const spaced = existenceOver("tokens", "'foo(?= bar)'");
+      expect(lines(spaced, "We wrote foo bar here.\n").messages).toEqual([
+        "foo",
+      ]);
+      expect(lines(spaced, "We wrote foo baz here.\n").lines).toEqual([]);
+
+      // The lookahead peeks at a word character, so the appended `\b` can
+      // never hold. Silent under `tokens`, fires under `raw`.
+      const glued = "'foo(?=bar)'";
+      expect(
+        lines(existenceOver("tokens", glued), "We wrote foobar.\n").lines
+      ).toEqual([]);
+      expect(
+        lines(existenceOver("raw", glued), "We wrote foobar.\n").messages
+      ).toEqual(["foo"]);
+    });
+
+    // `swap` takes the same lookaround, so the recipe's "X but not when
+    // followed by Y" advice holds for a substitution rule.
+    it("matches lookaround in a `swap` key", () => {
+      const ahead = swapPatternRule("foo(?= bar)");
+      expect(lines(ahead, "We wrote foo bar here.\n").messages).toEqual([
+        "REPLACED -> foo",
+      ]);
+      expect(lines(ahead, "We wrote foo baz here.\n").lines).toEqual([]);
+
+      const behind = swapPatternRule("(?<=x )y");
+      expect(lines(behind, "Here is x y now.\n").messages).toEqual([
+        "REPLACED -> y",
+      ]);
+      expect(lines(behind, "Here is z y now.\n").lines).toEqual([]);
+    });
+
+    // ...but a backreference is SILENTLY inert in `swap`, where the identical
+    // pattern fires under both `tokens` and `raw`. Nothing is written to
+    // stderr and the rule loads, so a `swap` rule built on `\1` looks healthy
+    // and never fires at all. The literal control pins that the rule shape and
+    // the document are otherwise fine, so the silence is the backreference and
+    // not the scaffolding. This is why the recipe's step 3 can no longer say
+    // "backreferences work" for `tokens` and `swap` in one breath.
+    it("silently ignores a backreference in a `swap` key", () => {
+      const repeated = "A the the repeated word.\n";
+
+      // The control: a literal key over the same document does fire.
+      expect(lines(swapPatternRule("the the"), repeated).messages).toEqual([
+        "REPLACED -> the the",
+      ]);
+
+      for (const pattern of [String.raw`(\w+) \1`, String.raw`(the) \1`]) {
+        const swapped = lines(swapPatternRule(pattern), repeated);
+        expect(swapped.lines, `swap key ${pattern}`).toEqual([]);
+        expect(swapped.stderr, `swap key ${pattern}`).toBe("");
+        // The same pattern under `tokens` and `raw`, for contrast.
+        expect(
+          lines(existenceOver("tokens", `'${pattern}'`), repeated).messages
+        ).toEqual(["the the"]);
+        expect(
+          lines(existenceOver("raw", `'${pattern}'`), repeated).messages
+        ).toEqual(["the the"]);
+      }
+    });
+  });
+
   describe("`nonword` governs `tokens`, not `raw`", () => {
     // Vale wraps the pattern in `\b…\b` only when the rule has `tokens` and
     // `nonword` is unset, and `raw` is inserted verbatim either way. So a