program(releases): track organization-wide semantic release convention rollout #20

September 28 current execution roadmap

Start here: egohygiene/aether#94 (REL-01). Work one checkpoint, save the result, and pause for review. This plan builds on the original program below; its current ordering supersedes the older foundation rollout order. The term “semantic release” here describes the system, not a preselected npm tool.

The roadmap issue batch changes planning only. The proposed default is reviewed preparation through release-please manifest mode, with Relay as the selected publisher, subject to the first decision checkpoint. No policy approval, implementation, release, merge, or fleet migration is implied by creating these trackers.

1. Decide and specify the common model

Aether #61, Hygiene #27, and Relay #47 are completed foundations. Inspect and extend their actual outputs; do not redo them or assume closed trackers mean a draft/proposed policy is ratified. Hygiene #37 owns the relevant conventional-commit/emoji/PR-title semantics. Historical commit normalization is outside this roadmap.

2. Implement the shared core

After the model is accepted, validator and Realm tooling work can proceed when their own inputs are ready. The first execution path is REL-01 → REL-02 → REL-03 → REL-04 → REL-05. Existing EgoLint #29/#68/#69 work remains its own v1 chain; REL-06 adds the accepted successor without hijacking it.

3. Prove and deliver the file family

Then complete #19 as the thin starter/onboarding surface pointing to the canonical baseline. Required/conditional files include the release declaration, changelog(s), Taskfile handoffs, pinned shared workflows, applicable commit references, and adapter config/tracking files only when selected. Empathy proves composition; Holon materializes; neither owns a second release engine.

4. Reuse the existing consumer pilots

Choose one relevant, ready pilot at a time after its compatible producer pins and baseline are available. Existing accepted v1 work may finish independently; reconcile it before adding successor-contract changes.

For the first usable core milestone, prove a Rust and a Python consumer plus a mixed-component fixture. Mark publication readiness separately from actual publication. Additional profiles graduate independently; the broader homelab, every registry, and every native channel are not core blockers.

5. Expand distribution with measured support

Policy and declaration prerequisites already exist: egohygiene/hygiene#29 → egohygiene/aether#63. The distribution parent is egohygiene/relay#48.

The first native channel sequence is Homebrew, Debian/APT, RPM-family, then a Scoop Windows reference, adjusted only by an explicit applicability decision. Each is an independent checkpoint after the common inputs; a blocked account or runner for one channel must not stall another ready channel. Use egohygiene/renderflow#419 as product-owned Renderflow qualification, and a smaller eligible Rust plus Python canary to prove reuse. Packaging recipes alone do not establish published support.

The full extension queue remains in Relay #48: language registries, OCI, WinGet, Chocolatey, AUR, Alpine/APK, Snap, Nix, additional architectures, and upstream-distro submissions where desired. Each selected extension gets one bounded owner checkpoint before coding. These are visible backlog choices, not hidden prerequisites or promises of universal acceptance.

6. Observe and adopt across the organization

• feat(releases): observe organization release-convention adoption and drift pace#17 — read-only release/applicability inventory; can start now and remains separate from mutation.
• 🗺️ [Release checkpoint] Roll out the proven release baseline one repository at a time pace#32 — reviewed release-baseline adoption, one consumer PR at a time, only after the applicable pilot is proven.
• feat(distribution): roll out the universal tool distribution profile across eligible repositories pace#19 — optional distribution-channel rollout after per-channel canary evidence.
• feat(distribution): publish fleet package availability, version, and installability dashboards observatory#13 and Add organization-level /releases/ and /distribution/ views #39 — distribution read model and organization views; consumers of evidence, not publishers or prerequisites for the first release.
• feat(tooling): consume Ego Hygiene tools from verified release and package-manager channels realm#19 — a real environment consumes released packages through declared channels and verifies exact versions.

Each active catalog row eventually receives an explicit profile, adoption result or blocker, and channel applicability decision. Unknown, not-published, experimental, stale, blocked, and not-applicable remain first-class states. The README matrix is generated from evidence, with details linked rather than copied into a large README.

Independent, smaller naming lane

egohygiene/relay#71 → egohygiene/optiflow#115. Relay source already includes part of this change; publication of the producer contract and the consumer's exact repin must be verified separately. This can proceed without completing the broad system, but does not waive OptiFlow's egohygiene/optiflow#93 qualification or alter historical release evidence.

Definition of progress and stopping points

1. Model ready: a reviewed engine/authority decision, versioned contract, and honestly recorded policy status.
2. Core usable: shared preparation, channel handoffs, validator, applicable baseline/tooling, and the selected Rust/Python/mixed proof are verified against exact producer versions.
3. Distribution proven: only the selected channels with real release/install evidence become supported; unselected extensions remain explicit.
4. Adoption complete: every applicable repository has a verified result or explicit approved exception/blocker; no arbitrary all-green requirement hides missing evidence.

