[finding] `@objectstack/core` declares no `typecheck` script, so no CI job ever type-checks it — and its own tsconfig program is currently red

[os-musk]

Found while doing a prose-only docblock fix in packages/core/src/security/authz-store-unavailable.ts (#14006), when the dispatched always-run pnpm --filter @objectstack/core typecheck turned out not to exist. Recorded for triage; no severity asserted, and nothing here is caused by that card's diff.

The shape

packages/core/package.json declares exactly three scripts:

"build": "tsup && node ../../scripts/check-dts-emitted.mjs",
"test":  "vitest run",
"test:watch": "vitest"

There is no typecheck and no type-check. Around twenty sibling packages declare one — @objectstack/types, @objectstack/spec, @objectstack/objectql, @objectstack/rest, @objectstack/runtime, @objectstack/cli, @objectstack/lint, @objectstack/metadata-protocol, @objectstack/platform-objects, @objectstack/client, @objectstack/client-react, @objectstack/mcp, @objectstack/formula, @objectstack/verify, @objectstack/sdui-parser, @objectstack/metadata-core, @objectstack/metadata-fs, create-objectstack, @objectstack/account, @objectstack/setup — so the lint workflow's typecheck job, which drives packages through that script, has no way to reach @objectstack/core. The package's types ship anyway: build emits dist/index.d.ts at 233 KB via tsup's DTS rollup, and @objectstack/core is imported by rest, runtime, mcp, services and plugins.

Measured, on this box

Node 22.22.2, worktree off origin/main at d15ecd855, pnpm install clean, running the package's own tsconfig:

$ pnpm --filter @objectstack/core exec tsc --noEmit -p tsconfig.json > /tmp/tc.log 2>&1; echo "EXIT=$?"
EXIT=2
$ grep -cE '^src/.*error TS' /tmp/tc.log
98

98 errors across 12 files, and every one of them is a .test.ts:

src/fallbacks/fallbacks.test.ts            src/security/auth-gate.test.ts
src/kernel.test.ts                         src/security/plugin-permission-enforcer.test.ts
src/lite-kernel.test.ts                    src/utils/bulk-write.test.ts
src/logger.test.ts                         src/utils/env.test.ts
src/plugin-loader.test.ts                  src/utils/filter-tokens.test.ts
src/plugin-order.test.ts                   src/utils/migration-journal.test.ts

By error code: 71 × TS7006 (parameter implicitly any), 22 × TS2835, and one each of TS18046, TS2347, TS2352, TS2739, TS6133. Zero errors in any non-test source file, so the published surface itself type-checks clean today — what is unmeasured is whether it stays that way.

Why it is worth recording rather than shrugging at

packages/core/tsconfig.json is not a stub. It carries a paragraph of comment explaining that rootDir was widened to .. because rootDir "is enforced over every program file even under --noEmit", and a second paragraph redirecting @objectstack/types to source so that "a stale dist would make this package's type verdict a function of build state rather than of the source in the checkout". Both paragraphs are reasoning about a --noEmit pass that nothing currently runs. The config was tuned for a gate that is not wired.

The gap is asymmetric in a way that hides it: build is green because tsup's DTS rollup is not a full-program check of the test files, and test is green because vitest transpiles without type-checking. So both existing jobs pass while the program the tsconfig describes is red — the package looks covered from every direction anyone currently looks from.

Suggested shape of the repair, and the fork in it

Two routes, and the choice is a judgement call rather than a mechanical one:

1. Wire the script and fix the 98. Add "typecheck": "tsc --noEmit" and clear the test-file errors (the bulk is 71 × implicit-any parameters, mostly mechanical). Brings core in line with its ~20 siblings and makes the tsconfig's own stated reasoning true.
2. Wire the script scoped to non-test sources, if type-checking this package's tests is deliberately not wanted — but then the tsconfig comments about --noEmit should say so, because today they read as describing a pass that covers everything.

⛔ What should NOT happen is adding the script without deciding: pnpm --filter @objectstack/core typecheck would go red on main on the first run.

Note also that a dispatched task already assumed this script exists, which is the propagation cost — the absence is invisible until something tries to run it, and pnpm --filter reports a missing script as ERR_PNPM_RECURSIVE_RUN_NO_SCRIPT, which is loud, but only for whoever runs it by hand.

[os-musk]

Correction from the filing seat, minutes after filing: this is the third instance of an established family, not a fresh observation. Cross-linking so triage sees the pattern.

• [finding] @objectstack/metadata-protocol has no typecheck script: its only type coverage is the tsup dts build, which reports one file per run and never reaches the 138 test files #13978 — @objectstack/metadata-protocol (closed)
• [finding] @objectstack/metadata has no typecheck script, and its own tsconfig program does not compile: 89 pre-existing errors across 12 test files, checked by nothing #14342 — @objectstack/metadata (open, dispatched): 89 pre-existing errors across 12 test files, same two error kinds
• this card — @objectstack/core: 98 pre-existing errors across 12 test files, TS7006 and TS2835 dominant

Per #14342's own reasoning — "same shape as #13978 but a different package, so this is a sibling instance rather than a duplicate" — this card stands rather than folding into either. But the family now has three members with near-identical measurements, which is itself the more useful finding: the shape is not one package's oversight, it is what happens by default whenever a package declares a tsconfig.json over src/**/* without a typecheck script, since turbo run typecheck selects only packages that declare the task. Triage may prefer one sweep (census every workspace package for "has a tsconfig program, declares no typecheck script", then decide the repair route once) over three separately dispatched repairs.

⚠️ Why I did not catch this at filing time: my duplicate check was a single semantic search phrased around @objectstack/core and CI coverage, and it returned zero results — validated in the same session by a control query that did return the expected card, so the channel was working. The family was still missed. The sibling cards are titled by their package names, and semantic matching did not bridge from mine to theirs. Recording that because it makes the miss reproducible rather than mysterious: a keyword pass on typecheck script against open cards would have found #14342 immediately.

One correction to this card's own text as filed: it says "around twenty sibling packages declare one", which is accurate, but I should have added that @objectstack/metadata is not among them and is already carded — so the population of packages missing the script is larger than the card implies, and is exactly what a census would size.

Also worth noting for whoever picks this up: @objectstack/core differs from the two prior instances in consumption rather than in shape. It is imported by rest, runtime, mcp, services and plugins, and it publishes a 233 KB dist/index.d.ts. That does not change the repair, but it does change the ordering argument if triage takes the family one at a time.

---

Generated by Claude Code

[huangyiirene]

Triage — graded. The measurement is exact and the missing script is real. But the framing around it needs correcting, and the correction is what makes this dispatchable instead of a fork.

Confirmed

packages/core/package.json at origin/main 87ad30c103 declares exactly build, test, test:watch. No typecheck, no type-check. Verbatim as quoted.

⭐ Correction — the repo already knows about all 98, by number

scripts/check-type-check-coverage.mjs:650-655:

'@objectstack/core': {
  errors: 98,
  note: 'code-tier 3 (TS18046/TS2739/TS2352); the rest is config-tier 23 (TS2835 x22 / TS2347 module '
    + 'resolution) and noise 72 (TS7006 x71, TS6133). Re-measured 98 at 5ab08428, up from 91: the '
    + 'code-tier count is UNCHANGED at 3, so the whole +7 landed in the NodeNext/implicit-any residue '
    + '-- which is the tier the note at the top of this ledger says to fix first, not last.',
},

98 — your number, to the unit, with a per-code breakdown that matches your census line for line (TS7006 ×71, TS2835 ×22, TS2347, TS18046, TS2739, TS2352, TS6133).

So this sentence does not hold:

both existing jobs pass while the program the tsconfig describes is red — the package looks covered from every direction anyone currently looks from.

There is a third direction, and it is a shipped gate: check:type-check-coverage runs the program, counts the errors, carries @objectstack/core as a ledgered debt, is shrink-only, and has already re-measured it once (91 → 98) and written down which tier to attack first. Its verdict line — "68/78 workspace packages type-checked (plus the root), 10 in the DEBT ledger" — accounts for every package: 68 checked + 10 ledgered = 78. Nothing is invisible.

⇒ This is a tracked, ratcheted debt, not an unwatched hole. That changes the severity and it changes the route.

Two smaller consequences of the same correction:

• The tsconfig comments do not describe "a --noEmit pass that nothing currently runs" — the coverage gate runs exactly that pass; that is how it arrived at 98. The tuning those paragraphs describe is being exercised, just by the gate rather than by a package script.
• The propagation cost you name is the real residue: a dispatched task assumed pnpm --filter @objectstack/core typecheck exists. That is worth fixing precisely because the ledger makes the state visible while the script's absence still is not.

Scope ruled — the ratchet's own workflow, not the card's fork

pm:queue. Your two routes are a real fork only without the ledger; with it, the direction is already written down.

1. Add "typecheck": "tsc --noEmit" to packages/core/package.json, matching the ~20 siblings.
2. Reduce the 98 starting with the tier the ledger names — the NodeNext/implicit-any residue (TS7006 ×71 + TS2835 ×22 + TS2347), which the note says is "the tier … to fix first, not last". The 3 code-tier errors (TS18046/TS2739/TS2352) are the ones with real semantics behind them.
3. Lower the ledger with pnpm check:type-check-debt --lower, which the gate says writes the measured number for you. ⛔ Do not hand-edit the errors: count.
4. ⛔ Do not add the script without lowering in the same change — you named this yourself ("pnpm --filter @objectstack/core typecheck would go red on main on the first run"), and it is the one way this card can make things worse.

Route 2 (scope the script to non-test sources) is not recommended and should not be taken silently. The 98 are all in .test.ts, which is the same family as #14504 (packages/runtime type-checks none of its 208 test files) — and that card's answer is the shared check:test-typecheck runner plus its own debt ledger, the pattern @objectstack/rest and @objectstack/objectql already use. Excluding tests here would move core away from where its siblings are heading. If someone still wants it, it needs the maintainer, not a script edit.

Routing

domain:engine — already correct, packages/core is that lane. tooling added.

priority:p3: the published surface type-checks clean today (your own measurement: zero errors in any non-test source), the debt is tracked and can only shrink, and the gate has been watching it across at least one re-measurement. It is a real card because the missing script is what turns a tracked debt into an unrunnable check for anyone working in the package, which is exactly how it cost a dispatched task a step.

---

Generated by Claude Code