Oxlint writes configuration failures to stdout, and the slice from the first
brace to the last one takes a wrapper's own warning for the report, so the gate
died with "did not return Oxlint JSON output" and discarded the only
explanation of why.
The batch budget counted only the file list, but execve() charges argv, the
inherited environment and one pointer per entry against a single ceiling. A
256 KiB batch beside a large environment failed the spawn outright, so the
gate reported nothing instead of linting.
Compute the budget from everything the spawn carries: the Node binary, the
Oxlint entry point, the fixed flags and — on POSIX only, since Windows ships
it in a separate block — the environment. Budget against half of macOS'
kern.argmax rather than all of it: a Node child SIGSEGVs (24) or throws a
stack-overflow RangeError (26) near 970 KiB, well before E2BIG at 1,048 KiB.
Resolve the Oxlint launcher from its own manifest instead of assuming a flat
node_modules layout, and name the scan and batch when a spawn fails so it
reads as a launch failure rather than a crash in the gate.
Oxlint takes paths as positional arguments only, so `check:code-quality:changed`
spawned one process carrying every changed file. A lane's `.orca-task-*` scratch
tree holding seven nested repo checkouts put 39,079 untracked source files in
scope — 3.5 MB of argv against a 1 MiB ARG_MAX — and the gate died with E2BIG
before Oxlint ran.
Two fixes: ignore the per-task scratch trees so a foreign checkout is no longer
counted as your changed code, and batch the argument list under 256 KiB per
invocation, concatenating the diagnostics so every batch reaches the exit status.
A diagnostic's span often reaches past the block a split moved — most commonly
to a hook dependency array, which legitimately grows when closure variables
become props. Requiring every line of the span to match contiguously reported
the moved body as new.
The block must still start at the same line in the base and appear in order,
and >=90% of it must be present. Genuinely new code shares neither the anchor
nor the ordering.
A file-splitting refactor makes every line of the new module an added line, so
pre-existing lint debt in code that merely moved starts failing the gate. The
only way to satisfy it is to edit the moved code, which is what a
behavior-preserving refactor must not do. Exempt a diagnostic when its
highlighted lines already existed verbatim and contiguous in the base revision.
Brennan Benson
Neil