Updated 2026-09-04: Section 14 adds the first real Camellia card (Hanna Sterling / unit 305), the Camellia unit sweep, the design-audit verdict + decisions, a follow-up audit on why listings never post automatically (D13), and industry research on resilient autonomous leasing with an open question on Clara recording a move-out notice for the office (D14). The earlier "invisible one-bedrooms" finding in §2 is withdrawn — see §5.
Someone applies, we approve them — and the automation stops. This is the investigation into Clara owning everything after approval: screening on arrival, the congratulations message with the lease link, preparing and sending the lease in AppFolio, chasing signatures, and answering "what's next?" from real state. Human does two things: give the tour, approve the application.
The company premise is that Clara does the work and humans supply judgment. "Lease the unit" is one of the four outcomes the architecture doc names as Clara's to own — but neither vision doc breaks down what happens between "approved" and "moved in." This page does.
The customer feels the same pain: Joanna told us on Aug 20 she's rarely in the office right now and welcomed Clara handling more of this ("That works. Yeah."). And in our own test conversations, approved applicants who ask "will I get a lease to sign?" still get told "the leasing team will follow up with you" — sometimes three times in a row. Today, nothing at all fires when an application flips to Approved: the system only reacts if the applicant writes in first.
From AppFolio's own records for the ~24 move-ins since late April, plus the July 20 site-visit walkthrough and AppFolio's documentation:
Pulled 2026-08-21 from the live ledger and lease reports. These are the rules Clara gets trained on — as policy defaults, never hardcoded (this must work for any client on thousands of properties).
allowedTermMonths: [6, 12]).Resolved (Fede, Aug 22): the fee is $38 — that's what the applicant pays and what Clara quotes. The $33 on the ledger is $38 minus AppFolio's own $5 processing fee. So both numbers were right all along (gross vs. net); there was no error, just the platform's cut. See Decision 1 below.
If you move in on the 15th of June and rent is $1,150, you pay for the 16 days you actually live there that month: $613. If you signed a 12-month lease with the special, July — your first full month — is free, but you still paid for those 16 June days, plus your $300–400 deposit and the application fee. That's the exact math Clara has to get right every time, because it's real money on real ledgers.
A person shows the apartment and says yes to the application. Clara does literally everything else: runs the background checks the moment the application arrives, congratulates the approved applicant with their lease link minutes after approval, builds the lease with the right dates and dollars, chases everyone until it's signed, fixes it if they change their mind about the term or the date, and answers "what's happening with my lease?" at 11pm with the actual status.
| Piece | Status | Detail |
|---|---|---|
| Approval visible in our data | Exists | Application status + approved-timestamp sync every ~5 min; stage hooks fire on the transition (today they only stop PM reminders). |
| Lease policy schema | Exists | Typed per-property policy: allowed terms, deposit tiers, application fee, concession rules — including a "month after move-in free" mechanic and a new-leases-only flag, built but never consumed. Gap: no pet-deposit tiers. |
| Proration engine | Exists | Actual-days formula, already matches the real ledger to the dollar. |
| Renewal automation spine | Exists | The full pattern to clone: policy → terms → queue → browser runner → portal e-sign → snapshot → send gate → poller detects countersign (never email). |
| Move-in wizard automation | Partial | A working automation of AppFolio's move-in wizard exists — but it creates a tenant from scratch and finishes with an instant signed lease. Unit-selection + lease-terms steps (~80%) are reusable. |
| Convert to Tenant from an application | Missing | Zero prior art. Needs fresh endpoint recon against the ZZ TEST property. |
| Generate Lease from templates + addenda | Missing | Only the upload-a-PDF variant is automated. The template+addenda+manual-fields variant needs recon; the renewal document-builder is the pattern to port. |
| Send for e-signature (new lease) | Missing | Renewals have it (send-to-portal); the new-lease sibling endpoint needs confirming. |
| Screening trigger | Missing | No automation anywhere touches screening. Endpoint recon needed; billed per screen, so needs an idempotency claim. |
| "You're approved" follow-up lane | Missing | No applicant-facing follow-up scenario keys on approval today — approval only stops cadences. New lane in the existing follow-up registry. |
| Review gate for Fede | Missing | New-lease equivalent of the renewal send-gate, plus a review surface: Clara stages everything, nothing sends until approved. Stays on until Fede personally lifts it. |
A read-only pull of AppFolio's own lease-document records for the online leases done so far. This is the training set for "imitate the team precisely." It covers 18 leases (units 1–100 of 120 — a second page wasn't pulled, so a few more exist); figures are what these 18 prove.
Both confirm the rule for Clara's change-handling: cancel-and-regenerate is safe up until countersign, and Clara must always check countersign state before offering a change.
Still open from this pull: the per-person audit log (blocked), the exact lease template + addenda names, and the second page of units. These don't change the design; they're detail the recon and a follow-up pull will fill in.
Settled by Fede already (Aug 21): run all available screening automatically on application arrival (fee covers cost); prototype at The Willows + ZZ TEST with Fede as the signing prospect; review-before-send gate on, and it stays on until Fede lifts it.
Every real charge is $33; the policy and every quote say $38. Clara shouldn't state a fee in the approval message until this is settled.
We tell people the application costs $38, but the ledger shows everyone actually gets charged $33. One of those numbers is wrong, and Clara is about to put it in writing to every approved applicant.
Today Sam posts the credit by hand, 5–12 days after the rent charge. Clara could post it as part of finishing the move-in — same mechanics, from policy.
The "first full month free" discount isn't part of the lease paperwork — someone has to remember to go back into the books later and subtract a month's rent. Clara could do that automatically so nobody ever forgets a $1,200 credit.
Passing Lease Details posts the security deposit. In review-gate mode, where does the flow pause for Fede's approval?
Halfway through building the lease, AppFolio charges the new tenant their deposit. So "wait for approval" has to happen either before that charge exists, or after — and before the lease email goes out. We have to pick the pause point.
Clara will say "here's the lease I'm about to send — OK?" Somewhere. Pick where that tap-to-approve lives.
A near-miss, logged honestly. While capturing AppFolio's screens on the test property, the automation followed a link into AppFolio's account-wide applications list — which is not limited to the test property — and acted on a real Camellia resident instead of the test dummy, re-submitting the final move-in step on an already-signed lease. A read-only check confirmed no damage: no duplicate charges, the lease unchanged (AppFolio treated it as a no-op). But it was luck, not design. The lesson is now a hard build rule: every automated action must confirm it is on the test dummy and the test property before it runs — never trust a starting-page check alone, and never let an automated step pick a record from an account-wide list. The live lease-preparation recon is paused until that guard is in and the first real run is done supervised.
The email delivers the lease, it doesn't promise it. The supervised run made Fede's north star concrete: the approval email must contain the link to sign the lease — one message: you're approved, here's your lease, sign here. That reorders the pipeline: approve → human review → prepare the lease in AppFolio → get the e-sign link → then send the email, with the link, once the lease actually exists. It deletes the old "the team will follow up" line entirely — that's old-world copy; the point is that Clara does the work and hands over the finished thing.
Why the lease link isn't built yet — the honest history. Renewals were the product, so the part of our AppFolio automation that puts a signable document in front of a resident to e-sign was built and proven live for renewals. New move-ins stayed manual until this project. That's a prioritization fact, not an oversight.
The good news from checking that renewal machinery: the "send a document to the resident to e-sign" step is a shared AppFolio subsystem, not renewal-only. So building it for new leases is mostly adapting the proven renewal path to the move-in starting point — much less than reverse-engineering it from scratch. That build is now the top priority, because it produces the link the email depends on.
Sources: raw standup + customer-call transcripts (#transcripts, Aug 19–20); live AppFolio ledger/report pulls for the last ~4 months of move-ins (2026-08-21); AppFolio help-center documentation of the move-in, online-lease, and screening flows; the codebase and the browser-agent endpoint inventory; the first build night's live recon (2026-08-21) and the supervised run with Fede as the prospect (2026-08-23). Figures on this page trace to those pulls; flagged unknowns are marked where they appear.
One real Camellia applicant, one real bug, found two ways at once: he showed up twice on the Prospects page, and — underneath that — his already-approved lease packet sat finished and waiting for a day and a half with nothing telling anyone it existed. Investigated read-only against production on Aug 31; the applicant's name is left out below, same as everywhere else on this page — he's referred to by unit.
Two rows for the same person on the Prospects page, both marked "from the website," both showing Clara had talked to them. One row said Not Interested. The other said Approved. Both looked live. The question that kicked this off: did we just forget to delete a leftover row, or is something actually still broken?
| When | What happened |
|---|---|
| Aug 25, morning | The applicant fills out Camellia's website form. That's the record that becomes his real, permanent one. |
| Aug 25, evening | He also calls in, same day, different channel. That call creates a second record for the same person. |
| Aug 25, night | Our system correctly notices these are the same human and closes the phone-call record, pointing it at the website record as "merged." At the time, that pointer was only ever written down as a sentence in a notes field — nothing in the code could actually follow it. |
| Aug 29 | His real rental application arrives from AppFolio (our property-management software). Our sync job — which runs every ~5 minutes — matches it to a record using an old tracking number left over from before the merge, and that number happens to still be sitting on the closed, wrong record. It writes the application there. The closed record springs back to life, looking like a second live applicant. |
| Aug 30 | Someone on the team notices the duplicate and manually moves the application data onto the correct record, then re-closes the wrong one. This was done by hand — not by re-running the normal automated process. |
| Aug 30, evening | The actual fix ships to the codebase (see §3). It stops future writes from landing on a closed/merged record. |
| Aug 31, evening | The routine sync job runs again, now correctly sees the corrected record move from "application in progress" to "approved" for the first time, and — because that's a real status change on the right record — the "congratulate the applicant and prepare their lease" step finally fires. A pending lease packet is created and held for a human to approve. Nothing had gone out to the applicant before this. |
| Today, ~9 minutes before this was looked at | The applicant calls again, asking about his down payment — this is the "last activity" the founder saw on the Prospects page. |
He's one person. Our system got that right once (the merge), then a second automated step ignored the merge and used an old tracking number to write to the wrong, closed record instead of the real one. A human quietly fixed the data by hand the next day. But because the fix had to go through the "corrected" record's own normal status changes, the applicant's "congratulations, you're approved" message and lease paperwork didn't get created until a day and a half later than it should have — and nothing anywhere flagged that delay to a person.
The AppFolio sync job matches an incoming application to one of our records using a tracking number it already has on file. It never checks whether that record is a closed duplicate before writing to it. When it found the tracking number sitting on the closed record, it treated that as a perfectly normal match and wrote the update — successfully. Nothing failed, nothing errored, nothing was rejected. From the code's own point of view, it did exactly what it was built to do. There was no "this looks wrong" check anywhere in that path, because the concept of "this record was merged into another one" wasn't something the writing code could see yet — only a sentence a human had typed into a notes field, which nothing else in the system could read.
Because the write succeeded, there was nothing to alert on. We checked directly: our error-tracking tool (Sentry) shows zero events tied to this incident over the last two weeks — not a warning, not an error, nothing. Tracing why: our logging has two tiers. One tier writes to our own internal logs only. The other additionally pages our error tool. Every "give up quietly" branch anywhere near this bug — including the step that later creates the congratulations message and lease packet — is wired to the internal-only tier on purpose, because that code is built to "never throw, only log" so a hiccup here can never break the rest of a sync run. The one branch that does reach our error tool only fires if something actually throws an exception — and this bug's failure mode never did. So the system had no way to tell a human "hey, I just wrote your approved application onto a closed, duplicate record" — because as far as the code was concerned, nothing had gone wrong.
Think of it like a mail carrier delivering a package to the address on the label — the label was wrong, but the delivery itself went perfectly, so nothing in the carrier's job tells them to double-check the address. Our alerting only rings a bell when a delivery fails outright. This one "succeeded," just to the wrong house.
We do have an automated test that replays this exact real incident, and it passes. But it only checks the first half of the chain — that an application correctly lands on the right (not the closed/duplicate) record. It stops there; it never checks whether the "congratulations, prepare the lease" step actually fires afterward. That second half has its own, separate set of tests, built and run a few days earlier against a different shape of bug (a brand-new application landing on an already-approved record) — not this shape (the same application getting moved onto the correct record after a merge, then needing to pass through its own status change before the lease step notices). The two test suites sit on either side of the exact seam this incident crosses, and neither one runs the full chain start to finish. On top of that, the record-matching tests themselves were only run by hand before this fix — they weren't wired into our automatic pre-merge checks until the same fix that this incident is about.
Updated 2026-08-31, evening — six fixes shipped and merged today (all verified against the actual pull requests, not taken on say-so), and Camellia's two pending lease packets were independently checked against production and now both show a resolved $300 deposit.
| Item | Status | Detail |
|---|---|---|
| Future writes landing on a closed/merged record | Fixed | Shipped Aug 30. Every record now carries a real, followable "this was merged into that one" marker instead of just a sentence, and every write path refuses to write to a merged record — it redirects to the correct one instead. |
| This applicant's own duplicate record | Backfilled Aug 31, verified | The one leftover record from this incident was missing the new marker (it predates the fix). Ran the existing backfill tool in dry-run first, then applied it to this single record; confirmed directly against production that the marker is now set. |
| Prospects page showing both rows for one person | Fixed | The page that lists prospects now hides a record once it's been merged away, instead of showing every record for a property regardless of status. |
| No alert when a lease packet quietly waits | Fixed | The team now gets a Slack message, with the right property tagged, the moment a new lease packet is created and waiting for review — so a delay like this one is visible immediately instead of only surfacing when someone happens to check. |
| Studio-unit deposit shows "not established" | Fixed | The piece of code reading a unit's bedroom count wasn't recognizing AppFolio's studio format ("0/1.00") — and separately, a field that should have carried the real deposit amount was never actually being read at all. Both fixed; checked directly against production — Camellia's two pending packets, including this applicant's, now show the real $300 deposit instead of "not established." |
| Lease term defaults to whatever AppFolio last had | Fixed | Each property can now set its own standard lease length. Camellia's is set to 12 months, confirmed live. |
| Prospects entered by staff in AppFolio showed "No source recorded" | Fixed | Those records now show an honest, real label for where they came from instead of a blank-looking placeholder. |
| A pending packet goes stale if the move-in date changes in AppFolio | Fixed | A packet already waiting for review now recalculates itself if the applicant's move-in date changes on the PMS side, instead of quietly holding numbers that no longer match reality. |
| Clara actually sending the lease in AppFolio, unattended | Still open | This step has never been proven against a real property — it's hard-locked to the test property only. Running it live is a separate, deliberate step waiting on Fede's go-ahead, not a bug. |
| "Draft the lease before asking for approval" flow | Still open, parked | Parked behind the same proof step as the item above — no point building further on an unproven sender. |
| Confirming how many applicants are on an application | By design | Still requires a human to confirm — that one's deliberate, not a gap. |
The team now gets a Slack message the moment a lease packet is created — that closes the specific gap this incident exposed. But every "I couldn't finish this step" branch before a packet ever gets created (a missing setting, a policy that isn't on file, a failed lookup) still only logs internally, by design, so one hiccup can't break a whole sync run. If one of those trips instead of the packet-creation step, we're back to silence.
Today, if this step ever quietly gives up again — wrong data, a missing setting, anything — nobody finds out until someone happens to look. The question is whether that's acceptable, or whether at least the more serious "give up" reasons should ring a bell.
Section 8 already settled that the review-gate for the new-lease pipeline stays on until Fede lifts it by hand. This incident is the first time we've actually watched the pipeline fail quietly for a real applicant — so the open question is what "ready to lift the gate" should require, now that we know silent failure is possible.
Right now a person has to click "OK, send this" every single time before an applicant hears anything, on purpose, while we're still learning where this can go wrong. This incident is one example of "where it can go wrong." The question is what has to be true before that manual click goes away for good.
Sources for this RCA: direct, read-only queries against the production database (record-level fields, timestamps, notes fields written by the team during the Aug 30 manual repair); the actual code at the commit that shipped the fix (PR #6669, Aug 30) and its own test fixtures, which cite this exact incident by record id; the existing automated-test coverage for both the identity/merge layer and the separate lease-review-packet layer; a direct query against Sentry (our error-tracking tool) for the investigation window; and the logging module's own source, read line by line to confirm which log levels do and don't reach Sentry. Investigated 2026-08-31.
The auto-draft lane is shipped dark — on at The Willows (our test property), off at Camellia. It is now proven end to end on The Willows, including the case this section is about: an occupied unit is refused rather than half-drafted, the office gets one email naming what to fix, and once the move-out was recorded the lane drafted the lease by itself on the next retry, with nobody touching it. Nothing was sent to an applicant at any point. The harness work behind that proof is merged, on both the PropFlow and browser-agent sides. The decisions below (D7–D14) are still open, and turning the lane on at Camellia is a separate, explicit go from Fede — nothing about the Willows proof changes that.
The first real Camellia lease card hit a wall, for a reason we've already seen once before. We used it as the trigger for a full, read-only audit of the whole approve-to-signed pipeline: is the design sound, or do we need to start over? Verdict: the design is sound — the fix is smaller than a redesign. Full detail in the audit and unit-sweep working files (2026-09-04); nothing here was written to AppFolio, the database, or Slack.
The first real lease card for Camellia: Hanna Sterling, unit 305. Her application shows Approved, and the card's numbers are correct — $1,000 rent, $300 deposit, 6- or 12-month terms, $433 proration for her requested move-in. But the card can't actually turn into a lease, because unit 305 is occupied. Checked three separate ways — AppFolio, our own database, and the raw sync records — and all three agree: Stephanie Rangel has lived there on a month-to-month basis since October 2024, and there's no move-out or notice on file for her anywhere. Hanna's application also still has a co-signer sitting in "Decision Pending" — screening isn't even finished.
The refusal Hanna's card ran into is AppFolio's own rule, not ours. AppFolio blocks converting an application to a lease when the unit's "Available On" marketing date is blank or in the future — and at Camellia, nobody keeps that date up to date by hand, so it's blank far more often than it should be. This isn't new: the exact same failure happened nine days ago, on unit 315, for a different applicant, one day before his move-in date. That one nearly cost a real family their move — the lease died mid-process with a $0 deposit on the books and no notification sent, because the failure was silent.
Hanna's card looks ready — right rent, right deposit, right dates — but the apartment isn't actually empty yet, and even once it is, AppFolio itself won't let the lease go through until someone (or Clara) tells it the unit is available. This has bitten us once before, on a different unit, days before someone's move-in.
Two rulings from Fede stay locked on this page: a free month is never written into the lease terms (it's a separate credit posted later, never a lease-term line), and the application fee is already paid at apply time — it doesn't need to be re-confirmed on this card. Also confirmed: the rent shown ($1,000) really is the rent that belongs on the lease — Camellia's policy is to list and lease every unit at market rate, so there's no separate "estimate vs. real" distinction to worry about here.
While tracing unit 305, we checked every vacant and soon-to-be-vacant unit at Camellia against AppFolio, our database, and the live website. The three systems agree on the numbers; the problems are all marketing and bookkeeping, not data corruption.
| Unit | Status | Bed/Bath | Rent | Posted (net/site) | On website? | Notes |
|---|---|---|---|---|---|---|
| 102 | Vacant | 1/1 | $1,200 | Yes/Yes | No | Marketed, missing from site |
| 106 | Vacant | 0/1 | $1,000 | Yes/Yes | Yes | Vacant ~8.2 months; 2 hard denials on file |
| 116 | Vacant | 0/1 | $1,000 | Yes/Yes | Yes | Stale tenant pointer in our DB |
| 120 | Vacant | 1/1 | $1,200 | Yes/Yes | No | Marketed, missing from site |
| 124 | Vacant | 1/1 | $1,200 | Yes/Yes | No | Marketed, missing from site |
| 206 | Vacant | 0/1 | $1,000 | Yes/Yes | Yes | Vacant ~10.7 months |
| 212 | Vacant | 1/1 | $1,200 | No/No | No | Not marketed anywhere |
| 214 | Vacant | 1/1 | $1,200 | Yes/Yes | No | Marketed, missing from site; ~7.5 months vacant |
| 306 | Vacant | 0/1 | $1,000 | Yes/Yes | Yes | On website, matches |
| 405 | Vacant | 0/1 | $1,000 | No/No | No | Not marketed anywhere |
| 408 | Vacant | 2/1 | $1,500 | No/No | No | Not marketed; ~8.9 months vacant; available-date predates ready-for-showing date by 6 weeks |
| 524 | Vacant | 1/1 | $1,200 | No/No | No | Not marketed anywhere |
| 605 | Vacant | 0/1 | $1,000 | No/No | No | Not marketed anywhere |
| 606 | Vacant | 0/1 | $1,000 | No/No | No | Not marketed anywhere |
| 617 | Vacant | 0/1 | $1,000 | Yes/Yes | Yes | On website, matches |
| 103, 202, 217, 314, 418, 517 | Occupied, month-to-month | — | — | — | — | No notice on file for any of them |
| 305 | Occupied, MTM since 10/31/2024 | 0/1 | $1,000 | No/No | No | Stephanie Rangel, no notice, no move-out — Hanna's application is approved against this occupied unit |
| 614 | Occupied, notice given | 1/1 | $1,200 | No/No | No | Only confirmed near-term vacancy — move-out 9/30/2026 |
On the website: exactly 5 units are advertised (106, 116, 206, 306, 617), all studios, all $1,000, all confirmed genuinely vacant and marketed in every system — no drift there.
We asked, directly: do we need to step back and redesign this pipeline? No. Roughly 40 of the pipeline's ~50 safety checks earned their place — most were built in direct response to a real near-miss (a $0-rent lease that almost went out, an automated click that nearly hit a real resident's already-signed lease, a one-click "mark as fully executed" button that can never be allowed to fire automatically). None of those should be touched.
The actual problem is narrower: several checks read a single AppFolio field that nobody at Camellia keeps up to date — the unit's marketing "Available On" date, the free-text bedroom count, the rent-roll rent — and when that field is missing or stale, the pipeline either stops silently (no card, no alert, nothing) or hard-refuses right before it would have gone through. The fix is to give those checks a second, better source to fall back on — the lease policy, the applicant's own stated move-in date, our own unit records — not to remove the checks or rebuild the pipeline.
We also found three things on the card itself that are pure noise, all three contradicting rulings Fede already made: a fee-total warning (the fee is already paid — nothing to warn about), a proration warning that can never actually trigger, and a "free month withheld" column that always reads as withheld because of how the code is wired, even though the free month was never supposed to be a lease-term line in the first place.
| Guard | The real incident that earned it |
|---|---|
| Property/scope fence | 2026-08-21: an automated recon step followed a link into AppFolio's account-wide list and almost acted on a real Camellia resident's already-signed lease. No damage — luck, not design. |
| Never allow the one-click "fully executed" button | AppFolio's move-in wizard has a button that instantly, permanently executes a lease with no undo. Never automated. |
| Refuse to write $0 or missing terms | 2026-08-23: a lease actually went out for signature with $0 rent from a bad default. |
| Detect "application already converted" | A prior bug produced duplicate tenant + occupancy records requiring manual, non-reversible cleanup. |
| At-most-once send / crash-window guard | The system that actually submits a lease to AppFolio has no built-in duplicate protection of its own — this is the only thing stopping a second binding lease from going out. |
| Read AppFolio's own refusal message | 2026-08-31, unit 315: AppFolio's real explanation was being discarded as a generic error, so nobody could see why the lease died. |
Do we just clean up the noisy warnings and leave a human clicking Approve every time, go further and let Clara fix the missing data herself and approve routine cases on her own, or scrap the design and start over?
If someone moves in on the 18th, does their 12-month lease term start that day, or does it start on the 1st of the next month with a short partial-month charge in between?
This is the actual fix for the wall Hanna's card and the unit-315 lease both hit. When the rent roll says a unit is empty (or about to be) and it lines up with the applicant's move-in date, should Clara go set AppFolio's availability date herself, instead of a lease dying because nobody remembered to?
As Clara does more of this without a person clicking through every step, how does the office stay in the loop?
Our records say Camellia offers a free month on new 12-month leases, but the website doesn't advertise it anywhere. Which one is right?
Her card looks financially correct but points at an apartment that's still occupied and an application that isn't fully screened. What do we do with it today, before any of the fixes above ship?
Decision 9 above asked whether Clara should set AppFolio's availability date herself. Turns out there's already code that does something like that — a follow-up, read-only audit checked why it's never actually fired.
Full working file: camellia-listing-audit.md (2026-09-04, read-only on all systems).
Two separate automations exist. Only one of them can post a listing at all:
TURNOVER_WORKFLOW_ENABLED — absent from Vercel production, both Lambda runtimes, and the ECS worker) → durable workflow starts → (gate: Property.autonomousListingPublishEnabled — true at Camellia) → sets Available On + posts to internet/website. The inline turnover-creation step runs today (that's why Camellia has 39 turnover rows); everything after the first gate has never executed, confirmed against Temporal Cloud's own execution history (zero runs referencing Camellia, ever).| Unit | Turnover record exists? | Would auto-publish have covered it? |
|---|---|---|
| 614 | Yes (created 2026-09-01) | Yes — stopped one gate short |
| 212, 405, 524, 605 | Yes | Yes — noticed after the automation shipped 2026-07-21 |
| 606 | Yes | No — noticed 2026-06-10, before the automation existed |
| 408 | No | No — vacant since 2025-12, never had a notice on file, ~8 months before the automation existed |
| 305 | No | No, and never could — no AppFolio notice field is set, and that field is the automation's only input |
Combined asking rent on the 4–5 units the automation would have covered: ~$6,900/month. Whether any of the six unmarketed units is intentionally held back (renovation, owner hold) hasn't been confirmed by the office in either system — still an open question, not established either way.
Per the standard rollout playbook, any fix here ships dark first and gets proven at The Willows; turning it on for real Camellia units is a separate, explicit call for Fede.
The piece that posts a listing to the website has never run for any property, because the master switch that starts it is off everywhere. How do we turn it on?
Separate from the audit above: a review of how the rest of the industry handles exactly this kind of problem — a system record that's out of date because nobody was paid to keep it current — to check our design against outside evidence before building further.
Other apartment software reads the system's numbers and stops when something looks wrong. Nobody else actually goes and fixes the number. That's the gap Clara can fill — but only if she fixes it the same careful way a good employee would: ask when unsure, write it down, and never let a person stop paying attention because all they ever do is click one button.
Full working file: resilient-autonomous-leasing-research.md (2026-09-04, read-only on all systems). Durable industry findings — the two-field structure shared across AppFolio/Yardi/RealPage, the notice-to-action gap, competitor depth, and the benchmark numbers — were written back to the shared knowledge base as pms-availability-data-hygiene.md; the design conclusions above are product decisions and stayed on this page.
When the office tells Clara (by voice, text, or approving an application) that a resident is moving out on a specific date, but nobody has typed that into AppFolio, should Clara write it in herself?
As with everything else on this page: this ships dark first, gets proven at The Willows, and turning any of it on for real Camellia applicants is a separate, explicit decision Fede makes later — not part of building it. Where this touches the human-approval gate specifically, that change goes through its own reviewed, deliberate diff, the same way Section 8's gate was set up in the first place.
Sources: the 2026-09-04 read-only design audit (code read at cited file/line references across the main app and the AppFolio browser-automation repo; git history since 2026-08-27; the captured AppFolio refusal payload from the live unit-315 session; the #alerts and #transcripts Slack history for both incidents) and the 2026-09-04 read-only Camellia unit sweep (AppFolio unit pages and application records, PropFlow's production database, and camelliadenver.com's live floor-plan page). Nothing was written to AppFolio, the database, or Slack during either pull.