I2711 — The pages job judges production only after the deployment of its own commit has arrived
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.
DONE wave 0 · p0 · implementation profile · parallel safe
Part of M004 — Performance is executable evidence, and the hot path does no canonical work twice.
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.
Current state
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.
Desired state
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.
Scope
- .github/workflows/validate.yml
- scripts/ci/pages-check
- scripts/site-check
- docs/CI.md
- test/cases
Out of scope
- Making the Pages deployment itself faster
Dependencies
None. This issue is a root of the graph.
Acceptance criteria
- 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
| covers | type | command | result | at commit |
|---|---|---|---|---|
| pages_waits_for_its_deployment_case | test | MJ_TEST_JOBS=3 bash test/run.sh 3027_the_release_path_goes_first 3028_the_pages_job_waits_for_its_deployment 3029_a_tag_in_flight_is_pending 3021_a_tag_does_not_freeze_the_queue 3019_a_failed_branch_run_cancels_itself 103_release_projection 94_ci_plan | tests: 7 passed, 0 failed (run 2026-10-14 ~22Z on master c0e3585dc836201089d6b5dd49f5a79fe8bff798 plus this change); case 3028: pages-check --for COMMIT waits, polling build.json every 30 s up to a declared 1200 s, passes when production serves the commit or a newer one, fails early only when an older commit is served with no deploy in flight, and names both commits | c0e3585 |
Timeline
- started
- 2026-10-14T22:01:02Z
- verified
- —
- completed
- 2026-10-14T22:02:38Z
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/I2711.yaml. Read it back with majordomus plan show I2711.