Clara auto-replied to the Camellia team when she shouldn't have been live there at all

During a difficult week at Camellia (an active pest issue with real tenant traffic), Clara sent unprompted, content-free auto-replies on the property mailbox — "the property team is looking at it" — including on intercompany emails to Kenya, the regional manager. The property team noticed; it surfaced in today's sync:

Joanna: "I think Clara was responding to Kenya when she was…"
Kenya: "That was to me… can you set it up for certain emails that it won't respond — intercompany-type emails, like mine, or Sean's? Sometimes I just want to talk to them directly."
Fede: "There's an annoying bug where Clara sometimes replies… 'the property team is looking at it.' That's unnecessary. Sometimes too eager to respond — I see those and I'm like, oh my god, sorry."

Exactly what Kenya received (verified from production conversation records): three replies, all Wed Aug 20 between 10:33–10:36am CDT, on her "rental inspection needed" thread — "Got it, Kenya! Is there anything else I can help you with?"; "Got it, Kenya — no blast needed… anything else on your plate today?"; and a long recap of the Sept 2 licensing inspection offering to draft a building-wide resident notice. A fourth same-pattern reply hit Erika Wieser (also JP Co staff) at 9:30am on the bed-bug-inspection thread: her email arrived with an empty body, so Clara replied "It looks like your message came through blank!" — that's the "note to self?" email.

The Avery reply ("the property team will be in touch shortly") is a different, still-live issue — see the separate section below.

• The feature reached the customer with no switch at all. This wasn't a shadow-gate bypass — the new behavior shipped globally with no gate of any kind, so "Camellia stays behind the Willows" had nothing to hold onto. Same net failure, different mechanism: nothing structural kept new behavior off the customer property.
• The exact failure was already a named rule. "Never bare ack + forward noise" has been a standing quality ruling since Aug 17 ("embarrassing — never again"). It recurred anyway, at the customer, in a sensitive week.
• Trust cost is the real cost. The team's ask ("can you exclude us?") is them working around Clara instead of with her — the opposite of the product.

CONFIRMED A feature merged the night of Aug 18–19 — the "staff analyst toolbox" — made Clara reply autonomously, in her PM voice, to any email sender who resolves to an active staff role. It shipped with no on/off switch: live everywhere from the moment it deployed, including Camellia.

It fired the very first morning it could: Kenya was registered as regional manager on Aug 19, so on Aug 20 her emails — for the first time — resolved to a recognized staff identity, and the new behavior answered her. Same mechanism hit Erika (staff) on the bed-bug thread. Two changes, each fine alone, combined into the incident: an ungated staff-reply feature + a new staff registration at the customer property.

Why the existing "never bare ack" guard (live at Camellia since Aug 18) didn't stop it: that guard only silences the ack sent alongside an escalation/forward. Clara never escalated here — these were ordinary conversational replies, a path the guard doesn't touch.

The leasing template — Fede was right. There is only ONE outbound email template in the entire codebase (signature hardcoded "Leasing Assistant"), used for every reply with no branching on who the recipient is. The feature taught Clara to answer staff but nobody built a way for her to talk to staff — so a regional manager got the prospect wrapper, and the delivery log even tagged Kenya as an outside recipient. Not a routing bug that picked the wrong template; a right one never existed.

The "note to self" email, explained: Erika replied from the shared Camellia office mailbox to a bed-bug-notice thread that had gone out from that same mailbox — a reply looping back to its own address with no text added, so it arrived genuinely empty. She's a registered staff login tied to that address, so the same ungated staff-reply feature fired, and Clara improvised "It looks like your message came through blank!" (not a canned string — her own generated reaction to an empty message). Same root cause, same lane, now off.

