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 we turn texting back on for 4 prospects whose first-contact messages got silently cancelled by Fede's Oct 8 duplicate-card cleanup, or leave them alone for good?

The full question, as raised

4 prospectOutreachWorkflow executions (9d00993d, 14a7d4e1, 3a810603, d4d975e0) were TERMINATED via manual 'temporal workflow terminate' (identity federicochapa@Federicos-Mac-mini.local, reason 'duplicate card cleanup, Fede 2026-10-08') during a Person-merge. Confirmed via DDB: all 4 ProspectInquiry rows survive, re-homed to a NEW survivor Person (not deleted) — outreachCadenceAnchorIso still set, outreachCadenceCompletedAt/outreachCadenceOutcome absent, outreachTouchIndex absent (zero touches ever sent on any of the 4). Because the anchor is set, outreach-reconcile's isReconcileCandidate guard permanently skips re-enrolling them (anchor must be ABSENT). They will keep re-paging leasing_workflow_health every 24h until a human decides: re-enroll (docs/runbooks/prospect-outreach-recovery.md Option A/B) or hand-stamp closed. Root cause: scripts/ops/merge-duplicate-persons.ts migrates DDB rows only — zero Temporal/workflow awareness — so a live or anchored outreach cadence on a merged inquiry is silently orphaned every time that script (or an equivalent manual merge) runs.

Turn their texting back onthe raiser's pick Leave them alone for good I'm not sure — go find out Take it to the engineering bridge

Why, and what was tried

The session raising this recommends: Turn their texting back on
Each is a distinct, never-contacted lead for its own property under a survivor person who also has OTHER active/completed inquiries — nothing ties these 4 specifically to whatever was actually duplicated.
Tried first, unsuccessfully: Verified via temporal workflow describe/show (termination reason + input payload) and direct DDB reads (GetItem on the original PERSON partition = gone; GSI3 INQ#<org> query = found intact under a new Person) that the rows moved, not deleted, and never got a touch. Checked blocked outstanding first: only b91430413 matches the theme (duplicate-Person merge race, 3 orgs) and is already RESOLVED ('dry-run merge first') — it covers the merge itself, not this outreach-cadence side effect, so nothing to adopt.

80327c2c is parked on this.

Pick an option above, then press Done.