Make rolling release publication transactional or consumer-fail-closed

[mark-e-deyoung]

Problem

The current rolling publisher mutates the public channel in this order:

1. move semper-exp-current tag to the new candidate SHA;
2. delete every asset from the existing release;
3. edit/create the release;
4. upload new manifest/checksums/binaries;
5. run the credential-free verifier.

This produces an externally visible mixed-state window even on a successful run. After step 1 the tag identifies the new candidate while release assets can still represent the prior candidate. During steps 2–4 the rolling release can expose zero or only a subset of the required assets. If publication fails part-way, the verifier detects failure only after the public channel has already been mutated.

Goal

A consumer resolving the rolling channel should either see a complete internally consistent candidate or fail closed. It should not be able to accept a manifest/binary/tag combination assembled across candidates.

Required design decision

Choose the smallest robust publication protocol. Evaluate approaches such as:

• stage the complete candidate under an immutable candidate-specific tag/release, verify it, then promote a lightweight rolling pointer;
• publish a candidate-specific immutable manifest/assets first and make the rolling channel only reference that verified immutable candidate;
• if GitHub Release mechanics prevent an atomic pointer swap, explicitly define the rolling endpoint as eventually consistent and make every consumer verify one immutable candidate identity before downloading artifacts, with retries/fail-closed behavior during transitions.

Do not claim the current delete/upload sequence is transactional.

Acceptance

• no consumer can successfully accept a manifest whose source SHA differs from the artifact identity it downloads;
• the rolling tag/ref, manifest source SHA, binary names/hashes, and source snapshot resolve to one candidate;
• a publisher failure at each mutation stage has a documented/reproducible recovery path;
• failure does not silently leave the prior candidate mislabeled as the new one;
• consumer tooling detects transition/incomplete state and retries or fails closed rather than executing an ambiguous artifact;
• rollback to the prior verified candidate is explicit and reproducible;
• no private validation material is involved.

Related

• Harden experimental publisher: make release mutation push-only #2: release mutation is push-only.
• Serialize rolling publisher so older pushes cannot overwrite newer candidates #3: superseded publishers cannot overwrite newer candidates.
• Verify and enforce protection on the release-triggering candidate branch #4: authority to push the release-trigger branch is governed.
• Fix rolling release notes provenance: avoid shell command substitution #7: human release-note provenance must be correct.

This issue addresses atomicity/consistency of the public publication transaction itself.

[mark-e-deyoung]

Concrete historical failure evidence — current 71c69952… channel

This issue is not only theoretical. The push workflow for candidate 71c69952f22d098da4ed2380d93f429bd43f088b had all three producer jobs pass, then the write-capable publisher failed after mutating the release:

• artifacts downloaded successfully;
• manifest/checksums generated successfully;
• release-note heredoc emitted multiple command not found errors from Markdown backticks (tracked separately in Fix rolling release notes provenance: avoid shell command substitution #7);
• rolling release/tag mutation proceeded;
• gh release upload then failed with HTTP 404 on the release asset upload endpoint.

A later pull_request workflow rerun succeeded in republishing the binaries because PR publication was still allowed at the time. The source-snapshot workflow, however, intentionally waited for a successful push workflow and timed out, so the current live release has no custom source archive.

This creates a useful failure-injection case for the eventual transactional/fail-closed design: simulate or handle failure after tag/release mutation but before/while uploading the new asset set, and prove recovery cannot leave an ambiguous channel.

The public repository/tag still provides source history and GitHub-generated archives, so this note is about the explicit SemperSupra rolling-source-snapshot contract rather than asserting a GPL violation.