Audit CI work reuse and release publication ordering across WrightKit

[Teakowa]

Goal

Reduce avoidable CI work across WrightKit without weakening correctness gates, and establish a release publication contract in which public release visibility follows successful verification of the exact release revision and its required artifacts/distribution outputs.

Context

WrightKit Rust repositories increasingly combine shared rust-quality jobs with repository-specific compatibility, corpus, integration, packaging, and release jobs. Several of those jobs invoke Cargo again for the same revision and compatible build configuration, while the existing shared cache primarily helps across runs rather than making one workflow run reuse work already produced by another job.

Release workflows also do not currently share one consistent promotion boundary. Repository publication can run independently from the main CI result for the same revision, and some flows make a GitHub Release public before the required R2 publication has completed.

The desired organization-level ordering is:

avoid work -> cheap correctness gates -> reuse compatible results/artifacts -> expensive integration/build/package -> verify distribution -> publish/promote

CI should additionally follow these build/reuse invariants:

• A build output with the same effective build identity should be produced once per workflow revision and consumed by downstream jobs as a current-run artifact/result instead of being rebuilt.
• Dependency/download caches and compatible compiler/build caches should be reused across jobs and runs when doing so is cheaper than reconstruction.
• Cache reuse and current-run artifact reuse are different contracts: caches accelerate reconstruction, while artifacts/results prove the exact output produced for the current revision.
• Reuse is bounded by build identity. At minimum, revision/source inputs, dependency lock state, Rust toolchain/compiler identity, target, profile, feature/configuration set, relevant compiler flags/environment, and other material build inputs must not be silently crossed.
• Incremental/intermediate build state may be reused only when its measured benefit exceeds restore/save/storage cost and its identity is safe; caching an entire target/ tree is not the default goal.

Different Rust toolchains, targets, profiles, feature sets, or other compilation inputs are not interchangeable merely because they belong to the same commit.

Scope

• Audit current CI and release workflows for WrightKit's actively developed Rust repositories, beginning with wright, workshop-rs, opy-rs, deltin-rs, and shared .github workflows.
• Identify repeated work for the same revision and compatible build identity, including repeated Cargo compilation across quality, compatibility, integration, scenario, corpus, smoke, and release gates.
• Define the effective build identity required before a current-run binary/library/package artifact may be reused by another job.
• Make compatible current-run build outputs single-producer/multi-consumer by default; retain independent rebuilds only where a different build identity or a concrete build-process failure mode requires them.
• Distinguish cross-run dependency/build caching from same-run result/artifact reuse; do not treat restoring an older cache as equivalent to reusing output produced earlier for the current revision.
• Define the smallest safe Rust cache policy for Cargo registry/git dependencies and compatible compiled dependency/intermediate state, including cache writer ownership, restore-only consumers, invalidation inputs, and storage bounds.
• Measure whether Rust incremental/intermediate workspace build caching materially improves hosted CI before standardizing it; do not preserve large incremental caches without evidence that restore/save cost is lower than recompilation.
• Identify cases where one job can consume a current-run artifact/result or be co-located with its producer instead of rebuilding the same target.
• Identify duplicate workflow execution for the same revision where an authoritative successful gate can be consumed rather than recomputed.
• Define release gating so publication for a release revision cannot outrun the authoritative CI/correctness evidence for that same revision.
• Define release staging/promotion so required native/provider artifacts are built, packaged, checksum-verified, published to immutable R2 versioned paths where applicable, and publicly verified before the corresponding GitHub Release is made public.
• Keep mutable latest pointers from exposing a partial/unverified release; their exact promotion point must preserve the repository's canonical release/provenance contract.
• Create repository-local executable follow-up Issues only for changes supported by the audit evidence; keep repo-specific gates and artifact logic in their owning repositories.
• Change shared .github workflows only for behavior demonstrated to be a stable cross-repository pattern.

Non-goals

• Removing or weakening meaningful tests, compatibility evidence, corpus/real-project gates, package smoke tests, or supported target coverage solely to reduce runtime.
• Sharing compiled outputs across incompatible Rust toolchains, targets, profiles, feature sets, lockfiles, revisions, compiler flags, or other material build inputs.
• Treating a global build cache as a substitute for exact current-revision verification.
• Uploading/restoring an entire Rust target/ tree by default when transfer/storage cost exceeds the work avoided.
• Forcing Rust incremental compilation in CI merely because Cargo supports it; incremental state must justify its storage and transfer cost with measured hosted-runner savings.
• Introducing sccache, remote build infrastructure, self-hosted runners, or another CI service without evidence that simpler GitHub Actions reuse is insufficient.
• Moving repository-specific release/build logic into .github merely to centralize YAML.
• Building an arbitrary-command reusable CI DSL.
• Redesigning versioning, release-plz/release-please product behavior, or distribution channels beyond what is required to establish correct gating/reuse/publication ordering.

Acceptance criteria

• The audit records the current workflow/revision evidence used for each repository and identifies repeated work by concrete producer/consumer jobs rather than by YAML similarity alone.
• Every proposed reuse path states the compatible build identity it relies on; incompatible toolchain/target/profile/feature/configuration work remains independent.
• For a compatible build identity within one workflow revision, one producer builds the required output and downstream consumers reuse that exact current-run artifact/result unless an independent rebuild requirement is documented.
• Cargo dependency downloads are not repeatedly fetched when a compatible dependency cache can safely satisfy the job.
• Compatible compiled dependency/build cache state is reused where measurements show a net benefit, with bounded writers and cache keys covering material build inputs.
• Rust incremental/intermediate workspace caching is either adopted with before/after evidence showing net wall-clock benefit or deliberately omitted with evidence that transfer/storage/reuse characteristics do not justify it.
• Same-revision duplicate Cargo work is either removed/reused where worthwhile or retained with a concrete independent failure mode/cost justification.
• CI caching distinguishes stable cross-run cache population from current-run build/result reuse and prevents untrusted/partial PR work from becoming an authoritative shared baseline.
• Release publication cannot proceed for a revision whose authoritative required CI gates have not succeeded.
• For repositories with R2-backed release distribution, required immutable versioned artifacts/checksums are published and publicly verified before the GitHub Release becomes public.
• Failed build/package/R2 verification does not leave a newly public GitHub Release representing a complete release.
• Mutable latest pointers cannot expose an incomplete artifact set and remain consistent with the repository's canonical public release state.
• No meaningful correctness, compatibility, real-project, package, or supported-platform evidence is removed merely for speed.
• Concrete implementation work is represented by repository-owned follow-up Issues; shared workflow changes are limited to patterns demonstrated across more than one repository.

Dependencies / ownership

• wrightkit/.github: cross-repository CI/release policy and reusable workflow contracts only.
• Each repository owns its quality/integration gates, binary/provider packaging, R2 object namespace, and release-specific publication behavior.
• Existing distribution contracts remain authoritative unless a repository-local follow-up explicitly supersedes their publication ordering.