chore: capture iss-194 — retention is documented as operating but has never run - #207
Merged
Conversation
… never run The newest-per-line policy is implemented and previewable, but no caller executes it and the release workflow carries no retention step, so the repository's own release list contradicts the prose. A dated DECISIONS line records why v0.4.0 and v0.4.1 stay: they are itd-70's live fixture. Assisted-by: Claude:claude-opus-5
REPPL
force-pushed
the
docs/iss-194-retention-never-run
branch
from
August 7, 2026 15:03
2abff7e to
77857ac
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Record-only: one ledger capture plus a dated
DECISIONS.mdline. No behaviour changes.What was found
The newest-per-line retention policy is described in the present tense in
.abcd/development/brief/04-surfaces/04-launch.md:134and the release glossary entry, andinternal/core/launch/retention.go:30implements it exactly — but nothing executes it.internal/core/launch/ship.go:41stops before any network call ("the real GitHub Release + SLSA + tag push + retention prune are a later phase"), and.github/workflows/release.yml, which publishes every release this project has actually cut, carries no retention step. The brief's own phase note schedules the prune as itd-70, unshipped.Live evidence: six releases exist, and the real preview keeps
v0.1.0,v0.2.0,v0.3.0,v0.4.2while it would prunev0.4.0andv0.4.1— so the repository's release list contradicts its own prose. Same implemented-but-never-run class as iss-183.Scope is the doc-currency half only: state that the policy is computed and previewable but not yet enforced, on the channel-truthful pattern iss-183 established. Wiring the prune is itd-70 and is not assumed here.
Disposition recorded
v0.4.0andv0.4.1stay rather than being pruned by hand: they are the only live fixture itd-70 has to prove itself against on arrival, and the first real prune should be the shipped mechanism's.Also noted in the ledger body as possibly separable:
internal/core/launch/dryrun.go:126discards the error fromGitExistingTags, so a shallow or tagless checkout yields an empty existing set and the retention preview reports nothing to prune — indistinguishable from a genuine nothing-to-prune. Reproduced during this investigation.Verification
make preflightexits 0;gofmt -l .is empty;go run ./cmd/record-lintreports 0 blockers.