Grill (why): Property Manager view — tenancy/property overview, arrears board, timeline, rental ledger

[davidtaing]

Capture — why-grill the Property Manager view

The operational counterpart to the developer/ES inspector view (docs/brief/developer-view.md). Where the dev view shows ES to teach it, the PM view plays the agent over the seeded scenario board. Not yet grilled — this issue holds the idea so it isn't lost. Next step: grill-brief → docs/brief/property-manager-view.md.

Surfaces David has in mind (raw, pre-grill)

1. Tenancy / property overview — a single-entity landing page: current status, rent, days-behind, notice/exit state at a glance.
2. Properties list with current arrears — the cross-entity board (backed by the existing Arrears read model): every tenancy and its live balance / oldest-unpaid / status. The "walk into a board and play the agent" entry point.
3. Timeline — the per-tenancy drill-down (backed by the existing compute-on-read Timeline.for_tenancy/1 fold): chronological, evidence-grade event history.
4. Rental ledger view — a double-entry debit/credit ledger presentation (aligns with the enforced double-entry fidelity: charges as debits, payments as credits, running balance). Distinct from the timeline — the accounting lens, not the event lens.

Open questions for the grill (do NOT decide here)

• "Property" vs "tenancy" as the primary noun. The domain today models tenancies (Arrears/Timeline are keyed by tenancy_id); there is no Property aggregate. Does the PM view introduce a property/portfolio layer, or is "property overview" really "tenancy overview"? This is a domain-model call for the grill.
• How the ledger view relates to the timeline — same data, two lenses, or genuinely different reads? Avoid building a worse-maintained duplicate.
• Where the PM view and dev view share components vs. stay separate routes (the dev-view brief already frames itself as "distinct from the Property Manager view").

Prereqs

Same hard prereq as the dev view — a populated event store — which is now green (scenario catalogue seeded).

[davidtaing]

Identity render is a first-class PM need (noted, deferred)

The PM-facing reads — the tenancy/property timeline, the event read, the rental ledger — must show property address + tenant names alongside each event, not just tenancy_id/property_ref. Identity display isn't a developer-inspector nicety; it's core to the PM view.

Good news — the option-C architecture already serves this (ADR 0008). Identity stays off the event log (no PII, unredactable-log footgun); any read view resolves it by an in-Elixir keyed merge with the identity read model at render time — property address off property_ref, tenant names off tenancy_id. The inspector (#81) does exactly this merge; the PM view does the same. So the identity read model is a shared concern across both views, not inspector-specific plumbing.

One forward-looking caveat for when this is designed: the current Latchkey.Simulation.Directory (#93) is a disposable, faker-seeded fixture living in the Simulation domain. A real PM deployment needs an authoritative, PM-entered tenant/property registry as the identity source (still off-log, same merge contract) — the Directory is the sim stand-in for it. Also worth deciding then: address is more naturally keyed by property (property_ref) than duplicated per-tenancy, which matters once the PM view groups tenancies by premises.

Deferred — surfaced 2026-07-13 while building the identity batch (#93/#96).

[davidtaing]

Parked (not now). The developer view (/inspector) has delivered the bulk of the learning value this initiative was chasing — seeing the event log, streams, ledger, and timeline directly. The PM view remains a mostly presentational second lens over data the inspector already exposes, so it teaches much less per unit of build effort.

Leaving this open to preserve the captured thinking, but stripping the proposed label so it stops surfacing as actionable in stocktakes. Revisit if a genuinely PM-facing lens is ever needed.