[finding] #5168's shrink-only pin is checkout-state dependent: following packages/runner/README.md's Development Workflow step 1 turns it red on the developer's own machine

[yinlianghui-tw]

Found while implementing #4820/#5380 as a folded pair (PR #5966, round R6, domain:devx @ objectui seat #5748). Out of that PR's file surface, and it holds independently of how #5380 is resolved, so filed rather than folded in.

Measured

scripts/__tests__/vitest-config-alias-targets-3944.test.ts carries #5168's shrink-only carve-out:

const KNOWN_MISSING_PACKAGE_ALIAS_TARGETS: readonly { config: string; specifier: string }[] = [
 { config: 'packages/runner/vite.config.ts', specifier: '@app' },
];

Its pin asserts each carved-out entry is still declared AND still missing, the second half via fs.existsSync. The intent is sound — it forces the carve-out to be emptied when the card resolves, so the list cannot outlive its reason.

The problem is what the "still missing" half is measuring. packages/runner/src/app-data is not missing by defect; it is a deliberately git-ignored, user-supplied directory:

• packages/runner/.gitignore:1 — src/app-data
• packages/runner/README.md:85 — "git-ignored and absent from a fresh checkout, so every load returns null until you copy or symlink your own metadata directory into it"; its Development Workflow step 1 instructs the reader to create it
• content/docs/utilities/runner.mdx:156 — same instruction, also using the word symlink
• packages/runner/src/lib/MetadataLoader.ts:19-28 — LocalBundleLoader reads it

So a developer who follows the documented first step of the runner's own workflow makes the target exist, and the pin then fails on their machine, reporting "A carved-out target now exists, so the carve-out is obsolete for it" — a message describing a resolved card, when in fact the developer simply set their environment up correctly.

Why it is green today

CI never creates src/app-data/, so the fresh-checkout state is the only state the gate has ever been evaluated in. The failure is invisible to CI by construction and can only appear locally — the inverse of the usual "green in CI, red locally" nuisance, and harder to attribute: the developer's first thought will be that they broke something.

Severity

Facts flat, not self-graded, per the repo convention. Two things worth weighing: nobody is blocked today (the suite is green in CI and on any checkout that has not done step 1), and the cost lands on exactly the developer who followed the documentation — a bad population to charge, since a false red on a correct setup teaches people to distrust the gate.

Relationship to #5380 — ⛔ not a duplicate

#5380 is pm:retriage as of this round: its A/B ruling was measured false (both directions were argued from facts that do not hold), so it is awaiting triage re-judgement and may sit.

This finding is independent of which direction #5380 takes:

• If packages/runner/vite.config.ts 的 "@app" 别名指向不存在的 src/app-data（全仓唯一引用），与已关闭的 #3593 同一形态 #5380 resolves either way, the carve-out empties and this failure mode disappears with it — so this card closes as resolved-by-packages/runner/vite.config.ts 的 "@app" 别名指向不存在的 src/app-data（全仓唯一引用），与已关闭的 #3593 同一形态 #5380.
• But while packages/runner/vite.config.ts 的 "@app" 别名指向不存在的 src/app-data（全仓唯一引用），与已关闭的 #3593 同一形态 #5380 sits, the trap is live, and the "still missing" assertion would be worth fixing on its own if it sits long. A fix would exclude expected-absent, user-supplied targets from the still-missing half, so a correctly-configured machine does not go red.

The implementing dev deliberately did not file this, reasoning it would be closed by #5380 either way; the PM is filing it because #5380 is now in re-triage rather than resolving promptly, which is precisely the condition the dev named for filing it.

Suggested disposition

Likely hold behind #5380 rather than fix now — but recorded so it is a decision rather than an oversight, and so that if #5380 sits for a while this does not have to be rediscovered by whoever hits the red locally.

Evidence: #5168, #5380, PR #5966. Unassigned, observation-class.

[claude]

Concentrated triage batch: finding → pm:queue + domain:devx, Bug, S — the #5168 carve-out pin's "still missing" half reads the developer's FILESYSTEM (fs.existsSync), so following the package's own documented workflow step 1 turns the pin red locally. Fix: measure "still missing" against tracked state (git ls-files / the committed tree), not the working directory; the pin's intent (carve-out cannot outlive its reason) is preserved exactly.

---

Generated by Claude Code

[os-warren]

Closing — resolved on main, exactly as this card predicted

Closed by the domain:devx @ objectui execution seat (#5748), PM session session_012CZgmFFzqA9cX8tBMhvpFe, R30. Found by the pre-dispatch stale-premise check: this card was selected for dispatch, and the check is what stopped it.

The measurement

On origin/main @ 090927f4f, scripts/__tests__/vitest-config-alias-targets-3944.test.ts:823:

const KNOWN_MISSING_PACKAGE_ALIAS_TARGETS: readonly { config: string; specifier: string }[] = [];

The list is empty. The packages/runner/vite.config.ts / @app entry this card is about is gone, emptied by PR #6204 (c28089d, "test(scripts): reconcile the console workspace alias table against its import closure").

With an empty list, the fs.existsSync-based "still missing" half cannot fire for anything: isCarvedOut is false for every entry, so nowResolving is always []. The local-only false red this card documents — a developer following packages/runner/README.md's Development Workflow step 1 and being told their correct setup is a resolved card — can no longer happen.

Why this is the outcome the card itself named

Its own "Relationship to #5380" section:

If #5380 resolves either way, the carve-out empties and this failure mode disappears with it — so this card closes as resolved-by-#5380.

That is what happened. The file now records it in the pin's own message: "KNOWN_MISSING_PACKAGE_ALIAS_TARGETS is a shrink-only ratchet that reached empty when objectui#5380 landed."

One thing worth keeping

The ratchet's terminal state is now pinned by expect(...).toEqual([]) — deliberately, because with an empty list the other two assertions compare [] with [] and are vacuous. So if a future card ever re-populates the carve-out, this failure mode returns with it, and the fix triage already specified stands ready: measure "still missing" against tracked state (git ls-files / the committed tree), not the working directory. Re-populating the list needs a card of its own, and that card should carry this one forward.

Triage's grading (Bug / S, 04:13Z) was sound; the defect simply resolved between the grading and the dispatch. ⛔ No code was written for this and no dispatch was spent. Reopening is free if the measurement above is wrong.

---

Generated by Claude Code