Skip to content

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

coverstypecommandresultat commit
a_tag_does_not_freeze_the_queuetestMJ_TEST_JOBS=2 bash test/run.sh 3021_a_tag_does_not_freeze_the_queue 103_release_projectiontests: 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.

Searches the titles and descriptions of every page this site publishes.