feat(distribution): roll out the universal tool distribution profile across eligible repositories

[szmyty]

Outcome

Use Pace to adopt, reconcile, and maintain the Hygiene universal distribution profile across every eligible Ego Hygiene CLI/tool repository without copying packaging/release implementations into each consumer.

The fleet goal is that an eligible tool declares one distribution contract, consumes versioned Relay mechanics, and exposes current installability evidence across the platforms/package managers it actually supports.

Architecture

Hygiene applicability policy
        ↓
Aether distribution declaration
        ↓
Relay reusable build/publish/install verification
        ↓
Pace discover → plan → apply → verify → reconcile
        ↓
consumer repositories
        ↓
Observatory fleet distribution status

Pace owns adoption and drift. It does not own release policy, publisher credentials, package registries, or reusable workflow implementations.

Inventory and classification

Discover organization repositories/components and classify them as:

• distributable CLI/tool required;
• distributable CLI/tool recommended;
• language-package-only;
• container-distributed;
• application with a different distribution profile;
• internal/private only;
• archived;
• not applicable;
• blocked pending package identity/account/credential setup.

Do not infer eligibility solely from implementation language.

Current-state discovery

For each eligible component, detect existing:

• GitHub release artifacts;
• cross-platform build matrices;
• Homebrew formula/tap;
• Debian/RPM packages;
• AUR packages;
• Snap;
• Scoop/Chocolatey/WinGet manifests;
• crates.io/PyPI/npm publication;
• OCI images;
• portable install scripts;
• checksums/SBOM/signatures/provenance;
• install/upgrade/uninstall docs;
• package-manager accounts/namespaces and symbolic publisher bindings where declared;
• release workflow ownership and copied-vs-Relay implementation.

Classify each channel as current, partial, legacy, copied, unverified, blocked, or absent rather than blindly replacing it.

Rollout behavior

For each repository:

1. consume the approved Hygiene profile version;
2. create or reconcile the Aether distribution declaration;
3. preserve existing valid package names/coordinates;
4. install thin, pinned Relay workflow integration;
5. migrate duplicated package/release mechanics to reusable Relay adapters where safe;
6. preserve repository-owned GitHub environments/secrets and publication authority;
7. generate a preview plan before changes;
8. run build/package/install verification;
9. publish Observatory-compatible adoption/drift evidence;
10. retain rollback instructions.

Pace must never fabricate registry accounts, package names, credentials, or ownership.

Canary sequence

Use a staged rollout rather than organization-wide mutation on day one.

Recommended canaries:

1. Renderflow — broad Rust/platform/package-manager surface already exercising Homebrew, Scoop, Chocolatey, Snap, AUR, Debian/RPM, etc.;
2. one smaller Rust CLI/tool such as Mantle or Identity;
3. one Python CLI/package once Relay's Python release profile is ready;
4. optionally one tool with OCI/container distribution to prove a materially different channel.

After canaries, generate the fleet rollout plan and dependency order.

Drift and conformance

Detect drift such as:

• repository declaration behind approved Hygiene/Aether version;
• copied workflow replacing approved Relay integration;
• expected channel missing;
• package manager publishing an older/newer version than the reviewed release;
• unsupported target still advertised;
• package/install evidence stale;
• publisher adapter version behind approved baseline;
• package coordinate/account binding changed unexpectedly.

Drift should produce a reviewable remediation plan, not an automatic destructive overwrite.

Relationship to repository-specific release work

Existing mature repositories may keep product-specific package metadata where it is truly necessary. Pace should consolidate mechanics, not erase meaningful package-manager conventions.

Renderflow's existing release/distribution work should become a canary/input to the universal system rather than being discarded.

Acceptance criteria

• Pace inventories every repository/component for distribution-profile applicability.
• Existing package channels and release automation are classified before mutation.
• Renderflow plus a second Rust tool and a Python tool prove the rollout across different cases.
• Consumer repositories use thin, version-pinned Relay integration where supported.
• Existing package coordinates and publisher authority are preserved unless explicitly migrated.
• Preview → apply → verify → rollback behavior is defined.
• Missing package-manager accounts/credentials become explicit blockers rather than invented values.
• Profile, declaration, Relay adapter, and published-version drift are detectable.
• Unsupported and not-applicable channels do not appear as failures.
• A machine-readable fleet adoption snapshot feeds Observatory.
• A prioritized rollout plan is produced for all remaining eligible repositories after canaries.

Dependencies

• policy(distribution): define the universal tool distribution and native-installability profile hygiene#29
• spec(distribution): extend release declarations with distribution targets, package coordinates, and publisher bindings aether#63
• feat(distribution): publish reusable cross-platform build, package-manager, and install-verification matrix workflows relay#48
• distribution observability: feat(distribution): publish fleet package availability, version, and installability dashboards observatory#13

Non-goals

• Automatically publishing unreleased versions while reconciling repositories.
• Moving package-manager credentials into Pace.
• Replacing repository-specific metadata that package ecosystems legitimately require.
• Treating every repository as a CLI distribution candidate.