[yaacovcorcos]

Scient Agent's releases skipped numbers: users went from 0.1.5 to 0.1.8. A release was a pushed v<version> tag, so the number was used up before the build was qualified. v0.1.6's run failed (Oh My Pi's browser WebMCP tests) and v0.1.7's draft was never published, and each retry took the next number.

This gives the agent Scient Desktop's order: check the version first, tag last.

What changes

• A release is a manual run on main with release set (workflow_dispatch), as Desktop's release is a dispatched run. Pushing a v* tag no longer starts a release.
• The version must come right after the latest published release. A new first job, scripts/scient/release-version.ts, refuses scient.json's version unless it is the next patch, minor or major after GitHub's latest published release and no tag carries it. It fails closed on any GitHub error other than 404.
• The tag comes last. Only after every job has passed does the release job check the version again, delete any unpublished draft of the same version and draft the release with --target <built commit>. The draft has no tag; publishing it creates v<version> on that commit. The job fails if drafting created the tag anyway.
• A retry reuses the number. After a failed or superseded run, run again with the same scient.json version. Its draft and its downloads.scientfactory.com copy replace the unpublished ones.
• Release runs share one concurrency group and are never cancelled; a second one waits.
• The binary-version checks compare against scient.json instead of the tag name.
• SCIENT.md documents the procedure and the rule. The SA-RELEASE ledger entry lists the new script and its test.

Unchanged: who publishes (a person publishes the draft); signing, notarization, R2 copy and compression; Desktop's catalog, which reads only published releases (releases/latest) and v<version> download URLs.

Checks

• scripts/scient/release-version.test.ts: 4 pass, covering the successor rule (0.1.9 → 0.1.10), skipping, repeating and going back, a tagged version, the first release and a malformed version. bun test scripts/scient: 77 pass.

• Script against the live repository: main's 0.1.8 → refused (tagged); 0.1.9 → accepted, version=0.1.9 written to GITHUB_OUTPUT; 0.1.7 → refused (orphan tag); 0.1.10 → refused (not next).

• actionlint 1.7.7: no new findings. It reports only the runner labels it doesn't know (xcode-27, macos-15-intel, windows-11-arm), and reports the same on main.

• oxlint, oxfmt --check, and the divergence check pass.

• Codex review (GPT-6.1 Sol, high; run through the Codex CLI because Scient's delegation failed): one finding. GitHub can't make a deletion apply only to drafts, so a draft published between the listing and the DELETE would have been deleted. Fixed in 47278dd9bf: each draft is read again right before its DELETE, the run stops if the draft has been published, and SCIENT.md says not to publish a draft while a release run of the same version is running. Codex found nothing else wrong with the expressions, gating, tag behaviour, the script or the docs.

• Rebased twice while other sessions released 0.1.9 and 0.1.10 the old way. c28e94bab7 makes the check say so when a hand-pushed tag on the next, never-published version blocks the release. Live: 0.1.10 is tagged but its release is still building, and the check now reports that tag instead of a dead end.

Not exercised: a real release run. This PR's CI covers the ordinary path, not the dispatched release path. The first real release (0.1.9) is that run, and its draft step fails loudly if GitHub ever creates the tag at drafting.

Not in this PR

The unpublished v0.1.7 draft and the unused v0.1.6 and v0.1.7 tags remain. Removing them waits for the owner's OK. They don't block anything: the next release is 0.1.9.