[PAMulligan]

Follow-up to #198, which merged while the first dispatch result was still coming in. Reopens the work on #189. Part of #186.

What #198's chain cannot do here

The dispatch of the merged chain against v2.1.4 (run 42518497713) built and packaged on all three platforms in about 90 seconds each, then every upload failed with HTTP 422: Cannot upload assets to an immutable release. This repository has GitHub's immutable releases enabled (the release objects carry immutable: true; Aurelius's do not). Nothing can be attached after publication, so the merged publish-then-attach chain will fail at its last step on every release, and no already-published release (v2.1.4, v2.2.0) can be back-filled.

Fix: draft first

• release-please-config.json: "draft": true and "force-tag-creation": true. release-please creates the tag immediately and the Release as a draft (without the eager tag GitHub creates it only on publish, which release-please's docs say breaks its lookup of the previous release).
• release-please.yml still calls gui-release.yml in the same run with the tag.
• gui-release.yml now has three jobs: check refuses a tag whose release is not a draft, with a clear message; build (unchanged otherwise) attaches the installers to the draft; publish runs only when every platform succeeded and flips the draft to published, listing the assets in the job summary. workflow_dispatch with a tag reruns attach-and-publish for a draft an earlier run left unpublished; without a tag it is a dry run that keeps the installers as artifacts. The release: published trigger is removed, since on this repository it could only ever fail.
• docs/GUI.md and docs/RELEASING.md describe the chain and the recovery path.

Verification

• All three files parse; the release-please config schema accepts both options.
• From this branch, gh workflow run gui-release.yml -f tag=v2.1.4 (a published release): the check job fails with the "already published" message and the build is skipped.
• From this branch, a dispatch with no tag: a dry run on the three runners, installers kept as artifacts, nothing published.
• The draft-attach-publish path itself can only be exercised by the next release-please run after this merges: the next Release PR merge should produce a published Release carrying Flavian-<version>.AppImage, Flavian Setup <version>.exe and the two DMGs.

🤖 Generated with Claude Code

[PAMulligan]

Both test dispatches from this branch (commit e5c1b5a) behaved as designed:

• Guard (tag=v2.1.4, a published release), run 42519555660: the check job failed with Release v2.1.4 is already published. This repository's releases are immutable once published, so nothing can be attached to it.; the build and publish jobs were skipped.
• Dry run (no tag), run 42519561675: check and publish skipped, all three installer jobs succeeded, nothing touched any release. Artifacts kept: flavian-gui-Linux (121 MB, Flavian-2.2.0.AppImage), flavian-gui-macOS (232 MB, Flavian-2.2.0-arm64.dmg and Flavian-2.2.0.dmg), flavian-gui-Windows (98 MB, Flavian Setup 2.2.0.exe).

What remains unproven until a real release: release-please creating the draft with the eager tag, and the publish job flipping it. The next Release PR merge after this lands is the one to watch; if a platform fails there, the draft stays and gh workflow run gui-release.yml -f tag=<that tag> finishes it.