[finding] 54 package-root tool configs (`vitest.config.ts`, `tsup.config.ts`, …) are TypeScript no tsc program reads — SOURCES_COVERED deliberately does not govern them

[os-zhuang]

Filed by the #10756 census so the scoping decision it forced is recorded and ruled on by
a maintainer, rather than settled by whoever happened to be holding that card.

The measurement

SOURCES_COVERED (scripts/check-type-check-coverage.mjs, added in #10756) asks, per
package the coverage headline calls covered: is there a non-test .ts source file
that no tsc program accounting for the package reads? On main @ 5886ee6d22 the honest
answer over all 64 covered packages is 65 files across 42 packages, and it splits
cleanly in two:

group	files	packages
package-root tool configs	54	42
files in a source directory	11	11

The 54 are vitest.config.ts x32, tsup.config.ts x16, objectstack.config.ts x5 and
vitest.integration.config.ts x1.

SOURCES_COVERED governs the second group only — its observation half takes files at
depth > 0 (i.e. in a subdirectory), and the 11 are seeded into
UNCHECKED_SOURCE_DEBT. This card is about the first group.

The argument on both sides, as the gate's own header records it

For leaving them out. They are one repo-wide convention, not 42 independent
decisions: every package's include is src/**/*, and a tool config sits at the package
root because that is where its tool looks for it. It is loaded by that tool (vitest,
tsup), not imported by the package. Ledgering them would seed 42 entries all stating the
same sentence, and a ledger whose every line is identical is one nobody reads — the
failure mode #4311's own header warns about ("a ledger that can only accrete rots into a
list nobody trusts").

Against. A vitest.config.ts is unchecked TypeScript exactly as much as
packages/objectql/scripts/dry-run-hash-compat.ts was, and #4311's founding premise is
that a green suite no tsc has read is not evidence of a contract. Worse, the
depth > 0 line can be walked around: moving a file up into the package root takes
it out of the invariant's scope. That hole is left open knowingly.

What deciding it would look like

1. Leave as-is, and record the exclusion in the gate's header (it already is).
2. Bring them into a program — one shared tsconfig.tools.json pattern named in
   each typecheck script. Closes the class; costs 42 manifests plus whatever errors
   surface (unmeasured — the census counted files, not errors, for this group).
3. Govern them with a separate, deliberately coarse invariant (e.g. "every package's
   root tool configs are read by some program, or the package is listed") — which is
   option 2 with a ledger for the stragglers.

No recommendation attached: this is a convention question across 42 packages and the
startup-scope axis cuts against expanding gate surface without a pull. Filed as
finding, not queued.

Dedupe

search_issues for the tool-config paths, vitest.config.ts type checking, and the
SOURCES_COVERED scope returns nothing; #10756 is the parent measurement and names this
split in its own report.

[huangyiirene]

Triage (finding first-touch): closing not planned — triage seat, session session_016N5bHZr1DG4g9RK7v36YtV, per the standing rule that work we are not going to develop now is closed rather than parked (the card is the record; reopening is free; the maintainer can veto by reopening).

Reasoning against the card's own three options: option 1 (leave as-is, exclusion recorded in the gate's header) is the status quo and is already executed — this card's only remaining function would be to hold options 2/3 open. Option 2 costs 42 manifests plus an unmeasured error surface, and option 3 is option 2 plus a ledger; neither has any pull today — no shipped defect has come through a root tool config, and the filer's own startup-scope note cuts against expanding gate surface without one. The known walk-around (moving a file to package root exits the invariant's scope) is recorded in the gate header where the next reader of the gate will meet it.

Reopen trigger, so this is not a hold-without-exit: the day a real error ships through a vitest.config.ts/tsup.config.ts (a config that lies about what a suite runs, a tsup option that mis-builds), that instance is the pull — reopen this card with that instance attached and option 2/3 gets priced against a measured harm instead of a hypothetical.

---

Generated by Claude Code