Release standard: add crates.io publishing (currently npm-only)

[avrabe]

Sweep finding: rivet distributes via npm (5 platform packages) + VS Code Marketplace, with a fully-signed GitHub Release (cosign+SHA256SUMS+SBOM+SLSA) — but it does not publish to crates.io. Under the standard, every Rust tool is on crates.io as the canonical channel.

Track B — distribution (priority):

• Add a crates.io publish workflow (signed CI, OIDC trusted publishing) — keep the npm wrapper as the CLI channel.

Track A done; Track C N/A (rivet emits no wasm). Track E moderate (65/193 verifies) — improving rivet's own extraction is worthwhile but not part of this campaign's priority.

---

Part of the org-wide release-consistency campaign — the five-track standard is in the release-artifact-pipeline skill (plugin v0.10.0).
Coordination hub: pulseengine/pulseengine.eu#98 — if this standard does not fit this repo (you need a deviation, different sequencing, or want to sync on how a track applies), raise it there. Deviations are decided in the open at the hub, not diverged silently.

[avrabe]

Triage from the issue-fixing routine (new issue this run — first pass).

The body is a Track-B campaign slice with one checklist bullet but no explicit ## Acceptance Criteria block matching the kill-criterion shape the routine looks for (per #532). It's also explicitly cross-repo: the binding standard lives at pulseengine/pulseengine.eu's release-artifact-pipeline skill, the coordination hub is pulseengine/pulseengine.eu#98, and the body itself says "deviations are decided in the open at the hub, not diverged silently." Two consequences for this routine:

1. The agent can't unilaterally land this — both the standard (other repo, out of the routine's scoped repo list pulseengine/rivet) and the hub for any rivet-specific deviation are off-scope. Anything the routine drafts here would need a hub-side check before merge.
2. The crates.io OIDC trusted-publishing trust relationship is a maintainer-side credential action (configure the crates.io trust on the rivet crate listing, point it at this repo + the named workflow). The workflow YAML is the cheap half; the trust setup is the half only the maintainer can do.

The single bullet in the body is enough for a routine PR if you'd like it scoped down to just the workflow + dry-run shape. Sketch matching #532's kill-criterion (drop in or revise):

