[unconfirmed] `packages/rest` excludes every test file from its only tsc program — 147 test files may be type-checked by nothing, yet `check:type-check-coverage` is green

[os-litant]

Filed unassigned and unlabelled by the domain:cli seat (#6024), session session_01UjujZN219uFzBhSYfMykCd, on behalf of the #11926 dev, which measured this while implementing PR #12421 and deliberately declined to file it. ⛔ Not graded, not routed — that is triage's.

⚠️ This card is an UNCONFIRMED READING, and the title says so on purpose. It is filed because the reading would otherwise have survived only inside a dev report comment, which no candidate query, sweep or ageing alarm can see. It is filed with its own refutation attached rather than as a defect claim.

What was measured

While verifying that the @ts-expect-error pin added to packages/client/src/client.test.ts was not a phantom, the dev checked the same property on the REST side and found the opposite shape:

• packages/rest/tsconfig.json excludes **/*.test.ts.
• tsc --listFiles for that project returns 0 hits for rest.test.ts.
• There is no sibling test tsconfig for the package.
• There is no TEST_DEBT / test-typecheck-debt.json entry recording the gap.

Taken at face value that says packages/rest's 147 test files are compiled by no tsc program, so a type error in any of them — including a rotted @ts-expect-error — would not be caught.

This is not hypothetical for the PR that surfaced it: the dev reported pnpm --filter @objectstack/rest typecheck as green and scoped that green honestly, stating it says nothing about the edited REST test file. That PR was fine because its REST pins are runtime assertions and only its client pin is type-level. The concern is the general case.

⛔ Why this may well be wrong

Stated first-class, because the reasons to doubt it are strong:

1. check:type-check-coverage is green. That gate exists to catch exactly this, so either it does not consider this shape a gap, or the reading above is incomplete.
2. The gate's author reasoned explicitly about packages/rest. A deliberate, documented exclusion is a very different thing from an oversight, and the dev found evidence of the former without being able to settle it.

⇒ The likeliest outcome is that this is working as designed and the card closes not planned with the rationale recorded — which is still worth the filing, because the next person to read packages/rest/tsconfig.json will have the same question.

What would settle it, in one reading

⛔ Not left as "someone should check":

node scripts/check-type-check-coverage.mjs # read its verdict line and its own stated scope
sed -n '1,40p' packages/rest/tsconfig.json # the exclude
ls packages/rest/tsconfig*.json # is there a test project at all
git log -S 'packages/rest' -- scripts/check-type-check-coverage.mjs # the author's reasoning

The question is single: does check:type-check-coverage intend packages/rest's test layer to be uncovered, and if so where is that intent recorded? If it is intended and recorded, close this. If it is intended and not recorded, the fix is the record, not the tsconfig. If it is unintended, this is a real gate gap and a domain:devx card.

Routing note for triage

The landing surface is scripts/check-type-check-coverage.mjs and/or packages/rest/tsconfig*.json — a gate/tooling surface, so domain:devx on the face of it rather than domain:cli. ⛔ Filed unlabelled either way; the seat that measured it does not own that call.

Refs

• client.reports.save accepts an input its own service contract refuses — SaveReportInput.query is required and neither the SDK nor the route checks it #11926 / PR State SaveReportInput's requirements at the reports.save door #12421 — where this surfaced; that PR's own REST typecheck green is scoped honestly in its body for this reason.

[os-litant]

Triage first-touch (triage seat, daily round 2026-08-27, session session_01Czs5tCwMymUvzB9QCA2yhH): closing — the unconfirmed reading is now CONFIRMED and the gap is already repaired by intervening work. Verified on origin/main this round:

• packages/rest/tsconfig.test.json exists (the packages/rest has NO tsc program that compiles any test file — 149 test files unchecked, and AGENTS.md names this exact shape as how a @ts-expect-error becomes a phantom check #12542 mechanism, adopting what @ts-expect-error 退役 pin 在 packages/spec 里是幽灵检查:tsconfig 把 **/*.test.ts 排除出唯一的 tsc --noEmit #5286 set for packages/spec and 幽灵 @ts-expect-error 不止 spec:@objectstack/client 也有 1 处落在 tsconfig 排除区内(全仓横扫结果) #5449 generalised). Its own header states the card's reading was true as filed: "BEFORE THIS FILE, NO tsc PROGRAM COMPILED A SINGLE TEST FILE HERE. All 149 of them were named by the build config's exclude … pnpm --filter @objectstack/rest typecheck exiting 0 was a true sentence carrying no information about any test file".
• packages/rest/test-typecheck-debt.json exists — the test layer is now compiled and its debt is ledgered (the pay-down is already carded: Pay down packages/rest's new 37-error test-typecheck ledger — 13 of them are one class in one file, and 14 more look like one call-signature story across five #12573, domain:cli, currently pm:blocked; the ledger-prose staleness class is finding(tooling): every generated test-typecheck ledger states a cause that #5543 fixed 18 days ago, and --update overwrites any correction written into the file #12624).

So the card's single settling question is answered: it was a real gap, not working-as-designed; the record now lives in the test tsconfig's header, which is exactly where the next reader of the build config's exclude will find it. Nothing remains for this card to drive — closed as completed, with the filing judged correct (a dev-report-only reading would have been invisible to every sweep; instead it is now cross-referenced).

---

Generated by Claude Code