After each checkpoint, record the issue/PR, exact revisions and checks, implementation versus publication state, blockers, and the next ready issue. Preserve partial work in a branch/draft PR before context is exhausted. Review/merge/publication follow their own authority; issue closure requires its stated evidence. Do not start the whole graph in one chat or wait for unrelated optional channels.

Parent and dependency relationships are explicit links here and in each checkpoint. This batch did not create native GitHub sub-issue/dependency edges because that mutation is unavailable in the current connector.

Fresh-chat starting prompt

Start the shared release-system roadmap at #20. Work only on the first dependency-ready checkpoint, currently egohygiene/aether#94. Read the applicable repository agent guidance, canonical architecture/decisions, continuity handoff, and live linked issue/PR state before changing anything. Reuse completed work and preserve concurrent work. Produce one bounded, reviewable checkpoint, save its branch/PR and verification evidence, update the durable handoff with the next ready issue, and pause for review. Release-please is a candidate to evaluate, not an already-ratified choice. Do not infer authority to merge or publish from the roadmap.

Original foundation scope retained for continuity

Outcome

Coordinate the one-PR-at-a-time rollout of the organization release convention without moving ownership away from individual repositories.

Workstream issues

• spec(releases): define the organization-wide semantic release and changelog contract aether#61 — spec(releases): define the organization-wide semantic release and changelog contract
• policy(releases): add the repository release-convention baseline profile hygiene#27 — policy(releases): add the repository release-convention baseline profile
• feat(releases): add Python package distribution to the reusable release profiles relay#46 — feat(releases): add Python package distribution to the reusable release profiles
• feat(releases): publish reusable semantic-release preparation and verification workflows relay#47 — feat(releases): publish reusable semantic-release preparation and verification workflows
• feat(releases): validate semantic release, changelog, and version-source conformance egolint#29 — feat(releases): validate semantic release, changelog, and version-source conformance
• chore(templates): seed the organization release-convention starter surface #19 — chore(templates): seed the organization release-convention starter surface
• feat(releases): observe organization release-convention adoption and drift pace#17 — feat(releases): observe organization release-convention adoption and drift
• ci(releases): pilot the Python package release convention mindgarden#27 — ci(releases): pilot the Python package release convention
• ci(releases): pilot the Rust CLI and binary release convention aniflow#10 — ci(releases): pilot the Rust CLI and binary release convention
• ci(releases): pilot the container-image release convention realm#17 — ci(releases): pilot the container-image release convention
• ci(releases): pilot the React application and static-site release convention egohygiene.io#17 — ci(releases): pilot the React application and static-site release convention
• ci(releases): pilot the publication and multi-component workspace release convention antidote#68 — ci(releases): pilot the publication and multi-component workspace release convention
• ci(releases): adopt the portable shell-tool release convention mantle#26 — ci(releases): adopt the portable shell-tool release convention

Existing release work to reconcile, not duplicate

• ci(release): validate and publish versioned first-party skill releases aether#13
• Harden, document, and release Identity v1.0.0 identity#18
• 🚀 Establish production-grade release and distribution pipeline renderflow#297
• ✨ Finalize publication UX, release automation, and repository readiness reflector#227
• egohygiene/egohygiene#284

Adoption registry

The Pace implementation must inventory every active repository and classify it before mandatory enforcement:

• Foundation and policy: .github, Aether, Hygiene, Relay, Egolint, Pace, Holon, Observatory, Sanctuary.
• Tools and environments: Mantle, Realm, AniFlow, OptiFlow, Beacon, Mindcap, Mindgarden, Flow, Athena, RenderFlow, Identity.
• Products and publications: egohygiene, egohygiene.io, Akashic, Antidote, Reflector, Store, Civics, Filament.
• Private, incubating, and archived repositories use an explicit applicability state; they are never silently excluded.

Rollout order

1. Aether contract; in parallel, Relay feat(reflector): bootstrap organization analysis engine #6 durable reports.
2. Hygiene baseline and Relay profile/mechanics.
3. Egolint validation and .github starter surface.
4. Python, Rust, container, web, publication, and shell pilots.
5. Pace read-only fleet adoption matrix.
6. Repository-owned remediation PRs for every remaining catalog row; only later consider Pace-authored PR proposals.

Program acceptance criteria

• Every active repository has a tracked release-profile decision and root changelog status.
• Every release-capable repository is validated against the same versioned contract.
• Every profile has at least one proven consumer before broad adoption.
• External distribution/deployment state is explicit and never faked by a GitHub tag.
• No release process relies on mutable action refs, force-updated immutable tags, or unreviewed automatic version rewrites.