2026-09-30 — Correcting one name in the entry above that applies rulings CJ1 and CJ1b (lane installerMeta2, autonomous run A; Refs: iss-2609291942520919): the session start's single write is not `cache/update-shown` but `cache/update-shown-<new>`, one claim per release, named for the new tag and written beside the cache's `binary-meta`; in the degraded per-root mode it is `.update-shown-<new>` beside the plugin root's own `.binary-meta` (`updateShownPrefix` in `internal/core/ahoy/unseen_update.go`, as the fix round of that lane built it). The ruling and the rest of the entry stand.

Frontmatter

.abcd/work/decisions/dcn-2609300000000014-correcting-one-name-in-the-entry-above.md
open on GitHub ↗ · commit history ↗

mentions1

• iss-2609291942520919itd-111 acceptance criterion 6 (after provisioning fetched a new pinned binary, the next session reports the version transition performed) is delivered as a per-repo comparison: ahoy.VersionTransition (internal/core/ahoy/vintage.go:220-234) compares core.Version against meta.setup_version in the repo's .abcd/config.json, written by ahoy install, and reports no transition when either side is a dev build. spc-22 stated the reference would be recorded beside the plugin-cache metadata. So a repo never set up by ahoy install, or a dogfood dev build, sees no transition report after provisioning fetched a new binary, which is the scenario the criterion describes. Either the plugin-cache record the spec named is the reference to consult, or the narrowing is recorded on the criterion.