I2054 — A tag does not turn every other pull request red until its record lands
From the moment a release tag is pushed until its release record is on master, a pull request that changes nothing about releases keeps a green structure job. Either scripts/ci/release-check holds a published tag without a record only when no open pull request proposes that record, or the record is proposed before the tag is pushed; the choice is the implementer's and is written down with what it costs.
DONE wave 0 · p1 · implementation profile · runs alone
Part of development-runtime — The runtime has a development surface.
Objective
From the moment a release tag is pushed until its release record is on master, a pull request that changes nothing about releases keeps a green structure job. Either scripts/ci/release-check holds a published tag without a record only when no open pull request proposes that record, or the record is proposed before the tag is pushed; the choice is the implementer's and is written down with what it costs.
Why
scripts/ci/release-check fails the structure job of every branch that does not carry the record of a published version, and the record needs a full CI run of its own to land, so each tag stops the queue for about two hours. With releases cut often, that is most of a working day.
Current state
Measured on 2026-10-08 with v0.17.0: pull requests 823, 824, 820 and 821 and the second round of 816 each went red on one finding - the version is published and the layer holds no release record for it - while the record's pull request 822 ran. Reproduced locally at ad3c2b93f4: release-check reports that one finding and nothing else. Case 996 (in pull request 816) gives the record's pull request its checks by a dispatch, which shortens the wait and does not remove it.
Desired state
A tag and its record landing are invisible to a pull request that touches no release file; a published version with no record and no pull request proposing one is still refused.
Scope
- scripts/ci/release-check
- .github/workflows
- .ai/repo/ci
- apps/majordomus-cli/src/release
- test/cases
- docs
Dependencies
None. This issue is a root of the graph.
What waits on this
Acceptance criteria
- A case publishes a tag in a fixture, leaves its record proposed and not landed, and a branch that changes no release file passes release-check
- The same case shows a published version with no record and nothing proposing one is still refused
- The document that describes a release says in which order the tag and the record are made and why
Validation
- scripts/ci/release-check
Evidence required
- a_tag_does_not_freeze_the_queue
Evidence
| covers | type | command | result | at commit |
|---|---|---|---|---|
| a_tag_does_not_freeze_the_queue | test | MJ_TEST_JOBS=2 bash test/run.sh 3021_a_tag_does_not_freeze_the_queue 103_release_projection | tests: 2 passed, 0 failed; docs/DISTRIBUTION.md#releasing says the order and why (run 2026-10-14 14:52Z on master 0dff496d1c plus this change) | 0dff496 |
Risk
Loosening the check by reading open pull requests makes a structure gate depend on the forge; proposing the record before the tag changes the release order every session follows.
Timeline
- started
- 2026-10-14T14:52:51Z
- verified
- —
- completed
- 2026-10-14T14:53:16Z
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/I2054.yaml. Read it back with majordomus plan show I2054.