I'm parked on you

Everything I could decide myself is decided. What's left needs you. Each one has a recommendation from Fable — if you agree, pick it and press Done. "I'm not sure" is a real answer and becomes work for me. You don't need to open the session — pressing Done sends your answer back and it picks up.

1Unit 607 (Paula Delgado) renews by Aug 9. She asked to be moved from $1,150 to the $1,000 the website advertises for comparable studios. Her lease record shows market rent IS $1,000, so she is $150/mo above market. What should Clara tell her?

In plain terms. Unit 607 (Paula Delgado) renews by Aug 9. She asked to be moved from $1,150 to the $1,000 the website advertises for comparable studios. Her lease record shows market rent IS $1,000, so she is $150/mo above market. What should Clara tell her?
Fable recommends: Split the difference — renew at ~$1,075
She said she'd be fine either way so she is not a flight risk, but she now knows she is $150 over market and a flat no breeds resentment; $150/mo x 12 = $1,800/yr is roughly one month vacancy plus make-ready, so holding the full delta is close to break-even at best.
Tried first, unsuccessfully: Read her actual Aug 3 message and the lease record: the Aug 6 standup answered the FREE-MONTH question (move-in special = new move-ins only), not the RATE question she actually asked, so no locked policy covers this and it needs Sean.

df70453a is parked on this.

2The Camellia move-in-special wording is fixed in prod, but concession-watcher re-scrapes camelliadenver.com daily at 13:00 UTC (7am MDT) and REPLACES the whole concessions array, so the fix is overwritten in ~9h. A manual edit silently losing to a scrape affects every property, not just this one. How do we make it stick?

In plain terms. The Camellia move-in-special wording is fixed in prod, but concession-watcher re-scrapes camelliadenver.com daily at 13:00 UTC (7am MDT) and REPLACES the whole concessions array, so the fix is overwritten in ~9h. A manual edit silently losing to a scrape affects every property, not just this one. How do we make it stick?
Fable recommends: Update the camelliadenver.com copy — website stays the single source of truth
The scraper treating the website as authoritative looks deliberate (concessionSource already distinguishes website/manual, and the new-property flow advertises 'Clara will pull concessions from this site'), so option 2 changes a designed semantic across all properties and should not ride along with a copy fix; also the website is what prospects read, so wrong copy there misleads people whether or not Clara is right.
Tried first, unsuccessfully: Verified in prod: two contradictory concession entries, one stating the FIRST month is free (opposite of the policy Sean locked). Replaced both with one correct entry — confirmed written, source=manual — then found scrapers/shared.ts:600 replaces the array wholesale on any scrape returning concessions, and lastScrapedAt was 8 minutes old.

df70453a is parked on this.

343 scripts in propflowai/scripts/ carry `if (!process.env.DYNAMODB_TABLE_NAME) … = 'propflow-prod'` — dead code, because .env.local pins propflow-stage, so the guard never fires and they silently run against STAGE. This is what produced today's phantom message (real email delivered, conversation row written to stage, prod showed nothing). Fix the class, or leave it?

In plain terms. 43 scripts in propflowai/scripts/ carry `if (!process.env.DYNAMODB_TABLE_NAME) … = 'propflow-prod'` — dead code, because .env.local pins propflow-stage, so the guard never fires and they silently run against STAGE. This is what produced today's phantom message (real email delivered, conversation row written to stage, prod showed nothing). Fix the class, or leave it?
Fable recommends: Fix the class — shared scripts/lib/resolve-table.ts that prints the resolved table and refuses a silent default; retrofit all 43
Reading the wrong table is as damaging as writing to it — I reported stage data as prod for several turns today and it looked completely coherent, so 'read-only is safe' is false; the failure is silence, and one shared loader fixes it everywhere instead of 43 chances to forget.
Tried first, unsuccessfully: Root-caused the phantom message: pull-link.ts defaults to PROD while every hand-rolled script preamble resolves to STAGE via .env.local, so a session reads real data and writes mirror data and both halves look right. Stage also carries prod's REAL Graph token and rootProviderMessageId (byte-identical), which is why a stage-driven send still delivered a real email.

df70453a is parked on this.

Pick an option above, then press Done.
PropFlow Docs