Publish reviewed GitHub Releases to crates.io using shared tooling #259

Goal and prerequisite

Publish the la-stack crate to crates.io automatically after a reviewed, stable GitHub Release is published, using this repository's own deployment workflow and an exact published shared-tooling pin.

Target the approved la-stack v0.5.0 release, replacing the previous v0.4.7 release plan. Configure and verify the publishing workflow before that release; close this issue only after the approved release is successfully published and its crates.io availability is verified.

Shared capability: acgetchell/research-repo-tools#50, delivered in the published research-repo-tools v0.1.8 release. The native GitHub blocker records that capability prerequisite. Coordinate the workflow with the exact published shared-tooling pin adopted through #276, which targets research-repo-tools v0.1.9 for la-stack v0.5.0. Package publication and consumer adoption retain their separate acceptance gates.

Verified current surface and local requirements

The current workflow inventory has no crates.io publishing job. .github/workflows/release-benchmarks.yml is dispatched manually for release benchmark assets. The root Cargo package is la-stack; the workspace also contains benches/comparison, with the root as its default member.

• Select the la-stack crate explicitly; do not accidentally publish the benchmark comparison workspace member.
• Preserve exact/interval/linear-form feature and numerical validation policy in this repository.
• Confirm the published version is visible before downstream delaunay releases requiring that version proceed.
• Keep existing shared-maintenance adoption Replace duplicated maintenance tooling with research-repo-tools #254 and review-command adoption Adopt shared CodeRabbit review commands from research-repo-tools #255 scoped independently; reuse their results rather than expanding or reopening them.

Implementation and ownership

• Adopt the published common release-validation contract and consumer workflow template. Keep workflow triggers, publisher registration, environment approvals, Actions permissions, crate selection, Cargo packaging/publishing commands, feature/MSRV/platform tests and scientific release policy here.
• On the reviewed stable release: published event, verify repository identity, immutable tag/commit identity, default-branch ancestry, tag/package version and release-note consistency, and required successful checks for that exact commit. Reject draft/prerelease or mismatched events; missing/failed/pending checks are not success.
• Configure crates.io Trusted Publishing with the reviewed repository/workflow/environment identity and the minimal OIDC job permissions. Follow current upstream setup/first-publication requirements. Record the actual configured publisher/environment evidence; committed YAML alone does not prove account settings are applied.
• Use native Cargo package verification/dry-run before a guarded upload. Explain source/artifact identity honestly rather than assuming the PyPI build-once transfer model. Serialize publication for a crate/version and handle retries, already-published versions, partial upload success and registry-index delays explicitly. Never move a published tag or blindly retry an upload after a visibility timeout.
• Document routine Just/release commands, manual recovery and registry verification; remove only the generic duplication actually replaced by the published shared contract.

Acceptance criteria

• Published research-repo-tools v0.1.8 or a later compatible exact pin and lockfile are adopted; no sibling checkout or unpublished-package dependency.
• Repository-owned workflow passes action/security checks and handles rejected events, wrong tag/version/commit, missing or failing checks, unavailable dependencies, and reruns without publishing during PR tests.
• Required native Rust/platform checks and clean package dry-run pass for the release commit; repository scientific and feature coverage is retained.
• Trusted-publisher identity, environment restrictions/approvals and permissions are configured and verified separately from the workflow source.
• The next approved release produces a successful workflow run and the expected crates.io version; verify registry availability and a clean downstream resolution/install as appropriate. Do not publish a throwaway version merely to test automation.
• Record release tag, commit, workflow run and registry evidence in this issue, including any failure/recovery. Closing the issue requires verified publication, not just merged YAML or a published GitHub Release.

References: Cargo publish behavior and crates.io Trusted Publishing.