Which leads Clara answers

Decisions for Fede this morning, one line each, recommendation first:

1. Phase 0 go: build the source-list setting as one dark PR today. Yes. (Section 9 lines 1 to 5 and section 14 option a stand as written.) Fede: go, Oct 15 morning. Built as PR #20019 (250 lines, merged and live Oct 15; no customer has a list yet). Replay of 2,640 local cards: Western Slope, JP&Co and Situs identical to today with no list; Situs listed to Zillow Rental Network picks exactly its 122 such cards. Proven live at Willows on Oct 15 (box below); the list holds the company's own AppFolio lead-source labels (normalized, not a fixed key set), the company-page field is handed to Smith on the bridge, and the proof is the real path at Willows in production after merge, then a sandbox company in Situs's shape, then Situs on Saturday.
2. The four follow-up rules go into today's check right after phase 0 at Western Slope (its picture already holds threads, tours and applications), and at Situs once the message sync is on; the wake itself comes later in phase 3. Yes.
3. When the model turn inside a wake fails: skip that touch and alert, never send today's words. Skip and alert.
4. The switch: shadow first, then a per-company "follow-up writer" setting off by default with a one-write kill switch, deleted when proven. Yes.
5. Intake judgment step: not built for hold-or-reply; the model decides only what Clara says when a renter wrote something. Yes.
6. When the picture read fails before any decision: hold and re-alarm up to three times, then rules on the last good picture, replacing today's 8-second fail-open-to-send. Yes. (Two mechanisms, two lines: 3 is the model turn, 6 is the data read.)
7. The source list is the one parameter of the level-1 preset, not a new switch on the dark register. Yes.
8. Rotate the production Temporal API key after tonight's echo into a local log. Yes.
9. Situs message sync before Saturday, so follow-ups can see staff texts. Yes, with Gera.

