[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 #12426

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.