This is the record of an abcd-managed repository

abcdBetav0.16.2 · 2026-11-06

Development record

Publishing A Release Is One Atomic, Refusable `ship`

intentsupersededmajorstandaloneitd-72

Superseded by adr-37 on 2026-09-20, on the product thinker's ruling: publishing moved into CI behind the changelog-driven gate (adr-37), versions are derived (adr-31) and the semantic gate runs before the tag (adr-52), so every criterion here is met in another shape or moot; a review on 2026-09-20 found no criterion still open.

Retroactive intent record for spc-80. spc-80 builds the Tier B (publishing) half of the itd-67 consolidated PRD — see itd-67, whose grilled PRD defines both tiers. This record exists so the spec resolves to an intent under planned//shipped/; the two-key grandfather marks that it did not pass through its own grill (the grilled provenance lives on itd-67).

Press Release

abcd publishes a new plugin release with one command — or refuses, loudly. ship computes the bump tier from the last launch baseline, writes the version and changelog into the curated release, prunes superseded payload files, stages the delta for confirmation, and then publishes branch + tag atomically. If nothing changed, it refuses. If the repo is not the one it expects, it refuses. If the push fails, nothing half-lands: a recoverable marker preserves the local commit and main is never force-reset.

Why This Matters

Tier A (itd-67) makes the abcd repo installable and versioned; without Tier B every subsequent release is a hand-run of renders, bumps, changelog edits, prunes, and pushes — each a chance to publish a half-state. The release is a single-repo curated cut from packaging (adr-28), not a mirror push. ship makes that cut a single audited act with every safety refusal built in.

What's In Scope

  • Bump-tier computation from the .launch/launch-report.json baseline (phase-complete since baseline → minor; otherwise patch; explicit --version always wins and is the only major path)
  • First-release bootstrap: an absent baseline seeds v0.1.0 and prepares the initial baseline record
  • No-change refusal on the canonical pre-bump payload digest (--force to override)
  • Repo identity check (marketplace name, plugin name, remote slug, protected branch) before any write
  • Overlay write + tracked-manifest prune, payload-scoped only, with traversal/symlink-escape defenses
  • Auto-changelog from git tags + the launch report, idempotent
  • Staged-delta confirmation, non-TTY refusal without --yes
  • Atomic branch+tag push or fail-closed with a recoverable failed-release.json marker; stale-verdict revalidation immediately before promotion

What's Out of Scope

  • The payload resolution itself (spc-78's render manifest is consumed, never re-derived)
  • The pre-flight gate suite (spc-79 owns it; ship invokes it)
  • Release retention pruning of prior tags/Releases (itd-70)

Scope Conditions

None stated.

Acceptance Criteria

BDD format, per itd-1-acceptance-gates. These gates are checked by intent-fidelity-reviewer when this intent moves to shipped/.

  • Given no baseline exists in the repo, when ship runs, then the seeded version is v0.1.0, every surface is treated as added, and the initial baseline record is prepared.
  • Given the pre-bump payload digest equals the baseline's, when ship runs without --force, then it refuses as a no-change release and publishes nothing.
  • Given the repo's marketplace name, plugin name, remote slug, or protected branch does not match the launch config, when ship runs, then it refuses before any write.
  • Given a prune entry resolving outside the payload root (absolute, ..-traversal, or symlink escape), when the overlay+prune stage runs, then the entry is rejected and nothing outside the payload root is deleted.
  • Given --publish in a non-TTY session without --yes, when ship reaches confirmation, then it refuses to publish.
  • Given the atomic branch+tag push fails partway, when ship exits, then the protected branch is never force-reset and a recoverable failed-release.json marker preserves the local release commit.
  • Given the gate verdict was computed against different manifest bytes or git state, when ship revalidates immediately before promotion, then the stale verdict is rejected and nothing is pushed.

Audit Notes

Populated by intent-fidelity-reviewer when intent moves to shipped/.

Frontmatter

iditd-72
typeintent
lifecyclesuperseded
kindstandalone
severitymajor

References4

Referenced by2

mentions9