From 39717e1cb138a7503ba48a69da11e61f351c06df Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 21 Sep 2026 09:17:51 -0700
Subject: [PATCH 1/6] spec(vale): propose schema validation of per-rule
 .vale.ini

Adds the vale-config-schema OpenSpec change: parse each rule's .vale.ini
into a lossless AST with @jedmao/ini-parser, validate it with a zod schema
keyed by the rule id, attribute rejections in verify under vale-config-*
constraints, and refuse the Vale run at assembly on a rejected config
while ast-grep still runs. Assembly stays verbatim concatenation.

Stacked forward in two slices; this commit carries only the proposal.

Refs #359
---
 .../changes/vale-config-schema/.openspec.yaml |   2 +
 .../changes/vale-config-schema/proposal.md    |  48 ++++++++
 .../specs/cli-rule-validation/spec.md         | 106 +++++++++++++++++
 .../specs/cli-vale-rule-engine/spec.md        | 109 ++++++++++++++++++
 openspec/changes/vale-config-schema/tasks.md  |  18 +++
 5 files changed, 283 insertions(+)
 create mode 100644 openspec/changes/vale-config-schema/.openspec.yaml
 create mode 100644 openspec/changes/vale-config-schema/proposal.md
 create mode 100644 openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md
 create mode 100644 openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
 create mode 100644 openspec/changes/vale-config-schema/tasks.md

diff --git a/openspec/changes/vale-config-schema/.openspec.yaml b/openspec/changes/vale-config-schema/.openspec.yaml
new file mode 100644
index 00000000..563fab5a
--- /dev/null
+++ b/openspec/changes/vale-config-schema/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-09-21
diff --git a/openspec/changes/vale-config-schema/proposal.md b/openspec/changes/vale-config-schema/proposal.md
new file mode 100644
index 00000000..e781d8dc
--- /dev/null
+++ b/openspec/changes/vale-config-schema/proposal.md
@@ -0,0 +1,48 @@
+## Why
+
+A per-rule `.taskless/rules/vale/<id>/.vale.ini` is the one rule input nothing validates. The style YAML goes through `schemas/vale-rule.ts` and the pinned corpus; the config is carried into the assembled run config as verbatim text. `assemble.ts` strips a copied-in `StylesPath`/`MinAlertLevel` with `line.split("=")[0]` and recovers matchers with `/^\[(.+)\]$/`; `verify` checks that the file contains a `[` and the substring `<id>.<id>`. Nothing checks that a matcher carries the `tskl) rule` breadcrumb, that a value is `YES` or `NO`, that an assignment names this rule and not another one, or that the run-level keys stayed out. The spec says a rule SHALL NOT be able to override another rule's matchers, and nothing enforces it.
+
+The gap is visible in a dogfood repository (eleven voice rules over ~1,100 markdown files, notes dated 2026-09-21): a fourth `.taskless/**` matcher copied into every rule to keep fixtures quiet under a bare `vale` run that `check` never performs, a duplicated key whose meaning flipped when Vale 3.21.0 moved repeated assignments from first-wins to last-wins, and matchers whose ordering only a person who has read the scoping spec can tell is backwards. Each of these is a config that Vale accepts and that does something other than what its author wrote, and the engine's design exists to remove exactly that class of silent failure.
+
+## What Changes
+
+- **Every per-rule config is parsed into an AST** with `@jedmao/ini-parser` (`resolve: false`, `delimiter: /=/`; blank lines, which the parser reports as empty unnamed sections, are dropped). The AST is lossless and ordered, so every check below is a refinement over the file's own sequence and nothing is re-derived from text. The parser was chosen by measurement against four alternatives: the `ini` lineage nests section names on `.` and loses source order, both fatal for a file whose sections are globs and whose order is its precedence; `iniparser` drops the `tskl) rule` key; `config-ini-parser` truncates it to `rule` and is GPL-3.0. Recorded in taskless/cli#359.
+- **A zod schema over that AST**, `schemas/vale-config.ts`, keyed by the rule's directory id, rejects: any root-level property (`StylesPath`, `MinAlertLevel`, or anything else placed above the first matcher, which Vale reports as `W101` and ignores); a matcher without `tskl) rule = <id>`; an assignment key other than `<id>.<id>`; a value other than `YES`/`NO`; a non-empty `BasedOnStyles`; a file with no matcher; a file that never assigns `YES`. It reports, without rejecting: a key assigned twice inside one matcher; a `NO` matcher that precedes every `YES`; a `[*]` matcher; a `.taskless/**` matcher.
+- **`verify` runs the schema** in place of its two substring checks, and the rejections are attributable: the first Vale entries in `RULE_CONSTRAINTS`, so `verify --json` pairs each with a `constraintId` the way it already does for `sg`. Advisories reach the reader on the rule's `notice`.
+- **Assembly runs the schema and refuses the Vale run** when any rule's config is rejected, naming the rule and the line. This is the same treatment a malformed ast-grep rule already gets: the engine that owns the bad file reports a failure that reaches the exit code, and the other engines still run. A rule left out with a soft notice would verify, run, and report nothing, which is the failure being closed. Advisories go to the check's `notices`.
+- **Assembly stays byte concatenation.** The header, then per rule a breadcrumb comment and the source file verbatim. The schema's rejection of run-level keys removes the only string edit assembly performs today, and `sections` is read from the AST's section names. No serializer is introduced; the parser's `toString()` is measured not round-trip safe and is never called.
+- **The `create-vale-rule` recipe** says the config is schema-checked and what each rejection and advisory means, and its `.vale.ini` guidance drops the `.taskless/**` matcher. The `update` ledger records that a previously tolerated config now refuses the Vale run.
+
+Nothing here is **BREAKING**: `0.y.z`, and the only behavior a consumer can observe is that a config Vale was already misreading now says so. `patch`.
+
+## Capabilities
+
+### New Capabilities
+
+None.
+
+### Modified Capabilities
+
+- `cli-vale-rule-engine`: a new requirement that a rule's config is validated against a schema before it is assembled, and that a rejected config refuses the Vale run; the "Per-rule scoping is expressed in the rule's own Vale config" requirement gains the statement that the schema enforces the cross-rule prohibition it already makes.
+- `cli-rule-validation`: "Verify checks a rule's required components" gains scenarios for a rejected config; "A rejection names the constraint it violated" gains the Vale constraint ids.
+
+## Impact
+
+- New dependency: `@jedmao/ini-parser@0.2.4` (MIT, zero dependencies, ~300 lines, last published 2022). Pinned exactly. If it ever needs a change the file is vendored, not replaced with a parser of our own.
+- `packages/cli/src/schemas/vale-config.ts` (new): parse and validate; exports the AST type, the rejection list with constraint ids, and the advisory list.
+- `packages/cli/src/rules/constraints.ts`: first `vale` entries, `enforcedBy: "verify"` and one for assembly.
+- `packages/cli/src/rules/inspect.ts`: `verifyOneRule` for `vale` calls the schema; the two substring checks and their messages become schema rejections. `violations` is no longer always empty for Vale.
+- `packages/cli/src/rules/assemble.ts`: `ruleConfigBody` and `sectionPatternsOf` go; `assembleValeConfig` parses, validates, refuses on rejection, and concatenates the verbatim source. Its return carries the advisories.
+- `packages/cli/src/rules/dispatch.ts`: a refused assembly becomes the Vale engine's `failure`; advisories join `notices`.
+- `packages/cli/src/rules/vale/verify.ts`: the `buildIsolatingConfig` docblock still says a repeat inside one matcher is discarded, which stopped being true at 3.21.0; corrected in passing.
+- `packages/cli/src/agent/create-vale-rule.md` (topic bump), `packages/cli/src/agent/update.md` (0.11.3 ledger line).
+- Tests: schema unit tests over an ini fixture set (one file per rejection and advisory, plus the dogfood config shape), `verify --json` attribution for Vale, assembly refusal and the byte-identical assembly scenario re-pinned through the new path, and a vendor-contract case that the parser and Vale agree on which lines are matchers for the globs the corpus uses (`[*.md]`, `[docs/**/*.md]`, a character class like `[docs/[a-z]*.md]`).
+
+## Delivery shape
+
+**Stacked, merging forward, two PRs.** Each is safe on `main` alone:
+
+1. Parser, schema, constraints, and `verify`. Stricter `verify` output and nothing else; `check` is untouched. The changeset lives here.
+2. Assembly refusal, dispatch wiring, recipe, ledger, and the archive. Extends the changeset.
+
+Ordering them this way means an author whose config would be refused hears it from `verify` in a release before `check` starts refusing it, which is the direction the existing "silent disable" guidance already pushes people.
diff --git a/openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md b/openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md
new file mode 100644
index 00000000..027a9618
--- /dev/null
+++ b/openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md
@@ -0,0 +1,106 @@
+## MODIFIED Requirements
+
+### Requirement: Verify checks a rule's required components
+
+`verify` SHALL check that a rule has the components its engine requires and that they are well formed, and SHALL NOT require fixtures or test cases to exist.
+
+The two commands split because they have different preconditions. An agent part-way through authoring has a rule and no fixtures yet, and needs to know the rule itself is valid before it can write a meaningful test for it.
+
+Per engine, `verify` SHALL check:
+
+| Engine    | Components                                                                                                                     |
+| --------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| `sg`      | `<id>.yml` against the ast-grep schema and the Taskless required fields                                                        |
+| `vale`    | `<id>.yml` against the Vale rule schema and the Taskless required fields, and the rule's `.vale.ini` against the config schema |
+| `runtime` | `check.ts` present, and at least one capture rule under `captures/`                                                            |
+
+The `vale` row previously read "against Vale's own validation." Measured against the pinned 3.18.0 binary, that covers less than it claims: `level: bananas` is reported, while `extends: nonsense` and `scope: fenced` both verify clean and produce a rule that matches nothing. Vale validates a rule when it _runs_ one, and it runs one field at a time — so a name it does not recognize is not an error, it is a check that never fires. Schema validation is therefore its own layer for `vale`, as it already is for `sg`.
+
+#### Scenario: A rule with no fixtures still verifies
+
+- **WHEN** `verify` runs against a rule whose fixture buckets are empty or absent
+- **THEN** it SHALL report on the rule's components only
+- **AND** the absence of fixtures SHALL NOT be a verify failure
+
+#### Scenario: A malformed rule reports its own error
+
+- **WHEN** a Vale style declares a `level` outside `suggestion`/`warning`/`error`
+- **THEN** `verify` SHALL report that error, naming the field
+
+#### Scenario: An unrecognized extension point is rejected
+
+- **WHEN** a Vale style declares an `extends` that is not one of Vale's check types
+- **THEN** `verify` SHALL report it, naming the field and the accepted values
+- **AND** it SHALL NOT report the rule as valid
+
+#### Scenario: An unrecognized scope is rejected
+
+- **WHEN** a Vale style declares a `scope` that is not one of Vale's scope values
+- **THEN** `verify` SHALL report it, naming the field
+- **AND** a scope using the `~` negation or `&` chaining syntax over recognized values SHALL be accepted
+
+#### Scenario: A field belonging to another check type is rejected
+
+- **WHEN** a Vale style declares a field its `extends` does not accept, such as `tokens` on an `occurrence` check
+- **THEN** `verify` SHALL report it before Vale is invoked
+
+The failure it prevents is not a local one: Vale reports this as `E201: has invalid keys` and reads one assembled config per run, so a single rule with a stray field suppresses every other Vale rule's findings.
+
+#### Scenario: A rule config that never enables the rule is rejected
+
+- **WHEN** a Vale rule's `.vale.ini` declares matchers but no `<id>.<id> = YES`
+- **THEN** `verify` SHALL report that the rule is present but off, naming the file
+
+#### Scenario: A rule config that assigns a foreign key is rejected
+
+- **WHEN** a Vale rule's `.vale.ini` assigns a `<style>.<check>` key naming a different rule
+- **THEN** `verify` SHALL report it, naming the key and the line
+- **AND** it SHALL NOT report the rule as valid
+
+#### Scenario: A rule config advisory does not fail verify
+
+- **WHEN** a Vale rule's `.vale.ini` assigns the same key twice inside one matcher
+- **THEN** `verify` SHALL report the rule as valid
+- **AND** the repeat SHALL be printed as a notice on that rule
+
+### Requirement: A rejection names the constraint it violated
+
+`verify --json` and `test --json` SHALL report, per rule, the constraints a
+rejection violated, pairing a `constraintId` drawn from the published
+`RULE_CONSTRAINTS` with the message that reports it. Vale config rejections are
+attributable in the same way, under `vale-config-*` constraint ids.
+
+The existing `errors` array SHALL continue to carry every failure message,
+including those that are attributable. A consumer reading only `errors` SHALL
+see what it sees today, so this is additive.
+
+An error with no constraint behind it SHALL NOT be given one. A wrong
+attribution sends a reader to a rationale that does not describe their failure,
+which is worse than sending them to none.
+
+A consumer SHALL NOT have to match on message text to recover the constraint.
+Text matching rots the first time a message is rephrased, and rephrasing an
+error message is not a breaking change.
+
+#### Scenario: A mismatched rule id is attributed
+
+- **WHEN** `verify --json` refuses a rule whose `id:` does not match its directory
+- **THEN** the rule's result SHALL carry a violation with `constraintId` `sg-id-matches-directory`
+- **AND** the violation's message SHALL also appear in `errors`
+
+#### Scenario: An unattributable failure carries no id
+
+- **WHEN** `verify --json` reports a failure that no published constraint describes
+- **THEN** the message SHALL appear in `errors`
+- **AND** no violation SHALL be reported for it
+
+#### Scenario: A passing rule reports no violations
+
+- **WHEN** `verify --json` accepts a rule
+- **THEN** its violations SHALL be empty
+
+#### Scenario: A Vale config rejection is attributed
+
+- **WHEN** `verify --json` rejects a Vale rule whose config assigns a key naming another rule
+- **THEN** the rule's result SHALL carry a violation with `constraintId` `vale-config-own-key-only`
+- **AND** the violation's message SHALL also appear in `errors`
diff --git a/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md b/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
new file mode 100644
index 00000000..add16923
--- /dev/null
+++ b/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
@@ -0,0 +1,109 @@
+## ADDED 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`
+- sets `BasedOnStyles` to anything but empty
+- declares no matcher
+- never assigns `<id>.<id> = YES`
+
+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 `NO` matcher before every `YES` matcher (a disable that precedes the enable it narrows is re-enabled by it)
+- 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)
+
+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 repeated key is reported, not rejected
+
+- **WHEN** one matcher assigns `<id>.<id> = YES` and then `<id>.<id> = NO`
+- **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 `.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
+
+#### 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
+
+## MODIFIED Requirements
+
+### Requirement: Per-rule scoping is expressed in the rule's own Vale config
+
+The system SHALL express a Vale rule's scope through **matchers** — `[<glob>]` sections — declared in that rule's own `.taskless/rules/vale/<id>/.vale.ini`. Include is `<id>.<id> = YES`, exclude is `<id>.<id> = 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.21.0:
+
+- 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 **last** assignment wins. Through Vale 3.20.0 the first assignment won here; 3.21.0 made the two directions agree.
+
+A disable therefore SHALL be declared **after** the enable it narrows, within the rule's own config. Because precedence is positional and the run config is assembled, **assembly SHALL be deterministic**: rules ordered by id, and each rule's own matcher order preserved verbatim. A non-deterministic assembly would make a rule's effective scope depend on directory iteration order.
+
+A rule SHALL NOT be able to override another rule's matchers. It cannot know its own position in the assembled file, and cross-rule overriding through a shared file is the coupling the per-rule layout removes. The config schema enforces this: an assignment key naming any rule but the config's own is a rejection, at `verify` and at assembly.
+
+#### Scenario: A rule scopes itself
+
+- **WHEN** a rule's own config enables it under `[marketing/**]`
+- **THEN** the rule produces findings in `marketing/` files and none in `api/` files
+
+#### Scenario: A rule narrows itself
+
+- **WHEN** a rule's config enables it under `[marketing/**]` and then disables it under `[marketing/legacy/**]`
+- **THEN** the rule fires in `marketing/` but not in `marketing/legacy/`
+
+#### Scenario: A repeated key keeps its last assignment
+
+- **WHEN** a rule's config assigns `<id>.<id> = YES` and then `<id>.<id> = NO` inside one matcher, or across two `[<glob>]` sections with the same glob
+- **THEN** the rule does not fire on a matching file
+- **AND** the reverse order fires
+
+#### Scenario: Assembly order is stable
+
+- **WHEN** the same set of rules is assembled twice
+- **THEN** the resulting config SHALL be byte-identical
+- **AND** each rule's matchers SHALL appear in the order that rule declared them
+
+#### Scenario: Duplicate matchers merge
+
+- **WHEN** two rules each declare a `[*.md]` matcher
+- **THEN** both rules run on a matching `.md` file (Vale merges the matchers)
+
+#### Scenario: A rule cannot assign another rule's key
+
+- **WHEN** `no-simply/.vale.ini` assigns `no-hedging.no-hedging = NO`
+- **THEN** `verify` SHALL reject `no-simply`, naming the foreign key
+- **AND** the assembled run config SHALL NOT be written with that line in it
diff --git a/openspec/changes/vale-config-schema/tasks.md b/openspec/changes/vale-config-schema/tasks.md
new file mode 100644
index 00000000..eb7553bb
--- /dev/null
+++ b/openspec/changes/vale-config-schema/tasks.md
@@ -0,0 +1,18 @@
+## 1. Slice 1: parser, schema, constraints, verify (bottom of the stack)
+
+- [ ] 1.1 Add `@jedmao/ini-parser@0.2.4` to `packages/cli` as an exact pin. Verify `pnpm --filter @taskless/cli exec node -e 'require("@jedmao/ini-parser")'` resolves and the lockfile diff is that one package.
+- [ ] 1.2 Add `packages/cli/src/schemas/vale-config.ts`: `parseValeRuleConfig(source)` constructs the parser with `resolve: false` and `delimiter: /=/`, drops unnamed empty sections, and returns the AST; `validateValeRuleConfig(ruleId, source)` returns `{ rejections: RuleViolation[], advisories: string[], sections: string[] }`. Verify unit tests cover every rejection and advisory in the spec from an ini fixture set under `packages/cli/test/fixtures/vale-config/`, plus the three-matcher dogfood shape, a `[2024/**]` glob, and a character-class glob `[docs/[a-z]*.md]`.
+- [ ] 1.3 Add the `vale-config-*` entries to `RULE_CONSTRAINTS` (`no-root-keys`, `breadcrumb-required`, `own-key-only`, `value-yes-no`, `based-on-styles-empty`, `matcher-required`, `enabled-somewhere`), each with `engine: "vale"`, `enforcedBy`, summary, and rationale. Verify `reference.json` regenerates and its test passes.
+- [ ] 1.4 In `rules/inspect.ts`, replace the two substring checks for `vale` with the schema: rejections go to `errors` and `violations`, advisories to `notice`. Verify `verify --json` on a fixture rule with a foreign key carries `constraintId: "vale-config-own-key-only"` and the same message in `errors`; the existing "declares no matcher" and "never enables" tests still pass under their new constraint ids.
+- [ ] 1.5 Vendor-contract test: for each glob shape in the fixture set, the parser's section names equal what Vale enables (run the pinned binary with the config and a fixture file, assert the rule fires where the glob says). Verify with `pnpm --filter @taskless/cli test -- vale-vendor-contract`.
+- [ ] 1.6 Correct the `buildIsolatingConfig` docblock in `rules/vale/verify.ts` (a repeat inside one matcher keeps the last assignment as of 3.21.0).
+- [ ] 1.7 Add the single changeset (`patch`, `@taskless/cli`): `verify` validates a Vale rule's `.vale.ini` against a schema and names the constraint. Run `pnpm typecheck`, `pnpm lint`, `pnpm --filter @taskless/cli test`; open PR 1 against `main`.
+
+## 2. Slice 2: assembly refusal, dispatch, recipe, ledger (tip)
+
+- [ ] 2.1 In `rules/assemble.ts`, delete `ruleConfigBody` and `sectionPatternsOf`; `assembleValeConfig` validates each config, and on any rejection returns a refusal naming the rule and line without writing the file. Accepted configs are written verbatim under their breadcrumb; `sections` comes from the AST. Verify the "Assembly order is stable" test still asserts byte-identical output, and a new test asserts a foreign key leaves `.taskless/.vale.ini` unwritten.
+- [ ] 2.2 In `rules/dispatch.ts`, a refusal becomes the Vale engine's `failure` (reaches the exit code); advisories join `notices`. Verify a mixed-engine test shows ast-grep results alongside the Vale failure and a non-zero exit.
+- [ ] 2.3 Recipe `packages/cli/src/agent/create-vale-rule.md`: state that the config is schema-checked, list what is rejected and what is advised, drop any `.taskless/**` matcher from its examples, and bump the topic version. Verify `pnpm build && pnpm cli agent create-vale-rule` renders and `pnpm cli check` is clean over the prose.
+- [ ] 2.4 `packages/cli/src/agent/update.md`: 0.11.3 ledger entry — a config `check` used to tolerate now refuses the Vale run, with the `verify` command that names the line; bump the topic version.
+- [ ] 2.5 Extend the changeset with the refusal. Run `pnpm typecheck`, `pnpm lint`, `pnpm --filter @taskless/cli test`; open PR 2 against PR 1's branch.
+- [ ] 2.6 Archive on this tip: wip commit, `pnpm openspec archive vale-config-schema -y`, confirm every prior scenario in `cli-vale-rule-engine` (23 before) and `cli-rule-validation` (26 before) survives, reset to the wip SHA, then archive for real.

