fix(cli): say "validates" where a sentence means the renamed check

The passes matched the command's name, not its inflections, so prose
saying a rule "verifies clean" kept meaning the old `verify`, which is
now `validate`, while the word `verify` now names the fixture-running
command. Two of those sentences are constraint rationales published in
`reference.json`; the rest are comments and test prose.

The spec delta also stops carrying three scenario titles that named the
old commands ("Verifying one rule catches a collision", "Test reports the
findings its fixtures produced", "Testing a runtime rule reaches no
network"). A MODIFIED block cannot rename a scenario, so their two
requirements move to REMOVED plus ADDED, as "Validate checks a rule's
required components" already had. Checked on a scratch archive: every
prior scenario survives, and only the five intended titles change.

Found in the second review of #492.

Author: theCodeDrift

openspec/changes/rename-rule-checks/specs/cli-rule-validation/spec.md

@@ -87,7 +87,7 @@
       "engine": "vale",
       "enforcedBy": "validate",
       "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."
+      "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 validates 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",
@@ -129,7 +129,7 @@
       "engine": "vale",
       "enforcedBy": "validate",
       "summary": "Some matcher assigns `<id>.<id> = YES`.",
-      "rationale": "No style is loaded, so 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."
+      "rationale": "No style is loaded, so 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 validates, it is assembled, and it reports nothing."
     },
     {
       "id": "vale-config-disable-after-enable",

packages/cli/assets/reference.json

@@ -267,7 +267,7 @@ async function pruneEmpty(
  * its own style, so the same rule is now `<id>.<id>`.
  *
  * Carrying the old name across would leave a config Vale parses happily,
- * reports nothing for, and exits zero on — the rule verified, the check ran,
+ * reports nothing for, and exits zero on — the rule validated, the check ran,
  * and no finding ever appeared. Found by migrating a real project and noticing
  * the Vale rule stopped firing while ast-grep kept working.
  */

packages/cli/src/filesystem/migrations/0005-rule-directories.ts

@@ -133,7 +133,7 @@ export const RULE_CONSTRAINTS = [
   // 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.
+  // zero exit and an empty report: the rule validates, runs, and finds nothing.
   //
   // `enforcedBy` reads `validate` for all of them even though `check` runs the
   // same schema and refuses the Vale run on a rejection. The field answers a
@@ -148,7 +148,7 @@ export const RULE_CONSTRAINTS = [
     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.",
+      "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 validates 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",
@@ -198,7 +198,7 @@ export const RULE_CONSTRAINTS = [
     enforcedBy: "validate",
     summary: "Some matcher assigns `<id>.<id> = YES`.",
     rationale:
-      "No style is loaded, so 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.",
+      "No style is loaded, so 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 validates, it is assembled, and it reports nothing.",
   },
   {
     id: "vale-config-disable-after-enable",

packages/cli/src/rules/constraints.ts

@@ -155,7 +155,7 @@ export type DeliveryAssessment =
  * Decide whether a whole file set may be written, BEFORE anything is written.
  *
  * Every check runs against the set as a unit and the first failure refuses all
- * of it. A partially written rule directory is worse than none: it verifies as
+ * of it. A partially written rule directory is worse than none: it validates as
  * a broken rule two steps from the cause, and the delivery that produced it has
  * already reported success.
  */
@@ -380,7 +380,7 @@ async function clearSymlinkedPath(
  * case-insensitive filesystem a delivered `captures/Logs.yml` written into an
  * existing `captures/logs.yml` keeps the on-disk spelling, so an exact compare
  * would find `captures/logs.yml` unmentioned and delete the file just written —
- * leaving a rule with no capture, which verifies as incomplete and never fires.
+ * leaving a rule with no capture, which validates as incomplete and never fires.
  * The cost is on a case-sensitive filesystem, where a stale sibling differing
  * only in case is spared. That is the right way round to be wrong: sparing a
  * stale file leaves the merge behavior this change narrows, while deleting a
@@ -521,7 +521,7 @@ export class PurgeIncompleteError extends Error {
  * - **Writes come first, deletions second.** Every delivered file is on disk
  *   before anything is unlinked, so an IO failure part-way leaves a directory
  *   that is a superset of the blessed rule — the merge behavior being narrowed,
- *   which is survivable — rather than a rule missing pieces, which verifies as
+ *   which is survivable — rather than a rule missing pieces, which validates as
  *   incomplete or silently never fires. That ordering is what makes a failed
  *   purge recoverable rather than dangerous: an entry that cannot be removed
  *   is reported by name and the rest of the pass still runs, so the worst case

packages/cli/src/rules/deliver.ts

@@ -62,7 +62,7 @@ export interface DemoManifest {
    * Listed rather than globbed. Several are dot-paths — under `.tests/`, or
    * named `.env` — and glob helpers skip those by default, so a glob would
    * embed the rule file and silently omit every case. That produces a rule that
-   * writes, verifies, and has nothing to prove, which is the exact failure
+   * writes, validates, and has nothing to prove, which is the exact failure
    * these runners exist to catch.
    */
   testPaths: readonly string[];

packages/cli/src/rules/demo/manifest.ts

@@ -37,7 +37,7 @@ function collisionFrom(
 /**
  * Whether this one id is held by more than one engine.
  *
- * Asked per rule rather than only over the whole tree, because verifying the
+ * Asked per rule rather than only over the whole tree, because validating the
  * rule an author just wrote is the moment a collision is cheapest to fix. A
  * whole-project pass that only diffs the engine id lists would say nothing at
  * exactly that moment.

packages/cli/src/rules/id-uniqueness.ts

@@ -86,7 +86,7 @@ export const VALE_TIMEOUT_MS = 60_000;
  * still exiting zero. That combination is not noise. Vale reports a rule
  * assignment placed outside any section as `W101 … is ignoring it` — on stderr,
  * with exit 0 and a well-formed empty result on stdout — so discarding it
- * leaves an author with a rule that verifies, runs, and reports nothing.
+ * leaves an author with a rule that validates, runs, and reports nothing.
  * Surfacing it is what makes the section-less scaffold safe: the mistake it
  * invites becomes legible instead of silent.
  */

packages/cli/src/rules/vale/run.ts

@@ -176,7 +176,7 @@ export interface ValeRuleVerification {
    * Carried on the verification rather than dropped at this seam because the
    * `W101 … isn't a core option` warning — what Vale says about an assignment
    * placed above the first `[…]` section — arrives on exactly this path: exit
-   * zero, empty findings, a rule that verifies clean while Vale ignores it.
+   * zero, empty findings, a rule that validates clean while Vale ignores it.
    * Empty when Vale was never run (a one-sided fixture set short-circuits) and
    * when it ran with nothing to say; the two are not worth distinguishing, and
    * empty-never-absent lets a caller concatenate without a fallback.

packages/cli/src/rules/vale/verify.ts

@@ -52,7 +52,7 @@ const layerResultSchema = z.object({
  * Layer 1, which alone can also report things that are true but not failures.
  *
  * An sg rule spelled `language: typescript` reaches the right parser and
- * verifies clean, but `TypeScript` is how ast-grep spells it. That is worth
+ * validates clean, but `TypeScript` is how ast-grep spells it. That is worth
  * saying on a rule that passed, so it cannot ride in `errors`.
  *
  * A list, one notice per element, because a rule can be true of more than one