Atlas work-order focus — a long timeline says it was cut
The detail route reads a work order's newest 200 timeline events; the header and badge say when older ones were not loaded.
1 Oct 2026 · branch p10-core-surfaces-atlas-timeline-cap · captured against propflow-stage · at 35a3192ffd0
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.
1 · A test work order with 207 timeline events, focused in Atlas
A work order on the sandbox TEST building, given 205 synthetic timeline events for this capture (its two real events are older) and stripped of them after it. The route reads the newest 200 only. Look at the Status Timeline header and its count badge: they must say the history was cut, and the badge must not claim a total nobody counted.
The two critique rounds
Round 1 (top of the focus): the header reads Status Timeline — newest only, older ones not loaded with the badge 200+, the same wording and badge the Messages block settled on in #14827 / #14951, so the two cut lists read alike. The first row is event 6, the oldest one read, which is what "older ones not loaded" promises. Not this PR: the Work Order block shows "—" for the id because this stage row has no display id, and times are UTC because Atlas spans buildings (both unchanged).
Round 2 (end of the table): the last row is event 205, the newest, and the table holds exactly 200 rows (6 to 205), so the badge's 200 is what was read and the + is what was not. The blocks below (Activity Log, PMS Mirror, Dispatch assignment) are unaffected. No change needed.
Asserted in the captured DOM — Status Timeline — newest only, older ones not loaded · 200+ · Fixture event 205 of 205 · Fixture event 6 of 205. Header and badge asserted after the lazy detail fetch rendered. Event 205 (newest) and event 6 (the oldest one read) are both present, so the block shows exactly the newest 200.
