Development record
Drawn-out intent
Every launch ship prunes superseded releases under a newest-per-line (MAJOR.MINOR) retention policy: publishing vX.Y.Z removes the superseded vX.Y.(Z-1) tag and (once cut) its GitHub Release + assets, while the terminal release of every other line survives.
Drawn out from a human brief edit by the brief-change derivation gate (itd-61 / spc-75). Grill + flesh out before planning.
SOTA
Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the install-update-release SOTA note. The finding reverses this stub's direction.
- Published versions are immutable by convention: Semantic Versioning rule 3 says a released version's contents "MUST NOT be modified"; a change is a new version.
- Ecosystems retract rather than delete: the Go module mirror caches "to avoid breaking builds", keeps serving a version its origin removed, and tells authors to retract a bad version and publish a new one.
- The forge now offers immutable releases (generally available
2025-10-28): once published, a release's "assets can't be added, modified,
or deleted" and its tag "can't be deleted or moved"; the release can still be
deleted, after which the tag name cannot be reused; a release attestation is
minted.
release.ymlalready runs the draft-then-publish flow "immutable releases require", so the setting is a repository switch. It does not block the prune: a superseded Release and its tag can still be deleted, at the price that the tag name can never be reused and no asset of a published release can be swapped in place. - Provenance outlives the asset: a public repository's attestations sit in an "immutable transparency log" whatever happens to the Release.
- Where "newest per line" is practised it is local disk retention: the harness's installer keeps the two newest versions on disk; Homebrew removes old local versions on upgrade. Neither deletes anything published.
- The prune has run by hand once (v0.6.7 pruned v0.6.1 to v0.6.6, tags kept, per the 2026-08-27 pilot note), and the advisories published for that cut name those versions.
Path 3 — deliberate divergence from the brief's own retention design,
argued from the field's immutability convention (semver rule 3, Go's
retract) and from the advisories whose patched_versions point at pruned
versions, not forced by the forge, which still allows the prune: enable
immutable releases, keep every release,
turn ComputeRetention into a report of what each line holds, and let the
only retention act be the status edit an immutable release still allows (a
superseded patch loses "latest"). The local preference overturned is brief
§3's "shipping a patch removes the superseded patch and its Release assets";
under prefer-sota it is revisited through an ADR at this intent's planning,
not silently kept or broken. No code beyond the setting and a rename; no
dependency. The independent fit-challenge runs at plan time.
Open Questions
- (SOTA 2026-10-23) Does the ADR retire the brief's retention paragraph outright, or keep newest-per-line as a report that names the superseded patches without deleting them?
- (SOTA 2026-10-23) Are the already-pruned v0.6.x Releases left as they are
(tags present, no Release), and does the launch report say so where an
advisory's
patched_versionspoints at them?
Frontmatter
| id | itd-70 |
|---|---|
| type | intent |
| lifecycle | drafts |
| severity | minor |
.abcd/development/intents/drafts/itd-70-launch-release-retention-newest-per-line.md
open on GitHub ↗ · commit history ↗
Referenced by2
- adr-33Launch phase ownership is tiered; the phase index is the sole ownership sourcerelated
- iss-282The retention prune has no executor: ComputeRetention renders the newest-per-line plan on every cut (brief section 3) and ship.go names GitHub Release + retention prune as a later phase, so superseded patches (v0.5.0, v0.4.0 today) stay published until someone deletes them by hand from the plan. First rung: a documented manual prune after each publish (gh release delete, tags kept for record); the executor belongs in the release workflow after that proves outrelated
mentions10
- dcn-26080700000000012026-08-07 — release retention: the newest-per-line prune (brief § 3, itd-70)
- dcn-26092900000000112026-09-29 — The product thinker answered the twenty-six Group J rulings (plan or close), J1 to J26 (recorded by lane recGroupJ of autonomous run A, for orchestrator abcd-fc). The answers are kept verbatim in the local-tier file `.abcd/.work.local/scratch/reports/rulings-answered-2609-29.md`, section "Group J", dated 2026-09-29, and are restated here because that file is not committed. PLAN: the installer script becomes a minimal starter with an ownership-checked hand-over, planned as a new intent with its planning interview owed (J2, iss-377, draft itd-2609292106557115); token metering and size classes are planned as one intent (J3, iss-2608301744251874 and iss-2608301856299268), and session token accounting in the history store joins that metering intent (J4, iss-2608220150157508; all three in draft itd-2609292107351737); the sources tooling moves into abcd's core with ingest and consult as abcd verbs (J5, iss-27, whose corpus half itd-76 already delivered), and the backfill of the placeholder source entries is part of that intent (J6, iss-55; both in draft itd-2609292108089653); the grill hands off to an installed external interview skill and falls back to its own (J11, iss-165, draft itd-2609292108373494); an opt-in local-model prompt sanitiser is planned (J14, iss-2608261543489261, draft itd-2609292109005937); decision-to-transcript links are planned, with the anchor kind and the link's home settled in the planning interview owed for draft itd-171 (J16, iss-2608290819228175); the dredge synthesis, its write-ups as their own memory source class, is planned together with draft itd-25, whose planning interview is owed (J19, iss-2609211905340006); one provenance register across ingest and vendoring is planned together with draft itd-26, whose planning interview is owed (J20, iss-2609211905346507); release retention, keeping the newest release per version line, is automated by planning draft itd-70 (J21, iss-282); a rules-backend seam with an opt-in CARL adapter is planned, the native loader staying the default (J22, iss-64, draft itd-2609292109214516); core-owned managed pre-commit gates are planned with draft itd-62 (J23, iss-84); a behavioural end-to-end scenario suite per verb family is planned (J24, iss-48, draft itd-2609292109475690). Every draft stays in drafts/ until a person plans it, and each source issue links its draft and names that planning interview in its deferral. BUILD: the teaching plane, the rules-loader safety domain generated from the hazard registry, is built as a lane, the registry being the single source (J10, iss-151 and itd-103; a code lane owns it). RULED DETAILS: `source_kind` carries both, as two separate labels, one for the tool and one for the route (J13, iss-2608230752354928); the prompt router's removal signal is the full list of active domains every time, a domain's absence meaning it has stopped (J15, iss-2608261550580260); setup offers an outside AI service (for example OpenRouter) at install, skippable, once the API adapter ships (J18, iss-2609081951416843, which waits on the API adapter); the salvage-hook timeout is 120 seconds, the wait must show a counter or a message while it runs and never stall silently, and every per-event timeout is pinned in a test (J25, iss-323). J13, J15 and J25 are carried by code lanes. CLOSE: the quick-tunnel preview protocol is closed unless the need recurs (J26, iss-2608230617385431, wontfix with that reason). PARKED ON A TRIGGER: agent payment protocols are kept under watch, not now, revisited as the protocols mature (J8, iss-138); the findings-only skill waits for the skill format to be versioned and stewarded (J9, iss-139); the disposition worksheet as an intent and a site page waits until after the first study (J17, iss-2609021815529020). DECIDE LATER: the Homebrew tap stays parked (J1, iss-380); pluggable search back ends (J7, iss-26); forge-backed record numbering (J12, iss-2608210737264758).
- dcn-26092900000000202026-09-29 — The product thinker answered the twenty-six Group J rulings (plan or close), J1 to J26 (recorded by lane recGroupJ of autonomous run A, for orchestrator abcd-fc). The answers are kept verbatim in the local-tier file `.abcd/.work.local/scratch/reports/rulings-answered-2609-29.md`, section "Group J", dated 2026-09-29, and are restated here because that file is not committed. PLAN: the installer script becomes a minimal starter with an ownership-checked hand-over, planned as a new intent with its planning interview owed (J2, iss-377, draft itd-2609292106557115); token metering and size classes are planned as one intent (J3, iss-2608301744251874 and iss-2608301856299268), and session token accounting in the history store joins that metering intent (J4, iss-2608220150157508; all three in draft itd-2609292107351737); the sources tooling moves into abcd's core with ingest and consult as abcd verbs (J5, iss-27, whose corpus half itd-76 already delivered), and the backfill of the placeholder source entries is part of that intent (J6, iss-55; both in draft itd-2609292108089653); the grill hands off to an installed external interview skill and falls back to its own (J11, iss-165, draft itd-2609292108373494); an opt-in local-model prompt sanitiser is planned (J14, iss-2608261543489261, draft itd-2609292109005937); decision-to-transcript links are planned, with the anchor kind and the link's home settled in the planning interview owed for draft itd-171 (J16, iss-2608290819228175); the dredge synthesis, its write-ups as their own memory source class, is planned together with draft itd-25, whose planning interview is owed (J19, iss-2609211905340006); one provenance register across ingest and vendoring is planned together with draft itd-26, whose planning interview is owed (J20, iss-2609211905346507); release retention, keeping the newest release per version line, is automated by planning draft itd-70 (J21, iss-282); a rules-backend seam with an opt-in CARL adapter is planned, the native loader staying the default (J22, iss-64, draft itd-2609292109214516); core-owned managed pre-commit gates are planned with draft itd-62 (J23, iss-84); a behavioural end-to-end scenario suite per verb family is planned (J24, iss-48, draft itd-2609292109475690). Every draft stays in drafts/ until a person plans it, and each source issue links its draft and names that planning interview in its deferral. BUILD: the teaching plane, the rules-loader safety domain generated from the hazard registry, is built as a lane, the registry being the single source (J10, iss-151 and itd-103; a code lane owns it). RULED DETAILS: `source_kind` carries both, as two separate labels, one for the tool and one for the route (J13, iss-2608230752354928); the prompt router's removal signal is the full list of active domains every time, a domain's absence meaning it has stopped (J15, iss-2608261550580260); setup offers an outside AI service (for example OpenRouter) at install, skippable, once the API adapter ships (J18, iss-2609081951416843, which waits on the API adapter); the salvage-hook timeout is 120 seconds, the wait must show a counter or a message while it runs and never stall silently, and every per-event timeout is pinned in a test (J25, iss-323). J13, J15 and J25 are carried by code lanes. CLOSE: the quick-tunnel preview protocol is closed unless the need recurs (J26, iss-2608230617385431, wontfix with that reason). PARKED ON A TRIGGER: agent payment protocols are kept under watch, not now, revisited as the protocols mature (J8, iss-138); the findings-only skill waits for the skill format to be versioned and stewarded (J9, iss-139); the disposition worksheet as an intent and a site page waits until after the first study (J17, iss-2609021815529020). DECIDE LATER: the Homebrew tap stays parked (J1, iss-380); pluggable search back ends (J7, iss-26); forge-backed record numbering (J12, iss-2608210737264758).
- dcn-26101400000000032026-10-14 — Before 1.0 only the newest release is offered: the product thinker ruled, after the v0.14.1 cut, "We don't want to offer them prior to 1.0", choosing "Only v0.14.1" over the recorded newest-per-line rule (brief, launch chapter; draft itd-70), which would also have kept v0.13.4, v0.12.0 and v0.11.1. The eight earlier GitHub Releases (v0.14.0, v0.13.4, v0.13.3, v0.13.2, v0.13.1, v0.13.0, v0.12.0, v0.11.1) and their assets were deleted by hand that evening; their tags and the git history stay, so each is still buildable from its tag. Automating the removal at every cut, and changing the recorded rule to match, is iss-2610141938299842 ("auto remove previous ones"); iss-282 holds the older newest-per-line executor gap. Not chosen: newest per line, which keeps older builds on offer.
- iss-194Release retention is documented in the present tense but has never run: the newest-per-line policy in brief/04-surfaces/04-launch.md:134 and the release glossary entry describe pruning as operating behaviour, and internal/core/launch/retention.go:30 implements it exactly, but nothing executes it. internal/core/launch/ship.go:41 stops before the network ('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 at all. The brief's own phase note schedules the prune as itd-70, unshipped. Same implemented-but-never-run class as iss-183, and found the same way: by reading the record against the live surface. Live evidence, 2026-08-07: six releases exist; the real preview keeps v0.1.0, v0.2.0, v0.3.0, v0.4.2 and would prune v0.4.0 and v0.4.1, so the repository's own release list contradicts the prose. Scope here 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 by this item. Maintainer disposition (2026-08-07): v0.4.0 and v0.4.1 are deliberately left in place rather than pruned by hand, so itd-70 has a live fixture to exercise on arrival — the first real prune should be the shipped mechanism's, not a manual one. Related observation, possibly separable: internal/core/launch/dryrun.go:126 discards the error from GitExistingTags, 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 in a shallow clone during this investigation before tags were fetched.
- iss-2608271804188295drafts/itd-70 is a machine-emitted stub, not a press-release intent: no press release, no scope, no acceptance criteria, and a provenance line citing spc-75 which exists nowhere (iss-239's class). The drafts lint sanctions its frontmatter shape, so the only defensible action is editorial — flesh it into a press release before anyone plans it, or delete it and let open iss-194 carry the release-retention concern.
- iss-2610150749053362Several draft intents carry H1 titles that read badly now that the out-of-scope drafts index is generated from each record's H1: itd-70's H1 is the placeholder 'Drawn-out intent', itd-2610070544145422's H1 is cut off mid-sentence ('…and it just works: the'), and eleven drafts have paragraph-length H1s of 300 to 1,093 characters (for example itd-2609150819440345 and itd-149).
- itd-61A Human Edit To The Brief Cannot Commit Until Its Implied Intents And Principles Are Drawn Out And Reconciled
- itd-72Publishing A Release Is One Atomic, Refusable `ship`
- itd-108The plugin installs from the curated release artifact, not the repo, and every cut release reaches users automatically