The Work Orders list now loads its newest 100 rows off the index and follows a cursor for more — and a search that matches nothing loaded says what it searched instead of claiming nothing exists.
22 Sept 2026 · branch feat/wolist-reader-on · captured against propflow-stage · at 159eebd59e
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
The sandbox bench building carries about four thousand work orders on stage. The page no longer reads all of them to paint: the server render and the 5-second poll each read ONE page of the building's work-order-list-index partition — the newest 100 by created date — and the table asks for the next chunk only when the reader reaches the last loaded page. The screen should look exactly as it did; what changed is what it cost.
Asserted in the captured DOM — Work Orders · New Work Order · 100+ work orders. 100 is the first chunk's size (a constant), and the + says more exist: the footer counts the LOADED window and must never read as the size of the backlog. The building's real total moves on stage and is deliberately not pinned.
Search and filters apply to the rows loaded so far, so an empty result is only a fact about what was SEARCHED. With a search active the table walks older chunks on its own (showing Searching older work orders… while it does), and stops at 1,000 rows rather than reading the whole backlog unasked. When it stops it says how far it looked and offers Search older — it never renders a bare "no work orders" over rows it has not read.
Asserted in the captured DOM — Searched the newest 1,000 work orders. · Search older · Only the newest 1,000 work orders were searched. · 0 of 1000+. 1,000 is the table's walk bound (a constant in WorkOrderTable.tsx), not a live count.