fix(vale): drop the 128 KB file-size guard

[theCodeDrift]

What

Removes the 128 KB oversized-file guard from the Vale engine: VALE_MAX_FILE_BYTES and the maxFileBytes per-run override in packages/cli/src/rules/vale/run.ts, the findOversizedFiles scan and oversizedFilesNotice in packages/cli/src/rules/vale/formats.ts, the sectionGlobs / valeSections threading that existed only to scope that scan, and their tests. AssembledValeConfig.sections stays (it is a fact the generator states; its docblock now says its consumer is gone).

The update ledger gains a Migrating to 0.11.3 line (topic v6 → v7), and create-vale-rule drops the paragraph that told authors large files are skipped (topic v8 → v9). A changeset (patch, pre-1.0) carries the release note with the numbers below.

Why

The guard was added in 0.11.2 (#323) against Vale 3.20.0, where lint time was superlinear in the size of a single Markdown block (#325). The same release moved the vendored Vale to 3.21.0, whose perf commits (ed711769, 252d0963) made that cost linear at roughly 2.8 µs per sentence regardless of block structure. At that rate a file would need to reach several hundred megabytes before it threatened the 60 s run budget, so the cap no longer separates a cheap file from an expensive one and only costs users findings in files it skips. No replacement bound is kept; VALE_TIMEOUT_MS remains the ceiling on damage.

Measured

Re-ran https://github.com/thecodedrift/reproduction_vale_blocks (npm run fixture:create && npm run bug:reproduce, three passes) with its @taskless/vale-darwin-arm64 resolved to the exact binary this worktree vendors (3.21.0-20260915061224, vale --version → 3.21.0), plus two extra single-block sizes with the same sentence and rule. darwin/arm64, warm, median of three. The 3.20.0 column is the reproduction's own recorded run and the removed docblock's measurement.

fixture	Vale 3.20.0	Vale 3.21.0
3,187,511 B, one block (huge.md)	81,090 ms	231 ms
3,230,010 B, blank-line sep. (wrapped)	4,415 ms	287 ms
131,255 B, one block (the old cap)	~770 ms	~26 ms
25,500,005 B, one block	—	~2,200 ms

Raw passes: huge.md 247 / 228 / 231 ms; wrapped.md 287 / 287 / 314 ms; 128 KB 77 / 21 / 26 ms (first pass paid the page-in); 25 MB 3,099 / 2,071 / 2,216 ms. Alert counts were 42,500 on both large fixtures, matching the reproduction's invariant.

What stays

• The per-file retry for a target whose front matter Vale cannot parse (One unparseable file zeroes findings for the whole check run #300) is unchanged; it is independent of file size. escapeGlobLiteral's docblock now cites that retry as the reason it escapes rather than drops a literal path.
• The timeout test's headroom reasoning in vale-run.test.ts is kept; its fixture no longer needs the maxFileBytes seam to reach the binary.
• The [section]-vs---glob depth-matching contract test in vale-vendor-contract.test.ts is kept as a pinned Vale fact; its docblock no longer names the guard as the consumer.
• Vale still emits nothing until the run finishes, so a run killed by an external time limit still loses every finding. That half of Track upstream: Vale lint time is superlinear in single-block size, and no output is emitted until the run finishes #325 is not fixed upstream; with linear cost it is just far harder to reach.

Spec

No OpenSpec change: nothing under openspec/specs/ mentions 128, VALE_MAX_FILE_BYTES, or an oversized-file exclusion.

Checks

pnpm build, pnpm typecheck, pnpm lint (No issues found.), pnpm --filter @taskless/cli test (94 files, 1518 tests) all pass.

Fixes #351
Refs #350
Refs #325
Refs #323

[theCodeDrift]

@claude /review

[claude]

Claude finished @thecodedrift's task in 2m 57s —— View job

---

Review complete

Review mode: incremental — read 0 prior review thread(s) before reviewing. .prior-review.json contains no threads, reviews, or top-level comments beyond the @claude /review trigger itself, so this is the first review pass on this PR — nothing to classify as already-addressed or still-open.

• Read .prior-review.json
• Fetch PR diff and metadata (gh pr diff, gh pr view)
• Read changed files in full where needed
• Run correctness / cleanup / altitude / conventions review angles
• Verify candidate findings
• Post final review

Assessment

This is a clean, tightly-scoped deletion PR that removes the 128 KB Vale file-size guard (VALE_MAX_FILE_BYTES, findOversizedFiles, oversizedFilesNotice, the sectionGlobs/valeSections threading) and updates the two agent-topic docs and tests accordingly. I traced every removed symbol end-to-end and found no correctness bugs:

• No dangling references. Grepped the whole tree for VALE_MAX_FILE_BYTES, maxFileBytes, findOversizedFiles, oversizedFilesNotice, OversizedFile — the only remaining hits are historical comments (CHANGELOG.md, a code comment in vale-run.test.ts explaining why the seam is gone) and the changeset itself.
• escapeGlobLiteral's docblock rewrite is accurate. Its only production call site is now the per-file retry's excludedTargets exclusion in run.ts:622 — the removed call was oversizedInScope.map(...), and the updated doc in formats.ts and git-ignored.ts correctly points at the retry as the new (and only remaining) reason it escapes rather than drops a literal path.
• stat/basename/extname imports in formats.ts/run.ts are still used elsewhere (targetFileParseError, converterFor, the UNWALKED_DIRECTORIES exclude predicate) — no orphaned imports.
• AssembledValeConfig.sections is now unconsumed in production code (only referenced in assemble.test.ts) — but this is explicitly called out and justified in both the PR description and the updated docblock in assemble.ts ("the field stays: this module is the generator..."), so it's a deliberate, documented choice rather than an oversight.
• Call sites all line up: dispatch.ts's runValeEngine, check.ts's dispatch call, and verify.ts's runVale call were all checked against the new/removed option shapes (DispatchOptions, ValeRunOptions) — none reference the removed sectionGlobs/maxFileBytes fields.
• Test removal is proportionate: every test deleted was specific to the removed guard (vale-formats.test.ts's findOversizedFiles suite, vale-run.test.ts's "oversized target file" describe block); the surviving tests (timeout headroom, [section]-vs---glob depth pinning, the per-file retry) had their comments updated to stop citing the removed guard as their motivation, and their assertions are unchanged.
• Spec claim verified: grepped openspec/specs/ for 128, VALE_MAX_FILE_BYTES, "oversiz" — nothing, confirming the PR's "No OpenSpec change" claim.

One point worth a second look but not raised as a hard finding (I don't have an exact CLAUDE.md rule to quote against it, since the bump-choice guidance in the repo's CLAUDE.md is written in terms of added surface, not a removed safety guard): the changeset is patch, which is consistent with this repo's 0.y.z convention, but functionally this removes a limiter that previously kept some large generated files (e.g. a checked-in changelog) out of lint results entirely. A project whose check currently passes only because such a file was silently excluded could start seeing new findings (and a newly-failing check) after upgrading. The changeset body does describe this effect in detail, so this is a "worth confirming with the author's intent" observation rather than a defect.

No inline comments posted — nothing met the bar for a concrete, confirmable bug.

[theCodeDrift]

I want to build on Claude's comment. I think what needs to happen is #356 will need upgrade guidance. We already know how to write this. It's designed to help the agent migrate to a new version which means checking if there are large files that are now being checked which should be excluded.

[theCodeDrift]

Re: @claude[bot] — "Claude finished @thecodedrift's task in 2m 57s — Review complete … no correctness bugs, no inline comments posted"
#356 (comment)

Read, nothing to change. On the one observation: the patch bump follows CLAUDE.md's pre-1.0 rule (anything above patch is reserved for a change a consumer must react to), and the changeset body already tells a user what they will see (a previously skipped file now produces findings) and what to do (narrow the matcher's section). Left as patch; flagged to the author as a question rather than changed here.

— AI Coding Agent