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" and "Take it to the engineering bridge" are real answers.

1

In plain terms. Should I merge a duplicate JPCO contact caused by a one-letter name typo, and should I also loosen the check that created it?

The full question, as raised

identity_contact_match_refused fired for org_jpco: an inbound signal for 'Julia Tsutsui' (juliatsutsui@gmail.com) matched the existing Person pers_874c6f22 ('Juria Tsutsui', same email, same live ProspectInquiry/tour) on email, but reuseAllowedByName's STRICT per-field name comparator (person-stamp.ts's email-race-winner branch, ~line 2490) refused because 'juria' != 'julia' exactly, minting an empty duplicate Person pers_c56d9065 with zero claims. Root cause: this branch always uses isNameCompatiblePerField with default (strict, exact-match) tolerance, never the 'lenient' Damerau-Levenshtein typo budget (min token len 5, max distance 1) that already exists in name-compatibility.ts for a different caller — Juria/Julia is edit-distance 1 on two 5-letter tokens, exactly inside that budget. Two separate questions: (1) merge the two Person rows now via POST /api/admin/identity/merge (soft-redirect, audited, non-destructive) — a prod-data write needing a human's direct OK per the prod-data-ops rule; (2) whether to widen reuseAllowedByName's tolerance to 'lenient' for this call site, given person-stamp.ts's own comments say this exact strict-vs-lenient split is deliberate and the branch was hardened after a real 2026-10-08 overmerge incident — a wrong widen risks gluing together different humans who share a contact.

Merge the duplicate; leave the name check as-is Merge the duplicate; loosen the check for 1-letter typosthe raiser's pick I'm not sure — go find out Take it to the engineering bridge

Why, and what was tried

The session raising this recommends: Merge the duplicate; loosen the check for 1-letter typos
The typo-tolerant budget already exists elsewhere in the codebase and is narrowly scoped, so it reads as the same tradeoff already accepted — but it touches a guard hardened after a real overmerge incident, so I want it confirmed rather than quietly widened
Tried first, unsuccessfully: Pulled both Person rows + claims from propflow-prod (smith-db), confirmed the existing Person's own email literally spells 'julia', traced the exact refusal branch and comparator in person-stamp.ts/name-compatibility.ts, and swept 'blocked outstanding' for an existing open decision on this cause (none found) before raising

ed00c1e6 is parked on this.

Pick an option above, then press Done.