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

I2054

A tag does not turn every other pull request red until its record lands

Where it stands

devtask.issue

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

Moves

plan.transition

What it is

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.
Now: 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.
Wanted: 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.
Done when: unknown: the record declares no `completion`
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.

Acceptance

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 present: a_tag_does_not_freeze_the_queue

Scope

Touches: scripts/ci/release-check.github/workflows.ai/repo/ciapps/majordomus-cli/src/releasetest/casesdocs
Not: unknown: the record declares no `non_scope`
Depends on: none
Priority: p1
Profile: implementation
Parallel safe: false
Owner: unknown: the record declares no `owner`

The work so far

Branches: none
Merged: none
Commits: 0
Trunk: master
Sessions: none
Created: 2026-10-08
Updated: 2026-10-14T14:53:16Z
Started: 2026-10-14T14:52:51Z
Verified: unknown: the record declares no `verified_at`
Completed: 2026-10-14T14:53:16Z

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.