Development record
itd-111 acceptance criterion 2 promises that abcd ahoy install run through a stale binary refuses before any write, but under an explicit --bin-dir the writability probe runs first: install (internal/core/ahoy/apply.go:91) calls resolveInstallTarget, whose dirWritable (internal/core/ahoy/store.go:431) creates and removes a .abcd-write-probe-* temp file in the named directory or its nearest existing parent, and only then (apply.go:157) does staleBinaryRefusal fire. The comment at apply.go:267 says the probe runs without creating anything, which store.go contradicts. Net state is unchanged, but a stale or unknown-vintage binary touches the filesystem before it refuses. Move the refusal above the probe, or amend the comment and the criterion's wording.
itd-111 acceptance criterion 2 promises that abcd ahoy install run through a stale binary refuses before any write, but under an explicit --bin-dir the writability probe runs first: install (internal/core/ahoy/apply.go:91) calls resolveInstallTarget, whose dirWritable (internal/core/ahoy/store.go:431) creates and removes a .abcd-write-probe-* temp file in the named directory or its nearest existing parent, and only then (apply.go:157) does staleBinaryRefusal fire. The comment at apply.go:267 says the probe runs without creating anything, which store.go contradicts. Net state is unchanged, but a stale or unknown-vintage binary touches the filesystem before it refuses. Move the refusal above the probe, or amend the comment and the criterion's wording.
Grounds
- pursued: TestStaleRefusalPrecedesTheBinDirProbe pins the watched --bin-dir (and a to-be-created one's parent) mtime in the past and requires it unchanged after a refused install; a probe running before the refusal would move it, and any future reordering that puts a write before the refusal would show the same way
Frontmatter
| id | iss-2609291942529461 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2609291942529461-itd-111-acceptance-criterion-2-promises.md
open on GitHub ↗ · commit history ↗
mentions5
- dcn-26092900000000082026-09-29 — Two itd-111 follow-ups from its fidelity audit (lane itd111Follow of autonomous run A). The stale-binary refusal of `ahoy install` runs before the adoption question as well as before the `--bin-dir` writability probe, so a refusal asks nothing it then ignores and touches nothing (iss-2609291942529461; the record fixed only "before any write"). The criterion 6 transition reference that spc-22 placed beside the plugin-cache metadata is not built: who writes that record, where it lives when the data directory comes from the environment, and whether it replaces the per-repo setup_version comparison are unsettled, so iss-2609291942520919 is deferred past v0.11.1 with those questions owed to the product thinker.
- dcn-26092900000000172026-09-29 — Two itd-111 follow-ups from its fidelity audit (lane itd111Follow of autonomous run A). The stale-binary refusal of `ahoy install` runs before the adoption question as well as before the `--bin-dir` writability probe, so a refusal asks nothing it then ignores and touches nothing (iss-2609291942529461; the record fixed only "before any write"). The criterion 6 transition reference that spc-22 placed beside the plugin-cache metadata is not built: who writes that record, where it lives when the data directory comes from the environment, and whether it replaces the per-repo setup_version comparison are unsettled, so iss-2609291942520919 is deferred past v0.11.1 with those questions owed to the product thinker.
- dcn-26093000000000012026-09-30 — The 2026-09-29 itd111Follow entry above records the ordering of the stale-binary refusal but not what it changes for a repository that is already set up, which only commit ea70f3c9b and its pull request named (recorded by lane integ23 of autonomous run A, from the review of itd111Follow). Because the refusal runs before the adoption question and before the idempotency check that answers a set-up repository with already_up_to_date, `ahoy install` run through a stale or unknown-vintage binary on an already set-up repository refuses and names both revisions, instead of reporting it already up to date; an explicit `--adopt=false` through such a binary yields refused, with its note, rather than aborted. Both are the louder answer itd-111 asks for: a stale binary that reports "up to date" is the silent answer its design decision 1 forbids (iss-2609291942529461).
- dcn-26093000000000042026-09-30 — The 2026-09-29 itd111Follow entry above records the ordering of the stale-binary refusal but not what it changes for a repository that is already set up, which only commit ea70f3c9b and its pull request named (recorded by lane integ23 of autonomous run A, from the review of itd111Follow). Because the refusal runs before the adoption question and before the idempotency check that answers a set-up repository with already_up_to_date, `ahoy install` run through a stale or unknown-vintage binary on an already set-up repository refuses and names both revisions, instead of reporting it already up to date; an explicit `--adopt=false` through such a binary yields refused, with its note, rather than aborted. Both are the louder answer itd-111 asks for: a stale binary that reports "up to date" is the silent answer its design decision 1 forbids (iss-2609291942529461).
- itd-111A Stale abcd Never Answers Silently