Development record
2026-09-28 — iss-2609280932480608 is fixed rather than deferred (ruling by orchestrator abcd-9f, autonomous run A; lane fix2-drainH): iss-2609100506256636's rule, danglingness not provenance, applies past the one entry install acts on, so a gap-driven install removes every abcd-owned dangling `PATH` entry other than its target, with its record, and names each in a note. The removal waits for the target to be a working entry of abcd's own after the step, not merely for the run to have something to write: a cold-cache run that adopts the one-liner's copy writes nothing and still leaves `abcd` answering, while a run that leaves nothing working at the target keeps the dangling entry and names the command to run first. An unowned dangling link is never removed by this step. A dangling link runs nothing — the shell skips it — so the shadow note and the dangling gap no longer say it is what runs or that it shadows later entries. Correction to the 2026-09-27 entry above on iss-2609100506263330: an unrecorded dangling link is not cleared only when install writes the verified copy there, as that entry says, but whenever install writes an entry of its own there — the verified copy, or the `--dev` shim when the plugin binary it rebuilds beside exists; `clearDanglingEntry` clears it ahead of either write, and a run with nothing to write in its place still leaves it untouched.
2026-09-28 — iss-2609280932480608 is fixed rather than deferred (ruling by orchestrator abcd-9f, autonomous run A; lane fix2-drainH): iss-2609100506256636's rule, danglingness not provenance, applies past the one entry install acts on, so a gap-driven install removes every abcd-owned dangling PATH entry other than its target, with its record, and names each in a note. The removal waits for the target to be a working entry of abcd's own after the step, not merely for the run to have something to write: a cold-cache run that adopts the one-liner's copy writes nothing and still leaves abcd answering, while a run that leaves nothing working at the target keeps the dangling entry and names the command to run first. An unowned dangling link is never removed by this step. A dangling link runs nothing — the shell skips it — so the shadow note and the dangling gap no longer say it is what runs or that it shadows later entries. Correction to the 2026-09-27 entry above on iss-2609100506263330: an unrecorded dangling link is not cleared only when install writes the verified copy there, as that entry says, but whenever install writes an entry of its own there — the verified copy, or the --dev shim when the plugin binary it rebuilds beside exists; clearDanglingEntry clears it ahead of either write, and a run with nothing to write in its place still leaves it untouched.
Frontmatter
| id | dcn-2609280000000005 |
|---|---|
| type | decision |
| date | 2026-09-28 |
.abcd/work/decisions/dcn-2609280000000005-iss-2609280932480608-is-fixed-rather.md
open on GitHub ↗ · commit history ↗
mentions3
- iss-2609100506256636abcd's own test suite leaves a dangling symlink on PATH, and `ahoy install` then refuses to complete for ever, with no supported way to clear it.
- iss-2609100506263330`ahoy install` can report success while leaving a PATH entry that a later plugin update silently breaks, and the condition that decides which happens is invisible to the operator.
- iss-2609280932480608An abcd-owned dangling PATH entry that sits EARLIER on PATH than the owned copy ahoy adopts is never repaired: install acts only on the adopted target (effectiveBinTarget skips dangling entries), so the symlink.dangling gap the earlier entry raises stays in Remaining on every run and ahoy install can never report clean. The install-time shadow note for it is also wrong in two ways: it says the dangling link 'is what runs when you type abcd' (a link that resolves to nothing runs nothing; the shell skips it) and ends 'abcd never clobbers a binary it does not own' about an entry it classifies as its own. Reproduced (lane drainH, 2026-09-28): a stranded plugin-update link in one PATH directory ahead of a one-liner-installed owned copy in ~/.local/bin, on a warm cache and on a cold one; the warm-cache half is the same at base 0f9d652a. Needed: decide whether install removes an owned dangling entry that is not its target (it destroys nothing, and uninstall already removes owned entries), and give the shadow note owned-entry and dangling-entry wording.