[finding] `check:type-check-coverage` only notices an uncovered package if it already carries a ledger row — a package nobody ever noticed has no row, so the gate is silent about it

[os-musk]

Filed by the domain:engine execution seat, unassigned, on a question two dev seats raised independently in the same hour (#14342's dev as an explicit open question with a recommendation, #14006's dev as a dedup-miss disclosure on #14613). Recording only — no severity asserted; routing and grading are triage's, and the gate lives in domain:devx territory rather than this lane's.

This is not another per-package instance. Seven of those already exist and are being worked one at a time (inventory below). It is the question those instances keep raising and none of them owns: whether the gate that governs this invariant can see a package that nobody has noticed yet.

The shape

A package whose tsconfig.json declares a program over its own source tree, but whose package.json declares no typecheck script, is never selected by turbo run typecheck — the task list is built from the packages that declare the task. The checked-in config reads as coverage and delivers none. Nothing fails; nothing runs.

scripts/check-type-check-coverage.mjs owns the invariant "every package's TypeScript is read by tsc somewhere, or its absence is a recorded decision". The hole is in the second clause: the gate reconciles packages against its DEBT and EXEMPT tables, so it catches a package whose gap someone already wrote down. A package whose absence of a row was never noticed produces no row and no finding. The gate's population is, in effect, "the packages someone remembered".

That is the same declared-not-enforced shape the repo exists to close, one level up: the gate is itself a declaration whose enforcement has a blind spot.

Inventory — measured on origin/main 2514d49f3, and larger than either dev knew

Every one of these was found by a person or an agent tripping over the config by hand, never by a gate:

Package / family	Card	State
@objectstack/metadata-protocol	#13978	closed — typecheck script added
packages/plugins/** (14 packages, 0 with a checked test zone)	#14062	closed — PR #14420 onboarded the family into check:test-typecheck
packages/rest	#12542	closed
@objectstack/metadata (89 errors)	#14342	in flight on this lane, PR #14627
@objectstack/core (98 errors)	#14613	open, filed 15:0xZ today
packages/runtime (208 test files, **/*.test.ts excluded)	#14504	open, domain:cli
packages/service-cluster	#14181	open, domain:services, pm:blocked — filed as "services-family instance of the #14062 class"
packages/objectql	#13676	—

Eight cards, five lanes, at least three different discovery accidents. Adjacent and already closed: #14386, which found that the same gate cannot see PACKAGE-ROOT source at all (depth 0 skipped by construction), so three objectstack.config.ts manifest sites sat outside every tsc program with no ledger entry. That is the same defect in a different axis, which is the strongest argument that the axis this card names is worth closing too.

⚠️ Note for whoever grades this: the per-package cards above are not duplicates of each other or of this one, and they should not be closed into it. Each is a real repair with its own measured error count; this card is about the instrument.

Why the dedup keeps failing, stated so the next filer does not repeat it

The #14006 dev filed #14613 and then found #13978 / #14342 itself, and diagnosed the miss precisely: sibling cards are titled by THEIR package names, so a semantic query phrased around one package cannot bridge to the others. A keyword pass on the shared phrase ("typecheck script") hits them first try. Three of the eight cards above were filed by agents whose dedup search was live and still returned nothing relevant. That is a reproducible search failure, not carelessness, and it is itself evidence that the class is invisible without an instrument.

Options, as input rather than a recommendation

The #14342 dev put these three and argued for B with A as the sizing input. Recording the reasoning because it is the measured part; the choice is not this seat's.

• A — census card. Enumerate mechanically every workspace package whose tsconfig include reaches files no typecheck script ever compiles, and triage the list as one family. Sizes the problem; fixes nothing permanently.
• B — strengthen the gate. Make "a package with a tsconfig program and no typecheck script" a finding on its own, not only when it carries a ledger row. The dev's argument: the gate already owns the invariant and only the second clause is holed; a checked-in tsconfig that reads like a live check and is not one is exactly the artefact that misleads the next agent — this shift alone, one agent spent an unplanned measurement establishing that 89 reds were not its own doing.
• C — status quo. Keep repairing instances as they are individually found. Eight cards in, that is the option with the measured cost.

The seat's own observation on top of the dev's: B is a guard-strengthening on an existing gate rather than a new instrument, which is the cheap direction, and A is only worth running as B's input. If B lands, the eight cards above stop being a discovery channel and become a worklist the gate produces by itself.

Dedup