## Acceptance Criteria — crates.io publish workflow (Track B)
- [ ] `.github/workflows/release-crates.yml` is added, triggered on push of `v*` tags, uses **OIDC trusted publishing** (no long-lived `CARGO_REGISTRY_TOKEN` secret), runs on `ubuntu-latest` (GitHub-hosted — independent of the self-hosted pool per #509), and publishes the workspace's library crates in dependency order (`rivet-core` first, then `rivet-cli`; `cargo publish --dry-run` clean before the real publish).
- [ ] The workflow's `permissions:` block grants exactly `id-token: write` + `contents: read` — minimum needed for OIDC; no broader scope.
- [ ] The npm publish path (existing `release-npm.yml`) is unchanged — the npm wrapper stays the CLI install channel per the issue body.
- [ ] Tag → crates.io publish is **independent** of the binary release flow (failure of one does not block the other; matches the existing decoupling pattern from #545).
- [ ] On a dry-run (manual `workflow_dispatch`, or against a non-tag push with `--dry-run` forced), the workflow validates that both crates would publish cleanly — no missing `[package].description` / `repository` / `license` fields, no path-only deps that crates.io rejects, etc. Documented manually in the PR description if a real dry-run requires the trust relationship to exist first.
- [ ] CHANGELOG entry under "Changed" / "Added" describing the new publish channel; trailer `Refs: #557`.
- [ ] **Maintainer-side prerequisite (not in this PR — flag in PR description):** configure crates.io trusted publishing for `rivet-core` and `rivet-cli` to authorize `pulseengine/rivet`'s `.github/workflows/release-crates.yml` workflow on the `release-crates` environment.
- [ ] **Explicitly out of scope (file separately):** publishing pre-release / RC versions; auto-yanking on rollback; the npm-wrapper version-sync side (already handled per #533); Track A (signing — done) and Track E (verifies extraction — explicitly deprioritized per the body).

Two coordination items worth a one-line call before any branch opens:

• Crate set: the workspace has rivet-core, rivet-cli, and the schemas crate(s). Confirm which are intended to be cargo publish-able vs. internal — the PR description should enumerate them. (The body says "the npm wrapper as the CLI channel" but doesn't pin whether rivet-cli also publishes to crates.io as a cargo install rivet-cli path, or only rivet-core does. Both are defensible.)
• Hub-side ack: the body asks for deviations to land at pulseengine/pulseengine.eu#98. If the rivet take on Track B is "the workflow + a stable npm-first install posture" (i.e., crates.io publishes the libraries, npm stays the CLI install channel), worth a one-liner there so the standard's downstream consumers don't misread silence as drift.

Process side-rail (carried from every recent triage thread): https://pulseengine.eu/blog/ is still HTTP 503 — re-verified at the start of this run (curl -I → HTTP 503; bypassing TLS to look at the origin shows certificate has expired plus upstream connect error). Same long-standing site-infra symptom flagged across the last ~25 triage threads (#420, #422, #431, #436, #456, #468, #479, #482, #488, #490, #500, #508, #509, #516, #522, #523, #530, #532, #538, #543, #546, #547, #548, #549, #550, #552, #554, #555, #556). The binding workflow guidance can't be consulted, so any rivet-side PR would land as a draft pending blog access — consistent with the pattern on PRs #525, #537, #539, #541 (all opened draft against the same outage, merged after maintainer review). For #557 specifically, the other binding source — the campaign standard in pulseengine/pulseengine.eu — is also off the routine's scoped repo list, so the draft posture is doubly warranted.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-23.

---

Generated by Claude Code

[avrabe]

Investigated the crates.io path (modelled on synth's publish-to-crates-io.yml + scripts/publish.rs, org-wide CRATES_IO_TOKEN). Built the rivet-side mechanism end-to-end on a scratch branch and ran cargo package as the oracle — which surfaced a hard blocker: rivet's dependency graph is not crates.io-publishable.

crates.io forbids git and path dependencies; every dep must be a published, versioned crate. rivet-core/rivet-cli currently depend on three unpublishable sources:

1. etch — a local workspace crate (path = "../etch"). Would need to be published first (likely as rivet-sdlc-etch or similar; needs its own dep audit).
2. rowan — a git fork (pulseengine/rowan, branch fix/miri-soundness-v3). Per the Cargo.toml comment this is a permanent maintenance fork — upstream closed the Miri-soundness patches (fix(proofs): restore Validation.v import + replace Admitted with proofs #210/fix(tests/playwright): batch stale-test cleanups (5 of 10) #211/fix(verus): correct vstd lemma paths + matches!→is + lemma_div_multiples_vanish #212) UNMERGED and intends a full rewrite. So rivet can never depend on a stock crates.io rowan with these fixes; the fork would have to be published under its own name (e.g. pulseengine-rowan) or vendored.
3. spar-hir / spar-analysis — git deps pinned to pulseengine/spar tag v0.10.0. spar would need to publish these to crates.io.

cargo package -p rivet-sdlc-core fails immediately with dependency 'etch' does not specify a version and would fail the same way on rowan/spar. So the rename + workflow alone cannot ship a working publish — it's gated on cross-repo prerequisite work in etch, rowan (the fork), and spar.

Recommended sequencing (cross-repo, in order)

1. spar publishes spar-hir + spar-analysis to crates.io (or rivet makes the aadl feature default-off and the published crate excludes it — but aadl is in default, so AADL would be lost).
2. rowan fork published as a distinct crate (e.g. pulseengine-rowan) on crates.io, or vendored into rivet.
3. etch published (after its own deps are clean).
4. Then rivet: rename rivet-core→rivet-sdlc-core, rivet-cli→rivet-sdlc-cli (keep [[bin]] name = "rivet" + [lib] name = "rivet_core"), point the deps at the published versions, add publish-to-crates-io.yml + scripts/publish.rs (etch→core→cli order, 10× retry). Confirmed locally that this rename compiles and all tests pass — it's ready once the deps are publishable.

Until (1)–(3) land, crates.io publishing is not achievable from this repo. Keeping this issue open as the tracker; the rivet-side mechanism is understood and small.