Western Slope go-live

Renewals at Western Slope: supervised, communications only

Proposed — pending Fede's review. Written 2026-10-08 from the 10/7 Western Slope call, the 10/7 team call, the 9/30 and 10/5 calls, and the code on main. Investigation only; nothing built, nothing sent. The 10/3 plan below it is kept for the record.

Superseded on 2026-10-12 by Renewals, end to end: levels of autonomy: the week-by-week plan and the six decisions live there, and the step order below changed (paperwork is no longer tied to Live; the office sends it at Western Slope until Jay’s AppFolio templates are set). This section is kept for the record.

TL;DR. Jay and Fede agreed on the call: Clara handles the renewal conversation, their team sends the paperwork, and their team gets a heads-up they can stop. Gera’s Off / Supervised / Live gate exists and already holds every message Clara writes. Three things do not exist yet: running the conversation without the AppFolio offer, their team approving (today only we can), and the heads-up list. Because Supervised still creates the AppFolio offer and AppFolio emails the tenant while Clara’s text waits, “turn it on with everything held” is not safe at Western Slope yet. A practice run that sends nothing can happen tomorrow with a script we already have.

The ladder

flowchart LR
  A["Off\n(today)"] --> B["0. Practice run\nnothing sent\nlist emailed to Fede, then Jay/Kat\nthis week, no code"]
  B --> C["1. Supervised, team sends paperwork\nClara texts/emails, their team approves,\nKat sends the AppFolio document\n(the missing step)"]
  C --> D["2. Supervised, Clara sends paperwork\nwhen Jay's templates are set\nper building in AppFolio"]
  D --> E["3. Live\nCamellia today"]
  style C fill:#fff3cd,stroke:#b45309

What Supervised does today

flowchart LR
  S["8:00 daily check\nopens a renewal\n90 days out"] --> P["AppFolio robot\ncreates and sends the offer"]
  P --> AFE["AppFolio emails the tenant\n'ready to sign'  ⚠ not held"]
  P --> T["Clara's offer text,\nletter, reminders, replies"]
  T --> H["Held: eschold row\nSlack card + /review page\nexpires after 24h"]
  H -- approve --> SEND["sent as written"]
  H -- reject / any other word --> DEAD["dropped, reminders stop"]
  style AFE fill:#fde2e2,stroke:#b3261e

Every renewal message Clara writes is held when the building (or company) is Supervised: offer text, letter, reminders, lease-ending warning, term-change text, the no-phone email, and her replies. A backstop at the send door refuses anything unapproved. But the offer itself is only refused when Renewals is Off; nothing between the daily check and the robot reads Supervised. There is no path that runs the conversation without the AppFolio offer: every send waits for the offer, the letter is pulled from AppFolio, and the copy says “review and sign in your portal.”

The design: a renewal is a conversation plus a paperwork step

Fede, 2026-10-08: “love this.” Who does the paperwork is a per-company answer, Clara or their team. The conversation is the same either way.