From 5e569816cfc068771aa3b349a01c99c3f828598b Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 21 Sep 2026 09:51:25 -0700
Subject: [PATCH 2/6] =?UTF-8?q?spec(vale):=20apply=20plan=20review=20?=
 =?UTF-8?q?=E2=80=94=20reject=20NO-before-YES,=20re-point=20the=20W101=20n?=
 =?UTF-8?q?otice=20requirement,=20state=20the=20patch=20case?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Review on #365:
- the notices requirement's motivating scenario (a top-level assignment,
  W101) is now a schema rejection before Vale runs; the requirement is
  MODIFIED to cover diagnostics the schema cannot foresee and keeps the
  scenario, re-pointed at the rejection
- a NO matcher before every YES moves from advisory to rejection: with
  BasedOnStyles empty it is dead or overridden in every config
- the foreign-key scenario no longer reads like per-line stripping
- the proposal says why slice 2's refusal is still patch under 0.y.z

Refs #359
---
 .../changes/vale-config-schema/proposal.md    |  6 +--
 .../specs/cli-vale-rule-engine/spec.md        | 38 +++++++++++++++++--
 openspec/changes/vale-config-schema/tasks.md  |  4 +-
 3 files changed, 40 insertions(+), 8 deletions(-)

diff --git a/openspec/changes/vale-config-schema/proposal.md b/openspec/changes/vale-config-schema/proposal.md
index e781d8dc..90cab837 100644
--- a/openspec/changes/vale-config-schema/proposal.md
+++ b/openspec/changes/vale-config-schema/proposal.md
@@ -7,13 +7,13 @@ The gap is visible in a dogfood repository (eleven voice rules over ~1,100 markd
 ## What Changes
 
 - **Every per-rule config is parsed into an AST** with `@jedmao/ini-parser` (`resolve: false`, `delimiter: /=/`; blank lines, which the parser reports as empty unnamed sections, are dropped). The AST is lossless and ordered, so every check below is a refinement over the file's own sequence and nothing is re-derived from text. The parser was chosen by measurement against four alternatives: the `ini` lineage nests section names on `.` and loses source order, both fatal for a file whose sections are globs and whose order is its precedence; `iniparser` drops the `tskl) rule` key; `config-ini-parser` truncates it to `rule` and is GPL-3.0. Recorded in taskless/cli#359.
-- **A zod schema over that AST**, `schemas/vale-config.ts`, keyed by the rule's directory id, rejects: any root-level property (`StylesPath`, `MinAlertLevel`, or anything else placed above the first matcher, which Vale reports as `W101` and ignores); a matcher without `tskl) rule = <id>`; an assignment key other than `<id>.<id>`; a value other than `YES`/`NO`; a non-empty `BasedOnStyles`; a file with no matcher; a file that never assigns `YES`. It reports, without rejecting: a key assigned twice inside one matcher; a `NO` matcher that precedes every `YES`; a `[*]` matcher; a `.taskless/**` matcher.
+- **A zod schema over that AST**, `schemas/vale-config.ts`, keyed by the rule's directory id, rejects: any root-level property (`StylesPath`, `MinAlertLevel`, or anything else placed above the first matcher, which Vale reports as `W101` and ignores); a matcher without `tskl) rule = <id>`; an assignment key other than `<id>.<id>`; a value other than `YES`/`NO`; a non-empty `BasedOnStyles`; a file with no matcher; a file that never assigns `YES`; a `NO` matcher that precedes every `YES` (with `BasedOnStyles` empty a rule is off until a `YES`, so such a `NO` is dead or overridden in every config — refusing it turns away nothing an author meant). It reports, without rejecting: a key assigned twice inside one matcher; a `[*]` matcher; a `.taskless/**` matcher. Each advisory has a legitimate reading, which is what separates the two lists.
 - **`verify` runs the schema** in place of its two substring checks, and the rejections are attributable: the first Vale entries in `RULE_CONSTRAINTS`, so `verify --json` pairs each with a `constraintId` the way it already does for `sg`. Advisories reach the reader on the rule's `notice`.
 - **Assembly runs the schema and refuses the Vale run** when any rule's config is rejected, naming the rule and the line. This is the same treatment a malformed ast-grep rule already gets: the engine that owns the bad file reports a failure that reaches the exit code, and the other engines still run. A rule left out with a soft notice would verify, run, and report nothing, which is the failure being closed. Advisories go to the check's `notices`.
 - **Assembly stays byte concatenation.** The header, then per rule a breadcrumb comment and the source file verbatim. The schema's rejection of run-level keys removes the only string edit assembly performs today, and `sections` is read from the AST's section names. No serializer is introduced; the parser's `toString()` is measured not round-trip safe and is never called.
 - **The `create-vale-rule` recipe** says the config is schema-checked and what each rejection and advisory means, and its `.vale.ini` guidance drops the `.taskless/**` matcher. The `update` ledger records that a previously tolerated config now refuses the Vale run.
 
-Nothing here is **BREAKING**: `0.y.z`, and the only behavior a consumer can observe is that a config Vale was already misreading now says so. `patch`.
+Nothing here is **BREAKING**, and the bump is `patch`. Slice 1 only makes `verify` stricter. Slice 2 makes `check` refuse a config it used to run to a zero exit, which looks like the "must react" case the bump guidance reserves higher bumps for, and is not: `0.y.z` is the first gate, and every config the schema refuses was already being misread by Vale — a rule enabled nowhere (`W101`), a rule silently overriding a neighbour, a disable the following enable cancelled. The release surfaces a defect the consumer already had rather than introducing one, the same call as dropping the 128 KB guard in 0.11.3, where files that were silently skipped are linted again. The changeset and the `update` ledger say what to do: run `verify`, which names the line.
 
 ## Capabilities
 
@@ -23,7 +23,7 @@ None.
 
 ### Modified Capabilities
 
-- `cli-vale-rule-engine`: a new requirement that a rule's config is validated against a schema before it is assembled, and that a rejected config refuses the Vale run; the "Per-rule scoping is expressed in the rule's own Vale config" requirement gains the statement that the schema enforces the cross-rule prohibition it already makes.
+- `cli-vale-rule-engine`: a new requirement that a rule's config is validated against a schema before it is assembled, and that a rejected config refuses the Vale run; "Per-rule scoping is expressed in the rule's own Vale config" gains the statement that the schema enforces the cross-rule prohibition and the disable-after-enable ordering it already requires; "Vale diagnostics on a successful run are surfaced as notices" is re-pointed at diagnostics the schema cannot foresee, since its motivating case (a top-level assignment) is now rejected before Vale runs.
 - `cli-rule-validation`: "Verify checks a rule's required components" gains scenarios for a rejected config; "A rejection names the constraint it violated" gains the Vale constraint ids.
 
 ## Impact
diff --git a/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md b/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
index add16923..3633b3fc 100644
--- a/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
+++ b/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
@@ -13,11 +13,11 @@ The schema SHALL reject a config that:
 - sets `BasedOnStyles` to anything but empty
 - declares no matcher
 - never assigns `<id>.<id> = YES`
+- declares a `NO` matcher before every `YES` matcher (with `BasedOnStyles` empty a rule is off until a `YES`, so 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 `NO` matcher before every `YES` matcher (a disable that precedes the enable it narrows is re-enabled by it)
 - 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)
 
@@ -43,6 +43,11 @@ Assembly SHALL write each accepted config's source verbatim. The parsed structur
 - **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 repeated key is reported, not rejected
 
 - **WHEN** one matcher assigns `<id>.<id> = YES` and then `<id>.<id> = NO`
@@ -71,7 +76,7 @@ Precedence is **positional**, and the system SHALL order matchers accordingly ra
 - 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 **last** assignment wins. Through Vale 3.20.0 the first assignment won here; 3.21.0 made the two directions agree.
 
-A disable therefore SHALL be declared **after** the enable it narrows, within the rule's own config. Because precedence is positional and the run config is assembled, **assembly SHALL be deterministic**: rules ordered by id, and each rule's own matcher order preserved verbatim. A non-deterministic assembly would make a rule's effective scope depend on directory iteration order.
+A disable therefore SHALL be declared **after** the enable it narrows, within the rule's own config; the config schema rejects a `NO` matcher that precedes every `YES`. Because precedence is positional and the run config is assembled, **assembly SHALL be deterministic**: rules ordered by id, and each rule's own matcher order preserved verbatim. A non-deterministic assembly would make a rule's effective scope depend on directory iteration order.
 
 A rule SHALL NOT be able to override another rule's matchers. It cannot know its own position in the assembled file, and cross-rule overriding through a shared file is the coupling the per-rule layout removes. The config schema enforces this: an assignment key naming any rule but the config's own is a rejection, at `verify` and at assembly.
 
@@ -106,4 +111,31 @@ A rule SHALL NOT be able to override another rule's matchers. It cannot know its
 
 - **WHEN** `no-simply/.vale.ini` assigns `no-hedging.no-hedging = NO`
 - **THEN** `verify` SHALL reject `no-simply`, naming the foreign key
-- **AND** the assembled run config SHALL NOT be written with that line in it
+- **AND** the Vale run SHALL be refused rather than assembled without that rule's config
+
+### Requirement: Vale diagnostics on a successful run are surfaced as notices
+
+When Vale exits zero and writes to stderr, the CLI SHALL surface that output as a notice on the check result. A notice SHALL NOT affect the exit code.
+
+This is the last line of defence, not the first. The case that motivated it — a rule assignment placed at the top level of the file, which Vale reports as ignoring with `W101` on stderr, a zero exit, and a well-formed empty result — is now rejected by the config schema at `verify` and at assembly, so Vale is never run over it. The requirement remains for every diagnostic the schema cannot foresee: Vale's own warnings about a style file, a format, or a config key that a future Vale adds. Discarding that output would leave the author with a rule that verifies, runs, and reports nothing, which is the silent-disable failure this engine's design exists to prevent.
+
+#### Scenario: An ignored rule assignment reaches the user
+
+- **WHEN** `.vale.ini` enables a rule outside any section and `check` runs
+- **THEN** the config schema SHALL reject that rule before Vale is invoked, naming the line
+- **AND** the rejection SHALL reach the user as the Vale engine's failure rather than as a notice
+
+#### Scenario: A diagnostic on a run that exits zero reaches the user
+
+- **WHEN** Vale exits zero and writes a diagnostic to stderr during `check`
+- **THEN** the CLI SHALL surface that diagnostic as a notice on the result
+
+#### Scenario: A diagnostic does not fail the check
+
+- **WHEN** Vale exits zero, writes a diagnostic to stderr, and reports no findings
+- **THEN** the check SHALL exit zero
+
+#### Scenario: Silence stays silent
+
+- **WHEN** Vale exits zero and writes nothing to stderr
+- **THEN** the CLI SHALL add no notice
diff --git a/openspec/changes/vale-config-schema/tasks.md b/openspec/changes/vale-config-schema/tasks.md
index eb7553bb..d9c312cc 100644
--- a/openspec/changes/vale-config-schema/tasks.md
+++ b/openspec/changes/vale-config-schema/tasks.md
@@ -2,7 +2,7 @@
 
 - [ ] 1.1 Add `@jedmao/ini-parser@0.2.4` to `packages/cli` as an exact pin. Verify `pnpm --filter @taskless/cli exec node -e 'require("@jedmao/ini-parser")'` resolves and the lockfile diff is that one package.
 - [ ] 1.2 Add `packages/cli/src/schemas/vale-config.ts`: `parseValeRuleConfig(source)` constructs the parser with `resolve: false` and `delimiter: /=/`, drops unnamed empty sections, and returns the AST; `validateValeRuleConfig(ruleId, source)` returns `{ rejections: RuleViolation[], advisories: string[], sections: string[] }`. Verify unit tests cover every rejection and advisory in the spec from an ini fixture set under `packages/cli/test/fixtures/vale-config/`, plus the three-matcher dogfood shape, a `[2024/**]` glob, and a character-class glob `[docs/[a-z]*.md]`.
-- [ ] 1.3 Add the `vale-config-*` entries to `RULE_CONSTRAINTS` (`no-root-keys`, `breadcrumb-required`, `own-key-only`, `value-yes-no`, `based-on-styles-empty`, `matcher-required`, `enabled-somewhere`), each with `engine: "vale"`, `enforcedBy`, summary, and rationale. Verify `reference.json` regenerates and its test passes.
+- [ ] 1.3 Add the `vale-config-*` entries to `RULE_CONSTRAINTS` (`no-root-keys`, `breadcrumb-required`, `own-key-only`, `value-yes-no`, `based-on-styles-empty`, `matcher-required`, `enabled-somewhere`, `disable-after-enable`), each with `engine: "vale"`, `enforcedBy`, summary, and rationale. Verify `reference.json` regenerates and its test passes.
 - [ ] 1.4 In `rules/inspect.ts`, replace the two substring checks for `vale` with the schema: rejections go to `errors` and `violations`, advisories to `notice`. Verify `verify --json` on a fixture rule with a foreign key carries `constraintId: "vale-config-own-key-only"` and the same message in `errors`; the existing "declares no matcher" and "never enables" tests still pass under their new constraint ids.
 - [ ] 1.5 Vendor-contract test: for each glob shape in the fixture set, the parser's section names equal what Vale enables (run the pinned binary with the config and a fixture file, assert the rule fires where the glob says). Verify with `pnpm --filter @taskless/cli test -- vale-vendor-contract`.
 - [ ] 1.6 Correct the `buildIsolatingConfig` docblock in `rules/vale/verify.ts` (a repeat inside one matcher keeps the last assignment as of 3.21.0).
@@ -15,4 +15,4 @@
 - [ ] 2.3 Recipe `packages/cli/src/agent/create-vale-rule.md`: state that the config is schema-checked, list what is rejected and what is advised, drop any `.taskless/**` matcher from its examples, and bump the topic version. Verify `pnpm build && pnpm cli agent create-vale-rule` renders and `pnpm cli check` is clean over the prose.
 - [ ] 2.4 `packages/cli/src/agent/update.md`: 0.11.3 ledger entry — a config `check` used to tolerate now refuses the Vale run, with the `verify` command that names the line; bump the topic version.
 - [ ] 2.5 Extend the changeset with the refusal. Run `pnpm typecheck`, `pnpm lint`, `pnpm --filter @taskless/cli test`; open PR 2 against PR 1's branch.
-- [ ] 2.6 Archive on this tip: wip commit, `pnpm openspec archive vale-config-schema -y`, confirm every prior scenario in `cli-vale-rule-engine` (23 before) and `cli-rule-validation` (26 before) survives, reset to the wip SHA, then archive for real.
+- [ ] 2.6 Archive on this tip: wip commit, `pnpm openspec archive vale-config-schema -y`, confirm every prior scenario in `cli-vale-rule-engine` (23 before, 32 after) and `cli-rule-validation` (26 before, 30 after) survives, reset to the wip SHA, then archive for real.

From 67c545ae412dd84e46c6b77a841cd5aa726dc760 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 21 Sep 2026 11:34:07 -0700
Subject: [PATCH 3/6] feat(vale): parse and validate per-rule .vale.ini against
 a schema

Add @jedmao/ini-parser (exact 0.2.4) and schemas/vale-config.ts, which
parses a rule's config into an ordered AST (resolve: false, delimiter /=/,
blank-line sections folded back into their matcher, source lines attached
by a side-by-side walk) and validates it keyed by the rule id: no root
keys, breadcrumb on every matcher, own key only, YES/NO values, empty
BasedOnStyles, a matcher, a YES somewhere, and no NO before every YES.
A repeated key, a [*] matcher and a .taskless/** matcher are advisories.

The vendor contract pins that the parser reads each corpus glob shape as
the matcher Vale enables, including a character class and a numeric
segment.
---
 packages/cli/package.json                     |   1 +
 packages/cli/src/schemas/vale-config.ts       | 516 ++++++++++++++++++
 .../test/fixtures/vale-config/bad-value.ini   |   4 +
 .../fixtures/vale-config/based-on-styles.ini  |   4 +
 .../vale-config/blank-inside-matcher.ini      |   6 +
 .../cli/test/fixtures/vale-config/dogfood.ini |  19 +
 .../test/fixtures/vale-config/foreign-key.ini |   5 +
 .../fixtures/vale-config/never-enabled.ini    |   4 +
 .../fixtures/vale-config/no-before-yes.ini    |   8 +
 .../fixtures/vale-config/no-breadcrumb.ini    |   3 +
 .../test/fixtures/vale-config/no-matcher.ini  |   1 +
 .../vale-config/repeat-across-sections.ini    |   8 +
 .../test/fixtures/vale-config/repeat-key.ini  |   5 +
 .../vale-config/root-assignment-only.ini      |   1 +
 .../test/fixtures/vale-config/root-keys.ini   |   7 +
 .../cli/test/fixtures/vale-config/star.ini    |   4 +
 .../test/fixtures/vale-config/stray-key.ini   |   5 +
 .../fixtures/vale-config/taskless-tree.ini    |   8 +
 .../cli/test/fixtures/vale-config/valid.ini   |   8 +
 .../fixtures/vale-config/wrong-breadcrumb.ini |   4 +
 packages/cli/test/vale-config-schema.test.ts  | 315 +++++++++++
 .../cli/test/vale-vendor-contract.test.ts     |  62 +++
 pnpm-lock.yaml                                |   8 +
 23 files changed, 1006 insertions(+)
 create mode 100644 packages/cli/src/schemas/vale-config.ts
 create mode 100644 packages/cli/test/fixtures/vale-config/bad-value.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/based-on-styles.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/blank-inside-matcher.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/dogfood.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/foreign-key.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/never-enabled.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/no-before-yes.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/no-breadcrumb.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/no-matcher.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/repeat-across-sections.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/repeat-key.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/root-assignment-only.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/root-keys.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/star.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/stray-key.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/taskless-tree.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/valid.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/wrong-breadcrumb.ini
 create mode 100644 packages/cli/test/vale-config-schema.test.ts

diff --git a/packages/cli/package.json b/packages/cli/package.json
index 2b347f67..5c3aa844 100644
--- a/packages/cli/package.json
+++ b/packages/cli/package.json
@@ -56,6 +56,7 @@
   },
   "dependencies": {
     "@clack/prompts": "^1.2.0",
+    "@jedmao/ini-parser": "0.2.4",
     "chalk": "^5.6.2",
     "citty": "^0.1.6",
     "jose": "^6.2.2",
diff --git a/packages/cli/src/schemas/vale-config.ts b/packages/cli/src/schemas/vale-config.ts
new file mode 100644
index 00000000..8ecc5e25
--- /dev/null
+++ b/packages/cli/src/schemas/vale-config.ts
@@ -0,0 +1,516 @@
+/**
+ * The schema for a rule's own `.vale.ini`, keyed by the rule's directory id.
+ *
+ * The counterpart of `vale-rule.ts` for the other file a Vale rule ships. The
+ * style YAML has been validated since the engine landed; the config was carried
+ * into the assembled run config as verbatim text, and `verify` asked two
+ * questions of it by substring. Nothing checked that a matcher carried its
+ * breadcrumb, that a value was `YES` or `NO`, that an assignment named this
+ * rule and not a neighbour, or that the run-level keys stayed out. Each of
+ * those is a config Vale accepts and reads as something other than what its
+ * author wrote, with a zero exit and an empty report.
+ *
+ * ## Shape
+ *
+ * The file is parsed into an ordered AST with `@jedmao/ini-parser` and every
+ * check is a refinement over that structure. Nothing here matches the file's
+ * text: the only place the source string is read after parsing is
+ * {@link locateLines}, which finds the 1-based line a node came from so a
+ * message can name it, and which validates nothing.
+ *
+ * The parser was chosen by measurement against four alternatives, recorded in
+ * taskless/cli#359. The `ini` lineage nests section names on `.` and loses
+ * source order, both fatal for a file whose sections are globs and whose order
+ * is its precedence; `iniparser` drops the `tskl) rule` key; and
+ * `config-ini-parser` truncates it to `rule`. Two of its options are
+ * load-bearing: `resolve: false`, because the default JSON-parses values and a
+ * `[2024/**]` matcher's neighbour `2024` would come back a number; and
+ * `delimiter: /=/`, because the default also splits on `:`, which a glob may
+ * contain. Its `toString()` is measured not round-trip safe and is never
+ * called; assembly writes the source bytes.
+ *
+ * Two things the parser does that this module undoes, both in
+ * {@link parseValeRuleConfig}:
+ *
+ * - A blank line is reported as a new section with an empty name, and the
+ *   lines after it land in that section rather than the matcher they belong
+ *   to. Such a section is folded back into the one before it (or into the root
+ *   when nothing precedes it), which is how Vale reads the file. A literal
+ *   `[]` header is indistinguishable from a blank line in the AST and folds
+ *   the same way; it names no file and is not a matcher anyone writes.
+ * - Root properties, the ones above the first `[matcher]`, arrive as a
+ *   section with no name at all. They are kept apart from the matchers because
+ *   the first rejection below is about exactly them.
+ *
+ * ## Rejections and advisories
+ *
+ * A rejection is a config no author means. An advisory has a legitimate
+ * reading, which is what separates the two lists. Every rejection is paired
+ * with a `vale-config-*` entry in `RULE_CONSTRAINTS`, so `verify --json` can
+ * attribute it the way it already does for ast-grep.
+ *
+ * One measured limit, in the too-strict direction: Vale strips an inline
+ * comment from a value (`YES # note` enables the rule), while the parser under
+ * `resolve: false` keeps it, so that line is rejected here with the value shown
+ * as Vale would not have read it. The message quotes the value, so the fix is
+ * visible in the report.
+ */
+
+import iniParser from "@jedmao/ini-parser";
+import { z } from "zod";
+
+import { VALE_VERSION } from "../rules/capabilities";
+import type { RuleViolation } from "../rules/constraints";
+
+/**
+ * The parser class, whichever way the module arrived.
+ *
+ * `@jedmao/ini-parser` is CommonJS with an `__esModule` marker and
+ * `exports.default = Parser`. A bundler honours the marker and hands the class
+ * to a default import; Node's own ESM loader does not, and hands the whole
+ * `module.exports` object, on which the class sits under `.default`. Vitest
+ * externalises dependencies and loads them through Node, the built CLI loads
+ * them through the bundle, so both shapes are real and both are handled.
+ */
+type IniParser = typeof iniParser;
+const Parser: IniParser =
+  (iniParser as unknown as { default?: IniParser }).default ?? iniParser;
+
+// --- The AST -----------------------------------------------------------------
+
+/** One `key = value` line. `value` is `""` for `key =` and for a bare key. */
+export interface ValeConfigProperty {
+  kind: "property";
+  key: string;
+  value: string;
+  /** 1-based line in the source, when it could be located. */
+  line?: number;
+}
+
+/** One `#` or `;` line, kept so the structure stays lossless and ordered. */
+export interface ValeConfigComment {
+  kind: "comment";
+  text: string;
+  line?: number;
+}
+
+export type ValeConfigNode = ValeConfigProperty | ValeConfigComment;
+
+/**
+ * One `[matcher]` and the lines under it, or the root when `name` is absent.
+ *
+ * The root is the run of lines above the first `[matcher]`. Vale reads keys
+ * there as run-level settings, which is why a rule config must not have any.
+ */
+export interface ValeConfigSection {
+  name?: string;
+  nodes: ValeConfigNode[];
+  /** 1-based line of the `[matcher]` header, when it could be located. */
+  line?: number;
+}
+
+/** A rule's `.vale.ini`, parsed. Sections are in source order. */
+export interface ValeRuleConfigAst {
+  sections: ValeConfigSection[];
+}
+
+/**
+ * Attach source lines to an AST by walking the two side by side.
+ *
+ * The parser carries no positions, so this walks the source's non-blank lines
+ * in order against the AST's sections and nodes in order: a line opening with
+ * `[` is the next section's header, and any other non-blank line is the next
+ * node in the current section. The header is checked against the section's
+ * name as a guard, and the walk stops assigning at the first disagreement (an
+ * escaped name, a `[]` header that was folded), so a message either names the
+ * right line or names none. A wrong line number sends a reader somewhere the
+ * problem is not, which is worse than no number.
+ *
+ * This is the one function that reads the source after parsing. It decides
+ * nothing about validity.
+ */
+function locateLines(source: string, sections: ValeConfigSection[]): void {
+  const lines = source.split(/\r?\n/);
+  let sectionIndex = sections[0]?.name === undefined ? 0 : -1;
+  let nodeIndex = 0;
+  for (const [index, raw] of lines.entries()) {
+    const line = raw.trim();
+    if (line === "") continue;
+    const lineNumber = index + 1;
+    if (line.startsWith("[")) {
+      sectionIndex += 1;
+      nodeIndex = 0;
+      const section = sections[sectionIndex];
+      if (section?.name === undefined || line !== `[${section.name}]`) return;
+      section.line = lineNumber;
+      continue;
+    }
+    const node = sections[sectionIndex]?.nodes[nodeIndex];
+    if (node === undefined) return;
+    nodeIndex += 1;
+    node.line = lineNumber;
+  }
+}
+
+/**
+ * Parse a rule's `.vale.ini` into an ordered AST.
+ *
+ * Blank-line sections are folded into their predecessor (see the module
+ * comment), the root section is the one with no name, and every node carries
+ * the source line it came from when that could be located.
+ */
+export function parseValeRuleConfig(source: string): ValeRuleConfigAst {
+  const parser = new Parser({ resolve: false, delimiter: /=/ });
+  const sections: ValeConfigSection[] = [];
+  for (const item of parser.parse(source).items) {
+    const nodes: ValeConfigNode[] = item.nodes.map((node) =>
+      "key" in node
+        ? {
+            kind: "property",
+            key: node.key,
+            // `resolve: false` guarantees a string when there is a value; a
+            // bare key or `key =` comes back `undefined` or `""`.
+            value: typeof node.value === "string" ? node.value : "",
+          }
+        : { kind: "comment", text: node.text }
+    );
+    const previous = sections.at(-1);
+    if (item.name === "") {
+      // A blank line, not a matcher. Its nodes belong to whatever came before
+      // it; with nothing before, they are root properties.
+      if (previous === undefined) {
+        if (nodes.length > 0) sections.push({ nodes });
+      } else {
+        previous.nodes.push(...nodes);
+      }
+      continue;
+    }
+    if (item.name === undefined) {
+      sections.push({ nodes });
+      continue;
+    }
+    sections.push({ name: item.name, nodes });
+  }
+  locateLines(source, sections);
+  return { sections };
+}
+
+// --- The schema --------------------------------------------------------------
+
+const propertySchema = z.object({
+  kind: z.literal("property"),
+  key: z.string(),
+  value: z.string(),
+  line: z.number().optional(),
+});
+
+const commentSchema = z.object({
+  kind: z.literal("comment"),
+  text: z.string(),
+  line: z.number().optional(),
+});
+
+const sectionSchema = z.object({
+  name: z.string().optional(),
+  nodes: z.array(z.discriminatedUnion("kind", [propertySchema, commentSchema])),
+  line: z.number().optional(),
+});
+
+const astSchema = z.object({ sections: z.array(sectionSchema) });
+
+/** The key every matcher must carry, naming the rule whose config it is in. */
+export const VALE_BREADCRUMB_KEY = "tskl) rule";
+
+const BASED_ON_STYLES_KEY = "BasedOnStyles";
+
+/** The constraint ids this schema can attribute a rejection to. */
+export type ValeConfigConstraintId = Extract<
+  RuleViolation["constraintId"],
+  `vale-config-${string}`
+>;
+
+function at(node: { line?: number }): string {
+  return node.line === undefined ? "" : ` line ${String(node.line)}`;
+}
+
+function matcherLabel(section: ValeConfigSection): string {
+  return `[${section.name ?? ""}]`;
+}
+
+/** `ruleId/.vale.ini line N:` — the prefix every message shares. */
+function where(ruleId: string, node: { line?: number }): string {
+  return `${ruleId}/.vale.ini${at(node)}:`;
+}
+
+function properties(section: ValeConfigSection): ValeConfigProperty[] {
+  return section.nodes.filter((node) => node.kind === "property");
+}
+
+/**
+ * A rule's config, validated against the rule it belongs to.
+ *
+ * Every refinement pushes a `custom` issue whose `params.constraintId` names
+ * the `RULE_CONSTRAINTS` entry it enforces, which is what lets
+ * {@link validateValeRuleConfig} attribute the rejection without matching on
+ * its own wording.
+ */
+function valeRuleConfigSchema(ruleId: string) {
+  const ownKey = `${ruleId}.${ruleId}`;
+  return astSchema.check((context) => {
+    const { sections } = context.value;
+    const fail = (
+      constraintId: ValeConfigConstraintId,
+      path: PropertyKey[],
+      message: string
+    ): void => {
+      context.issues.push({
+        code: "custom",
+        input: context.value,
+        path,
+        message,
+        params: { constraintId },
+      });
+    };
+
+    const matchers = sections.filter(
+      (section) => section.name !== undefined
+    ) as (ValeConfigSection & { name: string })[];
+
+    // Root: anything assigned above the first matcher. Vale reads it as a
+    // run-level key, warns W101 if it does not recognise it, and either way
+    // it enables nothing.
+    for (const [index, section] of sections.entries()) {
+      if (section.name !== undefined) continue;
+      for (const property of properties(section)) {
+        fail(
+          "vale-config-no-root-keys",
+          ["sections", index],
+          `${where(ruleId, property)} "${property.key}" is assigned above the first [matcher]. ` +
+            `Vale reads it as a run-level setting and ignores a rule assignment there (W101). ` +
+            `StylesPath and MinAlertLevel are set by the assembled run config; a rule assignment belongs inside a matcher.`
+        );
+      }
+    }
+
+    if (matchers.length === 0) {
+      fail(
+        "vale-config-matcher-required",
+        ["sections"],
+        `${ruleId}/.vale.ini declares no matcher, so the rule is scoped to nothing and will never run.`
+      );
+      return;
+    }
+
+    let enabledAnywhere = false;
+    /** Each matcher's final verdict on the rule, in source order. */
+    const verdicts: ("YES" | "NO" | undefined)[] = [];
+
+    for (const [index, section] of matchers.entries()) {
+      const path = ["sections", sections.indexOf(section)];
+      const label = matcherLabel(section);
+      const assignments = properties(section);
+      let verdict: "YES" | "NO" | undefined;
+
+      const breadcrumb = assignments.find(
+        (property) => property.key === VALE_BREADCRUMB_KEY
+      );
+      if (breadcrumb === undefined) {
+        fail(
+          "vale-config-breadcrumb-required",
+          path,
+          `${where(ruleId, section)} matcher ${label} has no "${VALE_BREADCRUMB_KEY} = ${ruleId}" breadcrumb, ` +
+            `so nothing attributes it to ${ruleId} once every rule's config is assembled into one file.`
+        );
+      } else if (breadcrumb.value !== ruleId) {
+        fail(
+          "vale-config-breadcrumb-required",
+          path,
+          `${where(ruleId, breadcrumb)} matcher ${label} carries "${VALE_BREADCRUMB_KEY} = ${breadcrumb.value}", ` +
+            `but this is ${ruleId}'s config. The breadcrumb names the rule whose config it is in.`
+        );
+      }
+
+      for (const property of assignments) {
+        if (property.key === VALE_BREADCRUMB_KEY) continue;
+        if (property.key === BASED_ON_STYLES_KEY) {
+          if (property.value !== "") {
+            fail(
+              "vale-config-based-on-styles-empty",
+              path,
+              `${where(ruleId, property)} matcher ${label} sets BasedOnStyles = "${property.value}". ` +
+                `It must be empty: a bundled style loaded here fires alongside ${ruleId} and reaches every rule whose matchers overlap.`
+            );
+          }
+          continue;
+        }
+        if (property.key !== ownKey) {
+          const foreign = property.key.includes(".");
+          fail(
+            "vale-config-own-key-only",
+            path,
+            foreign
+              ? `${where(ruleId, property)} matcher ${label} assigns "${property.key}", which names another rule. ` +
+                  `A rule's config may only enable or disable itself, as ${ownKey}; anything else is a cross-rule override.`
+              : `${where(ruleId, property)} matcher ${label} assigns "${property.key}", which is not a per-rule setting. ` +
+                  `Inside a matcher a rule's config carries only "${VALE_BREADCRUMB_KEY}", an empty BasedOnStyles, and ${ownKey}.`
+          );
+          continue;
+        }
+        if (property.value !== "YES" && property.value !== "NO") {
+          fail(
+            "vale-config-value-yes-no",
+            path,
+            `${where(ruleId, property)} ${ownKey} = "${property.value}" is not YES or NO. ` +
+              `Vale ${VALE_VERSION} reads a level name here as an override of the style's own level, and anything else as off, without saying so.`
+          );
+          continue;
+        }
+        verdict = property.value;
+        if (verdict === "YES") enabledAnywhere = true;
+      }
+      verdicts[index] = verdict;
+    }
+
+    if (!enabledAnywhere) {
+      fail(
+        "vale-config-enabled-somewhere",
+        ["sections"],
+        `${ruleId}/.vale.ini never enables ${ownKey}, so the rule is present but off.`
+      );
+      return;
+    }
+
+    // Ordering: a NO before every YES. With BasedOnStyles empty the rule is
+    // off until a YES, so such a NO is dead where nothing else matches and
+    // overridden where the later YES does. Reported against the first YES,
+    // which is the one that re-enables it.
+    const firstYes = verdicts.indexOf("YES");
+    const enabler = matchers[firstYes];
+    if (enabler === undefined) return;
+    for (const [index, section] of matchers.slice(0, firstYes).entries()) {
+      if (verdicts[index] !== "NO") continue;
+      fail(
+        "vale-config-disable-after-enable",
+        ["sections", sections.indexOf(section)],
+        `${where(ruleId, section)} matcher ${matcherLabel(section)} disables ${ruleId} before any matcher enables it, ` +
+          `and ${matcherLabel(enabler)}${at(enabler)} re-enables it afterwards, so this NO is either dead or overridden. ` +
+          `Precedence is positional: move the NO after the YES it narrows.`
+      );
+    }
+  });
+}
+
+// --- Advisories --------------------------------------------------------------
+
+/** The tree `check` excludes before Vale runs. */
+const TASKLESS_TREE_PREFIX = ".taskless/";
+
+/**
+ * What is true about a config that does not make it invalid.
+ *
+ * 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.
+ */
+function adviseValeRuleConfig(
+  ruleId: string,
+  ast: ValeRuleConfigAst
+): string[] {
+  const advisories: string[] = [];
+  /**
+   * Assignments seen per matcher name. Keyed by name rather than by section
+   * because Vale merges duplicate `[glob]` sections, so a key assigned once in
+   * each is a repeat in the config Vale reads.
+   */
+  const seen = new Map<string, Map<string, ValeConfigProperty>>();
+
+  for (const section of ast.sections) {
+    if (section.name === undefined) continue;
+    const label = matcherLabel(section);
+
+    if (section.name === "*") {
+      advisories.push(
+        `${where(ruleId, section)} matcher [*] enables ${ruleId} for every file Vale can read, code included. ` +
+          `Narrow it to the prose it is for (for example [*.md]) unless that is meant.`
+      );
+    }
+    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.`
+      );
+    }
+
+    const assignments =
+      seen.get(section.name) ?? new Map<string, ValeConfigProperty>();
+    seen.set(section.name, assignments);
+    for (const property of properties(section)) {
+      if (property.key === VALE_BREADCRUMB_KEY) continue;
+      const earlier = assignments.get(property.key);
+      if (earlier !== undefined) {
+        advisories.push(
+          `${where(ruleId, property)} matcher ${label} assigns ${property.key} again (first${at(earlier)}). ` +
+            `Vale ${VALE_VERSION} keeps the last assignment, "${property.value}"; through 3.20.0 it kept the first.`
+        );
+      }
+      assignments.set(property.key, property);
+    }
+  }
+  return advisories;
+}
+
+// --- The verdict -------------------------------------------------------------
+
+/** What the schema concluded about one rule's config. */
+export interface ValeRuleConfigVerdict {
+  /** Configs no author means, each attributed to its constraint. */
+  rejections: RuleViolation[];
+  /** True things about the config that do not make it invalid. */
+  advisories: string[];
+  /** Every matcher's pattern, in source order, exactly as the header spells it. */
+  sections: string[];
+}
+
+/**
+ * Validate a rule's `.vale.ini` against the rule it belongs to.
+ *
+ * `ruleId` is the rule's directory name, which is what the assembled config
+ * resolves `<id>.<id>` against. `source` is the file's text; it is parsed here
+ * and never re-serialised.
+ */
+export function validateValeRuleConfig(
+  ruleId: string,
+  source: string
+): ValeRuleConfigVerdict {
+  const ast = parseValeRuleConfig(source);
+  const result = valeRuleConfigSchema(ruleId).safeParse(ast);
+  const rejections: RuleViolation[] = result.success
+    ? []
+    : result.error.issues.map((issue) => {
+        // Every issue this schema raises is a `custom` one carrying its
+        // constraint; a structural issue would mean the AST builder and the
+        // schema disagree, which is a bug here rather than in the config, and
+        // it is surfaced as such rather than swallowed.
+        const attribution =
+          issue.code === "custom"
+            ? (issue.params as { constraintId?: ValeConfigConstraintId })
+            : undefined;
+        if (attribution?.constraintId === undefined) {
+          throw new Error(
+            `vale-config schema raised an issue with no constraint: ${issue.message}`
+          );
+        }
+        return {
+          constraintId: attribution.constraintId,
+          message: issue.message,
+        };
+      });
+  return {
+    rejections,
+    advisories: adviseValeRuleConfig(ruleId, ast),
+    sections: ast.sections
+      .map((section) => section.name)
+      .filter((name): name is string => name !== undefined),
+  };
+}
diff --git a/packages/cli/test/fixtures/vale-config/bad-value.ini b/packages/cli/test/fixtures/vale-config/bad-value.ini
new file mode 100644
index 00000000..b0290be1
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/bad-value.ini
@@ -0,0 +1,4 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = yes
diff --git a/packages/cli/test/fixtures/vale-config/based-on-styles.ini b/packages/cli/test/fixtures/vale-config/based-on-styles.ini
new file mode 100644
index 00000000..6e593840
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/based-on-styles.ini
@@ -0,0 +1,4 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles = Vale
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/blank-inside-matcher.ini b/packages/cli/test/fixtures/vale-config/blank-inside-matcher.ini
new file mode 100644
index 00000000..808f8b48
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/blank-inside-matcher.ini
@@ -0,0 +1,6 @@
+[*.md]
+tskl) rule = no-simply
+
+BasedOnStyles =
+
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/dogfood.ini b/packages/cli/test/fixtures/vale-config/dogfood.ini
new file mode 100644
index 00000000..8fe8cf44
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/dogfood.ini
@@ -0,0 +1,19 @@
+# The dogfood shape: three matchers, and the trailing .taskless/** block
+# that check never needs.
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+
+[2024/**]
+tskl) rule = no-simply
+no-simply.no-simply = NO
+
+[docs/[a-z]*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+
+[.taskless/**]
+tskl) rule = no-simply
+no-simply.no-simply = NO
diff --git a/packages/cli/test/fixtures/vale-config/foreign-key.ini b/packages/cli/test/fixtures/vale-config/foreign-key.ini
new file mode 100644
index 00000000..04c49c71
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/foreign-key.ini
@@ -0,0 +1,5 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+no-hedging.no-hedging = NO
diff --git a/packages/cli/test/fixtures/vale-config/never-enabled.ini b/packages/cli/test/fixtures/vale-config/never-enabled.ini
new file mode 100644
index 00000000..723a17a6
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/never-enabled.ini
@@ -0,0 +1,4 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = NO
diff --git a/packages/cli/test/fixtures/vale-config/no-before-yes.ini b/packages/cli/test/fixtures/vale-config/no-before-yes.ini
new file mode 100644
index 00000000..177f15ff
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/no-before-yes.ini
@@ -0,0 +1,8 @@
+[docs/legacy/**]
+tskl) rule = no-simply
+no-simply.no-simply = NO
+
+[docs/**]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/no-breadcrumb.ini b/packages/cli/test/fixtures/vale-config/no-breadcrumb.ini
new file mode 100644
index 00000000..c3605776
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/no-breadcrumb.ini
@@ -0,0 +1,3 @@
+[*.md]
+BasedOnStyles =
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/no-matcher.ini b/packages/cli/test/fixtures/vale-config/no-matcher.ini
new file mode 100644
index 00000000..e2c12450
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/no-matcher.ini
@@ -0,0 +1 @@
+# Nothing but a comment.
diff --git a/packages/cli/test/fixtures/vale-config/repeat-across-sections.ini b/packages/cli/test/fixtures/vale-config/repeat-across-sections.ini
new file mode 100644
index 00000000..c17dcc21
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/repeat-across-sections.ini
@@ -0,0 +1,8 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+
+[*.md]
+tskl) rule = no-simply
+no-simply.no-simply = NO
diff --git a/packages/cli/test/fixtures/vale-config/repeat-key.ini b/packages/cli/test/fixtures/vale-config/repeat-key.ini
new file mode 100644
index 00000000..a7d64e07
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/repeat-key.ini
@@ -0,0 +1,5 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+no-simply.no-simply = NO
diff --git a/packages/cli/test/fixtures/vale-config/root-assignment-only.ini b/packages/cli/test/fixtures/vale-config/root-assignment-only.ini
new file mode 100644
index 00000000..ab0ccb6a
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/root-assignment-only.ini
@@ -0,0 +1 @@
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/root-keys.ini b/packages/cli/test/fixtures/vale-config/root-keys.ini
new file mode 100644
index 00000000..71f627c3
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/root-keys.ini
@@ -0,0 +1,7 @@
+StylesPath = .
+MinAlertLevel = suggestion
+
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/star.ini b/packages/cli/test/fixtures/vale-config/star.ini
new file mode 100644
index 00000000..69efd5c8
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/star.ini
@@ -0,0 +1,4 @@
+[*]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/stray-key.ini b/packages/cli/test/fixtures/vale-config/stray-key.ini
new file mode 100644
index 00000000..2e03c849
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/stray-key.ini
@@ -0,0 +1,5 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+MinAlertLevel = error
+no-simply.no-simply = YES
diff --git a/packages/cli/test/fixtures/vale-config/taskless-tree.ini b/packages/cli/test/fixtures/vale-config/taskless-tree.ini
new file mode 100644
index 00000000..59238ffb
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/taskless-tree.ini
@@ -0,0 +1,8 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+
+[.taskless/**]
+tskl) rule = no-simply
+no-simply.no-simply = NO
diff --git a/packages/cli/test/fixtures/vale-config/valid.ini b/packages/cli/test/fixtures/vale-config/valid.ini
new file mode 100644
index 00000000..e8e01467
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/valid.ini
@@ -0,0 +1,8 @@
+[*.md]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+
+[docs/legacy/**]
+tskl) rule = no-simply
+no-simply.no-simply = NO
diff --git a/packages/cli/test/fixtures/vale-config/wrong-breadcrumb.ini b/packages/cli/test/fixtures/vale-config/wrong-breadcrumb.ini
new file mode 100644
index 00000000..5278401f
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/wrong-breadcrumb.ini
@@ -0,0 +1,4 @@
+[*.md]
+tskl) rule = no-hedging
+BasedOnStyles =
+no-simply.no-simply = YES
diff --git a/packages/cli/test/vale-config-schema.test.ts b/packages/cli/test/vale-config-schema.test.ts
new file mode 100644
index 00000000..25b3e420
--- /dev/null
+++ b/packages/cli/test/vale-config-schema.test.ts
@@ -0,0 +1,315 @@
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+
+import { describe, expect, it } from "vitest";
+
+import { VALE_VERSION } from "../src/rules/capabilities";
+import {
+  parseValeRuleConfig,
+  validateValeRuleConfig,
+} from "../src/schemas/vale-config";
+
+/**
+ * The config schema, over an ini fixture set.
+ *
+ * One fixture per rejection and per advisory, plus the dogfood shape the
+ * schema was written against: three matchers carrying the breadcrumb, an empty
+ * `BasedOnStyles`, `<id>.<id> = YES`, and the trailing `.taskless/**` block
+ * that `check` never needs. Every message is asserted on its text as well as
+ * its constraint id, so a fixture refused for some unrelated reason fails here
+ * rather than passing quietly.
+ *
+ * `vale-vendor-contract.test.ts` holds the parser to the binary: for each glob
+ * shape in this set, the section names it reads are the matchers Vale enables.
+ */
+
+const RULE = "no-simply";
+const fixtures = join(import.meta.dirname, "fixtures", "vale-config");
+
+function fixture(name: string): string {
+  return readFileSync(join(fixtures, `${name}.ini`), "utf8");
+}
+
+function verdict(name: string, ruleId = RULE) {
+  return validateValeRuleConfig(ruleId, fixture(name));
+}
+
+function ids(result: ReturnType<typeof validateValeRuleConfig>): string[] {
+  return result.rejections.map((rejection) => rejection.constraintId);
+}
+
+describe("parseValeRuleConfig", () => {
+  it("reads the dogfood shape as four matchers in source order", () => {
+    const ast = parseValeRuleConfig(fixture("dogfood"));
+    expect(ast.sections.map((section) => section.name)).toEqual([
+      undefined,
+      "*.md",
+      "2024/**",
+      "docs/[a-z]*.md",
+      ".taskless/**",
+    ]);
+    // The root holds only the two leading comments.
+    expect(ast.sections[0]?.nodes.map((node) => node.kind)).toEqual([
+      "comment",
+      "comment",
+    ]);
+  });
+
+  it("keeps a numeric-looking glob as a string", () => {
+    // The parser's default `resolve` JSON-parses values; the option is off so
+    // nothing here is ever a number.
+    const ast = parseValeRuleConfig("[2024/**]\nx = 2024\n");
+    expect(ast.sections[0]?.name).toBe("2024/**");
+    expect(ast.sections[0]?.nodes[0]).toMatchObject({
+      kind: "property",
+      key: "x",
+      value: "2024",
+    });
+  });
+
+  it("keeps a character-class glob whole", () => {
+    const ast = parseValeRuleConfig("[docs/[a-z]*.md]\n");
+    expect(ast.sections.map((section) => section.name)).toEqual([
+      "docs/[a-z]*.md",
+    ]);
+  });
+
+  it("keeps the breadcrumb key intact and splits only on =", () => {
+    const ast = parseValeRuleConfig(
+      "[*.md]\ntskl) rule = no-simply\nkey:with:colons = v\n"
+    );
+    expect(
+      ast.sections[0]?.nodes.map((node) =>
+        node.kind === "property" ? [node.key, node.value] : node.text
+      )
+    ).toEqual([
+      ["tskl) rule", "no-simply"],
+      ["key:with:colons", "v"],
+    ]);
+  });
+
+  it("folds a blank line inside a matcher back into that matcher", () => {
+    // The parser reports a blank line as a new, unnamed section and puts the
+    // lines after it there. Vale reads them as the same matcher.
+    const ast = parseValeRuleConfig(fixture("blank-inside-matcher"));
+    expect(ast.sections).toHaveLength(1);
+    expect(ast.sections[0]?.name).toBe("*.md");
+    expect(
+      ast.sections[0]?.nodes.map((node) =>
+        node.kind === "property" ? node.key : node.text
+      )
+    ).toEqual(["tskl) rule", "BasedOnStyles", "no-simply.no-simply"]);
+  });
+
+  it("attaches the source line to every header and property", () => {
+    const ast = parseValeRuleConfig(fixture("dogfood"));
+    const lines = ast.sections.map((section) => [
+      section.line,
+      section.nodes.map((node) => node.line),
+    ]);
+    expect(lines).toEqual([
+      [undefined, [1, 2]],
+      [3, [4, 5, 6]],
+      [8, [9, 10]],
+      [12, [13, 14, 15]],
+      [17, [18, 19]],
+    ]);
+  });
+
+  it("parses an empty file to no sections", () => {
+    expect(parseValeRuleConfig("").sections).toEqual([]);
+  });
+});
+
+describe("validateValeRuleConfig accepts", () => {
+  it("the dogfood shape, with only the .taskless/** advisory", () => {
+    const result = verdict("dogfood");
+    expect(result.rejections).toEqual([]);
+    expect(result.advisories).toHaveLength(1);
+    expect(result.advisories[0]).toMatch(
+      /line 17: matcher \[\.taskless\/\*\*\]/
+    );
+    expect(result.sections).toEqual([
+      "*.md",
+      "2024/**",
+      "docs/[a-z]*.md",
+      ".taskless/**",
+    ]);
+  });
+
+  it("an enable narrowed by a later disable, with nothing to say", () => {
+    const result = verdict("valid");
+    expect(result.rejections).toEqual([]);
+    expect(result.advisories).toEqual([]);
+    expect(result.sections).toEqual(["*.md", "docs/legacy/**"]);
+  });
+
+  it("a matcher with a blank line inside it", () => {
+    expect(verdict("blank-inside-matcher").rejections).toEqual([]);
+  });
+});
+
+describe("validateValeRuleConfig rejects", () => {
+  it("a run-level key above the first matcher, naming the key and line", () => {
+    const result = verdict("root-keys");
+    expect(ids(result)).toEqual([
+      "vale-config-no-root-keys",
+      "vale-config-no-root-keys",
+    ]);
+    expect(result.rejections[0]?.message).toBe(
+      'no-simply/.vale.ini line 1: "StylesPath" is assigned above the first [matcher]. ' +
+        "Vale reads it as a run-level setting and ignores a rule assignment there (W101). " +
+        "StylesPath and MinAlertLevel are set by the assembled run config; a rule assignment belongs inside a matcher."
+    );
+    expect(result.rejections[1]?.message).toMatch(
+      /line 2: "MinAlertLevel" is assigned above/
+    );
+  });
+
+  it("a rule assignment with no matcher at all, on both counts", () => {
+    // The W101 case that motivated the schema: Vale exits zero, finds nothing,
+    // and the rule is enabled nowhere.
+    const result = verdict("root-assignment-only");
+    expect(ids(result)).toEqual([
+      "vale-config-no-root-keys",
+      "vale-config-matcher-required",
+    ]);
+    expect(result.rejections[1]?.message).toBe(
+      "no-simply/.vale.ini declares no matcher, so the rule is scoped to nothing and will never run."
+    );
+  });
+
+  it("a matcher with no breadcrumb, naming the matcher", () => {
+    const result = verdict("no-breadcrumb");
+    expect(ids(result)).toEqual(["vale-config-breadcrumb-required"]);
+    expect(result.rejections[0]?.message).toBe(
+      'no-simply/.vale.ini line 1: matcher [*.md] has no "tskl) rule = no-simply" breadcrumb, ' +
+        "so nothing attributes it to no-simply once every rule's config is assembled into one file."
+    );
+  });
+
+  it("a breadcrumb naming another rule", () => {
+    const result = verdict("wrong-breadcrumb");
+    expect(ids(result)).toEqual(["vale-config-breadcrumb-required"]);
+    expect(result.rejections[0]?.message).toBe(
+      'no-simply/.vale.ini line 2: matcher [*.md] carries "tskl) rule = no-hedging", ' +
+        "but this is no-simply's config. The breadcrumb names the rule whose config it is in."
+    );
+  });
+
+  it("a key naming another rule, as a cross-rule override", () => {
+    const result = verdict("foreign-key");
+    expect(ids(result)).toEqual(["vale-config-own-key-only"]);
+    expect(result.rejections[0]?.message).toBe(
+      'no-simply/.vale.ini line 5: matcher [*.md] assigns "no-hedging.no-hedging", which names another rule. ' +
+        "A rule's config may only enable or disable itself, as no-simply.no-simply; anything else is a cross-rule override."
+    );
+  });
+
+  it("a run-level key inside a matcher", () => {
+    const result = verdict("stray-key");
+    expect(ids(result)).toEqual(["vale-config-own-key-only"]);
+    expect(result.rejections[0]?.message).toBe(
+      'no-simply/.vale.ini line 4: matcher [*.md] assigns "MinAlertLevel", which is not a per-rule setting. ' +
+        'Inside a matcher a rule\'s config carries only "tskl) rule", an empty BasedOnStyles, and no-simply.no-simply.'
+    );
+  });
+
+  it("a value other than YES or NO, and does not count it as an enable", () => {
+    // Measured against the pinned binary: `yes` leaves the rule off, and a
+    // level name turns it on at that level. Neither is what a scope says.
+    const result = verdict("bad-value");
+    expect(ids(result)).toEqual([
+      "vale-config-value-yes-no",
+      "vale-config-enabled-somewhere",
+    ]);
+    expect(result.rejections[0]?.message).toMatch(
+      /^no-simply\/\.vale\.ini line 4: no-simply\.no-simply = "yes" is not YES or NO\. Vale [\d.]+ reads a level name here/
+    );
+  });
+
+  it("a non-empty BasedOnStyles", () => {
+    const result = verdict("based-on-styles");
+    expect(ids(result)).toEqual(["vale-config-based-on-styles-empty"]);
+    expect(result.rejections[0]?.message).toBe(
+      'no-simply/.vale.ini line 3: matcher [*.md] sets BasedOnStyles = "Vale". ' +
+        "It must be empty: a bundled style loaded here fires alongside no-simply and reaches every rule whose matchers overlap."
+    );
+  });
+
+  it("a file with no matcher", () => {
+    const result = verdict("no-matcher");
+    expect(ids(result)).toEqual(["vale-config-matcher-required"]);
+    expect(result.sections).toEqual([]);
+  });
+
+  it("a config that never enables the rule", () => {
+    const result = verdict("never-enabled");
+    expect(ids(result)).toEqual(["vale-config-enabled-somewhere"]);
+    expect(result.rejections[0]?.message).toBe(
+      "no-simply/.vale.ini never enables no-simply.no-simply, so the rule is present but off."
+    );
+  });
+
+  it("a NO before every YES, naming both matchers", () => {
+    const result = verdict("no-before-yes");
+    expect(ids(result)).toEqual(["vale-config-disable-after-enable"]);
+    expect(result.rejections[0]?.message).toBe(
+      "no-simply/.vale.ini line 1: matcher [docs/legacy/**] disables no-simply before any matcher enables it, " +
+        "and [docs/**] line 5 re-enables it afterwards, so this NO is either dead or overridden. " +
+        "Precedence is positional: move the NO after the YES it narrows."
+    );
+  });
+
+  it("is keyed by the rule id, so the same file fails under another id", () => {
+    const result = verdict("valid", "no-hedging");
+    expect(ids(result)).toEqual([
+      "vale-config-breadcrumb-required",
+      "vale-config-own-key-only",
+      "vale-config-breadcrumb-required",
+      "vale-config-own-key-only",
+      "vale-config-enabled-somewhere",
+    ]);
+  });
+});
+
+describe("validateValeRuleConfig advises, without rejecting", () => {
+  it("a key assigned twice inside one matcher", () => {
+    const result = verdict("repeat-key");
+    expect(result.rejections).toEqual([]);
+    expect(result.advisories).toEqual([
+      "no-simply/.vale.ini line 5: matcher [*.md] assigns no-simply.no-simply again (first line 4). " +
+        `Vale ${VALE_VERSION} keeps the last assignment, "NO"; through 3.20.0 it kept the first.`,
+    ]);
+  });
+
+  it("a key assigned once in each of two sections with the same glob", () => {
+    // Vale merges duplicate `[glob]` sections, so this is the same repeat.
+    const result = verdict("repeat-across-sections");
+    expect(result.rejections).toEqual([]);
+    expect(result.advisories).toHaveLength(1);
+    expect(result.advisories[0]).toMatch(
+      /line 8: matcher \[\*\.md\] assigns no-simply\.no-simply again \(first line 4\)/
+    );
+    // Both headers are still reported as sections: the AST is the file's.
+    expect(result.sections).toEqual(["*.md", "*.md"]);
+  });
+
+  it("a [*] matcher", () => {
+    const result = verdict("star");
+    expect(result.rejections).toEqual([]);
+    expect(result.advisories).toEqual([
+      "no-simply/.vale.ini line 1: matcher [*] enables no-simply for every file Vale can read, code included. " +
+        "Narrow it to the prose it is for (for example [*.md]) unless that is meant.",
+    ]);
+  });
+
+  it("a .taskless/** matcher", () => {
+    const result = verdict("taskless-tree");
+    expect(result.rejections).toEqual([]);
+    expect(result.advisories).toEqual([
+      "no-simply/.vale.ini line 6: matcher [.taskless/**] is unnecessary: check excludes .taskless/ before Vale runs, " +
+        "so it acts only under a bare vale invocation.",
+    ]);
+  });
+});
diff --git a/packages/cli/test/vale-vendor-contract.test.ts b/packages/cli/test/vale-vendor-contract.test.ts
index 8a1dffb5..b72f6b94 100644
--- a/packages/cli/test/vale-vendor-contract.test.ts
+++ b/packages/cli/test/vale-vendor-contract.test.ts
@@ -21,6 +21,7 @@ import {
   valeMarkupList,
   valePlaintextList,
 } from "../src/rules/capabilities";
+import { parseValeRuleConfig } from "../src/schemas/vale-config";
 import { VALE_CHECK_TYPES } from "../src/schemas/vale-rule";
 
 /**
@@ -1396,3 +1397,64 @@ withVale("[section] header matching vs. the --glob CLI flag", () => {
     expect(Object.keys(stdout)).not.toContain("sub/CLAUDE.md");
   });
 });
+
+withVale(
+  "[section] globs read by the config parser match what Vale enables",
+  () => {
+    /**
+     * For each glob shape the corpus uses, the section name `parseValeRuleConfig`
+     * reads out of a config is the matcher Vale applies: the rule fires on the
+     * files the glob names and nowhere else.
+     *
+     * Depended on by: `schemas/vale-config.ts`, whose `sections` is what
+     * assembly will report as the run's matcher patterns, and every `verify`
+     * rejection that names a matcher. If the parser ever read a header
+     * differently from Vale — a character class truncated at its `]`, a numeric
+     * segment resolved to a number — a rejection would name a matcher that is
+     * not in the file, and `sections` would describe a run Vale did not make.
+     */
+    const shapes: {
+      glob: string;
+      fires: string[];
+      quiet: string[];
+    }[] = [
+      // `*` crosses `/`: Vale compiles a matcher without a path separator, so
+      // `[*.md]` is every markdown file at any depth. The block above shows the
+      // other half: a literal name does not recurse.
+      { glob: "*.md", fires: ["doc.md", "docs/deep.md"], quiet: ["doc.txt"] },
+      {
+        glob: "docs/**/*.md",
+        fires: ["docs/deep.md", "docs/a/b.md"],
+        quiet: ["doc.md", "docs/deep.txt"],
+      },
+      {
+        glob: "docs/[a-z]*.md",
+        fires: ["docs/deep.md"],
+        quiet: ["docs/Deep.md", "docs/1.md", "doc.md"],
+      },
+      { glob: "2024/**", fires: ["2024/note.md"], quiet: ["2023/note.md"] },
+    ];
+
+    it.each(shapes)("$glob", ({ glob, fires, quiet }) => {
+      const config = `${header}\n[${glob}]\ntskl) rule = no-simply\nrules.no-simply = YES\n`;
+      // The parser's reading of the header, before Vale's.
+      expect(parseValeRuleConfig(config).sections.at(-1)?.name).toBe(glob);
+
+      const documents = Object.fromEntries(
+        [...fires, ...quiet].map((path) => [path, "Just simply do it.\n"])
+      );
+      const cwd = project(config, { "no-simply": existence("simply") }, {});
+      for (const [path, body] of Object.entries(documents)) {
+        mkdirSync(join(cwd, path, ".."), { recursive: true });
+        writeFileSync(join(cwd, path), body);
+      }
+      // The whole tree, as `check` runs it. Measured the same with the paths
+      // passed explicitly; `.` is used so the block above and this one ask
+      // Vale the same way.
+      const result = runRaw(cwd, ["."], ["--no-exit"]);
+      expect(result.status, result.stderr).toBe(0);
+      const parsed = JSON.parse(result.stdout) as Record<string, unknown[]>;
+      expect(Object.keys(parsed).toSorted()).toEqual(fires.toSorted());
+    });
+  }
+);
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index ed466aef..108cd460 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -74,6 +74,9 @@ importers:
       '@clack/prompts':
         specifier: ^1.2.0
         version: 1.2.0
