Every ticket as the root of its provenance graph — goal, patch, approval, runs and (as the ticket-class build lands) mandate, manifestations, guarantees, journey, artifacts and children. Rendered through the <<<TicketGraphList>>> tag.
Tickets page (?page=tickets) has no pagination — 1.4MB, ~308 rows, never reaches idle
goal
The ?page=tickets view ships EVERY ticket in one server-rendered page: ~1.4 MB (1,445,135 bytes), ~308 fully-rendered rows (170 REQUESTED + 134 DONE + closed). No pagination, no lazy-load. The page never reaches document-idle — claude-in-chrome find/screenshot timed out after 45s waiting for idle, twice.
IMPACT: freshly filed tickets are written correctly (verified via ticket.queue AND in the page HTML — e.g. #500/#501 render at rows 2-3 of the Project tickets table, sorted newest-first), but the page is too heavy to render reliably, so users see a stale/frozen view and conclude their tickets were never created. This undermines trust in the whole ticket flow (it is exactly the symptom that triggered this report).
PROPOSED FIX: paginate or lazy-load the list; default-filter to REQUESTED+OPEN and page the DONE/CLOSED history into a separate tab; cap the initial payload well under the current 1.4 MB.
EVIDENCE (2026-08-03): server HTML = 1,445,135 bytes; 308 ticket rows parsed; #501/#500 at rows 2/3 (newest-first); browser find + screenshot both timed out after 45s on document_idle.
patch
none
approval
unapproved
runs
no runs recorded
mandate (clauses)
not yet recorded — lands with the ticket-class build
manifestations
not yet recorded — lands with the ticket-class build
guarantees
not yet recorded — lands with the ticket-class build
journey (blunders & successes)
not yet recorded — lands with the ticket-class build
artifacts (forge)
not yet recorded — lands with the ticket-class build