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
I2710
A release run never waits behind pull-request validates for a job slot
Where it stands
devtask.issue- Readiness
- complete completion is recorded and every required evidence token is present
- Status
- DONE
- Can start
- not now
- Milestone
- Milestone status
- ACTIVE
- Wave
0- Waiting on
- none
- Holds back
- none
- Behind it in all
0- Evidence
1of1
Moves
plan.transitionWhat it is
- Objective
- Give the release path (the release workflow, the record pull request's verdict and the Pages deploy that publishes the release) priority over branch validates on the shared runner pool, so that a published release reaches majordomus.dev within its own run time.
- Why
- 2026-10-14 19:07Z: v0.26.0 was published, but its record PR #1147 sat BLOCKED: the verdict run 38620987044 and the Pages deploy 38620990702 were queued because the pull-request validates of #897 and #946 held all 20 job slots. majordomus.dev kept offering 0.25.0 and the landing HOLD could not be lifted; the run of #897 was cancelled by hand to free slots. The owner: \"tohle se nesmi stavat\".
- Now
- Every workflow competes for the same runner pool first come, first served. Nothing makes a pull-request validate yield while a release, its record verdict or its Pages deploy waits for a slot.
- Wanted
- While a release run, a record pull request's verdict or a Pages deploy of master is queued or running, a pull-request validate that has not yet finished yields: it does not start new jobs (or cancels itself with a reason naming the release run and is re-requested after it), and the release path never waits for a slot a branch validate holds. Master's own validate is never cancelled by this.
- Done when
- unknown: the record declares no `completion`
- Risk
- unknown: the record declares no `risk`
Acceptance
- With a release run or record verdict queued, a pull-request validate yields within one minute and says which release run it yielded to
- A yielded validate is re-requested once the release path is done, without a person
- Master's validate and the release path themselves are never cancelled by the rule
- Validation
bin/majordomus plan validate- Evidence required
release_path_has_priority_case- Evidence present
release_path_has_priority_case
Scope
- Touches
.github/workflows/validate.yml.github/workflows/release.ymlscripts/cidocs/CI.mddocs/RELEASE.mdtest/cases- Not
Buying runners or changing the pool's size- Depends on
- none
- 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-14
- Updated
- 2026-10-14T22:02:16Z
- Started
- 2026-10-14T22:00:40Z
- Verified
- unknown: the record declares no `verified_at`
- Completed
- 2026-10-14T22:02: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.