test(compat): the fail-on-red gate's node -e invocation must be top-level (#704)

[AhmedElBanna80]

Closes #704. Also closes #702 — see below; that one needed no code.

The defect

#701 made the gate's three teeth independently provable inside the step's script, and gave the JS half a "must be top-level" assertion. The shell half had no sibling. Wrapping only the node -e invocation — leaving the prelude untouched — disarms all three teeth:

if [ "${KNEXT_RUNTIME:-node}" != "bun" ]; then
  node -e '…' "${SUMMARY}"
fi

	audit	real step
baseline	teeth 0/0/0, branches 3, reaches 0, escape 0	exit=1, error lines present
wrapped	byte-identical	exit=0, 0 ::error::red shard lines

Measured with bash -e, KNEXT_RUNTIME=bun, a red 8-failure Bun-lane summary. A night with real test failures concludes SUCCESS and counts toward the 14-night window in docs/compat/window-node-lane.md.

It slips every existing guard by construction. Wrapping the whole prelude is already caught — shellIfBlocks skips nested blocks via i = j, so the missing-summary branch stops being found. The narrower edit survives that. And it introduces no exit, so the escape-hatch scan has nothing to find.

The fix

shellNestingDepthAt nets block openers against closers per line, so anything opening and closing on one line contributes zero — which keeps "${SUMMARY}" and [ ! -f … ] from registering as nesting. The embedded program is blanked by offset first, or its JS braces would count as shell blocks.

Five shapes now red: conditional, brace group, subshell, case arm, function body. Baseline 0.

The near-miss, recorded because it is the point

The first cut caught four of five and missed the case arm. case … in opened the block, and the very next pattern line — node) — closed it again, netting zero at the invocation. The other four were caught.

The shape that would have shipped broken is the one nobody probes. That is the same failure eleven rounds of review on #701 kept surfacing, and it was caught here only by running all five shapes rather than the one that motivated the fix. Hence CASE_PATTERN, and hence the five-way probe.

#702 needs no code — its subject no longer exists

#702 reported that blankSingleQuoted's even-quote parity check is necessary but not sufficient, so a || true bracketed by two stray apostrophes is blanked and survives.

blankSingleQuoted was deleted by #701 round 9. No quote-pairing logic remains in tests/helpers/fail-on-red-gate.ts — blanking is offset-based (embeddedNodeProgramSpan) and exit is matched only in command position; neither depends on pairing.

Verified empirically rather than by reading, using #702's own reproduction:

BASELINE                            reaches 0
CONTROL  || true alone              reaches 1
STRAY    two apostrophes + || true  reaches 1   ← was the escape; now reds

Evidence

• Mutation-proved: the wrap reds expect(escapeHatches).toEqual([]); restore byte-exact; scan-mutation-residue.mjs clean; baseline green.
• Rides the existing assertion rather than adding a competing one, so no new red can stand in for another.
• tests/compat-suite-workflow.test.ts + tests/compat-shard-flake-attribution.test.ts: 153 passed.

What I did not verify

• No prover row added. The No CI job runs any mutation prover — five have been found non-functional in one session #685 nightly does not cover this check; the mutation proof above was run by hand. Worth a follow-up, but I did not want to contend scripts/mutation-prove-compat-fail-on-red-teeth.mjs while test(compat): guard the fail-on-red gate from OUTSIDE the script (#703) #705 was in flight.
• Deliberately did not touch tests/compat-suite-workflow.test.ts — test(compat): guard the fail-on-red gate from OUTSIDE the script (#703) #705 owns it this round.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
knext-docs	Ready	Preview	Aug 6, 2026 4:28pm