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
I2282
The record pull request's dispatched verdict does not satisfy branch protection
Where it stands
devtask.issue- Readiness
- ready no dependency and no gate holds it; nobody has started it
- Status
- READY
- Can start
- startable
- Milestone
- Milestone status
- ACTIVE
- Wave
0- Waiting on
- none
- Holds back
- none
- Behind it in all
0- Evidence
0of2
Moves
plan.transitionWhat it is
- Objective
- Make the record pull request a release proposes mergeable without a person closing and reopening it, or stop docs/DISTRIBUTION.md and case 996 from saying that it is.
- Why
- docs/DISTRIBUTION.md ('Why the release asks for the verdict of its record') says the publish job dispatches validate on release/record-<tag>, that the check-runs attach to the head commit the pull request reads, and so the record no longer sits with an empty rollup until somebody closes and reopens it. On 2026-10-10 the v0.19.1 record, #866 at head 03e1d8a597, had exactly that dispatched run (38015081212) conclude success with a `ci` check-run from app 15368, the app and context master's branch protection requires (strict false, no rulesets). The merge was refused with 'base branch policy prohibits'. The pull_request run the record's opening caused (38015082449, actor github-actions[bot]) concluded failure with zero jobs; both check suites are associated with pull request 866, and its statusCheckRollup stayed empty until a close and reopen at 05:22Z started pull_request run 38027303212. The dispatch has not yet made a record mergeable on its own: v0.18.0's (#832) dispatch failed and it merged after a close/reopen run, v0.19.0's (#861) was admin-merged. Case 996 holds that the two workflows are wired to each other; it never observes a record pull request become mergeable. Each release since has lost one CI cycle, about 90 minutes, between publication and the record reaching the site.
- Now
- The publish job opens the record pull request with GITHUB_TOKEN and dispatches validate on its branch. The dispatched run's `ci` does not count: the rollups of #1142 and #1147 list no check although their dispatched `ci` passed, and on 2026-10-16 v0.27.0's record (#1273, head a2aa25f) was refused with its dispatched `ci` green (run 38865302829). Its pull_request run (38865305333) was created action_required, not failed with zero jobs as through v0.26.0, and the record merged on that run once a person approved it. Since fix/the-record-dispatch-is-not-the-records-verdict, release.yml, the record pull request's body, docs/DISTRIBUTION.md ('Who starts the record's verdict', the runbook and the failure table) and case 996 call the dispatch an early reading and name the person's step: approve the waiting run, or close and reopen (majordomus prs drain). What remains is the owner's decision on a GitHub App or fine-grained token that would make the record's own run start without a person; until then record_pull_request_mergeable_without_reopen cannot be shown.
- Wanted
- A release's record pull request becomes mergeable on its own green `ci`, with no close, reopen or admin merge, and the documentation says what the pipeline proves. Two remedies are named. The first is the owner's decision because it needs a credential only the owner can provide: the publish job opens, or closes and reopens, the record pull request with a GitHub App or fine-grained token whose events start workflows, so the pull_request run carries `ci` itself. The second needs nothing new: the pipeline and documentation stop claiming the dispatch is a verdict, the release names the close/reopen as its remaining step and does it with a token that can, or the lander's runbook carries it, and case 996 is narrowed to what it shows.
- Done when
- unknown: the record declares no `completion`
- Risk
- unknown: the record declares no `risk`
Acceptance
- On a release, `gh pr view <record> --json mergeStateStatus` reads CLEAN once its `ci` concludes success, without the record pull request having been closed, reopened or admin-merged; or docs/DISTRIBUTION.md no longer says that it does
- docs/DISTRIBUTION.md names, for the record pull request, only steps the pipeline performs or the lander's runbook performs, and the failure table names the close/reopen if it remains
- Case 996 asserts only what it observes; if it keeps the dispatch, it does not call it the record's verdict
- If the token remedy is chosen, the credential is named in docs/DISTRIBUTION.md as the owner's, with how it is rotated, and no secret value appears in the repository
- Validation
bin/majordomus plan validateMJ_TEST_JOBS=4 bash test/run.sh 996- Evidence required
record_pull_request_mergeable_without_reopendistribution_claims_match_pipeline- Evidence present
- unknown: the record carries no `evidence` entries
Scope
- Touches
.github/workflows/release.ymldocs/DISTRIBUTION.mdtest/cases/996_the_record_pull_request_gets_its_verdict.sh.ai/repo/ci/release.yaml- Not
- unknown: the record declares no `non_scope`
- Depends on
- unknown: the record declares no `depends_on`
- Priority
- p1
- 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-16
- Started
- unknown: the record declares no `started_at`
- Verified
- unknown: the record declares no `verified_at`
- Completed
- unknown: the record declares no `completed_at`
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
| Level | Code | Message | Reproduce |
|---|---|---|---|
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2410; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2411; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2412; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2413; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares .github/workflows/release.yml with I2660; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2713; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2714; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2716; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2717; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2718; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares docs/DISTRIBUTION.md with I2720; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2723; they may not run concurrently | majordomus plan validate |
| WARN | scope_conflict | shares test/cases/996_the_record_pull_request_gets_its_verdict.sh with I2731; they may not run concurrently | majordomus plan validate |