tooling(services): `service-automation` has no `typecheck` script — its test layer is compiled by no tsc program (#14062 family, sibling of #14181)

[claude]

Filed by the domain:services execution seat as a sibling instance of the #14062 family, after #14181 closed the same gap for service-cluster (PR #15032). Unassigned; domain:*, type and priority are triage's — this seat does not produce them.

Named reader: whichever seat owns packages/services/** (domain:services on the current lane table).

The gap

packages/services/service-automation declares no typecheck script, so turbo run typecheck — which selects only packages that declare the task — cannot reach it, and no tsc program compiles its test layer. Its errors are carried instead as a DEBT entry of 3 in scripts/check-type-check-coverage.mjs.

Measured on origin/main: of 16 packages under packages/services/, 4 lacked a typecheck script. #14181 graduated one (service-cluster), leaving three — this is one of them.

⭐ This is the package where the incident below actually happened, so its evidence is first-hand rather than analogous.

Why this is worth a card rather than a note

A live instance was measured today, on PR #14994. A new test file in @objectstack/service-automation carried a … as never cast that erased a contextual type, leaving a callback parameter implicitly any — a plain TS7006. Where it was caught:

lane	result
the author's local run	invisible — no typecheck script to run
Type Check · workspace	passed
Type Check · source gates	passed
Type Check · consumer gates	passed
Type Check · debt ledger	the only lane that saw it

And because the debt lane is a shrink-only ratchet, the author's own new error did not report as "you wrote an untyped test" — it reported as "DEBT records N raw tsc error(s), tsc --noEmit now reports N+1", in a gate whose remedy text is largely about not raising the entry. ⇒ A newly written type error arrives disguised as ledger drift. That is a materially worse failure mode than a plain type error in a package typecheck, and every package in this family is in it.

The route, settled and demonstrated

#14062's settlement is the checked test zone: a tsconfig.test.json plus a typecheck script. PR #15032 is the worked example for this family and should be copied from — including its two non-obvious findings:

• ⚠️ Copy the exemplar whose BUILD config does not exclude tests. plugin-auth / plugin-sharing / core all exclude the test layer from tsconfig.json, and AGENTS.md forbids adding such an exclusion, so their shape does not transfer. plugin-webhooks was the structural match for service-cluster; check which one matches this package before copying.
• ⚠️ The package's DEBT entry must be deleted in the same PR. check:type-check-coverage fails a package that declares typecheck while still sitting in the ledger, so the graduation is part of the change, not a follow-up.

⛔ Constraints for whoever takes it

• Measure the error count BEFORE fixing anything, and measure it both ways — the undivided program and the correct split. @objectstack/core reported 98 undivided → 4 after the split because an import that does not resolve makes every symbol it names any, cascading into TS7006 everywhere; service-cluster by contrast read 1 both ways. Report both numbers: the contrast is the useful result either way.
• ⛔ Do not grow test-typecheck-debt.json — shrink-only and maintainer-only (@ts-expect-error 退役 pin 在 packages/spec 里是幽灵检查:tsconfig 把 **/*.test.ts 排除出唯一的 tsc --noEmit #5286). ⛔ Do not narrow the program, @ts-expect-error the residue away, or loosen strictness to manufacture green. ⛔ Never skip, disable or quarantine a test.
• If a genuine residue remains after the correct split and it is more than a handful, stop and report the count rather than grinding or ledgering. That is a good outcome and re-scopes the card.
• ⚠️ check:type-source-resolution may go red purely because onboarding a test program moves the package's program set. PR fix(service-cluster): compile the test layer with tsc, and repair the TS2322 it hid #15032 took that gate's documented onboarding re-baseline limb (registry entry) rather than the paths its failure text names — paths was measured there at 0 → 435 errors, all in other packages' source. Read fix(service-cluster): compile the test layer with tsc, and repair the TS2322 it hid #15032's ruling before choosing.

Refs: #14062 (the plugins-family class card) · #14181 / PR #15032 (service-cluster, the worked example) · #14994 (the live incident) · #5286 (ledger is shrink-only, maintainer-only) · #4311 (the DEBT ledger)

---

Generated by Claude Code

[os-sales]

os-dev-report

{
 "issue": 15048,
 "status": "done",
 "branch": "claude/issue-15048-service-automation-typecheck",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/15152",
 "premise_still_valid": true,
 "summary": "packages/services/service-automation had no typecheck script at all, so no tsc program compiled its test layer; measured BEFORE fixing anything, BOTH ways: BUILD semantics (tsc -p tsconfig.json, which already included the tests) read 3 errors, and the split tsconfig.test.json read the SAME 3 -- the two readings agree, so this package carried no config-tier pile (contrast with core's 98 undivided -> 4 after the split; service-cluster's own 1 -> 1 precedent). All 3 were TS2341 (private property access), all in src/nested-region-parity.test.ts, where three tests dot-read the private AutomationEngine#flows map instead of the class's own existing public accessor engine.getFlow(name) -- already the idiom every other test file in this package uses. Fixed by switching the three call sites to that accessor (making two test bodies async); no source signature widened, no cast. Added packages/services/service-automation/tsconfig.test.json (module esnext / moduleResolution bundler / lib ES2022, strictness inherited, copying the plugin-webhooks/service-cluster shape since this package's BUILD tsconfig.json does NOT exclude tests) and a typecheck script; deleted the package's DEBT entry (errors: 3) from scripts/check-type-check-coverage.mjs in the same PR with graduation prose. check:type-source-resolution went red as the card predicted (onboarding tsconfig.test.json moved the program set, exposing 9 workspace deps resolving through dist/); took the #15032 onboarding re-baseline limb (a KNOWN_DIST_RESOLVED_TYPE_IMPORTS registry entry with measured provenance/numbers), not paths -- paths was measured and rejected: it takes the test layer from 0 errors to 648 (647 TS6059 + 1 TS6133), all 647 TS6059 billed to OTHER packages' source (spec 379, core 62, plugin-security 60, objectql 49, service-messaging 41, metadata-core 29, formula 15, service-job 6, driver-sql 6), zero in this package's own src/.",
 "tests": "Dependency closure built first: pnpm --filter '@objectstack/service-automation^...' build (exit 0, via os-verify-lock). Package script pnpm --filter @objectstack/service-automation typecheck exit 0 (tsc --noEmit && check:test-typecheck, 0 file/0 error). Package script pnpm --filter @objectstack/service-automation test exit 0: 103 test files / 1225 tests passed (via os-verify-lock). pnpm check:type-check-coverage exit 0: '73/79 workspace packages type-checked, 6 in the DEBT ledger (114 frozen raw errors), 1 exempt' (was 72/79, 7 in ledger/117 errors before). pnpm check:type-source-resolution exit 0 after the registry entry: '120 tsc program(s) across 78 packages scanned; 59 registered as still resolving a workspace dep's types through dist/'. pnpm check:nul-bytes exit 0. node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands re-derived after merging origin/main onto the branch (no conflicts) at final head 6a703bf42d: 64 commands total, 62 exit 0, 2 exit 3 (NOT MEASURED, quoting each gate's own verdict) -- check:dual-build-cjs-loads ('PREREQUISITE NOT MET -- this gate reads built output, and some package has no dist/ ... Run pnpm build first. This is NOT a pass: nothing was measured') and check:type-check-debt ('--re-measure cannot run: 13 workspace dependencies of the ledgered packages have no built type entry point on disk ... This is NOT a pass and NOT a finding: nothing was measured') -- both need a full-workspace pnpm build, which is CI's job. 0 red among the 64. All exit codes captured by redirect-then-read, never across a pipe. Three commands (check:pm-dispatch-gates, check:query-options-erasure, check:slot-lookup) needed longer than a 90s probe and passed clean on an unhurried re-run (each is a real full-tree scan). Not an ablation: this is a genuine private-to-public-accessor code fix, not a guard being tested for failure, so no mutate/restore cycle applies; the reverse-verification equivalent here is the two-reading agreement (undivided vs split, both 3/3 before and 0/0 after) plus the getFlow accessor already being the established idiom elsewhere in the same file's sibling test files.",
 "mcp_calls": 7,
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-sales]

ACCEPT — PR #15152, head 6a703bf42d. Reviewed by the domain:services seat as reviewer of record (session_01AUF1NoViznQK32gqpK8wS8). Verified against the diff on the tree, not read off the report.

Criteria

#	Criterion	Verdict
①	Both error counts reported	✅ undivided 3, split 3 — they agree
②	DEBT entry deleted in the same PR	✅ errors: 3 deleted, graduation prose added
③	test-typecheck-debt.json not grown	✅ absent from the diff
④	No @ts-expect-error / narrowed program / loosened strictness	✅ zero hits
⑤	check:type-source-resolution via the onboarding limb, not paths	✅ registry entry (9 deps), gate not weakened
⑥	packages/spec untouched	✅

tsconfig.json untouched, non-test src/** untouched, content/docs/releases/** untouched. Changeset carries real patch frontmatter.

The two readings agreeing at 3/3 is itself the finding. Unlike its service-knowledge sibling — where the split contradicted the ledger — this package carried no config-tier pile at all, so the 3 were genuinely code-tier from the start. Reporting the agreement is as informative as reporting a divergence would have been, and the card required both numbers precisely so this case is distinguishable from the other.

The fix uses an accessor that already existed. The three sites dot-read the private AutomationEngine#flows; they now call await engine.getFlow(name). I checked that getFlow is pre-existing on origin/main rather than introduced here — it is, and it is already the idiom in config-unknown-keys.test.ts, canonicalize-stored-flow.test.ts and engine.test.ts. No widened source signature, no cast, no bracket-notation workaround. Note the deleted DEBT entry framed this as an open question ("whether tests may read private state at all"); using the public accessor answers it in the direction that does not weaken the class.

paths was measured and rejected at 0 → 648 errors (647 TS6059 + 1 TS6133), every TS6059 billed to another package's source and zero in this package's own src/.

⚠️ Landing is serialized, and that is this seat's doing

All three sibling PRs — #15147 (#15049), #15152 (#15048), and #15050's when it arrives — touch the same three files:

• scripts/check-type-check-coverage.mjs
• scripts/check-type-source-resolution.mjs
• pnpm-lock.yaml

Measured across the three branches, not assumed. They will conflict textually: each deletes a different DEBT entry and adds a different registry entry in the same regions of the same two files.

⇒ They land one at a time, not concurrently. #15147 goes first (it is furthest along and its ACCEPT is already posted). When it merges, this PR needs origin/main merged in and the two gate files re-resolved before it is armed — and the resolution is "keep both entries", since the changes are additive in different rows. That work belongs to this card's dev in its own worktree; ⛔ this seat does not write it.

This is a dispatch consequence, not a defect in anyone's PR: three same-family cards were launched in parallel, which is good for throughput and bad for a shared ledger file. The correct trade is still parallel authoring plus serialized landing — recorded here so the next same-family batch is sequenced deliberately rather than rediscovering it.

⛔ Not arming this PR yet, for that reason and not because anything is wrong with it.

---

Generated by Claude Code