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 test calls to our practice building keep paging engineers the same way a real tenant problem would? Our test calls to the practice building sometimes get correctly turned away because the caller isn't a real tenant on file. Right now, every one of those turn-downs pages engineers exactly like a real emergency. That has happened four times, three in one night, and the deeper question — why a caller who gives a name and unit still gets turned away — has gone unanswered for a month. What should we do?
The full question, as raised

guard-rejection-alert.ts (src/lib/domain/escalation/) posts to #alerts whenever a tool guard (identity_mismatch) refuses a call at a property with no escalation owner. The Willows (appfolio-45, Property.isTest=true) is the voice/SMS eval bench — every automated test call that trips identity_mismatch there pages #alerts exactly like a live incident. Fired 3x tonight (2026-10-01 ~02:00-05:00 CDT, voice channel: conv_voice_e5f0ad6e-149d-44da-87fb-fc9c55ad6982, conv_voice_64b2ca56-e0c7-4a67-9fe2-9db1f340fbc8, conv_voice_fd57db41-b413-4dda-be3e-b57ed60402b6) and once before on 2026-09-01 (SMS channel, nightly maintenance-eval's handyman-create-served-vacant scenario, conversation 1582b1e5-8a30-451d-8d4c-1e1c35a720a5) — that earlier page asked Fede to trace the exact IdentityMismatchError throw site in handle-create-work-order.ts and got no reply in 30 days. isHarnessSuppressed() (src/lib/testing/page-guard.ts, src/lib/testing/outbound-guard.ts) only suppresses this for in-process test runs with HARNESS_SUPPRESS_OUTBOUND=1 set; a real Twilio/ElevenLabs voice call never carries that env var, so every live eval call against the bench numbers pages for real regardless. A secondary cosmetic defect: on voice, the matter's captured 'question' field is Clara's own line ('Okay — let me get the details on that right away'), not the caller's actual ask — worth a follow-up, not this decision. Options: (a) add a presentation-only mute/dedupe keyed on isSandboxProperty() in guard-rejection-alert.ts/open-matter.ts's dispatch (keeps PR #6712's original goal — surfacing guard failures — intact via a log/quieter channel, just stops nightly #alerts noise); (b) leave alerting as-is and get someone to actually trace why create_work_order / the voice post-call sweep can't resolve a self-reported caller's identity; (c) pause/skip the test scenario(s) producing this until traced. Not attempting an autonomous fix: the underlying identity-guard code carries real correctness risk if patched blind, per the 2026-09-01 assessment.

Why, and what was tried
The session raising this recommends: Stop paging engineers for these test calls; just write them down instead
The page itself is harmless test traffic, not customer harm — muting it stops the nightly noise while the real caller-identity bug still needs its own owner to trace.
Tried first, unsuccessfully: Pulled the real conversation + matter rows from propflow-prod (org_sandbox, appfolio-45=The Willows, isTest=true), confirmed the caller is the phone registry's dedicated Voice-Eval 'Unknown Caller' test number transferred toward the hunt-chain fake-person bench line, read the full voice transcript (scripted tenant persona, kitchen-sink leak, caller hangs up before Clara can finish), checked config/automations.toml for a matching nightly schedule (none found — likely ad hoc/CI-triggered, not a known cron), searched #alerts history and found 3 identical pages tonight plus a 2026-09-01 instance already diagnosed by a prior run and raised to Fede with zero reply in 30 days. Did not attempt a code fix to the identity-guard logic itself given the prior run's explicit correctness-risk warning on that code.

a362ada9 is parked on this.

Pick an option above, then press Done.
PropFlow Docs