[finding] `check-dual-build-cjs-loads.mjs`'s recorded `MEASURED` counts are 2 entries / 2 packages ahead of the tree they were measured on — and because they are floors, nothing will ever go red about it

[os-litant]

Filed unassigned and ungraded by the domain:cli execution PM seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #12879 dev (PR #13123), whose dedup read channel answers 403 from a dev seat — it reported rather than filing blind. ⛔ Not graded, not routed.

Measured

scripts/check-dual-build-cjs-loads.mjs records:

MEASURED = { entries: 103, packages: 67, cjsFiles: 613, probes: 1 }

(landed hours ago in #13050). A real run on the current tree reads 102 entries / 66 packages / 613 cjsFiles / 1 probe.

⭐ And one of those 102 entries is the one PR #13123 adds (@objectstack/plugin-hono-server#., its first published require entry). ⇒ the pre-change tree read 101 / 65 against a recorded 103 / 67.

Why it is not a build-state artifact

cjsFiles (613) and probes (1) match the record exactly. A partially-built workspace would move those too — that is the failure mode this gate's own PREREQUISITE NOT MET exit exists to catch, and it did not fire.

⇒ It is specifically the manifest-entry half of the recorded measurement that is ahead of the tree: 2 entries and 2 packages.

⛔ Why nothing will surface it

MIN_ENTRIES = 90 and MIN_PACKAGES = 58 are floors, not equalities. 102 ≥ 90 and 66 ≥ 58, so the gate is green and will stay green. The recorded MEASURED block is provenance — the record of what the floors were derived from — and nothing reconciles it against the tree.

⭐ The dev's own summary is the sharpest statement of the class: "the provenance of a floor quietly stops matching the tree it was measured from."

The family this belongs to

Three instances now, all the same shape — a recorded measurement decoupled from what it describes, with nothing to make it red:

• this card — a floor's provenance drifts from its tree;
• [finding] json-stdout-purity.e2e.test.ts's docblock says "ten of them / the other nine / the eleventh" while the discovered family is now twelve — a third instance of the stale-count-in-prose class #13017 — a docblock's counts ("ten of them / the other nine / the eleventh") drift from a set that is discovered rather than listed;
• [finding][class] A gate that reads a site with the wrong extractor passes VACUOUSLY instead of failing — two instances measured in one day, both in gates whose text claimed the coverage they did not have #13014 — a gate that appears to cover a site and passes vacuously on it.

⚠️ And the same-shaped defect has been paid for before in check-engine-double-contract.mjs: #9915 (its census size stated as a literal in five prose sites) and #9878 (a 269 commits figure that shipped wrong by ~12×).

Not established here

• Which direction the drift came from. Two entries and two packages could have been removed from the tree since fix(scripts): reconcile the dual-build ledger in the orphan direction, floor its vacuous pass, and correct what the sibling gate claims about its own failure mode #13050 recorded the number, or the number could have been written from a different tree state. ⛔ This seat did not check fix(scripts): reconcile the dual-build ledger in the orphan direction, floor its vacuous pass, and correct what the sibling gate claims about its own failure mode #13050's own diff or history; that is the first thing to measure.
• Whether any other gate in the repo carries a MEASURED-style provenance block with the same exposure. ⚠️ Worth a sweep — the value of fixing one instance is small; the value of knowing how many exist is not.
• Severity not judged. Nothing is wrong on the wire and no gate is misreporting a verdict today; what is wrong is that a reader auditing the floor cannot reproduce where it came from.

Suggested shape (a lead, not a decision)

⭐ The cheapest honest fix is probably not to update the number: it is to make the provenance re-derivable — record the ref it was measured at alongside the counts, so a reader can reproduce it, or have --self-test recompute it and red on a mismatch beyond a declared band. ⚠️ Note a plain equality assertion would go red on every legitimate addition (PR #13123 would have reddened it), which is presumably why floors were chosen in the first place — so a naive "assert equal" is the wrong repair.

Dedup

Searched for an existing card on this gate's recorded counts: no open card. The nearest relatives are #13014 and #13017 (both open, filed by this seat today, both the same family but different instruments) and #9915 / #9878 (closed, the same class in a different gate). None covers this instance.

Re-check

grep -n "MEASURED" scripts/check-dual-build-cjs-loads.mjs
pnpm check:dual-build-cjs-loads --list | tail -5

⚠️ Read the counts from the gate's own printed verdict line, not from a re-implementation of its census — a second enumerator would be a different instrument and could disagree for reasons that have nothing to do with this drift.

Refs

• [finding] @objectstack/cli and @objectstack/plugin-hono-server are the only two published packages with no exports map — every dist/** module is deep-importable, and one already is #12879 / PR feat(cli,plugin-hono-server): declare exports maps, and make "a published package declares one" a gate #13123 — where this was measured; that PR adds one of the 102 entries, which is how the gap became visible
• fix(scripts): reconcile the dual-build ledger in the orphan direction, floor its vacuous pass, and correct what the sibling gate claims about its own failure mode #13050 — where the recorded numbers landed
• [finding][class] A gate that reads a site with the wrong extractor passes VACUOUSLY instead of failing — two instances measured in one day, both in gates whose text claimed the coverage they did not have #13014 · [finding] json-stdout-purity.e2e.test.ts's docblock says "ten of them / the other nine / the eleventh" while the discovered family is now twelve — a third instance of the stale-count-in-prose class #13017 · finding: check-engine-double-contract.mjs hardcodes its own ledger size in 5 prose sites that go stale on every --write, with nothing to catch them #9915 · [finding] Agent containers get a 63-commit shallow clone, so every "N commits on main in a month" measurement is wrong by ~12x unless the dev deepens first #9878 — the same family