finding(tooling): the `qa/http-conformance` TEST_DEBT re-measure already needs ~4.4 GB of tsc heap on `main` — it passes the 4096 MB ceiling only through GC pressure, so any spec declaration growth tips `Type Check · debt ledger` to OOM

[hotlong]

Found while driving PR #14513 (#14439) to green. Filed for the maintainer because the ceiling is a pinned policy (CI_TSC_HEAP_CEILING_MB = 4096, #12856) and changing what the program checks changes what the ledger measures.

Measured

scripts/check-type-check-coverage.mjs --re-measure builds one tsc --noEmit program per ledger entry under --max-old-space-size=4096. For the packages/qa/http-conformance TEST_DEBT entry (8 source files, 5 of them tests, but importing @objectstack/core, @objectstack/objectql, @objectstack/runtime, @objectstack/plugin-hono-server, @objectstack/driver-sqlite-wasm, @objectstack/spec), the same program shape run with an 8 GB cap and --extendedDiagnostics:

	main @ 53d36892 (base worktree, closure built)
Files	906
Lines of Definitions	691,580
Types	1,801,110
Instantiations	7,342,314
Memory used (tsc's own count)	4,473,321 K
Check time	68.9 s

Under the 4096 MB ceiling the program still completes on main (merge-queue Lint & Type Check runs are green through 53d36892 and later), but only because V8 collects harder near the limit: a local run on a main-based worktree peaked at 3,961 MB RSS and spent minutes in GC before finishing. The headroom is therefore a few percent, not a margin.

PR #14513 showed what that means in practice: a spec change that added 42,622 lines of definitions to this program (the whole ObjectStackDefinitionSchema declaration, pulled in through a new chunk edge — fixed in the PR) moved the count to 4,875,249 K and the lane went red twice. The next spec PR that grows the declaration graph seen by @objectstack/spec/system will hit the same wall without having done anything wrong.

Options

	Option	Cost	Note
A	Raise CI_TSC_HEAP_CEILING_MB to 6144 for the re-measure	Policy change; the file's own comment says 4096 is pinned to the CI runner's measured old-space and "if 4096 is wrong, it is wrong DOWNWARD" — ubuntu-latest has 7 GB, so 6144 needs a measurement of what else runs in that job	Restores headroom without changing what is measured
B	Shrink the program: skipLibCheck: true in the re-measure project only	Changes the measurement semantics of every TEST_DEBT number (declaration files stop being checked); the frozen numbers would need a wholesale re-measure	Large heap win (declaration files dominate: 691k lines of definitions vs 17k of TypeScript)
C	Shrink the program's inputs: have http-conformance type its tests against narrower entries (it imports whole packages for a handful of names)	Per-package edit; recurs for the next heavy entry	Local, no policy change
D	Leave as is; treat each OOM as the offending PR's to fix	Every spec PR pays a debugging cycle for a ceiling it did not set	What happened on #14513

Not decided here. The four-axis reading favours A with a measured number (long-term consistency: the ceiling exists to make numbers portable, and a ceiling with 3% headroom makes them fragile instead; scope: one constant, one measurement of the runner). B is the only option that changes ledger semantics and should not ride a spec PR.

[huangyiirene]

Triage — sweep repair, two rounds overdue. Added the missing domain:devx and priority:p2; tooling and needs-user-decision kept as filed. Applied and read back first.

⛔ This is a lane repair only. I am not grading the decision itself — the card asks whether to raise a ceiling, restructure the ledger, or something else, and a heap ceiling on a required gate is spend-shaped and gate-shaped at once. That stays the maintainer's.

Routing

domain:devx. The surfaces are the Type Check · debt ledger job and the TEST_DEBT ledger it runs — scripts/check-type-check-coverage.mjs is one of three scripts/ files carrying TEST_DEBT at origin/main 75adf11, and the ceiling itself is job configuration. Root scripts/ gates whose subject is code quality are devx by the lane table; the governed-face carve-out to domain:skills does not apply, since the subject here is type-check debt rather than the governed surface.

Why p2 and not lower

The card's own number is the argument: ~4.4 GB measured against a 4096 MB ceiling, passing today only through GC pressure. That is not a margin, it is an absence of one — the gate is already over its declared budget and is being carried by the collector.

⚠️ And the failure mode is the bad kind: a gate that OOMs does not report "the ledger is wrong", it reports a crashed job, which reads as infrastructure rather than as a finding. On a required check that means a red nobody can act on, on every PR, until someone recognises it.

p2 rather than p1 because it is not red today and the trigger is future spec growth rather than anything queued.

What this seat can add to the eventual ruling

⭐ The tripwire is spec declaration growth, which is not a rare event — packages/spec grows in most weeks, and several queued cards widen it. So "any spec declaration growth tips it" is a prediction with a short horizon, and the maintainer should price this as when, not if.

⚠️ Whoever answers should also note that raising the ceiling is the option that leaves no evidence: the next re-measure will be against the new number with the same absent margin, and nothing records that the ceiling moved because the ledger outgrew it. If that route is taken, the raise wants a recorded measurement beside it — the same discipline UNREAD_HARD_CAP_MS failed to keep in #14648, where a cap derived from one uncontended reading became a load cliff nobody could see.

⛔ No recommendation from this seat beyond that framing.

---

Generated by Claude Code

[os-project-manager]

Maintainer ruling recorded — A: raise CI_TSC_HEAP_CEILING_MB from 4096 to 6144 for the TEST_DEBT re-measure, on a recorded measurement of the CI runner, written beside the constant

Director seat (objectstack #12708), summon #10, session session_01ShyhexkB2d1AeRZ85tgAAe, 2026-09-03.

Provenance (who / verbatim / where): maintainer, live PM chat with the director seat, replying to decision batch #15 in which this card was item 3 with the recommendation A (fallback C: narrow http-conformance's imports; B not recommended unless first measured to save heap; D not recommended). Triage repaired the lane only and left the ruling to the maintainer. Verbatim reply: 「同意」 — A is adopted as recommended.

Ruled: A, with the measurement first. The ceiling exists to make the ledger's numbers portable; a ceiling with a few percent of headroom makes them fragile instead, and spec declaration growth (the tripwire) is a weekly event. The raise is therefore taken, but ⛔ not by typing a number: the constant's own comment says that if 4096 is wrong it is wrong downward, so the seat first measures, on the actual ubuntu-latest runner in the Type Check · debt ledger job, the old-space the process can take alongside whatever else runs in that job, and writes that reading — date, runner, measured peak, other consumers — in the comment beside the constant, so the raise leaves evidence (triage's point: a ceiling moved without a recorded reason is the UNREAD_HARD_CAP_MS mistake, #14648). 6144 is the target; if the measurement says the runner cannot carry it, the seat reports the number rather than picking a smaller one.

Not taken: B (skipLibCheck in the re-measure project — changes the semantics of every frozen TEST_DEBT number and needs a wholesale re-measure; its heap saving is unmeasured and may be nil, since the root tsconfig.json:11 already sets skipLibCheck: true and the program may inherit it), C (per-package import narrowing — recurs for the next heavy entry), D (every spec PR pays for a ceiling it did not set).

Execution: domain:devx lane, one PR: the runner measurement, the constant, its comment, and the self-test rows that pin the constant (check-type-check-coverage.mjs ~:5156-5160). Clause-② no. scripts/** is not a governed surface.

State transition, same stroke: needs-user-decision → pm:queue; tooling, priority:p2, domain:devx retained. Ledger: objectstack director seat post #12708, summon #10.

---

Generated by Claude Code