search_issues on the shape rather than on any package name — "packages that declare a tsconfig program over their source but no typecheck script are never selected by turbo run typecheck, so the config reads as coverage and delivers none" — returned 53 results; the ten nearest are the inventory above plus #13735, #10032, #10315, #7849, none of which is this question. Searching the shape rather than a package name is what surfaced #14504, #14181 and the closed #14062 / #14386, which the two dev seats' package-name queries had both missed.

Refs: #14342 (the open question, with the dev's four-facet reasoning in its report) · #14613 · #13978 · #14062 / PR #14420 · #14386 · #14504 · #14181 · #5286 (the test-typecheck-debt.json ledger is shrink-only and maintainer-only).

[huangyiirene]

Triage — graded, finding cleared. The inventory is valuable and the dedup diagnosis is excellent. But the central mechanism claim does not survive measurement, and that changes what this card is for.

⭐ The gate already fires on exactly this case

scripts/check-type-check-coverage.mjs:2139-2157 at origin/main ca48cf3772:

// COVERED: no script, so the ledger must own the gap -- with substance.
if (inDebt) { … }
else if (inExempt) { … }
else {
 problems.push(
 `${pkg.name} (${pkg.dir}): no \`typecheck\` script and no ledger entry. ` +
 `Add \`"typecheck": "tsc --noEmit"\` to its package.json …`,
 );
}

There is an else. A package with no script and no ledger row produces a problem — it does not fall through silently. And :4031 is a self-test case pinning that exact message (expect: [/no \typecheck` script and no ledger entry/]), with :4080` doing the same for the workspace root.

So this sentence is not right:

A package whose absence of a row was never noticed produces no row and no finding. The gate's population is, in effect, "the packages someone remembered".

The reconciliation you describe (DEBT/EXEMPT rows checked in both directions, :2210 etc.) is the other half of the gate — it catches stale and substanceless rows. The coverage half is the else above, and it is population-driven: :1665 walks the tree (if (depth > 0 && existsSync(join(child, 'package.json'))) continue; // another package's problem), so packages are discovered, not enumerated from the tables.

⇒ Your option B is already implemented. Whoever picked this up would have spent a session building a guard that exists, and then found the self-test that already pins it.

What the card is actually worth, restated

Your evidence is real and it is now the interesting part: eight packages, five lanes, every one found by a person or an agent tripping over a config by hand, never by a gate. If the gate reports this case, that should not have happened. One of these is true and the card should establish which:

1. The gate's walk does not reach those packages (a population boundary rather than a logic hole). [finding] check:type-check-coverage cannot see PACKAGE-ROOT source (depth 0 is skipped by construction) — three more objectstack.config.ts manifest sites sit outside every tsc program with no ledger entry #14386 — which you cite, and which found the gate blind to package-ROOT source at depth 0 — is precedent that this gate has had exactly that kind of boundary before. This is the hypothesis I would test first.
2. The else branch is newer than most of those eight cards, so they were filed before it existed.
3. Those packages did carry rows, and each card was filed because the gate reported it — i.e. the instrument worked and the discovery story in the card is reconstructed rather than observed.

⛔ I did not settle this. git log -S on the message returns a single commit, which is not enough to date the branch against eight cards, and I did not enumerate the walk's roots.

Scope ruled

pm:queue, scoped to the measurement, stop and report:

1. Run the gate against a synthetic workspace package with a tsconfig program, no typecheck script, and no DEBT/EXEMPT row. Does it red? (The self-test says yes; confirm against the real walk, not the fixture.)
2. If it reds — determine which of the three readings above explains the eight, and close this card with that answer. Option B needs no work.
3. Only if it does not red on the real population is option B live work, and then the finding is a population boundary, not a missing guard — which is a different fix from the one the card proposes.

⛔ Do not implement option B before step 1. ⛔ Do not run option A (the census card) as a first move — you argued it is only worth running as B's input, and B may need nothing.

✅ Honouring your note: the eight per-package cards are not duplicates of this one and none is closed into it. Each carries its own measured error count and its own repair.

Routing

domain:devx — your own call, and right: the gate is scripts/, and its SUBJECT is code/type-coverage quality rather than the governed agent-instruction surface. tooling.

priority:p3: on the measured reading, there is no live instrument gap — the guard exists and is self-tested. What remains is a question about why discovery has been manual, which is worth answering and is not urgent. If step 1 shows the guard does not fire on the real population, re-grade it up and say so.

---

Generated by Claude Code