Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1resolveTurnoverReadBound's per-building roster point-read (added #10844) is bounded by the caller's raw propertyScope, not by org-intersected scope, because getOrgScopedPropertyIds is derived FROM that roster read (no independent org check exists without reading the row). If a user's assignedPropertyIds erroneously includes a foreign-company building id (a defense-in-depth scenario, not the normal path), resolveTurnoverReadBound issues a GetItem for that building's PROP#<id>/META row before the org leg excludes it from the actual turnover query. load-turnovers-list.read-ledger.test.ts's 'a foreign building sitting in the caller's OWN assignment' case (pre-existing since #10827, never actually enforced before #10844 because the old estate-wide getProperties() read was unattributable to the ledger) now fails on this. A sibling loader, load-properties-list.ts, already solved the same shape by reading the org's own roster first via the PROPORG#<org> GSI (getPropertiesViaRoster) and intersecting before any per-building read, so a foreign id is never point-read at all.
In plain terms. The turnovers list now reads a foreign company's building record when a teammate's building list is accidentally set wrong — should we close that gap now, or just track it as a known limitation for later?
The session raising this recommends: Track it for later, ship the CI fix as-is The immediate red-main cause is a test-mock bug (missing getProperty delegate), not this gap; the leak is narrow (one property metadata row, not tenant data, and only reachable if the building assignment is already wrong elsewhere) and the real fix touches a hot isolation read path that deserves its own reviewed PR, not a rider on the CI-restore fix Tried first, unsuccessfully: Confirmed the mock-delegate fix restores 6 of 7 failing assertions in a clean origin/main worktree; traced the 7th to getOrgScopedPropertyIds' own docstring ('no extra DB read' — it is computed FROM the roster read, so org membership cannot be known before the read); grepped for a cheaper alternative and found load-properties-list.ts already does org-roster-first via PROPORG#; did not attempt the refactor myself given the isolation-sensitive blast radius