test-typecheck-debt.json

{
  "_comment": "Per-file tsc error debt of the @objectstack/cli TEST layer (#5286). `tsconfig.test.json` compiles `src/**/*.test.ts` — which `tsconfig.json` excludes and therefore no gate ever read — and every file below still carries errors from before that gate existed. THIS FIELD IS GENERATED: every regeneration rewrites it from scripts/check-test-typecheck.mts, and the EXACT ratchet below requires a regeneration on every repair — so an edit made here is gone by the next one. Anything true of THIS package goes in the sibling `_note` field, which is authored, is preserved verbatim, and is never written by the generator (#12624). This comment states NO cause for the errors, deliberately: the classes differ per package and per file, they move as the debt is paid down, and a cause written here is rewritten verbatim into every ledger by every regeneration — so it outlives its own repair and cannot be corrected in the file where it is read. Measure instead, before repairing anything: `tsc --noEmit --pretty false -p tsconfig.test.json` in the package prints the real classes with their TS codes. Each entry maps a file to its per-SIGNATURE error counts, never to a bare total, because a total can hold while the errors underneath it are replaced wholesale: a signature is the TS code plus the diagnostic message with structural type blobs collapsed, and it carries NO line or column — so the pin survives edits that move code around, and only stops matching when the error itself becomes a different error. EXACT ratchet, judged by re-running tsc: a file that gains errors is red, a file that loses them is red until its number is re-recorded, a file that reaches zero is red until its entry is deleted, a signature that ARRIVES or VANISHES is red even when the file total is unchanged, and a file NOT listed here may have no errors at all. Regenerate with: pnpm --filter @objectstack/cli gen:test-typecheck-debt",
  "_note": "SEEDED, NOT REPAIRED, and that was this card's own triage ruling rather than this author's convenience: 28 errors across 3 of this package's 115 test files, measured at 5a5336b399 with the workspace closure built first, on the PR that first put those files in front of tsc. Repairing them in the same change would have buried the gate under a cleanup, which is how an onboarding stops landing; the ratchet only has to shrink from here. THIS PACKAGE REACHED THE HIDDEN STATE BY THE OTHER SPELLING, which is the part worth carrying to the next package: `tsconfig.json` here has no `exclude` at all. It declares `include: [\"src\"]`, and these 115 files live in a sibling `test/` tree the glob simply never reaches — the identical end state AGENTS.md forbids by naming the `exclude` spelling, arriving through a door that rule's text does not cover. Measured rather than read off the config: `tsc --noEmit --listFiles -p tsconfig.json` puts 1009 files in the program and 0 of the 115 among them, while 119 of 119 non-test `src/**` files and all 121 `src/**` test files ARE there — so the zero is the `include` line, not a probe that sees nothing. The directional control is `packages/drivers/driver-memory`, whose tsconfig carries no test exclusion: the same probe puts 40 of its 40 test files in the program. Under `tsconfig.test.json` the count is 115 of 115, plus the 3 package-root harness modules (`vitest.config.ts`, `vitest-tiers.ts`, `vitest-tiers.fixtures.ts`) and `test/helpers/serve-process.ts`, none of which any tsc program read before either. WHERE THE 28 CAME FROM, both directions attributed with no unexplained remainder: the same file population under the build config's inherited NodeNext semantics reports 144, and 144 is exactly what `scripts/check-type-check-coverage.mjs` had recorded for this package in its per-PACKAGE `TEST_DEBT` ledger — class for class on re-measurement (TS7006 x59, TS2835 x56, TS2339 x24, TS2307 x3, TS18046 x2). So this file does not add debt, it holds the SAME population one level finer, per file and per signature, and that `TEST_DEBT` entry graduated in the same change. 120 of the 144 dissolve under this program's vitest-matching module semantics (TS2835 x56 extension-less relative imports, the TS7006 x59 cascading above them, TS2307 x3, TS18046 x2) and were about the CHECK rather than the code; collapsing that cascade EXPOSED 4 more (TS18048 x4 in test/i18n-extract-action-description.test.ts, previously hidden behind an `any` from its two unresolved imports of `../src/utils/i18n-extract` and `../src/utils/i18n-coverage`). The 24 TS2339 survive the move unchanged, file for file and count for count. 144 - 120 + 4 = 28. A SECOND CONFIG-TIER PILE THAT IS NOT IN THIS LEDGER, recorded so nobody re-derives it: this package's test tree sits OUTSIDE the build config's `rootDir` (`src`), so with `rootDir` inherited the same program adds 116 x TS6059 — one per file in `test/`, saying nothing about any test. `tsconfig.test.json` widens `rootDir` to `../..` the way `packages/client`'s test config already does, and for one measured reason beyond the 116: three of these tests import fixtures from `examples/app-showcase/src/**`, which is outside this package entirely, so even `rootDir: \".\"` still reports 3 x TS6059. WHAT IS ALREADY GATED, and it is nearly all of the package: 112 of the 115 test files carry no entry here at all, so any error any one of them gains is red on arrival. ⚠️ This layer holds ZERO `@ts-expect-error` directives — measured across all 115 files plus the 3 root harness modules, not assumed — so unlike packages/spec and packages/client no pin was silently dead here, and none reports TS2578 under this program. The card's sharpest line ('a `@ts-expect-error` in any of those files is a phantom check') is therefore a statement about what WOULD happen, not about an existing dead pin. What the gap really cost is the other half: 144 real diagnostics that no gate has ever reported, and no way to write a type-level pin in this tree at all. THE PILE IS CONCENTRATED, which is the useful thing for whoever pays it down: test/data-model-rules.test.ts x23 is 23 of the 28 on its own, and all 23 are TS2339 property reads off a lint-diagnostic type ('message' x17, 'fix' x4, 'severity' x2) — one narrowing helper on that type is very nearly the whole ledger. The remaining 5 are 4 TS18048 in one file and a single TS2339 in another. RECORDED EXACTLY, no bootstrap margin: this layer has never been gated, so the first new error in it should go red rather than be absorbed. ⚠️ That includes test/run-dev-unbuilt-workspace.e2e.test.ts, a known repo-wide RUNTIME flake whose fix was in the merge queue when this landed: it type-checks clean and carries no entry here, so a type error it gains is red like any other. A flake in `vitest` is not a diagnostic in `tsc` and this ledger never sees one.",
  "entries": {
    "test/data-model-rules.test.ts": {
      "TS2339: Property 'fix' does not exist on type '…'.": 4,
      "TS2339: Property 'message' does not exist on type '…'.": 17,
      "TS2339: Property 'severity' does not exist on type '…'.": 2
    },
    "test/i18n-declared-surface-gate.test.ts": {
      "TS2339: Property 'locale' does not exist on type '…'.": 1
    },
    "test/i18n-extract-action-description.test.ts": {
      "TS18048: 'bundles.en.objects' is possibly 'undefined'.": 2,
      "TS18048: '…' is possibly 'undefined'.": 2
    }
  }
}