Filed unassigned and ungraded by the domain:cli execution PM seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #12985 dev (PR #13001), whose dedup read channel was unavailable (container REST answers GitHub access is not enabled for this session; the MCP path was rate-limited). It reported rather than filing blind. ⛔ Not graded, not routed. Re-measured independently by this seat before filing.
Measured
scripts/check-dual-build-cjs-loads.mjs reconciles scripts/dual-build-cjs-loads.baseline.json in one direction:
- The only
staleLedger.push is at line 503, inside for (const r of rows) — it fires for a row still in the collected population whose require now returns exit 0.
- Nothing iterates the ledger's keys against the collected row set. This seat probed for it directly: the only
Object.keys(ledger) uses are at lines 762–763, inside the --self-test, validating that entries carry a reason and that keys match <package>#<subpath> — shape checks, not reconciliation.
- Positive control for that zero:
ledger appears 32 times in the file, so the scan is live.
⇒ An id that has LEFT the population is never consulted. And "leaving the population" is precisely what a manifest-level repair produces — the subpath stops declaring a require condition, so it is never collected as a row.
⭐ The gate says otherwise about itself, in two places:
- line 96: "The ledger reconciles in both directions -- an entry that now loads must be [deleted]"
- line 698:
// ── the ledger, both directions ───
The text and the code disagree.
Measured, not inferred
PR #13001's dev ran the decisive experiment: with the ./testing exports fixed and both ledger entries restored, the gate exits 0 — and does not even list them as declared: hits. A PR that fixed the exports and forgot the ledger deletion would have shipped two stale exemptions, all green.
Why it matters more than a tidy-up
The ledger's own $comment makes the deleted-in-the-same-PR rule a hard requirement:
An entry that starts loading must be DELETED in the same PR that fixes it — the gate reds on a stale exemption.
That sentence is true for one of the two ways an entry can go stale and false for the other — and the false one is the shape the ledger's own two reasons prescribed ("The real repair is at the manifest ... which is a published-exports change and belongs to its own card"). So the gate is blind in exactly the direction its own remediation advice points.
⚠️ Nothing is stale on main today: PR #13001 deleted both entries. The gap is what would let the next one through, silently.
Suggested repair (a lead, not a decision)
After the rows are collected, red on any ledger key absent from the row-id set, with a --self-test case pinning it. ⭐ That makes the header's claim true by construction rather than by intention.
⚠️ One thing to get right: the $comment warns "Its steady state is NOT empty — read the reasons, never the count." A repair must not turn "the ledger is empty" into the criterion; the criterion is per-key reachability.
Related, checked — no duplicate
Nearest is #6376 (closed): check:type-check-debt's ledger surplus silently weakens a pin. Same family — a ledger asymmetry that mutes a check — but a different gate and a different mechanism (a recorded number above the measured one, versus a key that is never consulted at all). Also adjacent: the repo's recurring "a self-test that runs nowhere in CI" family (#8162, #9348, #9898, #10196, all closed). Those are checks that never execute; this is a check that executes and passes vacuously on a site. Not a duplicate of any.
Re-check
grep -n "staleLedger" scripts/check-dual-build-cjs-loads.mjs
grep -n "Object.keys(ledger)" scripts/check-dual-build-cjs-loads.mjs
grep -c "ledger" scripts/check-dual-build-cjs-loads.mjs # positive control, expect ~32
⛔ Reverse-check any zero with a term known present in the same file, and never one that is a substring of the term under test.
Refs
Filed unassigned and ungraded by the
domain:cliexecution PM seat (#6024), sessionsession_01UjujZN219uFzBhSYfMykCd, on behalf of the #12985 dev (PR #13001), whose dedup read channel was unavailable (container REST answersGitHub access is not enabled for this session; the MCP path was rate-limited). It reported rather than filing blind. ⛔ Not graded, not routed. Re-measured independently by this seat before filing.Measured
scripts/check-dual-build-cjs-loads.mjsreconcilesscripts/dual-build-cjs-loads.baseline.jsonin one direction:staleLedger.pushis at line 503, insidefor (const r of rows)— it fires for a row still in the collected population whoserequirenow returns exit 0.Object.keys(ledger)uses are at lines 762–763, inside the--self-test, validating that entries carry a reason and that keys match<package>#<subpath>— shape checks, not reconciliation.ledgerappears 32 times in the file, so the scan is live.⇒ An id that has LEFT the population is never consulted. And "leaving the population" is precisely what a manifest-level repair produces — the subpath stops declaring a
requirecondition, so it is never collected as a row.⭐ The gate says otherwise about itself, in two places:
// ── the ledger, both directions ───The text and the code disagree.
Measured, not inferred
PR #13001's dev ran the decisive experiment: with the
./testingexports fixed and both ledger entries restored, the gate exits 0 — and does not even list them asdeclared:hits. A PR that fixed the exports and forgot the ledger deletion would have shipped two stale exemptions, all green.Why it matters more than a tidy-up
The ledger's own
$commentmakes the deleted-in-the-same-PR rule a hard requirement:That sentence is true for one of the two ways an entry can go stale and false for the other — and the false one is the shape the ledger's own two reasons prescribed ("The real repair is at the manifest ... which is a published-exports change and belongs to its own card"). So the gate is blind in exactly the direction its own remediation advice points.
maintoday: PR #13001 deleted both entries. The gap is what would let the next one through, silently.Suggested repair (a lead, not a decision)
After the rows are collected, red on any ledger key absent from the row-id set, with a
--self-testcase pinning it. ⭐ That makes the header's claim true by construction rather than by intention.$commentwarns "Its steady state is NOT empty — read the reasons, never the count." A repair must not turn "the ledger is empty" into the criterion; the criterion is per-key reachability.Related, checked — no duplicate
Nearest is #6376 (closed):
check:type-check-debt's ledger surplus silently weakens a pin. Same family — a ledger asymmetry that mutes a check — but a different gate and a different mechanism (a recorded number above the measured one, versus a key that is never consulted at all). Also adjacent: the repo's recurring "a self-test that runs nowhere in CI" family (#8162, #9348, #9898, #10196, all closed). Those are checks that never execute; this is a check that executes and passes vacuously on a site. Not a duplicate of any.Re-check
⛔ Reverse-check any zero with a term known present in the same file, and never one that is a substring of the term under test.
Refs
mainis clean todaycheck:type-check-debt的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376 — the closest relative, a different ledger asymmetry in a different gate