+      '@jedmao/ini-parser':
+        specifier: 0.2.4
+        version: 0.2.4
       chalk:
         specifier: ^5.6.2
         version: 5.6.2
@@ -674,6 +677,9 @@ packages:
       '@types/node':
         optional: true
 
+  '@jedmao/ini-parser@0.2.4':
+    resolution: {integrity: sha512-h/hrZFTA23DAXBF2ssK2jGI9W6X0YYVmlzRpsuOAEXdRfBTfh9W47w26FDHmTqJEQGPNxHp0mqD3G+eThZGMag==}
+
   '@jridgewell/sourcemap-codec@1.5.5':
     resolution: {integrity: sha512-cYQ9310grqxueWbl+WuIUIaiUaDcj7WOq5fVhEljNVgRfOUhY9fy2zTvfoqWsnebh8Sl70VScFbICvJnLKB0Og==}
 
@@ -2997,6 +3003,8 @@ snapshots:
     optionalDependencies:
       '@types/node': 25.3.3
 
+  '@jedmao/ini-parser@0.2.4': {}
+
   '@jridgewell/sourcemap-codec@1.5.5': {}
 
   '@manypkg/find-root@1.1.0':

From 51c55c8f108dd3e8d20b82ee2ef7efaf7abefc8c Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 21 Sep 2026 11:34:19 -0700
Subject: [PATCH 4/6] feat(verify): attribute Vale config rejections to
 vale-config-* constraints