Phase 0 shipped: per-company list of lead sources Clara answers. Merged (PR #20019) and proven live at Willows on Oct 15: with the list set to Zillow Rental Network only, a Zillow card got Clara's reply and assignment (card 232), a staff-typed TurboTenant card was left alone (card 233), the list was then restored. Evidence: proof comment. Situs can be set on Saturday with one command; new companies start with an empty list (Clara answers nothing until a list is set).

Two notes for the builders: the source-list setting must show on the company page, which is Gera's settings lane, so a heads-up goes to Smith on the bridge before that PR. And section 9 line 5 is sharpened by 16.4: the Western Slope default is no longer "reply to every staff-typed card" but "reply unless the typist's own history says hold".

Today Clara answers and takes over every new AppFolio card at a live company, whoever typed it. That was decided on Sept 30. It fits Western Slope, where almost every card comes from a listing site. It does not fit Situs, where most cards with a known creator are typed by a person (21 of 33 since Sept 29; by label, about 450 of 1,189 all time). Whether that person had already talked to the renter is not measured; Situs said on Oct 13 that it is the norm. The Jay Taylor double-contact happened at Western Slope on Oct 9, and nothing shipped since would stop it today.

2. Current state

One event, two robots. Every new AppFolio guest card our sync sees fires one "new lead" event. Two workers act on it on their own: one writes Clara's first email, the other assigns the card to Clara inside AppFolio. Both run the same checklist. Nothing on that checklist asks who created the card or whether a person already owns it.

flowchart LR
  A[New card in AppFolio
any source, any creator] --> B[Sync copies it
about once a minute]
  B --> C{Checklist}
  C -->|company off| X[Nothing]
  C -->|our own card echo| X
  C -->|imported at onboarding| X
  C -->|arrived before go-live| X
  C -->|already applied| X
  C -->|Clara already talking
and card has no message| X
  C -->|passes| D[Assign card to Clara in AppFolio
Supervised: still assigns · Off: refused at the writer]
  C -->|passes| E[First email]
  E --> F{Leasing mode}
  F -->|Live| G[Sent]
  F -->|Supervised| H[Held for a reviewer]
  F -->|Off| X

Three things worth knowing about the assign step. It runs before the email, not after. It ignores Supervised: Clara takes the card in AppFolio while her message is still held for review. (Off is honoured: the writer refuses every AppFolio write for a building whose Leasing is off.) And it overwrites whoever owned the card; the receipt only records the previous owner after the fact.

Other ways a lead arrives. Listing-site emails (Zillow, Apartments.com, Rent., Zillow's relay) go through a separate email lane that recognises senders, not sources, and is gated by a per-company lead-source setting. Phone calls and texts create cards that Clara herself owns. There is no "create a guest card" button in PropFlow. A new listing site we have never seen still gets answered if it also drops a card in AppFolio, because the card path does not branch on source. A new email format we cannot parse falls through to ordinary email triage, so it may still get a generic reply; only an unparsed Tenant Turner email raises an error line.

3. The Jay Taylor case

Correction to the premise: this happened at Western Slope, not Situs. Clara is still switched off at Situs and has never replied to or assigned herself a Situs card.

The card passed every check on the list because the only check that would have stopped it, "a person created this", was removed on Sept 30. Jay's name was on our record the whole time. Clara wrote from the card's inquiry message, which a staff-typed card never has, and did not read Jay's notes. The same shape happened once before: a card Kat Barker typed on Sept 29 got a reply and an assign within two minutes. Of 42 new Western Slope cards since Sept 29, Clara replied to 29; the two staff-typed ones are the only two where a person was already in contact.

What shipped after it (Oct 10): the card reader now returns the notes and the creator; a "reply, wait or skip" decision runs before the first email, with a short wait on hand-made cards; and a "stop, wait or send" check runs before each follow-up. The first-email decision only records what it would have done; the email still goes out. So as of today a second Jay Taylor card would get the same email and the same assign. The follow-up check is real: once a teammate has answered, Clara's later nudges stop.

Fede, Oct 9: "one of the best examples of Clara not having the full context, and sending an email that conflicts with what was sent by the staff."

4. Situs Group vs Western Slope

Since Sept 29 Situs got 64 new cards (21 by a named staff member, 11 by the system, 28 with no creator recorded); Western Slope got 42 (4 by staff). The labels are exactly as AppFolio stores them. "Staff" means a named person typed the card; "System" means a listing site created it.

What this says. Western Slope is a listing-site shop: most cards come from Zillow or another site, made by the system, and Clara answers them. Situs is a hand-typed shop: most cards with a known creator (21 of 33 since Sept 29) are typed by a person, with labels that say a Facebook message, a TurboTenant inquiry, a walk-by, a phone call or an agency referral came first. Turning Clara on at Situs with today's checklist would have her email and take over almost every one of those, including the ones a person just talked to.

Phone calls. Situs staff do log some phone leads as cards, but few: 2 of 64 by label plus one more by its notes. Whether Clara should follow up on those is an open question in section 10.

The Situs sync is paused on purpose. Gera's session paused it on Sept 29 ("locked off until founders deliberately turn it on") and re-scoped it to import-only on Oct 7, which is why 54 of the 64 cards since Sept 29 reached PropFlow only by a one-off import today. No resume is recorded. Any Situs ramp starts with lifting that pause, with Gera, so new cards arrive within the minute.

Where Situs leads could be automated, like the Zillow emails at Western Slope

Correction (Oct 14, after Fede's note): an earlier version of this page said we had never read Situs's email. That was wrong. We read it once, on Sept 1, through the one-time AppFolio extract: 93,656 emails with full bodies, 32,309 texts, 1,355 notes and 883 guest cards for 2026, measured and posted that day. What that pass showed: 313 cards got only an instant auto-reply, the median first human reply took 5.1 hours, 154 cards (17%) never got a human reply, 592 emails went out from cards, and 13% of cards arrived after hours and 7% on weekends. That is the strongest evidence behind the nights-and-weekends recommendation below.

What that pass did not give us, and what no later pass has: a split of the inbound inbox mail by listing site. The extract holds the email AppFolio logged against a person's record, not the raw leasing@ inbox, so a TurboTenant or Section 8 lead that a staff member read in Gmail and retyped into a card appears only as the card. The mailbox (leasing@thesitusgroup.com, Google) has been connected since Sept 29 and Clara is set up to send from it, but live Gmail reads are still paused pending the paid Google security audit or Situs's Workspace admin marking our app as trusted. So the "arrives by email" column below is still inferred from what staff paste into cards. Next pass to settle it: re-run the Sept 1 extract's email set (the 2026 dump on Fede's Drive) with a sender-domain count, which needs no Google audit.

One tell that these are hand-typed: TurboTenant, Affordable Housing, Zillow-direct and Drive By cards are rarely created after hours (5 to 8% of 974 inquiries this year), while Zillow Rental Network, Realtor.com and Zumper run 43 to 63%. Facebook variants sit in between (12 to 36%).

5. What AppFolio tells us about a card

Short version: we can see almost everything we would want, but only one place tells us who created a card, and that is the robot reading the card's activity log, not the reports feed and not email.

Not available anywhere: a yes/no "this came from a listing site" flag (we build it from creator = System plus a renter message plus a site-named source); calls or texts staff make from their own phones; a listing id on the card; any lead webhook from AppFolio. TurboTenant and Facebook arrive only as a label a person types, so there is no email we could hook unless Situs forwards those notifications to a mailbox we read.

6. What we tried before

We have been on both sides of this in four weeks. The creator check went in on Sept 18, got patched seven times, and was removed on Sept 30 at Fede's ask. The Jay Taylor email went out nine days later.

Was removing the creator check a mistake?

Partly, yes. Both passes landed on the same answer independently.

• Dropping "created by a person" as the reply rule was right. At Western Slope staff were retyping Zillow leads into cards by hand (a Sept 29 note put it at about half), so that rule parked real leads, and the robot's creator read stalled a Zillow card for an hour the night before. Since email leads started creating cards automatically on Sept 29, only 4 of 42 Western Slope cards have been staff-typed, so the rule would matter less there now.
• The overcorrection was "no skip logic of any kind." The softer "skip when staff are already talking to the renter" check proposed that night was refused, and the Sept 18 "a person is already assigned" check, written but never wired, stayed unwired. Since Sept 30 Clara has had no way to see a human on a card. That cost two double-contacts out of 42 at Western Slope. At Situs, where most cards with a known creator are typed by a person (21 of 33 since Sept 29), "reply to everything" would reach many renters a person has already answered. The removal fit Western Slope's shape and would not fit Situs's, which is the whole case for a per-customer ramp.
• Who created the card is the wrong signal in both directions. It blocks a staff-retyped Zillow lead nobody has answered, and it misses a System card a staff member already texted. The signal that matters is "has a human already engaged": someone other than Clara assigned, or a staff text, call, email or message to the renter logged before Clara's first touch.

7. Proposed design

Two mechanisms, kept apart because Fede's rules treat them differently: a permanent fix with no switch, and a new per-customer setting that defaults closed.

flowchart LR
  A[New card or lead email] --> B{A human already
has it?}
  B -->|yes: person assigned, or staff wrote
to the renter before Clara| X[Leave it alone
no email, no assign]
  B -->|no| C{Is its source on this
company's list?}
  C -->|all, or listed and on it| D{Leasing mode}
  C -->|not listed, or unknown| Y[No action
one 'new source seen' line a day]
  D -->|Live| E[Assign + first email]
  D -->|Supervised| F[Draft held; assign on approval]
  D -->|Off| X

A. "A human already has it" — a fix, no switch, live everywhere

Honest test first: at 7:20 PM, Jay's card had no assignee, no logged outreach (his earlier email predates the card) and empty notes; the notes landed two seconds after Clara sent. A check that only reads what is on the card at first sight would not have stopped it. So the rule has three parts:

• Skip the first email and the assign when the inquiry is assigned to a person other than Clara, or when a staff text, call, email or message to the renter is logged before Clara's first touch.
• Wait (superseded Oct 14 evening, see section 13: no fixed wait; the gate re-reads the card at send time and before every follow-up) when a person typed the card and it is younger than about 10 minutes: re-read the notes, log and messages at the end of the wait, then decide. This is the Oct 10 rule as designed; it just has to be enforced. It is a product rule about hand-made cards settling, not a scheduling delay, and it would have caught Jay's card by its notes.
• Repeat the "is a person assigned?" check at the moment Clara writes the assign; the card can change between the decision and the write.

• Build it by enforcing the Oct 10 "reply, wait or skip" decision in both workers, not by adding a third gate. Today its answer is discarded.
• Who created the card is a wait trigger, never a skip trigger. A staff-typed Zillow card nobody has answered still gets Clara, ten minutes later.
• Deletes: the unused "assigned to a person" gate, the log-only wrapper, and the stale comments that still describe the Sept 18 rule.
• What it cannot see: a staff call or text made from a personal phone and never logged. For those, only the ramp (B) protects, and at Western Slope on "all" mode they would still repeat.

B. The ramp: which sources Clara acts on — a new company setting

C. Supervised and Off hold the assign too

Today Clara takes the card in AppFolio while her message is held for review. Proposal: Supervised assigns when the reviewer approves; Live assigns at once; Off already never writes. This reverses Fede's Sept 22 "assign as soon as we know" ruling for the Supervised case only, so it is his call (section 9).

Rule collisions, named

• Sept 18 "no setting, no value" and Sept 30 "no allowlists, one engine" versus today's ask for a switch. Resolution: A ships as a fix with no switch. B is a new capability (ramping a customer) and gets exactly one company setting that replaces an existing one, so the setting count does not grow. The "no allowlist" rule was about code-level lists; this is a customer setting Fede sets per company.
• Sept 30 "no skip logic of any kind" versus A. A is a narrower check than the one removed; it never looks at the creator. Needs Fede's yes because it reverses his words.
• Sept 22 assign timing versus C. Fede's call.

Staff-typed phone-call cards

Situs staff do log some calls as cards (2 of 64 by label). Recommendation: leave them alone by default; the caller already has a human. A later option for a centralized team, off by default: follow up after 24 hours if the card's log shows no staff outreach. Replying at once is the Jay Taylor case again.

First source for Situs's nights-and-weekends phase (from Sat Oct 17)

8. Fable vs Opus

Two independent passes, then one rebuttal round. Opus 5.5 wrote its pass without seeing Fable's; the census and code findings were shared with both.

One caveat Opus held and Fable accepts: the "two of three Situs cards are typed by a person" figure is measured before Clara is on at Situs, so it is the expected shape, not a result.

10. Open questions

1. Assumption, not a question: card 3004's log did not hold Jay's Oct 7 email at 7:20 PM (the card was three minutes old and the notes arrived after Clara sent). Check A relies on the hand-made-card wait, not the log, for this case. The replay of cards 3004 and 1823 in the proof list tests exactly that.
2. Do Situs's assistants log their TurboTenant and Facebook outreach in AppFolio? If never, check A cannot see them and TurboTenant stays off the list until the email parser exists. Cheapest: ask on the Oct 16 kickoff, and sample 20 recent TurboTenant cards' logs.
3. Do TurboTenant and Zillow Network cards at Situs show "Guest Card Received" by System? Not checked yet (the Oct 12 page says so too). Cheapest: the same 20-card sample.
4. When does the Situs sync pause lift? It was deliberate (Sept 29, import-only since Oct 7). Lifting it is a step with Gera before the Oct 17 phase, not an incident.
5. Should Clara follow up on staff-typed phone-call cards after 24 quiet hours? Fede's call per customer; default is leave alone.

11. Method and evidence

• Code: read on the tip of main at 084ca8b7 (Oct 14), then re-checked at d7a246d1 for the Oct 10 changes. Nothing edited, no PR opened.
• Production records: read-only queries of the prospect list, write-intent and outbox tables for Situs and Western Slope, Sept 29 to Oct 14. Scripts kept in the session scratchpad; counts are new AppFolio guest cards by the label AppFolio stores.
• History: session transcripts (scoped per project folder), docs pages, Slack #transcripts raw thread of the Oct 13 Situs call, Fede-Gera messages of Oct 12 and 14, PR list on GitHub.
• Mailbox: read once, on Sept 1, through the AppFolio extract (93,656 emails with bodies, posted in #transcripts that day); not re-read for this page. The raw Gmail inbox has not been read live (Google read scopes paused pending the audit). The listing-site split of inbound mail is inferred from the text staff paste into cards.
• Two passes: Fable 5.1 (this session) and an Opus 5.5 agent, independent, then one written rebuttal round. Both drafts and the rebuttal are in the session scratchpad.
• Inference labels: the TurboTenant-by-email claim and the "two of three typed by a person at Situs" shape are inferred from records, not observed live.

12. Knowledge gaps: can Clara answer Situs renters today?

Updated Oct 16. The repeatable harness (/knowledge-coverage) supersedes the hand run below. Its first grading was wrong in three ways (no listing data shown to the judge, company-wide policies not accepted without a per-building entry, availability and rent counted as knowledge); corrected and re-run Oct 16: Situs 23.5% of knowledge questions answerable, 71% of listing-data questions; Western Slope 47% and 79%, with pets fully covered by the company policy and utilities the one real gap. Current numbers live on knowledge-coverage-situs and knowledge-coverage-western-slope.

How this was measured, and its limit. The 999 Situs cards from Oct 2025 to Sept 2026 could not be replayed through Clara's real composer: none of them has a PropFlow person or inquiry record to compose against. So a model (Sonnet) compared each renter question against an inventory of what the Situs knowledge base holds today. These are predictions of what Clara could answer, not Clara's actual replies. A real replay needs the old cards matched to the 52 PropFlow buildings and run against a sandbox company.

What Situs's knowledge base holds today: three company entries (office address, walk-ins by appointment, how residents pay), office hours, and deposit and fee amounts copied from listings at 20 of 52 buildings. No building has a policy written down; every amenity list is empty.

By source, the share needing a missing fact is highest where the renter already talked to a person: referrals (19 of 22), TurboTenant (35 of 50), housing programs (22 of 31). Zillow is the most answerable: 26 of 88 non-tour questions answerable, 46 missing.

The big boulders, by questions they block

Zillow specifically. 245 Zillow cards, 159 questions; 71 of them are only "can I see it" (calendar). The rest Clara mostly handles (availability, rent, application link) except pets, deposits and move-in cost, co-signers at the DU student homes, application fee (staff replies say none at Carr; Emerson has a $26 fee on record), accessibility. Quickest win for a Zillow-first ramp: a company-level pet rule, co-signer rule, application-fee rule and deposit rule, plus a Carr Street Flats fact sheet.

What onboarding still owes. Connecting the calendar would unblock up to a third. The larger half is the company policy questionnaire (screening, pets, vouchers, deposits, specials, lease terms) plus about ten building fact sheets, led by Carr Street Flats, Barcelona, Lampliter, Aspen Leaf and the DU homes. Staff replies in the export already hold first-draft answers for about 120 questions; the client still confirms each one, per the knowledge-base writer rules.

Rent and availability count as answerable, but with the Situs sync paused since Sept 29, any live answer needs the pause lifted first. Outputs with renter names stay local under the corpus runs folder for Oct 14 and were not pushed anywhere.

13. The gate, redesigned: signals in, one decision out

Proposed, pending review. Fede, Oct 14 evening: no hardcoded "wait 10 minutes for a staff-typed card". Read every signal on the card, decide fast, and keep the per-company ramp list inside the same decision. One engine, called at intake and again before every send.

flowchart LR
  A[Card or inquiry event
from the PMS] --> S1[Signals already in our mirror
creator · source · renter message
assignee · status · age · hours
company mode · ramp list]
  A --> S2[Signals that need a card read
notes · activity log
texts, calls, emails logged
showings · known person]
  S1 --> G{decideLeadAction}
  S2 --> G
  G -->|REPLY| E[First email, assign,
then the whole machine]
  G -->|HUMAN_HAS_IT| H[Stand down.
Watch; help later if asked]
  G -->|OUTSIDE_SYSTEM| O[Stand down.
A person is already talking]
  G -->|SKIP| K[Nothing: applied,
inactive, duplicate, pre-go-live]
  G -->|undecided| R[Reasoning layer reads
notes and messages, then picks]
  E -. before every follow-up .-> G

The signals

The decision, in order

1. SKIP if the inquiry is already applied, inactive, a duplicate of an active one, or older than go-live.
2. OUTSIDE_SYSTEM if the source key is a human channel (Facebook, drive-by, referral, phone, walk-in). A person is already talking to them; Clara stays out unless staff hand it over.
3. HUMAN_HAS_IT if a person other than Clara is assigned, or any human touch is logged on the card or the comms log, at the moment of the check. The check runs at intake, at send time, and before every follow-up, so Jay's notes two seconds after the send stop the next step instead of being missed.
4. REPLY if the card came from a listing site or the website (System), carries a renter message, and its source key is open on this company's ramp list.
5. Undecided (a person typed it, nothing logged yet, no message): the reasoning layer reads the notes and the card and answers reply, human has it, or ask. The default while that layer does not exist is set per company from the one-year distribution in section 15, not from a clock: Situs "a person typed it = a person has it" (92% touched within 10 minutes), Western Slope "reply unless something is logged" (their typed cards are retyped Zillow leads). Situs will likely want "a person typed it = a person has it"; Western Slope retypes Zillow leads nobody has answered and wants the reply.

One engine instead of four call sites

Scales past these two customers: every property manager has the same split, syndicated and website leads that arrive on their own versus referrals, walk-ins and phone calls a person already owns. The source keys are defined by arrival plus label, not by customer, and the ramp list is a per-company setting, not code. The only customer-shaped thing is the default for "a person typed it and nothing is logged yet", and that comes from data.

14. Long term: Clara joins mid-stream

Today's design starts every lead at step one and runs to a booked tour or silence. That is the Camellia shape, and it breaks at scale: plenty happens person to person, off the recorded lines. Today's Western Slope call (Jay, Kat, Jason with Fede, Gera and Sean) gave four real cases:

The shape of the fix

Fede's framing (Oct 14, ~9:15 PM): this is a general capability, never a customer rule. The stage is inferred from facts on the record. Staff add facts (a note, a logged call, a showing), never instructions to Clara. One decision runs before every send.

1. A stage on every inquiry (new, contacted, showing booked, showing done, application sent, applied, no outreach). The gate reads it; the machine starts from the stage, not from step one.
2. Three ways the stage gets set, all of them facts: inferred from the activity log (showing occurred, application sent), told to Clara by text or call ("I showed her 566 Placer at 2", a fact Clara logs, then infers from), or set by the staff member on the PropFlow lead page. Early on, Clara confirms with one clarifying question (Gera's suggestion) before she acts on a told stage.
3. Stand down is a posture, not a stop. On HUMAN_HAS_IT and OUTSIDE_SYSTEM Clara keeps the card in her list, keeps the notes flowing to AppFolio, and offers help when asked (the call list, "want me to send the app?"), without a single unprompted message to the renter.
4. The reasoning layer is where notes and free text get read. Hard rules stay for the cases that must never go wrong (applied, assigned, human touch); the layer handles the rest and its answers are logged for the harness.

Clara hydrates before she acts (Fede, Oct 14, 7:52 and 8:06 PM)

The mindset: a new employee in AppFolio opens the guest card, reads the activity log, the notes and what has already been sent, and only then decides. Clara does the same, at intake and again every time a follow-up timer fires. Rules first, for the cases that must never go wrong; then the model reads the whole block as a person would and chooses: proceed, hold, or do something different.

flowchart LR
  T["Timer fires
(24h, 72h, ...)"] --> H["Hydrate: one context block
card · activity log · notes
every text, call, email · tours · stage"]
  H --> R["Hard rules
applied / assigned / human touch / asked to stop"]
  R -- "rule held" --> X["stop or wait, logged"]
  R -- "no rule" --> M["Model reasons over the block"]
  M --> P["proceed as planned"]
  M --> D["send something different"]
  M --> W["hold, say why"]

Where today's code already is, and where it is not (read on main, Oct 14; nothing changed):

What this changes in the design above: item 4, the reasoning layer, gets a precise job. It is one call, at intake and at every timer, over the same block the rules read, and it returns one of four: proceed, hold with a reason, stand down, or a changed action (send the application, confirm the showing, answer the open question). The rules keep veto power; the model never overrides a hard stop. Its answers are logged beside the rule's answer so the harness can replay a year of cards and show where the two disagree. The schedule stays as the alarm clock, not as the decision.

The alarm clock: a general pattern, not a leasing rule (Fede, Oct 14, ~10:15 PM)

Temporal stays. It is solid and centralized, and it keeps every timer, retry and action it runs today. What changes is one thing: the workflow stops sending the message itself from a hard-coded template. At the timer it hands back to the core Clara loop. Clara wakes up, reads everything that happened since she last touched the lead, and decides: proceed, hold, or do something different. Not a setting; it applies to every customer. Leasing follow-ups first. Renewals and maintenance follow-ups follow the same pattern later, because people interject there too and we follow up blindly today.

flowchart LR
  subgraph today["Today"]
    T1["Temporal timer"] --> S1["Workflow activity
composes and sends"]
  end
  subgraph after["After"]
    T2["Temporal timer
(alarm clock)"] --> C["Core Clara loop
hydrate · rules · reason"]
    C --> P["proceed"] --> D["same send door"]
    C --> H["hold / stand down
(logged, timer moves on)"]
    C --> X["changed action"] --> D
  end

Where Temporal sends on its own today (observed on main, Oct 14): twelve activities compose and send messages from inside the workflow: prospect outreach, prospect re-engagement, renewal, maintenance comms, collections chase, post-tour chase, tour confirm nudge, promise, PM action reminder, mass comms, turnover, tenant confirmation review. Leasing is prospect outreach and re-engagement, where the stop/wait/send check already sits; that is where the seam goes first. The rest keep sending as today until each is moved, one at a time, with its own replay.

Proof before anything turns on (Fede, Oct 14, ~10:30 PM: "we better make sure whatever new thing works as well as what we have"). The Temporal permutation harness pins each workflow's observable behavior as committed goldens and grades a refactor mechanically: unchanged, fixed defect, regression, or new behavior. Checked on main tonight: it covers tour, renewal, pipeline and countersign. It does not cover prospect outreach or re-engagement, the two leasing workflows the alarm clock would touch first. So the order is fixed:

1. Pin today first. A prospect-outreach adapter in the permutation harness, goldens recorded on today's behavior, merged before any refactor. Pure test code, no behavior change.
2. Alarm clock in shadow. The timer calls the core loop, the loop writes its answer beside the rule's answer, Temporal still sends as today. The harness diff must read "unchanged" for every golden, and the year-of-cards replay shows where the two answers differ.
3. Flip one workflow (prospect outreach) only when the shadow log and the replay agree with staff on the disagreement table, then Willows live, then the sandbox company in Situs's shape, then a supervised week. Re-engagement, renewals and maintenance each repeat steps 1 to 3 on their own.

Order of work once Fede says go (each a small dark PR, none opened before his yes): (1) the gate from section 13, enforced at intake, over the existing picture; (2) re-read the live card at send time instead of the last sync, and fail closed to "hold" instead of open to "send" when the read fails; (3) give the follow-up writer the whole block, not a notes string; (4) the reasoning call, logged beside the rules first, deciding second, once the harness shows it agrees with staff on a year of cards.

Choices for Fede, with a recommendation: (a) staff slot a lead in by texting or calling Clara, and the stage is also inferred from the log — recommended, it is already how Western Slope works with her; (b) a note convention on the card ("admin, no outreach") as the fallback for Situs-style teams that live in AppFolio; (c) a stage picker on the PropFlow lead page, later, under Gera's settings lane.

Overnight Oct 14 to 15

Fede, 10 PM: "start with architectures, prototypes, harnesses; tomorrow morning give me findings with confidence, what went wrong, what worked; then we decide." Five pieces of work, all local, results folded into this page as each lands:

Morning shape: one findings table on top (pattern, confidence, evidence, what it changes), then the Situs slice, the cohesion map, the alarm-clock seam with its switch, and the decisions Fede asked to make in the morning. The seven yes/hold lines in section 9 and section 14 stand; nothing is re-asked tonight.

15. One year of cards: what the gate would do at Situs vs Western Slope

Headline: at Situs, a staff-typed card is a person's work: 80% get a staff text within 2 minutes of being typed, 92% within 10. At Western Slope the same wait finds almost nothing (40% at 10 minutes, 18% never), because their staff retype Zillow leads they already answered in the Zillow inbox, which AppFolio never sees. So no single wait fits both; the default for "a person typed it and nothing is logged" is per company, and the gate re-reads the card at send time anyway. The cards Clara is for are the automatic ones: at Situs a Zillow Rental Network card waits a median 19 hours for a human and 13.5% never get one.

Local harness, no PR, no CI, aggregates only. Situs window Sept 1 2025 to Aug 31 2026 (1,024 cards). Western Slope window Sept 1 2024 to Aug 31 2025 (964 cards; the 2026 cards were pulled without their activity log, and that year is distorted: their Zillow Rental Network feed was typed by staff from Nov 2024 to Aug 2025 and is automatic again now). Coverage: every row above 99% (activity log present, creation event found, timestamp parsed). Self-check with a planted card and a planted control passed. Files: gate_harness.py, coverage.md, mapping.md, results.md, results.json in the session scratchpad.

Outcome at the moment the card arrives

P1 = a staff-typed card counts as "a person has it". P2 = only a logged staff action counts.

By source at Situs (P1), with how long a human takes today

Reading it: every staff-typed source at Situs is touched within a minute or two of being typed, because the card is created as part of sending the first text. The automatic ones wait hours or days. That is the gap Clara fills, and it is exactly the Zillow Rental Network first-source call in section 9.

The curve that replaces the 10 minutes

Among staff-typed cards, the share with a first staff touch within N minutes (cumulative):

Ramp scenarios: share of all cards Clara would answer

Check against this month's production cards

Cards from Sept 29 to Oct 14 where the robot stamped the creator: Situs 33 agree, 0 disagree (TurboTenant, Facebook, Affordable Housing, referrals, drive-by all typed by staff; Zillow Rental Network and Website by System). Western Slope 12 agree, 11 disagree, and 6 of the 11 are Zillow Rental Network cards that are automatic now and were typed by staff in the 2024–25 window. The source mapping holds; one production label (a person's name) falls to "other".

Caveats

• Replies made outside AppFolio (Zillow inbox, personal phones, Facebook) are invisible, so "never touched" overstates the gap, most at Western Slope's plain-Zillow cards.
• Cards AppFolio creates from an application (178 Situs, 110 WS over all years) and "Shared Application Link" cards are skipped, as the gate would.
• The dumps were taken Sept 1, so mid-2026 Situs cards had less time for a reply; arrival-time signals are unaffected. Cards converted to a lease may be missing from the list filter.
• Whether the renter wrote a message shows on only 7% of Situs cards in the dump; staff assignment on a few. Neither drives these numbers.

16. Overnight findings

16.0 Roadmap draft for the morning (Fede, ~11 PM: "start with the must-haves, then three to five phases")

Objective: Clara stops replying to everything by default. Nothing goes to production tonight. Each phase ships dark, is proven on the ladder, and turning on at a customer is Fede's call. This draft gets sharpened as the Situs slice, the two prototypes and the Temporal study land.

Phases 0 and 1 can run in parallel; 2 depends on 1; 3 depends on 2; 4 depends on 1 and 3; 5 after 3 is proven at one customer. The four follow-up rules from 16.5 do not wait for 2 or 3: at Western Slope they land in today's check right after phase 0, proven by the same replay; at Situs once the message sync is on.

16.1 Cohesion with the platform (architecture pass, Opus 5.5, landed 10:50 PM)

Three findings that matter in the morning. (1) The alarm seam already exists: a timer that wakes Clara's loop with an event and no pre-written text was merged today, with one caller, the after-tour check-in; prospect follow-ups are "not wired to this yet" and the wake reads the thread only, not the person picture. (2) Clara hydrates from an empty glass at Western Slope and Situs: the picture holds her own thread plus the card's creator and status; card notes and activity rows arrive once, behind a per-company import that is off everywhere, and the assigned user is not in the picture at all. The gate is inert at both customers until that feed is on. (3) Every idea on this page already has a home on another page and none is wired end to end; the right next PR is "the alarm reads the picture", not a new engine.

Verified by this session on main: the wake function and its single caller. Reported by the pass, not re-checked here: the notes-import switch state and the missing assignee.

One vocabulary, so five pages stop using five words

Gate outcomes in that vocabulary: reply = act; a person has it = record, then wait; outside the system and skip = record; undecided = the judgment step.

One architecture: doors make events, Temporal keeps time, one loop decides

flowchart LR
  classDef built fill:#d8f0d8,stroke:#2e7d32;
  classDef partial fill:#fff3c4,stroke:#b8860b;
  classDef legacy fill:#f8d7d7,stroke:#a33;
  classDef proposed fill:#ffffff,stroke:#666,stroke-dasharray: 5 5;
  subgraph DOORS["Doors"]
    CARD["AppFolio card sync"]:::built
    TICK["AppFolio inbox tick, Willows only"]:::partial
    MAIL["Listing and inquiry email"]:::built
    LINE["Clara's line: text and call"]:::built
    STAFF["Staff text Clara"]:::built
  end
  NOTES["Card notes and activity: once at arrival, import off everywhere"]:::partial
  FD["Front door: one event per wake"]:::partial
  subgraph CLOCK["Temporal = alarm clock"]
    T["Durable timers and retries"]:::built
  end
  TPL["Template rendered in the workflow: about 15 senders"]:::legacy
  W["Alarm seam (scheduled wake): tour check-in only"]:::partial
  TH["Agent turn over the thread only"]:::built
  subgraph LOOP["Core loop"]
    H["Hydrate: person picture"]:::partial
    R["Hard rules with veto"]:::partial
    J["Judgment step, log-only first"]:::proposed
    H --> R --> J
  end
  SEND["The activity's own send code: safety screen, door resolver, send gate"]:::built
  REC["Decision recorded on the lead, replay harness"]:::partial
  CARD --> FD
  TICK --> FD
  MAIL --> FD
  LINE --> FD
  STAFF --> FD
  FD -->|"new lead"| H
  NOTES -.->|"proposed: fresh at every wake"| H
  T -->|"today, most senders"| TPL --> SEND
  T -->|"alarm"| W
  W -->|"today"| TH --> SEND
  W -.->|"proposed next PR"| H
  J -->|"act or ask"| SEND
  J -->|"record"| REC
  J -->|"wait: set next alarm"| T

Green = built and live. Yellow = partial or switched off. Red = the old way. Dashed = proposed.

Where this page overlaps or contradicts the other pages (each needs one ruling in the morning)

1. Failure posture, four versions on record: the follow-up check sends anyway after 8 seconds; the new wake throws ("never a blind send"); this page holds; the Sept 29 design says Clara never blocks on a failed read. Recommend: hold and re-alarm up to three times, then apply the rules to the last good picture.
2. Three designs for "a person touched it" (this page's logged touch, the Sept 29 first-human-touch stamp, the call list's staff clock) and three for "should Clara engage" (this page, vision 4.4, PMS conversations 8c). Merge today's two rule sets into one decision, entered at intake and at every alarm; do not add a third decider.
3. The ramp list is a switch. Either it is the one parameter of the level-1 preset (which sources Clara owns at a company) or it owes a dark-register line. Recommend: the preset parameter.
4. Re-read at send time: the tick sees texts, only a card read sees notes, activity and status. Both are needed.
5. Two rule mismatches seen in code, not proven bugs: opt-out is "either channel" at first touch but "both channels" in follow-ups; former tenants are skipped at first touch but not in follow-ups.
6. "Hand-made" is not "staff-typed": a Zillow card retyped by staff gets a reply today, while the harness says a person has it.

Three biggest risks, ranked

1. Empty picture. With notes, activity and assignee missing, the rules and the judgment step say "proceed" in Fede's exact cases (Kat's off-system showing, a call 20 minutes ago). Fix: one per-company feed at a sane cadence with no row to press, read fresh at each wake.
2. New template senders keep landing. The first-reply text merged as a template 15 minutes before the alarm seam, from the same account. Fix: a build check with a planted violation so a person-facing activity that renders text without a wake goes red, plus a ratchet list that only shrinks.
3. The judgment step leaks or drifts. Notes carry fair-housing content (8% at Western Slope, 34% at Situs per the leasing designs page) and the audience tag alone did not stop a leak in an earlier test. Fix: rules keep the veto; the model sees status fields and labels, never raw note text, until a planted-leak test passes with zero leaks.

Edits to this page the pass recommends (applied in the morning after Fede's rulings, not tonight)

Drop the new decision function name and say "one decision, the two rule sets merged"; add the first-reply text and the tour check-in wake to the call-site table; say the stop/wait/send check runs on three leasing senders, not every send; cite the alarm seam as built with prospect follow-ups as its next caller; add a step 0, fresh card notes, activity and status at each wake; add the assignee and the raw source key to the picture; rename "reasoning layer" to "judgment step"; state one failure posture; name what this page does not own (tick and door resolver: session 006; send gate: Gera; notes classifier and picture builder: their rows); do not make today's 10-minute wait on hand-made cards a rule; do not promise note text to the model until the leak test passes.

Full pass with file and line citations: session scratchpad, pass2-opus.md.

16.2 The Situs minimum slice, against the code (Fable 5.1 pass, landed 11:15 PM)

One setting is enough for Saturday. A per-company source list, enforced inside the one eligibility function both the first email and the self-assign already call. Today a live company answers and assigns every new card, any source, any creator; the only company gate is the live flag. With Situs set to Zillow Rental Network only, the "who typed it" question never arises: all 96 Zillow Rental Network cards in the harness year were created by the system, and every staff-typed card carries another label. No hours gate anywhere; the Saturday-night and Tuesday-morning cards get the same answer.

Four real Situs cards walked through the slice (list = Zillow Rental Network, Live): a Zillow Rental Network card received by the system Saturday 7:37 PM, no renter message, unassigned, staff's first text 40 hours later: reply, email and assign within two minutes. A TurboTenant card typed by "Assistant Lead" Wednesday 10:06 AM with a staff text the same minute: nothing, one log line. A TurboTenant card typed by Courtney with "sent you the link to apply" two minutes later: nothing. A Zillow Rental Network card Tuesday 9:45 AM with a renter message, staff called 5.5 hours later: reply, identical to Saturday. About 93% of Situs cards carry no renter message, so reply must not require one; today's code does not, and section 13 of this page will be corrected to match.

Ops steps before Saturday, not PRs: resume the Situs sync (Gera) and let the backlog settle as not-live skips; set the list; confirm Clara's AppFolio seat on all 52 Situs buildings (a missing seat parks every assign while the email still sends); flip the live flag early in the day, because the go-live floor compares calendar days and a 5 PM flip answers that morning's cards.

Three things most likely to bite at Situs that the slice does not cover:

1. The follow-up check is blind to AppFolio staff texts. It reads PropFlow threads, tours and tenancy, never the card's activity rows, and the AppFolio message-thread sync at Situs is listed as work in progress. Shape: Clara answers Saturday, the assistant texts the renter inside AppFolio on Sunday (median 19 hours), Clara's 24-hour nudge lands in a live staff thread. The once-at-arrival notes import does not help; it runs at intake, not at the timer. Cheapest cover: connect the message sync before Saturday, or accept it for week one and read staff touches at timer time in the next PR.
2. Clara's seat on every building. The AppFolio user is being created this week; verify all 52 rows Friday.
3. The plan over-promises. The rollout page promises TurboTenant on Oct 17; the data says TurboTenant is hand-typed every time at Situs, so it is off the Saturday list. And on the cards she does answer, 48% of a year's renter questions need facts the Situs knowledge base lacks, and the calendar is not connected, so "book the tour" lands as "someone will follow up".

Left out on purpose, and why Situs can go live without it: reasoning over notes (Zillow Rental Network cards arrive with none), a stage per inquiry and live card re-read (a system card starts at step one and the first email is the whole Saturday job), the TurboTenant key (needs staff touches visible or the email parser), Supervised holding the assign (Situs starts Live per the plan). Said plainly: Jay Taylor's Western Slope card is not caught by this slice; only the follow-up stop covers that shape.

Not checked tonight: whether the Situs email lane, the notes import switch, or Clara's seat are set in production. Full pass with file and line citations: session scratchpad, pass2-fable.md.

16.3 Temporal: the alarm-clock seam, the switch, the risks (deep study, Opus 5.5, landed 11:30 PM)

Smaller change than feared, with one real hazard. Today's leasing follow-up is not a fixed template: inside the workflow, one step asks a narrow model prompt for the words, then sends. The change is that this one call becomes a wake of Clara's loop through the seam merged today; timers, quiet hours, reply signals, the send-once guard, consent and the touch counter all stay exactly as they are. No workflow logic changes. One number changes: the send step's 60-second limit becomes about 4 minutes, because a wake can take two. The hazard is a double send if a wake times out and a retry runs beside it; the fix is the longer limit plus the send claim staying ahead of the compose, proven by a planted double send going red in the harness.

Production, last 30 days, read-only from Temporal Cloud:

How often a follow-up actually goes out (200 of the 654 finished runs read): 180 sent no follow-up at all; 130 ended because the renter replied, 122 of them before any follow-up; 23 ended on a stop condition (merged, deleted, applied, tour booked, home gone). Of the 98 runs live right now, 57 are past touch 1 with two or more sent, so newer runs send far more. The hidden number is silent skips: across every attempted touch, 73 were skipped for no consent, 33 because the text step did not send, 22 for opt-out, leasing off or company not live, 17 for no mailbox, 11 because the lead had already advanced. Any redesign of the follow-up decision sits behind those gates; consent is the biggest one.

Leasing follow-ups never failed in 30 days; every non-completion was a termination (prospect deleted, Fede's manual cleanups, the Oct 2 "stop post-call follow-ups"). No retry storms anywhere. 110 live runs are the whole population a bad deploy could hit. Half of all timers in a real run are quiet-hours holds, so a wake that ends at 7:58 PM matters. Renewal (322 terminated, 24 failed) and maintenance comms (211 timed out) have their own problems and need their own look before they become "later" domains.

The switch and the fallback, options with a recommendation:

Recommendation: c, then a. Shadow first, diffed locally on the subscription over captured touch contexts plus a small production shadow (about 30 turns a day, tools off so it can write nothing a customer sees). When the diff is clean, add the company setting, off by default. Delete it the week it is proven everywhere. One ruling for Fede in the morning: when the wake fails, (1) skip that touch and alert, (2) send today's words, or (3) retry at the next touch. Recommend (1): option 2 brings back "the timer sends words Clara never reviewed", which is the thing being removed; the reconciler and the next touch catch up; the real fallback is the kill switch plus an alert when wake failures pass 5% in an hour.

Ten regression risks, ranked, each with what catches it: (1) double send from a timed-out turn: 4-minute limit, claim before compose, planted scenario; (2) tool side effects inside a retried turn: tools off in version 1, a test asserts zero tool calls; (3) one wake error killing the whole sequence after five retries: the step catches every wake error, scenario "wake throws five times" must never end failed; (4) nondeterminism against the 110 running timers: keep the swap inside the activity, replay 20 real production histories per workflow first; (5) the wake knowing less than today's prompt (price drop, other homes, call context): the context block carries those facts, shadow diff on real leads; (6) quiet hours: the hold stays in the workflow, the door re-checks; (7) consent and opt-out: unchanged gate order, scenario "STOP arrives during the wake"; (8) state drift: a silent wake must not move the touch index; (9) the reconcile sweep re-sending a touch the loop held: decide that a resume skips held touches; (10) a worker deploy mid-turn: the claim from risk 1, plus a chaos test.

Proof plan and PR chain, eleven PRs each one concern and none with a customer effect until the ninth: outreach permutation adapter with today's goldens; re-engagement adapter; 20 + 20 real production histories into the replay corpus; the 4-minute limit, replay-proven; the wake context builder, pure, tools off; shadow mode (wake after compose, log the diff, still send today's words, catch every error); the shadow diff report on this page; the company setting with its kill switch, dark; the activity uses the wake when the setting is on, Willows first; same for re-engagement; delete the setting and the old branch once proven. Test gaps found tonight: the permutation harness has nothing for outreach or re-engagement and no planted-bug controls; outreach has two recorded production runs to replay against, re-engagement zero.

Security note for Fede: while pulling the production numbers, the agent's first command echoed the production Temporal API key once into its own local log in this session's temp folder. It was redacted there tonight and appears in no saved file. Rotating that key is a third-party production write and is your call; recommend yes.

Full study with file and line citations: session scratchpad, temporal-study.md, with the raw production pulls beside it.

16.4 Prototype: the judgment step at intake, graded on a year of cards (landed 11:40 PM)

Do not build a reasoning layer for the hold-or-reply call. On the cards the rules cannot decide (typed by a staff member, nothing logged yet: 282 at Situs, 295 at Western Slope), the model was worse than the simplest rule at both companies. Situs: hold on every one is right 95% of the time; the model 81%. Western Slope: reply to every one is right 59%; the model 30%. A bigger model changed one answer in fifty. The reason is not the model, it is the card: 99% of these cards say only "typed by X at time Y". What does predict the outcome is who typed it and how: a lookup by company, source, typist and hours, learned from each company's own history, is right 95% at Situs and 66% at Western Slope, matching or beating the model at both. Keep the model for the one place it earned its keep: the rare card where the renter wrote something, to decide what Clara says, not whether.

Note on the numbers: section 15 says 40% of Western Slope staff-typed cards are touched within 10 minutes; here only 27% get a person within 60 minutes, because this set excludes cards a person touched in the same minute they were typed. "Hours" in the lookup is a signal learned from history, never a gate on when Clara answers.

Grading was observable, not opinion: hold is right when a person texted, called, emailed, noted, booked or sent an application within 60 minutes; reply is right when nobody did within the hour and no person booked or sent within 24 hours. 1,516 model calls on the subscription, zero errors. The self-check plants a future event and asserts it never leaks into what the model sees.

Patterns, with confidence:

1. The model reads "a person typed it" as "a person is on it". High. True at Situs (staff reply within 5 minutes), false at Western Slope where most typing is data entry. The card cannot tell these apart, so no prompt fixes it; the company default is the better rule.
2. "After hours means nobody is there" is backwards at Situs. High (n=23). Situs staff who type a card at night or on a weekend reply within minutes, 22 of 23. The model said reply on 17 of them. A Situs staff-typed card is hold at any hour.
3. Who typed it is the strongest signal at Western Slope. High. Kat's cards got a person within the hour 62% of the time, Michelle's 18%. The plain rule "Kat typed it: hold; anyone else: reply" lands at 66% and is the version to adopt.
4. Batch typing is data entry. High at Western Slope. A card typed within 10 minutes of the typist's previous card got a person within the hour 13% of the time; 108 of 150 sat more than a day. At Situs the same pattern means the opposite: 48 of 48 batch-typed cards got a reply. A per-company rule; the model cannot see it because it reads one card at a time.
5. The question wording made the model contradict hard facts. High. On 100 control cards where staff had already sent an application or booked a showing, it said reply 38 times ("staff handled it, nobody needs to act"). One added sentence fixed it, 99 of 100. And the model must never see a card the rules already decided.
6. The renter's own words are where the model earns its keep. Low (20 cards). "Can you send me an application": send it. "Which unit is this, is this spam": answer. A current tenant's maintenance texts: not a lead. A staff note "DENY" in the message field: flag, do not reply. This fits the existing reply step, not a gate.
7. Holidays and system showing confirmations. Low (3 cards). Two July 4 cards and one "your showing is scheduled" text at creation: both are rules to add, not model work.

What this changes on this page: roadmap phase 4 shrinks. The judgment step is not a hold-or-reply decider; it decides what Clara says when a renter wrote something, and it stays behind the rules. Layer 1 gains three cheap rules: per-company typist lookup refreshed monthly, batch-typing per company, holidays. Model confidence scores mean nothing here (answers between 0.6 and 0.8 were right 29% of the time at Western Slope). Caveats: replies made outside AppFolio and the Zillow inbox are invisible; the Western Slope year is 2024 to 2025. Files: gate-harness/layer2_findings.md, layer2_results.json.

16.5 Prototype: wake-and-look follow-ups, graded on a year of cards (landed 12:20 AM)

This is where the model earns its keep. Every automatic card that Clara would have owned got three synthetic follow-up wakes, at 24 hours, 3 days and 7 days: 1,252 wakes across 171 Situs and 249 Western Slope cards. A fixed timer with no check lands on top of a person already working the lead 44% of the time at Situs and 35% at Western Slope. Today's rules-only check still sends into fresh human activity 26% and 28%. "Wake and look" with the model cuts that to 11% at both, and to 4% and 7% when the model may change the action. On a lead where nothing ever happened, both the rules and the model send every time, 321 of 321: the model never invented a reason to hold.

The biggest gain is at the 24-hour wake: 62% right for the rules against 91% for the model. Opus 5.5 on the 40 hardest wakes changed 11 answers and did not change the picture; Sonnet is enough. 2,504 calls on the subscription, zero failures. No real Clara sends are in this data (Clara never ran at Situs, and the Western Slope year predates her), so every "send" here is hypothetical.

Four rules to add today, no model needed. Most of the rules' misses are one shape: a single teammate text with no renter reply yet. The rules send anyway, on purpose, because a lone greeting never holds a follow-up. In 188 such wakes, the model held every one where that text was under 12 hours old (74 of 74). A time box catches most of these. Three more: the renter wrote back to a teammate (37 wakes, model holds 91%); a showing is booked for later (36 wakes, model never proceeds); an application is out (22 wakes).

What a changed action looks like. Allowed to do something other than the generic check-in, the model turned 175 wakes into something better: 88 showing messages (confirm, after-tour, reschedule), 43 answers to a renter's unanswered message, 39 application nudges. It never did this on a lead with nothing going on.

Recommendation from the prototype: ship the four rules now inside today's check; then make the wake a model look that may change the action, for leads where anything human happened since the last touch. Files: gate-harness/followup_findings.md, followup_results.json, followup_calls.jsonl.

16.6 The morning: what the night says, and the decisions

In one breath: Situs needs one setting for Saturday. The reasoning layer is not worth building for "should Clara reply"; cheap rules beat it. It is worth building for follow-ups, where today's fixed timers land on a person a third to a half of the time and "wake and look" cuts that to one in ten. The alarm-clock seam already exists and the Temporal change is small and well-contained. The glass is empty at both customers until notes, activity and assignee flow fresh at every wake. Nothing shipped tonight; no PR was opened.

Decisions for Fede this morning, one line each, recommendation first:

1. Phase 0 go: build the source-list setting as one dark PR today. Yes. (Section 9 lines 1 to 5 and section 14 option a stand as written.) Fede: go, Oct 15 morning. Built as PR #20019 (250 lines, merged and live Oct 15; no customer has a list yet). Replay of 2,640 local cards: Western Slope, JP&Co and Situs identical to today with no list; Situs listed to Zillow Rental Network picks exactly its 122 such cards. Proven live at Willows on Oct 15 (box below); the list holds the company's own AppFolio lead-source labels (normalized, not a fixed key set), the company-page field is handed to Smith on the bridge, and the proof is the real path at Willows in production after merge, then a sandbox company in Situs's shape, then Situs on Saturday.
2. The four follow-up rules go into today's check right after phase 0 at Western Slope (its picture already holds threads, tours and applications), and at Situs once the message sync is on; the wake itself comes later in phase 3. Yes.
3. When the model turn inside a wake fails: skip that touch and alert, never send today's words. Skip and alert.
4. The switch: shadow first, then a per-company "follow-up writer" setting off by default with a one-write kill switch, deleted when proven. Yes.
5. Intake judgment step: not built for hold-or-reply; the model decides only what Clara says when a renter wrote something. Yes.
6. When the picture read fails before any decision: hold and re-alarm up to three times, then rules on the last good picture, replacing today's 8-second fail-open-to-send. Yes. (Two mechanisms, two lines: 3 is the model turn, 6 is the data read.)
7. The source list is the one parameter of the level-1 preset, not a new switch on the dark register. Yes.
8. Rotate the production Temporal API key after tonight's echo into a local log. Yes.
9. Situs message sync before Saturday, so follow-ups can see staff texts. Yes, with Gera.

Phase 0 shipped: per-company list of lead sources Clara answers. Merged (PR #20019) and proven live at Willows on Oct 15: with the list set to Zillow Rental Network only, a Zillow card got Clara's reply and assignment (card 232), a staff-typed TurboTenant card was left alone (card 233), the list was then restored. Evidence: proof comment. Situs can be set on Saturday with one command; new companies start with an empty list (Clara answers nothing until a list is set).

Phase 1 shipping (Oct 16): the glass is filling. Three merged, no switch, live everywhere: the card sync now keeps every dated note and the latest activity as neutral fields on the mirrored card (PR #20255, proven at Willows card 128: three dated notes, newest activity a note on Sep 22; zero extra AppFolio requests); the person picture reads the assignee, source label, last activity and notes through that contract (PR #20288, 30-day replay of pictures with identical first-touch and follow-up decisions); and every follow-up wake now looks at what happened since Clara's last touch, classifies it and logs it, with the send unchanged (PR #20275, the §16.10 minimum slice, log-only). Then two more, also merged and live: the first-touch decision log records the card as staff see it (assignee kind, source label, status, note and activity counts, last-activity age, notes present; PR #20311, 913 real decisions byte-identical; the replay first looked like a gap at Western Slope, 241 of 1,010 people with recent cards reaching the decision step; a read-only check showed the replay counted by last-seen date, which the hourly sync refreshes on every card, so the 1,010 are the whole back catalogue; of the cards that actually arrived in the live window only 4 at Western Slope and 2 at Situs have no inquiry record, nearly all co-signer or not-yet-live cards by design, with one pending Oct 15 Western Slope card still unexplained; the replay now needs the card creation date, not last-seen), and the arrival race is closed: one shared timeline import per new lead, and the decision log waits up to 6 seconds for it before reading the picture, recording done / skipped / failed (PR #20322; at Willows the itemized entries visible at decision time went from 0 to 21 of 36; the import stays behind the existing staff-context setting, on only at Willows). Proven in production at 07:55Z Oct 16: a real new lead at Willows produced one first-touch decision line carrying every new field (import done before the decision, assignee none, source label, card status active, 0 notes, 1 activity "card created" 0 days old, no notes text), decision unchanged (reply, log-only). Evidence comments are on PRs #20288, #20311 and #20322. The wake-look line landed at 13:00Z Oct 16 on the morning's first re-engagement wake, at the Fairhaven sandbox company (first written up as Western Slope; the org id is the sandbox's): since the last touch five days earlier, a second card for the same person and nothing else (no coworker message or action, no renter reply in the PMS or to Clara, no staff activity); the gate decided "send" on the old rules, log-only (evidence on PR #20275). At the 14:00Z follow-up run the worker wrote 19 wake-look lines, 14 at Willows and 5 on real customer leads (17 nothing changed, 1 second card for the same person, 1 renter replied to Clara), all log-only with the gate deciding as before. Phase 1 is fully proven in production.

Two notes for the builders: the source-list setting must show on the company page, which is Gera's settings lane, so a heads-up goes to Smith on the bridge before that PR. And section 9 line 5 is sharpened by 16.4: the Western Slope default is no longer "reply to every staff-typed card" but "reply unless the typist's own history says hold".