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
I2711
The pages job judges production only after the deployment of its own commit has arrived
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
- Stop validate's `pages` job on master from reporting red because it read majordomus.dev before the deployment of the commit it judges had been served.
- Why
- 2026-10-14: validate 38579234241 on 0dff496d1c and validate 38600347235 on ff38297096 both concluded failure on the `pages` job, step \"the published site came from master, is current, and is being served\" exit 10, while production served that very commit minutes later; the job passed on a manual rerun. A false red on master holds the v0.26.0 tag (only a commit with ci success may be tagged) and costs a rerun of the job each time.
- Now
- The step reads production's build.json once, at the time the job reaches it, and fails when the deployment of its commit has not finished yet.
- Wanted
- The step waits, bounded, for production to serve its commit (polling build.json with a declared limit, saying what it waits for), and fails only when the bound passes or production serves a different commit that is not newer; a deployment that is still queued is reported as such, never as a defect of the tree.
- Done when
- unknown: the record declares no `completion`
- Risk
- unknown: the record declares no `risk`
Acceptance
- The pages job passes when the deployment of its commit arrives within the declared bound after the job starts
- It fails, naming both commits, when production serves an older commit after the bound
- The wait is bounded and declared, and liveness-check accepts it
- Validation
bin/majordomus plan validate- Evidence required
pages_waits_for_its_deployment_case- Evidence present
pages_waits_for_its_deployment_case
Scope
- Touches
.github/workflows/validate.ymlscripts/ci/pages-checkscripts/site-checkdocs/CI.mdtest/cases- Not
Making the Pages deployment itself faster- 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:38Z
- Started
- 2026-10-14T22:01:02Z
- Verified
- unknown: the record declares no `verified_at`
- Completed
- 2026-10-14T22:02:38Z
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.