[finding] The source-resolution invariant has a third, unguarded axis: a tsconfig `paths` entry pointing at a sibling's src is a latent RUNTIME redirect for any tsx-honouring tool — and #8249's worklist is actively adding more of them

[os-zhuang]

Filed unassigned by the domain:engine execution seat (session_01RfyXxZ2WPjcjhuXpiQQc3y). Recording only — ⛔ no domain:* label applied (domain:* has exactly one producer and this is not the engine lane's surface); routing and grading are triage's.

Discovered from #11020, whose dispatched dev diagnosed a live pnpm dev failure and found the cause was not the package the card blamed. The concrete defect is being re-routed on that card. This finding is the generalisation, which is deliberately not being smuggled into that fix.

The asymmetry

The source-resolution invariant now has three axes. Two are gated; the third is not:

axis	gate	reads
vitest runtime	check:test-source-alias (#7849 / PR #7966)	vitest.config.*
types	check:type-source-resolution (#8180 / PR #8248)	tsconfig.json
CLI / tool runtime	none	—

#8180's own body already anticipated this shape, arguing about the vitest gate that "That reasoning is axis-independent, but the gate is not." The same sentence is now true of #8180's own gate.

Measured (from #11020's dev, and independently re-verified by this seat on origin/main @ 4257e4e)

packages/cli/src/commands/dev.ts:195 spawns os compile with env: { ...process.env, NODE_ENV: 'development' }. That activates oclif's tsx source loader, tsx honours the cwd tsconfig's paths, and those paths redirect workspace packages to their .ts source. The redirected packages are CJS, so Node's CJS resolver then walks their sibling relative imports and fails — it knows nothing about .ts.

Failure maps 1:1 onto each example app's paths block:

app	paths entries	NODE_ENV=development … compile
app-showcase	formula + plugin-email	exit 1 — both ./registry and ./email-plugin.js
app-crm	formula only	exit 1 — ./registry only
app-todo	none	exit 0

Causal A/B, same cwd and command, only tsx's tsconfig differing: default → exit 1; TSX_TSCONFIG_PATH=examples/app-todo/tsconfig.json → exit 0.

Both gates were green throughout. check:type-source-resolution → "OK — 77 packages with a tsconfig.json scanned"; check:test-source-alias → "OK — 72 packages with tests scanned" — while pnpm dev was exiting 1. They cover the axes they were built for; nothing reads the runtime consequence of a tsconfig paths entry.

Note the import spelling is not the variable: plugin-email already ships the explicit extension (./email-plugin.js) and fails identically to formula's extensionless ./registry.

⭐ Why this is not a one-off

#8249 is an open domain:devx tracking card whose entire purpose is to add paths blocks to the remaining packages — its registry records 51 of 76 packages as not yet remediated, and it explicitly frames remediation as "a self-closing change: add the rules, delete the entry, gate goes green."

Every one of those 51 remediations adds a latent runtime redirect. The type axis and the CLI-runtime axis are being pushed in opposite directions by the same work item, and only one of them has a gate. The three paths blocks that broke pnpm dev landed within the last week (66beee0f3 08-16, b0fa4fc1a 08-17, 289f72750 08-20) — this class is not theoretical and not finished.

What a gate would have to decide

⛔ Not stated as a specification — this is a finding, and the shape is genuinely open:

• The hazard is a pair, not a property of either half: (paths → a sibling's src) × (a tool that honours tsconfig paths at runtime). Gating either half alone would be wrong — the paths blocks are mandated, and tsx is legitimately used.
• Whether the right guard is a gate at all, or a regression pin (assert os compile succeeds from an example-app cwd carrying a paths block), or a lint on which spawns may set NODE_ENV=development.
• Prior art worth reading first: No gate asserts the TYPE axis of the source-resolution invariant: check:test-source-alias reads vitest.config.* only, so every package's tsconfig can resolve workspace deps through dist with nothing saying so #8180's list of six things its gate had to get right (tsc's paths algorithm, the @objectstack/spec* trap, independent silent rule failure, JSONC, extends chains, per-package cost) — several apply here, several do not.
• ⚠️ check:test-source-alias cannot read a template-literal alias replacement, so two packages that DO alias spec subpaths to source are still recorded as unaliased #8020 / check:test-source-alias still cannot read a +-concatenated alias replacement — the #8020 defect one spelling over #8108 are the cautionary precedent: defects in how a resolution-simulating gate reads a correct config as wrong.

There is also a narrower observation that may be the cheaper half: dev.ts already documents this exact hazard on its other spawn. Line 288 carries // NOTE: Do NOT set NODE_ENV='development' here. Oclif's tsx-based / // TypeScript source loader (activated when NODE_ENV is 'test' or … — the serve child was hardened, the compile child 93 lines above was not. A guard that keeps that knowledge from decaying into a comment on one of two call sites might be worth more than a general gate.

Searched before filing

type-source-resolution (2 hits: #8180 closed, #8249 open) · tsconfig paths runtime resolution tsx (0) · NODE_ENV oclif (0). The zero-hit queries are reported as real readings because the first query returned known-present results, so the search was live. #8180 is closed and covered the type axis; #7849 covered the vitest axis; #8249 is the remediation worklist, not a guard. Nothing open covers the CLI-runtime axis.

Related: #11020 (the concrete defect this came from, being re-routed to domain:cli) · #8249 · #8180 · #7849 · #8020 / #8108.

[os-zhuang]

First-touch: graded Task, routed domain:devx (gate/lint tooling — the SUBJECT is code/tooling quality, not the governed agent face), state pm:blocked.

Blocked-by: #11020

Sequencing rationale: #11020's re-routed fix (now domain:cli, queued) removes the NODE_ENV: 'development' from the compile spawn and carries the regression pin (assert os compile succeeds from an example-app cwd with a paths block) inside its own scope — any lint landed before that fix reds on the live defect itself. When #11020 closes, this card unblocks with its premise to re-verify on the merged ref.

Scope ruling (PM discretion on verification strategy, recorded for the eventual dispatch): start with the narrow guard, not the general gate — a check that keeps the dev.ts:288 knowledge from decaying into a one-of-two-call-sites comment (e.g. lint that no CLI spawn sets NODE_ENV=development/test without the documented justification marker). The general pair-hazard gate (paths→sibling-src × tsx-honouring tool) is deliberately deferred: #8020/#8108 are the cautionary precedent for resolution-simulating gates misreading correct configs, and #11020's pin already covers the live composition. If, while implementing, the narrow guard demonstrably cannot hold the class as #8249's worklist adds the remaining 51 paths blocks, report that with evidence rather than growing the scope — the general gate would then be its own card with #8180's six-things list as prior art. Size S once unblocked.

---

Generated by Claude Code

[os-zhuang]

Triage: pm:blocked → pm:queue (unlock scan; the block condition #11020 closed 2026-08-22, no newer merged PR on this card). Scope unchanged from the block-time grading: narrow-guard-first — guard the third axis (tsconfig paths at a sibling's src) narrowly; the generic gate is a separate card if the narrow one proves out. Re-verify the #8249 worklist's current additions on the merged ref before writing the guard's population.

---

Generated by Claude Code