chore: make the release a manual dispatch

The job carried if: false, which blocks workflow_dispatch as well as
push, so there was no way to cut a release through CI at all and the
comment described a temporary state that had become permanent.

Releasing is deliberate: the push trigger is gone and the job runs when
someone dispatches it. The seven-day rate limit stays as the guard
against dispatching twice, and concurrency no longer cancels a run that
may be midway through uploading assets.

.github/workflows/build.yml

@@ -1,11 +1,10 @@
 name: Build & Release
 
+# Releasing is a deliberate act, not a consequence of pushing. Cutting one is
+# a manual dispatch: someone decides the collection is in a state worth
+# publishing, and the rate limit below still guards against doing it twice by
+# accident.
 on:
-  push:
-    branches: [main]
-    # A pack is the platform baseline plus what its cores need, so a profile
-    # change alters pack contents just as a platform list does.
-    paths: ["bios/**", "platforms/**", "emulators/**"]
   workflow_dispatch:
     inputs:
       force_release:
@@ -17,11 +16,10 @@ permissions: {}
 
 concurrency:
   group: build
-  cancel-in-progress: true
+  cancel-in-progress: false
 
 jobs:
   release:
-    if: false  # disabled until pack generation is validated in production
     runs-on: ubuntu-latest
     permissions:
       contents: write

wiki/architecture.md

@@ -197,7 +197,8 @@ platform's own verification mode.
 - standalone-emulator copies require explicit `--standalone-copies` consent;
 - CI writes only what its job needs: `validate.yml` holds `pull-requests: write`
   for the validation comment and labels, `deploy-site.yml` holds the Pages
-  deploy identity, and the release job stays disabled behind `if: false`.
+  deploy identity, and the release job holds `contents: write` but runs only
+  when someone dispatches it.
 
 - `safe_extract_zip()` prevents zip-slip path traversal attacks
 - `deterministic_zip` rebuilds MAME ZIPs so same ROMs always produce the same hash
@@ -326,14 +327,14 @@ pattern and how to add a test.
 
 | Workflow | File | Trigger | Role |
 |----------|------|---------|------|
-| Build & Release | `build.yml` | push to main (bios/, platforms/) + manual | restore large files, build packs, create GitHub release |
+| Build & Release | `build.yml` | manual dispatch only | restore large files, build packs, create GitHub release |
 | Deploy Site | `deploy-site.yml` | push to main (platforms, emulators, wiki, scripts) + manual | validate contracts, generate site, build with MkDocs, validate rendered HTML, deploy to Pages |
 | PR Validation | `validate.yml` | pull request on bios/, platforms/, emulators/, schemas/, scripts/, tests/ | validate BIOS hashes, schema check, run the full test suite, auto-label PR |
 | Weekly Sync | `watch.yml` | cron (Monday 6 AM UTC) + manual | scrape upstream sources, detect changes, create update PR |
 
-Build workflow has a 7-day rate limit between releases and keeps the 3 most recent.
-The release job stays disabled (`if: false`) until pack generation is validated
-in production. See the [release process](release-process.md).
+The build workflow has no push trigger: a release is dispatched by hand. It
+keeps a 7-day rate limit between releases and the 3 most recent tags. See the
+[release process](release-process.md).
 
 ## License
 

wiki/release-process.md

@@ -13,20 +13,21 @@ Budget target: ~175 minutes/month on the GitHub free tier.
 
 | Workflow | File | Trigger |
 |----------|------|---------|
-| Build & Release | `build.yml` | Push to `bios/**` or `platforms/**`, manual dispatch |
+| Build & Release | `build.yml` | Manual dispatch only |
 | Deploy Site | `deploy-site.yml` | Push to main (platforms, emulators, provenance, wiki, scripts, database.json, mkdocs.yml), manual |
 | PR Validation | `validate.yml` | PR touching `bios/**`, `platforms/**` or `emulators/**` |
 | Weekly Sync | `watch.yml` | Cron Monday 06:00 UTC, manual dispatch |
 
 ## build.yml - Build & Release
 
-Currently disabled (`if: false` on the release job) until pack generation is
-validated in production.
+Releasing is deliberate. Pushing never cuts one: somebody decides the
+collection is worth publishing and dispatches the workflow.
 
-**Trigger.** Push to `main` on `bios/**` or `platforms/**` paths, or manual
-`workflow_dispatch` with optional `force_release` flag to bypass rate limiting.
+**Trigger.** `workflow_dispatch` only, with an optional `force_release` flag to
+bypass the rate limit.
 
-**Concurrency.** Group `build`, cancel in-progress.
+**Concurrency.** Group `build`, queued rather than cancelled: a run that is
+already uploading assets must finish.
 
 **Steps:**
 
@@ -213,5 +214,15 @@ Run the pipeline online for a release: `--offline` skips the data directory
 refresh and the MAME/FBNeo hash refresh, so the packs would ship stale data
 directories.
 
-To re-enable automated releases, remove the `if: false` guard from the
-`release` job in `build.yml`.
+The workflow carries no push trigger, so there is nothing to disable and no
+guard to remove. Cutting a release means dispatching `build.yml` from the
+Actions tab, or:
+
+```bash
+gh workflow run build.yml
+gh workflow run build.yml -f force_release=true   # within 7 days of the last
+```
+
+The rate limit refuses a second release inside seven days unless
+`force_release` is set, which is what keeps a stray dispatch from publishing
+twice in a day.