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.
1propflowaicalendar@outlook.com (the emailIntegration on the internal Test Property, appfolio-45/'The Willows' sandbox, org_sandbox) hit AADSTS70000 'User account is found to be in service abuse mode' on token refresh, in the lead-received-outbox-drain cron (Sentry JAVASCRIPT-NEXTJS-1A2). This is a permanent, non-retryable Microsoft-side lock, not a code bug — no amount of retrying will clear it. Impact is contained: no customer property uses this mailbox (Camellia is the only live customer property), and property-graph-sender.ts already falls back to SendGrid on a Graph token failure, so mail kept sending. But nothing marks the connection dead anywhere a human would see it (EmailIntegration has no status/needsReconnect field, unlike the org-level ChannelAttachment path), so it will keep silently failing-and-falling-back until someone reconnects it by hand through Microsoft's account-recovery flow. Separately: this property is used by the eval/stress-test harnesses (evals/replay-harness, scripts/_willows-blocks-guestcard-harness.ts, sms-stress), which is a plausible (unverified) trigger for Microsoft's abuse detection given the volume those harnesses can generate against one mailbox.
In plain terms. Microsoft locked one of our own test mailboxes for 'account abuse' and it can't refresh anymore — should someone reconnect it now, or find out what triggered the lock first?
The session raising this recommends: Check what's flooding it, then reconnect It's a test mailbox with zero customer impact right now (SendGrid fallback covers delivery); reconnecting blind risks an immediate re-lock if something is still hammering it, so a quick check first costs little and avoids repeating this. Tried first, unsuccessfully: Pulled the Sentry event + stack trace (inbox-client.ts's token-refresh path), confirmed it's a single first-time occurrence via the Sentry API, traced the conversation/property through smith-db to appfolio-45/org_sandbox and confirmed the mailbox address and expiry, confirmed the SendGrid-fallback behavior by reading the send router, confirmed no existing open block covers this cause, and confirmed the per-property email integration has no reconnect-status field to surface this automatically.