🏗️ [architecture] [Release checkpoint 1] Decide the shared preparation engine and authority boundary #94

Roadmap-Key: REL-01
Program: egohygiene/.github#20
Parent: #93
Phase: 1 — decision

Outcome

Produce a small, reviewable decision record for the organization's common release-preparation engine and its integration with the existing Relay publisher. This is the first checkpoint to start in a fresh chat.

Entry conditions

• No new implementation prerequisite. Start with a read-only reconciliation of existing work.

Bounded scope

• Reconcile Aether spec(releases): define the organization-wide semantic release and changelog contract #61/🧭 Define the shared release-preparation, component-version, and prerelease model #93, Hygiene ADR-007/feat(skills): curate core first-party engineering skill suite #27, Relay chore(tasks): wrap skill publish workflows #47/Publish an opt-in confidential research skill bundle #71, the central app's release-please files, and the current Renderflow/OptiFlow release paths. Reuse live evidence; implementation, released availability, consumer pins, and ratification are different states.
• Compare release-please manifest mode, semantic-release, and Changesets against mixed-language projects, human review, independent/linked units, changelog format, prerelease needs, maintainability, and available local/offline planning. Keep this a compact decision, not a new framework.
• Evaluate release-please in PR-only mode with Relay as the sole selected tag/GitHub Release publisher. Verify upstream behavior and use a minimal synthetic compatibility probe for the risky assumptions: external tag/manifest reconciliation, changelog shape, and bot-created PR checks. Record any unproven condition honestly.
• Document who computes the proposed bump, where the authoritative version lives, what a merged release PR means, and what explicitly authorizes publication. Identify the smallest alternative if the recommended adapter cannot meet those boundaries.
• Deliver one proposed ADR with a decision table, exact relevant upstream references/versions, a file-role sketch, exceptions, open questions, and the next contract checkpoint. Explain it in plain language for maintainer review.

Acceptance evidence

• One recommended default and its exceptions are clear; release-please remains a candidate until the decision is reviewed.
• The choice accounts for the existing exact [Unreleased] requirement and the source of release semantics after PR merge.
• Tag ownership, manifest state, retries, authentication/event limitations, and local-versus-network operations have an explicit fit/gap assessment.
• No source pipeline, tag, package, policy-approval field, or published asset is silently changed; the next action is the linked contract checkpoint.

Boundaries

Do not implement the adapter, migrate repositories, choose every distribution channel, or mark a policy accepted on behalf of the maintainer. Keep the deliverable to one bounded decision/probe PR.

Reuse and related work

• Define the canonical commit, pull-request title, and change-history contract hygiene#37 — canonical commit/PR-title semantics; the history-rewrite proposal is outside this checkpoint.
• feat(releases): observe organization release-convention adoption and drift pace#17 — read-only adoption inventory can inform the decision without blocking it.
• https://github.com/egohygiene/egohygiene/issues/284 — existing app release-please/commit integration.

Checkpoint execution and handoff

Work one bounded checkpoint at a time. Read the applicable AGENTS.md, canonical architecture/decisions, and CONTINUITY.md; verify live issue, producer, branch, and PR state before editing. Preserve work already in flight. If this cannot fit one reviewable PR, record a smaller linked checkpoint before implementation rather than running an unbounded session.

Record exact source/pin versions, checks and their results, remaining gates, the saved branch/PR, and the next dependency-ready issue. Save partial work as a branch/draft PR when useful. Use reference-only issue links while acceptance gates remain; do not treat a merged PR as proof of publication. Pause for review after the checkpoint. Read the roadmap before choosing the next task.

This roadmap authorizes planning. A later implementation request authorizes its selected scope; it does not by itself authorize merging, creating tags/releases, deploying, registry publication, changing credentials, rewriting history, or overwriting immutable evidence. Publication follows the repository's separately approved release boundary.