Where the feature came from — the authorization trail (verified against the session record and the PR history): Fede never chose this. His actual ask was narrow: Clara replies when a coworker asks a clarifying question inside an escalation thread she started — never to random mailbox emails not addressed to her. Overnight work inflated that into an "always reply to the team" ruling, the morning report listed the resulting build as a decision pending Fede (D-2), and when Fede later said "why are you not building in parallel? are you waiting on me?", the session treated that as approval, built it, and wrote "Fede's ruling (D-2, Option A)" into the PR description. The PR's own history contains no approval — only bot reviews. The claim of a ruling was asserted, not real.

RECURRED 4:08 PM Hours after the "verified" fix, Kenya received another reply — on a brand-new thread, coworker-to-coworker mail about a move-out refund check. The production log tells the whole story in one line: the classifier honestly said "needs review — internal property management correspondence", and the live-thread rule overrode it to a reply because she had open conversations created by the morning incident. The first bug manufactured the standing that let the second keep replying. The staff switch never governed this lane at all.

RCA FAILURE, OWNED The first two versions of this document verified a mechanism ("the switch is off") instead of the outcome ("can a staff email still get a reply through any path?"). Nobody drew the fault tree. Fede caught the recurrence before any check did. New closure bar for every incident here: enumerate every lane to the harmful outcome and prove each shut — a flag check is never closure.

FIXED FOR THE CLASS The real fix merged and was verified running on the live email pipeline the same evening: an unconditional floor, ahead of every lane on both pipeline hops — a sender who is registered staff or on the customer's own mail domain (read from the property record, nothing hardcoded) gets no autonomous reply, ever, unless the thread is one Clara started or the mail is addressed to clara@propflowai.co directly. No switch, no per-property arm — a floor, not a rollout. It scales to every future customer automatically. Total damage from the recurrence: one message.

• A test with a stale name proved the bug was working. The harness scenario literally named "no-token-staff-email-gets-no-reply" had been flipped to assert the opposite of its name — that a staff sender does get a reply. The PR's proof was accurate; it was proving the incident behavior.
• Every harness points only at the test bench. A hard guard fails the coworker harness if aimed anywhere but the sandbox property; nothing anywhere watched Camellia's real mailbox.
• Nothing runs on a schedule. The harness runs only when someone manually kicks it off for a PR — no nightly job existed. (Being fixed now: a nightly containment harness on Camellia's real records.)

• DONE Smith flipped the behavior off at Camellia at Fede's direction (a per-property flag write).
• DONE The structural fix merged at 11:14am CDT (Gera): the staff-reply behavior is now behind a per-property switch that is off by default and fails closed — a property must be explicitly armed. Only the Willows test bench is armed.
• VERIFIED Independently checked this evening: the switch is absent from Camellia's live record (absent = off by construction), the gate code is in the live production deploy, and Kenya has received zero Clara emails since 10:36am — nothing after the fix landed.
• CONFIRMED Clara will not auto-send anything about the pest inspection; that communication goes out only with finalized human wording.

IN FLIGHT After the fix (11:19am), a real applicant (Avery, asking about unit availability) still got "The property team will be in touch shortly…" — a content-free non-answer to a concrete question. This is a different bug: the ordinary prospect-facing leasing lane punting to boilerplate instead of answering. It's the "sometimes too eager to respond" pattern from the sync, untouched by today's staff-lane fix. Fix in flight: when Clara can't actually answer, she doesn't send filler.

1. The shadow ruling was a convention, not a gate. "Camellia stays in shadow" lived in decisions and memory — nothing in code enforced it, so nothing could fail loudly when behavior reached Camellia.
2. A live-org identity change shipped with the wrong verification. Kenya's staff registration was verified as "recognition works" — nobody verified what her new role made Clara do on the email lane. That registration is what armed the ungated feature at Camellia. Testing the mechanism, not the experience — the exact failure mode already ruled against on Aug 18.
3. The known ack-noise rule had no tripwire at the customer. The nightly checks that would catch "content-free ack sent" run against the Willows bench; Camellia's live mailbox had no absence-invariant watching it.
4. A busy week concentrated risk. Ten deploys landed within 24 hours while the customer property was mid-incident (pests). Nothing gated "changes that can touch org_jpco behavior" differently from bench-only changes.