chore(vale): take Vale 3.19.0, re-measured

[theCodeDrift]

Everything that follows from #223 pinning the Vale manifest at 3.19.0. Now rebased onto main (the manifest commit dropped by patch-id, since #223 landed) and pinned to the published platform packages.

#223's digest was genuine. I downloaded vale_3.19.0_macOS_arm64.tar.gz from upstream and it hashed to exactly the a0e5f309… the manifest pins, then re-derived every claim we make about the binary against it.

What held

Every row of VALE_FORMAT_TIERS re-probed unchanged. src/generated/vale-vocabulary.ts regenerates byte-identical apart from its version string. The corpus differential, panic shapes included, still passes. A much quieter bump than 3.17.1 → 3.18.0, where eight rows moved in three directions.

What changed, which the table cannot report by construction

.ex/.exs gained comment and @doc extraction. Measured both ways: a bare simply = 1 line fires on 3.18.0 and is silent on 3.19.0, while a # comment fires on both. They leave the unnamed plaintext fallback for the comment tier, as two new rows.

Read the direction carefully. This is a narrowing: a rule matching [*.ex] was linting identifiers, atoms and string literals, and now sees comments only. Findings disappear, nothing errors, and nothing but a re-probe would have told us. agent update gains a ledger entry so a reader who notices a suspiciously clean run has somewhere to land.

MDX JSX children are now read as Markdown. .mdx stays markup, so the tier is blind to the change, but a Vale rule now covers prose inside <Steps> or <Aside> that it previously skipped, and those children carry the element name as a text.class.<name> scope. That family is already an open prefix in our schema, so scope: text.class.Aside validates today with no change.

sequence needs nothing. The new repeat feature lives inside a token entry, not at the check's top level, and our sequence arm only constrains that tokens exists and is a list. Probed and accepted.

Two latent bugs found on the way

Both recipes wrote ".mdx is supported as of Vale v%(VALE_VERSION)s" with the version interpolated. Native MDX arrived in 3.18.0, so raising the pin would have silently turned a true sentence into a false one in published agent guidance. Both now name the release that did it.

The full suite also passed once against a stale dist/, hiding reconcile-marker.test.ts, which asserts the engine version recorded into the rules marker. A rebuild reproduced it. Exactly the trap CLAUDE.md documents.

Now verified against the published binary

The branch was a draft because the vendor contract refuses to certify claims against a binary other than the pinned one, and the earlier measurements used an upstream download while the installed package was still 3.18.0. That refusal is the guard working.

release-vale.yml has since published 3.19.0-20260901000817; all six platform packages confirmed on npm, and the vendored binary now reports vale version 3.19.0. The pinned-version assertion and the two new .ex/.exs probes pass on the artifact a user will actually install.

1086/1086 tests, typecheck, lint, and pnpm cli check clean. The 4 no-hedging warnings in route.txt are pre-existing on main.

Refs #223

[theCodeDrift]

@claude /review

[claude]

Claude finished @theCodeDrift's task in 4m 30s —— View job

---

Review complete

Review mode: incremental — read 0 prior review thread(s) before reviewing. .prior-review.json contained no review threads, reviews, or resolved/open comments (only the @claude /review trigger itself), so this is the first review of this PR.

Todo list

• Read .prior-review.json (empty of prior review data — first review)
• Fetch PR diff and metadata with gh pr diff / gh pr view
• Run correctness angles (line-by-line, removed-behavior, cross-file)
• Run cleanup angles (reuse, simplification, efficiency, altitude, conventions)
• Verify candidate findings
• Post inline comments for confirmed/plausible issues
• Post final top-level summary

Assessment

This PR is almost entirely a re-measurement/re-pin: VALE_VERSION and the six @taskless/vale-* platform packages move from 3.18.0 to 3.19.0, VALE_FORMAT_TIERS gains two new comment-tier rows (.ex, .exs), the generated vocabulary and test fixtures follow, and several agent recipe files get corrected/expanded prose. I traced the cross-file consistency carefully (capabilities.ts → formats.ts, schemas/vale-rule.ts, vale-vendor-contract.test.ts, reconcile-marker.test.ts, the three agent/*.txt recipes) and the substantive claims check out:

• .ex/.exs as comment tier is exercised automatically by the existing it.each([...VALE_COMMENT_EXTENSIONS]) suite once added to the table; the only manual addition needed was # in the comment() helper's HASH set, which the diff does correctly.
• The text.class.<name> scope claim for MDX component children matches the already-open SCOPE_PREFIXES grammar in schemas/vale-rule.ts (isScopeOperand accepts any tail) — no schema change was needed, and none was made.
• The two recipe edits that hardcode v3.18.0 instead of interpolating %(VALE_VERSION)s are deliberate and correct — they're describing when MDX support historically arrived (3.18.0), not the currently pinned version, so interpolating the current version there would have been the "latent bug" the PR description calls out.
• update.txt's "Five things follow" count matches the five top-level bullets (Elixir, rewriter fix, Markdown-as-language, sg run --lang aliases, matching-semantics).

[New] One inline finding: packages/cli/src/rules/capabilities.ts:199 — the illustrative build-stamp in the VALE_VERSION docblock (3.18.0-20260824195610) is one version behind both the constant on the next line ("3.19.0") and this PR's own package pin (3.19.0-20260901000817). The diff touches this exact line and had the opportunity to fix it; it looks like a recurring one-version-behind pattern rather than something newly introduced. Doc-only, no behavioral impact.

Nothing else surfaced across correctness, removed-behavior, cross-file, reuse, simplification, efficiency, altitude, or CLAUDE.md-conventions passes — the diff is small, each changed fact is cross-referenced against a measured source (the vendor contract tests), and no test coverage or invariant was narrowed without a corresponding ledger/changeset entry.

[theCodeDrift]

Re: @claude[bot] — "Claude finished @theCodeDrift's task in 4m 30s … Review complete"
#226 (comment)

The one inline finding is fixed in c6f5927, and the part worth acting on was the observation attached to it rather than the instance.

Bumping the stamp to 3.19.0-20260901000817 would have moved the problem forward one release. Noting that the prior state had the same off-by-one is what turns it into a class: a literal that must be hand-carried on every bump is worse than no example, because it reads as the current pin and is not one. The docblock now names the shape and where it is minted; packages/cli/package.json holds the real values. I swept packages/cli/src for other hand-carried stamps and the only other hit is reconcile-marker.ts:34, which illustrates the nightly format for a string-comparison explanation and never claims to be a pin, so it stays.

Also useful to have the three deliberate-looking things confirmed independently rather than taken from the description: that the hardcoded v3.18.0 in the recipes is describing when MDX support arrived rather than the current pin, that .ex/.exs get exercised automatically by the existing it.each([...VALE_COMMENT_EXTENSIONS]) once in the table, and that text.class.<name> already validates against the open SCOPE_PREFIXES grammar with no schema change.

Still green after the fix: 1086/1086 tests, typecheck, lint, and pnpm cli check clean.

— AI Coding Agent