Clara, the new hire: roadmap tracker

Advice on the order

His order holds and overrides the earlier "one module a day" cut. Day 0 freezes the baseline, because no refactor can be judged without it. Then the base is refactored first: one core engine, the four shared interfaces, no module with its own hand-off or its own escalation; the shouldSpeak chain (PR 2) and askTheTeam/askState are that work. His three priorities sit on top of that core, in his order: (a) Situs Group onboarding done well is Stage 1 work (the intro texts, proven at the Willows on Oct 25 from the building line; the ownership map; the hello per role; the feedback loop) and does not wait for the refactor, so it runs beside it from day 1, with the turn-on at Situs being his word; (b) the hand-off framework is habit B on the shared askTheTeam and askState, built from customer feedback (the hand-off audit: one in three hand-offs that needed a person never reached one; the Situs and Western Slope rows); (c) the Opus 5.5 upgrade is the Monday model plumbing on the frozen baseline, and tenant replies (maintenance first, since intake and the attach guard are live at Western Slope; renewals second, it already has the loop) ship dark behind the existing tenant-door setting and wait for the floors and his turn-on. The full-context hypothesis is benched on the frozen set before any prompt is rebuilt around it. Leasing and collections deep-dives leave this window. Proposed, pending his review.

The bench: how every change is judged.

Frozen sets, three arms, a judge with planted controls, one row per run on the Clara Bench page. First result, 261 repair episodes:

Next on the bench: restrictive-today vs full-context (top); frozen baseline v1 (Day 0); the new first-email writer in shadow (release plan); the repair path on Opus 5.5 (Thursday); Benchmark E, who is writing (not started).

Upgrade path to Opus 5.5

One model setting per path, byte-identical replay, then one path at a time: replies and the first email (moving), voice (about 61 calls a week on Sonnet 4.6, timed call test first), the repair chain, the Haiku 4.5 checks.

Cheap vs big

Cheap, this week: the staff-card rule, three bugs, thumbs as the judging surface. Not careful at all: delete prompt text no turn needs (~62k tokens per first reply; identical replay proves it). Careful: first-reply proof and go-live (a fix, no switch). Very careful: when to reply; dark, Fede turns it on per customer.

Engineering detail

Tenant benches (rules prompts, not production)

Four repair cases: same order or new order?

Shipped Oct 25, and open

1. Decisions for you

"Heard today" is what I took from your call with Gera; it is my reading, not confirmed.

Update, Oct 25 evening (Benchmark lane): Day 0 is done; the frozen baseline v1 and its numbers are recorded on the Day 0 roadmap row. Nothing in it needs a decision from Fede.

Also heard: you own the baseline cleanup (prompt diet, no-reply groundwork, model upgrade, replay bench); Gera keeps the maintenance flow and gatekeepers.

The release plan for any new writer on a live path, starting with the first email to prospects, with its two questions:

