Read model & console surface for milestone runs

[xlight05]

Question

(Re-aimed 2026-07-23 by the milestone decision (#312) — runs key on milestones, not parent issues.)

• The console Builds page is keyed by spec tag today; what does it show now — a list of milestone runs? What is a "run" row, and how does it render the loop's cycles (initial coding, conflict re-dispatch, fix rounds, validation) — input from Run loop mechanics (#314) on rows-per-run vs rows-per-cycle and where the validation verdict lands?
• API surface (owner-directed): GET /projects/{p}/build/{tag} is removed — verified unused, the console calls only GET /projects/{p}/tasks?state=all&tag=. That read keeps its tag parameter but filters by milestone membership (title == tag) instead of the aep:spec/<tag> label. Which other read endpoints change in the committed OpenAPI contract?
• Task board: how milestone + issue status renders; what replaces the derived status algebra (taskmeta/derive.go) and the blockedBy projection. Note: issues close only at merge, so mid-run issue state is NOT a progress signal; there are no native edges — the provisioning wait renders from open aep:provision issues in the milestone (drawer deep-links), not from blocked_by.
• Progress: unchanged contract — ONE run-level feed (pod-log tail keyed to the execution) carrying main-agent and subagent frames, each identifying its emitter. Design the UI that renders that single run view, replacing the per-task SSE task-log stream.

[xlight05]

Input from Provisioning gates & validation (#284): phase names become run-row states — this ticket owns the state vocabulary. Two fixed surface facts: the build surface ends at deployment (no validation content in the build view), and validation is a post-deployment surface reading from the run row (verdict + report link from the merged validation PR). The provisioning wait state should render from the parent's live blocked_by (one GraphQL call, verified in #279) — open gates with drawer deep-links, not DB state.

[xlight05]

Input from Slim parent workflow (#285): the run timeline this surface renders is now fully specified — wait (unbounded, live blocked_by render + drawer deep-links) → dispatch → PR → merge → builds settled → deployed-green → validation (post-deploy surface, per #284). The read model gets concrete things to show: attempt counters against the four budgets (re-dispatch 2, build re-trigger 1, fix chain 2, conflict re-dispatch 2), the fix-chain lineage (child runs), build-stalled / merge-conflict terminal reasons, and Red main: <component> incident issues (outside-a-run failures — decide where they surface). One UX obligation from #285: cancel is the wait state's only expiry and it frees the project mutex — it needs prominent placement on a waiting run. Note: the map's 'observability for long-running parent runs' fog is absorbed here — the supervisor side (phase bounds, ground-truth polls) is settled; what remains is this ticket's rendering of it.