PMS conversations in Clara: architecture proposal

Oct 22: the rewrite layers, measured (proposed — pending Fede's go)

Proposed — pending review  2026-10-22. Read-only replay of 78 real first emails (66 Western Slope, 12 Camellia). Same writer draft into every setting; three model judges grade each sent text; the judges passed their planted-defect controls.

Before and after (cards out of 78)

Layer by layer

Recommendation

1. Delete the four dead layers. One at a time each looked free, but with all four off at once on the same 78 cards, 1 real card changes (see below).
2. Move tour times and name-the-home into a full-context retry inside Clara's own turn, so she fixes it with the whole conversation in view.
3. Keep the count check.

All four dead layers off at once (same 78 cards)

1 real card changes: Pomona Park (2f770954). The fact cut removed the email's only tour-times line. Today the after-trace redraft puts the times back; with it off alone, the held-email retry did. Each one-at-a-time run showed 0. With both gone, the email is held and the property team is asked to reply. The other 2 "worse" cards were a judge split (0365fde5) and noise from live tour times (d6e14119).

Shipped as PR #21992 (fix, no switch), armed to merge 2026-10-22.

What could not be measured

• Home facts and tour times are read as of today, not send day (18 of 31 tour-check fires are drift).
• 27 cards had no saved draft and were skipped.
• 11 inquiries were missing.
• Only layers on the main turn were counted; the fact-trace layer (fired 9) was not isolated.

Oct 22: the first-reply prompt, inspected (the writer fix — building on the harness)

Proposed — pending review  2026-10-22. Read-only inspection of the Ember Estates first email. Nothing was re-run or sent.

Follow-up: the whole prompt, on every channel, is inspected and re-architected on Clara prompt architecture (proposed).

What was measured

Three findings

1. The rules contradict each other. 6 length rules, 5 rules on how many homes to name, 3 on tour times. The model's thinking is that argument written out.
2. The tool gate re-fetches facts already in the prompt. It forces three lookups the home-facts block already answered.
3. About 85% is irrelevant to a first reply (maintenance, renewals, walk-ins, existing tenants), much of it written for weaker models.

Biggest sections

Tonight's objective and bar

One coherent first-reply prompt. The writer's own draft is what is sent, with no rewrite layers, replayed on the same 78 cards. Bar: 6 or fewer held, 0 over-share, 98% or more with a tour offered.

Oct 19: ready to decide — Clara replying through AppFolio at Western Slope

Proposed — pending review  2026-10-19, morning. Built dark overnight; nothing changed for any real customer.

What shipped tonight

Proof at the Willows (production, the door is on there)

Before → after, per lane (a person at Western Slope)

The resolver: which number a text leaves from

What else changed tonight:

• A prospect's reply inside AppFolio now wakes Clara, when her text is the newest one from the office.
• A teammate's AppFolio text puts her on hold for that person.
• STOP on the AppFolio line opts the person out on both numbers.
• Held texts expire instead of going out stale.
• A double text gets one reply.
• The renewal letter arrives from one number.

Replay on Western Slope's real people (read-only, nothing sent)

Same 41 people Clara texted since Oct 2. "Right number" means the number the person last wrote to.

The Oct 16 "35/41" counted who AppFolio could reach, not the right number: 32 of those 35 would have switched number mid-conversation.

Side effects and things to watch

• Number switch mid-conversation: prevented by the thread rule.
• Two numbers per person across lanes: one person can get leasing texts from AppFolio's number and maintenance texts from Clara's line.
• AppFolio request budget: see the table below. The inbox copy already uses most of a day's budget; each door send adds about 20 requests.
• Tenants answering a door text: the wake covers prospects and applicants only, so a tenant's reply in AppFolio does not wake Clara; many tenant rows still wait for tenant support in the inbox copy.
• No AppFolio record: the text is held, with one alert. Nothing goes out.
• AppFolio user "Clara Propflow" (540): has sent 8 texts at Western Slope (7 history, 1 live on Oct 18) with the door off. Verified: every one is AppFolio's own "Rental Application for <address>" template, the text copy AppFolio sends beside its rental-application email when Clara presses that button under this login. Not a Clara-written text, and not the door.
• Prospect texts AppFolio's number first: no Clara text on the thread, so Clara does not wake. At Western Slope the leasing line forwards to Clara's line, so first contact normally arrives there.
• After a STOP the follow-up sequence is refused at the send gate, not stopped.
• Tour confirmations still go out during a teammate hold, same as Clara's line today.

Prerequisites per customer

Decisions for Fede

Follow-ups filed: #21068 #21069 #20987 #20988 #20989 #20990 #20991 #20999 #21010

Open housekeeping: the shared main code checkout is stuck mid-rebase on another session's local commits; every builder tonight worked around it. Its owner needs to resolve it.

Oct 21: audit and re-inspection before the text door goes on at Western Slope

Overnight, Oct 20 → 21. Fede: "no turning on today, let's get it ready overnight, go deep and audit everything." Read-only audits on real Western Slope data plus three fix PRs for his rulings from the evening. Nothing is on. Proposed — pending review

Decisions for Fede

Findings, ranked

Corrected premises: a lead who texts the office number first does wake Clara (fix deployed); every first text already says "it's Clara with Western Slope". What gets better: one voice in the office inbox, staff see Clara's texts, replies to the office number reach Clara.

Proven live vs unit-covered only

Willows run, Oct 21 05:25–05:39Z (deployed build 6e1e4a9b)

Four texts from bench numbers to the Willows AppFolio line +15046087154. No settings changed. Zero texts left Clara's own Willows line (+18442853526) during the run. JP&Co request budget went 2,326 → 2,383 (+57).

Found during the run (not door bugs, filed separately): (1) in the prospect turn, the lead-status step moved card 197 to "not interested" citing an old STOP and ignoring the later START, and marked the guest card inactive in AppFolio 18 s later (card 197 is now Inactive, "No Response"; Clara kept answering the thread). Root cause: the after-turn classifier prompt lists a STOP as "withdrew" and never checks the live opt-out status, so a START that undid the STOP is ignored. Affects every prospect on Clara's line as well, not door-specific; one-line prompt fix plus a test from this thread. Issue #21577. Bench debt: card 197 and inquiry 2398fd62… stay "not interested" until the fix lands and they are reset. (2) The tenant's text filed onto an old May maintenance voice thread rather than the renewal thread; consistent with that tenant having said they are moving out, no action. (3) The brief's log name messaging/appfolio-inbox-text is stale: prospect wakes log as inbound-router reply_on_clara_thread plus a dispatch-log line; the tenant line logs pms=<id> without the sms: prefix.

Audit 1: what staff stepping in should do to Clara (real Western Slope threads)

The 33 people, Oct 16 to Oct 20

Kat sent 11 of the 19 prospect texts and the shared office login sent 8. The Oct 20 group of 8 who last wrote to staff: none wrote again, and Clara sent nothing. 9.6 for scale: the office answers a weekday text in a median 8 min, and an evening text in 13.8 h. Most residents ended on a thank-you; 2 real asks are still open. Both worked-twice leads (…4860, …4236) are in the 19: staff sent a cold check-in after Clara had already settled the question, and neither answered. That is a visibility problem (staff can't see Clara's thread), not a hand-back problem. Residents are outside the leasing-only door (#21563), so the hold question is really about the 19 prospects.

The one case that matters (…6055)

Oct 18: Clara books a tour. Oct 19: Kat sends an intro in AppFolio ("message me to set up a time"). Our inbox copy filed it into the same conversation. Oct 20: the lead texts Clara's line twice to move the tour, and Clara handles it in a minute. If the text door had been on, the hold would have refused those replies. The lead would still have got a reminder for the time they had asked to change. This is inferred from the hold code; it did not happen, because the door is off. Right now 1 of 287 Western Slope conversations is held, and it is an email thread.

Decision for Fede

Sources: propflow-prod, read-only, Oct 21 ~03:50Z. Inbox copy PMSMIRROR#appfolio#westernslopepm MSG# (980 rows; staff = senderKind staff, since Oct 16 00:00Z, 33 phones). AppFolio guest-card emails are excluded (Kat emailed about 20 cards). Conversations via conversation-list-index since Oct 2 (287), matched by phone and person. Clara's line = her own sms and email turns, not team notices. Code: origin/main df30ee1a50 wake-on-reply.ts, auto-reply-hold.ts.

Audit 2: every way the door makes someone worse off than today

Audit 4: who is worse off with the door on than today?

Read-only, Oct 21 ~04:00Z Today the door is off: Clara texts from her own line and the inbox copy only reads. The test is Fede's bar, "hard to make it worse than right now". Counts come from Western Slope production since Oct 2, read only (287 conversations, 5,768 messages, 980 inbox-copy rows), plus code at origin/main df30ee1a50. The deployed build includes the call-card fix and the wake-on-first-text fix.

What gets better

• One voice per lead. Staff see Clara's texts before they type: 6 of 80 leads were restarted cold by staff who couldn't see her thread.
• Replies to the office number reach Clara: 61 live inbound texts in 5 days. On weekday evenings the office's median answer time is 13.8 h; Clara answers in seconds to minutes.
• Leads see one number: the office's, the same one shown on AppFolio and the listings.
• A STOP on either number is honored on both.
• Clara's AppFolio login (user 540) is already labeled as Clara on 10 copied rows. That is evidence for readiness row 18.

Audit 3: every code path through the door, after the fixes

Audit 4: flip, rollback, and what to watch on day one

Operating and rolling back the AppFolio text door at Western Slope

Checked against the code on main (website build df30ee1a) and against production data. Today the door is off at Western Slope (no value stored). Leasing runs live, not Supervised. Maintenance runs in drafts. A teammate hold under the door therefore shows in no Slack channel.

1. Flip and rollback

aws dynamodb update-item --region us-east-1 --table-name propflow-prod \
 --key '{"PK":{"S":"ORG#org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38"},"SK":{"S":"PROFILE"}}' \
 --update-expression 'SET pmsTextDoor=:d, pmsTextDoorChangedAt=:n, pmsTextDoorChangedBy=:a' \
 --condition-expression 'attribute_exists(PK)' \
 --expression-attribute-values '{":d":{"S":"clara_line"},":n":{"S":"'$(date -u +%FT%T.000Z)'"},":a":{"S":"<your user id>"}}'

2. Who a rollback touches

Print the list before you flip back. The query applies the sender's own rule: the newest text in a thread decides which number Clara uses. Script: scratchpad/a5/door-threads.py, run with python3 -I. It is read-only.

# held texts that would trip a false alert on a later re-flip
aws dynamodb query --region us-east-1 --table-name propflow-prod \
 --key-condition-expression 'PK=:p AND begins_with(SK,:r)' --filter-expression '#s=:h' \
 --expression-attribute-names '{"#s":"state"}' \
 --expression-attribute-values '{":p":{"S":"PMSTEXTOUTBOX#org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38"},":r":{"S":"REC#"},":h":{"S":"held"}}'

3. Day-one watch

aws logs filter-log-events --region us-east-1 --log-group-name /aws/lambda/propflow-appfolio-sync-prod \
 --start-time $(($(date +%s)-86400))000 --filter-pattern '"decision="' --query 'events[].message' --output text \
 | grep -o 'org=org_c42d9150[^ ]* pms=[^ ]* decision=[a-z_]*' | awk '{print $3}' | sort | uniq -c
aws dynamodb query --region us-east-1 --table-name propflow-prod --key-condition-expression 'PK=:p' \
 --expression-attribute-values '{":p":{"S":"PMSTEXTOUTBOX#org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38"}}' \
 --query 'Items[].[SK.S,state.S,reason.S]' --output text
aws dynamodb query --region us-east-1 --table-name propflow-prod --select COUNT \
 --key-condition-expression 'PK=:p AND begins_with(SK,:h)' \
 --expression-attribute-values '{":p":{"S":"PMSMIRROR#appfolio#westernslopepm"},":h":{"S":"HOLD#"}}'
aws dynamodb get-item --region us-east-1 --table-name propflow-prod \
 --key '{"PK":{"S":"PMSMIRROR#appfolio#westernslopepm"},"SK":{"S":"STATE"}}' \
 --query 'Item.watch.M.[day.S,dayRequests.N,reserveHeldDay.S,lastTickAt.S]'   # plus the peek fields once that branch lands
KEY_SID=$(security find-generic-password -a twilio-api-key-sid -w); KEY_SECRET=$(security find-generic-password -a twilio-api-key-secret -w)
curl -s -u "$KEY_SID:$KEY_SECRET" "https://api.twilio.com/2010-04-01/Accounts/ACff85d85c80b83355a53032a5f31d7bed/Messages.json?From=%2B19708220641&DateSent%3E=<flip date>&PageSize=1000" \
 | jq -r '.messages[] | [.date_sent,.to,.status] | @tsv'   # keep rows after the flip instant; match To against prospects

4. Pages on day one: noise or real

A real incident is a person waiting, which shows as a held reply or a text leaking onto Clara's line. A wrong no-wake decision is silent by design, so read the wake counts every few hours on day one.

Evening and overnight delay (Fede, Oct 21 morning: "too slow for leads")

Status 16:44Z: step 1 (#21590, door send starts fast mode, reserve peek honored) live 16:1xZ; step 2 (#21592, charge the robot's real session-check count) live 16:44Z; step 3 (#21594, evening slots) armed. Proof: the first evening conversation after 7 PM MT, appended here.

Read-only inspection Oct 21 ~14:30Z. Numbers from the schedule code, the sync log and the Western Slope state row; "inferred" where marked.

Why it is slow. Two causes. The inbox copy spends its 4,000-request day (our own cap after the Situs 429 storm) by about 6:30 PM and drops to one read every 15 minutes. And after midnight the schedule itself reads only every 30 minutes, worse than the 15 minutes reported earlier. A third cause makes every evening conversation cold: Clara's own door send does not start the fast 60-second mode; only a newly found inbound text does.

Where the budget goes (average Oct 16–20, 3,502 a day): inbox reads 65% (762 reads × 3 requests: one for the page, two session checks the robot makes on every call), guest-card email re-reads 31% (every 2 h), thread reads 3%, door sends 0 so far. Who it touches: about 1–2 leads a day write after 6:30 PM (inferred from 129 texts to Clara's line since Oct 2: 40 after 5 PM, 9 between 7 and 9 PM, none after 9 PM); overnight is rare.

Fix, no cap raise, no switch (building now, Oct 21):

1. Robot: one session check per call, none within a minute of a success. Cuts ~1,300 requests a day. Robot PR appfolio-browser-agent#586 (armed). Our counter charged a fixed 2 per call for those checks; a PropFlow PR makes it charge the real number the robot now reports (building).
2. Inbox copy: a Clara door send starts fast mode; the reserve peek honors fast mode (60 s while a conversation is live, still never below the floor); email re-reads every 6 h instead of 2 h (saves ~700). PR #21590 (armed; four planted defects red, 531 inbox-copy tests green).
3. Schedule: read every 60 s from 6 AM to midnight and every 2 min overnight. Lands only after step 1 is live, or the copy would hit the reserve every evening. Expected total ≈2,830 a day, under the 3,397 reserve line (inferred). Result: evening ~2 min, overnight worst ~3.5 min.

Rejected: a cheaper "anything new?" signal (the list read is already the cheapest check; AppFolio's "you received a message" emails reach no mailbox we read); raising the cap (would need ~5,400 a day; AppFolio's real limit is unknown, Fede's call, not needed); longer fast mode after a send (does not help a cold evening reply).

Oct 20: is the text door ready at Western Slope? (read-only, pending review)

A. Is the text door ready at Western Slope? (read Oct 20, 21:10Z)

The path Western Slope hits most has now worked end to end once. A new lead arrives, Clara's first text opens the AppFolio thread from the lead's guest card, the lead replies, and Clara answers in the same thread. That ran at the Willows on Oct 20 at 16:58Z on a fresh test number (Fede approved buying it at 02:50Z). It cost about 27 AppFolio requests, the reply round trip took 99 s, and nothing went out on Clara's own line. Since Oct 19, five things have changed:

• Requests are now set aside for sends.
• Some senders now name the thread they belong to: teammate answers relayed to the renter, and texts to household members.
• Every tenant or prospect reply in AppFolio now wakes Clara.
• A tour reminder has gone out through AppFolio.
• Callers now get a guest card after the call.

Settings, read now: the door is unset at every company except the Willows test company, so every other company texts from Clara's line.

1. Would people get the right number?

"Right number" means the number the person last wrote to. We replayed the door's rules from the current code over everyone Clara texted, with the door turned on. Nothing was sent.

There are 13 misses since Oct 2, in three groups:

• 8 people last wrote to staff in AppFolio, either before the inbox copy started or on another conversation. Clara keeps her own line for them, as decided.
• 2 tenants whose AppFolio texts are still parked in the inbox copy.
• 3 prospects (…4860, …4203, …2516) whose newest text is Kat's in AppFolio. They move to AppFolio by design.

Most people already talking to Clara keep her number. The flip mainly changes brand-new leads. If the 35 people from the last 14 days were all brand-new:

• 31 could be reached in AppFolio: 23 already have a thread there and 8 would get a new thread from their guest card.
• 4 would get no text at all. All 4 are phone callers with no AppFolio card, and their calls came before the "card after every call" fix.

2. What is held at Western Slope right now

3. Teammate hold: what happens when Kat texts in AppFolio

• Follow-ups: they are refused one by one at send time. That covers texts on Clara's own line on that conversation too.
• How long: forever. Nothing releases it, and a prospect's reply doesn't either.
• Tours: confirmations and reminders still go out.
• What staff see: nothing in PropFlow or AppFolio, apart from a Slack line in Supervised mode.
• Prospect replies to Kat: Clara stays asleep.
• Today, with the door off: the hold does nothing. Since Oct 16, staff texted 33 people in AppFolio, and 12 of them are people Clara texted in the last 14 days.

4. AppFolio request budget

Today's count is 2,701 of 4,000 at 15:08 Denver. The inbox copy now stops at 3,400 so sends always keep 600. It hit that limit on the night of Oct 19. When that happens, replies in AppFolio wait until after midnight Denver.

A send costs about 7 requests into an existing thread and about 20 to start a new one. Clara sent 134 texts to renters and prospects in the last 14 days: a median of 7 a day, peak 23. Even if all 23 opened new threads, 23 × 20 = 460 requests, under the 600 reserve (arithmetic).

5. Situs and the setting

Situs: no Clara seat on the company connection or on any of 53 property rows, no inbox copy, no budget row. AppFolio there has two Clara users, 1254 and 1259, per session 000. Western Slope's seat is user 540. The inbox copy already labels that user's texts as Clara's: 2 live rows since Oct 16.

Gap list

Sources: propflow-prod read-only, Oct 20 ~21:10Z. ORG#<id>/PROFILE (7 orgs via entityType-createdAt-index GSI3PK=Organization); ORG#…/ATTACH#pms_credential; PROP META via proporg-index; PMSMIRROR#appfolio#westernslopepm STATE (dayRequests, reserveHeldDay) and MSG# (976 rows); PMSTEXTOUTBOX#<org>; CONV# via conversation-list-index since Oct 2 plus PERSON#…/INQUIRY#. Replay: session 002's fetch.py and replay.ts, re-pointed at origin/main 46638b5bc7 (resolvePmsTextAddress, pickPmsTextStart, pmsTextStartRecordsOf, threadTextDoorOf), scratchpad q/. Tenant-record starts are not modelled. One cohort entry with an email address in its phone field is excluded from the counts. Willows L3 run: session 002 runs-oct19-night.md and readiness row 6. Code: wake-on-reply.ts:51-77, file-message.ts:430-443, dispatch-envelope.ts:462-469, auto-reply-hold.ts:66-89, pms-mirror-store.ts:213, watch.ts:153-154, appfolio-text-start.ts:68-77.

Oct 20: what lands on the AppFolio guest card, per customer, and one notes policy (decided Oct 21)

BEFORE
Email · to 1…@convo.zillow.com
Subject: Re: Tanya is requesting information…
Hi Tanya, You're all set — tour confirmed for Friday, October 23 at
10:30 AM at 2841 Morningside Court…

Tour booked for Fri, Oct 23 at 10:30 AM, in person.

Email · to 1…@convo.zillow.com
Subject: Interested in 2841 Morningside Court
Hi Tanya, The home at 2841 Morningside Court is open now — a 4-bedroom.
I've got Friday morning open between 10:30 AM and 12:00 PM, or Saturday
between 10:00 AM and 2:30 PM…

Email
Subject: Tanya is requesting information…
I would like to schedule a tour. Possibly Friday morning or Saturday?

(missing: Clara asking for her number; her "Friday at 10:30 works",
her number, her "see you then")

AFTER
Booked Fri 10/23 10:30 AM, in person. Confirmed by email.

Wants to tour Fri morning or Sat. Emailed open times (Fri 10:30–12,
Sat 10–2:30); she picked Fri 10:30 and sent her number when asked.

BEFORE
Toured.
Text · to …4421 / Hi Maria, just a reminder your tour is in one hour…
Text · to …4421 / Hi Maria, a reminder about your tour tomorrow at…
Tour booked for Sat, Nov 7 at 11:00 AM, in person.
Call · with …4421 / Caller asked about 2-bedroom availability at…
(a paragraph summary of the call)

AFTER
Toured. Asked to apply; sent the application link.

Called in, wants a 2 bed by 12/1, has one dog. Told her dogs are OK
with a pet deposit; booked Sat 11/7 11 AM.

BEFORE
No reply after 2 weeks. Archived.
Email · to … / Subject: Re: … / Hi Jordan, just checking in one last time…
Email · to … / Subject: Re: … / Hi Jordan, still interested in…
Email · to … / Subject: Re: … / Hi Jordan, wanted to follow up…
Email · to … / Subject: Re: … / Hi Jordan, Thanks for reaching out…
Email / Subject: New Zumper lead… / Do you allow cats? Moving Dec 1.

AFTER
Followed up 3 times by email over 2 weeks, no reply. Archived.

Asked about cats and a Dec 1 move. Emailed: cats OK, open Dec 1,
offered Thu or Sat tours.

What staff see on the card today

Fede's belief holds, and it is worse than he thought outside Western Slope. At Western Slope, Clara's first email lands on the card as an "Email Sent" entry, and then the card goes quiet. Nudges and replies never show up, so staff reasonably conclude Clara never followed up. At Camellia, nothing Clara has done since April is on any card. At Situs, Clara has not contacted a single lead yet, so there is nothing to note.

Three causes, all in the code:

• Follow-up nudges have no note step at all.
• Replies: email replies never get a note. Text replies get one only if the building has a texting switch turned on, and it is off at every customer.
• Other notes are uneven: some outcomes write a note, some write nothing, and tours become AppFolio Showings only where a company setting is on (on at Western Slope only).

"Landed" means our robot confirmed the write. Check against AppFolio's own Oct 9 export for Western Slope: 14 application notes on both sides, and 47 "Email Sent" entries vs our 48. Camellia: 0 of the 83 Camellia guest cards created since April carry any note, and the card-write path only existed from Sept 18. Since then, Camellia saw 36 leads contacted, 76 nudges, 17 tours and 61 calls, with zero writes until a first card was created today. Counts include any bench tests on customer lines; none were flagged.

AppFolio's texting line vs Clara's line

AppFolio logs texts sent through its own texting line on the card by itself: Western Slope and Situs cards show "Text Sent" activity with no Clara involvement. Texts from Clara's own number are invisible to AppFolio. Today the code has no rule to skip our text note when the text went through AppFolio's line. At the Willows, where that line is on, 39 text notes were written Oct 16–20, so those texts probably appear twice (inference; not checked message by message). The fix: one rule, keyed on the line. On Clara's line we write the message note. On AppFolio's line we don't, because AppFolio already does. Outcome notes are written on both.

Before → after for a typical Western Slope lead

Decision for Fede

On Sept 22 Fede said "we don't need to write every turn, that's too much noise". That ruling is what produced today's one entry and then silence. Picking (a) or (b) reverses it.

Sources: production write-intent outbox (all 1,649 rows), conversation message rows, tour rows and prospect inquiries per company; AppFolio guest-card export of Oct 9 (guest-card corpus); code at origin/main 46638b5bc7 (guest-card outbox, note intents, text-note filing, prospect outreach, showing sync).

Overnight build, Oct 12 to 13: what shipped and what Fede decides this morning

Merged and open tonight

Willows performance report (the real AppFolio inbox, 0 new rows tonight)

No lag numbers (AppFolio time to PropFlow write): that needs a text into the Willows inbox, shared with JP&Co staff, so we sent none unasked. You text the Willows line, or our Twilio test number does on your yes.

Live in production since 12:18Z Oct 13 (6:18 am Denver). The every-minute watch now runs from our sync job for the Willows test company. First three production ticks: 3 requests each, 2.0 to 2.6 s per tick, 0 new rows, 0 duplicates, 0 held, no errors, no paused database. Ticks came 5 minutes apart because the morning band (6 to 8 am) is 5 minutes by design; they go to 1 minute at 8 am. No text has reached the Willows inbox yet, so there is still no lag number: that needs one text into the Willows line.

Western Slope coworker bank

Both fixes you asked about are proven: staff never go to tenant repair intake (call 3, Q1 to Q4); vacancy counts by unit status (call 4, Q1). Stale tenant on a vacant unit: #19273. ElevenLabs was degraded 08:55 to 09:35 UTC, and three calls from 09:47 to 10:13 UTC had no audio. Not ours. Sentry shows no new production errors then, which is not proof calls succeeded.

Decisions I took on your standing rules

• #19212, option A: an unknown number gets a phone-only person, as on Clara's line today.
• #19215, option B(i): one writer per door. The old importer stops filing texts on a mirrored company (#19246).

Yes / hold this morning

TL;DR: one real ask, the Western Slope turn-on.

1. Western Slope turn-on: yes once the clock and report merge and a Willows text gives a lag number, and after we confirm at Willows, with the first real text, that reading a changed thread does not clear its unread mark in AppFolio (unverified today, tracked as #19292). The change: today a prospect's AppFolio text wakes Clara and she can text back; mirrored, she reads and never replies until the engage decision.
2. Known number, unknown name (#19240): accept for slice 1. Same as Clara's line today.
3. Situs has no front-door row: slice 1 is Western Slope only. Unmatched Situs texts would sit pending.
4. 64 Western Slope tenants with no person record land on the front door: accept, issue to have the sync create them.
5. Lag numbers: you text the Willows line, or yes/hold on our Twilio test number.
6. JP&Co robot-user 403: grant the robot user read access rather than roll back; the mirror and guest-card reads need it. Your call.
7. #19256: hold, not slice 1. No move-out walk path on the Coworker Line.
8. #19260: rename 9 Fairhaven test buildings named like real customers.
9. #19247: block the old backfill script on mirrored companies before any turn-on.
10. Schedule per database, not per company: accept as designed.
11. #19151: another lane, no action here.

Dark: pms_inbox_mirror | feature: copy every AppFolio inbox text into the matching PropFlow conversation, labeled, Clara reads never replies | proof: pending (Willows watch ran, 0 rows) | turn-on: Fede

Still open

• #19228: a text can be sent twice. Open, not touched tonight.
• Shared-login texts not labelled with a person (#19234).
• Bulk sends from Clara's own seat are labeled once with a count; not exercised tonight.
• Harness gaps #19235 and #19241 are closed; left: identity fallbacks and two rendering hooks.
• Decision 7, the one-year read, runs attended.
• #19292: whether the thread read clears AppFolio's unread mark
• #19294: a send import at the top of the shared sync Lambda handler is not caught by any pin (the job and its branch are pinned)

1. The gap, measured

2. The shape: a generic core, adapters at the edge

Three places the core could live. Recommendation first.

The adapter contract (what each PMS module must provide): how to get a session (login, MFA, cookie jar), the list endpoint and its row shape, the thread endpoint and its row shape, the id spaces (party id, message id, property id), the write endpoint for phase 3, and the traps (which calls mark a thread read, rate limits). Everything else, watching, cursors, budgets, dedupe, identity, writing into conversations, is core and never knows which PMS it serves.

2b. One front door for every message

Fede: "one gate where all messages come in, and it doesn't matter if it's Yardi or AppFolio or email or a Twilio text or a phone call: the same core engine, otherwise it will be really hard to maintain." Today the inbound loop is wired per source: the Twilio webhook, the mailbox ingest, the call transcript and the guest-card feed each do their own identity, write and engine wake-up. pending the communication-layers map, which lists how coupled each path is.

Minimum slice: a typed event and one handler, used by the AppFolio watch from day one. The Twilio and email paths move behind the same door one PR at a time, each a fix with no switch, proven byte-identical on replay. That is how the "different implementations" get retired instead of multiplied.

2c. Integrations: one connector shape, three protocols

The connector shape is the same in all three: get a session, list, fetch one, write one, emit front-door events. The browser agent is "just another API", wrapped. Nothing above the connector knows which protocol it spoke. This is the concept only; no other app is in scope now.

3. Read: watch a list, on the session the robot already keeps warm

Fede's question: new browser every poll, or one always on? Neither. The robot already keeps every customer's AppFolio login warm with one plain web request every two minutes (its heartbeat), and starts a browser only to log in or renew, about once a day. A poll is one more plain request on that warm session. So the cost that matters is requests toward the PMS, not browser minutes. All AppFolio traffic stays inside the robot: one cookie jar, one pacer, one lock per customer. The sync runner asks the robot; it never replays cookies itself (a second client on the same session is how bursts and 429s start).

Verified at Willows on Oct 12, with no login and no browser. The company-wide inbox list is one JSON request (AppFolio's own conversations endpoint), newest first, 20 rows a page, not limited to the signed-in user (inbox-capture/request-log.md; shape.md). Each row carries the party (AppFolio id, name, a status such as "tenant (past)" or "applicant", the matched phone), the property and unit with their AppFolio ids, the latest message (id, body, direction, delivery status, the staff sender's name when staff sent last), the unread flag, the assigned user, and a candidate texting-line id (unverified: that field has 292 distinct values across 433 rows; the thread id field is empty on all 433). The row's id is the latest message id, so it moves on every send or receive: that is the change signal, and it is also why that id is not a thread key (the thread key is the outside number plus the texting line). Listing marks nothing read (two unread rows stayed unread across three polls) and a quiet poll returns byte-identical pages (inbox-capture/request-log.md; shape.md). The robot already exposes this read through a texting-inbox route: two session probes plus one list request per call, and it refuses to log in when the session is cold.

Still assumed. Our request is text-only by its own parameters. The inbox itself is not text-only (next paragraph). Also open: the page-size ceiling, the unread and read filters, the texting-line id (unverified: the candidate field has 292 distinct values across 433 rows; the thread id field is empty on all 433), and whether the list request can replace the heartbeat's own keepalive (if it can, the heartbeat and the poll are one request, and the robot raises the event: decision 1). One small robot change closes the first three: a query passthrough and a values-only shape mode, about 150 lines. The fourth is a canary.

Email is not read today. AppFolio's inbox shows email cards inline with texts in one timeline (Fede's screenshot, Oct 15, relayed by the renewals session; not reproduced here). Our read asks only for texts, sms[include]=true&chat[include]=false, with no email parameter (inbox-capture/request-log.md). Its 433 captured list rows are all type "sms" (ws-shadow/raw, ws-renewals-2026-10-15/raw). So the mirror sees no email today. Probed Oct 15 on the deployed robot (5 requests, Western Slope): the list endpoint ignores email[include] (texts+email byte-identical to texts-only; email-only returns 0 rows; chat include works). Emails are reachable only through AppFolio's per-person communication history, which the robot reads today for guest cards only (inbox-email-probe-2026-10-15/).

Request math at Western Slope, on the schedule. Page one is enough for a quiet tick, because new activity moves a thread to the top. On the measured curve (figure 8) the schedule is one minute from 8 am to 7 pm, five minutes from 6 to 8 am and 7 to 10 pm, fifteen minutes from 10 pm to midnight and thirty from midnight to 6 am (Fede, 10-12 night: fifteen is too often while people sleep): about 740 ticks a day instead of 1,440. At three requests a tick (the list plus the robot's two session probes) that is about 2,300 requests a day, or about 800 if the list read rides the keepalive (the phase 0 canary), plus one thread read per changed thread (about 10 a day). Against about 130,000 a day for the per-building design. A bulk blast moves many threads to the top in the same minute: that tick walks the list down to the high-water mark, one page per 20 threads, and writes the bulk rows from the list rows alone, one row with a count.

Why the tick slows down at night, with the data. Fede, 10-12 afternoon: "every 15 minutes at night seems a bit slow… what if there's an emergency?"; 8 pm: "I do think it makes sense to be less frequent; this is why we need a distribution, and a dynamic polling mechanism… I need data." The data is in (9.6, figure 8): of 3,983 inbound texts in a year on Western Slope's AppFolio line, 3.0% arrived between 8 pm and 8 am and 0.9% between 10 pm and 7 am, about one every ten nights; there is no after-work bump on this door (5 pm 3.2%, 7 pm 1.3%, 9 pm 0.4%) and only a small pre-work ramp (6 and 7 am, 1.5% together). So the schedule in decision 12 polls every minute while the office line is busy, every five minutes in the evening and early morning, every fifteen while people sleep, and drops back to one minute for 30 minutes after any change, which covers a conversation in progress. The worst case for a 2 am text is a 30-minute wait; the office today answers a weekday-evening text in a median 13.8 hours, and emergencies stay on the phone line and the call center. Limits: the year of texts is prospects only (tenants beyond a 5-household canary are not in it), and 90% of those texts answer something the office texted out the same day, so the evening is quiet partly because nothing goes out in the evening; Clara's own line, which answers at every hour, takes a third of its texts between 5 and 9 pm (3.5 weeks, our own tests not separated). The curve is per door and per customer, recomputed monthly, and it will move once Clara texts people in the evening.

Does reading mark a thread read, for everyone? Fede 10-12. Two different things: the thread page (the screen a person opens) fires AppFolio's mark-as-read (unverified: from a code comment, never captured); the list and thread JSON endpoints the watch uses do not (verified at Willows: unread rows stayed unread across three polls; the robot's code carries the never-load-the-page rule). So the watch never changes what the office sees as unread. Whether that flag is one per company or one per login is not in AppFolio's documentation; the probe hints it is shared (threads nobody on our side ever opened showed as read, while 27 of them still waited for an answer). Phase 0 settles it at Willows in one test: send a text to the Willows line, read it through the watch, and look at the inbox from a second login.

4. Mirror: copy it, land it on the right person

Each PMS message becomes one PropFlow message, keyed by the PMS message id so a re-read never duplicates. It carries: channel (text or email), direction, when it happened, the body, the door it came through (which PMS texting line), and who sent it: a named staff user (Kat, Jay), a shared login shown by its login name ("Assistant PM", "Clara PropflowAI": humans have used both, so never guess person or robot from it), or a bulk send (one renewal reminder to 200 tenants, labeled bulk).

What the Western Slope read says (read-only, 2026-10-12).

• Owners and vendors. Their messages are counted and kept pending until those modules exist; never dropped.
• Backfill is onboarding. The same reader walks the list backwards, one to two years deep, paced, resumable, and writes rows with their real timestamps plus a backfill mark. Backfilled rows are context, never events: they do not wake a follow-up, set "engaged", or fire an alert (section 6).
• Keep current. A cursor per customer per channel (the highest message id seen) plus the list fingerprint. Losing the cursor costs a re-read, not duplicates.

5. One thread, many doors: the split number

A tenant has Clara's number and the company's AppFolio number in their phone. Both must work forever, and nobody is told to switch. The model: the person is the key; a number is just a door. In Gera's portfolio model a line attaches to the customer or to a property; the PMS texting number becomes one more line at the customer level, provider "appfolio", and the PMS mailbox likewise. Every message records its door. pending: whether the line type admits a non-Twilio provider today (identity report); if not, that is the one schema change.

6. Clara's context: is it automatically in the loop?

Short answer: yes, through two doors that are already live, and that cuts both ways. Clara's reply turn loads the whole conversation, keeps staff rows, wraps each one as a teammate note ("teammate turn, not yours", naming who wrote it in AppFolio) and trims to an 80,000-token window. The follow-up engine reads every conversation the person has and already stands down when a teammate answered and the renter has not replied since. So a mirrored staff text is in her head the moment it lands. That is Fede's double-text fix ("Jay sends an AppFolio message, and then Clara sends out different things"), and it is a behavior change on day one, to be named and proven with a before and after replay.

Phase 1 is not a passive copy. Two things are wired today and both would fire on tenant threads: a live inbound text wakes Clara through the normal inbound path (the wake is gated on the per-property sync switch alone, not on PMS delivery), and a staff text stamps a permanent send block on the person's thread (only where the property's delivery is set to the PMS and a Clara seat exists). At Western Slope today that means: flip the existing switch and a tenant's text to the office gets no hold, a full Clara turn, and a reply from Clara's Twilio number. That is the second-number failure Fede named. And even with the wake and the hold removed, stored rows alone change decisions, because most readers look at the row's role (staff rows carry the assistant role) and never at who wrote it.

• Rendering. "Jay · AppFolio text, Oct 9 4:12 PM: …" in the thread view and in the prompt (today the staff kind renders "From mailbox"). Bulk sends render once with a count, not 200 times. A photo renders as a photo, or at least as "[photo]" with the file fetched inside the budget (Fede 10-12: a lot of these conversations carry one). The audit landed: photos from Clara's number already render inline on the thread view; the gap is getting them out of AppFolio (traps 56 and 66). The localhost mock exists (local branch proto/pms-mirror-rendering, never a PR; the real conversation page at localhost:3099/conversations/conv_proto_maria_242 on the Mac, screenshots in the scratchpad): every row shows "Jay · AppFolio text, Oct 9 4:12 PM", the shared login shows as "Assistant PM (shared login)", an automatic notice as "AppFolio notice", the bulk send once with "sent to 200 residents", a photo as a thumbnail or "[photo]" when the file is gone; the real prompt builder prints the same lines. Two findings for slice 1: with a header on every row the thread no longer folds a burst of messages into one bubble; and in the prompt the bulk and notice rows sit inside Clara's own turn unframed, so the shipped version must frame them as not hers. Not built in the mock: bulk detection, the photo fetch, the email preview card's header.
• Window. Clara's prompt gets mirrored messages from the last 90 days plus the last 20 regardless of age, plus a one-paragraph summary of older history; a two-year backfill never enters a prompt whole. Everything stays visible on the page.
• Wrapper wording. The teammate wrapper is written for leasing (tour rules). A maintenance or renewal text from Kat needs a neutral note: who, when, via AppFolio, what was said.
• Backfill is inert, by rule and by reader. Rows older than the turn-on cursor carry a history mark: they never move recency, never hold, never wake, never alert, never count as touches. Readers with no time window still see them unless told: the follow-up gate's "engaged", first touch, the prompt readers, promise extraction, the life-safety scan on escalated threads, and savings. Those readers honor the mark in the same prerequisite fix, and so does the work-order creator, which today attaches every tenant photo in the conversation to a new work order: it takes only photos after the turn-on cursor or from the current issue, and never one whose source is AppFolio. A thread minted for a backfilled row takes its start and last-message time from the rows, never from the import moment.
• Promises staff made ("I'll send the lease tomorrow") are context Clara must not contradict; they are never tracked as Clara's promises (Fede 10-08: promise tracking only through Clara).
• The company brain stays separate. The mirror feeds the person's conversation, never the brain (which has no reader yet); what the office teaches Clara is a different path (vision page, section 5).

7. When Clara chimes in

Rewritten tonight. Fede, 10-12: "I don't like this, it's too complicated." There is one mode for every customer (Fede 10-08), so no customer picks a level. The PMS door has two states, and the second is the same for everyone once it exists.

What "routine" is comes from the data, not from a policy table. Fede: "in the last year of data, both Situs Group and Western Slope, it's like sixty percent was routine, and of that so much was maintenance or payment questions, and then like twenty percent was human escalation; add real-life distributions." Figure 7 (below the engage decision) shows it, measured tonight on 1,083 real messages across six doors with one rubric and a 92% hand-check: on Western Slope's AppFolio text door 90% of what people send is routine, meaning Clara can close it herself: 69% is a question she can answer from facts on file (hours, a work-order date, an application status) and 21% is a thanks or an ok that needs no reply; 10% needs a person in the office; 0.3% is an emergency; on Clara's own line 74% routine, 24% human, 1.6% emergency; Situs's inbox 65 / 33 / 1.3. Fede's gut fits Clara's line and the Situs inbox; the AppFolio text door is more routine than that because most writers are applicants replying to a staff question (78% of its texts). Maintenance and payments are not most of the routine pile at any door (4 to 13% of all messages; 44% of what tenants send on the text door); leasing is. If Clara answered the routine share through the PMS door at Western Slope, she would take about 90% of the text door and the office would keep about 34 messages a month. The engage decision below runs on those labels; its thresholds are set on this mix and re-measured monthly from the mirrored rows.

The bar to move a customer from Reads to Answers: a clean supervised week on the PMS door with every draft held and reviewed, zero contradictions and zero double texts in the replay, and a measured routine share on figure 7 above a floor set once the number exists. The floor is set from figure 7 once Fede picks it.

Figure 9 is the same messages sorted by topic instead of by who should answer. Leasing is the pile everywhere except the Situs mailbox; maintenance only matters where tenants write; "other" is mostly a person asking for a person.

The supervised hold, as the code behaves (Opus round 2): a held draft expires after 24 hours, never a week; general replies are not held today; approval is per message through an emailed link; there is no daily digest. So the first week on the PMS door needs one change, named in phase 3: every PMS-door draft is held, and a held draft waits 7 days.

Settings: one for the mirror (new capability, default off, Fede turns it on per customer) and one for Clara answering through the PMS (new customer-facing action, default off, all lanes). The applications lane already has a switch of its own (the application-link mode, organization level); the one-setting rule absorbs it in phase 3. Rules, not settings: the N-hour "staff engaged" window, the routine labels, the escalation reasons, quiet hours, the cadence.

7a. Nothing falls through (While you were out)

Decided Oct 15 (Gera)  Written by Trinity, audited against this page, Gera's portfolio model, the constitution and origin/main 2bd0f0c; Smith's four fixes folded in.

The name (Gera, Oct 15): Reception. The whole system, front door, identity, one conversation, the engage decision, the doors and the catch-all, is Reception, what a PM office actually has. Its parts: the front door (one message-arrived event), the desk (identity), the person's file (one conversation), whose turn (the engage decision), the doors (outbound), While you were out (the catch-all, 7a) and the Team notice (what staff see of it, #19603). Anything built outside Reception is a bug, not a feature.

Why. Oct 13, 3:10 and 3:13 PM: a Western Slope commercial tenant called twice about a ceiling leak at a building not synced to PropFlow. Clara could not place the address, took no message, offered a person and closed; nobody at the company was told. Smith, Oct 15: prod reads the team-notify engine on at Western Slope with a team inbox on file (the Oct 13 drop itself is not yet traced), so the failure is a path that never handed off, not a switch. Voice got four per-path "if nothing happened, tell someone" checks that week, each resolving recipients its own way. This rule replaces them.

The rule. Every inbound message ends its turn with exactly one recorded outcome, written by one shared outcome writer, never by a check each path runs for itself. The outcome list is the one the team-notify engine already has (src/lib/team-notify/decide.ts), not a second vocabulary:

A turn that ends with no outcome is written as 3 handoff, reason: unhandled; silence is never an outcome. "Record only" is not a fifth value: on the PMS door, until phase 3, decision 4 holds, the outcome is computed and stored (phase 2, section 11) and no note leaves. Reasons are finite and specific: unplaceable address, unsupported building (a commercial or other row the PMS pull marks unsupported, never typed by hand), wants a person and no route, out-of-scope topic, emergency chain exhausted (all to the company inbox); error, door down (engineering, 'alert').

The note. It leaves through our door (8a): one email from the team-notify engine (routeTeamNotice → teamNotifyEngine, its existing company setting, nothing bypasses it and nothing new switches it) to the recipient the engine's one resolver picks from the door the message arrived on; today that is the company's team email, and the portfolio resolver (nearest wins, org as fallback) decides it when it lands. The voice backstop's property-first lookup (#19528) is a second resolver and retires into this one. A sent email is immutable, so one notice per person per day (the person-day key), and a second message from the same person while their hand-off is open is a threaded reply on the engine's Message-ID, never a new note. Notes go at once, day or night (Gera, Oct 15: no morning digest; Fede, Oct 13: "just email their general email"). The caller hears back on the door they came in. Staff see every note as an event line in the caller's own thread and as the Team notices kind on /conversations (#19603).

How it lands. No switch: recording the outcome is a correctness rule, live everywhere on merge. The front door calls the writer for the PMS door; voice, Twilio and the mailbox call the same writer from where they are until they move onto the door (decision 1(a) keeps them off this initiative's front door; the writer is shared code, not a door move). First two cases, in order: a text to an unmapped company number, which today gets an empty ack and no notice (twilio/webhook/route.ts:644); the voice hangup backstop, which today runs only on the bench (hangup-message-backstop.ts:130, a fix behind a gate, a hot-rule-8 miss, its own follow-up). Proof: the Oct 13 calls and the 1,083-message sample of figure 7 replayed into exactly one outcome each, with a planted no-outcome turn as the red control; the Willows rung with a real call to an unplaceable address and the note read in the team inbox.

8. Sending through the PMS, like an employee (phase 3)

The seam exists, and one lane already uses it. The robot can send a text or an email on a guest-card thread, attributed to the shared "Clara PropflowAI" login, and at Western Slope Clara already presses AppFolio's own "send rental application" button from the guest card (3 in the last 10 days; built 2026-09-18 behind the organization's application-link mode, gated so nothing else sends). There is no tenant route and no work-order route, so it covers prospects only. Phase 3 is real work, not just guardrails: the tenant route, a durable send-once claim, a cap and a send window, a Clara seat per customer, the 7-day hold. (Phase-3 report and Opus round 2, 2026-10-12.)

How solid is the existing send? (Fede 10-12: "I built this a while ago… I don't know if that implementation is solid or needs more testing.") Yes, this is the one, and it is solid for the one thing it does: an application link on a prospect's guest card. Tests: 9 on the writer, 27 on the application-link mode, 31 on send-on-ask, 10 on the message store, 12 on the sender, plus the shared outbox drain (224) and a replay case list. A robot failure parks the row with a reason, never silently; a repeat ask lands on the same row; the stored message is keyed by AppFolio's message id. Not confirmed: a numeric retry cap, so a retry after a robot timeout could send twice; that is the one known gap, and the harness's send scenarios (section 11) are built to find it. Nothing exists for tenants or work orders. The other gap is attribution: a text from Clara's login is recognized as hers only by seat id, and the robot does not carry the sender id on thread rows today, so her own send can be filed as a teammate's reply (round 2, 🔴2). Last touched 2026-10-11.

Scope: all lanes under one setting. Leasing replies, maintenance updates, renewal offers and reminders (today through our number), tenant communications. A customer that chooses the PMS door gets it everywhere; a customer that does not keeps Clara's number everywhere. No per-lane switches. The report's order: replies inside existing PMS threads first (smallest blast radius, never splits a thread), then everything through the PMS per customer after proof.

 leasing · maintenance · renewals · tenant messages · a person typing in PropFlow
                                  │  "this needs to go out"
                                  ▼
          dispatch() for texts · sendPropertyEmail() for email   (gates unchanged:
                                  │                                consent, quiet hours, human-replied hold)
                                  ▼
                   ┌──────── DOOR RESOLVER ────────┐   1 voice, staff, vendors → ours, always
                   │ who is it for · which company │   2 a reply → the door it came in
                   │ which channel                 │   3 else the company setting (text, email)
                   └──────┬────────────────┬───────┘   4 unreadable or door down → send nothing, never our line
                          ▼                ▼
                 OUR DOOR                APPFOLIO DOOR
                 text: Clara's line      OUTBOX row: one id per send, one claim
                 email: building,            │
                 client or our mailbox       ▼
                                         ROBOT, one writer per AppFolio database, warm session, never logs in
                                         guard: person id + role + phone + property, thread unchanged since Clara read it
                                             │ send
                                             ▼
                                         AppFolio inbox thread ──► read-back: one new row from Clara's user
                                             │                      red "failed" row = failed, alert, no resend
                                             ▼
                                         the MIRROR reads the same thread, files that row once by id, so one bubble

Willows battle test (Oct 13–14)

What changed, Oct 14, 01:45Z: this section is new. It tests texts coming in from AppFolio and Clara's texts going out, failure cases included, at The Willows only. No AppFolio login was triggered: Clara's login counter stayed at 0 in 24 h, read before and after. No thread page that marks texts read was opened, and no test text was sent (the last allowed send was kept back, see below).

Result: 12 of 14 pass. 2 real defects filed. Every planted defect was caught (14 of 14 controls fired). The full harness is 76 of 78, with all 78 controls firing. The two failures are the defects below. How it ran: the production code path (the watch tick, the AppFolio source, the robot client with its refresh rules, the company wall, the filer) against a stand-in robot that answers the real route. Each check runs again with a defect planted, and the planted run must fail. Live production evidence sits next to each row.

#	Scenario	Expected	Observed	Result	Control
A	Tenant texts the Willows line in AppFolio	Filed as tenant within 60 s; Clara not woken	Filed as tenant on the first tick; worst case one 60 s busy-hours interval plus the tick (p95 4.1 s). 0 Clara replies, 0 sends. Live, Oct 14 01:51Z: Fede's text from his phone filed as tenant into his existing Willows conversation, Clara not woken, but 9.5 min late: two cold-session ticks (01:49, 01:54) at the 5-min evening cadence, recovered on its own at 02:00. Correct, not fast (#19413: retry at 60 s after a cold tick)	Pass (label, placement, no wake); Fail (60 s)	Fired (planted wake; quiet-hours clock)
B	A teammate replies in AppFolio	Filed once as an office reply; no wake	Filed once as an office reply over 3 ticks; 0 Clara replies	Pass	Fired (teammate's id in Clara's set)
C	Clara's send through AppFolio, read back by the mirror	Filed once, as Clara	Filed once as Clara over 3 ticks. Live: the 23:43 send filed as Clara 32.5 s after AppFolio's time, and each AppFolio id appears once in the thread	Pass	Fired (old seat set)
C2	A Clara row stored before the seat fix gets relabelled	Reads as Clara once the fix is live	Stays "office reply" for good: the store writes each row once. Live: the 21:45 test send is still filed as a staff reply and counts as "staff engaged"	Fail: #19404	Fired
D	Duplicates, out-of-order rows, AppFolio ignoring the cursor, overlap page read again	Every text once, in time order	1/1/1/1 copies, in order. Live: every tick re-reads the overlap page (8 duplicates) and files none twice	Pass	Fired (store without dedupe)
E	Robot 500, 502 with stale-cookie wording, 110 s timeout, AppFolio 429, tick past its deadline	Tick records the failure, no refresh or login, next tick recovers	All five: 1 call (0 past the deadline), no retry inside the tick, paused 60 s (120 s for 429), 0 refresh or login asks, next tick files the text. Live: the 20:57 tick hit a cold session and the 20:58 tick recovered	Pass	Fired (retry, refresh, no deadline)
F	Cold session, twice in a row	Watch pauses, never logs in	Paused both times, 0 login or refresh asks, recovers once warm. The code sends the read with "never refresh" set	Pass	Fired
F2	A database that stays cold alerts someone	An alert after repeated cold ticks	5 cold ticks: only the tick log records them. No error, no Sentry event, no alert	Fail: #19405	Fired
G	Send with no confirmation	Read-back decides; never a second send	Send harness 22 of 22: AppFolio says no → refused after 1 post; row never shows → "sent, unconfirmed" after 3 reads, no resend; post dies → "unknown", the retry is refused, 1 post	Pass	Fired (22 of 22)
H	Does the background thread read mark texts read? (#19292)	Unread state unchanged	Thread read through the data feed (list and thread only, no read-receipt call). Unread count 1 before, 1 right after, still 1 fourteen minutes and two ticks later (battle-test/h-probe/h-run-2.json; the before reading is not on disk, h-run-1.json is empty)	Pass	Not applicable (live read)
I	20-minute live soak plus the full day	Steady ticks, 0 logins, 0 refusals	Day: 689 ticks, p50 2.6 s, p95 4.1 s, 3.0 requests a tick, 2,062 requests (limit 4,000), 1 cold tick and no 403s. Soak window: 4 quiet-hours ticks of 3.0–4.7 s, 3 requests each, 0 errors, 0 logins	Pass	Not applicable
J	The page as Fede sees it (light, dark, phone)	Right labels, right order, no other company	Order right, readable in both themes and on a phone, and no other company's names in the list or the messages. The 21:45 bubble mixes "Clara" on the label with office styling (part of #19404). Open: the thread title reads "Fede (as Kat)", source not found yet	Pass, one open question	Not applicable

What changed Oct 14, 02:00Z: the real-tenant case is now proven live for correctness (Fede's own text, tenant label, same conversation, Clara silent) and failed for speed: 9.5 min because the robot session was cold for two checks and the evening cadence is 5 min. Fixes in flight: a cold-session warning and 15-min page (#19410), and a 60-s retry after any cold check (#19413).

What changed Oct 14, 04:30Z (outbound door chain, all dark, default off everywhere): merged: the company setting, its admin card, the app-side send call, the robot route that posts into an existing inbox thread and reads it back (never logs in, refuses the wrong thread). Armed: the routing inside Clara's text sending (hold + one engineering alert on door-down, never her own line; the record id is the message's own id, never a content hash). Under review: re-driving texts held while the mirror was mid-read, and linking the read-back row to the sent record. Before the Willows flip: those two plus the vendor/staff question (recommend: vendor and staff texts stay on Clara's line; they have no inbox thread). Western Slope dry run: the read-only shadow harness is built and proven (0 writes, 6 controls blocked) but read 0 rows: the robot's Western Slope login has been dead since ~00:30Z (two refused logins, breaker, no re-login since); handed to the robot lane, no login attempted from here. Fairhaven cannot run the mirror as set up (no property on an AppFolio database).

What changed Oct 14, 06:30Z: the door-routing step is merged (dark; every company still on Clara's own line). The cold-check retry fix is merged: a cold robot session now costs the mirror about a minute per check instead of five. The relabel fix is merged and the one mislabelled afternoon row in Fede's Willows thread was repaired. Still open: the busy-hold drain and the read-back link, both retargeted to main and being rebased.

What changed Oct 14, 08:00Z: the outbound text door chain is fully merged and dark (setting, card, send primitive, robot route, door routing, drain of held texts, read-back link). Every company is still on Clara's own line. Next: Fede's answer on vendor and staff texts, then the Willows flip and one Clara text through the door.

What changed (Oct 14, 10:45 AM Denver; corrected 1:30 PM after an independent check): the Western Slope read-only dry run ran, after the robot's login key was fixed this morning. Two watch passes, no logins, no writes. It read 100 conversations (201 texts, part of the week; it stopped at its own request cap). 53 conversations would land on the right person and property. 47 would be held: 21 because our reader skipped the conversation's main person (a bug, fix under review), 12 unmatched prospects, 10 vendors (out of scope by Fede's ruling), 2 unknown numbers. Line mapping and Clara's seat were not blockers; an earlier version of this note said otherwise. The unread check proved nothing yet (the one unread conversation was never opened), and the no-send proof used stand-in controls rather than the real send code. Next: merge the two reader fixes, read the full week, and run a real unread test there.

Label check on the real inbox (Oct 14, 3:30 PM Denver): we replayed 920 stored texts from the Western Slope and Willows inboxes through the current reader and compared our label on each with AppFolio's. 689 of 920 match (75%, up from 58% on the old reader). The earlier "200 applicants shown as tenants" was a reader artefact, not a disagreement: an independent check of all 9 threads in production found people who applied and then moved in; AppFolio calls them tenants and so do our records, with matching ids and active leases. What is left: 184 rows where AppFolio's automatic texts showed as a teammate named "System" (fix merged today, not in this replay), one future tenant we still call an applicant, and one applicant our records still call a prospect (one issue filed for both). Prospects first: a fix that files only prospect and applicant threads and holds tenant threads as a dry run is in the merge queue.

Willows live battle test, passed (Oct 14, 2:30 PM Denver): six real texts from a test phone to the Willows AppFolio number, read by the mirror on the robot's warm session, no logins. Before the fix: both texts reached AppFolio within 3 seconds but PropFlow held them with nowhere to file (the guest-card link lived on the card, and the mirror only looked on the person). After: every text was filed on the prospect's existing Willows conversation, once, in send order, labelled "AppFolio text", in 26 to 63 seconds (median 42 s). The two held texts were filed on their own once the fix deployed. Clara stayed silent on all six (the mirror never wakes her), nothing was sent to anyone, AppFolio's unread count was untouched, no engineering alerts fired. Test card made inactive. Two defects filed: an inactive card still rewrites the person's name, and hold records linger after filing.

Text	AppFolio stamp	Mirror saw it	Filed	Clara silent
1 (held before the fix)	+3 s	2 h later, after deploy	+1 s	yes
2 (held before the fix)	+3 s	2 h later, after deploy	+5 s	yes
3 known prospect	+2 s	+52 s	+57 s	yes
4 right after a tick (worst case)	+1 s	+60 s	+63 s	yes
5 burst, first	+1 s	+28 s	+29 s	yes
6 burst, 3 s later	+2 s	+22 s	+26 s	yes

Kept back: the last allowed live send was not used, because today's deployed send route can still fall back to a login. C was proven by replaying the two real sends from 21:45 and 23:43. Smaller things seen: on the Sept 28 card, two sentences run together with no space ("notes.Done"), filed as #19407. The thread title reads "Fede (as Kat)". It is not in the code, so it is likely a test-persona label stored on the record; this is unconfirmed.

9. Western Slope's inbox, one to two years

Fede's question: what share of the inbox could Clara handle, so the office spends its day on the rest? Nobody knows yet; the read gives the number. One read, two uses: the two-year read is the phase 1 backfill (pending rows inside Western Slope's organization, waking nothing) and the analysis runs over that store. It is built once and runs on the subscription, outside CI. Labels and counts land on this page; message text is read by the classifier, the judges and Fede's spot checks, all on the subscription, and never enters the repo, CI, an eval file or a page.

1. Validated at Willows on Oct 12: the list read, no mark-as-read, stable fingerprints. Still to validate there before touching a customer: the thread read for a tenant party (verified for prospects only) and an overlapping page walk, because ties at a page break can skip a row.
2. Pass A, list pages only (minutes). One hundred threads tonight (a single probe, aggregates only, no text kept), then the full walk back two years at one request per 20 threads. Gives thread count, the tenant / applicant / prospect mix (tests the "90% tenants" figure, which is a gut number until then), properties, assigned staff, unread, failed sends, and one last message per thread for a first rough taxonomy. Landed: the probe numbers are in 9.5.
3. Pass B, thread reads (hours). Each thread's messages from the start, after the robot keeps the sender's name on every row. At one to two pages a thread, two to three thousand threads is 3,000 to 6,000 requests: two to five hours at one request every two or three seconds, overnight, resumable, stopping on the first throttle, JSON only. Raw rows stay in the organization's store and on our machines (tenant PII), never in the repo.
4. Classify offline on the subscription, no metered keys: lane (maintenance request, maintenance update, renewal reminder, renewal reply, rent and billing, lease and move, access and keys, leasing inquiry, tour, application, general question, complaint, emergency, notice or blast, other); sender class (named staff, shared login, bulk, system, tenant, prospect, other); handling (template or bulk; routine and answerable from facts on file; routine but needs an action Clara cannot take yet; needs human judgment; noise such as "ok", "thanks"). Bulk needs no model: the same body to many threads within minutes. Quality: 200 random messages labeled twice by independent judges plus 20 Fede spot-checks; agreement reported.
5. Numbers for Fede, on this page: messages per month in and out by lane; share of staff texts that are templates or blasts; share of inbound that needs a human, by lane (the "what percent escalates" number); staff texts per person by lane and median staff response time, office hours versus after hours; inbound after hours and how long it waited; tenant versus prospect versus unknown; double texts (a Clara text and a staff AppFolio text to the same person within two hours); placement rate (share of threads that would land in a PropFlow conversation today).

9.4 The 12-month communications census (Western Slope, as of Oct 12)

Read-only, counts only, no AppFolio calls: the AppFolio prospect timeline already synced into PropFlow (1,172 guest cards, Sep 2025 to Sep 2026), the shared leasing mailbox (the September audit for the year, a scrubbed four-month corpus for the detail), the Clara line since Sep 18, and the work orders. Each block covers a different population, so the rows are never added across blocks. The tenant side of the AppFolio inbox is the one channel this census cannot see yet; the two-year read above is what closes it.

Maintenance by email: almost never, as Fede said. In four months of the leasing mailbox (5,517 emails) four tenants emailed a new maintenance or property-condition request (a swamp cooler, carpet, a stove filter, a full dumpster), four chased a request made another way, two were borderline; 547 work orders were created in the same window, so email is under 1% of new requests. About eleven maintenance voicemails landed in the same inbox, three of them new. We saw no email intake path: an emailed request becomes a staff-keyed work order by hand ("I'll let the team know", "put a new work order in"). The resident portal, the call center and staff typing carry the volume. Caveat: staff mailboxes and the tenant half of the AppFolio inbox were not read; some staff-keyed orders may have started as an email or a text.

Year to date, Jan 1 to Oct 12 (read Oct 12, the mailbox read-only): 11,690 emails reached the leasing inbox; 6 opened a new maintenance request and 5 chased one, against about 1,700 work orders (AppFolio's own list through August, the mirror since), so 0.4% of new requests arrived by email, 0.6% with the follow-ups; 15 repair voicemails landed in the same inbox, 3 of them new. By month in the scratchpad (pms/census-ytd.md); the inbox folder only, staff mailboxes and texts not read.

What else the census says. Email is the biggest pile but mostly machines; texts are the biggest two-way channel we can see, and the office sends more than it receives (5,808 out against 4,015 in). A fifth of staff texts go out under a shared login, so attribution by signature matters (trap 64). Zillow is 79% of inquiry emails but 46% of all inquiries AppFolio recorded; Rent. and Zumper send none. On Clara's line, 161 of 269 conversations match a real AppFolio prospect or tenant and 148 sit on the company front-door row with no building known. Pending the PMS pull, labeled as estimates: about 20 tenant, vendor and owner text conversations active per day in the AppFolio inbox (the Oct 8 canary), about 35 emails and 57 texts per household over a tenancy, and the call-center log beyond the 68 calls that became work orders.

Method and the exact read commands: scratchpad pms/census.md and census-work/ (scripts and aggregates, no names, no text). The by-hand sorts of emails and voicemails are good to about plus or minus two; the guest-card, work-order and PropFlow counts recount exactly.

9.5 What the newest 100 threads look like (read Oct 12, list only)

One read-only call to the robot's inbox-list route at Western Slope on Oct 12, 18:28 Mountain: five list pages, newest 100 text conversations, no thread opened, no login, seven GETs in all. Aggregates only; the raw rows were deleted. The numbers below are floors (a thread counts on the day of its last message).

Not proven by this read: whether listing leaves threads unread (every row was already read; the Oct 12 JP&Co capture showed unread rows staying unread across three list reads). SMS only; email and chat conversations in the inbox are not in this count.

9.6 When texts arrive, and how fast the office answers (read Oct 12)

Read-only, counts only, Denver time: a year of Western Slope's AppFolio texts from the prospect timeline already synced into PropFlow (3,983 inbound, Sep 2025 to Sep 2026), the 5-household tenant canary, and the Clara line since Sep 18 (production, Query reads only). Fede: "I need data… a distribution of after work to when people go to bed, then almost zero when people are sleeping, maybe a window before work, then core work hours." The answer: core hours carry almost everything, there is no after-work bump on this door, the pre-work window is small, and the night is near zero.

What it changes on this page. Decision 12: the tick follows the door's clock instead of one minute always (Fede 10-12, 8 pm). The office's evening wait (median 13.8 hours, 31% with no staff text in 24 hours) is the "who is waiting" number the third pass asked for: the "waiting on the office line" view in slice 2 shows it for the first time, and the evening and weekend share (16% of texts) is phase 3's case. Limits: prospects only, and 90% of inbound texts answer something the office texted out the same day, so the curve follows the office's own sends; on Clara's line, which answers at every hour, a third of texts arrive between 5 and 9 pm (our own tests not separated). The curve is per door and per customer, recomputed monthly from the mirrored rows, and it will move once Clara texts people in the evening. Method and the full tables: scratchpad pms/hours/hours.md.

Risks: rate limits (one 429 stops the run), account lockout (the read never logs in; it pauses on a cold session), marking threads read (JSON only), PII (raw data stays in the store and on our machines; evals use synthetic names), attribution (shared logins reported as their own sender group). Willows shares its database with a live customer, so Willows polls fingerprint rows and never store previews or numbers. The 12-month cross-channel census is 9.4; the September leasing-inbox audit is its email half.

10. Traps, side effects and likely bugs

What a customer would see if we got it wrong, and the mitigation. Phase = where it first bites. Sources: code map, 10/11 and 10/12 reads, Opus round 1 (43 traps, merged), the engines map (20 engines). Rows 47 to 62 were added in v1.1.

The ten most likely to bite first (Opus round 1, agreed): today's mirror answers office texts from Clara's Twilio number (47, 2, 20); staff names missing, "Office" instead of "Kat" (11); tenants never match and stay pending, Clara still blind (39); a "rent is due" blast counts as a staff answer and stops follow-ups everywhere (10); the backfill moves recency and wakes old threads (17, 58); inbox paging silently skips a thread (41); anything that opens a thread page clears the office's unread badges (1); the per-property job causes a 429 storm or a lockout at connect (2, 4, 43, 60); a former prospect, now a tenant, lands in a leasing thread (13, 51); a STOP sent to the office line never reaches Clara (38).

11. Build order, minimum slice, proof

Started 10-12, 8 pm, on Fede's go. His words: "we have enough to start building… I do want to start validating our assumptions on the architecture… a local harness with real data, or the Willows… reading the messages and ingesting them, putting them in the proper conversation, we're going to have to build it no matter what, as well as the ability to send messages through the PMS, which we already built before; we need to battle test it… starting with an extremely comprehensive test harness that can cover end to end the new architecture is probably the first thing"; "the message comes in, how do we map the identity, put it in the right thread, if there's no thread we create a new conversation in PropFlow: all those things are the core engine"; "maybe there's one feature flag for all this"; "the first deliverable is get the information into PropFlow and see it on the UI, and a backfill of that, safely, without sending anything out"; STOP and START "for later"; photos "not core here, later, the same upload step as today, just a different source". What starts tonight, each dark behind one company setting ("mirror the PMS inbox", default off) and each a chain of small PRs: (1) the harness, end to end, local, on real-shaped rows (Willows captures with made-up names), with a fake robot, the scenarios in the table below and the send-path battle test; (2) the core engine it exercises: adapter contract, watch, store, identity and placement, the conversation created when none exists, labels in the thread view and the prompt, the history mark; (3) the existing send path under the harness and live at Willows. Later, by his ruling: STOP and START, photos, the engage decision, Clara answering through the PMS. Open decisions 1, 4 and 8 block none of it: the harness tests both tick owners and both history placements.

Rules that apply: Fede's go of 10-12, 8 pm covers the harness, the core engine and the send-path battle test; everything else waits for its decision on this page; each chain opens as one builder, each PR one concern under 300 lines, dark and mergeable alone; the fixes above ship as the only code path, live everywhere; prototypes (the read, the classifier) run locally on the subscription and never enter CI. Ladder: unit tests with a planted defect, read-only replay byte-identical, Willows live, Fairhaven sandbox in the customer's shape, supervised week (testing playbook).

The harness, end to end (Fede 10-12: "an extremely comprehensive test harness that can cover end to end the new architecture is probably the first thing")

Local, on the subscription, never in CI until the core lands as code: real-shaped rows (the Willows list and thread captures with made-up names; never a customer's rows), a fake robot that serves recorded pages and records every request, the real store and readers underneath, and a planted-defect control per scenario (a check with no control does not count). The live rung is Willows: the watch on the real line and one real application-link send.

12. Decisions for Fede

TL;DR: Fede's 8 pm go starts the harness and the core engine tonight under one setting. Decided tonight: decision 12 (the tick schedule, bands from figure 8, thirty minutes after midnight), decision 7 (one year, Western Slope and Situs). Decision 1 runs on the recommendation (our sync job owns the clock). Decision 4 (Fede, 10 pm): backfill is a per-company number, default 7 days to prove the mechanism (Fede: 'it could even be a week') (a year is too much; one to three months decided later from mirrored data); old rows land in conversations on day one; the history mark stays internal, never shown; the hard rule for the whole exercise is that a mirrored row can never cause a reply or any outbound, proven in the harness. Fede wants it on at a customer by Tuesday once battle-tested. Decision 8 (phase 3 scope) waits for the year of data. Everything else is recommended as written and can change later. Recommendation first on each. The third pass (a fresh Fable 5.1, unsteered) changed decisions 1, 3, 4, 5 and 8; section 13 shows where it disagreed and what was kept.

13. Tensions and disagreements

Opus 5.5 round 1 (an independent proposal and trap list, 7,100 words, read-only against origin/main and the Willows capture) and the engines map (20 engines read against a mirrored row) landed tonight. Where they disagree with this page or with each other, and the verdict:

Round 2 (Opus 5.5 reads v1.1 of this page adversarially against main; 7 blocking, 15 important, 17 contradictions; scratchpad pms/opus-round2.md). The seven blockers and what changed in v1.4:

Also taken from round 2: decision 1 (the front door as a shared module with a build check), decision 10 widened to operator paths, the Fede 10-08 placeholder ruling quoted as given, the robot already paces, the heartbeat relogs a lapsed session, the newest 100 threads are half applicants and a third unknown numbers rather than "90% tenants", the Coworker Line labels every assistant row "Clara" and renewal threads are excluded from person matching (two more readers for the provenance fix), the backfill's real request count (3,500 to 7,000 plus photos, with session checks), and the switchover order for the per-property loop. Not taken: nothing in the blockers; the 15 important gaps are tracked in the file. Contradictions 1 to 17 are resolved in the sections above or listed in NOT VERIFIED.

Third pass: a fresh Fable 5.1 at max effort, unsteered (Fede 10-12)

It read v1.4 cold, then checked it against both Opus rounds, the research files and the code, read-only (scratchpad pms/third-pass.md, 1,400 words). Its opinion, in its words: "Build the mirror. The read is nearly free and 'Clara sees what the office said' ends the two-voices problem on leasing threads today. The real risk is scope, not technology: the page has grown from 'mirror the inbox' into 'rebuild every door into PropFlow', and phase 1 carries about ten prerequisites before the first visible result. What Fede asked for is a one-to-two-week slice." It agreed with six decisions, changed five, and found four things nobody had raised.

Four things nobody had raised, all taken:

• Where a customer's tenant texts live decides what the mirror is worth there. Western Slope's office line is where tenants are; Situs runs about half of its tenant texting on two staff members' personal cells and our text-only read returned "no messages found"; email cards were not read. Western Slope first; Situs is not the second customer. Now a row in section 1.
• A third voice. AppFolio's own resident agent (Resident Messenger, generally available since June 2026 (unverified), in the resident app; its reach into the texting inbox is not documented) could answer before Clara. AppFolio automation is its own sender bucket and its answer counts as the office's: trap 67.
• Phase 1 had no exit proof. Now named: 300 real Western Slope conversations where staff texted, replayed before and after, zero contradictions, zero duplicate tour offers, the follow-up stood down.
• Phase 1's value for the office is "who is waiting", not "one history in PropFlow". The office lives in AppFolio. The "waiting on the office line" view and the Coworker Line reading the mirrored thread are store-only reads: slice 2, and the evening wait in 9.6 is the number they show.

Code check on decision 5 (tonight, origin/main, read-only). The two readers that gate the double text already tell staff from Clara: the prompt frames a human-authored row with an external name as a teammate's turn, and the follow-up gate counts any human-authored outbound as "staff answered". Four more are right or harmlessly blind (the hold writer, the runaway ceiling, the commitment extractor, the agent metrics; the collections chase and the tenant count look only at tenant rows). Six readers key on the message role alone and would read a mirrored staff text as Clara's: the 12-hour outreach cooldown, the prior-contact flag, the first-email prior-thread check, the prospect summary, the promise transcript and the intake classifier; one more ("handled by") is unclear. So the third pass is right that "every reader" was over-scoped, and the engines map is right that the fix is real: six named readers, pinned by the harness's engines scenarios. One more trap from the check: the "is this Clara's own send" test is "author is not human", so a bulk or notice row must never carry a non-human author kind unless it is meant to count as hers (trap 68).

Where this page still differs from the third pass. (1) Decision 4: the page keeps day-one history as the recommendation because it is what Fede asked for; the third pass's smaller slice is option (b) with its reason. (2) "Decide phases 0 and 1 tonight, 2 to 5 later": taken, with one nuance: phase 2 (compute "would Clara reply", send nothing) needs no decision beyond the mirror and can follow slice 1 without waiting on the numbers; only its thresholds wait. (3) Section 7: the third pass wanted one paragraph until the data lands; the page keeps the two-state table because Fede ruled the levels out and the table is the rule, and figure 7 replaces the theory the moment it lands. Fact corrections it made to itself and to this page: the 220 fridge magnets carry the after-hours emergency number, not the texting line; "about 90% tenants" was a gut number; the cadence was stated three ways; "text never leaves the store" was false.

7a vs decision 1(a): 1(a) keeps voice, Twilio and the mailbox off this initiative's front door, while 2b and 7a move paths "behind the door one PR at a time". Resolved Oct 15: the outcome writer is shared code every path calls from where it stands; it is not a door move, so 1(a) stands and 7a lands everywhere.

14. Reference (for agents)