Filed by the skills seat (session session_019T1sSZbQTnLhrK9HhNdNiB, 2026-08-20 ~19:4xZ) as cross-seat stop-the-bleed: a lint-family gate red against MAIN blocks every PR's Lint & Repo Gates, whatever the diff. pm:queue + provenance + an executable criterion per the transfer rule; domain:* left to triage (scripts/ gate tooling — devx by the lane table).
The failure (first seen 19:38Z, PR-side CI)
check:query-options-erasure inside Lint & Repo Gates, job 96556235643:
✗ check-query-options-erasure-ratchet: 1 parse failure(s) inside the population this gate measures:
• packages/spec/src/migrations/registry.ts:0:0 — Parsing error: Maximum call stack size exceeded
The failing PR's diff touches one scripts/pm/ file and cannot influence registry.ts parsing — the gate measures MAIN's population, so this reds independently of any diff.
Mechanism (verified by reading, local repro blocked by an incomplete shared-checkout install)
- The morning's stack-overflow fix landed on
pnpm lint's CLI invocation (package.json:31: node --stack-size=4000 node_modules/eslint/bin/eslint.js …). scripts/check-query-options-erasure-ratchet.mjs does NOT go through that entry: it imports the ESLint API in-process (import { ESLint } from 'eslint', line 93) and therefore runs on the default V8 stack.registry.ts is append-hot (6861 lines; three merges touched it today, most recently the v16-retarget commit f3996182b), and it has just crossed the in-process default-stack parse limit — the same file, the same signature, one un-fixed invocation path over a growing input. The gate itself is behaving correctly ("a file that does not parse was never read — nothing was counted"): the defect is the invocation.
Executable criterion
node scripts/check-query-options-erasure-ratchet.mjs exits 0 on a fresh origin/main checkout (currently exits 2 with the parse failure above). Fix shape, for the taking seat to judge: give the ratchet's ESLint pass the same stack headroom the CLI fix got — re-exec self with --stack-size (the repo's proxy script has a precedent for the re-exec pattern), or spawn the CLI entry with the flag; a self-test case pinning "the gate parses the repo's deepest known-legit file" would stop the third recurrence. Note the fatal-parse guard (scripts/eslint-fatal-guard.mjs, referenced at line 79) may want the same treatment — same class, verify before widening.
Blast radius
Every open PR's Lint & Repo Gates reds on next run until this lands (measured on one PR; the population argument covers the rest). PRs already known parked on it: #10445 (Blocked-by: back-link on its card).
Filed by the skills seat (session
session_019T1sSZbQTnLhrK9HhNdNiB, 2026-08-20 ~19:4xZ) as cross-seat stop-the-bleed: a lint-family gate red against MAIN blocks every PR'sLint & Repo Gates, whatever the diff.pm:queue+ provenance + an executable criterion per the transfer rule;domain:*left to triage (scripts/ gate tooling — devx by the lane table).The failure (first seen 19:38Z, PR-side CI)
check:query-options-erasureinsideLint & Repo Gates, job 96556235643:The failing PR's diff touches one
scripts/pm/file and cannot influenceregistry.tsparsing — the gate measures MAIN's population, so this reds independently of any diff.Mechanism (verified by reading, local repro blocked by an incomplete shared-checkout install)
pnpm lint's CLI invocation (package.json:31:node --stack-size=4000 node_modules/eslint/bin/eslint.js …).scripts/check-query-options-erasure-ratchet.mjsdoes NOT go through that entry: it imports the ESLint API in-process (import { ESLint } from 'eslint', line 93) and therefore runs on the default V8 stack.registry.tsis append-hot (6861 lines; three merges touched it today, most recently the v16-retarget commitf3996182b), and it has just crossed the in-process default-stack parse limit — the same file, the same signature, one un-fixed invocation path over a growing input. The gate itself is behaving correctly ("a file that does not parse was never read — nothing was counted"): the defect is the invocation.Executable criterion
node scripts/check-query-options-erasure-ratchet.mjsexits 0 on a freshorigin/maincheckout (currently exits 2 with the parse failure above). Fix shape, for the taking seat to judge: give the ratchet's ESLint pass the same stack headroom the CLI fix got — re-exec self with--stack-size(the repo's proxy script has a precedent for the re-exec pattern), or spawn the CLI entry with the flag; a self-test case pinning "the gate parses the repo's deepest known-legit file" would stop the third recurrence. Note the fatal-parse guard (scripts/eslint-fatal-guard.mjs, referenced at line 79) may want the same treatment — same class, verify before widening.Blast radius
Every open PR's
Lint & Repo Gatesreds on next run until this lands (measured on one PR; the population argument covers the rest). PRs already known parked on it: #10445 (Blocked-by:back-link on its card).