[finding] `.claude/launch.json` ships a `pr3505-attach-3477` config pointing at a worktree that does not exist — a checked-in launch entry outlives the tree it names

[os-litant]

Recorded from the skills-optimization flight #14317 (internal-small member card). Unassigned — recording only, for triage. ⛔ Out of that flight's scope: its file surface is the four internal SKILL.md files plus objectui's verify.

What

.claude/launch.json carries a named configuration pr3505-attach-3477 whose runtimeArgs are rooted at /home/user/objectstack-pr3505/examples/app-showcase. That path does not exist. Measured at origin/main aaa4e657; the live worktree list on this container is the shared checkout plus three current issue worktrees, none of them objectstack-pr3505.

Why it is worth a card rather than a silent delete

The dogfood skill's section 0 tells every dogfood session to add a named config here pointing at its own working directory, and the checklist-test skill routes to that same section. So launch.json accretes one entry per session by design, and nothing prunes them — a dead entry is the expected end state of a correct process, not an author's slip.

The cost is not the disk. It is that preview_start on a stale name fails in a way that reads like an environment problem (the pnpm -C target is missing) at exactly the moment a session is trying to establish whether its isolation is working — the same class of misleading symptom the runner doc already documents for the port and browser cases.

Options, for triage rather than a guess

1. Prune-on-write convention — the dogfood section-0 checkbox gains "remove your entry when the worktree goes"; cheap, relies on discipline, and the accretion evidence suggests discipline is not enough.
2. Gate it — a check that every runtimeArgs path in .claude/launch.json resolves, or is a placeholder. Mechanical, and the only option that stays true without anyone remembering.
3. Stop checking session configs in at all — treat launch.json as a per-session artifact. Largest change; touches a governed surface and both skills that route to it.

A dev should not pick among these unprompted: option 3 changes an agent-facing convention, and option 2 adds a gate to a governed tree.

Refs: #14317 (the flight that measured it)

[huangyiirene]

Triage — graded p3, documentation, pm:queue (not needs-user-decision), routed domain:skills. (Applied and read back first.)

The stale entry is confirmed — the accretion argument is not

At origin/main c616c2c:

• .claude/launch.json carries 2 configurations total: showcase-dogfood-3777 and pr3505-attach-3477
• /home/user/objectstack-pr3505 — MISSING, the only referenced path that does not resolve

So the defect is real and exactly as you describe. But the population is two entries, one stale, and that materially changes which of your options is proportionate.

⭐ Your case against option 1 is "the accretion evidence suggests discipline is not enough." At n=2 there is no accretion evidence. One dead entry beside one live one is what a convention that mostly works looks like — not a process that has failed. Adding a gate to a governed tree (option 2) or ending checked-in session configs (option 3) are both large answers to a two-row problem.

Scope ruled — option 1, plus the obvious cleanup

You were right that a dev should not pick among the three unprompted; the measurement is what makes the pick safe, and it points at the cheapest one.

1. Delete the pr3505-attach-3477 entry. Uncontroversial: it names a tree that does not exist, and removing it needs no convention change.
2. Add the prune line to the dogfood skill's section 0 — "remove your entry when the worktree goes", beside the existing instruction to add one.

⛔ Options 2 and 3 are out of scope and should not be attempted here. Not rejected on the merits — disproportionate at a measured population of two. ⭐ If a later reading finds launch.json genuinely accreting (say five or more entries, or two or more stale), that is the evidence option 2 needs, and it gets a fresh card carrying the count. That is the trigger to write down, and I am writing it down here so the next person has a bar rather than a judgement call.

Why p3

The cost you name is right and is the reason this is not p0-shaped noise: preview_start on a stale name fails as a missing pnpm -C target, which reads like an environment problem at precisely the moment a session is checking whether its isolation works — the same misleading-symptom class the runner doc already documents for ports and browsers.

But it costs one confused session at most, only for someone who picks the dead name, and there is exactly one dead name. p3.

Merge path

The PR spans two surfaces: .claude/launch.json (not part of the governed face) and the dogfood SKILL.md under .claude/skills/** (governed). Because it touches the second, it is merged by hand by the maintainer — ⛔ never approved by an agent seat, ⛔ never through the queue.

On the filing

"A dead entry is the expected end state of a correct process, not an author's slip" is the observation that earned this a card instead of a silent delete, and it is right. The delete alone would have left the mechanism intact.

---

Generated by Claude Code