I'm parked on you

Pick an option on each card and press Done; your answer goes straight back to the session. The raiser's pick is marked. "I'm not sure" is a real answer.

1

In plain terms. Should a roommate we've already removed from a lease stay removed, even if a different daily sync still thinks they're there? Today one got un-removed within a minute, right after we removed them — and it'll keep happening.

The full question, as raised

cotenant_stale_roster retired TenantOccupancy PERSON#pers_ab1ba941-7ca1-4726-a8a5-8bac951f8ab9 (Pedro Cruz, Camellia unit 118) to status='former' at 2026-10-01T08:15:48.716Z (confirmed: saveOccupancy call precedes sendBakeAlert's firedAt in reconcile.ts). Prod read-back (smith-db) shows the SAME row back at status='active', updatedAt=2026-10-01T08:16:11.783Z — 23s later. Root cause traced in code: dualWriteCoTenantOccupanciesForTenant (apply-entity-sync.ts, runs every rent-roll sync) does a full-object PUT recomputing status purely from the PRIMARY's own deriveOccupancyStatus signals, with no check of the co_tenant row's current status, for every name still present in coTenantsByTenantId — sourced from rr.additionalTenants, a DIFFERENT AppFolio field than the tenant_directory Current/Notice per-row data cotenant-stale-roster-reconcile uses as ground truth. reconcileCoTenantRemovals (#1879) only retires a co-tenant dropped from THAT SAME additionalTenants field, so it never catches this case either. Net effect: whenever tenant_directory and rent-roll additionalTenants disagree about one co-signer, the daily reconciler's retirement is silently reverted within about a minute, and the exact renewal-blocking bug it was built to fix (2026-07-21, unit 617) recurs. This is the reconciler's own named exit criterion in config/automations.toml ('the co-tenant dual-write gains first-class roster retirement') — a known, not-yet-built follow-up, not a new discovery. Did not open a code PR: this touches the co-tenant lifecycle subsystem, which has 3 prior incidents (#3068 runaway mint, #3219 fix, unit-612 stranded-lease), and the right fix depends on a judgment call about which AppFolio field should win.

Make removal stick, alwaysthe raiser's pick Trust the roster list, not the lease field Leave it, revisit if it recurs I'm not sure — go find out

Why, and what was tried

The session raising this recommends: Make removal stick, always
Matches intent already written in the code's own comments ('once a co-tenant has been reconciled off a lease its archived row must stop feeding...') and is the reconciler's own stated exit criterion — the known missing piece, not a new design.
Tried first, unsuccessfully: Read the alert, traced the exact occupancy row in propflow-prod via smith-db (status flipped active→former→active within 23s), read the reconcile job, the two sync paths that undo it, and the job's own written exit criterion + prior design history to confirm this is a known, named gap rather than a fresh bug.

1345c6a7 is parked on this.

Pick an option above, then press Done.