verifyOneRule for vale runs the config schema in place of its two
substring checks. Each rejection reaches errors and violations under its
vale-config-* constraint, so verify --json pairs it with a constraintId
the way it already does for sg; advisories ride on notice. The eight
constraints join RULE_CONSTRAINTS with a scenario each in the constraints
suite, and reference.json is regenerated.

The shipped demo Vale config gains its tskl) rule breadcrumb, which the
schema now requires and taskless demo vale must verify under. The W101
check test keeps its run-time assertion (check is untouched until the
next slice) and now expects verify to reject the misplaced assignment
first.
---
 packages/cli/assets/demo-vale/.vale.ini       |  1 +
 packages/cli/assets/reference.json            | 58 +++++++++++-
 packages/cli/src/rules/constraints.ts         | 74 ++++++++++++++++
 packages/cli/src/rules/inspect.ts             | 55 ++++++++----
 packages/cli/test/constraints.test.ts         | 88 +++++++++++++++++++
 packages/cli/test/mixed-engine-check.test.ts  | 21 +++--
 .../cli/test/verify-test-commands.test.ts     | 45 +++++++++-
 7 files changed, 313 insertions(+), 29 deletions(-)

diff --git a/packages/cli/assets/demo-vale/.vale.ini b/packages/cli/assets/demo-vale/.vale.ini
index f00b40b2..eeeca4a3 100644
--- a/packages/cli/assets/demo-vale/.vale.ini
+++ b/packages/cli/assets/demo-vale/.vale.ini
@@ -1,5 +1,6 @@
 # Scoped to markdown, which is where prose rules belong. A demonstration rule
 # should never widen its own scope into a project's source.
 [**/*.md]
+tskl) rule = prefer-use-over-utilize
 BasedOnStyles =
 prefer-use-over-utilize.prefer-use-over-utilize = YES
diff --git a/packages/cli/assets/reference.json b/packages/cli/assets/reference.json
index 8af6d21a..3760d5a1 100644
--- a/packages/cli/assets/reference.json
+++ b/packages/cli/assets/reference.json
@@ -81,6 +81,62 @@
       "enforcedBy": "test",
       "summary": "A test file's own `id:` must equal the rule id.",
       "rationale": "Fixtures are attributed by the id inside the file, not by its name. A fixture carrying another rule's id is silently not counted, so a rule that ships one reads as a rule that shipped none. `verify` passes, because the FILE is there; `test` is where it bites."
+    },
+    {
+      "id": "vale-config-no-root-keys",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "A rule's `.vale.ini` assigns nothing above its first matcher; `StylesPath` and `MinAlertLevel` belong to the run.",
+      "rationale": "Vale reads a rule assignment placed above the first `[matcher]` as a run-level key, warns `W101` on stderr, ignores it, and exits zero. The rule verifies clean while enabled nowhere. `StylesPath` and `MinAlertLevel` are properties of the assembled run config, which sets both; a per-rule copy is either redundant or silently fights the header."
+    },
+    {
+      "id": "vale-config-breadcrumb-required",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "Every matcher carries a `tskl) rule = <id>` breadcrumb naming the rule whose config it is in.",
+      "rationale": "The breadcrumb is how a matcher is attributed once every rule's config is concatenated into the one file Vale reads. A matcher without one is an orphan in the assembled config: nothing can say which rule it came from, and the migration that split the old shared config left exactly such matchers behind as unattributable hand edits. Vale ignores the key, so it costs nothing at run time."
+    },
+    {
+      "id": "vale-config-own-key-only",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "Inside a matcher, the only assignments are the breadcrumb, an empty `BasedOnStyles`, and `<id>.<id>`.",
+      "rationale": "A `<style>.<check>` key naming any other rule is a cross-rule override, and a rule cannot know its own position in the assembled file, so whether the override wins depends on directory sort order. Any other key is a run-level or Vale-wide setting placed where it would apply to every rule after it. The per-rule layout exists to remove that coupling; this is what enforces it."
+    },
+    {
+      "id": "vale-config-value-yes-no",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "`<id>.<id>` is assigned exactly `YES` or `NO`.",
+      "rationale": "Vale also accepts a level name here (`warning`, `error`) to override the style's own, which would make the rule's severity depend on its config rather than its style file, and it reads anything else as `NO` without saying so. A rule's scope is a yes-or-no question, and its level is answered once, in the style."
+    },
+    {
+      "id": "vale-config-based-on-styles-empty",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "`BasedOnStyles` is empty in every matcher that sets it.",
+      "rationale": "`BasedOnStyles = Vale` loads a whole bundled style alongside the rule, so a fixture that fails on `Vale.Spelling` reads as the rule firing, and every other rule's matchers inherit the style wherever the globs overlap. The isolating config `test` runs sets it empty for the same reason. A rule enables itself by name, not by style."
+    },
+    {
+      "id": "vale-config-matcher-required",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "A rule's `.vale.ini` declares at least one `[matcher]`.",
+      "rationale": "A Vale rule is enabled only inside a matcher, so a config with none scopes the rule to nothing. Vale accepts the file and the rule never runs. That is the silent disable this engine's design exists to prevent."
+    },
+    {
+      "id": "vale-config-enabled-somewhere",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "Some matcher assigns `<id>.<id> = YES`.",
+      "rationale": "With `BasedOnStyles` empty a rule is off until a matcher turns it on. A config whose every matcher says `NO`, or none says anything, leaves the rule present but off: it verifies, it is assembled, and it reports nothing."
+    },
+    {
+      "id": "vale-config-disable-after-enable",
+      "engine": "vale",
+      "enforcedBy": "verify",
+      "summary": "A `NO` matcher comes after the `YES` it narrows, never before every `YES`.",
+      "rationale": "Matcher precedence is positional: where two matchers match a file, the later wins. A `NO` that precedes every `YES` is therefore either dead (the file matched nothing else, and the rule was already off) or overridden by the `YES` that follows it. Measured against the pinned Vale, `[docs/legacy/**] NO` then `[docs/**] YES` fires in `docs/legacy/`. No config means that, so it is refused rather than reported."
     }
   ],
   "rules": [
@@ -119,7 +175,7 @@
         },
         {
           "path": ".vale.ini",
-          "content": "# Scoped to markdown, which is where prose rules belong. A demonstration rule\n# should never widen its own scope into a project's source.\n[**/*.md]\nBasedOnStyles =\nprefer-use-over-utilize.prefer-use-over-utilize = YES\n"
+          "content": "# Scoped to markdown, which is where prose rules belong. A demonstration rule\n# should never widen its own scope into a project's source.\n[**/*.md]\ntskl) rule = prefer-use-over-utilize\nBasedOnStyles =\nprefer-use-over-utilize.prefer-use-over-utilize = YES\n"
         }
       ],
       "tests": {
diff --git a/packages/cli/src/rules/constraints.ts b/packages/cli/src/rules/constraints.ts
index 34f27f83..93b62016 100644
--- a/packages/cli/src/rules/constraints.ts
+++ b/packages/cli/src/rules/constraints.ts
@@ -128,6 +128,80 @@ export const RULE_CONSTRAINTS = [
     rationale:
       "Fixtures are attributed by the id inside the file, not by its name. A fixture carrying another rule's id is silently not counted, so a rule that ships one reads as a rule that shipped none. `verify` passes, because the FILE is there; `test` is where it bites.",
   },
+  // --- Vale: the rule's own `.vale.ini`, checked as a parsed structure -------
+  //
+  // Every entry below is decided by `schemas/vale-config.ts` over the ini AST,
+  // never over the file's text. The common thread is that Vale accepts each of
+  // these configs and does something other than what the author wrote, with a
+  // zero exit and an empty report: the rule verifies, runs, and finds nothing.
+  {
+    id: "vale-config-no-root-keys",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary:
+      "A rule's `.vale.ini` assigns nothing above its first matcher; `StylesPath` and `MinAlertLevel` belong to the run.",
+    rationale:
+      "Vale reads a rule assignment placed above the first `[matcher]` as a run-level key, warns `W101` on stderr, ignores it, and exits zero. The rule verifies clean while enabled nowhere. `StylesPath` and `MinAlertLevel` are properties of the assembled run config, which sets both; a per-rule copy is either redundant or silently fights the header.",
+  },
+  {
+    id: "vale-config-breadcrumb-required",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary:
+      "Every matcher carries a `tskl) rule = <id>` breadcrumb naming the rule whose config it is in.",
+    rationale:
+      "The breadcrumb is how a matcher is attributed once every rule's config is concatenated into the one file Vale reads. A matcher without one is an orphan in the assembled config: nothing can say which rule it came from, and the migration that split the old shared config left exactly such matchers behind as unattributable hand edits. Vale ignores the key, so it costs nothing at run time.",
+  },
+  {
+    id: "vale-config-own-key-only",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary:
+      "Inside a matcher, the only assignments are the breadcrumb, an empty `BasedOnStyles`, and `<id>.<id>`.",
+    rationale:
+      "A `<style>.<check>` key naming any other rule is a cross-rule override, and a rule cannot know its own position in the assembled file, so whether the override wins depends on directory sort order. Any other key is a run-level or Vale-wide setting placed where it would apply to every rule after it. The per-rule layout exists to remove that coupling; this is what enforces it.",
+  },
+  {
+    id: "vale-config-value-yes-no",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary: "`<id>.<id>` is assigned exactly `YES` or `NO`.",
+    rationale:
+      "Vale also accepts a level name here (`warning`, `error`) to override the style's own, which would make the rule's severity depend on its config rather than its style file, and it reads anything else as `NO` without saying so. A rule's scope is a yes-or-no question, and its level is answered once, in the style.",
+  },
+  {
+    id: "vale-config-based-on-styles-empty",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary: "`BasedOnStyles` is empty in every matcher that sets it.",
+    rationale:
+      "`BasedOnStyles = Vale` loads a whole bundled style alongside the rule, so a fixture that fails on `Vale.Spelling` reads as the rule firing, and every other rule's matchers inherit the style wherever the globs overlap. The isolating config `test` runs sets it empty for the same reason. A rule enables itself by name, not by style.",
+  },
+  {
+    id: "vale-config-matcher-required",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary: "A rule's `.vale.ini` declares at least one `[matcher]`.",
+    rationale:
+      "A Vale rule is enabled only inside a matcher, so a config with none scopes the rule to nothing. Vale accepts the file and the rule never runs. That is the silent disable this engine's design exists to prevent.",
+  },
+  {
+    id: "vale-config-enabled-somewhere",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary: "Some matcher assigns `<id>.<id> = YES`.",
+    rationale:
+      "With `BasedOnStyles` empty a rule is off until a matcher turns it on. A config whose every matcher says `NO`, or none says anything, leaves the rule present but off: it verifies, it is assembled, and it reports nothing.",
+  },
+  {
+    id: "vale-config-disable-after-enable",
+    engine: "vale",
+    enforcedBy: "verify",
+    summary:
+      "A `NO` matcher comes after the `YES` it narrows, never before every `YES`.",
+    rationale:
+      "Matcher precedence is positional: where two matchers match a file, the later wins. A `NO` that precedes every `YES` is therefore either dead (the file matched nothing else, and the rule was already off) or overridden by the `YES` that follows it. Measured against the pinned Vale, `[docs/legacy/**] NO` then `[docs/**] YES` fires in `docs/legacy/`. No config means that, so it is refused rather than reported.",
+  },
 ] as const satisfies readonly RuleConstraint[];
 
 /**
diff --git a/packages/cli/src/rules/inspect.ts b/packages/cli/src/rules/inspect.ts
index f3ab086a..b8e61d80 100644
--- a/packages/cli/src/rules/inspect.ts
+++ b/packages/cli/src/rules/inspect.ts
@@ -21,6 +21,7 @@ import {
   describeFixtureReport,
   runRuntimeFixtures,
 } from "./runtime/run-fixtures";
+import { validateValeRuleConfig } from "../schemas/vale-config";
 import { validateValeRule } from "../schemas/vale-rule";
 import { verifyRule, type VerifyResult } from "./verify";
 import { violate, type RuleViolation } from "./constraints";
@@ -238,33 +239,53 @@ export async function verifyOneRule(
       errors.push(`Style file not found or unreadable: ${stylePath}`);
     }
 
-    // A Vale rule with no config of its own declares no scope, so it is enabled
-    // nowhere — it would verify, run, and report nothing. That is the silent
-    // disable this engine's design exists to prevent, so it is an error here.
+    // The rule's own config, against the config schema. A Vale rule with no
+    // config declares no scope, so it is enabled nowhere — it would verify,
+    // run, and report nothing. That is the silent disable this engine's design
+    // exists to prevent, so a missing file is an error, and so is a config
+    // Vale would accept and read as something other than what its author
+    // wrote: a rule assignment above the first matcher, a matcher with no
+    // breadcrumb, a key naming another rule. Each rejection is attributed to
+    // its `vale-config-*` constraint; what is true but not invalid rides on
+    // `notice`.
+    const violations: RuleViolation[] = [];
+    let notice: string | undefined;
     const configPath = ruleConfigPath(cwd, engine, ruleId);
     if (configPath !== undefined) {
+      let config: string | undefined;
       try {
-        const config = await readFile(configPath, "utf8");
-        if (!config.includes("[")) {
-          errors.push(
-            `${ruleId}/.vale.ini declares no matcher, so the rule is scoped to nothing and will never run.`
-          );
-        } else if (!config.includes(`${ruleId}.${ruleId}`)) {
-          errors.push(
-            `${ruleId}/.vale.ini never enables ${ruleId}.${ruleId}, so the rule is present but off.`
-          );
-        }
+        config = await readFile(configPath, "utf8");
       } catch {
         errors.push(
           `${ruleId} has no .vale.ini, so nothing scopes it and it will never run.`
         );
       }
+      if (config !== undefined) {
+        const verdict = validateValeRuleConfig(ruleId, config);
+        for (const rejection of verdict.rejections) {
+          violate(
+            { errors, violations },
+            rejection.constraintId,
+            rejection.message
+          );
+        }
+        if (verdict.advisories.length > 0) {
+          notice = verdict.advisories.join("\n");
+        }
+      }
     }
 
-    // No constraint is published for this engine, so nothing here is
-    // attributable. Empty, never absent: a consumer must be able to tell "no
-    // constraint was broken" from "this CLI does not report violations".
-    return { engine, ruleId, ok: errors.length === 0, errors, violations: [] };
+    // `violations` is empty, never absent, when nothing failed: a consumer
+    // must be able to tell "no constraint was broken" from "this CLI does not
+    // report violations".
+    return {
+      engine,
+      ruleId,
+      ok: errors.length === 0,
+      errors,
+      violations,
+      ...(notice === undefined ? {} : { notice }),
+    };
   }
 
   // runtime
diff --git a/packages/cli/test/constraints.test.ts b/packages/cli/test/constraints.test.ts
index 224deae9..b7277444 100644
--- a/packages/cli/test/constraints.test.ts
+++ b/packages/cli/test/constraints.test.ts
@@ -113,6 +113,38 @@ async function verifyWritten(options: {
   };
 }
 
+/**
+ * Write one Vale rule directory with the given `.vale.ini`, then run `verify`.
+ *
+ * The style file is always valid, so the only thing that can refuse the rule
+ * is its config, which is what every `vale-config-*` scenario probes.
+ */
+async function verifyValeConfig(
+  config: string,
+  ruleId = "probe-rule"
+): Promise<{ ok: boolean; errors: string[]; violations: RuleViolation[] }> {
+  const directory = join(project, ".taskless/rules/vale", ruleId);
+  await mkdir(directory, { recursive: true });
+  await writeFile(
+    join(directory, `${ruleId}.yml`),
+    "extends: existence\nmessage: \"Avoid '%s'\"\nlevel: warning\ntokens:\n  - simply\n"
+  );
+  await writeFile(join(directory, ".vale.ini"), config);
+  const verification = await verifyOneRule(project, {
+    engine: "vale",
+    ruleId,
+  });
+  return {
+    ok: verification.ok,
+    errors: verification.errors,
+    violations: verification.violations,
+  };
+}
+
+/** The config every Vale scenario below is a mutation of. */
+const VALID_VALE_CONFIG =
+  "[*.md]\ntskl) rule = probe-rule\nBasedOnStyles =\nprobe-rule.probe-rule = YES\n";
+
 /**
  * The scenario that must violate each documented constraint.
  *
@@ -198,6 +230,56 @@ const VIOLATIONS: Record<string, Scenario> = {
       }),
     names: /has no fixtures, so nothing shows it fires or stays quiet/,
   },
+  "vale-config-no-root-keys": {
+    run: () => verifyValeConfig(`StylesPath = .\n${VALID_VALE_CONFIG}`),
+    names: /"StylesPath" is assigned above the first \[matcher\]/,
+  },
+  "vale-config-breadcrumb-required": {
+    run: () =>
+      verifyValeConfig(
+        "[*.md]\nBasedOnStyles =\nprobe-rule.probe-rule = YES\n"
+      ),
+    names: /has no "tskl\) rule = probe-rule" breadcrumb/,
+  },
+  "vale-config-own-key-only": {
+    run: () =>
+      verifyValeConfig(`${VALID_VALE_CONFIG}other-rule.other-rule = NO\n`),
+    names: /assigns "other-rule\.other-rule", which names another rule/,
+  },
+  "vale-config-value-yes-no": {
+    run: () =>
+      verifyValeConfig(
+        "[*.md]\ntskl) rule = probe-rule\nBasedOnStyles =\nprobe-rule.probe-rule = warning\n"
+      ),
+    names: /probe-rule\.probe-rule = "warning" is not YES or NO/,
+  },
+  "vale-config-based-on-styles-empty": {
+    run: () =>
+      verifyValeConfig(
+        "[*.md]\ntskl) rule = probe-rule\nBasedOnStyles = Vale\nprobe-rule.probe-rule = YES\n"
+      ),
+    names: /sets BasedOnStyles = "Vale"/,
+  },
+  "vale-config-matcher-required": {
+    run: () => verifyValeConfig("# nothing here\n"),
+    names: /declares no matcher, so the rule is scoped to nothing/,
+  },
+  "vale-config-enabled-somewhere": {
+    run: () =>
+      verifyValeConfig(
+        "[*.md]\ntskl) rule = probe-rule\nBasedOnStyles =\nprobe-rule.probe-rule = NO\n"
+      ),
+    names:
+      /never enables probe-rule\.probe-rule, so the rule is present but off/,
+  },
+  "vale-config-disable-after-enable": {
+    run: () =>
+      verifyValeConfig(
+        "[docs/legacy/**]\ntskl) rule = probe-rule\nprobe-rule.probe-rule = NO\n\n" +
+          "[docs/**]\ntskl) rule = probe-rule\nBasedOnStyles =\nprobe-rule.probe-rule = YES\n"
+      ),
+    names: /disables probe-rule before any matcher enables it/,
+  },
 };
 
 describe("every documented constraint is a check that still fires", () => {
@@ -341,6 +423,12 @@ describe("every documented constraint is a check that still fires", () => {
     // `violations` unreadable as "what generation must learn".
     expect(result.violations).toEqual([]);
   });
+
+  it("accepts the Vale config every vale-config-* scenario is a mutation of", async () => {
+    const result = await verifyValeConfig(VALID_VALE_CONFIG);
+    expect(result.ok, result.errors.join("; ")).toBe(true);
+    expect(result.violations).toEqual([]);
+  });
 });
 
 describe("the constraint list is fit to publish", () => {
diff --git a/packages/cli/test/mixed-engine-check.test.ts b/packages/cli/test/mixed-engine-check.test.ts
index e16136d8..3ced1096 100644
--- a/packages/cli/test/mixed-engine-check.test.ts
+++ b/packages/cli/test/mixed-engine-check.test.ts
@@ -294,10 +294,11 @@ describe("check over a project with both engines", () => {
     // indistinguishable from a clean run. Surfacing the warning is the only
     // thing standing between that mistake and a silently disabled rule.
     //
-    // `verify` catches the coarser version of this (no matcher at all, or the
-    // check never enabled) — see `verify-test-commands.test.ts`. It cannot
-    // catch a misplaced assignment, because the file does contain a matcher
-    // and does name the check. Only Vale knows, and only at run time.
+    // `verify` rejects this config before Vale ever sees it: the config schema
+    // refuses any assignment above the first matcher, under
+    // `vale-config-no-root-keys`. `check` does not yet consult the schema (that
+    // is the next slice of taskless/cli#359), so its run-time notice remains
+    // the last line of defence and is asserted here alongside the rejection.
     it("surfaces Vale's W101 when an assignment sits outside every matcher", async () => {
       const scaffold = await mkdtemp(join(tmpdir(), "taskless-w101-"));
       try {
@@ -311,8 +312,8 @@ describe("check over a project with both engines", () => {
           "extends: existence\nmessage: \"Avoid 'simply'\"\nlevel: warning\ntokens:\n  - simply\n"
         );
         // The mistake: enabled, but above the `[…]` line, so it belongs to no
-        // matcher. `verify` passes this — a matcher exists and the check is
-        // named — which is exactly why the run-time notice has to survive.
+        // matcher. A matcher exists and the check is named, so the substring
+        // checks `verify` used to run passed this; the schema does not.
         await writeFile(
           join(rule, ".vale.ini"),
           "no-simply.no-simply = YES\n[*.md]\ntskl) rule = no-simply\nBasedOnStyles =\n"
@@ -320,7 +321,13 @@ describe("check over a project with both engines", () => {
         await writeFile(join(scaffold, "doc.md"), "Just simply do it.\n");
 
         const verified = await runCli(["verify", "-d", scaffold, "--json"]);
-        expect(verified.exitCode).toBe(0);
+        expect(verified.exitCode).not.toBe(0);
+        const report = JSON.parse(verified.stdout) as {
+          rules: { violations: { constraintId: string }[] }[];
+        };
+        expect(
+          report.rules[0]?.violations.map((violation) => violation.constraintId)
+        ).toContain("vale-config-no-root-keys");
 
         const { stdout, stderr, exitCode } = await runCli([
           "check",
diff --git a/packages/cli/test/verify-test-commands.test.ts b/packages/cli/test/verify-test-commands.test.ts
index 20052747..a7da0a37 100644
--- a/packages/cli/test/verify-test-commands.test.ts
+++ b/packages/cli/test/verify-test-commands.test.ts
@@ -35,6 +35,7 @@ interface Report {
     ok: boolean;
     errors: string[];
     violations: { constraintId: string; message: string }[];
+    notice?: string;
   }[];
 }
 
@@ -169,12 +170,48 @@ describe("verify checks components without requiring tests", () => {
   });
 
   it("fails a Vale rule whose config never enables it", async () => {
-    await valeRule("no-simply", { config: "[*.md]\nBasedOnStyles =\n" });
+    await valeRule("no-simply", {
+      config: "[*.md]\ntskl) rule = no-simply\nBasedOnStyles =\n",
+    });
     const result = await runCli(["verify", "-d", cwd, "--json"]);
     expect(result.exitCode).not.toBe(0);
-    expect(
-      (JSON.parse(result.stdout) as Report).rules[0]?.errors.join(" ")
-    ).toContain("present but off");
+    const rule = (JSON.parse(result.stdout) as Report).rules[0];
+    expect(rule?.errors.join(" ")).toContain("present but off");
+    expect(rule?.violations.map((violation) => violation.constraintId)).toEqual(
+      ["vale-config-enabled-somewhere"]
+    );
+  });
+
+  // The config schema, through the real CLI. `vale-config-schema.test.ts`
+  // holds every rejection and advisory to its fixture; this says the schema is
+  // wired into `verify`, and that a rejection reaches `--json` attributed to
+  // its constraint, the way an sg rejection already does.
+  it("attributes a foreign key in a Vale config to its constraint", async () => {
+    await valeRule("no-simply", {
+      config: `${SCOPED}no-hedging.no-hedging = NO\n`,
+    });
+    const result = await runCli(["verify", "-d", cwd, "--json"]);
+    expect(result.exitCode).not.toBe(0);
+    const rule = (JSON.parse(result.stdout) as Report).rules[0];
+    expect(rule?.violations).toHaveLength(1);
+    expect(rule?.violations[0]?.constraintId).toBe("vale-config-own-key-only");
+    expect(rule?.violations[0]?.message).toMatch(
+      /line 5: matcher \[\*\.md\] assigns "no-hedging\.no-hedging", which names another rule/
+    );
+    // Repeated verbatim in `errors`, so a consumer reading only that sees it.
+    expect(rule?.errors).toContain(rule?.violations[0]?.message);
+  });
+
+  it("accepts a Vale config with a repeated key, and says so on notice", async () => {
+    await valeRule("no-simply", {
+      config: `${SCOPED}no-simply.no-simply = NO\n`,
+    });
+    const result = await runCli(["verify", "-d", cwd, "--json"]);
+    expect(result.exitCode).toBe(0);
+    const rule = (JSON.parse(result.stdout) as Report).rules[0];
+    expect(rule?.ok).toBe(true);
+    expect(rule?.violations).toEqual([]);
+    expect(rule?.notice).toMatch(/assigns no-simply\.no-simply again/);
   });
 
   // Found by running the recipe's own worked `consistency` rule under the

From e1de40ac15e14a2df92b0114dc0eeacb83f981c2 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 21 Sep 2026 11:34:26 -0700
Subject: [PATCH 5/6] docs(vale): correct the isolating-config docblock, add
 the changeset, tick slice 1

buildIsolatingConfig said a repeat inside one matcher is discarded; since
Vale 3.21.0 the last assignment wins there too. The changeset records
what verify now refuses and advises; check is unchanged in this slice.
---
 .changeset/vale-config-schema.md             |  5 +++++
 openspec/changes/vale-config-schema/tasks.md | 14 +++++++-------
 packages/cli/src/rules/vale/verify.ts        |  7 ++++---
 3 files changed, 16 insertions(+), 10 deletions(-)
 create mode 100644 .changeset/vale-config-schema.md

diff --git a/.changeset/vale-config-schema.md b/.changeset/vale-config-schema.md
new file mode 100644
index 00000000..ecd422cb
--- /dev/null
+++ b/.changeset/vale-config-schema.md
@@ -0,0 +1,5 @@
+---
+"@taskless/cli": patch
+---
+
+`verify` validates a Vale rule's `.vale.ini` against a schema and names the constraint each rejection violates. The config is parsed into an ordered structure and checked there: an assignment above the first matcher, a matcher without its `tskl) rule` breadcrumb, a key naming another rule, a value other than `YES`/`NO`, a non-empty `BasedOnStyles`, a config with no matcher or no `YES`, and a `NO` matcher that precedes every `YES` are each rejected under a `vale-config-*` constraint that `verify --json` reports in `violations[]` and `reference.json` publishes. A repeated key, a `[*]` matcher, and a `.taskless/**` matcher are reported as a notice without failing the rule. `check` is unchanged.
diff --git a/openspec/changes/vale-config-schema/tasks.md b/openspec/changes/vale-config-schema/tasks.md
index d9c312cc..765b5b62 100644
--- a/openspec/changes/vale-config-schema/tasks.md
+++ b/openspec/changes/vale-config-schema/tasks.md
@@ -1,12 +1,12 @@
 ## 1. Slice 1: parser, schema, constraints, verify (bottom of the stack)
 
-- [ ] 1.1 Add `@jedmao/ini-parser@0.2.4` to `packages/cli` as an exact pin. Verify `pnpm --filter @taskless/cli exec node -e 'require("@jedmao/ini-parser")'` resolves and the lockfile diff is that one package.
-- [ ] 1.2 Add `packages/cli/src/schemas/vale-config.ts`: `parseValeRuleConfig(source)` constructs the parser with `resolve: false` and `delimiter: /=/`, drops unnamed empty sections, and returns the AST; `validateValeRuleConfig(ruleId, source)` returns `{ rejections: RuleViolation[], advisories: string[], sections: string[] }`. Verify unit tests cover every rejection and advisory in the spec from an ini fixture set under `packages/cli/test/fixtures/vale-config/`, plus the three-matcher dogfood shape, a `[2024/**]` glob, and a character-class glob `[docs/[a-z]*.md]`.
-- [ ] 1.3 Add the `vale-config-*` entries to `RULE_CONSTRAINTS` (`no-root-keys`, `breadcrumb-required`, `own-key-only`, `value-yes-no`, `based-on-styles-empty`, `matcher-required`, `enabled-somewhere`, `disable-after-enable`), each with `engine: "vale"`, `enforcedBy`, summary, and rationale. Verify `reference.json` regenerates and its test passes.
-- [ ] 1.4 In `rules/inspect.ts`, replace the two substring checks for `vale` with the schema: rejections go to `errors` and `violations`, advisories to `notice`. Verify `verify --json` on a fixture rule with a foreign key carries `constraintId: "vale-config-own-key-only"` and the same message in `errors`; the existing "declares no matcher" and "never enables" tests still pass under their new constraint ids.
-- [ ] 1.5 Vendor-contract test: for each glob shape in the fixture set, the parser's section names equal what Vale enables (run the pinned binary with the config and a fixture file, assert the rule fires where the glob says). Verify with `pnpm --filter @taskless/cli test -- vale-vendor-contract`.
-- [ ] 1.6 Correct the `buildIsolatingConfig` docblock in `rules/vale/verify.ts` (a repeat inside one matcher keeps the last assignment as of 3.21.0).
-- [ ] 1.7 Add the single changeset (`patch`, `@taskless/cli`): `verify` validates a Vale rule's `.vale.ini` against a schema and names the constraint. Run `pnpm typecheck`, `pnpm lint`, `pnpm --filter @taskless/cli test`; open PR 1 against `main`.
+- [x] 1.1 Add `@jedmao/ini-parser@0.2.4` to `packages/cli` as an exact pin. Verify `pnpm --filter @taskless/cli exec node -e 'require("@jedmao/ini-parser")'` resolves and the lockfile diff is that one package.
+- [x] 1.2 Add `packages/cli/src/schemas/vale-config.ts`: `parseValeRuleConfig(source)` constructs the parser with `resolve: false` and `delimiter: /=/`, drops unnamed empty sections, and returns the AST; `validateValeRuleConfig(ruleId, source)` returns `{ rejections: RuleViolation[], advisories: string[], sections: string[] }`. Verify unit tests cover every rejection and advisory in the spec from an ini fixture set under `packages/cli/test/fixtures/vale-config/`, plus the three-matcher dogfood shape, a `[2024/**]` glob, and a character-class glob `[docs/[a-z]*.md]`.
+- [x] 1.3 Add the `vale-config-*` entries to `RULE_CONSTRAINTS` (`no-root-keys`, `breadcrumb-required`, `own-key-only`, `value-yes-no`, `based-on-styles-empty`, `matcher-required`, `enabled-somewhere`, `disable-after-enable`), each with `engine: "vale"`, `enforcedBy`, summary, and rationale. Verify `reference.json` regenerates and its test passes.
+- [x] 1.4 In `rules/inspect.ts`, replace the two substring checks for `vale` with the schema: rejections go to `errors` and `violations`, advisories to `notice`. Verify `verify --json` on a fixture rule with a foreign key carries `constraintId: "vale-config-own-key-only"` and the same message in `errors`; the existing "declares no matcher" and "never enables" tests still pass under their new constraint ids.
+- [x] 1.5 Vendor-contract test: for each glob shape in the fixture set, the parser's section names equal what Vale enables (run the pinned binary with the config and a fixture file, assert the rule fires where the glob says). Verify with `pnpm --filter @taskless/cli test -- vale-vendor-contract`.
+- [x] 1.6 Correct the `buildIsolatingConfig` docblock in `rules/vale/verify.ts` (a repeat inside one matcher keeps the last assignment as of 3.21.0).
+- [x] 1.7 Add the single changeset (`patch`, `@taskless/cli`): `verify` validates a Vale rule's `.vale.ini` against a schema and names the constraint. Run `pnpm typecheck`, `pnpm lint`, `pnpm --filter @taskless/cli test`; open PR 1 against `main`.
 
 ## 2. Slice 2: assembly refusal, dispatch, recipe, ledger (tip)
 
diff --git a/packages/cli/src/rules/vale/verify.ts b/packages/cli/src/rules/vale/verify.ts
index dfb706a5..a66a6927 100644
--- a/packages/cli/src/rules/vale/verify.ts
+++ b/packages/cli/src/rules/vale/verify.ts
@@ -37,9 +37,10 @@ function stylesPath(cwd: string): string {
  * - `BasedOnStyles =` is empty, so none of Vale's bundled styles load. Without
  *   it a fixture could fail on `Vale.Spelling` and be read as the rule firing.
  * - Exactly one assignment of the key, in one matcher. Precedence here is
- *   positional (a later matcher wins; a repeat inside one matcher is
- *   discarded), so a config that assigned it twice would be relying on the
- *   rule that bit the scoping spec.
+ *   positional in both directions (a later matcher wins, and since Vale
+ *   3.21.0 so does a later repeat inside one matcher; through 3.20.0 the
+ *   first repeat won), so a config that assigned it twice would be relying
+ *   on the rule that bit the scoping spec, and on which Vale is reading it.
  *
  * `scripts/generate-vale-schema.ts` builds a second isolating config for its
  * probes, and `runOne` in `test/vale-schema-contract.test.ts` a third. Neither

From a62a893fe5a8d19c5c74916a48c3daafa173c777 Mon Sep 17 00:00:00 2001
From: Jakob Heuser <jakob@codedrift.com>
Date: Mon, 21 Sep 2026 12:01:03 -0700
Subject: [PATCH 6/6] feat(vale): judge enabled-somewhere and ordering by each
 matcher's final verdict

Vale merges same-glob sections and keeps the last assignment, so a YES
that a later NO overrides never reaches it. The schema now folds sections
by name, keeps each matcher's final verdict, and reads both the
enabled-somewhere and disable-after-enable checks from those verdicts: a
config whose only YES is overridden is rejected as present but off, while
the repeat itself stays an advisory. Spec scenarios updated to match, with
sibling fixtures pinning the accepted shape.
---
 .../specs/cli-rule-validation/spec.md         |  8 ++-
 .../specs/cli-vale-rule-engine/spec.md        | 12 +++-
 packages/cli/src/schemas/vale-config.ts       | 59 +++++++++++++------
 .../repeat-across-sections-still-enabled.ini  | 12 ++++
 .../vale-config/repeat-key-still-enabled.ini  |  9 +++
 packages/cli/test/vale-config-schema.test.ts  | 51 +++++++++++++---
 .../cli/test/verify-test-commands.test.ts     | 19 +++++-
 7 files changed, 139 insertions(+), 31 deletions(-)
 create mode 100644 packages/cli/test/fixtures/vale-config/repeat-across-sections-still-enabled.ini
 create mode 100644 packages/cli/test/fixtures/vale-config/repeat-key-still-enabled.ini

diff --git a/openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md b/openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md
index 027a9618..bfdb4ff5 100644
--- a/openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md
+++ b/openspec/changes/vale-config-schema/specs/cli-rule-validation/spec.md
@@ -59,10 +59,16 @@ The failure it prevents is not a local one: Vale reports this as `E201: has inva
 
 #### Scenario: A rule config advisory does not fail verify
 
-- **WHEN** a Vale rule's `.vale.ini` assigns the same key twice inside one matcher
+- **WHEN** a Vale rule's `.vale.ini` assigns the same key twice inside one matcher, and another matcher still enables the rule
 - **THEN** `verify` SHALL report the rule as valid
 - **AND** the repeat SHALL be printed as a notice on that rule
 
+#### Scenario: A rule config whose only enable is overridden is rejected
+
+- **WHEN** a Vale rule's `.vale.ini` assigns `<id>.<id> = YES` and then `<id>.<id> = NO` in its only matcher
+- **THEN** `verify` SHALL report that the rule is present but off, under `vale-config-enabled-somewhere`
+- **AND** the repeat SHALL still be printed as a notice on that rule
+
 ### Requirement: A rejection names the constraint it violated
 
 `verify --json` and `test --json` SHALL report, per rule, the constraints a
diff --git a/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md b/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
index 3633b3fc..27495515 100644
--- a/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
+++ b/openspec/changes/vale-config-schema/specs/cli-vale-rule-engine/spec.md
@@ -12,8 +12,8 @@ The schema SHALL reject a config that:
 - assigns a value other than `YES` or `NO`
 - sets `BasedOnStyles` to anything but empty
 - declares no matcher
-- never assigns `<id>.<id> = YES`
-- declares a `NO` matcher before every `YES` matcher (with `BasedOnStyles` empty a rule is off until a `YES`, so such a `NO` is either dead or overridden by the `YES` that follows; no config means it)
+- 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 (with `BasedOnStyles` empty a rule is off until a `YES`, so 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:
 
@@ -50,10 +50,16 @@ Assembly SHALL write each accepted config's source verbatim. The parsed structur
 
 #### Scenario: A repeated key is reported, not rejected
 
-- **WHEN** one matcher assigns `<id>.<id> = YES` and then `<id>.<id> = NO`
+- **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/**`
diff --git a/packages/cli/src/schemas/vale-config.ts b/packages/cli/src/schemas/vale-config.ts
index 8ecc5e25..3f6bb192 100644
--- a/packages/cli/src/schemas/vale-config.ts
+++ b/packages/cli/src/schemas/vale-config.ts
@@ -301,15 +301,34 @@ function valeRuleConfigSchema(ruleId: string) {
       return;
     }
 
-    let enabledAnywhere = false;
-    /** Each matcher's final verdict on the rule, in source order. */
-    const verdicts: ("YES" | "NO" | undefined)[] = [];
-
-    for (const [index, section] of matchers.entries()) {
+    /**
+     * Each matcher's FINAL verdict on the rule, folded by name and in the
+     * order the names first appear.
+     *
+     * Vale merges every `[glob]` section with the same name into one matcher
+     * and keeps the last assignment, so a `YES` followed by a `NO`, in one
+     * section or across two same-glob sections, is a matcher that says `NO`.
+     * The two checks below read these verdicts rather than any single
+     * assignment, because a config whose only `YES` is overridden that way
+     * leaves the rule present but off, which is the silent disable this
+     * schema exists to refuse. `enabledSomewhere` records whether a `YES` was
+     * ever written, which only decides how that rejection is worded.
+     */
+    const verdicts = new Map<
+      string,
+      { section: ValeConfigSection; verdict: "YES" | "NO" | undefined }
+    >();
+    let enabledSomewhere = false;
+
+    for (const section of matchers) {
       const path = ["sections", sections.indexOf(section)];
       const label = matcherLabel(section);
       const assignments = properties(section);
-      let verdict: "YES" | "NO" | undefined;
+      const folded = verdicts.get(section.name) ?? {
+        section,
+        verdict: undefined,
+      };
+      verdicts.set(section.name, folded);
 
       const breadcrumb = assignments.find(
         (property) => property.key === VALE_BREADCRUMB_KEY
@@ -365,30 +384,32 @@ function valeRuleConfigSchema(ruleId: string) {
           );
           continue;
         }
-        verdict = property.value;
-        if (verdict === "YES") enabledAnywhere = true;
+        folded.verdict = property.value;
+        if (property.value === "YES") enabledSomewhere = true;
       }
-      verdicts[index] = verdict;
     }
 
