A snapshot: read at commit 707a04c7ce8 on 2026-10-18T00:06:01Z by majordomus 0.29.0. Nothing on this page is read again. See it live

I2303

A release publishes its metadata to the site before its record lands, and the site never goes back a release

Where it stands

devtask.issue

Readiness: complete completion is recorded and every required evidence token is present
Status: DONE
Can start: not now
Milestone: test-evidence
Milestone status: ACTIVE
Wave: 0
Waiting on: none
Holds back: none
Behind it in all: 0
Evidence: 2 of 2

Moves

plan.transition

What it is

Objective: Make majordomus.dev serve a release's releases/latest.json and releases/<tag>.json from the release run itself, minutes after its archives are published, instead of after its record's pull request has passed its ci, without the site ever going back a release.
Why: On 2026-10-10 v0.20.0 was published on GitHub at 16:38Z and served by the site at 17:42Z, only after its record was merged by hand without waiting for ci; v0.19.1 was published at 01:46Z and served after 07:09Z, its record's ci running 106 minutes. The owner set a bound of 15 minutes from tag to served release and chose, asked the same day, that the release run publish its metadata itself before the record lands.
Now: release.yml's publish job derives the record and its projections, proposes them as release/record-<tag>, and dispatches pages.yml on the default branch; the site serves the release only once the record's pull request is merged and master deployed. scripts/site-deploy replaces gh-pages with the build entirely.
Wanted: The publish job runs `scripts/site-deploy --release-metadata <tag>` after `scripts/derive-check` judged the tree: exactly releases/<tag>.json and releases/latest.json change on gh-pages, build.json still names master's commit. It refuses a missing or mismatched tag file, a latest.json that differs from it, and a release older than the one served. An ordinary deploy keeps gh-pages' latest.json and the tag file it names when they name a newer release than the build, and says so. ADR 0131 records the decision.
Done when: unknown: the record declares no `completion`
Risk: unknown: the record declares no `risk`

Acceptance

`scripts/site-deploy --release-metadata <tag>` changes exactly releases/<tag>.json and releases/latest.json on gh-pages and leaves build.json naming master's commit, proven against a local bare remote
It refuses, pushing nothing, a missing tag file, a latest.json naming another tag, a latest.json that differs from the tag file, and a release older than the one served
An ordinary deploy of a build that names an older release keeps the served latest.json and its tag file and says so; a build naming the same or a newer release replaces them
release.yml's publish job runs the mode after scripts/derive-check and before the record is proposed, and the smoke job waits for the served metadata rather than for the record to be on the default branch
The case fails against the previous scripts/site-deploy, and against one without the keep rule

Validation: bash test/run.sh 1041_a_release_publishes_its_metadataMJ_TEST_JOBS=3 bash test/run.sh 87_release_pipeline 26_ci_wiring 996_the_record_pull_request_gets_its_verdictbin/majordomus plan validate
Evidence required: release_metadata_published_ahead_of_record_casedecision_recorded
Evidence present: release_metadata_published_ahead_of_record_casedecision_recorded

Scope

Touches: scripts/site-deploy.github/workflows/release.ymldocs/DISTRIBUTION.md.ai/repo/adrs/0131-a-release-publishes-its-metadata-before-its-record-lands.md.ai/repo/project/issues/I2303.yamltest/cases/1041_a_release_publishes_its_metadata.shtest/cases/87_release_pipeline.shdocs/generateddocs/PLAN_STATUS.mddocs/PAGES_STATUS.mdsite/contentsite/data
Not: Shortening the build and the publish job, which the 15-minute bound also needs: the macOS x86_64 package step, the second derivation and the rebuilt executable of the publish job.The staging line release.yml's publish step fails on since /dist/ is ignored: I2302.
Depends on: unknown: the record declares no `depends_on`
Priority: p0
Profile: implementation
Parallel safe: true
Owner: unknown: the record declares no `owner`

The work so far

Branches: none
Merged: none
Commits: 0
Trunk: master
Sessions: none
Created: 2026-10-10
Updated: 2026-10-14T08:00:34Z
Started: 2026-10-14T08:00:25Z
Verified: unknown: the record declares no `verified_at`
Completed: 2026-10-14T08:00:34Z

Synchronisation

Adapter: scripts/github-sync
Repository: unknown: the derived plan's header carries no repository
External issue: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it
State there: unknown: a live GitHub state; this executable makes no network call, so only `scripts/github-sync --check` can answer it

Findings

Nothing is wrong with these records.