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
I2663
The published UI is not read from nothing on every deployment
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
3- Waiting on
- none
- Holds back
- none
- Behind it in all
0- Evidence
0of2
Moves
plan.transitionWhat it is
- Objective
- Stop paying a quarter of an hour per deployment for a snapshot whose inputs did not change.
- Why
- The owner, 2026-10-13: 'investigate what is slow ... solve it systemically, prevent it next time' and 'this must be analysed and solved through .ai/; it must not happen again'. Measured that day: a merge reached production 45 to 61 minutes later, and two landings of the evening were not served an hour after they merged.
- Now
- Measured 2026-10-13 in the ui-snapshot job of two pages runs: reading the UI once took 749 and 974 s, the Cockpit 127 and 164 s, building the executable 106 and 126 s, the checkout 85 and 103 s. On the first run after a version bump the setup-rust step alone was still running after eleven minutes; whether that is a cache keyed by a file the bump changes is not yet verified. A second landing's run waits for the whole of the first.
- Wanted
- The snapshot is produced from a key over what it reads; a deployment whose key matches reuses the previous snapshot and says so, and a full read is bounded by the UI's own budgets. The executable the job needs comes from a cache a version line does not invalidate, or from the build another job of the same run already made. What each step cost is recorded per run.
- Done when
- unknown: the record declares no `completion`
- Risk
- unknown: the record declares no `risk`
Acceptance
- A deployment that changed nothing the UI reads reuses the snapshot and its page states the commit it was read at
- A full snapshot of this repository is within a declared number of seconds on a hosted runner, and the run fails its budget otherwise
- The first deployment after a version bump builds the executable no slower than the one before it, with the cause of today's eleven minutes named
- Validation
bin/majordomus plan validateMJ_TEST_JOBS=2 bash test/run.sh 2983_the_published_ui_is_the_trunks- Evidence required
snapshot_seconds_before_and_aftersetup_rust_after_a_bump_explained- Evidence present
- unknown: the record carries no `evidence` entries
Scope
- Touches
.github/workflows/pages.yml.github/actions/setup-rustapps/majordomus-cli/src/web/reportscripts/pages.ai/repo/ci/pages.yaml.ai/repo/project/issues/I2663.yaml- Not
What the screens showThe latency budget of a served screen, which is I2489- 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-13
- Updated
- 2026-10-13
- 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
Nothing is wrong with these records.