Added Nov 4, 2026 · Shipped Nov 5: #25337 (every tour step reads the thread first) and #25330 (Clara runs the steps on showings staff book; active only once onboarding records the customer's PMS no longer texts renters about showings) are merged. Live proof at Fairhaven is blocked until the test-company model accounts reset (~Nov 10).

What changes

Results of the local test (Nov 4)

Real threads replayed locally, no sends: 27 tours from Situs and Western Slope, 89 tour steps, each judged against the thread as it looked at send time. Labels were written by hand before the model ran.

Staff guest-card notes: live and read by Clara (Nov 5)

Fede, Nov 5: 'we need to be able to use notes', 'no feature flags', 'battle test it'. The Sep 30 notes import (dark for five weeks) is now live everywhere (#25404). Notes re-import within a minute of a change (#25413). Clara's follow-up, first-reply and tour-step reads consult the notes through the model, classifying each as a person acting, a bookkeeping note, or Clara's own. The first cut (a presence check) was rejected by its own battle test.

• Planted-defect controls: remove AppFolio's booking text, the model sends (PASS); add a teammate's confirming text, the model skips (PASS).
• Most remaining misses are definitions, not reading errors: the 1-hour reminder also carries how to get in, so the model sends it even after AppFolio's confirm exchange gave the time (5 of the 13 misses); reworded to time-only, 39 of 40 agree.
• "A teammate owns this thread" must not gate tour reminders: it was true on 16 of 20 steps on Clara's own tours. A one-hour "teammate texted recently" rule would have silenced 13 needed messages.
• Limit: this only stops Clara's copy. At Western Slope showing 597, AppFolio's "Thanks for visiting" email came ~22 h after Clara's after-tour link, so the renter got both; only AppFolio's own switch removes that.

Honest number: the read is right 85% of the time, so Clara's steps on a staff-booked tour run only where the PMS's own showing texts are off; otherwise about 1 in 10 renters would get a duplicate.

Harness: branch fede/office-activity-harness, scripts/coworker-harness/office-activity/send-check/ (prompt, fixtures and labels in separate folders; 161 subscription calls). No PR.

Built in three small PRs, in that order. Proof: replay of real Situs and Western Slope threads with AppFolio's texts on, then a live run at Fairhaven. Decision (Fede, Nov 5): no Clara switch ("why is this a setting"). Status: PR 1 read-first gate (#25303), PR 2 steps on staff-booked showings (#25229); results and Willows proof added here when they land.

Added Nov 4, 2026 (evening) · Tour-row decision taken Nov 4 evening; three pending · harness part 1 results in · full pass by an Opus 5.5 and a Fable 5.1 reviewer, five live sessions asked, past sessions mined, every page re-read · read-only, no PR · supersedes the Nov 2 decision list and N1–N5: three decisions below · independently verified against main a3cdc6bbeb Nov 4 evening (corrections below)

The problem in one line. Clara decides "is a person already on this?" from the last text in the thread. At Situs the office works in AppFolio, not in texts: a person booked every showing this year, and staff answered first in 36 of 47 text threads. Office silence in the thread means "someone has it", and Clara reads it as "nobody does" (Norma Nov 4, Matthew Nov 2). The opposite failure exists too: one staff text silences her for good (43 of 73 active Situs threads).

1. What the office does by hand, and whether Clara sees it

Three questions per action: is it in our records, is it shown in her prompt, does any decision read it. "Yes to records, no to decisions" is the pattern; staff-made showings are the one row that is no on all three.

Showing outcomes (shown / no-show) are out of scope for now by Fede's word (Nov 4): a later phase, not dropped.

The wake reads the whole thread, not texts only. An office call filed on the thread would have kept Clara quiet on Norma; it was filed about 40 minutes late.

Sources: main a717d5d4ea, production settings read Nov 4 (notes import on only at Sandbox). Ten doors decide whether Clara speaks (wake on an AppFolio text, Twilio text, email, first touch, staff email, staff text, reminders, after-tour link, follow-up cadences, voice); none reads a staff showing or note. Out of scope by Fede's word (Nov 4): staff mail in their personal mailboxes.

2. Results so far

Built on the Nov 2 POC's contract (Situs Onboarding lane): neutral contract under src/lib/domain/pms/office-activity/, AppFolio adapter in the integrations layer, harness and 58 scrubbed fixtures under scripts/coworker-harness/office-activity/, branch fede/office-activity-harness pushed as a backup only, no PR, no CI. Robot: 59 card reads + 58 showings reads, read-only, no login. Atlas row added. Not done: drift test and hash lock, README, the Sep 1 dump replay.

3. Corrections from the independent pass

Bottom line. "A refactor first" is mostly false; what is true is narrower: give the existing door the office record as an input and have the five callers ask it.

Confirmed as stated: the Oct 14 one-decision gate was never on main; first touch is log-only; the notes import runs once per new card behind a default-off setting; the notes classifier has no caller; nothing imports staff-made showings. Harness re-run offline: same numbers (152 → 181 of 228; dropping the showings source returns 152; zero network calls). Limits: every note, call and showing it found carries no named person; truth labels are model-made, 4 cards checked by hand; the adapter's hard-coded Mountain time and notice-wording match are fine for a prototype, a defect in the product. Source: code origin/main a3cdc6bbeb, harness fede/office-activity-harness 4091695854.

4. Path forward, rebuilt: see first, decide second

Step 3 is decided. Fede took the human-booked tour row (silent, no switch) on Nov 4 evening; it is being built now. A confirmed tour row is not silent today: the tour walker starts reminders for a future tour and sends the application link at once for a recent past one; the team confirmation email fires when a tour turns confirmed; the showing write-back fires on every tour row. Each of those must refuse the human-booked state, each proven with a planted-defect control.

Steps 1 and 3 run side by side. Live runs in steps 2 to 4 need a real AppFolio test card; reopening Willows is Gera's call (ask Smith on the bridge). Stop: wake-list patches, timers, a second decider, confirm-or-cancel and group texts until step 3. Follow-through must ask the step-2 read before it sends. Where: tour-cohort-walker.ts, send-pm-tour-confirmation.ts, showing-sync-stream-consumer.ts, external-change/reconcile.ts.

5. Decisions for Fede (three; (a) recommended on each)

1. C1. Once the office has spoken on a thread, may Clara ever speak there again on her own? Fede ruled yield + next-day re-check, Nov 4 (session 006; quotes relayed): "we need to be smarter here", "a human touched it during the day great, but then we need to check next day and see if we need to follow up", "not stay silent forever", "if a reschedule didn't happen why not have Clara follow up the next day… try a few times to reschedule". Joint wording (this lane + 006): (1) the read answers "does a person at the office own this thread right now": yes while the newest office-side row is a staff message or note, a human-booked tour is upcoming or ended less than N hours ago, an office call is filed on the thread in the window, or a named assignee touched the card today; the never-released hold becomes this derived answer, no flag. (2) When a person owns it, Clara yields, never mutes: the yield opens a Clara-held follow-through item due the next business morning (sooner only if the ask is time-bound). At due the same read runs again: still owned, stay quiet and read again next morning; no longer owned and the renter is waiting, or a promised step (reschedule, link, answer) never happened, Clara follows up with her normal cadence (one reschedule try). The clock only wakes the read; the read decides. No thread is left without an open item after a yield. (3) No pushes while the office owns it. Known gap: office calls land on the thread 40 to 70 min after the call, so the read can be early by that much. Split: 006 owns the read and every caller of it; this lane feeds it human-booked tour rows and office-activity entries (with a filed-at time on calls) through the person picture only.
2. C2. Should Clara ever message renters about tours staff booked? (a) build it dark, then turn it on per customer once their own AppFolio reminders are off. (b) never; she only stays out of the way. Recommend (a). Parked (Fede, Nov 4: no notifications for now; "what?" on the question): nothing changes tonight; re-asked after the silent tour row is live.
3. C3. What Clara may use from staff notes (can wait until after step 3). (a) the facts that change what she says (time, host, code sent, link sent), never the note's wording. (b) only to decide whether to speak. (c) raw notes. Recommend (a).

The former five, and why only these three remain:

• #1 Staff-booked showing → tour row. Decided (a), Fede, Nov 4 evening: "we just need a concept of a human manual tour vs Clara booked tour somewhere"; "would we send notifications if we detect a manual staff tour? I don't think we should"; "let's start there". A showing a person books, moves or cancels becomes a tour row marked human-booked; it sends nothing (no text, no host note, no reminder, no calendar event); Clara stops offering times over it and stays out of the thread; her follow-ups pause while it is upcoming, and after it passes today's rules apply. No switch, because a read that sends nothing is a fix under the Sep 30 rollout rule; proving it sends nothing is our job. Building now as one PR.
• #2 Model read vs a list patch: decided by the Nov 2 "every message … reasoning" rule and the Nov 3 "systematic refactor" ruling.
• #3 No clock for picking up: decided Oct 16 and Oct 25 (both quoted in the code). Only "may she pick up at all" remains, and that is C1.
• #4 Walk-ins: not a decision. Decision record 0072 covers what Clara books for someone at the door, not importing a showing staff booked; noted here since decision records are retired.
• #5 What she reads from notes: real but deferrable; it is now C3.

6. How this relates to "Clara remembers unfinished business" (002)

Same record; not yet the same read. The follow-through brief keeps an open-item list per renter and asks one question at each due time: speak, acknowledge, or stay silent, while tracking the item. Today's replay showed that question is blind to office activity, which is why it talked over staff 7 times in 42. Office activity is the missing input to both: a staff showing or call opens or closes items the same way a staff text does. Follow-through does not call the one function today: it has its own company mode (default off) and its own read, and sends nothing yet. When it starts sending, it must ask the step-2 read first. Supervised follow-through at Western Slope and Situs does not wait on this; nothing sends unseen there.

Not verified by the independent pass: production settings (notes import on only at Sandbox; Situs's text setup); Norma's timing (the 40-minute call-filing lag, and whether her 17:20 prompt held the "showing scheduled" notice; the scrubbed fixture was used, not production rows); session 006's replay numbers (34 of 42; 32 of 36); the Situs data numbers (507, 36 of 47, 43 of 73, 15 of 111, 61 of 202); whether Willows is closed, the AppFolio request budget, and which Situs hosts have connected calendars. Fede's quotes were not re-read in raw transcripts, so every dated ruling is as cited by the page and the code comments.

They agree on the shape. One tour record whoever made it, with an origin, a host and a provider-prefixed showing id. One Temporal run per tour that can start with the state the tour already has; every step first asks "already past, or already done by someone else?" Showings booked in AppFolio become Clara tours and get her calendar event, reminders and after-tour steps. When a person answered the renter first, Clara stays quiet. The north star is all seven AppFolio automatic messages off, each switched off the day its Clara replacement is proven.

They agree on the data. At Situs a person booked every showing this year (Fable counts 390 since January in one source, Opus 495 in another; both say 100%). About six in ten were booked the minute the card was typed in. One booked showing in four was changed afterwards. Renters self-booking on a listing site this year: zero. Staff answered a prospect's text first in 36 of 47 threads.

TL;DR: 19 lines, one list for the whole initiative. Yes to all except 15 and 16 (hold).

1. The tour run starts from any state and every step checks "already past or already done" first: ships as fixes, no switch. Recommend yes.
2. Showings booked in AppFolio (by staff or the VA) become Clara tours within 15 minutes, behind one company setting, default off; Situs on after the Willows run. Recommend yes.
3. On an imported tour Clara confirms only if AppFolio did not, puts it on the host's calendar unless an event already sits there, and tells the host once only when someone else booked it for them. Recommend yes.
4. Clara picks up a staff-started thread after 15 business minutes (5 after hours) of the renter waiting, as a setting, default off. Recommend yes. (Hold means Fable's "waiting on nobody" rule instead.)
5. Clara's after-tour follow-up replaces AppFolio's "Thanks for visiting" email, and renter replies to AppFolio's own thread are matched to the renter's conversation. Recommend yes.
6. Listing-site bookings (TurboTenant, Tenant Turner) use the same import path, built last, since none happened this year. Recommend yes.
7. Situs switches AppFolio's messages off in the order the tables below give, one note per switch, each after its proof. Recommend yes.
8. Staff-booked showings: Turn-on day: Situs switches off AppFolio's renter showing messages (scheduled, updated, cancelled, reminder, after-showing email); the confirm request goes off when Clara's confirm ask (decision 11) is on. Recommend yes, or renters hear everything twice.
9. Staff-booked showings: Renters already on the calendar get Clara's intro on turn-on day (6 open on the dump date). Recommend yes, never between 9 PM and 8 AM.
10. Staff-booked showings: Ask Gera for one real-AppFolio run at the Willows (closed today). Recommend yes; Fairhaven proves only Clara's side.
11. Confirm or cancel: Build it as a company setting, default off; turn on at Situs after a Willows run. Recommend yes.
12. Confirm or cancel: Renter wording: "Please reply to confirm you're still coming, or we may need to cancel." (softer: "…so Tessa knows to expect you"). Recommend yes: Fede's wording; fair because nothing is cancelled. The sample below now carries this ask in the Situs team's own words (what the team's own texts show).
13. Confirm or cancel: No reply by 30 min: one email to the host; the tour stays booked; nothing written to AppFolio. Recommend yes: Fede's Nov 2 ruling.
14. Confirm or cancel: The fold: with the setting on, a confirmation sends the host nothing. Recommend yes.
15. Confirm or cancel: Also drop today's "confirmed" text where the setting is off. Recommend hold: Western Slope hosts on texts get it today.
16. Confirm or cancel: Auto-cancel at the deadline, AppFolio's way. Recommend hold until a month of data.
17. Confirm or cancel: Setting name tour.requireConfirmation, label "Require confirmation before a tour". It names the policy, not the message: a tour is only kept if the prospect confirms the day of; Clara asks, reads the reply, and acts (keep, move, or release the slot per the no-reply rule); the text is just how the policy is carried out. Recommend yes.
18. Confirm or cancel: Only Clara asks: before turn-on, check (and if needed untick) AppFolio's confirmation box on the showings Clara books, or renters get two asks and AppFolio cancels. Recommend yes, before turn-on.
19. Confirm or cancel: Heads-up at 30 min, as built. 45 min gives a driving host more notice but flags more tours. Recommend yes; revisit with data.

Already decided today: no automatic cancel or release of an unconfirmed tour at launch; the host hears once, 30 minutes before, and the tour stays booked. A staff reply addressed to another staff member on a thread Clara is only copied on gets nothing from Clara (fix in flight).

Added Nov 4, 2026 · Proposed, pending Fede's review · read-only, nothing built, no PR · gleaned from 2,392 docs pages, the repo, and every session folder (Fede's own words only; relayed quotes marked)

What happened. A walk-in at Barcelona (8121 W. 9th Ave, Situs). Deiby made her a 10:00 AM showing in AppFolio. At 10:19 she texted her email address, answering Deiby. At 10:20 Clara woke, asked whether she had made it to the 10:00 showing, and offered times between 11:30 and 4:45. At 10:23 to 10:33 Deiby sent the application link, the lockbox code for a self-guided visit that afternoon (in Spanish), and moved the showing to 6:30 PM. Nothing on main changed since Nov 1 (five live sessions polled). Thread cbbe25a6…; the card says Norma, Deiby writes to "Nataly".

The rulings that already exist (newest first)

What Norma changes in the decisions above

The design on this page already covers the import, the pick-up timer and the read-back. Norma sharpens five lines. Each is a yes / hold.

1. N1. The import's switch. (a) Split by what talks. No switch: the tour row itself, visible to the availability tool and to the wake read, with no workflow start, no calendar write and no message to anyone (a tour Clara cannot see is a correctness gap). Behind the company setting: everything that speaks or writes a calendar on an imported tour (the intro, reminders, host notes, the event). (b) Decision 2 as written: the whole import behind the setting. Recommend (a): it matches the Oct 21 words and the rollout rule (a switch only for a new outbound).
2. N2. The wake gate. The Oct 14 gate (one decision, every signal on the card) already names "a showing by a human actor" as the strongest sign that a person has the card, but it was designed and never built: no code on main carries it. (a) Build that gate and run it at wake time as well as at intake: the model reads the card (showings and who made them, staff touches, notices, whether the renter is answering a person) and decides speak / stay quiet / tell the host. (b) Extend today's sender-kind list with "a showing notice counts as the office". (c) As today. Recommend (a); (b) is one more hardcoded rule of the kind Fede ruled out on Nov 2.
3. N3. The pick-up timer (decision 4) runs only on a thread where the renter is waiting on nobody, as read by the same model pass; a staff-made showing with a staff reply inside 15 minutes is never picked up. Recommend yes; this reconciles Fable's and Opus's versions.
4. N4. Walk-ins. A walk-in whose staff booked a showing becomes a tour (Oct 5: a self-guided tour still books an appointment); decision record 0072 is updated to say so. Recommend yes.
5. N5. Codes on imported tours. Clara sends the lockbox code 1 h before, from the card, unless the model read shows a person already sent it (Deiby did, in Spanish, at 10:32); never before 8 AM, never stored. Recommend yes.

Replay cases for the harness: Norma (Nov 4, cbbe25a6…, name mismatch and Spanish), Matthew (Nov 2), Deyci (Oct 30), Stephany (Nov 2). Mutation control: restoring today's list-based gate must turn Norma red. Nothing is built until Fede's yes; no PR, no branch.

Yes / hold: decisions 2, 3 and 8–10.

A new company policy for tours Clara runs, "Require confirmation before a tour": a tour is only kept if the prospect confirms the day of; Clara asks, reads the reply, and acts (keep, move, or release the slot per the no-reply rule; at launch the no-reply rule is keep the tour and tell the host, and releasing is decision 18, on hold). The text is just how the policy is carried out. The reminder an hour before a tour asks the renter to confirm. Any reply counts, text or email. If the renter has sent nothing by 30 minutes out, the host gets one email: not confirmed, still booked, a quick call might help. A confirmation sends the host nothing, so today's "confirmed" note folds in. Nothing is cancelled and nothing is written to AppFolio.

Related design, owned elsewhere: Clara re-engages when a human drops the ball (speak / stand down / re-engage when a teammate takes a thread and goes quiet, plus the team's daily list of items nobody is on; Proposed, nothing built). Split: this page owns the PMS inputs that read needs (current assignee, showing status, staff-booked tours created from the PMS, tour-row corrections); that page owns the rule and its proof; the Clara Refactor lane owns the shared context loader.

Proposed — pending review Nothing is built from this page. First consumer, in progress: a showing a teammate moved, read from their reply and checked against AppFolio; cancels wait for this design.

The rules

1. One owner per field. The PMS owns its facts; Clara owns her messages, notes, reminders and the confirmations she collected. The owner wins; no approval button.
2. Last-seen mirror. A change is "the read differs from the mirror", never "the newer clock".
3. Once per fact. One keyed Temporal signal per change, also during a "human replied" hold.

What each change does

How we notice: do we poll?

Yes, targeted, signals first. Cards, units and applications are already read every 1 to 5 minutes; showings are not.

Requests measured on Situs, Nov 2: 1 per showing read and 3 per card read (plain requests); a full card page in a browser takes 15 to 16. The earlier "37 a page" had no source. Method: Red team, Nov 2.

Four decisions for this design (E1 to E4)

• E1. Staff change a tour's time or status in the PMS: (a) PMS wins; (b) Clara wins; (c) latest wins. Recommend (a). Yes / hold.
• E2. Staff move or cancel a tour Clara confirmed. Telling the renter is a new outbound message, so it sits behind a company setting that is off by default and never sends at a Preview or Off building. With the setting on: (a) Clara sends one correction, unless a person told the renter between 30 min before and 3 min after the change. She waits about 3 min, then checks again. The model judges whether the renter was told. Who sent the message comes from the sender's identity, never a signature, and an unknown sender or a failed text never counts. (b) Nothing. (c) Staff approve first (a button we won't build). Recommend (a), with the setting off until you turn it on per customer. Yes / hold.
• E3. Freshness: (a) signals at once, calendar every 10 min, tours due within 48 h every 5 min, nightly sweep; (b) every open card every 5 min; (c) nightly only. Recommend (a). Yes / hold.
• E4. Both sides changed one field between reads: (a) owner wins, plus one correction if the renter saw the other value; (b) a person resolves it; (c) latest wins. Recommend (a). Yes / hold.

Two new rules, Proposed (found on Stephany, Nov 2)

Proposed — pending review Fede, Nov 2: "a new design". Nothing is built and no PR or branch is open for either. Both go through the battle test and Fede's review with the rest of this section.

R. Clara reads the renter's recent messages before any tour step. Before a reminder, the after-tour "how was it?" ask, the application link or a chase, Clara reads the renter's messages since the tour was booked or last moved (a thread on "human replied" hold included) and decides: go ahead, skip, or tell the host. Today none of these steps reads the thread, so Stephany's 2:32 PM "I'll have to reschedule" went unseen.

Recommend (a). Yes / hold.

H. The host follows the agent assigned in the PMS. When staff book or edit a showing, the person assigned in AppFolio becomes the tour's host for the calendar, notices and the after-tour ask. Stephany: a different host took the showing at 1:15 PM; our tour still names Deiby.

Recommend (a). Yes / hold.

What we will not do

• Write both systems at once, or let the latest change win.
• Treat an AppFolio email as the fact, or skip echoes by time window.
• Poll every card on a flat timer, or add a "confirm this change?" button.

Where the code goes

• Adapter: neutral change events (kind, source, provider-prefixed id, actor's roles); core never names a PMS. The first consumer already uses this shape.
• showing-sync-stream-consumer.ts is not the seam: it only turns our tour changes into PMS writes; it should skip origin-external ones (no check today).

Battle test, Nov 2

Proposed — pending review We replayed every real Situs showing change since go-live (Sep 29) through this design, assuming E1 to E4 = (a). Everything was read-only: nothing was sent and no PR was opened. The model's reads are stubbed with what actually happened, so this tests the rules, not the model. Passing scenarios only show the rules hold on recorded data; the real proof is a live run after you decide.

"Main today" means main with the teammate's-text fix merged (Nov 2). That fix sees exactly one kind of change: a move a teammate announced by text, on a confirmed Clara tour, at a live building. The 10 cancels had no Clara tour behind them, so there was nothing to undo.

Why 71 bookings and not 83. Staff booked 83 of the showings on the calendar since go-live (customer table below). 71 count as new bookings. 3 were rebookings that pair with a cancel on the same card into one move: Angelique 4011 to 4012, Maynor 3989 to 4026, Diego 4073 to 4076. The other 9 were booked before Sep 29, so only their later changes are replayed. Nothing is left over.

Three worst surprises

1. Stephany (showing 4082) got the wrong host and an application link for a tour that never happened. The leasing agent who took over her showing never became the host. Her "I'll have to reschedule" sat unread on a held thread. AppFolio's 3:00 PM "Showing Occurred" is just its clock. So main sent the notes ask to the old host, the link at 5:15 PM, and queued three chase texts. Patricia (showing 4081) is the same: nobody joined, the clock stamp fired, the link went out. The design gets both right.
2. AppFolio's automatic emails name an agent as the sender. Reminders, invitations, updates and cancels all carry the assigned agent in From. Production files them as that person. That is what paused Clara on Matthew's thread while her offer was still open. Reading who did something from evidence (the activity log, the roster, timing) instead of the From line resolves every record.
3. Main misses almost everything staff do in AppFolio. It misses all 71 showings booked by hand: no person, no tour, no reminders, and Clara's open offer stays up. It also misses 9 of 10 moves and 9 of 10 host changes.

Every record resolves from evidence, never from a signature. The evidence is, in order: our own ledger, the sender's user on the roster, the text's direction code, the activity author (texts and card events only), the clock, a few-second causal join to a showing change, and the full wording of AppFolio's automatic messages. A shared VA seat counts as a person, but never as one named person. "Unknown" fails the run, and there are none.

Red team, Nov 2

22 of 22 pass. Each attack is a real case, a variant of one with one thing changed, or a made-up case where no real one exists (rows 12 and 13), plus a planted bug. A row passes only if its scenarios pass and the planted bug turns them red.

Three changes from your review, now in the rules: (a) telling the renter is a new outbound behind a company setting, off by default, never at a Preview or Off building (E2 reworded above); (b) a cancel and a rebook on the same card within about 25 minutes are one move, in either order; (c) the "already told" check looks both ways, from 30 minutes before the change to 3 minutes after, then checks again. The model judges whether the renter was told. Who sent it comes from the sender's identity, and an unknown sender never counts. On the real cases, counting AppFolio's automatic notice as "told" changes no decision.

Still to align: the staff-booked showings rule (e) still counts an AppFolio notice as "told" and tells hosts about a reassignment. The battle-tested rules above count only a person, and the calendar moves silently (Stephany D1).

Poll cost, in requests. The "37 requests per card page" figure has no source. We measured our own reads on Situs today:

• one showing: 1 request;
• one card, read with plain requests: 3;
• a full card page in a browser: 15 to 16.

Method: counted from our own read logs on Nov 2 (85 single-showing reads; 70 cards at 3 requests each; 5 full page loads at 15 to 16 requests to the customer's AppFolio, plus 3 writes blocked each time). Requests an hour = calendar reads × 1 + card reads × 3. Reads have no cap, only logins do, and our own code disagrees on that cap: 3 or 5 an hour.

Gaps the replay found Proposed Each one is guarded by a planted bug:

• Words after the slot count. Sabrina, showing 4061: the agent texted "Are you at...?", and an hour later she said she needed to reschedule. Up to 48 h after the start, her words can show the tour did not happen.
• A plain "yes" to a teammate is a confirmation. The model reads it (Leslie, showing 4014).
• A teammate's note can close a visit, up to 48 h later. One note about an outing closes every showing on it (Sheyla's two homes, noted the next day).
• Each question to the model names its showing. Without that, Sheyla's "Confirm" to her 7:30 PM showing would also have confirmed her 8:00 PM one.
• Card closes count per home. Three homes closed in the same second are three closes (Diego).
• A cancel is dated at the message that called it off, not at the renter's last message (Rita, showing 4025).
• Tour mode can't come from AppFolio's type field. It said in person for video and lockbox tours (Rodney 4057, Ashley 4063). Open: no rule yet.

1. The answer in five lines

The plan

Yes / hold for Fede

All seven: yes. Two gate Situs this week: 2 and 7.

The seven AppFolio messages and what replaces each

2. The lifecycle, with every door Clara can walk in through

3. Temporal: one workflow, started with the state it already has

Decision: catch-up, not a start-at-state input. The run already observes the tour instead of assuming it: workflow id = tour id, a second start is a no-op under USE_EXISTING, every timer hangs off the scheduled start, the day-before and one-hour reminders skip once their moment has passed, and every send re-reads the row and quietly skips already-sent. So a staff-booked tour starts the way the cohort walker already starts an auto-confirmed one: write the row as confirmed, then signalTourConfirmed(…, {startIfMissing}); the "please confirm" loop returns before its first nudge. What is missing sits in the adapter and the activities: no PMS code calls applyTourIntent or any signal today, so a showing created, moved or cancelled in the PMS changes nothing here. Two constraints: the run needs a personId (resolved from the guest card first), and the row's existing source: clara | manual | external is written only as clara.

4. Data model

A showing on a home with no mapped property still becomes a tour at company scope, host line to the company inbox; the property is narrowed in when the unit maps.

5. Who goes first, and joining a thread late

Fede, Nov 2: no race rule at Situs now ("expected, we just launched"); what follows is behavior, not a switch. The pieces exist but do not see each other: the first touch skips when a teammate replied and waits ten minutes on a hand-made card; the follow-up gate stops on "teammate answered, no renter reply since" and "staff promise pending"; a staff text through the PMS texting door sets a hold, a staff email none; "coworker acted outside" is classed and then ignored; and "tour booked" reads PropFlow tours only. The thread-owner record and the import make one rule of these.

6. Western Slope said this already

Emails, card records and session records read as written. Lines marked raw come from the per-speaker #transcripts text of eleven Western Slope meetings (Sep 4 to Oct 28), never the recap; Kat had no mic of her own, so a † line is labelled Jason and may be hers, and Oct 21 and 28 names were removed at the source. The hand-off is their first ask at every meeting since Sep 16.

7. How often each door is used (Situs, real data)

Counted from Situs's own records: the AppFolio guest-card dump (Jan 1 to Sep 1, 2026; apartment buildings, 658 cards; all property types in parentheses), the message mirror (Sep 29 to Nov 2) and the live window since Clara went on (Oct 29 to Nov 2, ten Clara threads). Renters as initials; doors in order of use.

What the counts change: the import (PR 2) is the product at Situs, and a switch-on day is a mid-flow day (seven in ten open cards already past the tour), so phase 2 ships before anything renter-facing; staff moves are one booked showing in four, so PR 2b and the staff-move chain come next; listing-site import goes last. Caveats: AppFolio's confirm requests carry the agent's name and read as staff work; talk outside AppFolio is invisible, so "staff first" is a floor; the live sample is ten threads.

8. Risks and the double-message hazards

9. PR cut and proof ladder

Order for Situs: item 1 off now (4a is already off); PR 1–2 and the Willows run settle the AppFolio-confirmation question, PR 2b alongside; PR 3 with PR 4–5 retire items 2 and 3 together (a renter never hears two confirmations, nor none); PR 7 retires item 4; PR 6 last, for item 7.

Proposed, pending review · Nov 2, 2026 · Opus designer · read-only research: nothing sent, no PR, no setting changed · AppFolio behavior read from real Situs cards on Nov 2

1. One-pager

Decide (yes / hold):

• Ship phase 1 as fixes, no switch? Recommend yes.
• Build phase 2 behind a company setting, default off, and turn it on at Situs after the Willows run? Recommend yes.
• On a tour staff booked, Clara sends her own confirmation only when AppFolio's did not go, puts it on the host's calendar unless an event already sits there, and emails the host only when someone else booked it for them (a card note either way)? Recommend yes.
• Clara asks a renter to confirm only where AppFolio does not: her own tours once a Willows run confirms what card 9022 shows (AppFolio sent nothing before the tour), and staff tours only when the confirm box was unticked. Otherwise she reads the CONFIRM or DENY reply? Recommend yes.
• Clara picks up a staff-started thread after 15 minutes of renter waiting in business hours (5 after hours), as a setting, default off? Recommend yes.
• Situs switches AppFolio's messages off in the order of the table below? Recommend yes.

North star: AppFolio's seven automatic messages, each replaced

Wording is AppFolio's own, from real Situs cards (October). Coverage counts Situs renters, not code paths: "live in code" is not "live at Situs". On the one Clara-booked card checked (9022), none of AppFolio's messages before the tour fired; its thanks email was not yet due. At Western Slope AppFolio did send that email, under Clara's name, for a showing we wrote (Oct 18).

Stays on: the showing notice to current residents (ticked by default on the form) and AppFolio's application email.

2. The journey, with every way in

Clara can enter at any state. Numbers on the picture match the table.

3. Temporal: one tour workflow from any state

Two parts. A start state in the workflow input, used only by the import (phase 2, behind its setting). And a catch-up check in every step, which is the fix: a late start, retry or replay skips a moment that has passed, and nothing new fires. So the workflow PR merges alone; its replay lists every open run that differs.

4. Data model

Core code reads only these neutral fields. AppFolio names stay in the adapter. Today's Tour.af field, an AppFolio name in core, becomes outside.

A showing whose home does not map still imports at the company, in the company's time zone, and the host is asked which home. A missing property never drops it.

5. Who goes first, and joining late

At Situs, staff or the VA answered first in 36 of 47 text threads since Oct 20 (median 9 minutes). Clara keeps going first on new leads. Once a person has the thread, these rules apply. They extend today's follow-up check and first-touch decision; no second engine.

Proof: replay the 47 Situs threads. Count where Clara would have spoken; the bar is zero times within 5 minutes after a staff reply.

6. What Western Slope told us

Since September their staff act first, by hand: they book in AppFolio or by phone, call leads Clara is working, and own any thread they step into. Clara does not see it, so she starts over or repeats. Quotes are raw transcript lines; a speaker is named only where the transcript names one.

7. How often each way in happens (Situs)

Order by frequency: staff-booked showings first, then staff-first threads, then moves and cancels, then late email joins.

8. Risks and double messages

9. PR cut and proof ladder

This page cuts seven PRs in three provable units. About ten more live on the sibling pages and are not re-cut here.

Referenced, not cut here: confirm-or-cancel (on this page; unlocks message 3), staff tour move acceptance (4 PRs, Proposed Nov 1), group email threads (3 PRs, VA POCs page). The staff-booked showings page, when it lands, owns PRs 3 to 5; whichever cut it settles wins.

Ladder for every unit: replay of real Situs records → Willows live run on AppFolio's test property → sandbox company in the centralized shape (new capabilities only) → Situs switches off the matching AppFolio message.