I2486

What it is

Objective

Take every handler, git call and file read off the path of a UI request: the executor keeps the latest reading of each source a page asked for, a screen is rendered from those readings at once, and a worker reads a source again behind the reader whenever the reading is not of the repository as it is now.

Why

The owner said on 2026-10-12 that the UI 'is tragically slow' and is to be solved 'architecturally'. Measured on the UI-performance batch's build (c66f49e406, debug, load 20): /ui 2.2-2.5 s on every request, because health.report (2.4 s, probes, not cacheable) is in its first paint; the first request after a start or a change 5.6-8.1 s for roadmap, evidence and governance, because a cache keyed by the repository's state is empty exactly then; /ui/panels/delivery 75.7 s. A page costs its slowest source and no cache changes that. ADR 0142 records the decision.

Now

A screen asks its sources through ctx.execute and waits for all of them (ui/source.rs ask_all). A cached source answers at once while the repository stands still; an uncached one and the first read after any change run the handler on the request.

Wanted

capability::readings keeps, per source and input, what it last answered, when, how long it took and in which state of the repository. Context::read hands that over: at once when it is of the repository as it is now, with a worker reading it again behind the caller once it is older than a second; after at most 50 ms, marked stale and refreshing, when the repository has moved, and then every other source read lately is read again too; after waiting for the first reading when there is none, said as pending past a minute. One worker per source, four at once in all, above the executor's own cache and single flight. execute is unchanged and exact. ui::source asks for readings; an answer carries its standing (age, current/stale/pending, refreshing); a source line says a reading's age once it is older than five seconds and says when it predates the last change; a line whose reading is catching up carries data-catching-up and the page's script reads the screen again after 0.4 s, doubling to 6.4 s, until none is left. The first reader of the UI starts one background pass over SCREENS and PANELS. MAJORDOMUS_CAPABILITY_CACHE=off makes a reading run its handler; MAJORDOMUS_READING_PATIENCE_MS sets the patience, and wait makes every read exact.

Done when

unknown: the record declares no `completion`

Risk

unknown: the record declares no `risk`

Acceptance

Scope

Touches

apps/majordomus-cli/src/capability/readings.rsapps/majordomus-cli/src/capability/executor.rsapps/majordomus-cli/src/capability/handler.rsapps/majordomus-cli/src/capability/mod.rsapps/majordomus-cli/src/uiapps/majordomus-cli/src/http/router.rsapps/majordomus-cli/tests/executor.rsshare/ui/ui.jsdocs/MAJORDOMUS_UI.mddocs/CLI.mdtest/cases/1096_no_screen_waits_for_a_source.sh.ai/repo/adrs/0142-no-screen-waits-for-a-source.md.ai/repo/rules/project/no-screen-waits-for-a-source.v1.md.ai/repo/project/issues/I2486.yaml

Not

unknown: the record declares no `non_scope`

Depends on

I2461

Priority

p0

Profile

implementation

Parallel safe

false

Owner

unknown: the record declares no `owner`

The work so far

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.