Onboarding plan — Western Slope + Situs

Situs is behind Western Slope by design — it's on the slower, "other patterns allowed" track. It also has no company record of its own yet: Yale 25 Station currently sits under JP&Co's company record.

Maintenance intake lane

Definition of done: bench-tested at Willows, then rolled out to Situs. Re-checked 1:00 PM MT against Gera's pull requests from the last 7 days (merged and open): one maintenance fix (#7264, a number-word inside a reply no longer hijacks a stale work-order rating) and nothing on intake itself.

Foundational work

Gera's other open pull requests, outside the maintenance lane: 31 open, oldest from Aug 21 (re-counted 1:20 AM MT Sep 9). Grouped by what they touch — not judged; Fede will ask Gera which of these are still alive and worth keeping open.

Gera merged 35 pull requests across Sep 8 in Mountain time (midnight to midnight; the figure of 19 that stood here was a count taken at 1:00 PM, before the afternoon and evening) — most were fixes keeping the shared build pipeline green after a red spell on main, plus the Settings work: company admins manage their own team (#7339) and the five platform-wide switches are staff-only on write (#7365, so a customer role can no longer silence every customer's texting from a browser console).

A note on "merged" in this table. GitHub can show a pull request as merged when it never reached main — #7428 merged into a feature branch that is not an ancestor of main, and was redone as #7433, which did reach main at 2:47 AM. Every row here that says merged was checked against main itself, not against GitHub's label — most recently at 3:20 AM MT Sep 9.

Already answered — no action needed

• Preview environments skipping the second sign-in step: Fede picked "override" — built and merged (#7325).
• Whether Clara's knowledge can cross companies: no — separate companies stay fully separate (Fede, Sep 8).
• The plan to keep companies' data fully apart, and who builds step one: approved Sep 8, Gera owns it; it is not yet scheduled. It sat in "Focus now" as an open ask for a day after it was answered.
• Whether Western Slope comes off read-only now that the overnight tenancy program is done: no — it stays read-only, no writes there, the lock stays on (Fede, Sep 9). The dry proof walked each write flow to the blocked save and passed.
• Delete both test companies: done (Ulysses, Riverbend), backups kept. Western Slope consolidation: plan rewritten — the onboarding company survives, prototype hands over the line and knowledge after Tuesday's import; Fede signed, Gera's sign-off pending on the onboarding experience page, plus one answer from him: does anything in ElevenLabs or the call-start webhook carry the sandbox company id?

Defaults being taken — say something only if you disagree

• Jason's invite: goes out Tuesday, after his properties are imported.
• This morning's four tour-booking fixes for the prototype line: proceeding, no go-ahead needed — two merged, one in review, one unverified (see the tracker row).
• The in-hours leasing bridge that dialed their main line and pressed 2: retired from the agent (#7373); the toll-free bridge number still exists at Twilio with nothing pointing at it, and releasing it is a separate step we will record here.

Nothing to do right now

• Main was red 10:02 PM–12:24 AM MT, green for about ninety minutes, then red again from 1:59 AM. #7557 went in at 2:19 AM to remove a proof harness that should not have shipped, and three runs were still in flight at 2:20, so the current state is unsettled. Production is on the 1:41 AM deploy. This page has stopped counting these hour by hour: the shape does not change, and the count on its own reads as flakiness rather than as the specific thing worth fixing. The clearest evidence of the pattern is the fix itself. #7542 is titled "three guards #7527 tripped, and the one that was a real bug", and its first line reads: "#7527 merged green on its own PR and red on main — these three guards run on main and are not in a PR's required set." One merge, three separate guards, none of them able to fail where its author would see it. And one of the three caught something real: an auth-table purge sitting inside the domain table's module, querying an index the domain table does not have. That is the case for and against this arrangement in one PR — the guards find genuine defects, and they find them only after the code is on main. Across yesterday and last night the class now covers five rules: F7, the sensor registry, lib-data-mock-shape, sync-specialists-path-filter and entity-classification, plus the domain-index guard here.
• The F7 guard has now stopped main three times in 21 hours, and every fix was the same one line. #7380 at 3:47 PM Sep 8, #7427 at 1:41 AM Sep 9, and #7442 at 12:59 PM Sep 9. Each added a script under scripts/ that imports the raw Dynamo helpers; each import was legitimate (parking and restoring rows, reading a property to check it is a test property); each was fixed by pinning the file into the F7 exception table — #7397, #7434, #7450 — never by changing the code. Recovery was 13 to 55 minutes each time and nothing Western Slope needs was ever stuck behind one. The pattern is the point: Guard pins runs only after a merge, so the author cannot see it fail, and the guard treats a normal thing for a script to do as a violation by default. The third case is the sharpest — #7442 is itself a safety change, refusing to wipe or reset a property that is not marked as a test property, and it was the guard that broke on it. Main is green now; production deployed 1:21 PM MT.
• The overnight quiet ended at 10:32 AM MT, after seven and three-quarter hours with nothing merged. Main stayed green throughout and production was current the whole time, so none of it was a blockage. #7435 landed at 10:32 and deployed at 10:44.
• Clara sending texts and emails through AppFolio at Situs: still declined (Fede, Sep 3); stays off unless he reopens it.
• About 270 old automated workflows still running from before the Sep 3 switch-over — flagged, nothing broken.
• 46 leftover test identities at Yale — flagged, nothing broken.
• The landing-page prototype is live; outside feedback from Focus Lab is due Monday Sep 14 at 10am — nothing to do until then.
• Sessions 000, 001, and 008 are idle with no lane assigned.

Ground-truth check of Camellia against Western Slope, read straight from the code — not from the brief's assumptions. Paths are relative to ~/.claude/propflowai unless marked as a docs page. Correction to the brief: there is no Prisma schema in this repo — Property and Organization are plain TypeScript interfaces in src/lib/data/types.ts, backed by DynamoDB (table propflow-prod).

1. Listings and availability

Key files: src/lib/domain/leasing/public-listings-sync.ts, src/lib/platform/scrapers/appfolio-public-listings.ts, src/lib/domain/leasing/listings-sync.ts, vercel.json, lambda/appfolio-sync/schedules.json, src/lib/integrations/appfolio/pms-adapter.ts.

2. Inbound guest cards / leads

Key files: agents/clara/lib/email/parse-lead-source.ts, agents/clara/lib/email/process-inbound-message.ts, src/lib/integrations/appfolio/pms-adapter.ts, src/lib/domain/pms/writers/guest-card.ts, docs/adr/0094-appfolio-guest-card-sync.md.

3. Writing guest cards TO AppFolio

A constitutional fact, confirmed repeatedly in the code: AppFolio's official partner API has no write endpoint for guest cards, notes, tasks, or messages — it only writes leads, work orders, showings, and a few billing objects. The only path for anything guest-card-shaped is browser automation that drives AppFolio's own screen, because PropFlow's plan with AppFolio has no API access for this at all.

Bottom line for Camellia: zero AppFolio guest-card writes happen today. Camellia's guest-card interaction with AppFolio is 100% read (the Data API report). The write-back capability exists in code and is proven, but is switched on nowhere except the internal Willows test property.

4. Tours

Key files: src/lib/domain/calendar/provider/{types,resolve,outlook,google}.ts, src/lib/domain/calendar/sync-tour.ts, agents/clara/lib/agent/tools-leasing.ts, src/app/api/integrations/outlook/{authorize,callback}/route.ts.

5. Email and SMS channels

Key files: src/lib/integrations/email/property-graph-sender.ts, src/lib/integrations/email/client.ts, agents/clara/lib/email/inbox-client.ts, agents/clara/lib/messaging/{dispatcher,resolve-carrier}.ts, agents/clara/lib/messaging/adapters/twilio-sms.ts, config/phone-registry.json.

6. Knowledge base

Model: a PropertyKnowledge record (website/tour links, amenities, concessions, pricing details, office hours, holiday policy, neighborhood, utilities, plus free-text notes for anything the structured fields can't hold). Filled in through an admin screen. There is no "overnight onboarding fleet" in this repo — that claim doesn't hold up; the closest things are a generic onboarding wizard and an AppFolio-specific importer, neither used for Western Slope. Western Slope's knowledge was hand-written directly into the provisioning script.

There's no hard schema gate for "minimum knowledge to go live" — the real mechanism is a per-field readiness check run on every call. If a field isn't ready, Clara doesn't proactively state it and falls back to a live lookup instead of guessing.

Western Slope's current gaps, called out directly in the code (not on a tracker or Trello card — none found): no structured pet policy, empty amenities list, security deposit left as prose because it varies per unit, and office hours that can't represent the Monday lunch closure so it's described in free text instead.

7. Per-property switches for "live"

Field reference: the Property/Organization interfaces in src/lib/data/types.ts, DynamoDB-backed, not Prisma.

How Western Slope was provisioned: two separate mechanisms — a merge-triggered workflow that provisions the ElevenLabs voice agent only (prompt, knowledge base, tool bindings, phone assignment), and a separate hand-run script that sets the actual Property/Organization database row. These are not the same pipeline.

What Western Slope explicitly does not have, by design: still marked test/sandbox, escalation and PM email routed to Fede not the client, no PMS write-back, no autonomous renewal/turnover/listing-publish, and not in the shared production ElevenLabs fleet file — it deploys only through its own dedicated workflow.

8. Easy-to-forget go-live items

• Twilio webhook targets: no script in the repo sets the voice/SMS webhook URLs on either property's main line — the only script that touches Twilio webhooks wires the 3 transfer-bridge numbers only, never the main line. Camellia's and Western Slope's main-line Twilio console values are live data, not in the repo — presumably set by hand or implicitly by the ElevenLabs number-import step.
• ElevenLabs number import: the canonical phone registry auto-syncs on every push to main, with a drift check. Camellia is in it. Western Slope is deliberately not in it — its agent deploys only through its own dedicated workflow, by design.
• Org resolution: a hardcoded number-to-property map plus a live per-property number cache resolve a call/SMS to a property; a separate lookup resolves property to company.
• Escalation vs. missed-call recipient: two intentionally separate resolvers — one for renewal/PM-reminder notices, one for missed-call/staff paging. Both point at fede@propflowai.co for Western Slope; Camellia's point at its own mailbox.
• Cron jobs: all 38 crons are global — none are scheduled per-property; each handler decides per-property internally. The one that matters most for Western Slope's go-live is the 15-minute listings sync. Camellia doesn't use that path (it has a real PMS instead).
• Sentry: global, DSN-based only — no per-property setup needed at go-live.

9. Direct guest-card ingest from AppFolio (no email dependency)

Two distinct mechanisms exist, and they're commonly conflated:

1. Guest-card lead ingest — built, running, broad. This is what actually creates a prospect record directly from AppFolio with no email involved, using AppFolio's official Data API guest-cards report — a normal authenticated REST call, not browser automation, so it needs the AppFolio API key (the same key as the rent-roll sync in §1). Ingested cards are observational only — no auto-enrollment in outreach, for consent reasons; a PM has to act on them.
2. Guest-card message ingest ("reads AppFolio Messages") — built, opt-in, Willows only. This reads message threads off a guest card via the browser-automation session — the actual write-capable rail, gated by a property setting that's only on at the Willows today.

Ownership: the whole read/write browser-automation strategy is attributed to Fede in the source document, not Gera. The "first contact writes a guest card" gap (§3 above) — which is owned by Gera — is a different, currently not-built capability: creating a brand-new guest card, not reading an existing one's report or messages. Don't conflate the two.

Contrast with today's email path: the email-notification parser (§2, path A) is what Camellia actually relies on for its ILS leads today; the Data API guest-card report runs in parallel as a second, independent, non-email lead source that's already live — it needs an API key but not browser-automation credentials. Western Slope has neither, since it has no AppFolio account at all.

10. The full AppFolio messaging loop (Situs's ask)

Important caveat: for email specifically, AppFolio does not file a prospect's emailed reply on the guest card — it forwards it to the sending mailbox. So for email, the connected mailbox is the real inbound door, and the guest-card feed only matters for texts. This is account-config-dependent, not universal.

Gaps, plainly: the entire write-and-detect loop is real, tested, working code — but it's switched on at exactly one property in all of production, the internal Willows test line. Nothing in AppFolio's official partner API supports any of this at all; every bit of it depends on holding a logged-in AppFolio browser session for that account.

11. Fede's proposed simple mode for Western Slope (own mailbox + own Twilio, AppFolio read-only)

Is this already how Camellia works today? Yes.

• Email: Camellia's outbound is sent as camelliaapts@jp-co.com through its own connected mailbox — SendGrid is only a break-glass fallback if that fails. Not through AppFolio.
• SMS: Camellia's outbound is Twilio, from its own number — there is one outbound channel, and it only routes through AppFolio if a property is explicitly flipped to AppFolio-delivery, which is set on exactly one property (the Willows), not Camellia.
• AppFolio today, for Camellia: read-only — rent roll, guest-card lead ingest, and the public-listings overlay. Zero AppFolio writes happen for Camellia (see §3).

So: Camellia is already living in exactly the mode Fede is proposing for Western Slope — reply via its own mailbox and its own Twilio number, AppFolio read-only. This isn't a new mode to build; it's the existing default for every property that isn't explicitly flipped to AppFolio-delivery (today, that's nobody except the Willows).

What Western Slope is missing to reach that same state:

• SMS: nothing — the 970 line's SMS webhook already points at the same production Twilio handler Camellia uses. Already done.
• Email: the mailbox isn't connected yet. This is the one real gap: someone with Western Slope's mailbox credentials needs to complete the standard, one-time sign-in. No code work — it's a one-time click-through.
• AppFolio stays read-only automatically — nothing in Western Slope's setup flips it to write mode. No action needed to keep this default.
• Calendar is a separate item from this "simple mode" question but is already connected too — confirmed by a comment in the provisioning script.

UI packages, session 007 (2026-09-08, refreshed 1:05 PM MT): four of the five held drafts are merged and on main — the onboarding wizard (#7304, 9:23 AM MT), property page cleanup (#7311, 9:57 AM MT), customers see only their company's modules with Admin staff-only (#7310, 12:03 PM MT), and previews skipping the second sign-in factor (#7325, 12:24 PM MT). The back-office "Customers" screen (#7313) is the one left: re-greening on current main, then held for Fede's word. Fede's remaining calls: #7313's merge word; where the read-only renewal Autonomy line lives; when to add Situs Group. Done: Ulysses and Riverbend deleted; the two Western Slope companies have a written plan awaiting Gera's and session 006's sign-off. Full state, proof, and test plan: the onboarding experience page, section "Where the UI packages stand".

One page. Eight blocks of work, the dependency between them, and every row of work under its block with a status. Statuses come from merged changes and decisions, not from hand edits. Click a bar to jump to its block; use the filters to see only what is open or waiting on a decision, or only Fede's or Gera's rows. Each row names who owns it and what blocks it, so both engineers work from the same list. Sequencing is a proposal; the team sets the order together.

Owner: Fede (leasing) (reassigned 2026-09-08: Fede owns leasing, Gera owns maintenance) · added 2026-09-07 · confirmed intent with Fede (Slack, Sep 7) · tracked as an open Fede row in block 2 above

Found Sep 7 by texting the Willows line from an unknown number: nothing came back. On a PMS-delivered property, every outgoing text is handed to AppFolio, and AppFolio silently skips any number it has no guest card for. So a first-time texter — or a first-time caller — is unreachable by construction, and that is exactly the person a leasing line exists for.

The rule this section pins: a number the PMS has never heard of that texts or calls a PMS-delivered property becomes a new prospect, and we write the guest card, so the PMS can text them back. Fede (leasing) owns building it.

Confirmed gap, not a regression. Fede, same day (Sep 7): "i didnt add this new prospect -> new guest card logic" — so this logic never existed; it is net-new work, not something that broke. And "same would apply to a new phone call, we should write a guest card" — a first-time caller gets the same treatment as a first-time texter. Context: the find, in Slack · #7274 (stopgap: bench codes answer over Twilio for registered teammates, whatever the delivery setting).

Lane: Clara sends and reads texts and emails through the PMS · session 002 · updated 2026-09-08 · nothing here is on at a customer

Why this lane exists. Situs asked that Clara's texts and emails be written back into AppFolio, and agreed Clara can act as a named AppFolio user. So a property can be set to hand Clara's messages to the PMS instead of sending them from our own lines. Western Slope does not need this in week one: its leasing v1 runs from the mailbox (section 8).

Live today: only at the Willows test property. Checked on the production database this morning: exactly one property carries the setting, and it is the Willows. No customer property sends or reads through AppFolio.

Built and merged Sep 3–4, off by default at every property:

• A per-property setting chooses "our lines" or "through the PMS". It fails closed to our lines when anything is missing.
• Texts and emails go out from the guest card under Clara's AppFolio seat. Every door still runs the texting compliance check first.
• Guest-card threads are read back into PropFlow conversations every two minutes. Messages a teammate sent inside AppFolio show as "Sent by <name> in AppFolio".
• Once a human teammate replies on a thread, Clara stops replying on that thread. This binds on both her text and email doors.
• Proven live at the Willows Sep 3: a prospect's text came back answered through AppFolio in 1 minute 38 seconds; an email in 54 seconds.
• A regression harness for the whole loop, teammates included, runs hermetically on every pull request; a live mode is allow-listed to the Willows.
• Sep 7: teammates using the bench test menu at a PMS-delivered property get their replies over our own line, so the Willows stays testable either way.

Pending, no decision needed:

• First contact from an unknown number writes a guest card — the section above; Fede (leasing) owns it. Until then a first-time texter or caller at a PMS-delivered property gets no reply.
• The "teammate replied, Clara stops" rule has not been proven with a real second seat. We hold only Clara's seat; proving it needs one more AppFolio login.
• Reading back is a two-minute poll that walks card by card. Before Situs scale it has to read the inbox instead.
• On the JP AppFolio account, a prospect's email reply to an AppFolio-sent email is forwarded to the seat's mailbox rather than filed on the card, so it arrives on the mailbox path. The Situs export does show filed replies, so it is per account. Confirm on Situs's account before relying on it.
• Situs's AppFolio access stays read-only. Their guest cards are not written until Fede says so.

Needs Fede (recorded, not being re-asked):

• Turning this on at Situs. Fede, Sep 3: "no we wont turn on yet." Decision D-H on the Situs hub page stays open until he brings it up.
• Which thread a reply lands on when one person has an old escalated thread and a newer active one: today the older escalated one wins. Options belong on the Situs hub page; not fixed.

Related from the same session, live at Camellia since Sep 5: AppFolio rental applications with no phone and no email now import instead of being silently dropped, and their contact details attach later when the office adds them. It matters for any AppFolio-synced client. Still open: the guest-card importer drops contact-less cards, and there is no reader for AppFolio's application or screening emails.

This section is the audit's evidence and a recommendation for the binding-mechanism half of X1. The architecture itself, including the org, group and property rungs, is being decided on the portfolio architecture options page. Nothing here is decided.

Proven Sep 6, 7:33 AM: the prototype line died in one second because its booking tools required a property at pickup and a company line has none. Three options were evaluated the same day with five audits (470 cited rows), two proofs of concept on branches (never merged, never provisioned; pull requests closed pending X1), and a reproduction harness. Reports: voice · text and email · leasing · renewals, maintenance, turnovers · data model and settings · Gera's portfolio work · proof A · proof B · harness · how Situs is set up.

This audit's recommendation into X1: A, with C kept only for the prototype demo, and B's one good idea folded in (the org-scoped address resolver, which A already has). Reason in one line: A finishes a migration the codebase is already halfway through, and B invents a storage primitive to avoid finishing it. Out of scope for now: renewals and turnovers. The audit covered them for completeness (39 rows, zero critical for the first version) and they are not on the roadmap. Two things are outside all three options and need their own rows on the roadmap: work orders can be written into the wrong customer's AppFolio (account id dropped between the queue gate and the runner), and nothing knows two homes are far apart.

What was proven today, and what was not. Proven: both shapes work at the code layer with red-before/green-after tests; Camellia's single-property path is unchanged in both; the harness reproduces 22 assumptions red on today's code, including a real cross-company bind at pickup for a person who exists at two companies. Not proven: any live call on either shape; the prompt that asks "which home?"; mid-call context refresh on the voice platform. The harness's six robot-call scenarios wait on a portfolio test line, which is a purchase.

Decisions for the team are listed once, in section 12 (X1, X7, X8, X9), not here. In short: (1) the binding shape, inside X1. (2) Approve one Twilio voice number for the portfolio test line — done Sep 7: +1 720-807-1724 bought and registered under Fede's standing approval for numbers (#7285); the ElevenLabs import and the six robot runs are the remaining work, not a decision. (3) Should the harness's red view get a nightly slot? (4) Ruling on knowledge: today the code guarantees what Clara learns at one building never surfaces at another; the vision promises compounding. Company-level knowledge needs one of: company facts shared, home facts isolated (recommended); everything isolated; everything shared.

Line: +1 970-822-0641 · updated Tuesday 2026-09-08, 8:40 AM, refreshed 1:05 PM MT from the merged pull requests · verified against the live agent this morning, not from memory · rows tracked in block 0 above

Live now (read back from the agent at 8:30 AM). Since Monday afternoon the line runs on real AppFolio data instead of Saturday's hand-captured sheet: a live listings lookup plus the three production tour tools (book, reschedule, cancel), so a tour request writes a real tour and a real guest card against the home the prospect asked about; the call-start hook that feeds those tools is on. Kept from the weekend's rounds and still in the prompt: fast qualification (answer once bedrooms, area, and budget are known), at most two homes per answer, no counts or bedroom-mix recitals, neighborhoods only as labels, caller ID used silently, no volunteered missing fields, Spanish end to end, maintenance transferred to Western Slope's 24/7 maintenance line (English or Spanish leg), closed-hours "talk to a person" takes a message, in-hours "talk to a person" transferred to their leasing desk through our bridge that dials the main line and presses 2 (probe-verified after hours) — superseded at 12:40 PM MT, see "Built and shipped dark" below. Overnight, session 008 shipped and confirmed on the live agent: the "re-read the caller when a turn times out" setting the fleet got on Sep 4 (root cause of Jay's 9-second silences and repeats), two same-street homes booked as one visit instead of two an hour apart, a booking bug that silently dropped the second home, and the expired Labor Day reminder removed.

Not on, by decision. Inbound texting on the line (off until the remaining cross-company lookups are closed: 20 open sites, counted by a guard that fails the build if one is added).

Needs Fede: nothing. Per today's rule (go-aheads and scheduling are defaults, not decisions), the four follow-ups above are in progress. The in-hours leasing-transfer test is cancelled and the leasing bridge is retired at forwarding go-live: once Western Slope forwards their main line to Clara, a bridge that dials that main line and presses 2 would loop back into Clara. The replacement is direct lines from the team directory Jason is sending (names, direct numbers, roles): "talk to a person" during office hours will transfer to a direct number read from the property record, shipped dark, with message-taking as the behavior until the record carries a number. No customer contact from us.

Built and shipped dark, 2026-09-08 — the replacement transfer. The change described in the paragraph above is now in the code, switched off. During office hours, a caller who asks for a person on a leasing or general matter is put through to a direct desk number kept on the property's own record, instead of through our number that dials their main line and presses 2. That old bridge is gone from the phone agent, because it stops working the day Western Slope forwards their main line to Clara: dialing that line would hand the caller straight back to Clara. The number itself is still set up at our phone provider and nothing points at it, so no caller can reach it; switching it off for good is a separate step we will record when we take it. The desk number is deliberately left blank right now, and [Corrected 2026-09-09, 10:25 PM MT: until tonight that message reached nobody. #7497, merged 9:29 PM, binds it to the existing missed-call email path so it goes to the address the property's contact setting names — the same path Camellia uses, no new tool or sender. It is shipped dark and must stay dark until Fede says otherwise; merging it re-provisions the live 970 agent automatically. And it was not the only such path: #7535, merged 11:29 PM, found the same hole after hours — a caller asks for a person, Clara promises the team will get back, the system tries to page a human, the page fails, and the promise reaches nobody. That one is now emailed too, also dark. So on both sides of the office day, "we'll get your message to the team" was a promise the system could not keep, on two independent paths, found four hours apart. The same change also removes the in-hours transfer into Western Slope's own leasing tree, per Fede's ruling. The maintenance transfer is untouched.] blank is a safe, designed state rather than a gap: with no number on the record the transfer cannot happen, and a caller who asks for a person during office hours is told the true, warm thing — "I'll get your message to the team right now, they're in the office until four" (until three on a Friday) — and Clara takes the message. She never says she is unable to transfer them, and she never mentions a desk line or a number to a caller. Everything else is unchanged: maintenance still transfers around the clock, and outside office hours it is still a message. How the number gets set once Jason's directory arrives: we pick the leasing desk's direct line out of the team directory (names, direct numbers, roles) and write it onto the Western Slope property record with the existing setup script — it prints what it would do first and only writes when told to, and it refuses anything that is not a properly formatted phone number. It must be a direct line that rings a desk, never their published main line, or the loop comes back. Writing that number changes what a real caller hears, so it is a switch-on that waits for Fede's explicit go and gets its own line on this page — not part of shipping the code. Verified on the live phone agent the same afternoon: the only two numbers it dials are the two maintenance lines, the third destination is now the property record's desk number, the old bridge number is gone from the agent entirely, and the greeting is word for word what it was. Two things to check before the number is switched on, not after: first, make one test call once a number is on the record and confirm the transfer actually happens — this is the first time we have made a transfer depend on a value read at call time, and if the phone vendor does not fill that value in the way we expect, the transfer would quietly never fire (today that failure is harmless, because it means a message gets taken). Second, Clara still reads their main number, 970-434-7000, out loud in three places as a fallback when a transfer fails; once that line is forwarded to her, reading it out sends the caller back to her, so we need a decision on what she says instead. Done the same day (2026-09-08, #7374 merged 12:56 PM MT): Clara no longer reads their main number out loud anywhere — when a transfer fails she takes the message and says the team will get it, adding when the office is next open if it is closed, verified on the live agent with the greeting and all three transfer destinations unchanged.

Tuesday 2026-09-08, 1:15 PM — follow-ups, and one finding Fede should see. Shipped to the line: streets from the neighborhood list can no longer be quoted as homes (the same hazard was found in six more places and removed; #7368, merged 12:40 PM MT), and the second home a caller books now actually gets booked (#7372, merged 12:31 PM MT); before today the platform remembered "a tour was already booked on this call" without recording which home, so a second booking never reached the database while Clara told the caller both were confirmed. Found by the robot call meant to prove two-home booking. Jay's two Tuesday tour requests from Monday: only one exists in our records, and it carries no address. His call ran before the booking tools were live, so nothing was written during the call; the after-call sweep creates one tour per call and could not match the spoken address. Nobody at Western Slope can see it: no logins for their company yet, the property is flagged as a test property, no calendar event, no AppFolio record. If those had been real prospects, both would have been dropped. Still in review (#7369, reviewer asked for changes, round 4 answered): "cancel my tour" when two tours are booked now asks which one, or both, by a name that belongs to the tour (its street or unit), not its position in a list. The two live proofs (two-home booking, cancel both) run after that merges.

Tuesday 2026-09-08, 3:00 PM. "Cancel my tour" with two tours booked: behavior complete and covered (asks which one, or both; a tour is named by its own identifier plus date and time, the address is only a spoken label) but still in the review queue after eleven rounds, most of them about how the tour is named; merges automatically on a clean verdict. The two live proofs (a two-home booking writes two tour rows; cancel both) run right after that merge, or tomorrow if the review runs on. Also live today: Clara never hands out a callback number on a failed transfer (their main line would loop back to her once forwarded), and in-hours "talk to a person" dials a leasing desk number from the property record, which is unset until Jason's directory arrives. New defect logged, not fixed: a repeat caller who gives a new name still gets the old stored name in their confirmation text.

Tuesday 2026-09-08, evening — the four follow-ups, and what the test calls found. Three of the four are done and live on the line. Clara no longer offers a street as if it were a home: the neighbourhood list she reads now maps an area to street names only, with no house numbers and no rents, and one rule says plainly that a home is real only if it is in the live listings. Six other places in her script were teaching her an answer with a hand-typed address or rent from the deleted 5 September snapshot, including the Spanish version — all gone. (On "372 Ember Lane" specifically: it is genuinely available today at $2,825, so quoting it is now correct; the bug was that she was reading it off a geography list back when it was not.) A caller who books two homes on one call now gets two bookings. A check meant to stop Clara re-booking the same tour was remembering only "a tour was booked on this call" and not which home, so the second booking was silently dropped — and it answered "success", so she told the caller both were confirmed. That was found by the first test call, not by reading code. "Cancel my tour" when two are booked now asks which one. It used to cancel whichever was soonest and say "your tour is cancelled", leaving the other on the calendar with nobody aware. She now names both visits back with home, day and time and asks which one or both; "both" cancels both, and she does not say they are cancelled until the second one actually is. Proven on a live call: two homes booked, "actually, cancel my tour", she asked, the caller said "both", both were cancelled, and production shows both rows cancelled with their calendar holds released and the guest card cleared. Nothing was left behind.

Tuesday 2026-09-08, late — the same-street fix is proven on a live call, and it uncovered one more gap. Booking two homes on one street now works the way it should: Clara names both by house number, books the first at the time the caller picked, and the second one moves itself to the next opening — the caller is asked once, not twice, and she reads each home back with the time it actually holds. Two visits were written for real, back to back, nine thirty and nine forty-five, one trip. But the text the caller receives names only one of the two homes — the later one — so the home they arrive at first is the one they have nothing in writing about. The office gets a correct email listing both; only the message to the renter is short. That is now the top item on this line, because it is the same shape as the two bugs fixed today: what she says and what actually reaches the person do not match. (The wrong-name greeting is still there too — three calls running, the caller gives a name and is greeted by an older one already on file.)

What the calls found that is still open, and needs a decision. (1) Two homes on the same street still cannot both be booked. Her script says two homes on one street are one visit at one time — but the calendar refuses the second booking as a clash with the first, every time. The two rules contradict each other, so one of them has to change: either same-street pairs get two times, or the calendar stops treating one visitor's two homes as a conflict. (2) She said "confirmed" over a booking that had failed. When that clash came back, she was given real alternative times to offer and instead said "you're all set for both homes" and added that the team would confirm the second one. That is the same class of problem as the two fixes above — telling a caller something that is not true. Fix merged 4:08 PM MT (#7381), and only half of it is live: a home counts as confirmed only when its own booking succeeded, so a clash is offered as alternative times instead of being announced as booked. The prompt half reached the line on merge through its own provision lane; the booking handler and listing-resolution half needs a production deploy, and production has not deployed since 3:53 PM MT because main is red. That window closed at 5:57 PM MT: main went green at 5:46 and production deployed at 5:57 on a commit that contains this fix, so both halves are live. The red was not this change's fault. Main went red at 3:47 PM MT on #7380, one commit earlier: a new script, scripts/merge-shadow-tenant-rows.ts, imports the raw Dynamo helpers module outside the F7 exception table (the ADR-0079 eslint-ban evasion surface). Those two checks are push-only, so #7380 was green on its own pull request and could not have caught it. Fixed by #7397 (merged 5:34 PM MT — it also stopped the guard over-reporting, since only one of the two lines it flagged was a real violation) together with #7403 at 5:46, which greened main. (3) She greets a caller by the name already on file rather than the one they just gave. Both test callers gave a name and were greeted by an older one from a previous test on the same number, and the confirmation text used the old name too. Not a bug — a switch that is off. The product already replaces the stored name with the one given on the call, behind a per-property setting that is off by default and off here; #7382 (merged 3:14 PM MT) added two test files pinning that rule and changed no behavior. Turning it on for this property is an activation, one dry-runnable script line, and it is on Fede's list above. Even then the very first greeting still reads the record before any tool has run, so that one sentence keeps the old name. (4) Jay's two Tuesday tour requests: only one exists, and it has no home attached; the second exists nowhere. His call ran before the tools were switched on, so nothing could have been written during it, and the after-the-call sweep that rescued the first one only ever creates a single tour and leaves the address blank when it cannot match what was said. Nobody at Western Slope can see any of this yet — they have no logins, the property is still marked as a test property, unconfirmed tours never reach a calendar, and nothing is written into their AppFolio.

Tuesday 2026-09-08, 5:00 PM — two items for Fede, one incident. (1) The confirmation text greeting a repeat caller by an old name is not a bug but a switch: the product already lets a name given on the call replace the stored prospect name, behind a per-property setting that is off by default and off here. Turning it on is an activation: one dry-runnable script line, recorded in the handoff file. (2) The false "confirmed for both homes" from today's proof call is fixed in a pull request going through review; until it lands, a caller asking for two homes at one time can be told a tour is confirmed when it is not. Incident, not this lane's: the main branch has been red since an unrelated afternoon merge, and production has not deployed since the cancel-both change; that fix will wait behind it.

Tuesday 2026-09-08, 11:59 PM — day closed. The last gap from the proof calls is merged: the caller's confirmation text now lists every home booked on the call in time order ("367 Ember Lane at 9:30, then 374 Ember Lane at 9:45"), virtual stops keep their call-you wording, homes at other properties never enter the text, and every single-home text, Camellia and Yale included, is unchanged character for character. Live in production as of 7:06 PM MT — confirmed: it merged at 6:56 and the 7:06 deploy is on a commit that contains it. A live two-home call to prove the text end to end is owed tomorrow (today's robot budget is spent). Open for Fede: the per-property switch that lets a name given on the call replace a stale stored name (one script line in the handoff). Open for a card: the test-harness cancel helper needs the property id or it silently leaks test tours under the new fail-closed cancel rule.

Wednesday 2026-09-09, 12:45 AM — checked against Gera's portfolio design. The design's nameplate (a phone number names the customer, the home is chosen by talking) is the same shape as the shared-agent decision and the isolation rule, so no conflict there. Two of this lane's stopgaps do conflict and are marked on the go-live tracker: the leasing-desk number lives as a field on the building row and should instead hang on the company as a hook; and the 970 number pointing at a stand-in building is exactly what the nameplate replaces, along with the copied test calendar and per-property switches on that stand-in. Nothing in the tours, cancel, or receipt work is affected.

Records: ~/westernslope-data/HANDOFF-2026-09-05-night.md (weekend state; superseded Monday by the real-data change), proto-defects-2026-09-05.md (26 weekend defects, all fixed or decided), robocalls-2026-09-06.md (every robot call with quoted grades). Monday's change and 008's fixes are described in their pull requests on main.

Owner: Fede · updated 2026-09-08 · three property-manager reviews applied; knowledge review gate live on propflowai.co

Live: Clara activated in Western Slope's AppFolio; full read-only pull done Sep 7; operations read + coverage on the new-customer-onboarding-experience page; reusable AppFolio onboarding tool + Claude Code skill merged and handed to Gera; password-protected knowledge review page live on propflowai.co (same gate as demo/proposals), seeded for Western Slope; three independent property-manager reviews applied; link not yet sent.

Pending: Jason's API upgrade + key (promised Sep 8); tool's later phases to be run on a test database; six overstated catalog endpoints to clean.

Needs Fede: send the review link + password to Jason, Jay, Kat; his drafted reply to Jason is unsent in Gmail.

Decided: knowledge sharing — separate companies, nothing shared (Fede, 2026-09-08); knowledge review = table/page reviewed with the customer, no product write yet (Fede, 2026-09-07).

Owner: this lane, session 006 · updated Tuesday 2026-09-08

Live on production. The stopgap that stops one company from seeing another company's data: a company admin now sees only their own company, proven by logging in as an outside customer. Settings only returns the caller's own company. The Settings page now renders correctly for a company that has no properties yet (Gera's rewrite). The button on the sign-in link now lands inside the app — the broken-page error is gone.

Pending, on us. Two Settings changes are built and waiting on Fede to look at them: the Company Name field comes prefilled from the company's own record with no error shown on load, and the customer-facing Billing card shows only the unit count. A typed 6-digit sign-in code is drafted; its sign-in-then-bounced-back bug is fixed (12:05 PM MT) and it still needs a real inbox read to prove the code lands. A second sign-in factor using a passkey or a text code, with no recovery codes, is drafted and its live walkthrough is posted (12:06 PM MT, two screenshots) — it now waits only on Fede's word. Also on main since this morning: company admins manage their own team from Settings (#7339), and the five platform-wide switches (texting, email, shadow modes, vendor mails) refuse a write from any customer role (#7365) — a customer could previously silence every customer's texting from a browser console. Work on isolation step one starts this week. Before Tuesday we still need to check how Camellia's AppFolio writes resolve to a database, so the Western Slope import instructions are right.

Found overnight. In Settings, "Connect AppFolio" saves the key but never imports the properties behind it — so Tuesday's AppFolio connection for Western Slope will go through the onboarding wizard instead. Situs Group has no company record of its own yet (Yale 25 Station currently sits under JP&Co's company), and it needs one before any Situs person can be given a login.

Needs Fede. Approve the two Settings changes above. Approve the two-step isolation plan and say who builds step one — our recommendation is Gera, handed the entry-point inventory and test suite this lane already built. Decide when Jason gets his invite — our recommendation is Tuesday, after his properties are imported. Paste the Stripe setup email to Sean (it's drafted and ready).

Full detail: the onboarding experience page (billing decision, Tuesday AppFolio runbook, backlog) and the isolation architecture page (the isolation plan).

From merged-PR authorship (PR author, not commit author; squash commits credit Gera for everything). Directional — and counted once, on 2026-09-05, and not re-derived since (checked against this page's own history: the figures have not been edited since the commit that created the page). Several hundred pull requests have merged in the days after, so read the numbers as the shape of who built what, not as a current tally. The ownership column is the part that is still live: it records a decision, not a count.

Full decision study: voice-agent-architecture-decision

v1 for Western Slope = Clara answers leads, answers questions, and books, moves, or cancels tours. She does not touch applications or move-in; those go to a person. The table maps each funnel stage to what actually controls it in the code today (checked against main, Sep 5).

Email: what Camellia's setup gives us, and the one gap for Western Slope

Camellia runs on a Microsoft 365 mailbox connection: read new mail, reply from the property's address. AppFolio relays every syndicated lead into that mailbox as a "New Lead" email, and the parser already reads the name, email, phone, beds, move-in date, source, and the two property hints: the first line ("New Lead for 1235 Grant Street") and "Interested in: Camellia Apartments". Zillow's own emails also carry the listing address. So yes: mailbox read and write is enough to do for Western Slope what we do at Camellia.

The gap: today one mailbox connection belongs to exactly one property. The property is decided by which mailbox the email arrived in; the "Interested in" line is stored as a display hint and never used to pick the property. Western Slope has one mailbox, leasing@westernslopepm.com, for about 14 properties. Before go-live, the inbound path needs one addition: when a mailbox is shared, resolve the property from the "New Lead for <address>" / "Interested in" line (and from the Zillow listing address), and fall back to a human when it cannot. For scattered-site homes the "property" in AppFolio is the address itself, so the match is exact, not fuzzy. Decision W11.

Onboarding and settings have to be redone

Today the controls above are a mix of a settings field, per-property flags set by script, deploy-level arms, and hard-coded lists. There is no single place to say "for this property Clara owns inquiries and tours, and hands off applications and move-in". Onboarding a property should become one screen per flow: off / shadow / live / hand to human at stage X, with the safe default being off. That rework is the platform item for week 2 onward; for week 1 we set the switches by hand in the order above and record each one on this page.

Everything below was checked against main on Sep 5. The theme: the product assumes one property per channel (one mailbox, one number, one calendar, one listings URL, one settings row per property). Western Slope is one company with ~14 properties behind one mailbox, one number, and one listings feed. The portfolio level has to exist first; the rest hangs off it. Sizes are estimates.

Order of attack. Mon: G1 organization + property import scaffold (Gera), G4 importer and G2 parser on real lead emails (Fede). Tue: G2 routing, G3 stopgap number mapping (Gera); mailbox consent and G6 setup (Fede). Wed–Thu: G5 calendar and buffer, G9 knowledge from their answers (Fede); G7 leak paths and the first cut of the G13 isolation harness, text + voice (Gera). Fri: end-to-end proof on one property; G8 transfers only if the direct numbers arrived. Week 1 decision, any day: G14 (which layer binds the property on a shared line), since it shapes G3, G5, and the front-door agent.

Baseline: 89 facts cover 99% of real messages (4,851 Camellia messages mapped to 112 fact keys). Western Slope's first-draft knowledge base was built from public data only (their site, AppFolio listings, Pomona's site, reviews, state filings; 73 files, nothing guessed). Result: public data answers about 27% of message volume. Of the 89 priority facts: 14 known, 6 partial, 69 gaps. The gaps are exactly the things that live in AppFolio or in staff heads, which is why the clara@ user and their answers are the whole week-one job.

Files: ~/westernslope-data/knowledge/BRAIN.md (22 questions, cited per bullet), facts.json (112 keys), properties.json (14 properties). Move-in, payments, lease terms, and maintenance gaps are recorded there too but are out of scope until leasing is live.

Sensitive scopes only, no audit, no fee. Google states 2–3 business days brand plus 3–5 days scope; plan 4–8 weeks. Domain, privacy and terms pages are in place; the privacy paragraph is in a PR. Blocker for the required demo video: Gmail send and calendar writes are not wired, and Google rejects scopes not shown in use. Kit: email-architecture page. Interim for Situs: their Workspace admin allowlists our app for their org.

Superseded by the fuller readiness check below: Google Workspace readiness for Situs Group (2026-09-15). Gmail send and calendar scopes are wired now (per property); reading Gmail is still not built and needs Google's restricted-scope review.

What exists today

PropFlow already has a working Google connect, built 2026-08-13, one per property. It can send email (send-only, scope gmail.send) and read/write a calendar for tours (calendar.events, calendar.readonly). It is wired into property onboarding, the settings page, and the admin integrations inspector. The privacy page already discloses the send-only scope in section 8.

What it cannot do: read Gmail at all, get push notifications when new mail arrives (no watch/Pub-Sub), or connect at the company level instead of per property. There is an unused constant for company-level scopes (ORG_GOOGLE_SCOPES in org-connect.ts) with a note that reading Gmail needs Google's annual security assessment. Gera's Google work so far is just the shared control layer: handling a declined OAuth consent (#7518) and one place to disconnect any integration (#7875). The Google button on the welcome and calendar page is a dead end today, it says "coming shortly."

We have a Google API client set up in the keychain (propflow-google-client-id), but no record of Google's app verification or the CASA security assessment being done. gcloud is installed for fede@propflowai.co on the propflow-admin-tools project, but it needs Fede to log in again before we can confirm the consent screen setup and which APIs are turned on.

What Google actually allows for a shared leasing inbox

Researched today against Google's own docs. The short version: no app can read a Google Group or a delegated mailbox just because a person signs in with their own Google account. Reading mail only works two ways: an alias on someone's personal account, or a real account with its own separate login. The other option, "domain-wide delegation," only a domain super-admin can turn on, and it grants access across the whole domain at once, which is a much bigger ask than a single shared inbox.

Reading Gmail needs a "restricted" scope (gmail.readonly or gmail.modify). Restricted scopes require Google's full app verification plus a CASA Tier 2 security assessment, a paid, self-serve lab test that runs roughly $540 to $1,000 and takes 4 to 12 weeks including Google's own review. It has to be redone every 12 months. Calendar scopes are a lighter category, "sensitive" not "restricted," so they only need standard review, no lab test.

Sources: Restricted scope verification · Gmail delegation · Domain-wide delegation best practices · Restricted scope requirements

Gaps

Checklist to a verified app

In order. "Can start today" means it does not wait on anything else on this list.

Stopgap for Situs Group, no code change

Situs Group's own Google Workspace admin can allowlist PropFlow's app as a trusted app for their domain (Admin console, Security, API controls, App access control). That removes the "unverified app" warning screen for what we already have today, sending email and calendar, with no engineering work. It does not unlock reading Gmail; that still needs the verification and CASA path above.

One question for Situs Group before we design anything further

Is leasing@ a Google Group, a mailbox someone delegated to others, an alias on one person's account, or its own separate login? The answer decides whether a person's own sign-in can ever read that inbox, or whether it needs its own dedicated account.

Western Slope (W)

Situs (S)

Shared (X)

Two questions every customer answers

Every customer answers two separate questions, and they don't have to have the same answer.

1. How do leads reach Clara? This is intake — which door a prospect's inquiry walks through before Clara ever sees it.
2. Who does Clara reply as? This is reply identity — the mailbox, phone number, or AppFolio guest card the customer's prospects actually see a message come from.

A customer can have a fast intake channel and a slow reply identity, or the reverse. Fixing one does not fix the other.

This section is the current-state map, one channel at a time. For the bigger redesign — one intake pipeline every source runs through, replacing today's two separate lead writers, plus provenance and PMS write-back as a customer-level choice — see Lead-intake engine: where we are, where we're going, just below.

Intake channels

Reply identity

Per-customer matrix

Where each piece lives in the product

• Listing-site lead email parsing: agents/clara/lib/email/parse-lead-source.ts, agents/clara/lib/email/process-inbound-email.ts
• AppFolio guest-card / rental-application pull (Reports API): src/lib/integrations/appfolio/pms-adapter.ts
• Property-voiced email send (connected mailbox, Graph primary / SendGrid fallback): src/lib/integrations/email/property-graph-sender.ts
• Mailbox connection and calendar/email OAuth: src/lib/domain/calendar/outlook-client.ts, src/lib/domain/calendar/provider/google.ts, src/lib/integrations/email/graph-subscription.ts
• Voice / SMS number routing: config/phone-registry.json, src/lib/domain/properties/phone-registry.ts
• Per-user PMS login credential (Clara's PMS-login identity, intake only): src/lib/data/dynamo/pms-credential.ts (PK PMSCRED#<userId>), src/lib/domain/pms/registry.ts
• AppFolio guest-card messaging (send + read, browser session replay): src/lib/integrations/appfolio/message-sender.ts, src/lib/domain/pms/message-sender.ts, src/lib/domain/pms/guest-card-message-reader.ts, src/lib/integrations/appfolio/guest-card-message-reader.ts
• Two-database AppFolio account resolution (jpco vs situsgroup): src/lib/integrations/appfolio/resolve-account.ts, src/lib/integrations/appfolio/config.ts

Open decisions

Sources: this page's own audit sections (2 · Inbound guest cards/leads; the two-clients side-by-side table; the household-identity and lead-intake-speed sections above) · new-customer-onboarding-experience-2026-09 · ~/.claude/propflowai/CLAUDE.md · origin/main of the propflowai repo, read 2026-09-09: src/lib/integrations/appfolio/pms-adapter.ts, src/lib/domain/pms/registry.ts, src/lib/domain/pms/message-sender.ts, src/lib/integrations/appfolio/message-sender.ts, src/lib/domain/pms/guest-card-message-reader.ts, src/lib/integrations/email/property-graph-sender.ts, src/lib/data/dynamo/pms-credential.ts, agents/clara/lib/email/parse-lead-source.ts · AppFolio Stack/Reports API public documentation (see the lead-intake-speed section's own source list, above).

Podcast companion: The Week of Whack-a-Mole — the whack-a-mole week, the Willows proof, all four adversarial review rounds (25/19/17/5), the engine, and the three decisions below, in plain English. Audio pending; the brief and outline are already on that page.

What changed in revision 2: two independent adversarial reviews (concurrency/scale; identity/tenancy/consent) plus a 62-row setup-permutation gauntlet found 3 blockers and 9 must-fix gaps in the first draft — mostly a poll cadence and shared-breaker design that couldn't survive scale, a consent model with no cross-customer opt-out mechanism, and a write-back design that could loop or leak. All 12 are resolved below with a concrete design change; the full list, including the should-fix findings adopted along the way, is in the review log. A fourth CRM-of-record mode ("read-only during onboarding") was added — it's Western Slope's actual state today and the three-mode design had no way to say so. See existing mechanisms the engine reuses for what does not change.

What changed in revision 3: two more adversarial reviews ran against revision 2 — reviewer C re-walked every one of the 62 setup rows for identity/consent breaks, reviewer D checked whether the plan can actually be built and operated one dark step at a time. Between them: 3 blocks, 9 must-fix, 4 should-fix, 3 notes, plus a proposed executable-gauntlet appendix (16 findings from D alone, 3 from C — see totals in the review log's convergence line). The two most serious findings were that revision 2's name-agreement fix (B-07) was scoped to the leasing writers only and leaves the shared Person-mint spine — the one place every entity type reuses — fusing (and, on the tenant path, silently renaming) people on bare phone match (C-01), and that the "never auto-enroll AppFolio prospects in outreach" consent rule (ADR-0094) is a Writer-B-only mechanism this design never named as something the unified pipeline has to keep (D-02). Both are now named explicitly, with the rest resolved below: a rules ledger names every rule each writer owns today and where it must survive the merge; the platform opt-out table gets its own ladder step ahead of write-back instead of being implied by write-back's prose; step 1's dedup-key change is split out from the plumbing move and gets its own proof; a legacy-provenance backfill default, a reply-identity backfill policy, and a concrete AppFolio polling-budget worked example are added; and every new gate names an owner and an alert reader. An executable gauntlet merges reviewer D's proposed L-01..L-10 rows with the permutation rows that read FAIL or CANNOT-EXPRESS today into one runnable table, modeled on the portfolio harness's own gauntlet. The L-nn numbering below was a drafting artifact of that merge and never matched the gauntlet's own T-nn ids — see the crosswalk note at the top of the rules ledger, revision 4.

What changed in revision 4: two more adversarial reviews ran against revision 3 — reviewer E (coherence/completeness, reading this cold as the engineer who builds step 1 next week) found 1 blocker, 5 must-fix, 4 should-fix, 2 notes; reviewer F (auditor of every finding from rounds 1–3) found the design converged, with 1 should-fix and 4 notes of its own. Reviewer E's blocker (E-01) re-opens D-02: the rules ledger's "never auto-enroll" row only ever described guest-card.ts's deliberate, ADR-0094-driven refusal to enroll AppFolio guest cards in outreach. It said nothing about AppFolio rental applications — a separately listed intake source — whose writer (rental-application.ts) is fully wired to the same enrollment hook and today enrolls zero applicants only because mapApplicationStage happens to always return a cadence-stop stage, not because of any consent decision. That accident is one stage-mapping change away from auto-enrolling a PMS-sourced applicant in outreach with no consent check at all. Fixed below: the rules ledger now carries one never-auto-enroll row per adapter, stating plainly which enforce it by decision and which merely happen not to trigger it yet, and a new gauntlet row fails loudly the moment an application-sourced lead would be enrolled without consent evidence. The other four must-fix findings split the two name-blind matching functions the rules ledger had conflated into two rows with two gauntlet rows, renamed every stray L-nn citation to the gauntlet's own T-nn ids with a crosswalk line, resolved a real contradiction between this section and the integration map over whether the AppFolio notification email is a lead source, and gave the LeadSignal contract a way to express two source records folding into one. A household-grouping rule-precedence order is now stated explicitly (E-06). All of E's should-fix items and F's should-fix and notes are adopted below; the full list and this round's verdict are in the review log. A commit (#7463, restamping a corrected guest-card contact value onto its Person) landed on origin/main during this review round and directly closes setup-permutation row P-21, which was FAIL as of revision 3 — updated below.

What changed in revision 5: one more adversarial review ran against revision 4 — reviewer G (fresh eyes, reading cold) found 0 blockers, 3 must-fix, 1 should-fix, 1 note (G-01 through G-05; see the review log). G-01 caught a self-contradiction revision 4 introduced in its own two fixes to the same shape: F-02 tightened gauntlet row T-14 to require the review-queue outcome and remove "mint a second Person" as a passing branch, but the new T-19 row E-02 added in the same revision still accepted minting as passing and wrongly cited itself as "the same tightened either/or resolution as T-14" — fixed by tightening T-19 to match T-14 exactly, cross-referenced below. G-02 found origin/main had moved one substantive commit (#7464, two co-pendency fixes) past this document's own re-confirmed tip since revision 4 was written; P-03, P-20, and P-38 are re-verified against the current tip below, with two citation updates and one verdict flip (P-38, PARTIAL → PASS). G-03 fixed a real contradiction between the refactor ladder's step 3.5 and step 5 cells over which one T-08 actually gates — step 3.5's write-back opt-out table cannot run T-08's write-back scenario before write-back itself ships in step 5, so step 3.5's cell no longer claims T-08 "turns green." G-04 adds a stated migration posture for legacy SMS consent records, mirroring D-06's existing name/contact backfill default. G-05 reworded the household-precedence text so gauntlet rows are cited as tests pinning the rule, not as the rule itself. All five are resolved below with a concrete text change; details and this round's verdict are in the review log.

1. Why this, why now

Every bug fixed this week was the same bug wearing a different hat: two doors disagreeing about what a lead is. A phone number matched two different people because one writer trusted it and the other didn't (#7444). A cosigner's application went ungrouped because one writer reads a relationship marker the other one ignores. A unit showed up as two different ids depending on which door the lead walked through (#7441, #7455). A dead person's leftover marker silently broke an entire property's sync because only one of the two writers knew to clean it up (#7439). None of these are new bugs so much as the same design gap resurfacing: PropFlow has two independent places that turn a signal into a lead, an inbound-email/voice path and an AppFolio-sync path, and every rule that lives in only one of them is a place the two doors can disagree. AppFolio is one source today, but it is already one of hundreds a portfolio property might use — other guest-card CRMs, other PMSs (Yardi), listing sites, a website contact form, a phone call, a text. Chasing each disagreement as it's found is whack-a-mole; the fix is one door, not two, with one set of rules everything walks through, so a new source is an adapter, not a rewrite of the rules.

2. Today — two writers, two rule sets, one Person mint

2a. Rules ledger — every rule each writer owns today, new in revision 3

Plain version: reviewer D's attack (D-02, D-03, D-04) found that the diagram above names Writer B's rules but not Writer A's with the same precision, and that two of Writer B's rules — the consent rule and the stage-progression rule — don't appear anywhere else in this document either, so nothing stated that the unified pipeline in step 2 has to keep them. This table is the fix: every rule either writer enforces today, who owns it today, where it lives, and which gauntlet row (below) pins it so a future refactor that drops it fails a test instead of shipping quietly. Revision 4 note (E-03): revision 3 cited these gauntlet rows with an "L-nn" prefix (reviewer D's original proposal numbers) while section 9's actual executable gauntlet built the same rows under a "T-nn" prefix, matching the portfolio harness's own convention — two different id strings for the same rows, so a reader searching this document for "gauntlet row L-09" would never find it. Crosswalk: every L-nn below is renamed to its matching T-nn — L-01→T-01, L-02→T-02, L-03→T-03, L-04→T-04, L-07→T-07, L-08→T-08, L-09→T-09, L-10→T-10, L-11→T-11, L-12→T-12, L-13→T-13, L-14→T-14 — one id space from here on. Revision 4 also splits two rows reviewer E found conflated (E-01, E-02): the never-auto-enroll rule is now one row per adapter instead of one row that only ever described the guest-card writer, and the two independent name-blind matching functions get two rows instead of one that implied a single fix covers both.

Step 2 of the refactor path (below) is the step that folds these into one pipeline; its Deletes/Keeps columns now point at this table by name instead of re-describing each rule in prose, and every row above gets a pinning test in the unified pipeline before step 2 is called done (D-02, D-03, D-04). The never-auto-enroll rule is a source-keyed rule by design (F-04): ADR-0094's consent gap is specific to PMS-sourced signals, not a rule every source must carry identically — "not re-derived from source type at call time" (below, step 2) means the check itself is implemented once, not re-invented per call site, not that every adapter must refuse enrollment the same way a source with no PMS consent gap would.

3. Target — one contract, one pipeline, one lead, provenance, write-back as its own step

Plain version: every source — AppFolio, a website form, a phone call, a text, Yardi, a generic webhook — gets its own small adapter that translates that source's shape into one common shape. That common shape runs through exactly one pipeline: figure out who this is, which unit/property they mean, which household they belong to, then write. One lead comes out the other end, with a record of exactly where it came from and a pointer back to the source system. Writing back to the customer's PMS — if they want that — is a separate, later step, not folded into the same code that decides who someone is.

The LeadSignal contract

One shape every adapter must produce, so the pipeline only has to know one thing. Changed in revision 2 (review findings A-12, B-02, B-09 below): the dedup key now names the org, not just the source record; person fields carry their own provenance instead of last-write-wins; and the role field's cross-PMS limits are named instead of implied.

• org/account id — the PropFlow org, plus which underlying PMS database when a source has more than one (AppFolio: jpco vs situsgroup). New in revision 2 (A-12): an AppFolio guest-card uuid is only unique within one database — src/lib/integrations/appfolio/resolve-account.ts already resolves every AppFolio write fail-closed, from the property record, specifically because a global default is "a live cross-tenant-write hazard" (its own header comment); the dedup key inherits that discipline instead of trusting uuid non-collision across jpco.appfolio.com and situsgroup.appfolio.com.
• source — which adapter produced this (e.g. appfolio_guest_card, appfolio_notification_email, website_form, yardi, voice_call, sms, generic_webhook).
• source record id — the id this signal has in the source system (AppFolio's guest-card uuid, an email's message id, a call's conversation id). The pipeline's dedup key is (org/account id, source, source record id), not (source, source record id) alone — the revision-2 fix for A-12.
• property/unit reference — property-scoped, matching the fix already made to the email-lead path (#7441/#7455) rather than reintroducing a bare unit id anywhere. Stated explicitly, new in revision 3 (D-07): existing ProspectInquiry rows already persisted under the old bare-unit-id shape are read compatibly — the read path accepts both shapes — they are never re-keyed. A re-key would move a DynamoDB partition/sort key built from the unit id, which is exactly the kind of silent partition move this design must never cause; compatible reads cost nothing extra and avoid that risk entirely.
• contact values — email, phone, normalized once, at the edge, not re-normalized differently per writer.
• names — first/last, kept separate from any role annotation the source embeds (the #7424 cosigner-name fix, generalized: no source's formatting convention is ever saved into a person's name).
• applicant role / cosigner marker — a first-class field, not a string a downstream writer has to notice or miss (closed by making this part of the contract instead of a parsing afterthought). Named limitation, revision 2 (B-09): the only shipped evidence this field can be populated from is AppFolio's "(Co-signer for [name])" name-text convention (#7424). Yardi/RealPage do not expose an equivalent text marker in the API tiers this design has looked at; role there lives in structured occupancy/lease-party fields the Yardi/RealPage adapter (refactor step 6) has not been scoped against yet. The contract stays source-agnostic, but each new adapter's build-out must state, in writing, what field it populates role from — or that it cannot, and defaults every applicant to primary until it can. A source that cannot populate role is not silently treated as "no cosigner"; it is a named gap on that adapter's own step in the refactor table.
• group id — the source's own grouping signal when it has one (AppFolio's application group id), carried through rather than discovered separately by only one writer.
• consent evidence — {channel, source, timestamp, evidence} per channel the person has been reached on, not one blanket flag. Changed in revision 2 (B-01, B-03) — see consent and cross-customer opt-outs, below, for the full model; today's SmsConsentRecord (agents/clara/lib/data/types.ts:2167-2176, PK CONSENT#{phone}) records consent per phone number with no channel field at all, so it cannot express "consented to AppFolio texting, not to Clara's number" — the LeadSignal contract's consent-evidence field is the fix. evidence's own shape, new in revision 4 (E-07): {text, ip, userAgent}, mirroring today's SmsConsentRecord fields (consentText, ip, userAgent) rather than leaving it an untyped blob — a source that can't populate one of the three (e.g. a phone call has no ip/userAgent) leaves it null, never a placeholder value.
• raw payload pointer — where the original record lives, for provenance and for replay. Lives inside the same per-org partition the identity wall already defines, never a separate ungated blob store, and identity/household/eligibility decisions are made only from the structured LeadSignal fields above, never by re-reading the raw payload for inference — a fair-housing guard (B-11), since a voice transcript or email can incidentally carry protected-class information a scoring pass must never glob for "more signal." Carries a list, not a single pointer, once two source records fold into one lead (E-05, new in revision 4): a folded lead's raw-payload pointer is an array, one entry per contributing source record — never a single field silently overwritten or a second entry silently discarded once dedup fires. See the fold/merge signal below for how that folding itself is expressed on the LeadSignal contract.
• fold/merge signal, new in revision 4 (E-05) — a LeadSignal can declare that it is the same underlying lead as one or more prior signals folding into it: {foldedSourceRecordIds: [{org, source, sourceRecordId}, ...], survivingSourceRecordId: {org, source, sourceRecordId}}. This is how the notification-email trigger and the poll's own delivery of the same guest card (gauntlet row T-04) — or a guest card and a duplicate website-form submission for the same person, once that adapter exists (step 6) — collapse to one lead without either contributing record's provenance getting silently dropped: every folded id is appended to the raw-payload-pointer list above, and the surviving id is the one the pipeline's dedup key and every downstream write key off going forward.
• observed-at — when the source says this happened, distinct from when our pipeline processed it (needed for out-of-order arrivals, below).

Adding a new source is: write one adapter that emits LeadSignal, add its fixtures to the household/lead corpus, add a corpus slice from real data if one exists. The pipeline — identity resolve, unit resolve, household resolve, write — does not change. That is the whole point: today, adding a new intake path means someone has to decide whether it plugs into Writer A's rules, Writer B's rules, or invents a third set. Under this contract there is only one set of rules to plug into.

Person-field precedence — who wins when two sources disagree

Plain version: three sources can each hand the pipeline a slightly different version of the same person's name or contact info. Something has to decide which one sticks, and it has to write down who said what and when — not just silently overwrite. New in revision 2 (B-02): the resolver already has exactly this discipline for settings (portfolio-architecture-how.html §04: "every effective value has provenance... a chain node, a default or a floor"); person fields had no equivalent, so whichever writer ran last silently overwrote the others' spelling with no record of who touched the legal name last — the same class of bug (#7424, cosigner text in a name field) recurring one layer up.

• Every stored name/contact field carries {value, setBy: source, setAt: observed-at, supersedes} — the resolver's provenance shape, applied to person fields instead of settings.
• Legal name: PMS of record wins. A staff-typed AppFolio guest card outranks a voice-transcribed name ("Bob Smith" from a call loses to "Robert Smith" typed by staff) — the PMS is the system the leasing team already treats as the record of truth for a legal name.
• Phone/email: latest verified contact wins. The most recently observed value the person has confirmed (replied from, called from) is authoritative — a stale email from a listing-site lead doesn't outrank a phone number they just texted from.
• Every prior value is kept, not deleted — supersedes chains the history, the same way MAPLOG# keeps the full undo trail for settings, so a wrong precedence call can be audited and reversed without reconstructing it from source logs.
• Legacy-row backfill default, new in revision 3 (D-06). Every Person/contact field written by today's code has no setBy/setAt — the precedence rule is meaningless on cutover day unless both sides of the first comparison have a value. The backfill default: synthesize setAt from the row's own updatedAt, set setBy: 'legacy-unknown', and rank legacy-unknown below every named source, so any new, attributed observation always wins over an unattributed legacy one on the very first comparison after the switch flips. This is a one-time synthesis at read time (no bulk rewrite of existing rows required) — gauntlet row T-07 (below) is the case that proves it against a legacy-shaped fixture.
• Household/group-membership decisions get the same shape, new in revision 3 (C-03). {value, setBy, setAt, supersedes} covered names and contacts in revision 2 but not the grouping decision itself — which household a person was folded into, and by which rule (cosigner marker, shared contact, AppFolio group id, or the unresolved-cohabitation default, below). The household-resolve stage now writes the same shape on its own output: value = the group id assigned (or "ungrouped"), setBy = the rule that decided (cosigner-marker / shared-contact / appfolio-group-id / unresolved-cohabitation-default), setAt = when, supersedes = the prior grouping if a later signal changes it. This closes the gap C-03 named: today a wrong name overwrite is auditable, a wrong household fuse or split was not.
• Household-grouping rule precedence, new in revision 4 (E-06). C-03's shape records which rule decided a grouping, but revision 3 never stated what happens when two rules for the same person disagree — e.g. AppFolio's own group id says household A while a cosigner text marker (the only cross-PMS signal Yardi/RealPage have) implies household B. The order, highest wins:
  1. Group id (appfolio-group-id) — the source's own explicit grouping signal, when it exists, always wins over an inferred one.
  2. Cosigner marker (cosigner-marker) — the LeadSignal contract's role/cosigner field, read when no group id is present.
  3. Shared contact (shared-contact) — a matching phone or email between two LeadSignals, read only when neither of the above fired, and only after the name-agreement gate (the ensurePersonForSignals/pickBestProspect fixes, pinned by gauntlet rows T-14/T-19 above — new in revision 5, G-05: those rows are the tests that pin this gate, not the gate itself) clears — a bare contact match is never sufficient on its own.
  4. None (unresolved-cohabitation-default) — no grouping signal at all; the two people stay separate individuals, graded as the unresolved-cohabitation class (B-08), never silently fused and never silently swallowed into "zero failures."
  When two signals disagree — a group id says A, a cosigner marker says B — the higher-precedence rule wins outright; the loser is recorded as a supersedes entry citing the rule and value it lost to, never a silent pick and never averaged.

4. Idempotency, ordering, and scale

Plain version: the same lead can arrive twice (AppFolio's poll re-sends the whole list; a webhook can retry), leads can arrive out of order (an application can land before the guest card that created it), the same tick can start again before the last one finished, and at a few thousand units there will be a lot more of all of this happening per minute than there is today. The pipeline has to be built assuming all four from day one, not patched in later. This section changed substantially in revision 2 — the original draft's "60-second incremental pull" and "each adapter owns its own rate-limit" claims did not hold up against the code that exists today; see findings A-01, A-02, A-03, A-05, A-07, A-10 in the review log.

• The poll is per AppFolio database, not per property and not per account-wide default, and its cadence is a function of what the Reports API can actually do, not a flat number. Changed in revision 2 (A-01): nothing in the repo today demonstrates a server-side date-filtered guest-card query — src/lib/domain/pms/writers/guest-card.ts's own comment states the fetch is unwindowed (status: 'all'), so every tick re-reads the full card list. Before committing to any flat cadence, the date-filter question gets an actual answer: a live probe against a real AppFolio database (not "appears to ignore"), run once per plan tier we support. If the report genuinely cannot be filtered server-side, cadence is stated as a function of property size and the account's remaining API budget (a 5,000-card cold-start customer polls slower than a 50-card one), never a flat 60 seconds for every property regardless of size.
• A per-database change fingerprint makes an unchanged card a no-op, every tick. Changed in revision 2 (A-10): guest-card.ts already fingerprints a card's content and skips re-processing an unchanged one (its own comment: "fingerprint the card's CONTENT, persist the fingerprint on the prospect it landed on, and on the next tick skip the identity reads for a card whose fingerprint is unchanged") — the polling adapter reuses this pattern and emits a LeadSignal only on a fingerprint change, not on every row it observes. Without this, provenance storage and pipeline load grow with poll frequency for every unchanged row, forever.
• Per-database overlap lock. Changed in revision 2 (A-03): retryOnRowConflict (src/lib/domain/pms/writers/utils.ts) bounds damage from two overlapping runs racing on the same row — it does not stop the runs from overlapping, and nothing in lambda/appfolio-sync/handler.ts today stops a new tick starting while the prior one for the same property is still in flight. A DynamoDB conditional-write lease per connection (property + AppFolio database), held for the duration of a tick and released or TTL'd on completion, skips a new tick outright rather than launching a second one on top of the first. retryOnRowConflict stays as the second line of defense for the residual cross-job case (guest-card sync vs. application sync vs. an explicit manual invoke), not the only one.
• Per-property error breaker, not a shared account-wide one. Changed in revision 2 (A-02): src/lib/platform/resilience.ts's appfolioBreaker is a single module-level circuit breaker, not scoped per AppFolio database or per property — its own file documents the incident this already caused ("the balances cron's own burst opened the shared breaker mid-run, so every property still queued behind the tripped one in that invocation failed too, '0/2 properties synced'"). One property's bad data or transient outage must never stop a different property's sync in the same invocation. The breaker (and the underlying rate-limiter) is scoped per AppFolio-database connection before any cadence increase ships, so a faster poll doesn't multiply this failure mode by however much faster it runs.
• Dedup key per source, scoped to the org/database. Each adapter defines its own stable dedup key — AppFolio's guest-card uuid / inquiry id (already the pattern ADR-0094 uses so a later application submission merges onto the ingested prospect instead of duplicating it), an email's message id, a call's conversation id — and the pipeline dedupes on (org/account id, source, source record id) (A-12, LeadSignal contract above), never on inferred identity alone. Inferred identity is exactly the layer that fused two different people together in #7444.
• At-least-once delivery, and every stage is idempotent with a stated redo key. Changed in revision 2 (A-07): the pipeline's five stages (normalize, identity resolve, unit resolve, household resolve, write) are not atomic with each other today, and person-stamp.ts's own doc comment names this as an accepted gap ("a crash between person-mint and relation-row-write already leaves an orphan Person row in DDB, by design"). Every stage states its own redo key — the value it re-derives its output from, not a stale closure — so re-running the full pipeline from scratch against the same LeadSignal, on top of whatever partial state a crash left, converges to the same result rather than double-processing. retryOnRowConflict's own discipline (re-read the fresh row, re-derive from the row, bounded retries, rethrow on exhaustion) is the model. Partial-failure recovery rule: a crash between any two stages is recovered by redelivering the same LeadSignal and re-running the pipeline from stage 1 — never resuming mid-pipeline from assumed state — because every stage's redo key makes the earlier stages' outputs a no-op to recompute. "Partial-pipeline-crash-replay" is added as an eighth grading class in the stress-test plan (below), alongside the seven already named.
• Out-of-order and unresolved-parent arrivals. Changed in revision 2 (A-05): observed-at on the LeadSignal decides which of two present records is older, but says nothing about a child signal (an application, a cosigner marker referencing a group id) arriving before the parent guest card/person it references exists in the pipeline's world yet — the actual shape of #7439 (orphan dedup sentinels) and the application-group writer's own "no filter → phantom prospect" history. The pipeline design now states this case explicitly: a LeadSignal whose parent reference can't be resolved is persisted as a provisional record, tagged with what it's waiting for (the specific parent id/group id), and reconciled automatically on the next signal that resolves that reference — never silently dropped, and never used to mint a floating Person that a later-arriving parent must then merge into. The application-before-guest-card sequence resolves this way: the application creates the lead immediately, with its role/cosigner marker intact, and marks its own guest-card pointer pending until the guest-card poll or notification catches up and resolves it.
• Cold start. A 5,000-historical-guest-card customer reuses the historyFullyRead/liveSinceIds cutover and per-connection cursor/wall-clock-budget/fail-soft-resume mechanism already proven for guest-card messages (lambda/appfolio-sync/handler.ts, ~lines 2867-2922 and ~1879-2140) rather than leaving cold start undesigned — a historical card is tagged as history, not treated as a brand-new live lead by notification alerts or future write-back, and a backfill that can't finish in one invocation resumes instead of restarting.
• Per-org rate limits. AppFolio's Reports API is ~1 request/second per database, with a documented 429 cliff at ≥8 concurrent (appfolioPolicy comment, resilience.ts); other sources will have their own ceilings. Each adapter owns its own rate-limit and backoff — the pipeline downstream of LeadSignal is source-agnostic and does not need to know any of that. At org/customer-count scale (toward 50-100 customers), a stated infra-layer fan-out/backpressure ceiling across orgs sharing the same DynamoDB tables and the same AppFolio rate limiter prevents the same "0/2 properties synced" failure class from recurring at org granularity as it did at property granularity (A-11) — this is a note for the infra layer, separate from the per-org business-logic isolation claim below.

  Worked polling-budget example, new in revision 3 (D-12). guest-card.ts re-fetches the full, unwindowed card list every tick (status: 'all', confirmed against origin/main) — so the real cost driver is payload size × frequency, not request count alone, and request count against the 1 req/sec ceiling is shown below to confirm it is not the binding constraint at today's real customer sizes.

  Customer (real unit count)	Cadence	Requests/database/month	% of the 1 req/sec ceiling (2.59M req/mo max)
  Western Slope — ~250 doors	5 min	30 × 24 × 60 / 5 = 8,640	≈0.33%
  Situs Group — 640 units (live AppFolio dashboard count)	5 min	8,640	≈0.33%
  Situs Group — 640 units	60 sec (revision-1's original flat cadence)	43,200	≈1.7%
  Situs Group — 640 units	15 min (current guest-card schedule, schedules.json)	2,880	≈0.11%

  Request count is not the binding constraint at any real customer's size today, at any cadence in this range — the ceiling has slack of two orders of magnitude. What is not yet a measured number: the per-tick payload size (bytes per guest-card row in the Reports API response), which is what actually grows with card count × frequency. No live capture of that byte size exists in the corpus today, so it is named here as an open measurement, not invented — capture it from one real tick against a Plus/Max database before committing cadence past 5 minutes for a 500+ unit customer, and set the per-database breaker to trip on payload-bytes/tick past a stated threshold once that number exists, not on request volume alone (request volume is proven safe by the table above; unmeasured payload growth is the actual risk A-02's breaker redesign has to cover).

• Thousands of units. The identity spine (claims + CLAIM# sentinels) and the household engine already operate per-org, not per-property-hardcoded, per Constitution Article VII.1 (configuration lives in data, never code). The pipeline scales the same way: one adapter per source, fanned out per org, no per-property special-casing in the pipeline itself.

Write-back never re-ingests its own writes, and never creates next to a card a human already typed

Plain version: once write-back ships, PropFlow's own guest-card write must never look like a brand-new lead to the poll or notification adapter, and it must never create a duplicate card next to one a leasing agent already typed by hand. New in revision 2 (A-08, B-04): neither case was specified in the original draft.

• Search before create, every write — and never on contact value alone (revised in revision 3, C-02). Every write-back adapter runs its target write through the same identity-resolve stage as intake — search the target CRM by contact value and require name agreement before matching, never contact alone — before creating a new card. Clara taking a phone call and minting a PropFlow-only lead, followed by a leasing agent typing the same person into AppFolio by hand the next morning, must resolve to "matched existing PMS record," not a second card. But a genuine stranger who happens to share a phone number with an unrelated existing AppFolio guest card (family, a forwarded number, a former roommate) must not have their write-back attach to that stranger's card — a contact-only match at the write-back boundary is a worse failure than a duplicate: it silently mutates a real, unrelated customer's PMS record and can trigger that customer's own AppFolio automatic communications under the wrong person's context. A low-confidence name disagreement at write-back refuses — creates nothing, logs the ambiguity — rather than attaching to the best contact match, mirroring resolveGroupLinkVerdict's own refuse-on-ambiguity pattern. This inherits the same name-agreement gate C-01 requires inside ensurePersonForSignals (rules ledger, above, row T-14) — write-back's search-before-create does not ship ahead of that gate; step 5 in the refactor table below states this dependency explicitly, not just "after ADR-0094 amendment is decided." A provenance row logs which of the two happened on every write-back write.
• Reads its own writes back as a no-op. A guest-card-message reader already solves this for messages: every PMSMessageEvent carries a sentByUs flag (src/lib/domain/pms/guest-card-message-reader.ts:65-77), resolved by comparing the sender id against the PMS seat this account sends as, so PropFlow's own sends are never re-ingested as new inbound signals. The LeadSignal contract gets the same field for guest-card leads: a write-back write carries a provenance marker identifying it as PropFlow-authored, and the poll/notification adapters treat a card carrying that marker as a no-op, never a new lead — modeled directly on sentByUs, not reinvented.

4b. Consent and cross-customer opt-outs — new in revision 2

Plain version: two blockers from the identity/consent review (B-01, B-03) found that the design's own consent story didn't actually exist as data anywhere in the product, and that a well-meaning feature (syncing PropFlow's leads into a customer's AppFolio account) could get a real person texted by a system they never agreed to hear from. Both are resolved with a concrete mechanism below, not just a corrected sentence.

• The gap, plainly. A prospect texts STOP to Situs Group's Clara number. Weeks later the same phone number reaches Western Slope as a brand-new lead — not a staff/vendor case, so no cross-customer link is ever created for it. Nothing in the original design named where a platform-wide opt-out lives, and the code confirms there's nowhere for it to live: SmsConsentRecord (agents/clara/lib/data/types.ts:2167-2176, PK CONSENT#{phone}) has no channel field at all, so it cannot even express "opted out of AppFolio's texting but not Clara's." Separately, once write-back creates or updates a guest card in a customer's own AppFolio account, AppFolio's own automatic communications can fire a welcome text from AppFolio's number to a person who only ever consented to Clara's number — with zero PropFlow record that it happened.
• An opt-out lives in a platform-level, contact-value-keyed table — checked by every send path, regardless of org. Not a new invention: src/lib/domain/identity/resolve.ts's gatherProspectCandidates already calls cross-org helpers (findPersonsByPhoneAcrossOrgs, findPersonByEmailAcrossOrgs; src/lib/data/store.ts:3147,3179) to look up a contact value across every org's Person rows for prospect matching. The same infrastructure, pointed at a real opt-out check rather than identity matching, is the platform-level link this design was missing — a table keyed OPTOUT#<channel>#<value>, checked before any send on any channel, from any org. This is the cross-org link Gera's platform-architecture design (portfolio-architecture-how.html §05, "an opt-out follows the human") already commits to in prose; this design names the concrete mechanism it runs on.
• Consent evidence is per channel, not per phone number. The LeadSignal contract's consent evidence field (above) carries {channel, source, timestamp, evidence}. "Consented to AppFolio texting" and "consented to Clara's number" are two different rows, not one flag on a phone number.
• Legacy SMS-consent migration policy, new in revision 5 (G-04), mirroring D-06's name/contact backfill above. Today's SmsConsentRecord (agents/clara/lib/data/types.ts:2167-2176, PK CONSENT#{phone}) has no channel field and does not migrate into the per-channel consent-evidence shape — there is no backfill script and none is planned. This is deliberate, not a gap the way D-06 closed the equivalent gap for names: since write-back (step 5) refuses to enable PMS-side texting without a recorded consent-evidence record for the specific channel it would message on, every prospect who consented under today's channel-less record has, by construction, zero per-channel evidence on cutover day, and write-back correctly refuses for them until a fresh, per-channel evidence record is captured going forward — the same fail-closed posture the design uses everywhere else a signal is ambiguous or missing, not a migration this design owes anyone.
• Write-back never enables PMS-side texting without a recorded consent for that specific channel. Before a write-back adapter creates or updates a guest card that would trigger the customer's own AppFolio automatic communications, it checks the consent-evidence table for a record on the AppFolio-texting channel specifically — not "any consent this person has ever given." Where the customer's plan and permissions allow it, the adapter also disables AppFolio's own automatic-communication trigger on cards it creates; where it can't, the write-back mode for that customer is not turned on until that gap is closed. ADR-0094's existing rationale ("express SMS consent was given to JP/AppFolio, not to Clara's number," docs/adr/0094-appfolio-guest-card-sync.md:40,61) is already the right policy in prose — this makes it a data check the write-back adapter enforces, not a behavioral assumption that happens to hold today because write-back doesn't exist yet.

4c. New gates — owner and alert reader for each, new in revision 3 (D-13)

Plain version: this design adds several mechanisms that hold, delay, or refuse something a person or a write would otherwise get. Constitution Article III.4 requires any such gate to be registered in the guard replay registry with a 30-day replay before it merges; Article VII.9 requires every alert to name a reader and an action, or it gets turned off. None of the gates below had an owner or an alert reader named anywhere in revision 2 — this table is the fix, and none of these gates merges without its guard-replay-registry entry per Article III.4.

Existing mechanisms the engine reuses — new in revision 2

Both reviews flagged specific patterns already built and proven elsewhere in the product that this design must reuse rather than reinvent. Listed once, here, so no future step re-derives one of these from scratch.

• Content fingerprint, no-op on unchanged rows — src/lib/domain/pms/writers/guest-card.ts (fingerprints a card's content, skips re-processing an unchanged one on the next tick). Reused by the polling adapter (A-10).
• sentByUs write-back-loop guard — src/lib/domain/pms/guest-card-message-reader.ts:65-77 (flags PropFlow's own sends so they're never re-ingested as new inbound signals). Reused by the write-back provenance marker (A-08).
• historyFullyRead/liveSinceIds cold-start cutover and per-connection cursor/wall-clock-budget/fail-soft resume — lambda/appfolio-sync/handler.ts ~2867-2922 and ~1879-2140. Reused for the LeadSignal pipeline's own cold start (A-06).
• retryOnRowConflict — src/lib/domain/pms/writers/utils.ts (re-read fresh row, re-derive from the row not a stale closure, bounded retries, jitter, rethrow on exhaustion). Kept as the pipeline's per-record write primitive and the second line of defense against overlap, behind the new per-connection lease (A-03).
• resolveAppfolioAccountFromProperty, fail-closed per-property account resolution — src/lib/integrations/appfolio/resolve-account.ts. The LeadSignal contract's org/account id (A-12) and the notification-email adapter's org attribution (B-05) both inherit this discipline instead of inventing a weaker lookup.
• resolveGroupLinkVerdict, refuse-on-ambiguity household grouping — src/lib/domain/leasing/application-group.ts:178-209 (refuses to fold a card into a group when the match is ambiguous, rather than guessing). Extended to the no-group-id, no-shared-contact case (B-08's unresolved-cohabitation class) as the same refusal pattern, not a new one.
• recordDroppedNotification audit path — src/lib/integrations/email/webhook-processors.ts:524-575. Confirmed today's unknown_subscription branch already alerts (classified failed, not routine — B-06's correction); the new notification-email adapter's own "no matching org/subscription" branch routes through this same path, not a new one.
• Provenance-by-construction for settings — the resolver's {value, setBy, setAt, supersedes} shape and MAPLOG# full-undo trail (portfolio-architecture-how.html §04). Copied for person/contact fields (B-02) instead of building a second, weaker provenance story.
• Two Person rows + admin-only PLINK for the same human at two customers — the correct shape for the identity wall (portfolio-architecture-how.html D1/E3); kept as-is. The gap the reviews found (B-01) is in the consent layer riding on top of this shape, not the shape itself.
• The existing regression suite and household harness — scripts/household-harness/, src/__tests__/household-harness/, npm run household:regress. Extended, not rebuilt, for multi-source replay (section 5).

5. Stress-test plan

Plain version: before this replaces anything live, it runs against everything real we have — a million real emails, Camellia's actual inbox history, real phone calls and texts, and the mined AppFolio corpus from all three companies — and it has to come out clean. Passing hand-written test cases is not proof; replaying real history is.

• Extend, don't rebuild. The household harness already exists (scripts/household-harness/, src/__tests__/household-harness/, run via npm run test:harness:household / npm run test:harness:household:replay / npm run household:regress) and already replays real PMS records through the grouping engine, grading against known failure classes. This becomes a multi-source replay: the same harness shape, fed by every source's real corpus, not just AppFolio's.
• Corpora, kept separate by class:
  • PMS corpus (exists) — guest cards, applications, tenant records from JP&Co, Situs Group, and Western Slope, per the household-identity section above.
  • Email corpus — Camellia's real inbox history plus the other clients' lead emails, scrubbed. Human-authored and Clara-generated messages kept in separate buckets so a grader never mistakes Clara's own past reply for a new incoming signal.
  • Call transcripts and texts, as signals into the same identity/household resolution the harness already grades — not graded for conversation quality here, only for whether the resulting lead and household are correct.
• Grading classes mirror the failure types this week already named: wrong-fuse (two people merged into one), wrong-split (one person split into two), wrong-unit, wrong-role/cosigner, orphaned-sentinel, dropped-write, mis-ordered-arrival. Two classes added in revision 2: partial-pipeline-crash-replay (A-07 — a crash mid-pipeline, then the same LeadSignal redelivered, must converge to one correct result, not double-process) and unresolved-cohabitation (B-08 — two genuine roommates with no group id and no shared contact correctly stay ungrouped rather than getting fused, and that "correctly separate but not grouped" outcome is tracked as its own class, not silently swallowed into "zero failures"). Every real failure found becomes a permanent scrubbed case per Constitution Article III.1 — reproduced red on the old pipeline, green on the new one, before the fix is called done. New in revision 3 (D-14): the household harness replays a corpus synchronously through the real JSON store in a temp dir — nothing in that shape today can inject a crash mid-pipeline. partial-pipeline-crash-replay needs its own mechanism to be runnable, not just a named class: a stage-N throw behind a test flag, then a second harness invocation redelivering the same LeadSignal. This mechanism is built as part of step 3 (above), before this grading class is added to the suite.
• Target: zero failures across every corpus and every grading class before any switch flips at a real property. The Willows is the live proof on top of the corpus replay — real guest cards and real applications submitted through the actual product, checked against the production database, the same way the household-identity Willows pass (above) was run.

6. Refactor path — dark, Willows-proven, regression-gated, every step

Every step below ships dark, gets proven at the Willows, and runs clean against npm run household:regress before the next step starts. No per-property switch survives past its own proof step (Constitution: no per-property switches for correctness behavior); each step names what it deletes. New in revision 2: a "turns green" column, naming which of the 62 setup-permutation rows (below — 24 PASS · 16 FAIL · 3 PARTIAL · 22 CANNOT-EXPRESS today) that step is expected to flip, plus a step order change: the scale/idempotency fixes (A-01/02/03/07/10) move to step 3, ahead of the notification-email adapter, because the notification email is a trigger under the revision-2 design (below), not a source — it can't safely ship before the poll it triggers is itself scale-safe.

Plain version, new in revision 4 (E-10). What a real customer would actually notice, step by step: step 1 changes nothing anyone can see. Steps 2 and 3 fix bugs Fede already knows about (fused people, a stuck sync) but don't turn anything new on. Step 3.5 is invisible — it's the safety rail that has to exist before step 5 can ship. Step 4 makes the AppFolio email that already lands in a mailbox trigger a faster check for new leads, not a new channel. Step 5 is the first step a customer could actually feel — it's what lets a customer keep using their own AppFolio account as their system of record instead of PropFlow replacing it, and it doesn't ship at anyone until Fede turns it on by name. Step 6 is one new intake door at a time (a website form, a different PMS) — routine after step 2, not a redesign each time.

Ladder prerequisite, new in revision 3 (D-09): the "runs clean against household:regress before the next step starts" gate above has no mechanical enforcement today — the harness's own README states plainly, "Not wired into CI today. That is a deliberate, separate decision" (confirmed against origin/main), which means, per Constitution Article VIII.2 ("a rule nobody can check is a wish"), every "gated" claim on every step below currently depends on an engineer remembering to run it by hand. Wiring household:regress into CI as a required check, scoped to this refactor's own file footprint, is a prerequisite for this ladder — it happens before step 1's work starts, not implicitly assumed to already be true. This is still parked, per Fede, for the general repo-wide CI hook; this refactor gets its own narrowly-scoped required check instead of waiting on that broader decision. Also a prerequisite, not a ladder step (new in revision 3, C-01): the graded name-similarity gate inside ensurePersonForSignals — the shared reuse-or-mint spine every entity type composes, not just the leasing writers — is being fixed in code now as a live bug (the shared Person mint's name-agreement default for contact-only reuse, for every caller, not scoped to leasing) and is referenced below as a prerequisite PR, not folded into step 2's own effort estimate; step 2 depends on it landing first.

What this refactor does not touch, and why: rows that depend on org-structure decisions outside this design (Yale 25's company record, X11 — P-15P-51P-52), on a different product's own missing feature (AppFolio's withdraw step still needing a human click inside AppFolio itself — P-08, P-42), on the isolation gauntlet's own separate lane (staff dual-company login, batch reads, misconfigured lines — P-23, P-56, P-57, P-58, P-59), or on vendor-identity scoping across AppFolio databases (B-13 — a real, must-fix cross-tenant collision in canonicalVendorId, but a vendor/staff-identity fix, not a lead-intake one; handed to Gera's lane as its own finding, not solved here) stay open after this refactor and are tracked on their own lanes, not silently folded into "done" here.

7. Open decisions

Changed in revision 2: decision (a) now has four modes, not three (the setup-permutation gauntlet exposed a real customer — Western Slope — the three-mode design couldn't name). Decision (b) is corrected: the notification email was recommended in revision 1 as the primary intake channel; the review found that claim unproven (A-04) and it is downgraded here to a trigger for the poll, pending the test named below. A new decision (e) is added for the platform-wide opt-out mechanism the consent review (B-01) found missing.

Review log

Convergence, updated in revision 5. Rounds run: 4. Round 1 (reviewer A — concurrency/scale, 12 findings, 1 blocker; reviewer B — identity/tenancy/consent, 13 findings, 2 blockers) produced revision 2, closing 3 blocks and 9 must-fix findings, adopting 12 should-fix/note findings, and deferring 1 (B-13, Gera's lane). Verdict: one more revision. Round 2 (reviewer C — identity/consent re-walk of all 62 setup rows against revision 2, 3 findings, 1 block; reviewer D — buildability/operability, 16 findings, 2 blocks, plus a proposed gauntlet appendix) produced revision 3, closing all 3 blocks and 9 must-fix findings, adopting 4 should-fix and 3 note findings, and merging D's proposed gauntlet appendix into section 9. Verdict: one more revision. Round 3 (reviewer E — coherence/completeness re-read of revision 3, 12 findings, 1 blocker; reviewer F — full audit of every finding from rounds 1–3, 5 new findings, 0 blockers) produced revision 4, closing E's blocker and 5 must-fix, E's 4 should-fix and 2 notes, and F's 1 should-fix and 4 notes. Verdict: one more revision (E); converged (F) — F independently re-checked all 44 prior findings against current code and found every one still holds. Round 4 (reviewer G — fresh eyes, reading revision 4 cold, 5 findings, 0 blockers) produced this revision (5). G's verdict was "not converged — one more revision": F-02's fix to T-14 and E-02's new T-19 row, both landed in revision 4, were never cross-checked against each other, and G-01 caught the result — T-19's either/or outcome, unreconciled against T-14's same-revision tightening, was a real self-contradiction on the design's single most safety-critical row. G-01 through G-03 (all "must fix before build") and G-04 (should fix) and G-05 (note) are resolved below with a concrete change — T-19 tightened to match T-14 exactly (G-01), P-03/P-20/P-38 re-verified against the current origin/main tip with P-38 flipped PARTIAL → PASS (G-02), the step 3.5/step 5 contradiction over gauntlet row T-08 corrected (G-03), a legacy SMS-consent migration posture stated (G-04), and the household-precedence text reworded to cite T-14/T-19 as pinning tests rather than the rule itself (G-05). Open items after round 4: none blocking. The prerequisites this document has always named as build-order facts, not design gaps, remain open in code as of this revision, unchanged by round 4: the CI wiring for household:regress (D-09), the ensurePersonForSignals name-agreement prerequisite PR (C-01), and the separate pickBestProspect prerequisite (E-02) and the rental-application enrollment-seam gate (E-01/T-18) — G-02 confirmed the one substantive commit landed since revision 4 (#7464) touches neither. B-10's CRM-mode-transition design and B-13's vendor-identity fix remain named, scoped-elsewhere gaps, exactly as in round 1's resolution.

Every finding from the two adversarial reviews (reviewer A — concurrency/scale, 12 findings, 1 blocker; reviewer B — identity/tenancy/consent, 13 findings, 2 blockers), and how this revision addresses it. All 3 blockers and all 9 must-fix findings are resolved with a concrete design change, above; every should-fix and note is resolved or explicitly deferred to a named, separate lane below — none were silently dropped.

Round 1 — resolved: 24. Deferred to a named separate lane: 1 (B-13, Gera's vendor/staff-identity lane). Rejected: 0. Round 2 (revision 3) — resolved: 18 of 19 findings with a concrete design change (3 blocks, 9 must-fix, 4 should-fix, 3 notes, one of which — D-05 — resolves itself once D-02/D-03 are addressed). Rejected: 0. Round 3 (revision 4) — resolved: 17 of 17 findings with a concrete design change (1 blocker re-opening D-02, 5 must-fix, 4 should-fix, 2 notes from reviewer E; 1 should-fix, 4 notes from reviewer F). Rejected: 0. Round 4 (revision 5) — resolved: 5 of 5 findings with a concrete design change (0 blocks, 3 must-fix before build, 1 should-fix, 1 note from reviewer G). Rejected: 0. Every block, must-fix, should-fix, and note from all four rounds got a concrete design change within this document, except B-13 (round 1), which is a real, confirmed cross-tenant hazard outside lead-intake's scope and is handed to Gera's lane rather than solved here, and B-10's CRM-mode-transition design, C-01's underlying fix, and the separate pickBestProspect prerequisite (E-02) and the rental-application enrollment gate (E-01), all of which are named as prerequisites/separately-scoped work rather than solved inline — each named explicitly so nothing silently falls through the gap between two designs or two pieces of work.

Sources: origin/main of the propflowai repo, read 2026-09-09: agents/clara/lib/agent/tools-leasing.ts (handleSaveProspectImpl:2065, unit-id helpers targetUnitIdFromLabel/stripListingPropertyPrefix:1981,2016, self-email guard:2192-2203, ADR-0101 on-behalf guard:614,2105,2116) · src/lib/domain/identity/resolve.ts (resolveProspectIdentity:571, gatherProspectCandidates:385, pickBestProspect:354) · src/lib/domain/pms/writers/guest-card.ts (syncPropertyGuestCards:691, group-suppression counters ~738-741, external-id match ~823-828) · lambda/appfolio-sync/handler.ts (resolvePersonByContact:2728, sync call site:2793) · src/lib/data/dynamo/leasing.ts (saveProspect:589) and src/lib/domain/identity/prospect-spine-stamp.ts (wraps ensurePersonForSignals) — both writers converge here, the sync path via saveProspect rather than a direct call · src/lib/domain/pms/types.ts (PMSGuestCard:569) · src/lib/data/types.ts (emailIntegration:3082, EmailIntegration:13109) · src/lib/integrations/email/webhook-processors.ts (findIntegrationBySubscription:419, call site:706, unknown_subscription:709) · src/lib/integrations/email/property-graph-sender.ts (sendPropertyEmail:278, reads emailIntegration:286) · config/phone-registry.json, src/lib/domain/properties/phone-registry.ts · src/lib/data/dynamo/persons.ts (claim keys:17-18, dedup sentinel:18,540,612,979), src/lib/domain/identity/person-stamp.ts, src/lib/domain/identity/resolve-known-applicant-person.ts, src/lib/domain/identity/backfill-person-contact.ts (the contact-restamp gap, prod 2026-07-26/08-07) · src/lib/domain/leasing/household/{resolve.ts,co-pendency.ts,writers.ts} · src/lib/integrations/appfolio/message-sender.ts · appfolio-browser-agent repo, origin/main (lib/guestCardMessaging.ts: "NEVER creates a guest card" per its own doc comment) · docs/adr/0094-appfolio-guest-card-sync.md (Status: Proposed, not yet finalized in the doc itself) · scripts/household-harness/, src/__tests__/household-harness/, package.json (household:regress and related scripts) · lambda/appfolio-sync/schedules.json (guest_cards: rate(15 minutes); rental_applications: rate(5 minutes)) · git log for #7417, #7420, #7424, #7439, #7441, #7444, #7455, #7462, #7327 · ~/.claude/CONSTITUTION.md, ~/.claude/propflowai/CLAUDE.md, ~/.claude/propflow-vision-2026-08.txt. Corrected from the original brief: the household-reminder fix is #7327, not #7466 (no #7466 commit exists). Could not verify: an exact PR number for the cosigner-marker/shared-phone-from-claims fix (content matches commit 0c1b240c39 closely; no PR number appears in its log entry) or for the guest-card-contact-restamp fix (content matches backfill-person-contact.ts, documented against a 2026-07-26/08-07 production gap; no PR number found). restamp-person-contact.ts, named in the original brief, does not exist — backfill-person-contact.ts is the real file and is cited above instead.

Revision 2 sources (2026-09-09): two independent adversarial design reviews (concurrency/scale, 12 findings; identity/tenancy/consent, 13 findings), both checked against origin/main of the propflowai repo at commit 65ea04b60953e58b93565983a6e8c48197ead258, confirmed current as of this revision (git fetch, read-only, no working-tree checkout). Additional files read for revision 2: src/lib/platform/resilience.ts (appfolioBreaker:308, single module-level instance; appfolioPolicy:312; 429-cliff comment:320) · src/lib/domain/pms/writers/utils.ts (retryOnRowConflict:48) · src/lib/domain/pms/writers/guest-card.ts (content-fingerprint comments ~275-331, ~501-512; unwindowed status: 'all' fetch, ~496) · agents/clara/lib/data/dynamo/compliance.ts (SmsConsentRecord access pattern, PK CONSENT#{phone}) and agents/clara/lib/data/types.ts (SmsConsentRecord:2167-2176 — no channel/fromNumber field) · src/lib/domain/identity/resolve.ts (gatherProspectCandidates, cross-org helpers) and src/lib/data/store.ts (findPersonsByPhoneAcrossOrgs:3147, findPersonByEmailAcrossOrgs:3179) · docs/adr/0094-appfolio-guest-card-sync.md (lines 40, 61 — consent-rationale prose) · src/lib/integrations/appfolio/message-sender.ts (sendGuestCardMessageL4, no consent references) · src/lib/domain/vendors/vendor-write-invariants.ts (canonicalVendorId:46-73, no database qualifier) · src/lib/domain/leasing/application-group.ts (resolveGroupLinkVerdict:178-209) · src/lib/integrations/email/webhook-processors.ts (DROPPED_NOTIFICATION_IS_ROUTINE:524-575, confirms unknown_subscription is failed, not routine) · portfolio-architecture-how.html §§04-05 (resolver provenance shape, wall/consent framing) · household-identity-2026-09-08 (Willows E2E proof table, above).

Revision 3 sources (2026-09-09): two further independent adversarial design reviews against revision 2 — reviewer C (identity/consent re-walk of all 62 setup-permutation rows, 3 findings) and reviewer D (buildability/operability, 16 findings plus a proposed gauntlet appendix) — both checked against origin/main of the propflowai repo at commit 1b938ffecb1effc628e0d80121558d460cc74aed (2026-09-09), git fetch, read-only, no working-tree checkout. This revision itself re-confirmed the repo's tip at commit 71eacc5b8e2cb1530b68c52c706df754f62ed72f (2026-09-09, #7461, CI cost-routing only) — one commit ahead of both reviewers' cited tip; the delta touches only CI test-lane logic, not any file this design cites, so no finding or code claim above needed re-verification against it. Additional files read/spot-re-checked for revision 3: src/lib/domain/identity/resolve.ts (pickBestProspect/gatherProspectCandidates, confirmed no name comparison in the reuse path) · src/lib/domain/identity/person-stamp.ts (ensurePersonForSignals header comment, confirmed shared across Tenant/ProspectInquiry/VendorCompany/User/Conversation call sites) · src/lib/domain/identity/tenant-spine-stamp.ts (applyTier1IdentityOverwrite:196, unconditional rename after name-blind reuse, confirmed) · src/lib/domain/pms/writers/guest-card.ts (never-enroll/onFreshProspectMinted comment ~29-40, confirmed pinned by a never-called test) · scripts/household-harness/README.md (confirms "Not wired into CI today. That is a deliberate, separate decision," line 40) · docs/adr/0094-appfolio-guest-card-sync.md (Status: Proposed, confirmed unchanged) · src/lib/integrations/appfolio/resolve-account.ts · unit-count figures: Situs Group 640 units (live AppFolio dashboard, cited in the setup-permutations customer profile above), Western Slope ~250 doors (Jason, Sep 4 call, cited in the onboarding audit above) — used for the D-12 polling-budget worked example, request-count math shown inline, payload-bytes figure explicitly named as an open measurement, not invented.

Revision 4 sources (2026-09-09): two further independent adversarial design reviews against revision 3 — reviewer E (coherence/completeness, 12 findings) and reviewer F (full audit of all 44 prior findings plus 5 new ones) — checked against origin/main of the propflowai repo, git fetch (read-only, no working-tree checkout), tip 20dac1348f5f696ebe0b477f03d19b09100befac (2026-09-09, #7463) — one commit ahead of both reviewers' independently-fetched tip; that commit is not CI-only (it fixes setup-permutation row P-21, above) and was checked directly rather than assumed immaterial. Files read/spot-re-checked for revision 4: src/lib/domain/pms/writers/rental-application.ts (onFreshProspectMinted declared ~284, called ~2184; mapApplicationStage ~612; "WIRED BUT INERT TODAY" header comment ~260-275, confirmed) · src/lib/domain/leasing/pms-mint-engagement.ts (header comment confirming the three-check stand-down and that guest cards are "deliberately NOT wired," rental applications ARE wired and stand down only via mapApplicationStage) · src/__tests__/appfolio-rental-application.test.ts (confirmed test spies assert onFreshProspectMinted IS called on fresh mints — the opposite polarity from the guest-card writer's never-called pin) · src/lib/domain/identity/resolve.ts (pickBestProspect:354, gatherProspectCandidates:385, re-confirmed zero references to person-stamp.ts) · src/lib/domain/identity/person-stamp.ts, src/lib/domain/identity/prospect-spine-stamp.ts (confirmed as two separate files — person-stamp.ts holds ensurePersonForSignals, prospect-spine-stamp.ts wraps it for the leasing writers; neither file references resolve.ts's functions) · src/lib/domain/pms/writers/guest-card.ts (resolveStage now at ~495, function and one-directional behavior unchanged from revision 3's citation) · src/lib/domain/identity/backfill-person-contact.ts (restampPersonContact:334, the #7463 fix — fill-or-change contact restamp, gated on name agreement) · lambda/appfolio-sync/handler.ts (restampPersonContact wired live ~2789-2858, confirming #7463 is in production, not just merged). Corrected from revision 3: the rules ledger's never-auto-enroll row previously implied the seam is declared inside guest-card.ts itself; on re-check, guest-card.ts only narrates the seam in its header comment and never declares an onFreshProspectMinted parameter — the seam is declared and called in rental-application.ts only, and guest cards simply have no enrollment hook wired to them at all. This distinction is now stated correctly in the ledger.

Revision 5 sources (2026-09-09): one further independent adversarial design review against revision 4 — reviewer G (fresh eyes, 5 findings) — checked against origin/main of the propflowai repo, git fetch (read-only, no working-tree checkout, no edits), tip 229c8f6cd586998d2157b86558debe253adbc337 (2026-09-09) — two commits ahead of this document's revision-4 re-confirmed tip (20dac1348f, #7463). The intervening commit that is substantive rather than mechanical is a9353b392475cda5267fc9a57f184b8bd639c32e (#7464, "Fix two household co-pendency gaps: bare cosigner role + cross-tick shared-phone signal"), read directly (13 files, 1094 insertions): src/lib/domain/leasing/household/co-pendency.ts (new coPendencyRoleEvidence, org-salted contact fingerprints replacing raw values), src/lib/domain/leasing/household/writers.ts (applyRoleEvidence's role correction and never-zero-primaries guard), src/lib/domain/pms/writers/rental-application.ts (cross-tick contact-fingerprint pool seed) — confirmed this touches none of resolve.ts, person-stamp.ts, or tenant-spine-stamp.ts (T-14/T-19/C-01/E-02 unaffected) and none of mapApplicationStage/onFreshProspectMinted (T-18/E-01 unaffected). The two remaining commits to the current tip — fb833206d6 (#7468, claim-without-sentinel self-heal) and 229c8f6c (#7459, AppFolio credentials moved to the company) — were read and confirmed unrelated to household co-pendency, identity resolution, or consent. New test coverage read directly: src/__tests__/household-harness/scenarios.ts (BARE_COSIGNER_SEED_WITH_UNRELATED_RECORDS, SHARED_PHONE_SEED_DIFFERENT_UNIT fixtures) and src/__tests__/household-harness/simulate.test.ts (the "a THIRD, unrelated same-unit applicant makes the bare flag AMBIGUOUS — no link at all, never a guess" case, confirming P-38's over-fusion shape now fails closed rather than swallowing the stranger).

8. Setup permutations (gauntlet rows, draft)

Plain version: every customer answers eight questions when they onboard — which PMS, which plan tier, how many PMS databases, who owns the CRM record, which doors leads walk through, who Clara replies as, how the org is shaped, and what shape the actual leads take. The rows below run real combinations of those eight questions through today's code the way the isolation gauntlet (T1–T14) already runs identity/org questions through it — one row, one scenario, one verdict, cited to a file or a PR. This table is proposed — draft, same status as the rest of this section: it names what the engine can and cannot express today, it does not change anything, and every FAIL becomes a scrubbed corpus case (Constitution III.1) before any fix ships.

Pruning rules — why 62 rows, not several thousand

The raw cross-product of the eight dimensions in the brief is enormous (4 PMS × 3 tiers × 2 DB-counts × 3 CRM modes × 256 channel subsets × 4 reply identities × 5 org shapes × 12 lead shapes) — multiplied out, roughly 4.4 million combinations (new in revision 4, E-11: stated in prose rather than left for the reader to compute). Three rules cut that down to the 62 rows that actually distinguish a verdict:

• Plan tier and DB-count only vary where they change what the code does. Plan tier gates exactly two things today — Reports API read access (Plus+) and write access (Max) — and nothing else reads it (src/lib/integrations/appfolio/pms-adapter.ts); a row exists for each gate, not for every tier × channel combination. DB-count only matters for AppFolio, and only where two-database account resolution is exercised (src/lib/integrations/appfolio/resolve-account.ts) — it is collapsed everywhere else.
• Channel and reply-identity dimensions are read off the real per-customer matrix, not the full powerset. Each customer group below uses the channels and reply identity it actually runs (or is scheduled to run) per the integration map, above, plus one or two adjacent combinations that stress a real gap (a race between two channels, a channel that needs a plan tier the customer doesn't have). Channel combinations no customer is near — e.g. generic webhook + staff-entered + phone, all four reply identities at once — are pruned as equivalent to their simplest constituent row: if channel X alone is CANNOT-EXPRESS, adding channel Y to the combination doesn't change that verdict.
• Org shape and lead shape are crossed only with the dimension each one actually stresses. Org-shape rows (staff across two customers, shared vendor numbers, sub-orgs) reuse the isolation gauntlet's own T1–T14 verdicts rather than re-deriving them, because that gauntlet already ran exactly these combinations against the identity/phone/calendar code. Lead-shape rows (cosigner, shared phone, same-name strangers, etc.) are crossed against each customer's actual intake+identity engine, not against every reply-identity or org-shape variant, since household grouping and reply identity are independent code paths per the integration map's own framing ("a fast intake channel and a slow reply identity... fixing one does not fix the other").

Net: every real customer's actual setup gets full lead-shape coverage (the dimension Fede asked the Willows proof to run first); every dimension gets at least one row that isolates it; nothing is duplicated across two rows expected to verdict identically for the same reason. New in revision 2: the refactor path above (§6) now names, step by step, which of these 62 rows (24 PASS · 16 FAIL · 3 PARTIAL · 22 CANNOT-EXPRESS today) it turns green, and which stay open past this refactor because they depend on a separate lane (partner programs, org-structure decisions, other PMS clients, Gera's vendor-identity fix).

Camellia (JP&Co) — AppFolio, jpco.appfolio.com, 1 DB

Setup: AppFolio, plan tier ungated here (writes go through browser-session replay, not the official write API — docs/adr/0094-appfolio-guest-card-sync.md), 1 database, CRM mode PropFlow-only (ADR-0094, unreversed at Camellia), intake = guest-card pull every 15 min + AppFolio lead-notification email over the connected mailbox + calls/texts to Clara's number, reply = connected Microsoft mailbox (camelliaapts@jp-co.com) + Clara's number, org shape = single property, single company.

Yale 25 Station (ConAm) — sits under JP&Co's AppFolio company record, real PMS is RealPage/ILM

Setup: PMS on paper is RealPage (migration in progress off ILM Lead Manager), but Yale 25's property row lives under JP&Co's AppFolio company record (decision X11) — a company/PMS mismatch, not a clean single-PMS case. Intake = yale25@ mailbox + shared jpco guest-card pull (unconfirmed whether Yale 25's actual leads ever create AppFolio guest cards at all). Reply = yale25@ property-specific mailbox we created. CRM mode = "PropFlow replaces" (Fede's stated intent for RealPage), org shape = property administratively parked under the wrong company.

Situs Group — AppFolio, situsgroup.appfolio.com, 1 DB, separate from jpco

Setup: AppFolio, Plus tier (read-only Reports API; write needs Max), 1 database distinct from jpco's, CRM mode undecided (no company record of its own — administratively near JP&Co), intake = guest-card pull, but most applications land in TurboTenant/Tenant Turner outside AppFolio entirely, reply = none working today (Google Workspace sign-in exists but send/read don't; Phase 2 plan is to forward their leasing inbox), org shape = staff overlap with JP&Co's admin surface (no company record of its own).

Western Slope — AppFolio, westernslopepm.appfolio.com, 1 DB, read-only lock

Setup: AppFolio, upgraded off Core 2026-09-09 (tier to confirm, Plus or Max), 1 database, intake = listing-site lead email to leasing@westernslopepm.com (the only automated path Core allowed; guest-card pull becomes available once tier is confirmed), reply = connected Microsoft 365 mailbox, org shape = single property, single company — but AppFolio access here is explicitly read-only, writes locked by Fede's decision ("it stays read-only, no writes there, the lock stays on," 2026-09-09), which the proposed engine's three CRM-of-record modes don't cleanly name.

Willows (test bench) — AppFolio jpco, sandbox property, AppFolio guest-card messaging live

Setup: same jpco AppFolio account as Camellia, same 15-minute guest-card cadence, but the only property anywhere with Property.messagingDelivery === 'pms' — reply identity is AppFolio's own guest-card messaging (browser-session replay, no official API at any tier). Org shape = single sandboxed test property, walled by #7442's refusal to clear/park/reset/wipe/seed a non-test property. These eight rows are the actual first-pass Willows end-to-end proof (above), run as real AppFolio applications and checked in the production database — reproduced here as gauntlet rows rather than restated.

Future — no current customer has this setup

These rows exist to name a gap before a real customer hits it, per Constitution VII.10 ("their identifiers entered as data, never as code") — not because a design decision is owed today. Org-shape rows reuse the isolation gauntlet's own verdicts (portfolio-architecture-how.html, "The isolation gauntlet — T1 to T14") rather than re-deriving them.

Row count: 62 rows (P-01–P-62) after pruning. Verdict counts, today (by pill, counted directly from this table's markup): 24 PASS · 16 FAIL · 3 PARTIAL · 22 CANNOT-EXPRESS — 65 verdicts across 62 rows because three rows carry two verdicts for two sub-cases within one setup (P-09: same-source redelivery vs. cross-source dedup; P-18: ingestion vs. reply; P-56: T6 vs. T14). P-21 flipped FAIL→PASS in revision 4 (E-12): #7463 landed on origin/main during this review round and fixes exactly the gap that row named. Sources: everything cited inline above, plus origin/main of the propflowai repo read 2026-09-09 — src/lib/domain/pms/registry.ts (getPMSClient, the yardi/realpage cases gated by isMockPmsEnabled()) · src/lib/data/types.ts (OrganizationPms:12626, RealPage migration-drain field and isRealPageIlmTrackingSender doc comment ~3493-3499, pmsSource:3468) · src/lib/integrations/appfolio/resolve-account.ts, config.ts · src/__tests__/household-harness/scenarios.ts:1721, README.md:648-694 (autoLinkCoApplicants, default off, per-property) · the household-identity section's Willows end-to-end proof table and "What the real-data test run found," above · the integration map and its per-customer matrix, above · portfolio-architecture-how.html, "The isolation gauntlet — T1 to T14" (scripts/portfolio-harness/gauntlet/results/latest.md:9-22) · PRs #7417, #7420, #7424, #7435, #7439, #7444, #7445 · docs/adr/0094-appfolio-guest-card-sync.md (Status: Proposed). Labeled inference, not fact: P-15, P-16, P-26 describe shapes not yet observed in real Yale 25/Situs traffic — they follow deductively from the code gaps cited, not from an incident.

9. Executable gauntlet (planned) — new in revision 3

Plain version: sections 6 and 8, above, name a lot of things that should be true once this refactor ships — a family member sharing a phone never overwrites the wrong tenant's name, a consent refusal actually refuses, a crash mid-pipeline never doubles a lead. This table turns those claims into one runnable table: one row, one scenario, one expected outcome, one assertion, cited to a file, modeled directly on the portfolio harness's own gauntlet (scripts/portfolio-harness/gauntlet/, T1–T14) and the household harness (scripts/household-harness/). It merges reviewer D's proposed L-01..L-10 rows with the setup-permutation rows above that read FAIL or CANNOT-EXPRESS today and aren't already an explicit regression target elsewhere in this document. Every row here becomes a real test in the household harness before the step it's cited against is called done — this table is proposed — draft, same status as the rest of this section, and does not change anything by existing.

Rows T-01–T-03, T-06, T-07, T-09, T-11–T-13, T-15–T-17 are runnable today as a baseline against the two existing writers, and re-run unchanged against the merged writer once it lands (fixed in revision 4, E-09 — the prior wording said "runnable today" and "once the unified writer exists" in the same clause, which contradict each other as written). Rows T-04, T-05, T-08, T-10, T-14, T-19 depend on pipeline stages or fixes this design hasn't shipped yet (steps 2–5, C-01's prerequisite PR, D-14's crash-injection mechanism, and — new in revision 4 — the separate pickBestProspect prerequisite T-19 needs) and are expected CANNOT-EXPRESS or FAIL until those land; T-18 is runnable today and is expected to PASS by accident (the stage-mapping stand-down), which is exactly the state this row exists to keep visible — same polarity convention the isolation gauntlet and the P-01–P-62 table already use. This table does not attempt to re-litigate every one of section 8's 39 FAIL/CANNOT-EXPRESS verdicts individually — the ones not listed here already have an explicit regression target named against a refactor step in section 6 (e.g. P-19/P-26 against the adapter step 6, P-47/P-48 against a future PMS-client integration outside this refactor's scope) and gain their own gauntlet row when that step is scoped in detail, not before.

Date: 2026-09-16. Trigger: a Camellia resident with a lease and a move-in date was treated as a stranger on two calls (9/15, 9/16) because two sync writers fought over his phone record every minute. Fede: "seems like a bigger architectural issue", "take some time to think this through", "this has to work beyond just AppFolio, like Yardi." Decisions on the engine are deferred until after the Western Slope go-live on 9/17 (Fede, 2026-09-09).

Sources read: 18 ADRs and design docs, ~60 PRs (May 4 → Sep 16), the 2026-09-09 authoring session, memory rulings from 8 sessions, the constitution and lanes, Gera's portfolio architecture page, the shared PMS layer and the Yardi/RealPage adapters, public docs for Yardi, RealPage, Entrata, Buildium.

1. What was decided, and when

2. The writers today

Nine paths write a person's phone or email record, each born from one incident, each encoding one local rule, none aware of the others:

1. Tenant sync from the rent roll, every 5 minutes. Promotes its number, demotes the previous one. AppFolio-only code; bypasses the shared PMS layer.
2. Guest-card sync, every 1 minute since the 9/13 cadence cutover. Three sibling functions: fill-if-empty (Aug 9), overwrite-and-retire (Sep 9), add-as-secondary (Sep 10). Which one runs is the caller's judgment; nothing enforces it.
3. Rental-application sync.
4. Person merge (Aug 14) and the row consolidation after it (Sep 10).
5. Household auto-link (Sep 9).
6. The call-start webhook, which mints a skeleton person for an unknown number.
7. Voice and SMS lanes, which write names, not contacts, under their own precedence.
8. Admin and login paths (manual claims, cross-customer link).
9. Maintenance scripts. One was found writing dedup rows raw, bypassing the only sanctioned producer (Sep 6). Two more are known and unaudited.

Readers disagree too: the call-start lookup reads retired rows; the general lookup does not. That difference is documented in one PR body and one code comment.

3. The pattern in the incidents

Fourteen identity incidents since April. Six are the same shape: two writers disagree about one person, on their own clocks.

• Jul 21: AppFolio corrections landed on an orphan duplicate instead of the bonded person.
• Aug 15: a corrected email landed as secondary, the dead typo stayed primary.
• Sep 9: the fill-if-empty rule dropped a corrected phone, so a later record minted a duplicate. The fix for this is the writer now causing the churn.
• Sep 10: two overlapping sync runs minted duplicate rows.
• Sep 11: repeat inquiry forked a household; one person split across two households.
• Sep 15 and 16: this churn. Tenant sync and guest-card sync alternate ownership of one number; the resident is unresolvable most of every 5-minute window.

Each fix was correct for its incident and moved the problem to the next writer. The Sep 9 session's 18 progress reports never contain the word "tenant".

The dedup sentinel, a second row in a different partition that must live and die with its claim, has caused four incidents and is fenced by "never hand-delete" warnings in four separate memory files. It has self-heal in both directions now. It has not been redesigned.

4. What holds beyond AppFolio

• A shared PMS layer exists and already normalizes guest cards and applications to one shape for any PMS. Yardi and RealPage adapters are partly built; RealPage's application feed is a mock because that tier has no real API.
• Tenant contacts do not go through that layer for AppFolio. They are parsed from raw report fields inside an AppFolio-only writer. The Yardi adapter does it properly, which shows the layer works when used.
• AppFolio links a guest card to its application with a shared inquiry id. None of Yardi, RealPage, Entrata or Buildium documents a person id that survives lead to resident. For every other PMS, matching by phone and email carries the whole load.
• Change detection: RealPage and Buildium push webhooks; Yardi and Entrata are poll-and-diff. Today's code assumes polling everywhere.
• The credential store is still typed to AppFolio only.

5. Governance facts

• This work is not a registered lane. The constitution says unregistered work does not change product behavior; it has changed it in at least 20 PRs.
• ADR-0094 governs live writers while still "Proposed". ADR-0018 still describes a suggestion-queue phase Fede rejected. ADR-0018's trust tier for the AppFolio sync disagrees with the shipped code.
• Proof standard on record (Fede, Sep 8): "prove it in production end to end at the Willows with real guest cards, real application submissions, with all the permutations." Unit tests are not proof. No test drives two production writers against one person; the household harness grades an end state. The "second pass writes nothing" harness now in flight is the first idempotence gate.
• Fede's rule for contact data (Sep 16): "it comes in during onboarding, and mostly never changes unless the office goes update email / phone which is rare but we should catch it." And: "where someone is already past the guest card stage and about to be a tenant, we are overriding" must stop.

6. Questions the review has to answer (after 9/17)

1. What is the authority order between sources for one person's contact info, and does it hold for every PMS? Tenant record over application over guest card is Fede's stated instinct. Where do PM-typed and human-verified values sit? Answered 2026-09-16, see the ruling above.
2. Who may write a claim? Is there one enumerated, enforced list, or does the inventory keep being rebuilt incident by incident?
3. Since a person may hold several live values per type, what does "primary" mean per channel, and which reader definition of "live" is the one?
4. Does the two-row dedup sentinel stay, with self-heal, or does the design change?
5. One person per human per org, plus a link across orgs: is that the settled model, and does it replace the May wording?
6. Is idempotence a required property of every writer, gated in CI by the new harness, and is cadence then free to be whatever the product needs?
7. For PMSs with no stable person id and no application feed, what counts as "a person entering the system"?
8. Does write-back to the PMS exist as a concept? ADR-0094 rejected it; a write path is now proven at the Willows; the reversal awaits Fede's word.
9. What is the proof for any of this: the Willows permutations, the household corpus replay, the idempotence harness, all three?

7. In flight today, nothing else

• Tourniquet PR #8894: the guest-card writer demotes instead of retiring, is a no-op when the value is already on file, never re-adds a value the person's history retired, and carries the tenant-outranks-guest-card rule dark. Held by Fede, 2026-09-16: wrong shape under the stage ruling.
• Harness PR (branch fede/sync-idempotence-harness): second pass over the same payload writes zero claims. Red today on the two-number case.
• No design has been written. No engine work starts before 9/17.
• Fix landed 2026-09-17: the guest-card sync gates on lifecycle anchor (tenant record not ended, future move-ins included, or an application) and makes no primary-moving write for anchored people. Live in prod 01:30Z; Willows two-number proof passed (recognized from both numbers, no churn). Old values retired before the fix stay retired (Fede, 2026-09-17).

This section is about intake speed only. For the full per-channel, per-customer picture — including reply identity — see Integration map: how a lead reaches Clara, and who Clara replies as, just above.

The question

Every new lead deserves a response within 60 seconds. Today's guest-card pull from AppFolio runs every 15 minutes. That 15-minute window is a bottleneck: conversion rates are 35x higher when first contact occurs within 5 minutes vs. over 1 hour.

How a lead reaches us today

Two doors deliver leads to Western Slope:

• Lead email to the property's connected mailbox. AppFolio relays every syndicated lead (Zillow, Apartments.com, ILS partners) as "New Lead" email to leasing@westernslopepm.com, seconds after it lands in the listing site. This is the fastest path today.
• AppFolio guest-card pull. Every 15 minutes, Clara polls the AppFolio Reports API for new guest cards (property → guest-card list, date-filtered). Up to 15-minute latency. Full-list diff is needed because date filters may be ignored on the guest-card report.
• Rental applications, every 5 minutes. A separate polling job syncs applicants into the leasing CRM (LeadSimple, Knock, Respage, etc.); latency is ~5 minutes on average.

What AppFolio offers

How the competitors do it

Industry benchmark for first response: 60 seconds or less. Here's how 13 leasing CRMs and AI assistants integrate with AppFolio and list-management platforms:

Key finding: Leasing CRMs claim dedup via unified CRM, but only LeadSimple documents an explicit "Duplicate Lead Checker." None document household or co-applicant grouping. LeadSimple's dedup tool requires manual merge; household logic is vendor-specific and incomplete across the board.

Options

A. 60-second incremental pull per AppFolio database — recommended, and pursue B in parallel

How it works: One polled request per AppFolio database per minute across all properties. Diff new guest cards by ID against the last known state; keep a 15-minute full-pull as the safety net. Incremental pulls stay within the ~1 request/second Reports API limit on Plus plans. No permission gate beyond the Plus tier upgrade (Western Slope upgraded off Core as of 2026-09-09; tier to confirm; Situs is Plus).

Timeline: Builds this week. Owner: Ours to build; requires no partner application.

Latency: Up to 1 minute per database. Faster than today's 15-minute pull; aligned with the 60-second response SLA.

Trade-off: Still polling, not real-time; misses the 30-second Respage benchmark. Real-time arrives via option B.

B. Apply to the AppFolio Stack partner program for guest-card webhooks — real-time, parallel to A

How it works: Submit the partner application, complete the security questionnaire, and request confirmation that "new guest card" is a published webhook event (it may not be; must verify with AppFolio). On approval, configure signed HTTP webhooks to deliver guest cards in real-time as they land in AppFolio.

Timeline: Partner application and questionnaire: 2–4 weeks. Confirmation of event availability and webhook setup: same cycle.

Latency: Real-time (seconds after guest card created in AppFolio).

Owner: Fede's call to start; partnership coordination with AppFolio required.

Trade-off: Longer cycle time, but real-time delivery. If guest-card is not a published event, the application may be rejected for that specific use case.

C. Direct Zillow and Apartments.com lead feeds as a registered vendor — structured, bypass AppFolio

How it works: Register directly with Zillow Lead API and Apartments.com as a lead recipient. Prospect submits on Zillow or Apartments.com, lead posts directly to our endpoint, skipping AppFolio entirely. Structured JSON with phone, email, beds, move-in, source, and listing URL.

Timeline: 4–6 weeks onboarding per feed (testing, security approval, credit check per vendor).

Latency: Seconds (direct from listing site to our system).

Owner: Fede coordinates with vendors; engineering builds the webhook receiver.

Trade-off: Does not cover non-Zillow/Apartments.com sources (property website, ILS partners, AppFolio's own inquiry form). Western Slope lists on Apartments.com and Zillow, so this covers the majority of online leads. Situs Group will have broader exposure; C becomes more valuable there. Requires dedup/household logic to handle the same lead arriving via AppFolio guest card AND Zillow feed simultaneously.

Note on the lead-email mailbox (fastest today)

The lead-email path (ILS syndication email to leasing@westernslopepm.com) remains the fastest available without permission gates or partner applications. Email delivery is seconds after a prospect submits. This is the only path available on AppFolio Core plans. For Western Slope (upgraded off Core as of 2026-09-09; Reports API key arriving this week; tier to confirm), the email mailbox remains a fast path; guest-card pull via Reports API becomes available once tier is confirmed.

Sources: AppFolio Stack Partner Program · AppFolio Stack APIs · Skywalk API for AppFolio Guest Cards · AppFolio Realm-X Leasing Performer · LeadSimple AppFolio Setup · Respage ResMate Case Study · Zillow Lead API · Apartments.com Integration with AppFolio

Sep 4 demo transcript (raw) · Sean's proposal PDFs (Sep 4) · Situs AppFolio dashboard and occupancy report, read-only, Sep 5 · Western Slope AppFolio listings and pomonaparktownhomes.com, Sep 5 · production unit counts · GitHub merged-PR authorship · repo voice config and drift audit · ElevenLabs and Google docs · Colorado SOS mirrors.