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 the auto-merge that fixes duplicate contact records also check names before combining two people who aren't on a lease yet, so it can't undo the rule that stops two different renters who share one phone from being glued together?

The full question, as raised

decideIdentityMerge's guest-card-pair name gate (identity-merge-decision.ts:400-419) only runs when hasGuestCardOnlyPmsExternalIdClaim is true on one side. A pair of Persons with NO PMS claim at all (plain contact-only / inbound-signal records, neither lease-anchored) skips the name check entirely and merges on shared phone/email alone (duplicate_contact_value, 2026-08-14 ruling). That is exactly the cohort ensurePersonForTenant's contactLadder:false strict name guard (tenant-spine-stamp.ts:713-718, 2026-09-24 ruling: 'a recycled/shared unit phone must not silently fold two households') was built to protect — so the healer can silently reverse that protection within under a second for any two non-anchored people who share a phone and have different names. Confirmed today by this exact alert: the mint-time guard correctly refused pers_bbbc351c vs pers_9c28bb23 as a name mismatch, then the healer merged them 420ms later with zero name check (this pair happened to be a nickname variant of the same real person, so the merge was right by luck, not by the gate working).

Add the name check for these cases toothe raiser's pick Keep merging on shared phone alone I'm not sure — go find out

Why, and what was tried

The session raising this recommends: Add the name check for these cases too
The Sept 24 ruling exists specifically to stop a shared household phone from gluing two different renters together; today that protection gets undone for any contact-only pair without anyone deciding it should.
Tried first, unsuccessfully: Read the guard and the healer directly (person-stamp.ts:2227-2261, name-compatibility.ts:345-372, identity-merge-decision.ts:279-429), pulled the two real person records from propflow-prod and confirmed they were already auto-merged, and checked 'blocked outstanding' for a prior question on this — found two resolved-but-different ones (b90219772: guest-card join when names match; b90254956: turn off an old claim), neither covering this generalized gap.

f8221f32 is parked on this.

Pick an option above, then press Done.