I3448 — A deploy of master keeps every pre-release's metadata the site already serves
Make an ordinary deploy of master keep each releases/<tag>.json that gh-pages carries and the build lacks, so that a pre-release's metadata, published by the release's own job before its record reaches master, is never removed by the next deploy.
READY wave 0 · p1 · implementation profile · parallel safe
Part of M004 — Performance is executable evidence, and the hot path does no canonical work twice.
Ready. Every dependency is done, so majordomus plan start I3448 will be accepted.
Objective
Make an ordinary deploy of master keep each releases/<tag>.json that gh-pages carries and the build lacks, so that a pre-release's metadata, published by the release's own job before its record reaches master, is never removed by the next deploy.
Why
Found on 2026-10-20 after v1.0.0-alpha.1 was tagged at 9a5a9b77520. release.yml's publish job pushed gh-pages 54b6c8f94f1 ('release: v1.0.0-alpha.1 pre-release metadata, published beside the latest'), and the next master deploys of the same commit (d830fa03091, dd9c60d7445) carried no releases/v1.0.0-alpha.1.json, so https://majordomus.dev/releases/v1.0.0-alpha.1.json answered the site's 404 page while the GitHub release existed. It stays missing until the release record pull request lands on master.
Current state
scripts/site-deploy keeps, on an ordinary deploy, the releases/latest.json gh-pages carries and the tag file it names when that names a newer version than the build (ADR 0131). A pre-release is never named by latest.json (I2829 refuses that), so its tag file is not kept and is deleted by the copy of site/public over the gh-pages worktree.
Desired state
An ordinary deploy keeps every releases/<tag>.json on gh-pages that site/public does not hold, stable or pre-release, and says which it kept; latest.json keeps its present rule. The deploy after a pre-release's metadata publication still serves that file.
Scope
- scripts/site-deploy
- docs/RELEASE.md
Out of scope
- Which release latest.json names, which stays the newest stable release
- Publishing a pre-release's metadata from master before its record lands
Dependencies
None. This issue is a root of the graph.
Acceptance criteria
- A fixture gh-pages carrying releases/v9.9.9-alpha.1.json and a build without it: after an ordinary deploy the file is still there, byte-identical, and the deploy names it as kept
- Negative: a releases/<tag>.json the build itself holds is replaced by the build's copy, not kept from gh-pages
- latest.json behaves as before: kept when it names a newer stable release than the build, replaced otherwise
Validation
- bash test/run.sh 3721_a_deploy_keeps_every_pre_release_it_serves
- majordomus plan validate
Evidence required
- test_a_deploy_keeps_every_pre_release_it_serves
Evidence
None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.
Timeline
- started
- —
- verified
- —
- completed
- —
Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.
Canonical record: .ai/repo/project/issues/I3448.yaml. Read it back with majordomus plan show I3448.