0c. Release plan: a new writer on a live path (Proposed, Oct 25 — pending Fede's review)

Template for every path that moves to the split prompt and Opus 5.5, starting with the first email to prospects. A new writer is a new capability on a live path, so it ships behind a company setting (default: today's writer) that is deleted the week the rollout ends. Fixes found along the way still ship with no switch.

Decisions for Fede: (1) Which company goes first in stage 2? Recommendation: Western Slope (highest volume, staff already review Clara's emails daily). (2) Shadow at all three companies or Western Slope only? Recommendation: all three; shadow sends nothing.

Dark: company.firstEmailWriter (today / new) | feature: first email to prospects written by the split prompt on Opus 5.5 | proof: pending (shadow pairs, stage 1) | turn-on: Fede.

Fifteen real first emails, today's Clara and the new one side by side; Fede's marks decide whether the new one goes live:

13. Your review set: new first email vs today's (Oct 24 night)

How this was run. The new prompt was frozen and run 3 times, back to back with today's prompt in the same hour (about 65 cards per run, plus a Spanish slice of 4). Cards whose inputs changed between the two writers are left out. The pairs below come from the last run. Names are kept. Phones and emails are removed. A red dash marks where the email used an em or en dash.

The numbers, three runs (run 1 / run 2 / run 3)

Pairs compared per run: 66 / 67 / 64.

What stands out

• The four you graded (#1 to #4 below, your #25 #26 #27 #30): new Clara is at least as good on all four in every run. No dashes, no dropped questions. Today's Clara dropped what the renter quoted on your #30 in all 3 runs.
• Worse on new Clara: it puts more answers off (about 6 against 3 per run) and runs longer (about 68 words against 52).
• Naming extra homes: both writers did it on about 5 cards per run (15 for new, 14 for today over 3 runs). The earlier 6 against 3 did not repeat. It still breaks your one-home rule, and #9 shows it. The fix is written and ready for the next cycle after your marks: name only the home they asked about, others only when they ask.
• One invented fact: on #4, new Clara says the home "comes with its own private yard space". It took that from a smoking rule ("allowed outdoors in your own fenced yard"). The fact check did not catch it.
• Note-shaped drafts: 2 of about 200 new drafts were notes about the renter, not emails. The new send check holds both. One needed a small follow-up fix to that check, merged Oct 25 evening (#22336), live everywhere, no switch.
• Bench clock mix-up: "held by the date check" on #1 and #10 is a bench artifact. The writer's clock said Friday and the check's clock said Saturday. Live, both use the same clock.

From the frozen runs on Oct 24, 9:11 PM to 11:20 PM MT. The production change for the new first email stays on a local branch, with no test runs, until you mark these.

The four repair cases in full, with a blank for Fede's call on each (summary in tenant communications):

Four repair cases for your call: same order or new order?

Written Oct 25 from the repair benchmark. Two of these (cases 2 and 3) are wrong attaches in the accepted prompt itself, not duplicates: the report went onto an unrelated open order because the matching order was not in the list Clara saw.

Four real Situs Group tenant texts. Each time an open work order was nearby, and the question is whether Clara should add the report to it or file a new one. "Clara" below is the accepted version (3b, the production prompt split into pieces, running on Opus 5.5). It is a replay only; nothing was sent. Times are Mountain time.

Two things to know first:

• In cases 2 and 3, Clara (3b) did not file a duplicate. She attached the report to an open order for a different thing (the AC, and a bathroom faucet). That is a wrong attach.
• "Open orders as the harness saw them" is the list Clara's intake step got. Older orders that only appear in the tenant's history are listed separately.

1. Beate Burgess, Lampliter, new stove vs the roach order

Tenant text (Fri Aug 28 2026, 5:12 PM, replying to the office's pest-prep message):

Thank you for sending these

I will get this list completed

I would really like a new stove soon too please. I can't think about using that after what I saw crawling out of it.

Open order the harness saw:

• LAMP-18152, "Cockroaches": "Resident Update 08/26/2026: They are also in the bathroom. Tenant reports cockroaches coming out of the stove after using it Monday evening. They are now seeing roaches in the kitchen and have requested full roach treatment (they believe last time only one treatment was done instead of three)."

What the office did: On Aug 31 it created a separate stove order, LAMP-18184, "Stove roach infestation: Please inspect the stove, as the tenant reports it is heavily infested with roaches and is requesting a replacement." It asked for permission to enter. Beate said yes and added: "I had added this to the roach submission on the portal but maybe I should have made it a separate one." The office replied: "I have created a separate work order."

What Clara (3b) did: She filed a new order for the stove and added a note to the roach order about the prep list.

Ugh, I'm sorry you saw that, Beate. No wonder you don't want to use the stove. Your stove request is in as work order LAMP-18717, but replacing it needs the team's approval, so I can't promise that part here, and there's no scheduled time on it yet. I've also added a note to LAMP-18152 that you're working through the prep list.

(Our labeler counted this as a duplicate of the roach order. The office made the same choice Clara did.)

Question: Is a new-stove request after roaches came out of the stove the same order as the roach treatment, or a new order?

Fede's call: ______________________

2. Cornisha M. Dockins, Lowry, washer and dryer vs an older dryer order

Tenant text (Sun Jul 12 2026, 11:17 AM, answering the office's Jul 10 question about the dryer):

Good morning I believe there's a problem with the washer and the dryer. The washer does not retain enough water to wash the clothes. They don't really be wet after the cycle is done then when you put them to the dryer by time, the cycle of the dryer is done. The clothes are already mild dude. I believe they need a replacement.

("mild dude" is most likely "mildewed".)

Open order the harness saw:

• LOWR-17614, "Air Conditioner": "Tenant reports their swamp cooler/AC broke again. AC is set to cool but there is no air blowing at all. Maintenance previously changed a belt last week because it broke, and tenant believes the belt has broken again."

In the tenant's history, status unknown, not in the harness's open list:

• LOWR-17113, created May 9 2026, "Dryer filter service": "DRYER: Sorry, one last thing my dryer is telling me that it needs a filter and when the dryer is on, it's so hot in here we can't even breathe."

What the office did: No work order in our copy. The next office message (Jul 13) was about an outstanding balance.

What Clara (3b) did: She attached the washer and dryer report to the AC order (a wrong attach).

Good morning Cornisha, ugh, mildewy laundry is the worst. I've added the details to work order LOWR-17614: the washer isn't filling with enough water, and the clothes come out of the dryer smelling mildewy. Replacing the machines isn't something I can approve here, but the tech will see your note when they look at both machines.

Question: If the May dryer order were still open, would this report go on it, or is a washer and dryer that do not work a new order? (Either way it never belongs on the AC order.)

Fede's call: ______________________

3. Marly M. Ochoa, Woodside, kitchen odor extractor and roach/fly fumigation

Tenant text (Wed Jul 22 2026, 12:57 PM):

Buenas tardes , para preguntar sobre una solicitud que hice hace días para la revisión de mi extractor de olores de la cocina y para una fumigación de cucarachas y moscas

English: Good afternoon, I'm asking about a request I made a few days ago to check my kitchen odor extractor and for a cockroach and fly fumigation.

Open orders the harness saw:

• WOOD-17721, "Cockroaches": "Resident Update 07/21/2026: Tenant update: requesting pest control/fumigation due to many cockroaches and many flies in the unit."
• WOOD-17489, "Other Maintenance - Not Listed": "Bathroom sink: the faucet handle/knob is loose/detached."
• WOOD-17490, "Drain/Pipe Clog": "Bathroom sink: the sink drains very slowly."
• WOOD-17254, "Lighting": "Bathroom vanity light bulbs have burned out."

In the tenant's history, status unknown, not in the harness's open list:

• WOOD-15393, created Sep 22 2025: "KITCHEN HOOD: Tenant Marly called in to report the kitchen hood is not turning on." It also carries the Jul 21 pest update.

What the office did: Replied: "Your unit has been added to next week's pest control schedule and will be treated during the scheduled service." It filed no order for the kitchen hood. The next day it filed an unrelated garbage disposal order (WOOD-17738).

What Clara (3b) did: She put the fumigation on the roach order, which is right, and the kitchen extractor on the bathroom faucet order, which is a wrong attach.

Buenas tardes, Marly. La fumigación de cucarachas está en la orden WOOD-17721, que está abierta y asignada a Situs Real Estate Corp. Ya le agregué que también necesita tratamiento para las moscas.

La revisión del extractor de la cocina está en la orden WOOD-17489, que también sigue abierta. Por ahora ninguna de las dos tiene una fecha programada.

English: Good afternoon, Marly. The cockroach fumigation is on order WOOD-17721, which is open and assigned to Situs Real Estate Corp. I added that it also needs treatment for the flies. The kitchen extractor check is on order WOOD-17489, which is also still open. Neither one has a scheduled date yet.

Question: The kitchen hood is not on any order Clara can see as open. Should Clara file a new order for it, or treat it as the old September hood order?

Fede's call: ______________________

4. Karin R. Rodriguez Perez, Lampliter, AC leaking water vs the outside spigot order

Context: The day before, office teammate Deiby Magana texted: "Buenas tardes Karin, si te arreglaron tu aire? Me dijo mantenimiento que esta semana van y te lo remplazan como sea con uno mas nuevo." (English: Good afternoon Karin, did they fix your AC? Maintenance told me that this week they'll go and replace it with a newer one either way.)

Tenant text (Sun Jul 26 2026, 11:42 AM):

Hola buenas tardes si fíjate que si pero fíjate que se sale agua mucha agua porque tengo que poner trapos

English: Hi, good afternoon, yes it was, but a lot of water is coming out and I have to put down rags.

Open order the harness saw:

• LAMP-17337, "Exterior spigot uncontrolled leak": "Water spicket on outside of building next to unit is shooting water straight out & can't be turned off."
• There was no open AC order in our copy.

What the office did: Two days later (Jul 28) it filed a new order, LAMP-17787, "AC unit water leak: The tenant reports that the AC unit keeps leaking water."

What Clara (3b) did: She added the AC leak to the spigot order (a wrong attach) and reported it to the team.

Hola Karin, qué pena que el aire esté soltando tanta agua. Ya lo agregué a su orden LAMP-17337 y le avisé al equipo de la propiedad que es urgente. Mientras tanto, si puede, apague el aire desde el termostato para que deje de salir agua.

English: Hi Karin, sorry the AC is letting out so much water. I added it to your order LAMP-17337 and told the property team it's urgent. In the meantime, if you can, turn off the AC at the thermostat so the water stops.

Question: An AC leaking inside and an outside spigot leak: same order or new order? (The office filed new.)

Fede's call: ______________________

Where the reviewers disagreed and what we chose

Two adversaries read the sources and the draft, not the conclusions: a Fable 5.1 reviewer (two rounds: the design, then a gap hunt) and an Opus 5.5 reviewer. Each item below shows both positions and the choice. Items marked "recorded for Fede" are where we kept his ask against the reviewers' advice, or left a conflict for him; they are recorded here, not asked (decisions for Fede holds three questions).

What each past effort contributed

# Clara's machine: verified facts (origin/main edfd125bdc, 2026-10-25)

Read only from `/Users/federicochapa/repos/propflowai-map-ro`. Every line: box name | what it does | proof (file : function) | who uses it.
Module tags: SH shared core, LE leasing, MA maintenance, RE renewals, TC tenant comms (resident questions; no module directory of its own).
Where last night's inventory (commit 47c1188a19) disagrees with today's code, today's code wins and the delta is named in "Deltas" at the end.
"UNVERIFIED" means looked for and not proven.

## A. Inbound channels and entry points

- A1 Text message (Twilio) | STOP/START/HELP handled first, then a message envelope is put on the inbound queue; if the queue is off or the message is too big, it is processed inline | `src/app/api/twilio/webhook/route.ts` : POST, `publishInboundMessage`, fallback `processEnvelope` | SH
- A2 Voice call transcript (after the call) | Phone is out of scope: the live call turn happens inside ElevenLabs. After the call, the transcript enters here and is written to the conversation; prospect and work order are captured | `src/app/api/voice/call-ended/route.ts` (re-entered by `lambda/inbound-processor/handler.ts` : `processVoice`) | SH
- A3 Email to our own address (SES) | SES stores mail in S3 and a Lambda puts a pointer on the queue; webhook fallback exists | `lambda/ses-email-forwarder/index.mjs`, `src/app/api/email/ingest/route.ts`; handler `processEmail` → `agents/clara/lib/email/process-inbound-email.ts` : `processInboundEmail` | SH
- A4 Connected Outlook mailbox (push) | Microsoft Graph webhook, writes an email intake record, then queues `inbox_email` | `src/app/api/integrations/outlook/webhook/route.ts` → `src/lib/domain/email/inbound-delivery.ts` : `deliverInboundEmail` → `src/lib/integrations/email/webhook-processors.ts` : `processNotification` | SH
- A5 Company mailbox pollers (pull) | Every minute, same path as A4; the Gmail poller skips companies that are not live | `lambda/company-mailbox-poller/handler.ts` (`pollCompanyMailboxes`), `lambda/gmail-company-inbox-poller/handler.ts` (`pollGmailCompanyMailboxes`) | SH
- A6 New guest card from the PMS | The AppFolio sync imports guest cards into the mirror and emits `lead.received`; a cron drains it into the first-email consumer | `lambda/appfolio-sync/handler.ts` → `src/lib/domain/pms/mirror/guest-card-mirror.ts` : `emitLeadReceived`; `src/app/api/cron/lead-received-outbox-drain/route.ts`; `src/lib/domain/leads/consumers/clara-first-email-consumer.ts` | LE
- A7 Reply on a guest card / PMS inbox | `wakeClara` queues a `pms_email` payload or a text envelope with carrier `appfolio`; the PMS inbox mirror wake does the same for renter texts on Clara's PMS thread | `lambda/appfolio-sync/handler.ts` : `wakeClara`; `lambda/appfolio-sync/pms-mirror-reply-wake.ts` : `mirrorReplyWake`; consumer `agents/clara/lib/messaging/process-pms-email.ts` : `processPmsEmail` | LE (PMS email), SH (text)
- A8 Staff texts and emails | No separate door: they arrive through A1/A3/A4 and are recognised as staff by the router (rung 1b), then get staff-desk tools | `src/lib/domain/identity/resolve-actor.ts` : `resolveActor`, called from `agents/clara/lib/messaging/inbound-router.ts` : `routeInboundMessage` | SH
- A9 Staff approve or answer a held draft | Slack thread replies, the dashboard held-email route, and the email staff-reply door (tagged reply key, exact approve/reject words) | `src/app/api/slack/events/route.ts`; `src/app/api/held-emails/route.ts`; `src/lib/domain/staff-reply/door.ts` → `resolve-held.ts` | SH
- A10 Video | Separate video turn surface | `src/app/api/video-turn/chat/completions/route.ts`, `src/app/api/video-clara/*` | SH (out of scope for the diagram beyond a mention)
- A11 Dashboard "reply as Clara" | UNVERIFIED: no production route found under `src/app/api` (searched takeover / as-clara / staff-reply patterns). The operator skill `clara-takeover` is tooling, not the app.

### The spine (queue to turn)
- S1 Inbound queue | One SQS FIFO queue, grouped per sender | `src/lib/integrations/sqs/client.ts` : `publishInboundMessage` | SH
- S2 Queue consumer | Routes envelopes to `processEnvelope`; older payloads (email, voice, inbox_email, pms_email, transfer_recording) through a switch | `lambda/inbound-processor/handler.ts` : `handler` | SH
- S3 Text lane | Wraps the turn with the supervised hold hook, then dispatches | `agents/clara/lib/messaging/process-envelope.ts` : `processEnvelope` → `routeAndDispatchEnvelope` | SH
- S4 Email lanes (3) | SES, Outlook/Graph (`processInboxEmail`) and PMS email all go through one record processor and a `deliver()` callback | `agents/clara/lib/email/process-email-record.ts` : `processEmailRecord`; `lambda/inbound-processor/handler.ts` : `processInboxEmail`; `process-pms-email.ts` : `processPmsEmail` | SH
- S5 Fixed-rule lanes (before any model) | In order: safety pre-empts (test menu, test-data guard, life-safety gas/CO lexicon with a canned evacuate/911 reply and a page, no model), scheduling lane, maintenance state-first lane, rating lane, maintenance intake lane, then the default lane | `agents/clara/lib/messaging/inbound-dispatcher.ts` : `dispatchInbound`, `tryPreempts`, `tryLifeSafetyPreempt`, `trySchedulingLane`, `tryMaintenanceStateFirstLane`, `tryRatingLane`, `tryIntakeLane` | SH (lanes are MA heavy: rating, state-first, intake)
- S6 Router rungs | Vendor check, PM confirmation and mass-comms replies, tenant email capture, staff via `resolveActor`, handler pipeline, tour pipeline, PM commitment extraction, then "always pass to Clara" | `agents/clara/lib/messaging/inbound-router.ts` : `routeInboundMessage` | SH (vendor, tour = LE)
- S7 Agent turn | `handleIncomingMessage` → `handleIncomingMessageTurn` | `agents/clara/lib/agent/conversation-manager.ts` | SH

## B. Per-turn inputs

- B1 Conversation history | Thread messages filtered for agent context, converted to model messages, trimmed to fit 80,000 estimated tokens (always keeps the first message plus the newest that fit; no fixed count) | `conversation-manager.ts` : `filterMessagesForAgentContext`, `buildClaudeMessages`, `applyContextWindow`, `MAX_CONVERSATION_TOKENS = 80_000` | SH
- B2 Knowledge block (not retrieval) | Full dump of company sections then property sections, minus retired items; fees rendered separately and left out for residents | `conversation-manager.ts` : `loadTurnPropertyContext`; `src/lib/domain/leasing/knowledge/leasing-knowledge-block.ts` : `buildLeasingKnowledgeBlock`; `agents/clara/lib/agent/property-knowledge-block.ts` : `renderPropertyKnowledgeBlock` | SH (named for leasing, used on every turn)
- B3 Who is writing | Identity resolution, tenant by phone, occupancy, spine name | `src/lib/domain/identity/resolve.ts` : `resolveIdentity`; `conversation-manager.ts` : `getTenantByPhone`, `resolveTenantOccupancy`, `resolveSpineNameView` | SH
- B4 Prospect and guest card | Prospect record by person, listing card for the reply | `conversation-manager.ts` : `getProspectByPersonId`, `resolveListingCardForReply` (`listing-card-for-reply.ts`) | LE
- B5 Lease answers | Lease-term context for resident questions | `conversation-manager.ts` : `resolveLeaseAnswerContext` | TC
- B6 Renewal state | Notice days and the renewal saga's paperwork | `conversation-manager.ts` : `loadNoticeToMoveOutDays`, `paperworkCopyOfSaga`; prompt block `buildRenewalPromptBlock` | RE
- B7 Turnover context | `conversation-manager.ts` : `resolveTurnoverContext` | MA (turnover)
- B8 Company and property settings | Team facts, company voice (never-say list + language), application-link mode, video tour link, tour hours, office hours | `conversation-manager.ts` : `buildTeamFacts`; `src/lib/domain/onboarding/company-voice.ts` : `readCompanyVoice`; `getOrgApplicationLinkModeForProperty`, `getOrgVideoTourLinkForProperty`, `readOrgTourHours` | SH
- B9 Persona | Name "Clara" is hardcoded; no per-company persona name field found (looked, none) | `agents/clara/lib/agent/clara-personality.ts` : `CLARA_CORE_PERSONALITY` | SH
- B10 PMS mirror | Mirrored PMS messages reach the turn only inside history (`msg.pmsMirror`, rendered by `mirrorBody`); no separate per-turn PMS lookup found | `conversation-manager.ts` : `buildClaudeMessages` | SH
- B11 Open asks and held state | Open escalation matters and the open-matter decision; hold state from the deferred reply row | `src/lib/domain/escalation/matter-context.ts` : `loadOpenMatters`; `conversation-manager.ts` : `decideOpenMatterTurn`; `agents/clara/lib/agent/deferred-reply-row.ts` | SH
- B12 Opt-out / mute | Suppression read at the start of the turn | `conversation-manager.ts` : `checkSuppression` (`muteGate`) | SH
- B13 Turn-time context messages | Injected as `<system_context>` user messages, not system prompt: completed actions, available units, open matters, cadence events, open homes, team answer, conversation state, recap, local date/time, scheduled wake (last) | `conversation-manager.ts` : `renderAvailableUnitsBlock`, `renderOpenMatterBlock`, `buildOpenHomesContext`, `computeConversationState` / `formatStateBlockForInjection` (`conversation-state.ts`), `currentLocalTimeLine` | SH
- B14 Memory / promises store | UNVERIFIED as a turn input: no memory store is read by the turn. Promises are extracted after the turn (G7)

## C. Prompt layers, in order

System prompt from `agents/clara/lib/agent/clara-unified.ts` : `getUnifiedSystemPrompt`, one template, this order:
- C1 Persona | `clara-personality.ts` : `CLARA_CORE_PERSONALITY` | SH
- C2 Today line, denied-applicant header, company voice pointer | `todayDenver`, `buildDeniedApplicantScopeHeader`, `company-voice-block.ts` : `renderCompanyVoicePointer` | SH
- C3 No dead-end hand-off rule | `no-dead-end-handoff.ts` : `NO_DEAD_END_HANDOFF_RULE` | SH
- C4 Property info | office hours, application link, knowledge sections (B2), fee rules, listing card, guest-card first-touch rules, walk-in rule | inline in `clara-unified.ts`; `guestCardFirstTouchRules`, `getApplicationLinkInstruction` | SH + LE parts
- C5 Resident scope rail (residents only) | inline | TC
- C6 Property knowledge (fees; not for residents) | `property-knowledge-block.ts` : `renderPropertyKnowledgeBlock` | SH
- C7 Specials, lease-answer grounding, application status | `buildLeasingSpecialsBlock`, `buildLeaseAnswerGroundingBlock`, `buildApplicationStatusBlock` | LE, TC
- C8 Prospect info, stated facts, tour state | inline | LE
- C9 Tenant info | `formatTenantInfo` | TC
- C10 Renewal info | `buildRenewalPromptBlock` | RE
- C11 Module workflow (zero or one) | maintenance `clara-maintenance.ts` : `getClaraMaintenanceWorkflow`; leasing `clara-leasing.ts` : `getClaraLeasingWorkflow`; turnover `clara-turnover.ts` : `getClaraTurnoverWorkflow`; staff-only `STAFF_FAIR_HOUSING_RULE` | per module (own copy)
- C12 Channel style rules | `clara-delivery.ts` : `getDeliveryRules` | SH
- C13 Language + company voice | `renderCompanyLanguageRule`, `renderCompanyVoiceBlock` | SH
- C14 Current caller / active work order | inline | MA
- C15 Denied-applicant scope (always last) | `DENIED_APPLICANT_SCOPE` | LE
Then the turn adds (in `conversation-manager.ts`):
- C16 Promoted principles (lessons from grading) | `composeWithPromotedPrinciples`, `loadPromotedPrinciplesBlock` (`src/lib/domain/grading/injection*.ts`) | SH
- C17 Capability prompt blocks (from the tool set) | `composeWithCapabilityBlock` | per module
- C18 Email overlay (email leasing turns) | `agents/clara/lib/prompts/clara-email-core.ts` : `composeEmailCoreOverlayForReplyTurn` | LE
- C19 Staff desk persona or PM persona | `staff-desk-persona.ts` : `composeStaffDeskSystemPrompt`; `clara-pm.ts` : `applyPmPersona` | SH (staff)
- C20 Thinking-off rule, transfer rule, "why line" rule | `draft-thinking.ts` : `thinkingOffRuleFor`; `transferCapabilityRuleFor`; `safety/decision-why.ts` : `WHY_LINE_RULE` | SH
- C21 Examples | No separate examples file and no few-shot block. Examples live inline in module prompts: `clara-leasing.ts` (about 105 grep hits for example/good/bad), `clara-maintenance.ts` (about 5), renewals `renewal-core.ts` and `tools/renewal/prompt.ts`, a few in `capabilities/resident-services.ts` | per module
- C22 Guardrails | No separate guardrails layer; rules live inside the workflow bodies and C3/C15/C20 | SH
- C23 Tool definitions | `agents/clara/lib/agent/capabilities/index.ts` : `composeCapabilities` picks capabilities (tenant: maintenance + resident services, + renewal when active; prospect: leasing; staff: desk/portfolio/metrics; always escalate-PM and conversation closure), `composeTools` dedupes and strips | per module (see table)
- C24 Prompt caching | up to four 1-hour breakpoints: last tool, whole system prompt as one block, newest message; no static/dynamic split inside the system prompt | `conversation-manager.ts` : `toolsForCaching`, `systemForCaching`, `withMessageCacheBreakpoint` | SH

## D. The model call(s)

- D1 Text and email turn | `claude-sonnet-5`, high effort, 16,384 max tokens, adaptive thinking; hardcoded, not env-overridable | `src/lib/platform/ai/model-tiers.ts` : `REASON_FIRST_DRAFTING_MODEL`; `conversation-manager.ts` : `resolveDraftParams`, `REASON_FIRST_DRAFTING_CHANNELS = ['email','sms']` | SH
- D2 Staff desk text turn | `claude-sonnet-5-5` | `model-tiers.ts` : `STAFF_DESK_DRAFTING_MODEL` | SH (staff)
- D3 Video turn | `claude-sonnet-5-5`, thinking off | `model-tiers.ts` : `VIDEO_DRAFTING_MODEL` | out of scope
- D4 Voice / other channels via this loop | env-dependent: `process.env.CLAUDE_MODEL`, default `claude-sonnet-4-6` | `model-tiers.ts` : `AGENT_MODEL` | out of scope
- D5 Tool loop | the model calls tools, tool results go back, up to 10 rounds (3 on the tour-action-only path) | `conversation-manager.ts` : `modelCall` (wraps `tracedClaudeCall`), `handleToolCall` (defined `agents/clara/lib/agent/tools/index.ts`), `MAX_TOOL_LOOP_ITERATIONS = 10`, `TOUR_ACTION_ONLY_MAX_ITERATIONS = 3` | SH
- D6 Side classifiers | all `claude-haiku-4-5` (`FAST_MODEL`): reply-topic verdict for the hold (`src/lib/domain/leasing/renewal-orchestration/classify-reply-topic.ts` : `classifyReplyTopicVerdict`), escalated-topic classifier (`agents/clara/lib/agent/escalated-topic-classifier.ts`), email classify (`agents/clara/lib/email/classify.ts`) | SH
- D7 Provider | Anthropic API only (no Bedrock found); no fallback model; credential rotation on 429/401 and a secondary key on 401/403; retry + circuit breaker | `src/lib/platform/ai/client.ts` (`failoverFetch`), `src/lib/platform/resilience.ts` : `claudePolicy` | SH

## E. Post-model layers (all deterministic; no LLM judge in the live turn)

In execution order inside `conversation-manager.ts` after the model returns:
- E1 Final text and "why" extraction | `safety/decision-why` : `extractDecisionWhy`
- E2 Empty or intermediate draft rescue | `decideIntermediateDraftSalvage`, `fallBackToEarlierTurnText`
- E3 Strip leaks | `stripReasoningPreamble`, `stripHistoryStamps`, `stripToolCallMarkup`, `stripInternalPrompt` (`outbound-safety-pipeline.ts`)
- E4 Dates and tour times | `enforceWeekdayDates` (`src/lib/domain/leasing/weekday-date-redraft`), `detectOffTurnTourTimes` (redraft or blank) | LE
- E5 Claims must be grounded | `enforceWorkOrderClaimGrounding` (MA), `enforceNoUnitCount` (LE)
- E6 Fair housing and promise backing (one retry) | `runOutboundSafetyChecks`
- E7 Work order confirmation, language | `ensureWorkOrderConfirmation`, `detectLanguage`
- E8 Remove private info | `stripOutboundPII`, `resolveRedactedReply`
- E9 No dashes | `enforceNoDashes` (turn-integrity)
- E10 Made-up facts guard | `guards/hallucination-guard.ts` : `runHallucinationGuard` (can hand to a person)
- E11 Final re-check | `sendGateFinding`
- E12 Anomaly review | `anomaly-review-gate` : `runAnomalyReviewGate` (may hold the draft and send a holding message)
- E13 Desk and turnover honesty | `evaluateTurnoverEditHonesty`, `stripDeskRefEcho`, `evaluateDeskWriteClaims`
- E14 Team-inbox silence | withholds a bare hand-off ack
- E15 Hand-off promise rewrite | `decideSameTurnEscalationOutbound`, `rewriteUnreachedForwardPromise`, `stripAllHandoffPromiseClauses`
- E16 Hold hook (row line) | `deferred-reply-row.ts` : `claraReplyRowWithheld` / `claraReplyRowHoldIf`
- E17 Unbacked hand-off claim | `src/lib/domain/compliance/policies/promise-backing-policy` : `findUnsanctionedHandoffClaim`
- E18 Opt-out withhold (texts) | `opted-out-reply.ts` : `withholdsReplyAfterOptOut`
- E19 Outcome + reply row | `publishFinalTurnOutcome`, `pushTurnRow(buildMessage(...))`, `saveConversation`
- Not found: a repeated-reply dedupe (only message-id dedupe in `saveConversation`); a post-model length or segment limit.

## F. Output gates, in evaluation order

### F-text (text reply; `process-envelope.ts` : `routeAndDispatchEnvelope`)
- F1 Stay quiet | Turn returns no text with a reason: runaway ceiling, farewell loop, closer skip, escalated thread (a person took over; `escalated-gate.ts`), tapback reaction, person muted, opted out, conversation ended, team-inbox silence | `conversation-manager.ts` (`suppressedBy`)
- F2 Turn failed | rate limit or error: nothing sent, logged, rethrown | `handleRateLimitExhausted`, `handleInboundTurnFailure`
- F3 Hold for approval (row line) | handyman texts Supervised, or the reply's topic / recipient / routed module is Supervised (rules R1 to R7 below); staff never held | `deferred-reply-row.ts` holdIf → `src/lib/domain/modules/reply-hold-decision.ts` : `shouldHoldClaraReply({kind:'reply'})` → `supervised-reply-rule.ts` : `decideSupervisedReplyHold`
- F4 Hold: router-answered maintenance acks and handyman in-house divert | `process-envelope.ts`
- F5 Hold: routed backstop (residents, not urgent) | `shouldHoldClaraReply({kind:'routed'})` → `routedModuleSupervisedAt`; `markReplyRowHeld`
- F6 Write the hold + approval card | `holdReplyWithAck` → `holdDraftReplyText` (`renewal-reply-review.ts`) → `holdText` (`src/lib/domain/escalation/held-text.ts`): saves `EscalationSmsHold`, posts a card to the company's Slack channel (grouped per channel, kind, day), emails reviewers, dashboard `/admin/escalation-holds/<id>`; a resident gets one fixed acknowledgement text; a rollout release can send at once; hold write failure → `escalateUnholdableDraftReply` (Sentry + #alerts)
- F7 Policy skip | test/stress sender, thread escalated (person took over), human replied (`autoReplyHold`), texts disabled (not for replies) | `agents/clara/lib/messaging/dispatch-envelope.ts` : `applyOutboundPolicy`
- F8 Consent at dispatch | skipped for replies | `dispatch-envelope.ts` : `isAllowedToSend`
- F9 Text door compliance gate, in order | harness off switch, canary, TCPA opt-out (runs for replies), AppFolio OTP, stress, test-scope recipient, flipped-line admission, module OFF, drafts backstop (`shouldHoldClaraReply({kind:'door'})`), company not live (replies always pass), contact ceiling, write admission, then send | `src/lib/integrations/twilio/client.ts` : `runOutboundTextComplianceGate`
- F10 Send | adapter registry: Twilio text, AppFolio PMS text, (email adapter uses SendGrid) | `agents/clara/lib/messaging/dispatcher.ts` : `dispatch` → `dispatch-envelope.ts` : `dispatchEnvelope`; `adapters/twilio-sms.ts`, `adapters/appfolio-inbox-text.ts`, `adapters/appfolio-pms.ts`
- F11 After send | refused: `markReplyRowNotSent`; sent: `backstampProviderIds`, then the guest-card text note is filed to the PMS (`fileStagedGuestCardTextNotesAfterSend`)

### F-email (differences)
- F-e1 Stay quiet | same loop reasons plus ingest gates (private note, lead claimed elsewhere, lead routed to guest-card engine) and `decideEmailSendMode` = suppress (relay or aggregator sender) | `process-inbound-email.ts`
- F-e2 Hold | `supervised-reply-hold.ts` : `supervisedReplyHoldScope` / `supervisedReplyHoldFor` (topic classifier + `shouldHoldClaraReply`) and routed backstop; held via `bake-gate.ts` : `holdEscalationEmail`; the 911 reply is never held
- F-e3 Email door gate, in order | no external recipient → send; staff audience → live check only; test scope; module OFF; Supervised (`shouldHoldClaraReply({kind:'door'})`); company not live → refused and logged BLOCKED (not a held draft) | `src/lib/integrations/email/company-live-gate.ts` : `evaluateCompanyLiveGate`, via `property-graph-sender.ts` : `sendPropertyEmail`
- F-e4 Lane order differs | SES: hold before live gate. Graph lane: live gate before hold (`lambda/inbound-processor/handler.ts`). PMS email: human-replied refusal before hold (`process-pms-email.ts`)
- F-e5 Send | PMS, Graph, Gmail or SendGrid door, each with its own suppression and contact ceiling
- UNVERIFIED: a "human replied" gate at the SES or Graph send door

### The hold rule (R1 to R7, `supervised-reply-rule.ts` : `decideHold`)
- R1 Reply topic's module is Supervised → hold (urgent maintenance to non-prospect sends)
- R2 A renewal action was deferred and Renewals is Supervised → hold
- R3 Routed module is Supervised → hold (same urgent carve-out)
- R4 Renewal thread or open renewal cycle, topic "other", not staff, Renewals Supervised → hold
- R5 Prospect and Leasing Supervised → hold
- R6 No topic verdict and anything Supervised → urgent sends; known lane not Supervised sends; else hold
- R7 Otherwise → send. A held reply may be released at once by the module's rollout plan percent.
- Topic answers are only renewal / maintenance / other; leasing is decided by the recipient being a prospect.

### Callers of `shouldHoldClaraReply` (8, not 7)
`process-envelope.ts` (reply kind; routed kind), `process-inbound-email.ts` (routed), `lambda/inbound-processor/handler.ts` (routed, Graph), `process-pms-email.ts` (routed), `supervised-reply-hold.ts` (reply kind, email hook), `twilio/client.ts` (door), `company-live-gate.ts` (door).

### Other outputs
- F12 Ask for help (hand-off) | Opens an EscalationMatter and asks the owner (property then org chain) by email or a staff text | `src/lib/domain/escalation/open-matter.ts` : `openMatterAndAsk`, `openMatterAndAskOrHeld`, `openMatterAndAskCore`; owner `resolveEscalationOwnerViaChain`; tools `escalate_to_human` (`src/lib/tools/handlers/handle-escalate-to-human.ts`), `forward_to_property_manager` (`handle-forward-to-property-manager.ts`) | SH
- F13 Page the manager (urgent maintenance, gas/CO) | `src/lib/domain/maintenance/page-property-manager.ts` : `pagePropertyManager` | MA (core-consumed)
- F14 Answer comes back | email reply → `reply-release.ts` : `releaseMatterOnStaffReply` → `runTeamAnswerTurn` (relays to the person, teaches the knowledge base); team-notify answer → `team-notify/clara-turn.ts` | SH
- F15 Stuck ask follow-up | one nag via Temporal `escalationMatterWorkflow`; the cron `/api/cron/escalation-matter-nag` → `nag-pass.ts` now posts stuck matters to Slack alerts (`stuck-matter-surface.ts` : `surfaceStuckMatter`); the nag email is retired | SH
- F16 Alert engineering | `logCritical` → Sentry fatal (`src/lib/platform/logging.ts`); `notify({channel:'alerts'})` (`src/lib/platform/observability/notify.ts`); team-notify `alertEngineering` → Sentry | SH
- F17 PMS write via outbox | guest-card intents (create card, append note, cancel tour, mark inactive, assign, send application) → outbox → drain (on demand + cron every 15 min) → `PMSGuestCardWriter` | `src/lib/domain/pms/guest-card-text-note.ts`, `guest-card-outbox.ts`, `src/lib/data/dynamo/pms-write-intent-outbox.ts`, `src/lib/integrations/appfolio/guest-card-writer.ts` | LE (own writers in MA and RE)
- F18 Reminders | promise ledger after the turn (events bridge → trajectory grade after ~6h quiet → `promiseWorkflow`); PM action reminders (dark: off by default per company) | `lambda/conversation-events-bridge/registry.ts`, `temporal/activities/promise.ts`, `temporal/pm-action-reminder-triggers.ts` : `startPmActionReminderCadence` | SH
- F19 Dark (default off) outputs | team-notify engine and team-notify text (`src/lib/team-notify/setting.ts`), emergency alert call chain (`emergency.alert_chain`), PM action reminders (`pm_action_reminders.enabled`) | SH

## G. State written

- G1 Conversation and messages | `src/lib/data/store.ts` : `saveNewMessages`, `saveConversation`; `src/lib/domain/messaging/conversation-writer.ts` : `markReplyRowHeld`, `markReplyRowNotSent`, `backstampProviderIds`
- G2 Held drafts | `EscalationSmsHold`, `EscalationHold` (`HeldMessage`) | `src/lib/data/dynamo/escalation-hold.ts` : `saveEscalationHold`
- G3 Asks | `EscalationMatter` | `src/lib/data/dynamo/escalation-matter.ts`
- G4 Turn outcome | `recordTextOutcome` / `recordEmailOutcome` → `stampConversationTurnOutcome` on the conversation; inbound Slack card edited by `finishInboundCardOutcome`
- G5 Traces and snapshots | `saveAgentTrace`, `persistTurnSnapshot` (`dynamo/turn-snapshot.ts`)
- G6 Refusals and touches | `recordModuleRefusal` (`module-refusal-log/record.ts`), email log rows BLOCKED, `recordTouch`
- G7 Promises | `src/lib/data/dynamo/promise-ledger.ts`
- G8 PMS write intents | `src/lib/data/dynamo/pms-write-intent-outbox.ts`
- G9 Activity log | UNVERIFIED: no generic per-turn activity log (only `recordActivity` in `renewal-saga/writer.ts`)
- Everything lives in one DynamoDB table `propflow-data` (`src/lib/data/dynamo-client.ts`)

## Module concepts (shared vs own copy)

See figure `machine-modules`. Own copies per concept (count across LE, MA, RE, TC): automated-send review doors 3, topic classification 4, hand-off 2, person lookup 3, PMS writer 3, reminders/cadence 4, quiet hours 2, examples 4, tool sets 4, intake 2, scheduling 3, staff notice sender 3, module-off refusal 3, entitlement 3.
Invented: Leasing = tour pipeline, guest-card engine with PMS write-back, application-link chain, outreach cadence. Maintenance = work order intake and triage, vendor dispatch and chase, life-safety and on-call chain, handyman texts mode. Renewals = offer saga and packet, auto-start scanner, decisions engine, deferred tool calls under Supervised. Tenant comms = read-only resident answers, lease-terms answer engine, key pickup, unanswered-questions digest.
Shared pieces housed in a module folder: the hold's topic classifier and `holdDraftReplyText` (renewals files), the knowledge block (leasing file), `pagePropertyManager` (maintenance), scheduling intent engine (leasing). Two staff-notice "one doors" coexist: `escalation/team-notice-send.ts` and `notifications/human-notification-lane.ts`.

## Deltas vs the 2026-10-24 inventory
- `shouldHoldClaraReply` has 8 call sites (brief said 7).
- Daily nag email is retired; stuck asks now post to Slack alerts.
- Shadow modes are deleted, not drawn.
- Line numbers moved; this file cites functions only.

## UNVERIFIED list
1. Dashboard "reply as Clara" route (none found).
2. Human-replied gate at SES / Graph email send doors.
3. PMS text door's internal gate order (shares the compliance gate; order not traced).
4. Escalation nag cron schedule.
5. Generic per-turn activity log.
6. Memory store as a turn input.
7. Tenant PMS write from the Clara loop (`set_tenant_email`, may be staff tooling).
8. Knowledge on tenant turns traced end to end (marked shared from prompt text).
9. Prompt example counts are grep counts, not curated counts.
10. "Email Sent" PMS entry detail.

Engineering calls, closed on recommendation

The four pages carried 24 open questions; the brain and platform pages a few more. Internal engineering is decided here; three owner calls survive (decisions for Fede). Rows that only restate standing rules (adapters per PMS, no confirm screens, phrases follow the desk) were dropped.

Sources and method

Lifecycle side: four Opus 5.5 digests of 29 past pages, the Oct 24 hand-off audit (810 rows, counts as corrected by the Escalations session's claim check), the Oct 16 staff-loop queries, the Oct 21 Western Slope working-session transcript, Fede's Oct 22 to 25 notes as relayed through Trinity, a Gera-style study of his audit and architecture pages, and two adversarial reviews. Full text of the four pages absorbed earlier is parked under ~/agents/006/parked/. Internals side: the Benchmark lane's read-only inventories and benchmarks as cited in each table, and its fragment of decision surfaces and ledgers, carried over verbatim. This rewrite merged Clara, the new hire and Clara re-architecture: the one page to review on Oct 25.

The chapter list

1. The idea: a hire, not a tool, and no noise
2. End to end: week one, learn and get feedback, supervised, five habits, floors, two dials, end state
3. Where it stands today: the path, the audit, modules, prototype, models, gates
4. The internals: full context, core engine, Cerebrus, who is writing, the bench, upgrade path, cheap vs big, engineering detail
5. Tenant communications: repair cases, shipped and open
6. Proof and rollout
7. Order of work: advice, seven days
8. Decisions for Fede: A1 to A3, 1 to 6, release plan, first-email review, repair cases
9. Appendix: reviewers, sources, decided here, changes, ledgers (done means, asks, bench night, model paths)

Changes in this rewrite

• One page. Clara, the new hire (this URL) and Clara re-architecture: the one page to review are merged. Fede, Oct 25: "It's all one thing." The second page becomes a pointer here.
• New: the number one objective (no noise) at the top, every interface and habit restated against it; Fede's "why" for the re-architecture; the full-context hypothesis (no proof yet); the core-and-modules diagram; the order of work re-cut to the base first and his three priorities, with Day 0 freezing the baseline.
• Dropped from the new-hire page: the chapter 1 machine transcript (the audio stays); the analogy table (the 10,000-foot lifecycle figure carries it); the channels, the outside research and the "what if I have a question" tables of week one (detail behind the hello per role); the exit checklist; the price table (prices are one sentence, not decided); the switch-to-dial table; the old seven-day roadmap and its figure (superseded by the re-cut week); the "what was asked tonight" list (all decided Oct 24).
• Condensed Oct 25 (parts 1 to 7 cut to under 8,000 words): every fold in those parts is dropped, with its figures: week one today vs the framework, the ownership map, the hello per role, learn-and-feedback, supervised by channel, the five habits table, the hand-off layers, the floors table, the two levels and the per-module examples, the message-path inventory, the spread, the leasing hand-off path, the shadow feed, the habit mechanics, the gate detail, the prompt-size breakdown, the cheap-vs-big table (now one sentence), the outside best-practices table, the "what changes" list, the two strategies, the identity detail, the model-status detail, the tenant volume and supervised detail. Their sources are the two former pages' history and the linked hub pages.
• Dropped from the re-architecture page: the Benchmark UI rethink (a Benchmark app design, not Clara's); the D and F tenant blocks and the first G run (superseded by D2, D3 and G2, and none ran the production prompt); the phases picture (superseded by the order of work); the "what the replies look like" samples (the 15 first-email pairs replace them); the operational calls of the week; its old "one module a day" seven-day plan. Compressed with numbers kept: status (folded), the lease plan, tool coverage, commercial work orders, gates, model paths. Its tenant decisions (1) to (4) are kept verbatim inside the folded supervised-mode table.
• Ids. All old anchors of both pages that still have content still land. The Benchmark lane's "1. Decisions for you" heading is now #decisions-benchmark, because #decisions is the whole decisions section. Heading levels of the carried decision blocks moved one level down to sit inside section 8; their wording and numbering are unchanged.
• Housekeeping on the carried fragment: a stray closing tag and an unclosed "Full review below" fold before the model-path ledger, and a stray end-of-document tag after the 15th first-email pair, were removed.
• Cross references. "Section N" pointers in kept text now link by name, because the section numbers changed. Figures are renumbered in page order, and figure references in kept text follow the new numbers; the one link to the dropped Benchmark D2 block now points at the tenant bench summary.

0. The goal, and what done means

Fede, Oct 24: Clara will carry every office module in layers (Clara, the new hire). One giant prompt on a mid-size model cannot carry that. This lane puts down the foundation: specialized small prompts per job, a frontier model under them, and a repeatable safe way to upgrade the model as new ones ship. Everything else on this page is a tactic under those three.

How every Clara change is benchmarked and released (proposed): Clara Bench page, section 6b: what we already have for each stage, and the gaps.

The three fixes shipped Oct 24 (first-reply opener, four prospect-email fixes, work-order number) are proven live and are not what done means.

0b. Every ask since Oct 22 and where it really stands

Built Oct 24 19:3xZ from the session transcript after Fede: "ive already asked for all of this multiple times". Relayed asks count as asks.

Clara Benchmark, night of Oct 24

In one line: the Benchmark is now its own app, PropFlow gained two small pieces it needs, and both benchmarks ran with production as arm 1.

What got built

Repair texts: 261 real tenant repair texts, whole episodes

• Takeaway: your fixes help on every line but duplicates.
• The biggest lever is matching a text to a work order already open, not the prompt.
• As gated today, Clara answers 0 of these 261 texts (the tenant text switch is off at both customers).

Full mode, Oct 25 afternoon: 20 of the 261 through the real door

Only 20 repair texts can run with Clara's real lookups against production: 215 are Situs history texts older than the message mirror (which starts Sep 29) and were never stored, 15 are held by the mirror, 10 come from a sender who is not an active tenant there, 1 has two tenancies. Until the evening, full mode could not measure whether Clara filed a work order when the office did, because the door skipped the filing step; that is fixed and measured below. On the reply itself, same 20 texts, both writers in one pass, judge controls 4 of 4:

Filing, measured Oct 25 evening. The door now runs production's own work-order filing step read-only (merged as #22386, live, proof: 0 writes, 0 notices, 0 Slack cards). For each of the 20 texts, this is what today's production filing logic would do, next to what the office actually did. The office column comes from the G3 records matched on each text's source id.

Totals: add to an open order 8, new order 5, reply only 7. Against the office: 1 clear match, 4 misses where the office filed and production would only reply, 1 different problem, 1 split report, 1 wrong attach. Not run read-only: the actual create, the which-home rule, the emergency content check, the vendor-first check. Order ids are stand-ins, nothing was created.

Filing, decomposed Opus 5.5 vs production, measured Oct 25 evening. Same 20 texts, same door. The decomposed column is the accepted prompt (3b) with both halves on Opus 5.5: the four graded edits on the filing step's classifier prompt (one order per text, a worsening report updates the open order, a repair report is never reply-only, a leak is urgent), then the decomposed writer with the real lookups, seeing what that filing decided. In the G3 benchmark 3b ran the classifier on production's model (Sonnet 4.6) and only the writer on Opus; that exact version is the sensitivity line under the totals. Nothing was created or sent: 0 refused writes, 0 notices, 0 new messages in #western-slope; the writer's 5 notes and 1 team alert were blocked at the door. Read legend: match = filed what the office filed; miss = the office filed and this arm did not; different problem = filed something other than what the office filed; split report = one text, several orders; wrong attach = put on an open order for a different thing; plausible = no office order to compare, the choice is reasonable.

Better with the decomposed arm: the two-laundry-room text (n52) is one order instead of two, which is Fede's one-order rule holding; the key complaint (1156292270) is no longer put on the security camera order (production's choice, which the earlier read had called plausible); the electrical dispute (1162814418) gets silence, like the office, instead of a note on a closed order. Worse: the laundry-machines text (1161429708, Spanish) goes onto an old washer order at her unit instead of a new order; the homeless report (1159587096, Spanish) files nothing and the writer sends a team alert and says "ya alerté al equipo", though it is not a safety emergency, so it breaks the no-team-items rule; the valve text (1165635254) gets a note before Clara knows which order. On 1159587096 the office's order is the shower faucet order (ZEPH-18587) that 1158429018 also maps to, so neither arm could have matched it from this text. Same on both: the no-water emergency (1166988363) files at once as an emergency, and the 4 shared misses are texts that are not themselves repair reports (a photo promise, a parking reply, "fixed", "thanks"), so the office's order likely came from another message. The four "ask first" rows come from Opus giving lower confidence than Sonnet (0.5 to 0.6 against 0.7 to 0.8 on the same texts) meeting production's fixed thresholds: a new problem with any open order needs 0.8 or it asks (1159587096, 1164004510), and a pick with no real order id asks (1156292270, 1165635254). The open lists make this worse: at Situs the door shows 8 to 43 open orders per tenant, most of them years-old "Work order (AppFolio)" rows still marked dispatched. So moving the classifier to Opus needs its thresholds re-set, or the open list cleaned, or both. No tenant in these 20 has two units, so the which-unit rule was not exercised. Sensitivity, 3b exactly as benchmarked (same edits, classifier on Sonnet 4.6): 5 add, 4 new, 1 ask, 10 reply; it also files n52 as one order, files the homeless report as a new order, and asks on the laundry-machines text instead of the wrong attach. The "I've put in a repair request for this." opener on 1166988363 and 1167466911 is the work-order confirmation production's finish step adds, not Opus (it doubles Opus's own line on 1166988363); the Spanish offer line on 1167466911 follows the company voice rule for limited English.

One caution on the four "miss" rows shared by both arms: those texts are not repair reports ("I'll send it at 4", a parking reply, "fixed", "thanks"); the office order on the same day came from somewhere else, so neither arm should have filed from the text. They count as misses in the table only because the office outcome is matched by day, not by text.

What this says for the lane goal: on filing, the decomposed prompt on Opus is not yet at parity with today's production. It fixes the split report, the key-on-camera attach and one needless note, but it asks first on 4 texts where production acted (Opus reports lower confidence and production's fixed thresholds turn that into a question), puts the moved laundry machines on an old washer order, and on the person-approaching-residents text alerts the team instead of filing. Both of the new misses are Spanish texts. Decision for the lane, not for Fede: the filing thresholds and the open-order list (8 to 43 stale open orders per Situs tenant) are tuned for Sonnet and must be re-set before the classifier moves to Opus; the sensitivity line (classifier stays on Sonnet, writer on Opus) is the safer first step and is what G3 measured.

One miss only full mode could show: with the balance lookup running for real, the decomposed writer quoted a tenant's two-week-old balance when she had not asked. Small sample; the light-mode numbers for the same 20 sit beside these in the report file.

Prospect first emails: 72 cards, three arms

• Takeaway: the split fixes the mechanical items but skips the first lookups more than the same prompt on Opus.
• "Same email as production" is noise: Sonnet matches itself only 3 of 12.
• The "<home> is open now" opener comes from production's own first-sentence rule.

What is live, what waits

Your morning list

Saturday Oct 25, five things, in order. Everything else below is Oct 24's list and is done.

1. Grade the 15 first-email pairs (section 13): today's Clara vs the new writer, same facts, same hour. Your marks decide whether the new writer goes to production; it stays off until then. Two things we already know are wrong on the new writer: it turned a smoking rule into "private yard" on two cards (the fact check missed it), and both writers still name extra homes about 5 times per run (the one-home fix is written, held for the run after your grades).
2. Live witness, 2:46 AM MT: a real Realtor.com lead at Western Slope (David, 2841 Morningside Ct) got today's Clara's first email 46 seconds after arrival: no dash, one home, the beds/baths/size/rent line, two tour windows kept ("Monday between 9:00 AM and 12:45 PM"), opened with his name, sent not held. He had asked for a phone call at a number he gave; Clara wrote "I can't give you a call" and offered the tour by email, and no text went to that number at that moment. At 8:01 AM MT the morning text run sent him one: "Hi David, it's Clara with Western Slope Property Management. I sent you an email about your inquiry. If texting is easier, you can reach me right here." So he did get a text, five hours after the email. Your call whether that text should go at once when a renter asks for a call and leaves a number (your Oct 22 rule covers tour notifications; this is a first reply). Noted only; nothing sent. Same morning, the dash check across 16 hours of real traffic: 3 Clara messages at Western Slope, 0 with a dash; Situs 0 messages.
3. Rule on the four repair cases (same order or new order). Two are the accepted prompt putting a report on an unrelated open order; your verdicts set the bar for matching.
4. The 96 Slack cards at 8:56 PM: a benchmark read loop, nothing sent, nothing written, no setting changed; three fixes merged overnight (ledger, first row). Proof rerun lands there once the deploy is out.
5. Which company first, and switch or no switch for the new writer: section 0c, release plan, one line each with a recommendation.
6. Model moves, model-first or path-by-path: section 0d has every place Clara uses a model and a recommended order.

Still local, no PR: the production prompt change for the new writer; the repair prompt's two rule lines (accepted version 3b). PR 22321 (post-call notes and stale held drafts block, never rewrite) merged Oct 25 afternoon; its three open choices are follow-up issues 22375 to 22377, the one worth a look: rejecting a stale held first email also drops the tour it booked (main already did this; 0 such cases in 14 days).

You answered all six tonight ("Finish everything"). Each row shows where it stands; this table is updated as the work lands.

Not done tonight: runs through the real entry point; live proof of the photo fix (needs a real tenant photo); the "answer it, don't defer" fix is untested (the Benchmark lacks the customer's knowledge base).

0d. Every place Clara uses a model today, and the order to move them

Read-only inventory taken Oct 24 (code as of Oct 19, plus four paths added since). Nothing in production runs on Opus 5.5 today. Volumes are real customer traffic for Oct 18 to 25; our own test traffic is excluded.

Recommended order

1. Clara's email and text replies (~120 real runs, ~300 model calls a week). Already moving. Every retry and redraft follows automatically because they reuse the same model setting.
2. The voice line (~61 real calls a week, all on Sonnet 4.6). This is the largest customer-facing path nobody is moving yet. It is a setting change per agent in ElevenLabs, but voice speed matters, so it needs a timed call test before switching.
3. The first email to a new lead (~25 to 100 a week). Already moving. Move the new retry and the guest-card note writer with it.
4. The repair chain: intake decision (~25), work-order review (~199, part test), access read (~100), tech text summary (~12), the new emergency check. Partly moving with Bench G3. The review and access read are not in G3's arms yet.
5. The routing decisions in front of every reply: email labeling (~210), text sorting (~112), fair housing check (~70 to 140), fact-check, topic match, scheduling reads. All on Haiku 4.5. These are cheap and fast, so test whether Opus 5.5 is worth the speed and cost before moving them.
6. After-call capture: prospect capture (~46), claimed unit (~44), caller name (~15), post-transfer actions, opt-out check, staff call-back notice.
7. Lead follow-up and prospect notes: follow-up text, lead-quiet decision, disqualification, lead card summary (~120), neighborhood lines (~43).
8. Vendor, renewal, mass-text and turnover paths (low volume, mostly Haiku).
9. Internal summaries, uploads and staff tools last.

Paths with no replay set or eval found

• The fact-check of Clara's draft against her lookups (trajectory judge)
• The booking-only reply on taken-over threads
• The "your tour is booked" removal rewrite
• Video and staff-desk replies (only a desk-thread eval helper)
• The tenant access read for repairs (access extractor)
• Scanned PDF attachment reading
• The opt-out check on finished calls
• Neighborhood "around the home" lines
• The weekly owner briefing paragraph
• The "Improve with AI" button for text blasts
• The public website question box
• The policy-option duplicate check
• Report layout learner and rollup template learner
• Move-out "who pays" panel
• Move-out condition extraction (only a model comparison, no replay)
• Answering a manager's question about a tenant claim
• Video meeting summary
• The Maestro reasoning step (dormant) and the guest-card note safety sorter (not wired)
• Voice: Turnover Intake and Escalation Answer Callback agents
• Fast-tier benches are not real-record replays. Every Haiku row marked "fast-tier bench" has a scored set but no end-to-end replay through Clara.

Final-pass review, Fable 5.1 (max)

Independent final pass, Fable 5.1 at max effort, Oct 25 evening, over the published page (before the Cerebrus section was added). Findings are the reviewer's; nothing on the page was changed in response yet. Where the two reviews agree, working separately: the "I've told the team" reply is still permitted in several places; the page asks Fede far more than three things; the Benchmark ledgers and the body disagree on whether the new first-email writer has a switch. Opus alone leads with "nothing measures noise"; Fable alone leads with the asks cut. One finding in both reviews is withdrawn: the claim that a Slack approval card on tenant replies contradicts "never a queue". Withdrawn (Fede, Oct 25): "I never said I didn't want an approval queue." His Sept 8 autonomous rule covers identity and household decisions, not a person reviewing Clara's dark tenant replies. The approval card stays as designed.

Verdict

Not yet: the page states the right objective at the top and then contradicts it in the design, and it asks Fede to choose between options that disagree with each other. First, pick one answer on supervised mode: the Supervised section and Figure 13 say the customer's own Send button is the only hold left, while the Tenant communications diagram and the Friday row make every tenant reply wait on a Slack card until a person approves it. [Withdrawn as a contradiction: Fede keeps the approval card; the fix is to make the Supervised section say so.] Second, strike the four places that still let Clara say "I'll check with the team" and send one more notice: rollout step 2's tracked-ask exception, decision 5's option (b), the repair writer in prompt 3b, which alerts the team on its own judgment with no emergency gate, and the new first-email writer, which puts answers off twice as often as today's. Third, cut the asks to the three that are Fede's (A1 to A3) and mark the rest decided or recorded; today the page carries more than thirty inputs for him, including a switch question his Sep 30 rule already answers. With those three edits, and the untraceable "intro texts proven at the Willows" sentence removed, the page is ready to decide from; Tuesday and Saturday are the only days a builder could start without asking, and Day 0 only for the first-email surface.

Noise audit

Every interface, habit, outbound and reply pattern on the page, read against the one objective. Noisier items first, in order of severity; the quieter items at the end are the parts worth keeping as written.

Where the "I couldn't help, I've told the team" reply still survives on the page:

• Proof and rollout, step 2: "no 'with the team' without a tracked ask" allows the sentence whenever an ask exists.
• Decisions for you, decision 5: option (b) "short code-built reply + team item" is recorded as a reviewer's preference.
• Your review set: the new writer writes "I'll check with the team and get back to you" in pairs 6, 12, 14 and 15, more often than today's.
• Ledgers, filing table: with both halves on Opus the 3b writer alerted the team on a trash complaint and told the tenant "ya alerté al equipo"; with the classifier on Sonnet 4.6 (Thursday's configuration) that text was filed instead, but the writer's alert path has no emergency gate in either configuration.
• Four repair cases, case 4: Clara 3b writes "le avisé al equipo de la propiedad que es urgente" after a wrong attach; the page asks about the attach, not the alert.
• Tenant communications, TODAY diagram: "Can't answer: 'I'll check with the team' to the tenant" is described as today and nowhere listed as removed.
• Ledgers, done means row 2: the production bug that inserts "I'll check with the team" in English inside a Spanish email is named and sits on no day of the week.

Automatic staff messages on the page that are not a tracked ask:

• The daily re-ask on the ask record (live cron), with no setting named.
• The email to the property manager that forward_to_property_manager sends today, not listed for removal.
• Review-mode hold cards (102 in 14 days) and the maintenance hold (120), both kept or "fixed" rather than deleted.
• The proposed Slack hold card on every tenant reply (Tenant communications).
• Intro texts and the "I've answered 14 renters" first move (Week one).
• "Clara proposes PMS settings" and "Clara chimes in inside their shared inbox" (step 4; Figure 12).
• About 20 staff notice templates kept (Figure 13 row 13), and "transfer confirmed by text" to callers (step 4).

Reminders or digests without a setting: only the daily re-ask cron. The morning list and the resident-questions digest both carry a setting (default off) wherever they appear; the page should say they are the same cron.

Claims and assumptions

Line numbers below refer to the tag-stripped text of the page and of the two source extracts, not to the HTML. Labels: HARD (traced to a source line), ESTIMATE (a number with no derivation), INVENTED (no trace in any file), UNVERIFIABLE (cannot be checked from the extracts), CONTRADICTED (two statements disagree); "inconsistent" means one quantity with several values on the page. Ranked by how much each changes a decision.

Traced with no issue: Western Slope has fewer tenant messages than Situs (223 against 252); Figure 5's 2, 2, 8, 2 split of the 14 cases; the 122 silent drops (85 plus 37); Situs at 33% and Western Slope at 47%; the 261-episode table; and the 15 pairs and the four repair cases are line for line with the Benchmark page.

Consistency of the three owner calls: A1 to A3 and their recommendations appear once each and are referenced consistently in "Not scheduled, waits on a decision" and in the appendix. The problem is the count of everything else, not the wording of these three.

Simplify and reuse

• Duplicates production, by the page's own admission ("almost everything the design needs already exists"): askTheTeam is the ask record plus the team-notify engine; the morning list is the resident-questions digest cron plus the nag; shouldSpeak is the supervised-hold decision, the router and the shadow feed's overlay; PmsInbox is the AppFolio inbox mirror; the proof rail is the recorder and the service door, both live. The seven-day table should say "wrap" for each, never "build".
• Duplicated on the page: the 261-episode table (The bench; Ledgers), the Dark line (Proof and rollout; 0c), the model-paths group table (Where it stands; 0d), the four repair cases (summary; full appendix), the tenant-communications calls (1) to (4) (section header; folded table), and the first-email release (0c; decision 3; the morning list; "Not scheduled"). Each pair should be one occurrence and one link.
• Deletable with no loss: the 0d inventory of 97 paths (about 360 lines; link its own page), the 15 first-email pairs (about 420 lines; Fede grades them in the Benchmark app, not on a design page), the 0b asks ledger, the four repair cases in full, the "Heard today" column, the two "Listen" podcast lines inside a decision page, the Phase tracker stub (a separate URL against the one-page rule), and "Changes in this rewrite" (history, not design).
• Dangling after the condensation: Figure 10's caption cites five figures marked "(dropped Oct 25)"; Figure 8's caption reads "The order is the order of the order of work"; the 0c heading carries the dash the page tells Clara never to write; the bench correction says the G3 run is "in progress" directly above its finished table.
• Where two sections disagree, beyond the claims table: phone is "out for now" (The idea) while the 0d recommended order moves the voice line second and Figure 7 says "phone later"; "no per-message team item" (The idea) against the hold card and decision 5 (b); Advice (a) says the intro "does not wait for the refactor" while step 4 makes it new outbound, default off, pending A2; Week one's "she never nags" against the live nag cron; step 2's "today's standing-vs-one-off sort keeps saving standing answers" against Figure 12's "sorted by Clara with no question" (same thing, said twice, differently).
• Reuse the Benchmark page's "What Fede does this week" list: the merged week schedules no input from Fede (grades on the 15 pairs, four repair verdicts, A1 to A3) even though Monday, Tuesday and Friday depend on them.

Execution readiness

Could a builder start on Sunday morning with no questions? Day by day, with the missing inputs.

Across the week: the release plan's stages 0 and 1 (shadow at three companies, 50 pairs) need no decision yet appear on no day; no day has an owner except Day 0; Fede's own inputs (15 marks, 4 verdicts, A1 to A3) have no date; the English "I'll check with the team" line inside Spanish emails is a named production bug on no day; and the shadow-feed overlay, called "the first draft of shouldSpeak", is not referenced by Tuesday's row.

Ten lines for Fede

• The page says the right thing first: Clara's first job is to add no noise to a tenant's inbox or your team's.
• It then says two different things about supervised mode: one part says a person approves every tenant reply on a Slack card, another says there is no hold on Clara's own channels. Pick one before Friday's work starts.
• Four places still let Clara say "I'll check with the team" and send your staff one more message: the hand-off fixes, the fallback when an email fails its check, the repair writer that goes live Thursday (it can alert your team on its own judgment), and the new first-email writer, which defers twice as often as today's.
• One reminder already runs every day to your staff with no setting, while the page promises she never nags.
• You are asked more than thirty things, not three. Most can be closed by rules you already set; three are really yours.
• One of the asks is already answered by your own rule: an improvement to something live ships with no switch, so "switch or no switch for the new writer" should not be a question.
• Several numbers appear with two or three different values: the size of today's prompt, the time per reply, and the cost per email.
• One claim has nothing behind it: that the staff introduction texts were already proven at the test building. Nothing on the page or in its sources shows it ran.
• The readiness floors are starting guesses, not measurements, and both live customers sit below the first one today.
• Sunday's work, the Situs onboarding package, is not defined anywhere; Tuesday and Saturday are the only days a builder could start without asking you something.

Final-pass review, Opus 5.5 (max)

Independent final pass, Opus 5.5 at max effort, Oct 25 evening, over the 14:14 version of the page (with the Cerebrus section). Findings are the reviewer's; nothing on the page was changed in response yet, except that the "approval queue" finding below is withdrawn. Withdrawn (Fede, Oct 25): "I never said I didn't want an approval queue." His Sept 8 autonomous rule covers identity and household decisions, not a person reviewing Clara's dark tenant replies. The approval card stays as designed.

Verdict

Not ready to decide from yet. The page puts "add no noise" first, but nothing on it measures noise, and its own plan still lets Clara say "it's with the team", emails staff a notice per question, keeps a daily re-ask with no setting, and puts every tenant reply behind a Slack approval card. The week builds shared plumbing but drops the two Benchmark days that made Clara quieter: the reply-or-silent table, and the fixes for live defects such as the English "I'll check with the team" line inside Spanish emails. Change first: define a noise number (replies a person would not have sent, plus staff messages not tied to an open question), record it in the Day 0 baseline and make it a fourth readiness floor; second, write one rule per channel for when Clara stays silent, and hold the approval card and the per-question notice until that rule exists. Then cut the roughly twenty open decisions to the few that block this week, and fix the three places that still say Fede has three questions.

Noise audit

Ranked by severity. Section names are the page's own headings.

Claims and assumptions

HARD: traced to a source number. ESTIMATE: a stated estimate or proposal. INVENTED: stated as fact with no support. UNVERIFIABLE: in neither source extract; it may come from tonight's session and needs its evidence on the page. The Cerebrus section was added after the merge and is checked against itself.

Simplify and reuse

• Supervised says two things. "A senior next to her" says "never a queue" and "the customer's own Send button is the only hold left", while "Tenant communications", the gates table, decision 5 and Friday each keep a hold; keep the first rule and delete the rest. [The "never a queue" half is withdrawn, see the note above this review; the inconsistency between the two sections is still to fix by stating the card as the design.]
• Asking the team says two things. "Clara is a hire" and "Four interfaces" send "at most one notice per matter", while the asks ledger records "No team items in phase 1; silent or helpful" as ruled; one sentence per channel settles both.
• "The Benchmark lane's own seven-day plan is this one" ("Phase tracker") is not true yet. The merged week dropped Benchmark day 4 (live defects, including the English "I'll check with the team" line in Spanish emails and the doubled "I've put in a repair request") and day 6 (the reply-or-silent table built from 2,591 real tenant texts); put both back, they are the noise work.
• Reuse, do not invent, the silence rules. The reply-or-silent table becomes shouldSpeak's rule set, and the existing code gate (role, teammate last; "working, Keep" in the gates table) answers questions 1 and 3 before anything new is written.
• Reuse what is built for reminders. The Oct 23 resident-questions digest (built, off) is the morning list, the live daily re-ask folds into it, the existing staff-text setting carries A2, and askTheTeam wraps the existing ask record instead of adding a sender.
• Restore, do not redesign, the old page's rules: the urgency rule (emergency, tour today, money due today), the burst fold, the per-owner caps and the counter. They were written and reviewed, then lost only in the condensing.
• Voice is out of scope but still in the week: Day 0's voice set, Monday's plumbing over 15 voice agents (0d), the upgrade path's ~61 calls, and Cerebrus (87% voice). Cut voice from this week and Monday gets smaller.
• Delete duplicates with no loss: the G3 table appears in "The bench" and again in "Repair texts"; the model table in "Every place Clara uses a model today" and again in 0d; the dark-features line in "Fixes ship with no switch" and in "Release plan"; "Not scheduled" repeats the decisions list. Keep one of each and link it.
• Delete superseded or out-of-window parts: the tenant benches' D3, G2 and triage rows (rules prompts, superseded by G3 by the page's own correction), the pricing sentence, the meetings end state, the 97-row model ledger (link it), and the video and podcast blocks that repeat the page. If Cerebrus is cut to one detector, its four tables become three lines.
• Fix stale text: step 2's "until the question in step 4 replaces it" (step 4 now has no question); Figure 8's "The order is the order of the order of work"; the byline's "(section 14)"; "Changes in this rewrite" puts the tenant decisions "inside the folded supervised-mode table", which is gone; "What each past effort contributed" lists "three outcomes only" against Oct 23's two.
• One switch fewer. If the new writer follows the no-switch rule its own done-means row states, the setting, stage 2 and the dark-features line go, and the shadow stage stays as the proof.

Execution readiness

Section: "The seven days, Oct 26 to Nov 1". Ready means a builder can start Sunday morning without asking anyone.

Summary for Fede

• The page puts the right goal first: Clara's top job is to add no noise. But nothing on it measures noise, so we could not tell whether this week made her quieter.
• Clara can still answer "I've let the team know" and email the team about it; the plan only forbids that when no question was logged.
• The tenant plan has a person approve every Clara reply in Slack. The page itself says "never a queue", and the last queue like it let 101 of 120 texts expire. [withdrawn, see the note above this review]
• Every open question would email its owner, and a daily re-ask already runs with no way to turn it off.
• On her own text line, Clara still replies after a staff member has answered; that fact was dropped from the page.
• The week builds shared plumbing but drops the two days that made her quieter: the reply-or-stay-silent rules and the fixes for live mistakes.
• The new first email to prospects puts answers off more often than today (about 6 in 15 vs 3), and its release test does not check for that.
• "One in three hand-offs failed" counts Clara staying quiet as a failure even when staff may have answered in AppFolio; as a target it would push her to bother people more.
• The page says you have three questions; there are about twenty, plus fifteen emails to grade.
• What I would change first: count the noise, write one rule per channel for when she stays silent, and put those two missing days back in the week.

Cerebrus: a grader that reads every turn after it went out, that no person has read back.

Fede (Oct 25, voice): "should we kill it or should we merge it?" This section is the inventory, read from main on Oct 25, and the decision. Spelling: Fede ruled "Cerebrus" (the repo's spelling) on Aug 27; his voice note said Cerberus. Inventory by four read-only workers over the worktree, GitHub, Sentry and the production table; every number names its source.

Where it sits today

Inventory

What its ideas are worth now

Every detector judges what Clara said. None judges whether she should have spoken. Cerebrus cannot move the noise rate, the headline number of this page, under any option; that is the honest answer to the lens Fede asked for.

Decision: fold. Decided: D (Fede, Oct 30, via the Trinity DM)

Under every option the noise rate is untouched; the quiet-or-reply decision is shouldSpeak in Figure 8, not Cerebrus. Fede's Aug 20 ruling (no pre-send gate) stands unless he picks B. The branch-protection edit (dropping the required check) is a GitHub settings write done in the build, right before the deletion PR merges.

Build (session 019, started Oct 30): PR 1 #24099 (merged Oct 30 night) moves the detectors into app code; proof: a read-only replay of 3,048 real Clara turns since Sep 30 (504 calls, 1,045 texts, 378 would-flag) gives identical output before and after · PR 2 #24112 (merged Oct 31 13:05 MT: 361 files, 35,456 lines removed, grader output byte-identical on the same 3,048-turn replay; also removes the quality-replay harness, which only compiled against the vendored engine) deletes the vendored copy, sync script, checksum, parity step, drift tests, D8 remnants and the CI jobs; the required check "Regression Gate — Leasing (required)" was removed from branch protection on main Oct 31 07:45 MT (required checks now: Build, Type Check, Unit Tests, Lint, review). Its first CI run died in the review classifier on the size of the file list ("spawnSync gh ENOBUFS"); the one-line buffer fix #24117 merged Oct 31 08:55 MT, its checks were re-run and it is armed to merge on green (dangerous-diff label: the review workflow and merge guard edits are comment and name-list changes, read in full by this session) · PR 3 (branch feat/cerebrus-fold-3-red-flag-slack-cards built and pushed Oct 30 night, unit-covered, 619 lines; held: no card posted, no PR opened until Fede answers the open question above) posts each NEW red text or email flag as a Slack card with the four rating buttons, never the backlog. One more thing for Fede before it goes live: the shadow cards' channel (C0C283G9QDR) is tagged in the repo as Western Slope's activity feed, audience "customer", though today only Fede, Gera, Sean and the Smith bot are in it; the cards would carry Camellia and Situs conversations too, so they should go to a channel that is ours by name (one-line change). Recommendation: a new internal #clara-ratings channel · the cerebrus repo PropFlow-Technologies/cerebrus was archived Oct 31 13:10 MT (read-only, last push Aug 30, no open PRs; its one open issue, #36, describes the "stated intent, no tool call" idea the app already runs as intent_unfulfilled). Proven in production, Oct 31 13:57 MT: the grading worker redeployed from the deletion commit at 13:21 MT (deploy green) and by 13:57 MT had written 14 per-turn rows on a real Western Slope call, rubric turn-checks-v4+cerebrus-v0.1.19, same as the last row before the deploy (12:37 MT). Steps 1 and 2 of the fold are done; step 3 waits on Fede's two answers above. Closed, Nov 2 (Fede, via 007: "I thought we were done with Cerebrus", "I don't want to continue with it"): the held branch for Slack rating cards on new flags was deleted, no PR opened, no card ever posted. The seven checks stay as quiet app code writing their machine row; nothing reads it. No further work on this lane.

Every place Clara uses a model today

Group	Paths	Real weekly volume	Model today
Clara's main text and email reply	1 (plus 3 pieces already moving)	~120 real turns	Sonnet 5
Voice line	13 live agents	~61 real calls	Sonnet 4.6
Customer-facing writing	19	small, mostly under 20 a week each	Sonnet 4.6 / Haiku 4.5
Decisions and classification	59	two biggest ~200 a week each	Haiku 4.5
Internal writing	15	small	mixed

Nothing in production runs on Opus 5.5 today (real traffic, Oct 18 to 25). Fede's question "why do we need topic classification?": we don't, for phase 1; the turn itself decides reply, silence or hand-off. Path by path: model paths.

Every gate between Clara and a send (Oct 10 to 24)

Of 27 real first emails, 17 were changed after Clara wrote them; 7 changes made the email worse. No rewrite step caught a real problem in 14 days. Fede, Oct 24: "re-inspect all the gates to see which ones are working and not working" and "we are also removing the rewrite gates".

Gate	14 days	Action
Rewrite steps on the first email	"check with the team" 31 (1 real); tour times 5 of 5 wrong; booking promise 12 of 12 wrong; hallucination guard 8 of 10 wrong	Remove
Fair-housing screen (Haiku)	0 of 16 holds right	Retire last
Review-mode hold	102 fired, 1 real catch	Keep
Hold on maintenance texts	120 held, 101 expired unsent	Fix who works it
Door wake rules, voice blocks (482), staff notice check	working	Keep

The Benchmark lane's definition of done: done means.

On 33 real moments, reading the ask ledger before speaking beats not reading it.

Every message takes the same path. The gates are where the spread is.

Doors inTwilio text · our email (SES) · Outlook push · mailbox pollers (Graph, Gmail) · AppFolio guest cards · AppFolio inbox mirror · ElevenLabs call ended · Slack replies · video

One queueSQS FIFO, one group per sender
publishInboundMessage

One consumerlambda/inbound-processor → processEnvelope (text, mirror) or processEmailRecord (every email lane)

Gate 1supervised hold before the turn
decideSupervisedReplyHold

Fixed lanessafety · life-safety · scheduling · rating · maintenance intake, before any model

Routervendor → staff (resolveActor) → tour pipeline → agent turn
routeInboundMessage

The turnhandleIncomingMessageTurn: one system prompt (getUnifiedSystemPrompt), tools by capability, model, tool loop

Gate 2–3opt-out withhold · supervised backstop · reply row written

Gate 4–5outbound policy (test senders, escalated threads, human replied, SMS off) · consent · company-live (email only) · text-draft hold at the Twilio client

Adapters outTwilio text · "SES" adapter that sends via SendGrid · AppFolio inbox text / PMS note · ElevenLabs · Outlook (not in the registry)