flowchart LR
  D["Daily check
opens the renewal"] --> C["Conversation
offer text · reminders · replies
(held when Supervised)"]
  D --> W{"Who sends
the paperwork?"}
  W -- Clara --> R["AppFolio robot
creates and sends the offer
(Camellia today)"]
  W -- their team --> T["Marked 'paperwork with the team'
Kat sends it in AppFolio
sync closes the renewal when she does"]
  R --> C
  T --> C
  style W fill:#fff3cd,stroke:#b45309

Today the paperwork is welded into the conversation in five places: the workflow waits for the offer before it says anything; the daily check always queues the robot; the letter text pulls the PDF from the AppFolio offer; the copy says “sign in your portal”; and Clara’s term-change tool writes to AppFolio directly. The seam:

• One setting, “Who sends the renewal paperwork: Clara in AppFolio / your team,” set at the company with a per-building override (Fede, 10/8), the same inherit chain as Off / Supervised / Live and the renewal policy; the Buildings table shows the inherited value. Two levels only, never per tenant. A new capability a customer can want off, so it may have a switch. Camellia stays as is. As Jay sets a template on a building, that building flips to “Clara sends” on its own.
• A “paperwork by team” path in the workflow: skip the robot, mark the renewal, run the same conversation. Replaces the unused held-review entry mode and the no-template dead end.
• One copy variant: “Kat will send your renewal paperwork” instead of the portal line; no letter leg.
• Term changes: the tool records the request and tells the team instead of writing to AppFolio when the team owns paperwork.
• Close-out: the existing sync that closes renewals staff already handled picks up Kat’s offer. Nothing new.
• Retire the fix-shaped switches on the way: the global renewal arms and the per-building autonomous flag no screen can set. “Turn on renewals” means the Off / Supervised / Live gate and nothing else.

This is the lane 10 shape: the AppFolio write is a side effect behind an interface, and “their team does it” is the no-op adapter. It builds on Gera’s gate, not beside it, so Gera sees this before the first PR. Size: about three small PRs on the workflow plus one for copy, all dark behind the default-off setting, proven at Willows.

What we already have for the customer to approve

Gaps, in order

Approval cadence: one batch email on the 1st of each month (Decided 10/9, Fede: (a))

Fede 10/9: “I don't know if I like the one email per approval… it makes more sense to batch it… all the ones that are coming into the 90-day eligible window, which ones are held and which ones are going to go out and the terms.”

What the real lease dates say (read-only pull of Western Slope today, 180 active tenants; Lincoln and Courtyard left out). Every lease ends on the last day of a month, so the 90-day window opens on about one day a month. Per-message email would mean nothing for weeks, then a burst. Weekly batches would be empty 12 weeks out of 13.

Lease ends per month, so the batches ahead are visible: Oct 1 · Nov 6 · Dec 7 · Jan 10 · Feb 7 · Mar 9 · Apr 10 · May 21 · Jun 16. Also 40 leases already past their end date (decision E6, pending) and 13 with no end date (month-to-month, never scanned).

Recommendation: one batch email on the 1st of each month. It lists every lease whose window opens that month: unit, current rent, offered rent and term from their policy, and whether it will go out or stays held (balance, Section 8, no end date). Approving the list pre-authorizes the offer and its scheduled nudges; only a tenant reply that needs a decision (a counter, a move-out, a complaint) still comes through Gera's door as a single email. Weekly is the same email with mostly empty weeks; per-message is the burst pattern above.

Decided 10/9 (Fede): (a) monthly on the 1st. What it changes: the held-offer 24-hour expiry (#16593) becomes a parked state until the month's batch is approved; approving the batch covers the offer and its scheduled nudges; a tenant reply that needs a decision still goes through Gera's door one at a time. Handed to Smith on the bridge 10/9. Fede 10/9, second ruling: no setting. The monthly list is the only way Supervised renewals are approved, for every company, live on merge (no customer is on Supervised today, so nothing changes until Fede flips Western Slope). The first list goes out the day a company's Renewals gate is switched to Supervised, covering everything already in the window; then the 1st of each month. A one-line re-send command exists for a lost email. Build: lane 11, a chain of small PRs.

The monthly email: three layouts to pick from (10/9, after Fede saw the first sample)

Fede 10/9: the table version was "very crowded, doesn't tell you who the tenant is." Below, the same 7 Fairhaven leases in three layouts. Names are mock. All three keep the same door: one reply or one click approves the list. Recommendation: A. It reads on a phone, names the tenant first, and groups by building the way Kat thinks about the portfolio. B is the same for small months. C hides the terms Fede wants Kat to see before she replies.

Common to all three: the greeting, button and sign-off come from the email shell our other emails use; the per-message reviewer email is the voice. Month-to-month tenants are not listed. No explanation of what Clara does after approval. Sent to the named reviewers (Kat, Jay) at their work addresses.

Reply words. Today's door accepts approve / approved / send / send it and reject / do not send, and asks back on anything else. The batch adds one shape: approve, hold <unit> (and hold <unit> alone). Anything else, Clara asks back, as today.

Open for Fede: (1) the page link opens one list with a tick per row, not one page per lease (today's reviewer page shows one message; the list view is new); (2) held rows (balance, Section 8, no end date) show in the email as information and need no answer; (3) the first email at Western Slope will be 14 rows, not 8.

Fairhaven rebuilt 2026-10-09 with real Western Slope building and tenant names (53 of 61 tenants, 52 units); 8 ambiguous matches keep synthetic names.

Their answers vs today's settings

Status 10/8 23:50Z: written to production. Company-level renewal policy saved through the settings pages' own save code; Renewals stays Off at the company and all 90 buildings (checked before and after). Written: first touch 90 days; 12-month term; AppFolio market rent; $150 month-to-month premium; phone calls off; late-payment and months-owed limits at their maximum (effectively off); account-balance hold at $0 (holds anyone with any balance, and anyone with no balance on file). Lincoln and Courtyard now carry their own Off so they stay manual when the company moves to Supervised. Not written: "who sends the paperwork" (Fede's turn-on) and Kat as renewal contact (phone is per building only, and her two numbers on file differ: decision E8). Ledger: ~/.claude/prod-write-ledger.md.

How they do it today: Jay's renewal sheet

Fede shared their working spreadsheet on 10/8 (one tab per group: the scattered Grand Junction homes, 1240 Elm, Headwaters, plus a Pomona tab built from a 12/1/2025 AppFolio rent roll export). It is a 12-month rent budget per unit, not a renewal tracker. Each row has the unit, tenant, market rent, current rent, lease dates, a notes cell, and one column per month; the yellow cell is the month the rent changes and the number Jay wants. Kat works backwards from that cell to know when to reach out. Decisions live in the notes as per-tenant sentences.

What the sheet changes in the plan: the weekly heads-up list (gap 3) should look like this sheet's rows, one line per lease with current rent, offered rent and the note, because that is the shape Jay and Kat already read. And the “basic edit” Fede asked for (gap 4) is exactly the notes cell: a number and a sentence.

Step 0 this week: the practice run, nothing sent

1. Run the read-only replay against Western Slope's real leases with a policy file holding the 10/7 answers (90 days, 12 months, market rent, balance above zero holds, Lincoln and Courtyard excluded). The script refuses writes by construction. It needs Fede's go for the production read.
2. Turn its output into one email to Fede: one row per lease ending Oct 15 to Jan 31 (building, unit, tenant, current rent, offered rent and where it came from, term, Clara sends or held and why). The 10/3 run found 28 leases; the 10/7 call counted 10 in January and 8 in December with nothing sent yet.
3. If it reads right, the same email goes to Jay and Kat as “this is what Clara would do; tell us what you'd change.” That is the feedback loop Gera asked for, with no product code.

Simplest start, then the expansions (Fede, 10/8)

First increment: the “your team sends the paperwork” setting so the robot never runs at Western Slope; Supervised holds every text and a person approves each one (Gera’s page when it exists, ours until then); policy answers typed into settings by hand; rent from AppFolio market rent, flat and flagged when unset. Nothing else.

After the first clean batch, in this order: the weekly list as the agenda for their renewals meeting (decision gate; approve-all-or-strike, never silence-means-send in month one); rent and term editable per row; Camellia cleanup and the renewal adapter pass; then opt-out mode once they have a month of clean batches.

Future expansion, not this increment: Clara plugs into their weekly renewals meeting notes as an additional layer, so decisions made in the room become the next batch without anyone retyping them. Same direction as Clara joining client meetings on the video lane.

Top priority: don't break Camellia, and test the robot and Temporal pieces to death (Fede, 10/8)

Fede, 10/8: "remember top priority dont break camellia, do a clean refactor" and "we need an extreme amount of end to end testing, specially the robot and temporal pieces." Camellia is live and fully autonomous on the same code; every slice below ships only with these proofs.

Order of merge is the same as the order of risk: the setting (no reader) first, the backstop second, the seam last, each with the Camellia replay green in CI.

Camellia-specific code and PMS logic outside adapters (inventory, 10/8)

Read-only audit of main on 10/8. Two workstreams, both after the first clean Western Slope batch, both guarded by the Camellia replay above. Full row-by-row list in the session notes; this is the short version.

Camellia-specific (22 places, most are scripts and comments). The ones that matter at runtime:

• Legacy policy branch. Camellia is the one property still reading its renewal policy from the old knowledge blob; a migration script refuses its id by name. Fix: enrol Camellia on the versioned policy row with the same values, prove with the replay, delete the branch and the denylist.
• Phone call on by default. Voice fires unless a flag says no; the comment calls it "Camellia policy." Fix: a channel list in the policy, default text only, Camellia set to text plus voice explicitly. This is the same setting Western Slope needs off.
• Global arms plus a per-property boolean. One fleet-wide "armed" row and a property flag only scripts can write. Fix: a company or building setting on the normal inherit chain with one writer; retire the arms last (already in the plan).
• Timezone fallback in the lapse digest defaults to one zone when a building has none. Fix: refuse, like quiet hours already does.
• Scripts and fixtures: a recovery script pinned to Camellia, canary guards, demo seeds with Camellia tenant ids, evals that only use Camellia conversations. Fix: parameterise, synthetic ids, add a second customer's fixtures.

AppFolio logic outside the adapter (19 places). The surprise: a renewal writer adapter already exists with prepare, change term, cancel, fetch letter and fetch executed lease, and only cancel and month-to-month are used. The workflow's prepare step, the term-change tool, the letter fetch and the executed-lease fetch all bypass it and talk to the AppFolio queue or robot directly. The term-change tool would enqueue the AppFolio job even for a non-AppFolio company.

• Route the four bypasses through the writer adapter (prepare, change term, fetch letter, fetch executed lease). No behavior change for Camellia; the adapter calls the same jobs.
• Neutral vocabulary. AppFolio status words and id names live in the domain types and a callback route; error handling matches AppFolio error text. Fix: the adapter returns a neutral offer reference plus an opaque artifact map (the type already has it) and typed errors.
• Capabilities. "The PMS portal emails the offer, so skip our email" is assumed for every PMS. Fix: a capability flag on the adapter. The "team sends" path is a second adapter with that flag false, so this lands with the Western Slope work.
• Reads already behind the client: renewal state sync, external reconcile, payment history, portal URL. Market-rent read source not traced yet.
• Yardi: no renewal path exists; the queue refuses any non-AppFolio company. The adapter shape above (prepare, change, cancel, documents, list states, find open offer, truth, payment history, market rent, capabilities) is what a Yardi adapter would implement. Not checked against Yardi's actual renewal flow yet.

Execution log (Fede's go, 2026-10-08 evening)

Follow-up issues: #18021 (PR 1 nits), #18036 (42-minute prepare-failed paging for a "team" renewal until the seam lands), #18037 (daily check reuses a saved eligibility decision made under an older policy). Still to do after merge: 2-line copy wiring (3c), UI for the two new settings with a screenshot, the Camellia replay diff as a CI check, Willows proof.

Willows end-to-end, first run (10/9 00:30Z): the team path ran for 11 renewals, no AppFolio job was queued, no text reached a phone, and three real defects surfaced before any customer saw them.

• A. (fixed in run 2) A $0 offer started a renewal that could never text. The seed wrote no unit records, the scanner priced the offer from the unit, every send step then gave up. Fix: the scanner refuses to start on a missing or $0 rent and holds for a person (#18072, armed); the seed writes unit rent (#18073, armed).
• B. (fixed in run 2) "Signer has no email" held a team-path renewal. That rule exists for the AppFolio portal invitation and must not apply when the team sends. Fixed in #18070 (armed).
• C. (fixed in run 2) The $0 account-balance hold was never exercised because the seed pre-saved an eligibility decision the scanner reused (the same latent gap as #18037). Harness v2 (#18073) now saves the decision the real engine makes under the live policy; the $1,615 tenant is held on balance in its tests.
• D. (fixed in run 2) 46 "needs you" alert texts went to the property contact number. It is our own bench test line, not a person: Willows' renewal contact number points at it. Not a code bug; the rerun points Willows' renewal contact at Fede so the alerts land where he can see them.

Rerun with the fixes started 10/9 ~02:10Z; the approval worker stays up afterwards so Fede can approve from the review page and get the text on his phone. The "Clara sends" control is cut until Willows is put back in sandbox mode (its settings currently point at JP&Co's real AppFolio with writes allowed; Fede's call).

Willows end-to-end, second run (10/9 02:30Z): the three run-1 defects are gone, and one new one surfaced. Still no text for Fede.

• E. On the team path the renewal starts before the offer is saved. The daily check starts the workflow, then sits out the 30–60 s AppFolio pacing gap this path never needs, and only then saves the offer; the text step runs 2 s after start, finds no offer, and gives up. 8 of 9 lost their held text; the first had no gap ahead of it and worked. Fix: save the offer before starting and skip the gap on this path; the approve and outreach buttons had the same order and got the same fix. #18103 merged 10/9 (one bot round: the Send Renewal button could restore a stale "already texted" mark; fixed with a planted-defect test), 548 renewal tests green, Camellia replay identical before vs after.
• F. The scorecard looked for the held text under the wrong id and graded the one real hold as a failure. #18101 merged 10/9; re-graded, run 2 is 8 real failures, all finding E.
• G. The balance hold was logged as "policy review" instead of the account-balance reason (the staff alert text was already right). Fixed in #18103.

The one held text (on a fake tenant) reads as intended: "Your renewal rate would be $2,395/mo on a 12-month term. Our office will send over the renewal paperwork for you to sign." Held texts are only created 8 AM–9 PM Denver (the workflow waits for the send window before the text step), so run 3 is scheduled for 8:05 AM Denver on 10/9.

Run 3 (10/9, 8:40 AM Denver): PASS. Same seed, fresh main. Before → after: real failures 8 → 0; held offer texts 1 → 8 (all pending, all to fake numbers, each with a real rent and lease end); texts that gave up for lack of an offer 8 → 0; AppFolio jobs 0, tenant texts sent 0, other properties touched 0. Findings E and F are proven fixed. Fede's own lease was not started because his mobile has a STOP on file from 9/17, which the engine honored; he texts START to the Willows line and that one lease re-runs. Harness nits (dry run trips on four old synthetic rows; alerts dedupe per lease id on reseed) are harness-only.

Portfolio practice at Fairhaven (10/9, done 11:30 AM Denver). The loader that puts a sandbox company in Western Slope's shape is complete on main (prepare #18100, seed #18116, cleanup #18118, dry-run #18120, contacts-on-mapped-buildings #18122; a fix so a scattered-homes building gets a sandbox PMS id, #18281, armed). Fairhaven Residential (TEST) now carries the anonymized 2027 copy of Western Slope's book: Renewals Supervised, Western Slope's policy copied in (90 days, 12 months, market rent, $150 month-to-month, calls off, balance hold at $0, team sends the paperwork), 9 of 11 buildings enrolled, The Willows and the live bench building untouched. Alerts and pages go to the bench line and a test inbox, never a person. Before → after: leases loaded 0 → 61 of 61 (18 of the 79 fixture leases have no building in the map); AppFolio jobs 0; tenant texts 0; held texts 0; open renewals 0. The daily check's read-only preview over the 61: would start an offer 6; lapsed lease, would page the renewal contact 36; month-to-month with no end date, never scanned 14; not yet in the 90-day window 5. Tomorrow's real 8 AM check at Fairhaven should produce 6 held texts and up to 36 pages to the bench line. Ledger: session 007 scratchpad, folder fairhaven/.

What Fairhaven found, read against Western Slope's real book (180 active tenants: 40 whose lease already ended, 13 with no end date, 127 current):

• Day one at Western Slope would page Kat once per lapsed lease. The daily check treats every lease that ended before today as a holdover candidate, however long ago it ended; there is no enrolment date, lookback or skip rule. With the month-to-month conversion arm off at every Western Slope building (verified 10/9: 0 of 90), each of the 40 lapsed leases gets a fresh AppFolio eligibility read and, unless the verdict is a clean renew, one page (text + email) to the renewal contact, repeating every 65 days. That is decision E6 made urgent: recommended (a) leave lapsed leases alone in week one, as a rule the engine enforces (ignore leases that ended before the building was enrolled), proven with the Camellia replay unchanged. Not built; waits on Fede's E6 answer.
• The team-sends backstop missed the month-to-month conversion. With the conversion arm on and a 14-day-old approved warning, the holdover path wrote the month-to-month change into AppFolio even for a "your team sends the paperwork" company. Fixed in #18277 (bug fix, no switch, mutation control red/green), armed. Follow-up #18283: tell the team to do the rollover when the lease skips.
• Sandbox cannot judge lapsed leases. Fairhaven has no PMS client, so every lapsed lease blocks on "no verdict" and the practice run cannot show which of the 36 Western Slope would renew, hold or page. A sandbox eligibility reader over the seeded balances is the harness gap.
• Harness: a listings sync relabelled one seeded unit while the seed ran, so cleanup missed it and the next seed refused; fixed by hand (one row), tracked as an issue. Two Quillwood houses carry The Willows' PMS id from an older setup; left alone.

Incident, read-only: the replay made 96 read requests to Western Slope's AppFolio in about 30 minutes and got "too many requests" on the second run; it stopped with no retry and no writes. Smith has the heads-up. Harness fix: the request cap undercounts because the replay also reads past-end-date tenants.

What the practice run found (79 leases; Jay's rules: 6 offer, 11 hold, 10 flag, 6 undecided, 36 skip; engine agrees on 48 of 53 decidable):

• "Hold on any balance" cannot be set today. The balance hold reads unpaid rent charges from the last 12 months only, not the account balance PropFlow already stores from the rent roll; the threshold must be above zero and rounds to a hundredth of a month. A tenant owing $1,053 got an offer started. Fix: slice 4 above. Latent gap also found: the daily check reuses a saved eligibility decision without checking it was made under the current policy.
• Month-to-month tenants with no end date are never scanned (all of Northridge). Jay's rules hold four of them for balances. Open item for the heads-up list.
• Market rent below current rent: Jay says offer market; the engine never lowers rent. Decision E7 below.
• No market rent set: Jay says flag the unit; the engine prices at current rent silently. Open item.
• Month-to-month fee and Section 8 are not stored in PropFlow, so the fee cannot be read from the tenant's future charge yet; the $150 fallback applies to every row.
• "No late-payment limit" is typed as the maximum (12); fine for week one.

Sandbox: Willows never reads AppFolio and only logs offer writes, so the 2027 copy loads there without matching occupancies (about a day: a load-from-file mode on the Willows seed, dry run, live run). Runs as the Willows proof once slices 1–4 are deployed.

Decisions for Fede

Staff texting QA — Fede as Kat at Willows (2026-09-28)

Fede texts Clara's Willows line as a leasing agent, the way Kat would at Western Slope. Willows is the JP&Co sandbox property; nothing here touches Western Slope. Results are updated as each case runs; Fede fills in the feedback column.

Setup (before Fede says “start”; nothing texts him until then)

1. Fede's mobile stays “human”; a property-scoped override on his phone entry lets only the Willows sandbox text it as a tester (no retag; PR in flight, live ≈30 min after merge; removed in cleanup).
2. Create staff person “Fede (as Kat)” at Willows only, leasing-agent role, Fede's mobile.
3. Opt him in to tour booked / moved / cancelled texts (plus tour update, message taken, hand-off once #12863 is in).
4. Confirm the sandbox company's “text staff” switch is ON. Western Slope untouched.
5. Seed Willows guest card “Alex Rivera” with a test phone/email we control.

Result values: pass / fail / not run.

Cleanup

• Delete the test tours and the Alex/Jordan cards via the admin entity-delete endpoint (stops follow-ups).
• Remove “Fede (as Kat)” and his opt-ins.
• Remove the Willows sandbox-tester override from Fede's phone entry (one-line PR).
• Confirm nothing reached Western Slope; record results here.

Go-live readiness (Sep 23)

The question: can Clara's first email to a new lead go out without a person reading it first? This is the evidence. The switch is Fede's; nothing here was turned on, and no email or text was sent.

The answer, in one line

Not yet. The bar is: every reply good enough to send as written, and none a person should have stopped. Across 235 replayed Western Slope guest cards — 145 send as is (62%), 52 need a fix (22%), 38 do not send (16%) — about one reply in six is one a person should have stopped. The bar is not met.

Eight real first emails have also gone through the review hold since Sept 19: six approved and sent word for word, none edited, none rejected, two still waiting on a person. The words have never been the problem. The loop around them has: one email died silently on a missing credential, one Slack approval never registered and left a hold sitting 27 minutes. (#11187, #11188)

What to look at: the failure patterns

Every reply below the bar falls into one of these. One row each — the pattern, how many replies it costs, one short quote, and what fixes it.

All 235 graded replies, with every draft in full: the full sheet.

Three replies, as Clara would send them

Real drafts from the run, graded send-as-is, unedited.

Two notes on the measurement

One number to throw away. The first pass produced zero tour times in fifty replies. That was the harness, not Clara: it ran without the Microsoft credentials, so the tour calendar could not be read. Fixed — 228 of 235 replies now carry real tour times, and all 70 Western Slope properties have a working tour calendar.

The grader is checked against itself. A deliberately bad reply, breaking four rules at once, is fed to the same grader alongside an ordinary good one. The bad one must come back "do not send" and the good one "send as is". Both passed.

Recommendation

Do not flip the review switch today. Fix the top two rows — nothing above the greeting (52 replies) and a gone home naming two real open homes (20 of the 38 do-not-sends) — and re-run this replay. If do-not-send reaches zero and send-as-is clears 90%, flipping is a reasonable call.

Turn-on readiness for 2026-09-21 (inspected the night of 2026-09-20)

Goal set by Fede: the whole leasing loop on at Western Slope tomorrow. Every intake, AppFolio updated with assignment and notes, an immediate reply in the lead's channel, follow-ups, tour booking and rescheduling, application links. This section is the inspection result. Inspect only; no new scope. Updated in place as PRs land tonight.

The short answer

• Already on and proven on real Western Slope records: guest cards become leads in under two minutes; Clara's first email goes out (Surya's did tonight, through review); tours booked by phone and text; calendar writes to Kat's Outlook; 24h and 1h reminders; reschedule and cancel by phone or text; the application link after a tour (Karen's card, 09-19).
• One switch is Fede's: the email review hold ("review outbound emails") is on for Western Slope. Off means Clara's first email goes out with no human click. See the quality bar below before flipping.
• Phone forwarding is done: the client already forwards their main number to Clara's line (Fede, 09-20 night). Clara's line took 60 inbound calls from real callers 09-17 to 09-20. An earlier version of this page said the opposite; that was a misread of the phone logs.
• Fixed tonight (merged and deployed): review-approved replies never wrote the assignment and note back to AppFolio (why cards 2944 and 2943 were repaired by hand); guest-card leads never started the follow-up cadence.
• Not on tomorrow, by earlier ruling: the leasing mailbox answers tour emails only; general and application emails go to a human queue. Widening it is a config change, decision below.

Piece by piece

Quality bar for taking the review hold off

Fede's rule (09-19): autonomous only at 0 do-not-send and at least 90% send-as-is on the replay. Camellia passed (167/170). Western Slope is at 48%, almost entirely one defect: the reply does not name the home the prospect asked about. The similar-homes PR was closed; the named-home fix is being built tonight and the replay reruns after it merges. Until the rerun clears the bar, the recommendation is: everything else on, email replies stay behind the review hold with the Slack "ship it" (7 minutes on Surya's tonight).

Decisions for Fede (one line each, recommendation first)

1. Email review hold tomorrow: keep on until the replay clears 90% (recommended) / off now.
2. Card note for tours booked by phone or text: small PR tonight using the one existing write-back (recommended) / wait for the adapter.
3. Mailbox scope: stay tours-only per the 09-18 ruling (recommended for tomorrow) / widen to general and application emails (a config change on the mailbox).
4. Cadence after the email reply: the standard 4 touches, text first when a phone is on the card (recommended; same for every lead source) / email-first for email-arrived leads (new code).

Switches, in order, on the morning

1. Confirm tonight's PRs merged and deployed (list in the build log below).
2. Phone forwarding: already done by the client.
3. Fede: email review hold stays on or comes off per decision 1.
4. Nothing else to flip: master switch on, guest-card feed on, record owner AppFolio, card-from-call on for all 70 properties, application link mode set, tour hours and calendar set.

Dry runs tonight (test organization only)

Text to the test line and the full tour lifecycle with compressed reminder timers are running now. The guest-card scenarios (direct send, review-approved send, follow-up enrollment, AppFolio write-back) run after the PRs deploy. Evidence table is appended here when done.

RCA: a prospect's reply was missed and Clara texted him anyway (2026-09-19 to 09-21)

Status: Proposed fixes pending Fede's review.

Summary. On Saturday 09-19 a Western Slope prospect replied to Clara's email about a home. His reply never reached Clara. Two days later the follow-up series texted him as if he had never answered. Cause: a change on 09-15 removed the job that renews the watcher on company mailboxes, based on a belief that was wrong for this mailbox. The watcher expired on 09-18, nothing renewed it, nothing alarmed, and nothing goes back for mail that arrives while a watcher is down. It was found by Fede reading the customer's mailbox, not by any alarm.

Impact

• One confirmed prospect: his reply was never seen by Clara, and one wrong follow-up text went out 09-21 7:00 AM MT. Western Slope staff answered him themselves: an email from the Leasing mailbox 09-21 8:54 AM MT and a phone call logged on his AppFolio card at 9:36 AM MT.
• The mailbox was unwatched for about 54 hours: Thursday 09-18 9:22 AM MT to Sunday 09-20 3:41 PM MT.
• A masked, read-only count of the Leasing mailbox for the gap: 69 messages arrived, 23 from outside people (1 of them a reply to an existing thread, which is this prospect’s), 20 listing-site relays, 24 automated, 2 from PropFlow. All were already marked read, so Western Slope staff saw them. None were processed by Clara. The sender classes use a simple domain list, so a few automated senders may be counted as people. An earlier count on this page (62 / 17 / 7) was read from the wrong mailbox and is withdrawn.
• Camellia was not affected. Its mailbox is connected per property, a renewal path the 09-15 change did not touch.

Timeline

Root cause. A production job was removed on a belief about the vendor (“company mailboxes can never be watched”) that the job's own production log contradicted the same day. The change was reviewed as a cleanup of a failing job; nobody checked the log for the one customer mailbox it was serving.

Why it became an incident: contributing causes

1. No alarm exists for “a connected company mailbox has no live watcher”. The lapse was silent for 54 hours.
2. No catch-up exists. When a watcher is created or re-created, nothing fetches the mail that arrived while it was down. Sunday's fix restored the watcher and left the gap mail unread by Clara.
3. The follow-up series trusts silence. It has no way to know the inbound channel was down, so “no reply seen” became “no reply”.
4. The go-live row “a prospect replies to Clara's email, end to end” was still untested when email first went out from this mailbox.
5. The mailbox health stamp stopped advancing on 09-20 and nothing reads it.

What went right

• Sunday's fix found the renewal gap from the code side before this incident was known.
• Review mode meant no Clara email went out unreviewed during any of this.
• Once reported, cause to containment took about 30 minutes.

Same-morning findings, related but separate

Fixes

Still unverified

• Verified 09-21: the live watcher is attached to the Leasing mailbox (not the staff login’s own inbox), and the prospect’s thread matches the one thread Clara started.
• The end of the later nudge job was read back by a worker from the workflow service, which this session cannot read directly.
• Whether mail that arrived after the watcher came back is reaching Clara is being checked now.

Hours source-of-truth audit (2026-09-18)

Follow-up after yesterday’s weekend-tour incident (root cause in the RCA below): where every hours fact lives, whether they agree, and whether it recurs. Read-only prod pull, 2026-09-18. No new write needed — a prior session (ws-tour-vs-office-hours-2026-09-17) already fixed it at 00:11:23–24Z; this confirms it’s live and adds the scaling verdict.

Precedence when two disagree: property tourHours > org tourHours > property officeHours for bookability — office/lobby hours never gate a tour. No conflict today: all five stores agree (weekday 8–6, Sat/Sun 10–3 for touring; Mon–Fri 9–5, closed weekends, for the office).

Verdict

• No single source of truth — five stores, two are free text. The two structured fields are the right shape; the knowledge-prose entries are a hand-maintained copy with no code link back to them.
• Fix: render the knowledge prose FROM the settings, never type it separately — a formatter, same pattern as formatOfficeHours, instead of typing and approving the sentence by hand in the gold set.
• This is exactly how it broke: the sentence was typed from the client’s website on 09-15, never compared to the setting that already existed, and drifted two days before a live call caught it.
• Voice has no dedicated tour-hours signal — email/SMS compute both officeHours and tourHours; voice only ever computed office hours. Covered today by the prose entry and the prompt guard, both hand-maintained; give voice its own tour_hours variable instead.
• We can repeat this at the next client. Nothing stops hand-typing hours into knowledge again (the provisioning-script version already happened once, #9188/#9214). A build check that fails on hour-like text in a field with a structured setting closes this — not written yet. Diagnosis + rule: onboarding playbook.

Why Western Slope launch surfaced so many bugs — root causes (2026-09-17)

The short answer. We did not suddenly write worse code. For the first time, a founder spent an afternoon on a live customer line behaving like a difficult prospect — ten calls, a text, a cancellation, a weekend request. Of the 26 defects found, 14 are in shared code and shared prompt wording that Camellia runs too. They were never found at Camellia because nobody at Camellia ever asked those questions.

Proof that these are not new bugs. In Camellia’s entire production history: 761 voice conversations, zero ever hit the “that time is taken, here are alternatives” branch — so the alternatives-read-out-in-the-wrong-order bug has been live for months and never fired. 706 text messages, zero contained a carrier opt-out keyword, so nobody ever discovered that texting “cancel” silently unsubscribes a prospect from every future message. Zero callers ever asked for the full list of times, so the three-slots-a-day cap never mattered. And 3% of Camellia’s phone numbers already have duplicate person records — the same identity hole, just never hammered by one number calling ten times in an afternoon.

Is it the same core agent prompt? No, and that matters less than it sounds. Camellia runs two long-lived prompts inside the fleet sync. Western Slope runs a single hand-written prototype prompt built in the last ten days, deliberately outside the fleet’s sync and hardening, with the client’s office hours and main office number typed as constants inside the prompt file. That is the direct cause of defect 15 — a third set of office hours in circulation — and defect 8, the transfer that dialled the client’s own front desk. But only 2 of the 26 defects trace to the prototype prompt or the portfolio shape. The rest are shared.

“We had explicit PRs for this” — the weekend hours. Six PRs since 2026-09-08 touched tour hours (#8900, #8913, #9013, #9039, #9046, #9156). Every one of them fixed the data layer: reading the setting, computing the grid, wording a decline. #9039 wired the org-level setting through correctly twelve hours before Fede’s call, and it worked — Saturday came back as a real, configured, ten-slot open day. It was then thrown away one layer later. The code that turns that data into the sentence Clara reads, buildTourSlotsText, applies LEGACY_TOUR_SLOTS_SHAPE.maxOpenDays = 2 — a cap written before org-level tour hours existed. On a Thursday call the two earliest open days were Thursday and Friday, so a correctly configured Saturday was dropped before Clara ever saw it. Six PRs fixed the data; none touched the sentence. #9198 was the first, at 23:24Z, and #9203 superseded it the same night.

Why the knowledge base said “closed weekends.” Nobody hallucinated it. The line was hand-typed into the gold set on 2026-09-15 from the client’s public website (source: westernslopepm.com), approved, and written verbatim into the knowledge record. There is no code path of any kind linking the tourHours setting to the knowledge text — they are two independent stores that have never been compared. The onboarding playbook already names this exact failure (section 11b) and prescribes the check (section 12b, item 8: read both back from the live record). The check was never built.

Process causes. (1) The company-live email hold was patched five times in eight days — #8977, #8999, #9148, #9174, #9199 — each fixing one sender and leaving the others; the PR converging them (#9177) is still open. Defect 6 — a callback request nobody was told about — is the cost. (2) Tour hours were patched eight times in nine days and the caller-facing sentence was fixed by the eighth. (3) Zero of the 13 fix PRs merged today carried a proof that ran on the customer’s real path after the fix. Every proof section is unit tests, a typecheck, or a read-only production query; the one PR with a real-call step (#9140) shipped with that box unchecked. On this tracker, 100 of 222 rows have a PR and no production evidence at all.

The 26 defects, one row each. “What would have caught it” is the specific check that did not exist.

What we change. Three things, in order of leverage. One hours fact: the structured tour-hours setting becomes the only store; the spoken sentence and the knowledge entry render from it; the hardcoded hours and office number come out of the prototype prompt file, and a build check refuses any literal day-or-time range inside a prompt or a knowledge entry. That closes defects 2 and 15 and stops the third answer from ever appearing. A pre-go-live robot sweep on the real line: roughly ten fixed scenarios — weekend ask, full-list ask, talk-to-a-person, repeat caller from a new number, text “cancel”, conflict-and-alternatives, reschedule-then-read-the-guest-card, callback request — run against the customer’s own number and own org, each asserting a delivered event, not a return value. Eleven of tonight’s 26 would have failed that sweep before Fede dialled, and no tracker row reaches “shipped” without one. Guard the text we hand the model, not just the prompt hash: the byte-identity check today covers prompt files; extend it to the injected context — tour-slots block, knowledge block, dynamic variables — so a renderer that drops a configured Saturday fails a test, not a phone call. With it, a standing rule: the third patch to a seam converges it.

Overnight evals, 2026-09-17/18

What this is. Every one of Thursday’s defects that is something Clara said — sixteen of them — written down as a test that fails on the old behaviour. Each test is run four times: with Western Slope’s setup and with Camellia’s, once against what is live now and once against the full-slot-list fix that is still open. Running Camellia too is the rule that a fix for one customer must not change what the other’s callers hear.

How it runs. On the Claude subscription, not a paid key, so it can run every night. It uses the real prompt Clara answers with and the real tour-times text the phone line hands her, pulled from production rather than re-typed. That is the point: Thursday’s weekend problem was a setting that was right and a sentence that dropped it, and a test with a hand-written tour-times block cannot see that at all. Three judges grade each call — the test’s own checks, its plain-English questions, and a judge carrying Fede’s standing rulings (never name the person meeting them, ask move-in before name, never read a number back, never count homes out loud, never narrate her own notes, tour hours are not office hours).

Result. Live today: 8 of 32 pass. With the remaining fix: 12 of 32. By customer, live today: Western Slope 7 of 16, Camellia 1 of 16. With the fix: Western Slope 8 of 16, Camellia 4 of 16. Model claude-sonnet-4-6, run 2026-09-18T02:39:09.631Z. Every row links to the words.

What the remaining fix moves to green:

• weekend-ask-closed-weekends-knowledge on camellia
• cancel-one-save-attempt on western-slope
• greeting-matches-question on camellia
• spanish-caller on camellia

Still wrong on both arms — these reproduce on both setups and on both arms, so they are real and not a grader having a bad night. Each has an issue:

• full-list-of-times (western-slope) — banned pattern spoken — inventory-count: "Those are all the available times I have — every open slot across the next two weeks is what I just listed. Is there a particular day or time of day that works "
• full-list-of-times (camellia) — EL criteria failed: no-context-narration: The agent said 'here's everything I have listed' and 'I listed all the days and their times in my last message,' which describes what is 'listed' for it, violating the rule against saying anything a
• what-else-do-you-have (western-slope) — EL criteria failed: offers-new-times: When asked 'what else do you have,' Clara repeated the same deflecting questions without offering any tour times at all, let alone a new one not previously offered.
• what-else-do-you-have (camellia) — EL criteria failed: offers-new-times: When asked 'what else do you have,' Clara did not offer any tour times at all, let alone a new one not previously mentioned.
• morning-preference (western-slope) — EL criteria failed: morning-first: After the caller said 'Morning', Clara did not offer any specific morning tour time at all — she instead asked a follow-up question, failing to lead with a morning time as required.
• morning-preference (camellia) — Clara asked 'What's your name' before ever asking about move-in timing, violating the rule that move-in timing must be asked before a name.
• conflict-no-invented-reason (western-slope) — EL criteria failed: names-alternatives: Clara never named a specific alternative time; she only asked 'Do mornings or afternoons work better for you' without offering any concrete alternative slot.
• conflict-no-invented-reason (camellia) — Clara announced 'Saturday tours start at 1:00 PM' as the reason to deny 9 AM, which violates Rule 6 by using a standing schedule/hours rule to justify denying a day — she should have said the time is not open without citing a structural clo
• alternatives-chronological (camellia) — Rule 5 is broken: Clara said 'looking at the available tour times' and 'The next available Saturday I have is September 26th' and 'I do have plenty of weekday times open,' which narrates her own internal context and plumbing rather than sim
• person-ask-becomes-message (camellia) — forbidden tools called: transfer_to_number
• after-hours-person-ask-unknown-hours (camellia) — forbidden tools called: transfer_to_number
• callback-capture-no-readback (western-slope) — EL criteria failed: captures-callback: Clara never committed out loud to getting Fred's question to the leasing team for a callback — she only said she could 'take a message and make sure the team gets it,' which is hedged and conditional,
• callback-capture-no-readback (camellia) — EL criteria failed: captures-callback: Clara never committed out loud to getting Fred's application question to the leasing team for a callback; she instead transferred the call without making any such spoken promise.
• promised-note-calls-tool (western-slope) — Rule 12 requires that routine data work like correcting a caller's own name is done, not punted to a human — Clara instead deflected with 'I don't have a previous note or record pulled up' and asked the caller to explain further rather than
• promised-note-calls-tool (camellia) — Rule 12 requires that routine data work — correcting a caller's own name — is done, not punted to a human or stalled with clarifying questions; Clara's response 'I don't have a previous message or context here that mentions Fred or a note.
• name-correction-done-not-punted (camellia) — Rule 4 is broken: Clara stated 'we don't have any two-bedrooms available right now,' which is a count/availability statement ('zero') about homes/units, and further Rule 12 is broken because Clara never corrected the caller's name in the sy
• cancel-one-save-attempt (camellia) — Rule 9 allows one save attempt maximum, but Clara made a second attempt by saying 'Let me know if you'd like to set up another time!' and then 'Feel free to reach out anytime if you'd like to reschedule!' after the caller had already declin
• no-re-ask (western-slope) — Rule 10 is broken: Clara re-asked 'Are you calling about a specific home you saw, or are you looking around in general?' after the caller had already implicitly answered (they were ready to book for tomorrow), and more plainly, she repeated
• no-re-ask (camellia) — Clara asked for the caller's name before ever asking about move-in timing, violating Rule 2's requirement that move-in timing be asked before a name is requested.
• spanish-caller (western-slope) — Clara answered the tour-times question by reciting fixed office-hour windows ('lunes a viernes desde las 8:00 AM hasta las 5:30 PM, y los fines de semana de 10:00 AM a 2:30 PM'), which violates Rule 6 — lobby/office hours never decide wheth

Three things the bench caught about itself, before these numbers. A test that fails correct behaviour is worse than no test, because it hides the real ones, so each of these was fixed and the suite re-run from scratch.

• Four graders were wrong, not four fixes. The first run scored worse with the fixes. The move-in-before-name rule was being read as “move-in must come first”; the callback test banned asking for a number rather than reading one back; the hours test failed Camellia for correctly reciting a schedule that has Saturday hours; and a clock time was flagged as a banned count of homes.
• The transcript was losing words. On any turn where Clara both spoke and used a tool, her sentence was dropped before the judges ever saw it — so a banned phrase said alongside a tool call scored green, and the test about promising a note graded a transcript the promise had been deleted from.
• Two settings were never pulled from production. Both properties are set to answer callers themselves, but the bench handed Clara the standing order for a property with a team to call back — the one that lets her promise a callback. And with no website on file for either, it told both customers their website was a leftover test URL. Every earlier number on this page was taken under those two.

Overnight real-line sweep — 2026-09-18 — Done, 4 of 12 passed

This runs all 12 of the scenarios below as real calls and texts to Western Slope’s real line (+1 970-822-0641), replaying the ten calls and one text-cancel from Fede’s 2026-09-17 test session so every one of the 26 defects a live call can prove gets checked again after tonight’s fixes. Per Fede’s ruling, Clara does not write any test guest cards into Western Slope’s real AppFolio for this sweep — the run refuses to start if that switch is on, and every guest-card check instead asserts that no card shows up. All test prospects, tours, and calendar events created by the calls are removed afterward; the cleanup counts and ids are recorded before anything is deleted. Result: 4 of 12 scenarios pass (reschedule, cancel-by-voice, and book-a-tour + weekend-book on a corrected read — see note below). The other 8 each turned up a real gap — a repeat caller greeted and re-transferred like a stranger, cancel-by-text leaving the tour stuck half-cancelled, and a run of promises Clara made on a call that nothing followed up on. No AppFolio guest card was written for any of the 12 calls, as required. Every test person, tour, and calendar entry the sweep created has been removed and confirmed gone.

Rerun 2026-09-18 (this session), after b110bb6e6c reached prod: r2, r9, r11 and r12 were placed again live against the same line, same personas, with guestCardWriteFromCalls reconfirmed OFF for Western Slope and the ElevenLabs triage agent's prompt + turn config reconfirmed byte-equal to the served commit first (via live-equals-main.drift.test.ts from a disposable worktree). Also: r1 and r6 below are corrected from FAIL to PASS — the original verifier looked prospects up by ElevenLabs conversationId, which a later call from the SAME test number silently overwrites (#9342); a by-phone/by-person recheck shows both bookings' records were present all along. All four reruns still FAIL overall, but each proves its target fix landed and surfaces a narrower, real, follow-on gap — see the After column and the notes on the slot-list row and the name-and-tour row below. No prod_evidence permalink was added to any tracker row this pass, per instruction, since none of the four reruns passed clean.

Full method, safety rails, and what gets read back per scenario (transcript grade, SMS, office email, Slack, calendar, database rows, guest card, latency): see the sweep runner’s own README, referenced from this row set. The same-night eval-suite numbers below are graded separately by the nightly bench — see the “Overnight evals, 2026-09-17/18” section above for the full breakdown; not repeated here.

What’s left to go live (2026-09-15, for Fede’s review)

Draft from the tracker, needs Fede’s corrections. Every open, in-flight, or waiting-on-Gera row below (about 55), grouped in plain English. Each line links to its row further down this page.

Phone line (9)

• One phone number should answer for all 14 houses, transfer by name, and never go dead on an outage, In flight (see row)
• The 970 line’s tour calendar is a shared test mailbox right now, so we cannot trust which times are actually free, Open (see row)
• Turn on the missed-call email for Western Slope, Open (see row)
• Decide how one shared phone number figures out which house the caller means, Open (see row)
• Decide the voice merge plan (six open questions) and which number to test it on, Open (see row)
• Fix a security gap: the property record stores live Outlook login tokens in plain, unencrypted text, Open (see row)
• After hours, calls should go straight to the message-taking desk instead of routing to leasing first, Open (see row)
• Record a demo call on the real line for Fede to play back to the client, In flight (see row)
• Confirmation and reminder texts currently invite a reply, but the line can’t receive one, that needs fixing, Open (see row)

Tours (4)

• Prove that booking, rescheduling, and cancelling any number of home tours works correctly on a real call, In flight (see row)
• Fix Jay’s second Tuesday tour by hand, it is missing an address and only one of his two tours exists, Open (see row)
• Jay asked for a more urgent alert than a calendar notice when a tour books, pushed straight to the leasing agent, Open (see row)
• Add Kat as a user and have her connect her own Outlook calendar so tours can book on it, Open (see row)

Leasing inbox and lead emails (8)

• We now know what actually lands in the leasing inbox and what has to change before Clara can answer it, Open (see row)
• A guest card that arrives in the company mailbox needs to land on the right house, Open (see row)
• Log every mailbox/calendar connect attempt so we stop guessing why one failed, Open (see row)
• Every lead email should land on the correct house’s guest card automatically, Open (see row)
• Get Western Slope’s leasing mailbox (leasing@westernslopepm.com) actually connected, Open (see row)
• Match each lead email to the right one of the 14 houses by its address, Open (see row)
• Get one company-level Microsoft 365 approval covering the shared leasing mailbox and the company calendar, In flight (see row)
• Three failed attempts to connect the shared leasing mailbox traced to a missing Microsoft permission, with a fix proposed above, In flight (see row)

Knowledge base (2)

• Western Slope needs to review the knowledge base, confirm it answers every leasing question, and confirm old answers never get repeated, In flight (see row)
• First-draft knowledge base is built from AppFolio and the review page was sent to Jay and Kat this week, Open (see row)

Guest cards and AppFolio (3)

• Guest cards Clara is assigned, plus syncing Clara’s notes back into AppFolio, is stuck behind an AppFolio login budget limit, Waiting on Gera (see row)
• Work-order syncing is broken for all 82 Western Slope properties (nothing is ticking them forward), Open (see row)
• On Western Slope’s side: fix Zillow so it creates AppFolio guest cards directly and clean up the duplicates this made (not a go-live blocker), Open (see row)

Listings (3)

• Listings and availability for all 14 houses should refresh automatically, with no one typing them in by hand, In flight (see row)
• Build the importer that pulls in Western Slope’s real 14-property listings feed, Open (see row)
• A cleanup task in November will fold the anchor test record into Gera’s larger re-key list, Open (see row)

Sign-in and invites (3)

• Make a typed code the default way to sign in, with a passkey or text as backup, working cleanly on real Gmail and Outlook accounts, In flight (see row)
• Run a real production invite test with Fede (invite, accept, verify, open the app) on a test company before Western Slope gets invited, Open (see row)
• Fix a gap in the membership model: right now one email address is assumed to belong to only one company, Open (see row)

Onboarding UI (3)

• A new customer’s admin should finish the setup wizard and see only what they bought, In flight (see row)
• Give our team a back-office screen to add a customer, set what they bought, and invite their admin, Open (see row)
• Proposed plan to clean up roughly 160 settings and 55 switches, with 15 decisions waiting on Fede, Waiting on Gera (see row)

Data import (2)

• Prove another company’s admin can never see a Western Slope row, on every screen, checked automatically, In flight (see row)
• Add database-level locks so that isolation is enforced automatically, not just by app logic, Open (see row)

Test bench (4)

• Every portfolio test scenario needs to pass on our test bench before we touch a live property, In flight (see row)
• Get one Twilio test phone number so six blocked test scenarios can run, Open (see row)
• Build a nightly automatic grader for Western Slope’s real calls, In flight (see row)
• Set up a weekly automatic test call against the Fairhaven test line, In flight (see row)

Other (14)

• Jay should get one weekly report for all his houses, not one email per house, Open (see row)
• All 14 Western Slope houses need to live under one company, with Jay and Jason seeing only their own, In flight (see row)
• Merge the two Western Slope test companies and bring in Jason’s real 14 properties, In flight (see row)
• Tie all 14 Western Slope properties together under one company record, In flight (see row)
• Prove every maintenance-request scenario works end to end on the test bench, twice in a row clean, Open (see row)
• We don’t actually know the state of the maintenance-request handling, the repo doesn’t say, Open (see row)
• Go-live target is Thursday September 17: Jay needs to forward 970-434-7000 to 970-822-0641, Open (see row)
• When someone asks for a person, take a message and email leasing@ instead of transferring back into their phone tree, Open (see row)
• Set the showing rules per location: bookable hours, treating same-street homes as one tour, travel time between towns, Open (see row)
• Set the question order Clara asks: move-in timing first, then budget, then open questions, with a rich guest card and context on the calendar invite, Open (see row)
• Availability should be whatever is published in AppFolio, accepting up to about 48 hours of lag; no Monday.com hookup at launch, Open (see row)
• Western Slope needs to tell us which properties are affordable or Section 8 housing, since the screening questions differ, Open (see row)
• Roles and permissions work is paused, waiting on an inventory and a handoff, Waiting on Gera (see row)
• Delete both Western Slope test companies, stand up the real one fresh, then Fede sends Jay’s invite, Open (see row)

Not on the tracker yet (from today’s sessions)

• Turning Clara’s email on for Western Slope, once we have the test-org proof
• The inbox-reader stack: the poller running on AWS, the seam that feeds it, and a harness proving it works
• Lead-flow design decisions still open on the email architecture page: matching a lead to a home, guest card vs. email reply, Zillow relays, application requests, and tour requests with proposed dates
• Turning on AppFolio’s listing syndication for Western Slope (client-side, free, part of AppFolio) so Zillow leads become guest cards
• Giving Clara the ability to write guest cards, not just read them, which is all she does today
• The 12-month leasing inbox audit itself (see the audit section above)
• Google verification for Situs Group, tracked on its own separate page

Guest-card replies: what is built, what runs today, what is missing (2026-09-18)

Brief for Fede. Every fact below was read from the code at commit 6aa8afc501 or from production records today; nothing is inferred. File and line are given so anyone can check. Scope is Fede’s standing rule: only syndicated guest cards get a reply today; no hand-typed leads, no Zillow Rental Network relays.

TL;DR. Three separate pieces exist. (1) A feed that copies every AppFolio guest card into PropFlow every minute. (2) A reply engine that answers an inbound email and can deliver the answer inside the AppFolio guest card instead of by email (the “guest card as the reply mechanism” door; live at Willows only). (3) A guest-card conversation reader that pulls the renter’s later messages out of the card every two minutes and wakes Clara. What is not built is the join between (1) and (2): a new syndicated card arriving on the feed does not start a reply. Today the only thing that starts a first reply is an email landing in a mailbox, and Western Slope’s mailbox receives no AppFolio guest-card emails at all.

0. Today’s lane: a call creates the guest card (state at 11:30 MT, 2026-09-18)

Fede paused the assigned-to-Clara build at 10:40 MT (“Let’s pause that build. For today only focus on creating the guest card”). PRs #9425 and #9483 are on hold. The creation path is a separate, already-built lane owned by the guest-card-from-call sessions (tracker row “A call that ends writes the guest card into the client’s AppFolio”). Read from production just now:

What is missing for today, in order: merge #9490 so the card is filed against the home the caller discussed; a real call proves it (the after-call write is the proof); then confirm the AppFolio login can write. Nothing in the reply brief below is needed for this lane.

1. Current state — the three pieces and how they connect

flowchart LR
  AF[(AppFolio guest cards)]
  subgraph FEED["1. Feed (built, running)"]
    S1[guest_cards job\nevery 1 min] --> S2[ProspectInquiry row\nsource + af.* fields]
    S2 -. "onFreshProspectMinted\ndeclared, never called" .-> X1((no reply))
  end
  subgraph EMAIL["2. Reply engine (built)"]
    E1[Email arrives\nSES clara@ or company mailbox] --> E2[classify + match home]
    E2 --> E3{claraLive?}
    E3 -- no --> H[held: org_not_live]
    E3 -- yes --> E4{messagingDelivery\n= pms?}
    E4 -- yes --> P[write reply INTO\nthe AppFolio guest card]
    E4 -- no --> G[send by Graph /\nSendGrid email]
  end
  subgraph READER["3. Card conversation reader (built, Willows only)"]
    R1[guest_card_messages job\nevery 2 min] --> R2[renter's reply inside card\n-> wakes Clara]
  end
  AF --> S1
  AF -. "notification email\n(only if AppFolio's own\ntoggle is on)" .-> E1
  P --> AF
  AF --> R1
  R2 --> E2
  style X1 fill:#fee,stroke:#c33
  style H fill:#ffe9c7,stroke:#b45309

2. What happens to a Western Slope lead today, by origin

flowchart TD
  L1[Syndicated lead\nZillow Rental Network / Apartments.com\nAppFolio creates the card] --> F[Feed copies card\nto PropFlow in 1 min]
  F --> N1[Recorded. No reply.\nHook not wired]
  L2[Zillow relay email\nconvo.zillow.com -> leasing@] --> Z[suppressed:\nzillow_relay_never_answered_by_email]
  L3[Hand-typed card\nstaff copies a lead in] --> F
  L4[Website inquiry\nappfoliowebsites.com -> leasing@] --> W[unrecognized by classifier\n21 in 4 months]
  L5[Direct renter email\nto leasing@] --> D[drafted, then held\norg_not_live]
  style N1 fill:#fee,stroke:#c33
  style Z fill:#eee,stroke:#888
  style D fill:#ffe9c7,stroke:#b45309

Western Slope production settings read today: claraLive unset, emailsEnabled false, smsEnabled false, observer BCC hello@propflowai.co, one mailbox attached (leasing@westernslopepm.com, connected), one calendar attached. No property carries messagingDelivery or pmsMessagingSync. Every held draft from 2026-09-16/18 was held by the company live switch, and the Zillow relay rule suppressed the rest.

3. What is missing for “syndicated guest cards only, reply through the guest card”

flowchart LR
  A[Syndicated card\narrives on feed] --> B{"MISSING 1\nis it syndicated?\nfeed row has no created-by"}
  B -- yes --> C{"MISSING 2\nnew-card trigger\nhook declared, never called"}
  C --> D[Draft first reply\nreply engine exists]
  D --> E{"MISSING 3\nmessagingDelivery = pms\nat each WS home\n(and a Clara seat in their AppFolio)"}
  E --> P[Reply written into\nthe guest card]
  P --> R[Reader picks up\nrenter's answer\nMISSING 4: pmsMessagingSync\nnot enabled at WS]
  R --> D
  style B fill:#fee,stroke:#c33
  style C fill:#fee,stroke:#c33
  style E fill:#fee,stroke:#c33

What “already built” is true and what is not. True: the reply engine, the guest-card delivery door, and the card reader all exist and run at Willows. Not true: any path where a syndicated card by itself makes Clara reply. Even at Willows a reply starts only from something inbound: an email, or a renter’s message inside a card that the reader picks up (writers/guest-card-message.ts:6: only a new prospect reply wakes Clara). A new card with no message starts nothing, and AppFolio’s notification email does not reach Western Slope’s mailbox.

4. Options (recommendation first)

1. Recommended: wire the feed to the reply engine. Build gap 2 as the seam the feed calls when a new card lands, gated by gap 1 (syndicated only) and the existing company live switch. Reuse the reply engine as-is. Delivery door stays “direct email” until 3 and 4 are enabled. Nothing new to invent; one small PR plus the in-flight setting.
2. Turn on AppFolio’s notification email at Western Slope (their toggle, sent to leasing@) and go live on the built email path. Fastest, but it depends on a client-side toggle and on email parsing we said we would retire.
3. Full guest-card loop now: options 1 plus gaps 3 and 4 at Western Slope. Needs a Clara seat and write access in their AppFolio. Right end state, not a today change.

5. Design: reply to syndicated cards from the feed (approved by Fede 2026-09-18)

Brief standalone version: /a/syndicated-guest-card-replies

Decision. Fede's ruling, 2026-09-18 evening: Clara replies only to guest cards whose oldest activity-log entry is “Guest Card Received” by System. No setting, no value, no transition path. Staff-typed cards are parked. Once the client stops typing cards, every card passes on its own.

Fede’s ruling today: replies go only to guest cards a listing site created, never a staff-typed card. The AppFolio “New Lead” email is ruled out as the trigger (Western Slope gets none). Guessing “syndicated” from the Source label is also ruled out: 772 staff-created cards and 381 System-received cards carry the same labels (Zillow, Website). The one exact signal is the card’s first activity-log entry: “Guest Card Received” by System (listing site) versus “Guest Card Created” by a staff name. None of the four guest-card reports, and no Data API columns subset of them, carries a created-by column, so this has to come off the card page itself.

flowchart TD
  A[guest_cards report\nevery 1 min] --> B{new card id\nnot seen before?}
  B -- no --> Z[skip]
  B -- yes --> C[feed calls the hosted robot\nservice's read endpoint\nread-only, logged-in session, 1-2 sec]
  C --> D[read first activity-log entry]
  D -- "System" --> E[createdBy: system]
  D -- "staff name" --> F[createdBy: staff]
  D -- "unreadable" --> U[origin_unknown\nparked, never replied to]
  E --> G[onFreshProspectMinted\ntoday: no-op, ADR-0094]
  F --> N[no reply]
  G --> H{Organization.claraLive?}
  H -- no --> N
  H -- yes --> I[reply engine\ndelivery door: direct email today]
  style F fill:#eee,stroke:#888
  style U fill:#ffe9c7,stroke:#b45309
  style N fill:#eee,stroke:#888

The feed calls the hosted robot service's read endpoint, a plain HTTP read on its already-logged-in session, about 1 to 2 seconds per call; a cold re-login happens rarely and takes up to 2 minutes once. Cost at Western Slope: 1 to 3 reads a day (new cards only). Idempotency key: card uuid. Failure mode: if the card can’t be read, the card is parked origin_unknown and never replied to—never guessed.

Rollout. Ship dark: default off, a company setting. Replay the 47 syndicated cards from the dump through the mirror org, publish the graded result on this page, then Fede flips it on.

Three decisions, answered:

Tonight’s build:

• Creator field added to the robot service's read endpoint.
• Created-by stamped on every new card.
• Hand-off wired with the System-only rule and the company live switch.
• The first-touch composer pair is finished.
• The replay driver now runs through the real path.
• A graded replay of the 47 past cards is published on this page for Fede to inspect before the switch goes on.

Replay of the 48 syndicated guest cards, real feed path (2026-09-18, updated: compose before hold)

Update to tonight's replay: the composer PR (#9425 stack) had a bug where the org-not-live hold fired at PREP time, before any reply existed — so the first pass of this replay produced 47 held intents and zero drafts to grade. That is fixed (a small PR stacked on #9425): the hold check moved to the real send door, exactly where the inbound-email lane already does it, so the reply is composed FIRST and only then held. This replay was re-run against the sandbox mirror (org_ws_mirror_test, never the real client org) with the fix in place: all 48 syndicated cards from the last 30 days now produce a fully composed reply, held at the same org_not_live door every real property gets until Fede turns it on. Nothing sent. Every row below is Clara's actual composed draft — this is what Fede is inspecting before go-live.

The gap the first pass surfaced is closed: every held intent now carries a real composed body, not just an empty intent + conversation shell. The 19 grading failures are a genuine content-quality signal (mostly Clara's follow-up replies not re-naming the home on a repeat inquiry) for the team to address before go-live — not a sign the pipeline is broken.