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. Tonight's maintenance quality-check failed all 3 tests because our test tenant's phone number got confused with someone else's in a different company's data — can I fix it by giving our test tenant its own dedicated number, even though that also turns on about 20-30 real text messages a night to that number going forward?

The full question, as raised

morpheus-nightly's 3 generated goldens (gen-i3-pivot-ambiguity-bathroom-mirror-cracked/closet-door-track/sink-leak-pooling) all failed 0/3 tonight with identical shape: 'drafted 0 WO(s)' + Composed capabilities=LEASING,ESCALATE_PM,CONVERSATION_CLOSURE identity=unknown on every turn. Reproduced live against propflow-prod: getTenantByPhone('+12065551001','appfolio-45') -> null, resolveIdentity(...) -> type:'unknown'. Root cause: the eval bench tenant's (pers_653bb3b4, appfolio-45/TEST-204) PRIMARY phone claim is +12065551001, a widely-reused fake '555'-exchange test number. A completely unrelated Person (pers_a9fccb0c-..., org_53047a06-...) independently claimed that SAME number as PRIMARY via their own appfolio_sync backfill, verified 2026-09-22 -- 12 days more recent than our tenant's 2026-09-10 claim. findPersonByPhoneAcrossOrgs's cross-org tie-break (claim-selection.ts pickPrimaryClaim) picks the most-recently-verified claim among tied trust tiers, so it now resolves our injected sender phone to the OTHER org's Person (no occupancy at appfolio-45) instead of our bench tenant. getTenantByPhone returns null, resolveIdentity falls through to unknown, composeCapabilities (identity-gated, not intent-gated -- same shape as PR #4437) grants LEASING only, so Clara can never call create_work_order no matter what the tenant says -- one shared cause failing all 3 maintenance-creation checkpoints identically. The fix already exists and is HALF-applied: scripts/seed-maintenance-eval-tenant.ts was built (PR history ca67b96732a / 288c6bf16f3) to move this bench tenant off the collision-prone fake number onto a PropFlow-owned unique tester line, +17202122112 (config/phone-registry.json kind=tester). Live DynamoDB read confirms step 1 (addClaim) ran 2026-09-06 -- the +17202122112 claim exists, active, non-primary -- but step 2 (promoteClaim) was never applied, so the migration stalled and the old colliding number stayed primary. Running 'npx tsx scripts/seed-maintenance-eval-tenant.ts --apply' against propflow-prod promotes +17202122112 to primary (demoting +12065551001 to active-secondary), which fixes tonight's reds and prevents recurrence. I did not run --apply myself: the script's own dry-run output says explicitly 'After applying, the nightly eval sends ~20-30 REAL SMS/night to +17202122112. Announce + get a human go first.' -- that is a deliberate author-built gate on a recurring real-world side effect, which is exactly the kind of call this alert-triage charter reserves for a human.

Apply the fix nowthe raiser's pick Hold off, investigate more first I'm not sure — go find out

Why, and what was tried

The session raising this recommends: Apply the fix now
The number is already PropFlow-owned and registered as a tester line (config/phone-registry.json); the only new effect is the real nightly SMS sends the script was always built to enable, and leaving it unfixed means every maintenance-creation golden (and the nightly Morpheus quality watch that depends on them) stays red indefinitely.
Tried first, unsuccessfully: Reproduced the failure live against propflow-prod (getTenantByPhone + resolveIdentity both miss), read all 3 failing scenarios' full transcripts (same 'drafted 0 WO(s)' + identity=unknown shape on every turn), traced the identity code (resolve.ts waterfall, claim-selection.ts pickPrimaryClaim, persons.ts findPersonByPhoneAcrossOrgs), and confirmed via direct DynamoDB queries (phone-index GSI) that 3 different orgs' Persons all hold a 'primary: true' non-deprecated claim on the exact same fake test phone number, with the colliding org's claim now verified more recently than ours. Found the pre-built remediation script and confirmed via live read that it is already half-applied. Stopped short of running --apply myself only because the script's own text asks for a human go-ahead before arming nightly real SMS.

388e4ec1 is parked on this.

Pick an option above, then press Done.