Development record
drafts/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.
issueopennitpickiss-2608271804188295
drafts/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.
Remedy grounds (2026-09-29)
- J21 rules to plan itd-70, so deleting the draft is off the table and the remaining work is the fleshing the planning interview performs; iss-194 has resolved, leaving iss-282 as the open carrier the press release draws from.
- No outside-practice check: an editorial repair of an internal record.
- Rejected: deleting the draft, which the J21 ruling overtakes.
Frontmatter
| id | iss-2608271804188295 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | nitpick |
.abcd/work/issues/open/iss-2608271804188295-itd-70-is-a-machine-emitted-stub-not-a.md
open on GitHub ↗ · commit history ↗
mentions4
- 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-239Dangling pre-rebuild spec ids in the draft corpus: itd-44 (spc-56), itd-51 (spc-33/37), itd-57 (spc-48/60/62), itd-61 (spc-75) cite specs from the numbering adr-21/adr-26 reset (live store is spc-1..spc-22). Worse, intents/README.md and itd-34 assert the itd-44 lineage 'landed as itd-44 (spc-56 thin adoption)' — no such spec or decision-verdict code exists, so the record claims a delivery the tree cannot back.
- 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 out
- itd-70Drawn-out intent