Zachary Lowden
eaa277b0d4
The flag was already tried and reverted: #3458 enabled it 2026-07-30, #3807 turned it off 08-11 after the release build OOMKilled three times at 37-39 GiB against the enforced 40Gi builder cgroup. The 2026-08-18 doc was written after that revert and still recommended it as the only lever, with the RSS cost listed as unverified. Re-measured on 16.3.1: +43% peak next-build RSS, worse than the +33% on record. Live distribution n=67 builds, worst observed 28.59 GiB; times that multiplier lands at 37.3-39.8 GiB, the band the OOM kills were recorded in. No headroom. The turbopackSourceMaps escape hatch is closed too - it cannot be split client/server and server .js.map has a hard consumer gate. The flag VALUE is unchanged (still false). This is docs plus one comment, so the lever is closed off in the place someone would next reach for it.
claudedocs/
In-depth technical documents: RCAs, audits, analyses, handovers, and investigations.
These are not auto-loaded by agents — they cost nothing until someone opens them.
They live here (not in docs/) because they contain operational detail, investigation
methodology, and measured evidence that would be noise in user-facing feature docs.
Status-line convention
Every document that asserts an outcome (a fix landed, a proposal was merged, a measurement holds, a recommendation stands) must carry a status line that names the commit SHA or PR number the claim was true at. This makes the status a claim about a point in history, not about the present, so it can be re-verified rather than re-trusted.
Format
The status line goes immediately after the document's # heading, as a bold
**Status:** paragraph. The first word after the colon is the status category,
followed by the evidence:
# Document Title
**Status:** merged. PR #NNNN (merged YYYY-MM-DD). <one-sentence summary>.
Categories
- merged — the change landed. Name the PR and merge date.
- open — the issue/PR is still open. Name the PR.
- diagnosed, not fixed — root cause known, no fix shipped. Say what would fix it.
- historical snapshot — the doc captures a point-in-time measurement or analysis. Say what it was measured at (commit SHA, branch, date).
- recommendation unchanged — the doc's recommendation still holds. Say when it was last checked.
Corrections
When a status has changed since the doc was written, state the correction in place
rather than silently editing out the old claim. Use the pattern from
typecheck-tests-gap-2026-08-12.md or turbopack-chunk-hash-collision-2026-08-18.md,
which carry a real (corrected …) status line:
**Status (corrected YYYY-MM-DD):** <new status>. <evidence>.
The original text is not removed — the correction block sits above or replaces the old status line, and the body of the document is left untouched.
What NOT to put in a status line
- Internal infrastructure names, hostnames, or deployment details (this repo is public).
- Operational specifics that belong in the private infra repo.
- Claims that require running the codebase to verify (e.g., "coverage is still 32%").
Verification
Re-derive a doc's status against the repository (gh pr view, git log), never
from the doc's own text. An audit that reads each doc's self-reported status instead
of re-checking the repo will get the same wrong answers the doc already has.