Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1propflowai's maintenance-eval-daily job collapsed from a steady 17/21 (3 prior nights) to 10/21 tonight (2026-09-23). 4 brand-new failures (tenant-disposal-create, tenant-emergency-urgent, tenant-oven-create, tenant-specialist-handyman-assign) plus 3 known-chronic scenarios that changed signature (handyman-close-with-photo, handyman-relay, handyman-reverse-relay-roundtrip) all share one shape never seen the prior 3 nights: gatherActivity returns workOrderCount:0 -> outcome:noop -> zero WorkOrder rows ever persisted on the conversation. Only TENANT-initiated scenarios failed this way; HANDYMAN-initiated and voice scenarios all passed. The maintenance worker build running tonight (git sha 8778bfa44f, PR #10984) differs from yesterday's (56b3dc614c15) by roughly 150 merged commits -- an unprecedented overnight wave of auth/identity/org-scoping hardening PRs. Investigated the identity-relevant candidates: PR #10772 (dev persona-switcher fix) is explicitly production-byte-identical per its own PR body -- ruled out. PRs #10743/#10745/#10746/#10750 (PersonRole validUntil row-clock) are explicitly LATENT -- nothing writes the clock field yet, so every row today still reads as no_clock -- ruled out. Leading, UNPROVEN suspect: PR #10756 ('a known tenant never gets a ProspectInquiry or guest card') adds a KnownTenantRefusalError thrown from resolveProspectIdentity whenever an inbound sender resolves to a known tenant; every current call site (tools-leasing.ts x2, process-tour.ts, postcall-prospect-capture.ts) catches it, so on a straight read it shouldn't reach the maintenance intake path -- but it is the only non-latent, non-dev-only behavior change in the whole diff that touches 'is this sender a tenant' classification, which is exactly the axis separating tonight's failures (tenant) from tonight's passes (handyman). No Sentry hit in the run window (07:10-07:44 UTC), consistent with a caught/expected exception rather than a crash rather than proof of no impact. Could not confirm real-tenant (Camellia, the one live production property) impact within this investigation's time budget -- a full DDB scan was too slow to complete; a targeted query needs faster prod access than available from this alert chain.
In plain terms. Should someone check right now whether real tenants' repair requests are silently not creating tickets tonight — or can this wait for the normal daily review?
Last night's automatic check on whether Clara can open a repair ticket for a tenant broke: most tenant-report test cases failed, and in every one, no ticket got created. This happened right after a large batch of security fixes went live overnight. I found one change that looks like the closest match, but couldn't prove it, and couldn't quickly confirm if real tenants are affected too.
The session raising this recommends: Check production for real dropped repair requests A resident's repair request silently going nowhere is worse than a wasted urgent check. Tried first, unsuccessfully: Pulled 3 nights of DDB pointer-row baselines (all 17/21, zero tenant-scenario failures) to confirm this is a new regression, not chronic noise. Cross-checked docs/ops/failure-notes.md: 7 of tonight's 11 failures are pre-existing escalated/chronic causes; the other 4 have never been logged before. Pulled the full Temporal history for today's eval run and decoded every failing scenario's grade result plus the underlying maintenance-workflow history to confirm the shared zero-WorkOrder-ever-created signature. Identified the exact maintenance-worker git build running tonight vs yesterday via workerVersion.buildId on the workflow task events, then diffed that exact commit range (~150 commits). Checked Sentry for unresolved issues in the run window -- none related. Read the PR bodies for the 5 most identity/auth-relevant candidate commits and ruled out 4 as latent or dev-only by their own stated proof sections. Attempted a live DDB scan for real-tenant WorkOrder creation on the one live property to settle prod-vs-bench-only, but it did not complete fast enough to include here.