check-type-source-resolution recommends `paths`, but `paths` is unavailable when the consuming program's rootDir excludes the dep — the message names no remaining self-serve option

[claude]

Filed by the PM dispatch loop from a measured finding by the #14646 round (PR #15978). ⛔ Unassigned and ungraded — domain:*, type and priority are triage's.

⚠️ This card is about the gate's GUIDANCE, not its verdict. The round that hit this judged the underlying design working-as-designed and I agree: the ratchets steered it to the correct outcome (don't take the dependency). What cost a full cycle was that the remedy the gate's own message names leads to a second, unmentioned wall.

What happened

check-type-source-resolution refused a new dist-resolved type import: @objectstack/runtime → @objectstack/service-realtime (via tsconfig.test.json). Its message offers two remedies and refuses a third:

• Add the paths rules to the package's tsconfig.json — the default remedy it names first.
• Re-baseline, if the (via …) names a program this change ONBOARDED (settled by the registry doc-block).
• ⛔ Widening the registry entry — refused, the registry is shrink-only.

The round measured its case correctly as the already-counted-program case (packages/runtime's typecheck script names tsconfig.test.json byte-identically before and after the diff), so the re-baseline limb was closed and widening was refused. That left paths — the remedy the message names.

paths then fails, for a reason the message does not mention. Measured: it cleared check-type-source-resolution (exit 0, registry unwidened) and then made pnpm --filter @objectstack/runtime typecheck exit 1 with 13 TS6059, billing @objectstack/service-realtime's file graph into packages/runtime's test-typecheck ledger. All 13 were TS6059; none was a code error. That is precisely the PR #12570 shape the message warns about — but it warns about it only under the re-baseline limb, not under the paths remedy it recommends.

The mechanism: paths pulls another package's source into a program whose rootDir is ./src, which tsconfig.test.json's own header states it will not widen. And that ledger's only other remedy is maintainer-only.

⇒ For a package whose test layer is already onboarded and re-baselined, a NEW cross-package source dep in its test program has no self-serve remedy: the registry refuses the widening, paths bills TS6059 into a ledger the other package cannot see, and both the ledger expansion and the rootDir widening are closed to a dev seat.

What this card asks for

Not a design change. Make the closed door visible at the point of refusal, so the next seat does not spend a cycle discovering it:

• check-type-source-resolution's message should say that paths is not available when the consuming program's rootDir excludes the dependency's source, and name the TS6059-into-the-ledger outcome — the same warning it already gives under the re-baseline limb.
• State the remaining option plainly: don't take the dependency (reach the subject through in-package source, as the round did), or escalate, because ledger expansion and rootDir widening are maintainer-only.

⚠️ Verify the claim above before writing it into a message: it is one round's measurement on one package. ⛔ A message that overstates the closure would be worse than the current silence. Reproduce the paths → TS6059 leg first.

Prior art / refs

#15978 (the PR that hit it, and its round's measurement) · #12570 (the billing shape the message already cites) · #14646 (the card) · the tsconfig.test.json header stating it will not widen rootDir · the shrink-only registry doc-block

---

Generated by Claude Code