-    if (!enabledAnywhere) {
+    const final = [...verdicts.values()];
+    const firstYes = final.findIndex((entry) => entry.verdict === "YES");
+    if (firstYes === -1) {
       fail(
         "vale-config-enabled-somewhere",
         ["sections"],
-        `${ruleId}/.vale.ini never enables ${ownKey}, so the rule is present but off.`
+        enabledSomewhere
+          ? `${ruleId}/.vale.ini enables ${ownKey} only where a later assignment to the same matcher turns it off again, so the rule is present but off.`
+          : `${ruleId}/.vale.ini never enables ${ownKey}, so the rule is present but off.`
       );
       return;
     }
 
-    // Ordering: a NO before every YES. With BasedOnStyles empty the rule is
-    // off until a YES, so such a NO is dead where nothing else matches and
-    // overridden where the later YES does. Reported against the first YES,
-    // which is the one that re-enables it.
-    const firstYes = verdicts.indexOf("YES");
-    const enabler = matchers[firstYes];
+    // Ordering: a NO-verdict matcher before every YES-verdict matcher. With
+    // BasedOnStyles empty the rule is off until a YES, so such a NO is dead
+    // where nothing else matches and overridden where the later YES does.
+    // Reported against the first YES, which is the one that re-enables it.
+    const enabler = final[firstYes]?.section;
     if (enabler === undefined) return;
-    for (const [index, section] of matchers.slice(0, firstYes).entries()) {
-      if (verdicts[index] !== "NO") continue;
+    for (const { section, verdict } of final.slice(0, firstYes)) {
+      if (verdict !== "NO") continue;
       fail(
         "vale-config-disable-after-enable",
         ["sections", sections.indexOf(section)],
diff --git a/packages/cli/test/fixtures/vale-config/repeat-across-sections-still-enabled.ini b/packages/cli/test/fixtures/vale-config/repeat-across-sections-still-enabled.ini
new file mode 100644
index 00000000..b7e7792a
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/repeat-across-sections-still-enabled.ini
@@ -0,0 +1,12 @@
+[docs/**]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+
+[*.md]
+tskl) rule = no-simply
+no-simply.no-simply = YES
+
+[*.md]
+tskl) rule = no-simply
+no-simply.no-simply = NO
diff --git a/packages/cli/test/fixtures/vale-config/repeat-key-still-enabled.ini b/packages/cli/test/fixtures/vale-config/repeat-key-still-enabled.ini
new file mode 100644
index 00000000..e2652633
--- /dev/null
+++ b/packages/cli/test/fixtures/vale-config/repeat-key-still-enabled.ini
@@ -0,0 +1,9 @@
+[docs/**]
+tskl) rule = no-simply
+BasedOnStyles =
+no-simply.no-simply = YES
+
+[*.md]
+tskl) rule = no-simply
+no-simply.no-simply = YES
+no-simply.no-simply = NO
diff --git a/packages/cli/test/vale-config-schema.test.ts b/packages/cli/test/vale-config-schema.test.ts
index 25b3e420..b2a02950 100644
--- a/packages/cli/test/vale-config-schema.test.ts
+++ b/packages/cli/test/vale-config-schema.test.ts
@@ -251,6 +251,43 @@ describe("validateValeRuleConfig rejects", () => {
     );
   });
 
+  it("a YES overridden by a later NO in the same matcher, as present but off", () => {
+    // The verdict is the matcher's FINAL assignment (Vale keeps the last), so
+    // the only YES here never reaches Vale. The repeat is still advised.
+    const result = verdict("repeat-key");
+    expect(ids(result)).toEqual(["vale-config-enabled-somewhere"]);
+    expect(result.rejections[0]?.message).toBe(
+      "no-simply/.vale.ini enables no-simply.no-simply only where a later assignment to the same matcher turns it off again, so the rule is present but off."
+    );
+    expect(result.advisories).toHaveLength(1);
+    expect(result.advisories[0]).toMatch(/assigns no-simply\.no-simply again/);
+  });
+
+  it("a YES overridden by a NO in a second section with the same glob", () => {
+    // Vale merges same-glob sections before it reads them, so this is the
+    // same override split across two headers.
+    const result = verdict("repeat-across-sections");
+    expect(ids(result)).toEqual(["vale-config-enabled-somewhere"]);
+    expect(result.rejections[0]?.message).toMatch(
+      /enables no-simply\.no-simply only where a later assignment to the same matcher turns it off again/
+    );
+    expect(result.sections).toEqual(["*.md", "*.md"]);
+  });
+
+  it("judges the ordering by folded verdicts, not by any single assignment", () => {
+    // [docs/legacy/**] reads YES then NO, so its verdict is NO, and it sits
+    // before the only YES-verdict matcher: the same rejection as a plain NO.
+    const result = validateValeRuleConfig(
+      RULE,
+      "[docs/legacy/**]\ntskl) rule = no-simply\nno-simply.no-simply = YES\nno-simply.no-simply = NO\n\n" +
+        "[docs/**]\ntskl) rule = no-simply\nBasedOnStyles =\nno-simply.no-simply = YES\n"
+    );
+    expect(ids(result)).toEqual(["vale-config-disable-after-enable"]);
+    expect(result.rejections[0]?.message).toMatch(
+      /line 1: matcher \[docs\/legacy\/\*\*\] disables no-simply before any matcher enables it, and \[docs\/\*\*\] line 6/
+    );
+  });
+
   it("a NO before every YES, naming both matchers", () => {
     const result = verdict("no-before-yes");
     expect(ids(result)).toEqual(["vale-config-disable-after-enable"]);
@@ -274,25 +311,25 @@ describe("validateValeRuleConfig rejects", () => {
 });
 
 describe("validateValeRuleConfig advises, without rejecting", () => {
-  it("a key assigned twice inside one matcher", () => {
-    const result = verdict("repeat-key");
+  it("a key assigned twice inside one matcher, while a YES survives elsewhere", () => {
+    const result = verdict("repeat-key-still-enabled");
     expect(result.rejections).toEqual([]);
     expect(result.advisories).toEqual([
-      "no-simply/.vale.ini line 5: matcher [*.md] assigns no-simply.no-simply again (first line 4). " +
+      "no-simply/.vale.ini line 9: matcher [*.md] assigns no-simply.no-simply again (first line 8). " +
         `Vale ${VALE_VERSION} keeps the last assignment, "NO"; through 3.20.0 it kept the first.`,
     ]);
   });
 
   it("a key assigned once in each of two sections with the same glob", () => {
     // Vale merges duplicate `[glob]` sections, so this is the same repeat.
-    const result = verdict("repeat-across-sections");
+    const result = verdict("repeat-across-sections-still-enabled");
     expect(result.rejections).toEqual([]);
     expect(result.advisories).toHaveLength(1);
     expect(result.advisories[0]).toMatch(
-      /line 8: matcher \[\*\.md\] assigns no-simply\.no-simply again \(first line 4\)/
+      /line 12: matcher \[\*\.md\] assigns no-simply\.no-simply again \(first line 8\)/
     );
-    // Both headers are still reported as sections: the AST is the file's.
-    expect(result.sections).toEqual(["*.md", "*.md"]);
+    // Every header is still reported as a section: the AST is the file's.
+    expect(result.sections).toEqual(["docs/**", "*.md", "*.md"]);
   });
 
   it("a [*] matcher", () => {
diff --git a/packages/cli/test/verify-test-commands.test.ts b/packages/cli/test/verify-test-commands.test.ts
index a7da0a37..9ace0a7f 100644
--- a/packages/cli/test/verify-test-commands.test.ts
+++ b/packages/cli/test/verify-test-commands.test.ts
@@ -203,8 +203,12 @@ describe("verify checks components without requiring tests", () => {
   });
 
   it("accepts a Vale config with a repeated key, and says so on notice", async () => {
+    // The repeat is in a matcher that ends NO, but [docs/**] before it keeps
+    // the rule enabled somewhere, so the config is accepted with a notice.
     await valeRule("no-simply", {
-      config: `${SCOPED}no-simply.no-simply = NO\n`,
+      config:
+        "[docs/**]\ntskl) rule = no-simply\nBasedOnStyles =\nno-simply.no-simply = YES\n\n" +
+        `${SCOPED}no-simply.no-simply = NO\n`,
     });
     const result = await runCli(["verify", "-d", cwd, "--json"]);
     expect(result.exitCode).toBe(0);
@@ -214,6 +218,19 @@ describe("verify checks components without requiring tests", () => {
     expect(rule?.notice).toMatch(/assigns no-simply\.no-simply again/);
   });
 
+  it("rejects a Vale config whose only YES a later NO overrides", async () => {
+    await valeRule("no-simply", {
+      config: `${SCOPED}no-simply.no-simply = NO\n`,
+    });
+    const result = await runCli(["verify", "-d", cwd, "--json"]);
+    expect(result.exitCode).not.toBe(0);
+    const rule = (JSON.parse(result.stdout) as Report).rules[0];
+    expect(rule?.violations.map((violation) => violation.constraintId)).toEqual(
+      ["vale-config-enabled-somewhere"]
+    );
+    expect(rule?.notice).toMatch(/assigns no-simply\.no-simply again/);
+  });
+
   // Found by running the recipe's own worked `consistency` rule under the
   // rule-directory layout. Vale compiles a consistency rule's name into its
   // pattern as an RE2 group name, so a hyphen fails the file with E201 — and