Renewals — the one doc

Source: scratchpad/report-code-arch.md

Renewals: code-architecture deep inspection — what we are up against for Western Slope

Read-only inspection, 2026-09-23. Repo /Users/federicochapa/.claude/propflowai at e05e8826ad (git fetch origin main run first). Nothing edited, nothing written to production, no polling loops.

Labels: CERTAIN = read directly at the cited file:line. LIKELY = inferred from code plus a dated doc. Doc-sourced history carries its date, because several statuses on the 2026-09-03/04 renewals page have since moved.

Frame. Renewals have run live at exactly one property: Camellia (JP&Co, jpco.appfolio.com, PropFlow property 1773625953462), one building, an on-site team that does not engage. Next: Western Slope Property Management (westernslopepm.appfolio.com, org org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38), ~70 mostly single-family properties under one org, one CENTRALIZED leasing team (Kat, Bev; owner Jason), AppFolio read-only today. WS stored modules: leasing.prospects on; leasing.renewals, maintenance, collections off (go-live tracker, DDB PROFILE row, read 2026-09-13 and 2026-09-23).

Contents

1. Component inventory
2. Camellia-specific assumptions baked in
3. What breaks for a centralized multi-property org (ranked S/M/L)
4. Skeletons and technical debt
5. Where it is working well
6. Temporal usage specifically
7. Ranked answer to "what are we up against"

---

1. Component inventory

1.1 The spine in one paragraph

A daily Temporal Schedule runs the auto-start scanner (src/lib/domain/leasing/renewal-auto-start.ts, 2,579 lines), which walks every property on the platform carrying autonomousRenewalEnabled or autonomousHoldoverEnabled, finds leases inside that property's own window, and starts one renewalWorkflow per lease. The workflow owns the cadence (letter MMS -> SMS -> voice -> reminder ladder -> expiry nudges -> countersign wait) and is the sole writer of renewal lifecycle state into the DynamoDB RenewalSaga read-model (ADR-0047). Offer preparation in AppFolio happens outside Temporal: an SQS job goes to the agent-runtime Lambda, which POSTs the external appfolio-browser-agent Vercel app (/api/run-renewal, Browserbase) and PATCHes back to /api/leases/[leaseId]/renewal, which advances the saga. Four Vercel crons are alert/remediation backstops. Tenant intent arrives as Temporal signals from Clara's voice/SMS tools and from the AppFolio rent-roll poller.

1.2 Temporal components

Full Temporal detail (ids, signals, timers, retries, patches, deployment) in section 6.

1.3 API routes

1.4 Crons (vercel.json)

Domain logic: src/lib/domain/renewals/{stuck-saga-sweep,workflow-health-sweep,external-reconcile,external-reconcile-sweep,external-apply,retry-failed-prepare,prepare-retry-budget}.ts. Against the repo rule at CLAUDE.md:87 ("a new cron added to compensate for a missing timer is the wrong direction"), three of four are alert-only, which is the sanctioned shape; the prepare-retry cron is remediation that arguably belongs inside the workflow (LIKELY).

1.5 Lambdas / SQS / the browser robot

• Live offer-preparation path (CERTAIN). triggerRenewalSync(leaseId, propertyId, payload)

(src/lib/integrations/sqs/agent-jobs.ts:235) publishes a FIFO job to AGENT_JOBS_QUEUE_URL (agent-jobs.ts:22). Callers: renewals/approve/route.ts:763, renewals/outreach/route.ts, renewal-auto-start.ts:1966 (skipped only when workflowOwnsDispatch). The agent-runtime Lambda (lambda/agent-runtime/src/handlers/renewal-l4.ts) POSTs APPFOLIO_BROWSER_AGENT_URL + /api/run-renewal (external repo, Browserbase), which drives AppFolio's internal API and returns renewalOfferId; the Lambda PATCHes /api/leases/<id>/renewal.

• Which AppFolio database is resolved per property, fail-closed: resolveAppfolioAccountFromProperty

(src/lib/integrations/appfolio/resolve-account.ts) reads Property.pmsAppfolioAccount (types.ts:3827) and throws AppfolioAccountUnresolvedError when absent. It rides every runner call as the x-account-id header (l4-core.ts:966). The code names only two live databases: jpco and situsgroup (l4-core.ts:3467, 3703; test l4-account-header.test.ts:94,107).

• PMS write capability gate: Property.pmsSource is "the sole gate for any push-to-PMS code path

(triggerPmsSync, triggerRenewalSync)" — admin/dev/pms-inspector/entity-schemas.ts:2826.

• Read-back / truth: the rent-roll poller syncPropertyRenewals (src/lib/domain/pms/writers/renewal.ts)

handles three AppFolio row states — renewed, tenant_signed, prepared — emitting saga events (never competing writes), each idempotent on pmsRef.

• Decommissioned: lambda/renewal-nudge — only dist/ remains; EventBridge rule

propflow-renewal-nudge-schedule is DISABLED (.claude/decommission-snapshots/renewal-nudge-20260430T030542Z/eventbridge-rule.json). The old propflow-renewal-outreach Lambda was deleted 2026-05-01 (.claude/decommission-snapshots/renewal-outreach-20260501T194232Z/README.md). Also appfolio-sync-20260430T184716Z/{rule,targets}-renewals.json.

1.6 DynamoDB

Entities (src/lib/data/dynamo/helpers.ts): RenewalSaga (:1009), RenewalSagaOpenClaim (:1010), RenewalView (:1011), RenewalPolicy (:1012), RenewalEligibilityDecision (:1013), RenewalChangeReview (:819), RenewalArmState (:838), RENEWAL_SAGA_PERSON_PK='RenewalSaga' (:796).

Key shapes (src/lib/data/dynamo/renewal-saga.ts:6-10):

• RenewalSaga: PK=RSAGA#{sagaId}, SK=META; GSI4 renewal-saga-person-index, GSI4PK='RenewalSaga',

GSI4SK={personId}#{openedAt}. Re-keyed off the legacy tenantId onto canonical personId (ADR-0035 D2); lookups go through getSagasByPerson.

• Claim sentinel: SAGACLAIM#<personId>#<leaseId>#<state>#<pmsRef> / SK=META.
• RenewalPolicy: PK=PROP#{propertyId}, SK=RENEWAL_POLICY#{version} (dynamo/renewal-policy.ts:10) —

property only, no org component.

• RenewalArmState: PK=CONFIG, SK=RENEWAL_ARMS, single upsert-only row (types.ts:16059).

RenewalSagaState (verbatim): OPENED, OFFER_PREPARED, PREPARE_FAILED, OUTREACH_ACTIVE, INTENT_TO_RENEW, INTENT_TO_VACATE, HUMAN_REVIEW_PENDING, EXECUTED, NTV_RECEIVED, TRANSFERRED, CANCELLED, HOLDOVER, MIGRATED_TO_WORKFLOW. Terminal set: `EXECUTED, NTV_RECEIVED, TRANSFERRED, HOLDOVER, MIGRATED_TO_WORKFLOW,

CANCELLED. closedReason: 'executed' | 'ntv_received' | 'transferred' | 'holdover' | 'cancelled' |

'resolved_externally' | null`.

Saga fields: id, personId, leaseId, propertyId, state, pmsRef (AppFolio occupancyId), policySnapshot (frozen at open), workflowId, closedAt, closedReason, transferredToUnitNumber?, holdoverOfficeNotifiedAt?, tenantSignedNotifiedPmsRef, last-error.

Storage libs: src/lib/data/renewal-saga/{writer,find-or-mint,workflow-id,bucket-by-person,daily-metrics,negotiating-marker,preparing-timestamp,in-memory-storage}.ts; src/lib/data/dynamo/{renewal-saga,renewal-policy,renewal-eligibility-decision,renewal-projection,renewal-external-events,renewal-change-review}.ts; src/lib/data/{renewal-view,renewal-state-sources,renewal-conv-fallback,renewal-for-tenant}.ts.

1.7 UI

• src/app/(workspace)/(operations)/leasing/renewals/(list)/page.tsx — the renewals board (graduated from

/leasing/renewals/board, which now redirects: board/page.tsx:13).

• .../renewals/[leaseId]/page.tsx + RenewalDetailClient.tsx (~2,200 lines) + _components/RenewalDetailGhost.tsx.
• .../renewals/layout.tsx:12 — requireModuleForSection('/leasing/renewals').
• .../renewals/board/_components/{BoardV2,PropertyScopePrompt,data,map-renewal,board-scope-gate,live,board-shared}.
• src/components/feature/dashboard/leasing-renewals/{RenewalsSection,LeasingSection,LeasingRenewalsRow,WeeklySnapshotCard,...}.tsx.
• src/components/domain/leasing/RenewalsPolicyCard.tsx, src/components/domain/properties/RenewalPolicyEditor.tsx.
• Admin: admin/dev/renewals-cohort/, admin/dev/access-inspector/_components/ArmsTab.tsx.

1.8 Outreach channels

src/lib/domain/leasing/renewal-orchestration/: send-renewal-email.ts, send-renewal-letter-mms.ts, fetch-renewal-letter-pdf.ts, letter-mms-outcome.ts, letter-mms-status.ts, recap-sms.ts, sms-cascade.ts, initiate-renewal-call.ts, renewal-call-context.ts, record-outreach-conversation.ts, renewal-outreach-hold.ts, renewal-send-guard.ts, channel-outcome.ts, append-pm-notify-to-renewal-conversation.ts, append-reminder-to-conversation.ts, fetch-executed-lease-pdf.ts.

Cadence as the code states it: the letter MMS is Phase 1.5 and fires regardless; renewalPolicy.voiceCallEnabled (default true) decides whether an outbound Clara call fires on offer-prepared; reminder ladder D+1 / D+7 (workflow defaults reminderStep1 = '24 hours', reminderStep2 = '7 days'); expiry nudges at lease-end -30d and -15d; sms-cascade.ts:8 — there is no email cascade any more (retired 2026-05-17), AppFolio's resident portal owns renewal email on that leg.

1.9 Voice agent, tools, prompts

Tools (agents/clara/lib/agent/tools/renewal/schemas.ts:27-125, handlers handlers.ts): renewal_accepted, renewal_declined, renewal_escalate (with counter_offer / counter_offer_terms -> board card "Negotiating terms"), send_portal_link_sms, send_offer_sms, change_renewal_term. Prompt: agents/clara/lib/agent/tools/renewal/prompt.ts. ElevenLabs: config/elevenlabs-agents.json — "Clara — Renewal" (:145), "Clara — Renewal (Outbound)" (:179). Evals: evals/prompts/renewal-{scoping,voice,sms}.ts; evals/gauntlet/run-renewals.ts + golden-dataset-renewals.json; evals/promptfooconfig-renewal-scoping.yaml; gate threshold renewals: 95 (evals/eval-gates.generated.json:45).

1.10 Reports, metrics, reminders, countersign

src/lib/domain/leasing/{renewal-rate.ts, renewal-lapse-digest.ts, renewal-lapse-digest-window.ts, renewal-receipt-ttl.ts, alert-engineering-lapsed-renewal.ts}, compute-light-renewal-rate; src/lib/data/renewal-saga/daily-metrics.ts. Reminders/countersign: pm-action-reminder-backstop.ts, resolve-pm-action-reminder-config.ts, renewal-reminder-sms.ts, pm-action-reminders/{pm-action-reminder-tick-cap,pm-action-link,pm-action-kinds,pm-action-reminder-copy,pm-action-link-appfolio}.ts; countersign detection src/lib/integrations/appfolio/{awaiting-countersign-probe.ts, email-ingestion/handle-appfolio-lease-countersign.ts, email-ingestion/parse-appfolio-lease-countersign.ts}; lambda/appfolio-sync/lease-countersign-signal.ts.

1.11 The RENEWAL_ARMS config

Durable row PK=CONFIG / SK=RENEWAL_ARMS. Written ONLY by scripts/set-renewal-arms.ts (a code ship cannot write it). Read through arm-store.ts with a cache TTL, warmed at worker boot (services/renewal-worker/index.ts:234, workers/renewal-worker.ts:71). Defaults DEFAULT_RENEWAL_ARM_STATE (types.ts:16218).

Inert leftovers: --holdover-in-workflow and --walker-spawn (plus their allow/disallow pairs) were removed 2026-09-03 under "one starter, one owner"; scripts/set-renewal-arms.ts:31-39 notes the live row "may still carry these fields from before the retirement — they are inert." Dead data in a production config row.

1.12 Env flags in renewal code (Fede's rule: none should exist — each is a finding)

Real behaviour gates, all legacy fallbacks mid-migration onto the DDB row:

• RENEWAL_AUTONOMOUS_SENDING — autonomous-gate.ts:42, autonomous-gate-core.ts:108-111.
• RENEWAL_HOLDOVER_CONVERSION — holdover-gate.ts:23,36,48.
• TURNOVER_AUTONOMOUS_SENDING — turnover-gate.ts:13,39,56 (its header records the env var being wiped 4x in 72h

by ECS task-def re-renders — the reason the durable row exists).

• EMAIL_NTV_FIRM_ROUTING_ENABLED — Vercel-side, gate home src/lib/domain/leasing/ntv-gate.ts; disarmed by

default; gates firm NTV routing AND the AppFolio move-out draft.

• TEMPORAL_NONDETERMINISM_METRICS_ALERT — nondeterminism-metrics-drain.ts; OFF; wiring not landed (ADR-0052 WS4).

Config/infra, not behaviour gates (listed for completeness): AGENT_JOBS_QUEUE_URL, APPFOLIO_BROWSER_AGENT_URL, ELEVENLABS_API_KEY / ELEVENLABS_RENEWAL_AGENT_ID (initiate-renewal-call.ts:55-56), RENEWAL_ARM_CACHE_TTL_MS (arm-store.ts:58), RENEWAL_TASK_QUEUE_OVERRIDE (client.ts:135 — test harness only, never prod), TEMPORAL_USE_VERSIONING (workers/renewal-worker.ts:91), Sentry/build metadata. Canonical inventory: docs/runbooks/renewal-orchestration.md.

1.13 Settings

Property.autonomousRenewalEnabled (types.ts:3996); Property.autonomousHoldoverEnabled; Property.capabilityStage.renewals (types.ts:3630, DECLARED BUT NOT WIRED — see section 4); Property.renewalPolicy {rentStrategy, maxIncreasePercent, maxIncreaseAmount, termOptions, mtmPremium, delinquencyThresholdMonths, voiceCallEnabled} (types.ts:4825, the legacy blob); versioned RenewalPolicy.thresholds {maxBalanceMonths, maxLatePayments, lateGraceDays} (the v6 row); PropertyLeasingSettings.renewalContactEmail (types.ts:15697), renewalContactPhone (:15700), renewalExecutionCcEmails; renewalAutoStartDaysBeforeLeaseEnd default 90 (settings-resolver.ts:56,80,192-195); Property.jurisdictionStateCode (types.ts:3988); Organization.escalationOwnerEmail; module entitlement leasing.renewals -> LeasingRenewalsEntitlement (src/lib/domain/modules/resolve-module-entitlement.ts:84).

---

2. Camellia-specific assumptions baked in

2.1 Hardcoded ids and addresses

• 1773625953462 appears in ~120 files — essentially all eval fixtures, replay corpora, canary/Willows harness

scripts and test data. CERTAIN, not a production behaviour risk.

• The one load-bearing production hardcode is a denylist: scripts/lib/refused-property-ids.ts:37-40 pins

Camellia's id (both AppFolio spellings) so the renewal-policy-facts migration script refuses to touch it. Comment :20-24: "It is the live production property with real residents whose renewals are in flight... Enrolling it is a decision with a human in the room." CERTAIN. Consequence: WS properties would onboard onto the NEW versioned facts path while Camellia stays on the legacy blob — two customers, two policy-resolution code paths. (src/__tests__/renewal-policy-single-home.drift.test.ts header cites 15 non-Camellia live properties enrolled.)

• No hardcoded customer emails in live renewal source. The only non-test hit is an illustrative comment,

pm-contact-email.ts:10 ("e.g. Camellia = camelliaapts@jp-co.com"). CERTAIN.

• src/lib/platform/scrapers/camellia.ts:8 carries the property id but is a marketing-website content scraper, not

a renewal path. CERTAIN.

2.2 The policy numbers ("25-day / 6-late / 2.0-balance")

• Code defaults: DEFAULT_RENEWAL_POLICY_THRESHOLDS = { maxBalanceMonths: 2.0, maxLatePayments: 2, lateGraceDays: 10 }

— src/lib/domain/leasing/eligibility/engine.ts:74-77; DEFAULT_LATE_GRACE_DAYS = 10 at :51. CERTAIN.

• The 25-day grace and the 6-late ceiling are Camellia's per-property override, not code constants.

engine.ts:38-42: "the confirmed target — a 25-day grace + a widened maxLatePayments ceiling of 6 — moved the property from 59.3% to 92.0% AUTO_RENEW." They live in Camellia's versioned RenewalPolicy.thresholds row. CERTAIN. There is no string "policy v2" in the tree; the internal name is v6 (RenewalPolicyV6Snapshot).

• Statute floor: only one jurisdiction module exists — eligibility/jurisdictions/co.ts

(CO_STATUTE_VERSION='CO-HB-24-1098-v2024-04-15', CO_CITATION='CO HB 24-1098 §38-12-1305(2)(a)(II)'), applied unconditionally; Property.jurisdictionStateCode is read by COLLECTIONS, not by the renewal eligibility engine. CERTAIN. WS is also Colorado, so this is not a WS blocker — it is a blocker for the first non-CO customer.

• The same fact is stored twice and four readers disagree on the default. renewal-policy/facts.ts:20-47 states

it: knowledge.renewalPolicy.delinquencyThresholdMonths and RenewalPolicy.thresholds.maxBalanceMonths are the same fact, written to both by RenewalPolicyEditor, and an absent value defaults to ?? 1 in RenewalsPolicyCard.tsx, ?? 2 in PropertyDetailClient.tsx, 2.0 in eligibility/engine.ts, and ?? 1 in statuses/renewals.ts's dormant deriveRenewalStatus. The file's own words: "one unmigrated property already tells a PM two different stories about its own delinquency bar on two different screens." CERTAIN.

2.3 Single-property and on-site-team assumptions

• The board refuses "All Properties." renewals/(list)/page.tsx + board/_components/board-scope-gate.ts:33-39:

with no ?propertyId= and no single-property workspace scope, the page renders PropertyScopePrompt — "Cohort math is per-property — there's no meaningful cross-property aggregation to fall back to, so null means render the pick-a-property prompt, not guess." CERTAIN. The data layer is NOT the limit: getRenewals(propertyId?) (src/lib/data/store.ts:3987-3991) builds propertyIdsInScope from the tenant set when the id is undefined.

• Quiet hours default to Camellia's timezone. src/lib/temporal/activities/quiet-hours.ts:26-32 hardcodes

'America/Chicago' when Property.timezone is unset, with the comment "matches Camellia (the only live customer at time of writing)." Called from renewal-auto-start.ts:2314. No org-level timezone tier. CERTAIN.

• Escalation SMS is property-only with no fallback. renewal-notify.ts:15,115,123 — "phone:

PropertyLeasingSettings.renewalContactPhone only (no fallback — absent means email-only)." CERTAIN.

• renewalAutoStartDaysBeforeLeaseEnd is property-only, no company layer. settings-resolver.ts header states

only tourDurationMinutes and notifications.observerBcc have a company tier (plus company-only applicationLinkMode); "every other field below is unchanged — still property-only, no company layer." CERTAIN.

• Per-property enrollment, no bulk mechanism. renewal-auto-start.ts:405-422: "Per-property opt-in: the single

enforced gate is the property's autonomousRenewalEnabled master switch... One toggle per property — there is no separate outreach flag." A property is scanned if it opted into renewal OR holdover (:436); if none has, the scan exits (:439). CERTAIN.

• Policy rows are per-property (PK=PROP#{propertyId}) with no org default. organizationId appears in the

eligibility layer only as an audit field on TenantRenewalFeatures (eligibility/features.ts:21), never as a lookup key. CERTAIN.

• Leasing "intake mode" was only ever the single-building shape. listing-resolution.ts:118-123: 'single'

mode — "the line means ONE property with apartments in one building... every property live today: Camellia, Yale, the Willows." CERTAIN for the comment; LIKELY that renewal copy inherits the assumption.

• isSingleHome / isHomeAddressForWording (listing-resolution.ts:108-112,

resolve-prospect-email-branding.ts:115,126,132) govern EMAIL BRANDING WORDING only and are referenced by no renewal file. CERTAIN. Caution: renewal-policy-single-home.test.ts / .drift.test.ts are about "one home for renewal facts" (the legacy-vs-versioned consolidation), NOT single-family housing.

2.4 AppFolio tier / access assumptions

• No "lower tier / no DB API" comment is co-located with renewal code, and **no live renewal code references

westernslopepm. CERTAIN** (grep).

• The real assumption is the write path: triggerRenewalSync requires Property.pmsSource==='appfolio' (the sole

push-to-PMS gate) AND Property.pmsAppfolioAccount (fail-closed), and the external appfolio-browser-agent must hold a logged-in session for that subdomain; only jpco and situsgroup are named as live (l4-core.ts:3467,3703). CERTAIN for the mechanism; LIKELY that WS has neither the account row nor a robot session, since its access is read-only today.

• Correction worth recording, because it is easy to get wrong: dispatchAppFolioWrite

(activities/renewal.ts:2306) IS declared-and-never-called — but that is the WORKFLOW-OWNED dispatch behind the workflowOwnedDispatch arm (OFF). The LIVE offer-preparation path is the caller-side SQS dispatch in §1.5, and it runs in production today. CERTAIN.

• AppFolio hard rules from docs/runbooks/debugging-a-stuck-renewal.md: never silently default a value AppFolio

renders (missing policy = fail loud); send ALL terms from policy (termOptions: number[], one Renewal Option per term); MTM premium is a separate fee, never rolled into rent; Form Template only — the lease document is single-term, multi-term lives at the Renewal Options layer; a term change requires cancelling the previous offer first, which AppFolio otherwise refuses; reset requires BOTH sides (AppFolio cancel + PropFlow saga + delete terminal sagas).

---

3. What breaks or must change for a centralized multi-property org

S ~ config or a small PR. M ~ one focused PR chain. L ~ design plus several PRs.

What does NOT break — most of the shape. The workflow engine, the saga read-model, the person-keyed GSI, the eligibility engine, the send guard, the six scope-pin checkpoints, the reply-mailbox chain, the PM-contact email chain with its org rung, tour hours' org tier, per-property AppFolio account resolution, and the module entitlement resolver are all already org-aware or org-indifferent.

---

4. Skeletons and technical debt

4.1 Half-shipped arms

• workflowOwnedDispatch — still OFF, opt-in allowlist. types.ts:16087-16093: "Default OFF... proven on

Willows/appfolio-45 BEFORE any live property is added." Nothing in the repo shows a live property in the allowlist. Meanwhile its workflow-side patch renewal_workflow_owned_dispatch_v1 was deprecated as UNCONDITIONAL on 2026-09-21 (#10431) — so the patch fork is gone while the arm doc still describes the behaviour as off-by-default. Those two statements need reconciling. CERTAIN. Practical effect: in prod only the caller-side SQS dispatch is exercised, and dispatchAppFolioWrite is dead code in the workflow.

• autoStart, autonomousSending, holdoverConversion all default false and nothing in-repo asserts their

production values. To a reader of the repo alone the whole engine is dark. CERTAIN.

• Inert arm fields in the live config row (--holdover-in-workflow, --walker-spawn and pairs) —

set-renewal-arms.ts:31-39. CERTAIN.

4.2 Patch ledger and retireBy

Ledger: src/__tests__/temporal-patched-ledger.drift.test.ts (1,067 lines), inside the required Unit Tests gate. It statically scans src/lib/temporal/workflows/ for patched() / deprecatePatch() and cross-checks a PATCHED_LEDGER object for entry existence, file, coverage kind, valid dates and substantive notes. Enforcement is two-stage (:68-77, :978-1017): past retireBy it only console.warns; it fails CI only after retireBy + RETIRE_GRACE_DAYS (14, :95).

No renewal patch is past retireBy as of 2026-09-23. Three are within a week: countersign_reminder_requires_signature_v1 (renewal-workflow.ts:1730) -> 2026-09-29; renewal_commitment_stated_phase_v1 (:1704) -> 2026-09-30; renewal_negotiating_intent_v1 (:2089) -> 2026-09-30. Further out: renewal_infra_classifier_budget_v1 (:2900) -> 2026-11-02; renewal_scope_pin_v1 (:2678) -> 2026-11-19; v2 (:1696), v3 (:3506), v4 (:1668) -> 2026-11-20. Already retired via deprecatePatch: 20 ids, most recently six on 2026-09-19 (incl. renewal_honor_pause_v1) and renewal_workflow_owned_dispatch_v1 on 2026-09-21. No getVersion( anywhere (older API unused). CERTAIN.

4.3 TODO / FIXME / deprecated in renewal code

• activities/renewal.ts:113 — TODO(G-1): wire capabilityStage.renewals.
• activities/renewal.ts:1113 — TODO(Phase 6.4): pass intent via activity input so this lookup can drop.
• Four TODO(saga-migration) markers, each riding an eslint-disable no-restricted-syntax, all pointing at the same

unfinished move off a deprecated tenant field onto getRenewalView: renewal-cycle.ts:399, renewal-status-display.ts:337, RenewalDetailClient.tsx:934, board/_components/map-renewal.ts:698.

• src/lib/data/renewal-saga/writer.ts:318 — @deprecated alias OpenObservedSagaParams.

CERTAIN.

4.4 Duplicated mechanisms (Constitution: one mechanism per signal)

• Dispatch owner is forked by design: caller-side triggerRenewalSync (renewal-auto-start.ts:1966,

approve/route.ts:763, outreach/route.ts) vs workflow-owned dispatchPmsPrepare (renewal-workflow.ts:3052). Arm-gated and deliberate, but two live paths for one signal. CERTAIN.

• Two homes for the delinquency threshold, four disagreeing defaults (§2.2). The clearest live violation.
• renewal-workflow.ts hard-codes RENEWAL_NON_RETRYABLE_ERROR_TYPES inline at :690 and :735 instead of

importing the shared constant from retry-policies.ts:7-11 that every sibling workflow imports — a silent lock-step drift risk. CERTAIN.

• approve/route.ts and decision/route.ts are one handler under two URLs (deliberate back-compat alias).
• Resolved duplicates, worth knowing they are closed: the second renewal starter was DELETED, not disarmed

(#6902, 2026-09-04) — one starter now; holdover ownership collapsed onto the daily scanner (renewal-auto-start.ts:934, renewal-workflow.ts:3710); the cohort walker evaluates and persists, never spawns; declines funnel through renewal-declined-tenant.ts:14 ("the single source of truth"). CERTAIN.

4.5 Skipped tests

Across all 171 test files matching renewal|arms|countersign|holdover, exactly one skip: src/__tests__/agent-renewal-eval.test.ts:195 — const describeLive = LIVE ? describe.sequential : describe.skip, gated on RUN_LIVE_EVALS==='true'. A live-call eval gate, not an abandoned test. No unconditional it.skip / describe.skip / xit / .todo anywhere in the renewal surface. CERTAIN.

4.6 Eslint suppressions

16 renewal-related entries in eslint-suppressions.json, mostly test-file no-explicit-any. Non-test: RenewalDetailClient.tsx (no-restricted-syntax x5, the saga-migration TODOs), renewal-workflow.ts (no-explicit-any x7), RenewalPolicyEditor.tsx (react/no-unescaped-entities x1). CERTAIN.

4.7 Behavioural debt the code alone will not show you

The 2026-09-03/04 renewals-architecture-decision page (~/.claude/propflow-docs/artifacts/renewals-architecture-decision-2026-09-03.html) catalogues ~50 issues since launch as BUG / DESIGN FLAW / INCOMPLETE / DESIGN DECISION. Its own TL;DR: about a third genuine bugs, a third designs that did what they were told and what they were told was wrong, a third half-built. Doc-sourced and dated 2026-09-04; several entries there are already marked fixed and live (archived-saga bug, duplicate starter, duplicate-send guard, intent-evidence module). The shapes that matter most for a CENTRALIZED, ENGAGED team, because those are precisely the ones such a team will hit:

1. "Tell a human once, then wait" — A1: five offers never sent for want of an email on file; one PM email, a

65-day suppression marker (retry-failed-prepare.ts:818), a 30-minute retry cron that skips on the marker.

1. The PM-flag field has one writer and zero readers — A2, sole writer activities/renewal.ts:2432. **Confirmed

still present, CERTAIN.**

1. Escalation is fire-and-forget by construction — B3/B4: no tracked matter, no deadline, no re-page. A

counter-offer and a paper-lease request each sat for weeks.

1. Reminder hold never lifts early — B5, named in renewal-outreach-hold.ts's own header.
2. Reachability module has zero callers — A4: src/lib/domain/leasing/renewal-reachability.ts

(evaluateRenewalReachability); channels are chosen once at renewal-auto-start.ts:1220 and never re-evaluated. Confirmed file present, CERTAIN.

1. Contact-info changes never re-open a stuck renewal — A5: saveTenants discards the did-it-change result

(src/lib/data/dynamo/property.ts:681-700).

1. Nothing closes a renewal when its lease is archived — E1.
2. The 7-in-7-days message ceiling is measureOnly: true for renewal letters — F3,

send-renewal-letter-mms.ts:200-221, 265-289; policy decision pending since 2026-09-03. Confirmed, CERTAIN.

1. The external reconciler's observe half works; the apply half is unproven, and the "looks handled — confirm?"

button contradicts Fede's 2026-09-03 follow-the-PMS-signal ruling — C2/C3.

Items 2, 5 and 8 I re-verified against current files (CERTAIN). The rest are doc-sourced as of 2026-09-04 and should be re-read before being quoted as today's state.

---

5. Where it is working well

• One starter, one owner. The second auto-starter was deleted, not disarmed (#6902). The cohort walker cannot

start a renewal. renewal-entry-point-spine.drift.test.ts pins it. The root of the Sept 3 early-offer incident is structurally closed. CERTAIN.

• The workflow is the sole writer of lifecycle state, through a saga writer with an optimistic version lock; the

rent-roll poller emits saga EVENTS rather than competing writes (pms/writers/renewal.ts header), every branch idempotent on pmsRef.

• Replay corpus. src/__tests__/renewal-workflow-replay-corpus.test.ts replays committed real Temporal histories

(src/__tests__/fixtures/temporal-histories/) against current code. Plus a nightly prod-history canary — see §6.9.

• Permutation harness with a committed golden baseline —

src/__tests__/workflow-permutations/renewal/{renewal-adapter.ts,renewal-scenarios.ts,baselines/renewal.golden.json}.

• Ten renewal drift tests pinning structural invariants: renewal-entry-point-spine,

renewal-outbound-non-renewal-gate, renewal-outreach-stage-stripped, renewal-policy-single-home, renewal-replay-ci-paths, renewal-saga-personid-rekey, renewal-source-stripped, renewal-voice-optout, renewal-worker-deploy-gate, tenant-renewal-timestamps-stripped.

• arms-registry-coverage.test.ts structurally scans src/ for every createDomainGate(...) call site and

every autonomous*Enabled property flag and fails CI if either is unregistered in the Arms admin tab — it closes the "invisible gate" class directly (cites #5801/#5904 at :21-27). The best piece of self-governance here.

• Regression suite src/__tests__/regression/renewals/ — 9 files plus a manifest, spanning board selector, PMS

writer accounting, reconciler escalation, eligibility, workflow, outreach, Clara classification, voice, API route (npm run test:renewals-regression). 161 renewal test files overall, 20 on the workflow, 9 on countersign.

• Scope pins (p9-workflow-pins). Six named checkpoints where a running saga re-resolves which company it

belongs to before a send (activities/renewal-scope.ts:11-46), with residual gaps stated in the file rather than left to be inferred. The pattern to copy for the multi-org work.

• Per-property AppFolio account resolution is fail-closed (resolve-account.ts) — a mis-scoped renewal offer

cannot land in the wrong customer's database by default. Exactly the property a second AppFolio customer needs.

• The PM-contact email resolver is already the nearest-wins org resolver we want elsewhere

(pm-contact-email.ts:1-38): property renewal contact -> property inbox -> Organization.escalationOwnerEmail, folded in ONE place, with organizationId read off the property row and never off the caller's session.

• The module entitlement seam (domain/modules/resolve-module-entitlement.ts,

integrations/email/company-live-gate.ts, integrations/voice/initiate-outbound-call.ts) — one shared fail-closed question asked at doors that already exist, instead of a new central checkpoint. Renewal email and renewal voice already declare it.

• Willows is physically unable to write into JP's real AppFolio (recording stand-in), which is what makes a real

end-to-end proof safe to run (2026-09-04 page).

---

6. Temporal usage specifically

6.1 Workflow ids, task queue, schedules

• renewalWorkflow — workflows/renewal-workflow.ts:1035; registered type string 'renewalWorkflow' (:464).
• Task queue: process.env.RENEWAL_TASK_QUEUE_OVERRIDE || 'propflow-renewal' (client.ts:135,

workers/renewal-worker.ts:99, services/renewal-worker/index.ts:202-204).

• Workflow id, two modes:
• Unarmed: workflowId = input.renewalId (the minted saga id) — client.ts:206-214.
• Armed (ADR-0108 D2, ON by default since 2026-09-03): renewal-${leaseId}-${renewalMintCycleKey(leaseEndDate)}

via stableRenewalWorkflowId (client.ts:153-155), called from renewal-auto-start.ts:1846, and stamped onto saga.workflowId. resolveSagaWorkflowId(s) = s.workflowId ?? s.id (src/lib/data/renewal-saga/workflow-id.ts:27).

• workflowIdConflictPolicy: USE_EXISTING; workflowIdReusePolicy: 'ALLOW_DUPLICATE' (re-open after a terminal

run); signal-first path signalWithStart at client.ts:402-412.

• renewalAutoStartScanWorkflow — workflows/renewal-auto-start-workflow.ts:36; started only by a Temporal Schedule

(upsertRenewalAutoStartSchedule, client.ts:575-624): fixed id renewal-auto-start-daily-wf (:593), ScheduleOverlapPolicy.SKIP (:601), workflowExecutionTimeout: '20 minutes' (:596). Operator CLI scripts/temporal/upsert-renewal-auto-start-schedule.ts, default cron 0 9 * UTC. The schedule only controls firing — the run still no-ops unless the durable autoStart arm is armed.

• The cohort walker and the tour/turnover walkers have their own schedules; pausing a schedule is the only gate for

the cohort walker (no env flag).

6.2 Activities and retry policies

Activities in activities/renewal.ts: sendOutreachSms:751, sendReminderSms:1038, sendOutreachEmail:1432, sendRenewalLetterMmsActivity:1699, dispatchVoiceCall:2001, dispatchAppFolioWrite:2306, dispatchPmsPrepare:2363, classifyPrepareFailure:2432, escalateToPM:2488, loadSagaInitialState:2870, resolveLeaseEndIsoActivity:2984, resolveSendWindowDelayActivity:3009, recordWorkflowPhase:3089, recordWorkflowOutcome:3207, transitionSagaToOfferPrepared:3850, escalateHeldRenewalActivity:3964. Plus processCohortWalkActivity (renewal-cohort-walker.ts:58) and processRenewalAutoStartActivity (renewal-auto-start.ts:25).

proxyActivities groups in renewal-workflow.ts:

Shared constant RENEWAL_NON_RETRYABLE_ERROR_TYPES lives at retry-policies.ts:7-11 and is imported by the auto-start and cohort-walker workflows — but NOT by renewal-workflow.ts, which duplicates the literal inline at :690 and :735. Drift risk. CERTAIN.

6.3 Signals, updates, queries

All in renewal-workflow.ts. There is no separately-named accept / decline / counter / change-term / pause / countersign signal — those are payload field values, not distinct signals:

• pmsChangedSignal 'pmsChanged' :466 · pmsFailedSignal 'pmsFailed' :467 · deliveryStatusSignal 'deliveryStatus' :468
• tenantIntentSignal 'tenantIntent' :469 — payload kind: 'renew'|'vacate'|'negotiating', plus condition and

requestedTerm: 'mtm'|number. Accept, decline, counter and change-term all live here.

• pmActionSignal 'pmAction' :470 · pmStatusOverrideSignal 'pmStatusOverride' :471 — payload

status: 'paused'|'resumed'|'manual_renewed'|'manual_declined'. Pause lives here.

• Updates: retryLetterUpdate 'retryLetter' :492 · externalResolutionUpdate 'externalResolution' :549 ·

pmDecisionUpdate 'pmDecision' :586 (PM approval).

• Query: getSnapshotQuery 'getSnapshot' :654.
• Registration: a generic dedup() wrapper at :2118 registers each signal (:2125 pmsChanged, :2148 pmsFailed,

:2149 deliveryStatus, :2150 tenantIntent last-write-wins, :2151 pmAction, :2157 pmStatusOverride); setHandler(retryLetterUpdate,...) :2163; shared factory makeResolutionWrapupHandler :2281 wired for externalResolutionUpdate (~:2314-2321) and pmDecisionUpdate (~:2325-2331); setHandler(getSnapshotQuery, buildWorkflowSnapshot) :2357.

• Countersign is derived state, not a signal: pms() === 'countersigned' via countersignTerminal()

(~:1798-1804), fed by pmsChangedSignal from the rent-roll poller and the AppFolio countersign email parse.

6.4 Timers, sleeps, conditions

6.5 Versioning and patching

patched() / deprecatePatch() only — no getVersion( anywhere. Live and retired ids, the ledger mechanism and the 14-day grace are in §4.2. Note the stale-premise warning the code itself carries (client.ts:220-250): ~12 in-file comments justify "the pre-patch cohort is drained" from "60 days have passed since landing", arithmetic that predates the 60d -> 400d run-timeout bump and is no longer sufficient. Drain must be verified against Temporal visibility on the CURRENT namespace propflow-prod.hmqma (the old propflow-renewal-prod.hmqma is retired read-only and reports 0 RUNNING for everything, which proves nothing). CERTAIN.

6.6 continue-as-new / unbounded history

No continueAsNew() call anywhere in renewal-workflow.ts (zero grep hits). It is a known, documented gap — client.ts:216-220: "400d is a generous cushion, not a real bound — a workflow parked indefinitely for PM action can still eventually hit it; a follow-up (continueAsNew before the ceiling) is the real fix and remains out of scope here." Combined with the two no-timeout condition() waits and the multi-week timers in §6.4, one renewal saga can accumulate history for most of a year with no escape valve. The single biggest structural fragility. CERTAIN. Same comment records 17 renewalWorkflow executions RUNNING in prod as of 2026-09-03, so long-lived renewals are empirically normal.

6.7 Determinism

• Date.now() at :1818, :1822, :2499, :3619 — explicitly documented as safe (:3572-3573,

expiry-nudge-schedule.ts:5): the SDK patches it for replay. CERTAIN, accepted rather than accidental.

• No Math.random(), no uuid, no direct fetch/IO in any of the four core workflow files. CERTAIN.
• Activity modules are imported into workflow files as import type only (renewal-workflow.ts:258,

cohort-walker-workflow.ts:15, renewal-auto-start-workflow.ts:5) — erased at compile time, so no activity-layer IO enters the deterministic sandbox. The only non-type runtime imports beyond @temporalio/* are the pure helper resolveExpiryNudgeWait (:249) and the pure constant RENEWAL_PREPARE_DEFAULT_TIMEOUT (:257). CERTAIN.

6.8 Worker deployment

services/renewal-worker/index.ts is a generic multi-worker runner: one shared connection and one shared workflow bundle (:293-297), then Worker.create() per entry of a 17-queue registry (:188-223, :301-331) including propflow-renewal with renewalWorkerActivities (:202-204). Worker identity ${taskQueue}-${buildId}-${ecsTaskId} (:316).

• ECS task def infra/temporal-worker/task-definition.template.json: ARM64 Fargate, cpu 512, memory 3072

(:5-10), image tag placeholder (:16), stopTimeout 120 (:18), ~25 Secrets Manager/SSM secrets (:42-134), awslogs /aws/ecs/propflow-renewal-worker-__ENV__ (:136-144), health check node /app/healthcheck.js 30s/10s/20s/3 (:145-151). The task-def template is on the auto-merge guard's DANGEROUS_GLOBS list because it selects IAM roles.

• Graceful drain: per-worker shutdownGraceTime: '25s' (index.ts:326; renewal-worker.ts:110), SIGTERM/SIGINT

handler (:403-404) calls shutdown() (:384-402) on all 17, backed by a 50-second hard-exit watchdog (HARD_EXIT_WATCHDOG_MS = 50_000, :381) forcing process.exit(0) — added after a confirmed 2026-08-29 incident where the propflow-promise worker never left DRAINING.

• Concurrency: maxConcurrentWorkflowTaskExecutions: 10, maxConcurrentActivityTaskExecutions: 10

(renewal-worker.ts:112-114), labelled "Phase 0 defaults; production tunes these."

• Versioning: buildId from PROPFLOW_GIT_SHA || GIT_COMMIT || fargate-<ts> (:152-158);

useVersioning = TEMPORAL_USE_VERSIONING === 'true' (:260) — OFF by default per the README's canary note; strict pinning needs a manual temporal task-queue versioning add-new-default.

• Activity registration: workers/renewal-worker-activities.ts:44-53 is the single shared map between the local dev

runner and the Fargate entrypoint, extracted after a prod incident where pinRenewalScopeActivity existed only in the dev map ("Activity function ... is not registered on this Worker", header :1-22).

• Alerting: Sentry wired directly (index.ts:94-104), DSN in the task-def. Replay divergences page Slack #alerts

(C0BGTNSP04C) from CI, not from the worker.

6.9 Replay testing

Pipeline scripts/temporal/export-recent-histories.ts -> scrub-history-fixture.ts -> replay-history.ts. Export fails hard on zero histories (its own comment :33-40 records the earlier silent bug that ran green for three weeks testing nothing). Scrub rounds dollar fields to 1000 and redacts worker identity / sticky-queue strings (:27-36, :73-78). Replay extracts the real task queue from the history's own WorkflowExecutionStarted event (history-task-queue.ts:14-37) because Worker.runReplayHistory otherwise synthesizes a fake queue name that can flip literal-task-queue branches, then replays against current code and exits 1 on divergence. CI: .github/workflows/nightly-renewal-harness.yml job prod-history-replay-canary (:544-703), nightly, --workflow-type=renewalWorkflow --limit=10 --closed-within-days=30, Slack on divergence. Committed fixtures src/__tests__/fixtures/temporal-histories/: intent-only-countersign-wait-prechange.json (125 events), postcutover-holdover-reoffer.json (27 events), plus three retired wedge-incident fixtures. Coverage gaps: only branches exercised by the last 10 closed histories in 30 days; never executes activities, so business-logic bugs are out of scope; a zero-export night fails the job but sends no divergence alert.

6.10 Fragility

CERTAIN

1. No continueAsNew against a 400-day run timeout, with two no-timeout waits and multi-week timers (§6.6).
2. renewal-workflow.ts duplicates the non-retryable error-type list inline instead of importing the shared one.
3. 17 Temporal Workers share one Node process, connection and bundle — a hang in one queue threatens drain for all,

which is why the 50s hard-exit watchdog exists.

1. The patch-ledger gate warns silently for 14 days past retireBy before it reds CI.
2. Worker useVersioning is OFF by default — no build-id pinning during a deploy over a 14d-400d in-flight run;

safety rests entirely on patched() discipline.

1. The nightly replay canary silently loses coverage on a zero-export night.
2. The "60 days have passed" drain arithmetic in ~12 in-file comments is stale since the 400d bump (§6.5).
3. Three renewal patches retire 2026-09-29/30.

LIKELY

1. Held-review parks (lease-end + grace) plus no continue-as-new could produce genuinely large histories; no

history-size incident found in the files read.

1. Concurrency limits are self-described "Phase 0 defaults"; possibly under-tuned, no throttling evidence found.

---

7. Ranked answer to "what are we up against"

1. Turning on AppFolio writes is Fede's call, not a Western Slope task. The robot already signs in to westernslopepm. Writes

are blocked by a read-only lock we set on 2026-09-08 because Western Slope has no test property; flipping it to live is one setting on the account row in the browser agent, Fede's call, no build and nothing for Western Slope to do. (L, CERTAIN mechanism / Fede gate.)

1. Fan-out config: enrollment, policy and timezone are all per-property with no org tier. ~70 properties x

(one toggle + one policy row + a timezone) is the bulk of the wiring work, and two of the three have no set-once mechanism at all. (M/L, CERTAIN.)

1. The board does not exist for a portfolio. A two-person centralized team cannot work a per-property cohort

board across ~70 buildings; the loader can already go org-wide, the page refuses to. (M, CERTAIN.)

1. The escalation half was built for a team that never answers, and WS's team answers. That flips the

tracked-matter / reminder / reachability work from "nice" to the main thing — for the first time there is somebody to chase, and somebody who will notice when nothing chases them. (L, CERTAIN for the code shape, doc-sourced for the incident history.)

1. Small but sharp, all S, all CERTAIN, all cheap: the America/Chicago quiet-hours default (TCPA); the letter

MMS and recap SMS doors that do not ask the module gate while email and voice do; capabilityStage.renewals declared and unwired; escalation SMS with no org rung; WS's escalation email still pointing at an internal placeholder; the renewals specialist's missing module check (#11307).

1. Calendar: three renewal Temporal patches retire 2026-09-29/30 — inside the window this work would run.

---

Process note: one research subagent reported encountering, and correctly disregarding, a spoofed mid-task message purporting to come from another session and asking it to resend its findings. No action was taken on it and it did not affect any content above. Worth knowing that such a message appeared.

Source: scratchpad/report-history.md

Renewals: a history of the feature

Read-only archaeology of the PropFlowAI repo, published docs, and prior session memories. Compiled 2026-09-23 against origin/main (fetched 2026-09-23).

Method note on counts. Two commit sets are used throughout:

• Strong set = commits whose subject line names renewals (renewal, renewals, countersign, holdover, month-to-month, mtm, NTV). 810 commits. This is the honest measure of renewal work.
• Union set = strong set plus every commit touching a path matching renew, lease-end, countersign, mtm, month-to-month. 2,399 commits. This over-counts: renewal files are touched incidentally by sweeping refactors (spine collapse, org scoping, DataTable migration).

PR numbers are taken from the (#NNNN) suffix squash-merge leaves on the subject.

March has zero PR numbers because the team was still committing straight to main and merging local branches (Merge branch 'renewals-p1' etc.); the PR-per-change workflow starts in April.

---

1. Dated timeline

2026-03 — the Renewals tab (UI only, pre-PR workflow)

• 2026-03-04 Split leasing tab into New Leases and Renewals subtabs — the first renewals surface.
• 2026-03-09 feat: Renewals tab Phase 1 — KPIs, columns, filters, sort, conversation modal + first smoke/e2e suite. This is the earliest commit whose subject names renewals.
• 2026-03-17/18 Renewals Phase 2: auto-outreach, RENEWAL_STATUS constant, ACCEPTED status between OUTREACH_SENT and RENEWED, balance/MTM/total-upcoming columns, demo seed script, manual "Send Outreach" button for demos, outreach timing moved to Settings.
• 2026-03-18/19 The renewal intent classifier is rewritten twice in two days: regex → LLM, then "pure LLM with conversation history, no regex". Renewal overhaul: decline confirmation, warm messaging, cadence settings, status rename.
• 2026-03-20/22 Race and consistency bugs: decline stuck at outreach_sent, DynamoDB GSI eventual-consistency in renewal-trigger, Sentry capture added.
• 2026-03-25/26 UX audit chunk 5 (Prospects + Renewals overhaul), per-property renewal outreach in AppSettings, MTM indicator, turnover auto-create from declined renewals.
• Character of the month: hand-merged local branches (Merge branch 'renewals-p1'), demo-driven, no PR numbers.

2026-04 — autonomous outreach scaffolding, AppFolio writes, the first guard (112 PRs)

• 2026-04-14 #91 Approve → AppFolio sync, new renewal statuses.
• 2026-04-17 #128 autonomous outreach scaffolding + AppFolio test-property pipeline.
• 2026-04-19 #202 callback fires concierge SMS, flag-gated off (the first renewal gate). #229 CloudWatch alarms for PMS consumer + renewal pipeline. #224 Clara-branded policy card.
• 2026-04-20 #278 auto-decline on NTV filed. #271 daily cron migrated launchd → Lambda + EventBridge.
• 2026-04-21 #302 voice toolkit cut to 5 tools. #313 SMS + voice share one Clara agent, Haiku classifier retired. #314 PREPARING / PREPARE_FAILED / ESCALATED states + auto voice call on prepared. #324 REVERT of #313's SMS half — a narrow renewal-only prompt meant a mid-renewal tenant saying "my toilet leaks" got no maintenance tools. Evidence was Fede's own dogfood at 2026-04-21 18:34 UTC ("why did rent go up so much?" → Clara fell into generic deflection). Voice kept the dedicated prompt; SMS went back to the unified prompt with a renewal block appended.
• 2026-04-22 #366 removes the NEVER-WRITE-TO-CAMELLIA allowlist guard — the moment renewals could write to a real customer's AppFolio. #361 AppFolio offer becomes source of truth for the voice call. #355 runtime switch on the approve route. #356/#359 CI auto-syncs the renewal voice prompt and tool registrations to ElevenLabs on merge.
• 2026-04-23 #384 minimum-increase policy (% or $/mo). #381 real Day-2 SMS nudge scheduler. #376 real AppFolio signature state on the detail page.
• 2026-04-26/27/28 The hardening burst: #429 intent-to-vacate from operational emails, #422 email fallback for no-phone tenants, #467 per-channel outcome stamps + SMS→Email cascade, #470 detect manually-created PM offers, #458 detect countersign via AppFolio renewal_summary, #471 multi-term offer pitch parity, #469/#478 runtime hallucination guard ("legal-risk defense for live tenant outreach"), #493 auto-fire renewal_escalate when the hallucination guard blocks, #491 change_renewal_term, #496 auto-send the AppFolio Renewal Notice Letter as MMS, #499 per-property voice-call toggle, #503 preparedOffer.occupancyId as the single AppFolio identity.
• 2026-04-29/30 #535 renewal E2E canary "verifying every 2026-04-29 failure" (there was a bad day on 04-29). #538 RenewalSaga types + pure state machine. #554 the saga becomes the single source of truth for status + KPIs.
• Docs artifact appfolio-renewal-benchmarks.html was last generated 2026-04-24T01:34:45Z: 60 L2_DOM trials, 0.0% success, $32.66 spend, dominant failure ROW_NOT_FOUND_AFTER_PREPARE (42/60). It has not been regenerated since — the benchmark page is stale.

2026-05 — Temporal migration, the abandoned v5/v6 policy engine, the overnight revert (157 PRs)

• 2026-05-02 ADR-0016 renewal state-source registry. #576 saga-aware reset.
• 2026-05-05/07 #635 auto-flip → RENEWED on the AppFolio portal-sign email (this email-triggered flip is later named as the cause of a real incident — see approved-to-signed.html: "Countersign truth comes from polling AppFolio's reports — never from email. We learned this on renewals the hard way."). #746 v2 promoted to canonical /leasing/renewals. #751/#753/#758 saga backfill + drift report + legacy fallback dropped.
• 2026-05-09 #764 Sean's 5/7 UX review applied.
• 2026-05-11 The overnight autonomous-renewals build: #837, #838 (4-step nudge ladder + PM email + AppFolio outcome handoff), #839 EventBridge + dogfood scope, #846, #852, #853 (drop step-4 PM reminder — "one PM email is enough"), #858 single-threshold auto-start (90 days default, 60d override), #859, #863–#874 (dry-run policy Lambda, analytics event types, MetricSnapshot writer, Outlook signals tool + HUMAN_REVIEW_PENDING + queue UI, policy-tuning admin page + weekly digest Lambda, v1 policy module with 10 gates).
• 2026-05-12 #881 reverts the whole overnight build (#863–#874). Stated reasons: /simplify skipped on every PR, bot review missed on #869 and #874, internal jargon leaked into owner-facing UI ("PROVISIONAL METRIC MAPPING"). The revert PR was opened as DRAFT ("do NOT merge without explicit author go-ahead") and merged 2026-05-12T13:54Z. #893 then had to regenerate package-lock.json. Same day #865 rolled the nudge ladder out to all properties.
• 2026-05-14 ADR-0025: self-hosted Temporal for renewal workflows.
• 2026-05-16/17/19/20 The Temporal cutover: #988 RENEWAL_OUTREACH_KILL_SWITCH (emergency comms stop), #1005 renewal-nudge Lambda retired, #1065 renewal-outreach Lambda replaced by a daily Temporal Schedule, #1067 SendGrid bounces routed into the workflow, #1075 saga-writer kill switch + reconciler cron retired, #1080 migration script porting open sagas to workflows, #1187 legacy fireRenewalOutreach gated behind a Temporal allowlist, #1202 auto-start routed through startRenewalWorkflow, #1214 workflow-owned RVIEW projection cutover.
• 2026-05-22 v6 eligibility engine #1307: 2 gates (balanceMonths, latePayments), binary AUTO_RENEW / HITL_REVIEW, no score. Its body records that the v5 engine POC branch fede/renewals-engine-poc was abandoned (260+ unrelated stale changes; it carried the 5-gate + score + BLOCKED_LEGAL machinery v6 deliberately cut). Plus #1317 AppFolio feature extractor, #1323/#1327 cohort walker in Phase-1 shadow mode, #1330 seed-policy script, #1334 policy editor wired to the v6 DDB entity, #1340 Clara decision column.
• 2026-05-24 #1376 consolidates send switches into one fail-closed gate, ships disarmed. #1378 term permutations (6/12/MTM) in the E2E matrix.
• 2026-05-26/27 Temporal namespace strategy pivots to one app-wide tenant-backend namespace (#1465 supersedes the per-domain rule). ADR-0036 #1558/#1565: email the offer + letter to no-phone tenants. ADR-0037 #1574: NTV-on-PM-capture chain.
• 2026-05-26 (recorded later in the 09-04 quality audit as F2) the renewal letter was sent 4× to unit 118 in ~86 minutes.

2026-06 — holdover / month-to-month, ADR-0046, spine collapse (114 PRs)

• 2026-06-03 ADR-0045 (#1852) unify Temporal namespaces onto propflow-prod. ADR-0046 (#1920) renewal expiry, holdover and execution notifications. #1801 capture positive renewal intent (incl. MTM) from email. #1896 fixes escalation wired to the wrong switch (per the 09-04 audit, that had been broken since launch).
• 2026-06-04→09 The holdover build, ADR-0046 D1–D7: #1927 MTM holdover decision engine, #1929 HOLDOVER terminal saga state, #1942 holdover scan (lapsed-unsigned → MTM), #1947 AppfolioPMSWriter.convertToMonthToMonth, #1925 AppFolio lease provenance, #1922 email accounting on execution, #1923 MTM reminder warning, #1978 configure "signed" notification emails in the UI (D4), #2019 D1 office email + D2 re-offer lineage, #2020 decouple holdover arming from renewal outreach, #2021 flip the lease MTM flag during convert, #2023 pre-arm canary through the real worker, #2115 no-comms-to-declined guard at every send activity, #2119 D7 fresh-check for off-flow renewals, #2102 recover-wedged-renewal script (dry-run, gated).
• The 07-31 incident doc dates the start of the ~7-week exposure window to 2026-06-09, when the lapsed warn SMS shipped.
• 2026-06-10 #2129/#2137 formal-notice emails → firm-NTV path and AppFolio move-out draft, both flag-gated and disarmed. #2145 hardens signal extraction against 6 audit failure modes.
• 2026-06-11 ADR-0055 (#2267) "renewal UI must reflect workflow state, not infer it" — per the 09-04 audit this fixed the "declined and stalled at once" phantom-status class that had affected 38% of history.
• 2026-06-16→25 ADR-0035 spine collapse eats the renewal fields: #2427 re-key RenewalSaga tenantId→personId onto GSI4, #2517 retire renewal lifecycle timestamps, #2521 retire Tenant.renewalOutreachStage → Lease, #2523 retire Tenant.renewalSource, Phase F absorbs reasonForNonRenewal/unitNumber into TenantOccupancy.
• 2026-06-22/23 ADR-0066 (#2570) collapse the two-job renewal pipeline. ADR-0067 (#2596) AppFolio session concurrency for parallel prep. #2578 auto-start skips already-resolved / offer-in-flight cycles.

2026-07 — the heaviest month (201 PRs), two incidents, ADR-0108

• 2026-07-02 #2924 TRANSFERRED outcome (ADR-0076) — stop labelling unit transfers as Declined. #2851 simplified v2 list+detail behind a per-browser toggle.
• 2026-07-05/06 ADR-0045 rewritten as a clean-cut namespace migration (#3085), cross-namespace renewal migration script (#3086), fail-closed TEMPORAL_NAMESPACE (#3084). #3148 renewal-prepare-retry auto-cure ships disarmed; #3257 (07-07) arms it always and retires the RENEWAL_PREPARE_RETRY_ARMED flag — a rare case of a gate actually being removed.
• 2026-07-07 #3220 Renewal Failure Gauntlet prod-repro harness Phase 1; #3222 alert-only Temporal workflow-health sweep cron.
• 2026-07-09→16 The board rewrite: #3327 ADR-0081 renewing into a different unit, #3346 guard renewal send against wrong-unit transfers, #3389 weekly owner report, #3435 MTM rows with in-flight offers, #3482 ADR-0085 shard the saga GSI4 hot partition, #3513/#3534 cohort-board prototype → live data, #3606 DataTable migration, #3677/#3695/#3816 Cohort Board v2 + Settled review ledger ("founders' #1 ask"), #3691 adopt the Yale 25 Station "% Renewed" formula, #3876 centralize the renewal-rate formula (responders-only, transfers = retention), #3878 the board replaces the classic table, #3902–#3935 six same-week board/detail revisions.
• UI thrash, 2026-07-15/16: #3825 and #3835 redesigned the detail page; #3842 reverted both "— founder call"; #3935 then restored the original hero UI, #3926 restored the PM Approve control. Four days, two forward PRs, two restorations.
• 2026-07-15 ADR-0091 (#3829) reconcile renewals against external PMS actions.
• 2026-07-17 ADR-0100 (#3987) PM-decided month-to-month conversion. #4054 outreach exhaustion wraps up quietly instead of escalating to a PM — this is the decision the 09-04 audit blames for units 420/522 going silent. #3997 renewal D3 cut over to the executed-lease outbox (ADR-0098 Phase 5a).
• 2026-07-18/19 #4110 renewal voice honors caller opt-out. #4167 renewal offer emails sent from the property mailbox via Graph. #4144 stops junk stuck-saga pages.
• 2026-07-19/20 The "X-series": #4174–#4192 — eleven projection/terminal-state fixes in two days (already-MTM is terminal, held-for-review routes to Requires action, credit balances render as credit, offer summary shows the real sent offer, honest escalated-row copy).
• INCIDENT 2026-07-21 — the false "ready for your signature" email. ADR-0104 (#4217, merged 07-20) went live via #4267, removing an allowlist. 44 minutes later the hourly pm-action-reminder-backstop emailed camelliaapts@jp-co.com: "A lease is ready for your signature — Ryan Davidson (Unit 218)", claiming the lease was signed on the tenant's end. Nothing was pending — it was Ryan's in-force July-1 transfer lease (308→218) whose lower-tier AppFolio mirror carries lastLeaseSignedAt: null forever. Evidence edl_a1f39f79, 2026-07-21T23:00:13Z. Blast radius 1 real email + 2 to a test address from orphaned harness fixtures. Root cause: the backstop approximated "awaiting countersign" as (no signature date + not archived + created within 30d), indistinguishable from an executed mirror lease — and the same file already refused to fabricate that signal for renewal_countersign. Fixed by #4279 (07-22): the lease leg becomes a structural no-op; the E2E harness, which only ever tested true positives, gained the incident-shaped negative regression, a single leaseSk() source of truth, a manifest moved out of the worktree (the post-merge reap had been destroying the prod cleanup ledger), and a residue exit gate. Prod remediation applied ~2026-07-22 01:30Z: 4 false cadences terminated, the backstop schedule paused, 2 orphaned PMREM leases deleted.
• Same day, #4236 reverted #4217's merge — but that revert is process, not product: "ADR PRs are never merged by automation — the open PR is the discussion surface and Fede accepts the decision." #4297 restored lease_countersign reminders via a verified e-sign signal. #4263 made the PM "Pause" button actually pause outreach.
• 2026-07-22 — ADR-0108, the one-spine refactor. #4322 the ADR; #4374 one decision spine (shared gate pipeline, per-caller dispositions); then thirteen fixes in one day: #4352 (approve starts the workflow before dispatching SQS — kills the unrecoverable sqs-orphan), #4353, #4354 (gate the autonomous path on the non-renewal stamp — the "NTV gate"), #4355 (one isDeliverableEmail; 'n/a' emails can no longer reach AppFolio), #4356 (atomic per-lease mint claim closes the scanner⇄PM double-mint race), #4357, #4358, #4359 (HELD tenants page the PM once — no more silent dashboard-only holds), #4371 retire drained patches + the RVIEW cutover gate, #4376/#4379/#4385.
• 2026-07-24 #4492 stops the duplicate "ready for signature" email — AppFolio already sends that email itself when an offer enters awaiting-countersign, and the PM-action cadence was firing its own reminderIndex: 0 at the same moment. ADR-0104 §125 had predicted exactly this overlap; the dedupe mechanism existed and was never wired into the renewal bridge. Same PR adds weekend-skip (Sat/Sun nudges deferred to Monday 09:00 property-local, DST-aware).
• 2026-07-25 DynamoDB TTL audit + receipt TTL floor (#4541). The 09-04 audit notes a workflow built to test real AppFolio automatically was never run once and was deleted 2026-07-25.
• 2026-07-28/29 Quiet-hours-by-area-code shipped and was reverted the next day (#4843/#4844 reverted by #4866 — quiet hours are the property's local time).
• 2026-07-29 The orphan-send class: #4842 fence orphan sends + stop anchoring renewal SMS to a closed saga, #4846 the send gate and the conversation anchor resolve ONE saga, #4865 gate the portal-link SMS on the anchor.
• INCIDENT 2026-07-31 — notice tenants texted renewal quotes. At 08:30 MT the daily auto-start scan sent a lapsed-lease "renew now" SMS (renewal_expiry_nudge_sms, milestone lapsed) to two notice tenants at Camellia. Both occupancies carried reasonForNonRenewal: "Notice to Vacate filed", renewalState: "declined", unit status notice. For one, the PM had cancelled the AppFolio offers on 7/07 and set a move-out date of 7/31 — and Clara texted him a renewal quote that morning. Root cause: the lapsed/holdover branch continues before the ADR-0108 decision spine runs, so it enforced no gates at all (G8 declined-stamp, G9 suppression, G11 signer-email, G13 transfer); the pre-lapse 15-day warn band had the identical hole; sendScanMtmWarning never consulted ADR-0092 §5 suppression; and G8 read only the occupancy stamp, never the canonical lease's lastObservedNoticeAt / leaseMoveOutDate. Fixed same day by #5152, with a failing-first reproduction. A 30-day audit found no other wrong sends but 8 further gaps, 3 rated High, and 7 of 8 were still open at the time of the 09-04 write-up.
• 2026-07-31, same day, second failure — a resident emailed asking to renew if rent came down ~13%; seven seconds later PropFlow told her PM the renewal was "ready for your signature — it just needs your signature to wrap up", while AppFolio said "Out For Signing — 0/1 Tenant(s) Signed." Her counter-offer surfaced nowhere a human would see. #5173 (07-31) made the countersign PM reminder require signature evidence. The 19-surface audit (#5175) found the same defect — copy asserting facts the system never verified — on 11 surfaces.
• 2026-07-30/31 #5014 a thrown PM escalation email is a failure, not a success. #5192/#5205 renewal escalations lose their follow-up promises.

2026-08 — the honesty era; renewal feature work drops to 40 commits

• 2026-08-01/02 ADR-0122 accepted; #5274 ships D1/D2 — tenantIntent carries provenance (pms_verified vs stated), a third kind negotiating is added, and the load-bearing OR that collapsed "said yes" with "signed" is split. countersignOnRenewIntent is deleted outright rather than left as a permanently-false parameter. Four PM-facing surfaces stop reading the phase name and start reading the evidence. The 09-04 audit calls ADR-0122 "the cleanest root-cause fix in the whole history."
• 2026-08-05 #5438 re-send capability + preflight that refuses before the cancel. #5476 internal engineering review lane for renewal corrections.
• 2026-08-07 #5563 extends two renewal patch retireBy dates because "grace elapsed at midnight, required checks red repo-wide" — the first of four such episodes.
• 2026-08-09 #5592 one home for renewal facts: versioned RENEWAL_POLICY# rows, read-boundary substitution through loadRenewalPolicyView, a drift fence, and an offer that records the policy version that priced it. Ships dark: 0 of 17 properties enrolled, proven by scripts/renewal-shadow-diff.ts run twice against live prod records. No commit since mentions enrolling a property.
• 2026-08-10→14 #5643 stop retrying PMS prepare once a lease left the pool. #5691 bound the renewal-decision read. #5741 executed-lease accounting notice waits for the countersign. #5754 waiting on a countersign is silent — no time-based alerts, daily long-tail polling. #5776 stop burning an AppFolio MFA code to learn "not countersigned yet".
• 2026-08-15 #5800 retire six overdue renewal patched() guards (ADR-0108 D5).
• 2026-08-17/18 — the guard deep dive. #5828 hold renewal reminders once a resident answered or a human owns it. #5830 scoped opt-out — a renewal-text "stop" no longer kills maintenance and email too. #5849 renewal_escalate opens a tracked matter at owner-armed properties, single engine.
• 2026-08-20/24/28 #5487 derive prepareTimeout from the retry budget. #5807 ANTHROPIC_MAX_RETRIES on the renewal worker so a 429 burst backs off instead of dying. #6529 hard-exit watchdog + desiredCount=2 to stop a SIGKILL-every-deploy loop.
• 2026-08-30/31 #6617 detail page onto the standard host; #6626 had to unbreak main the same day; #6624 fixed a nonexistent CSS token (push-main-red). #6720 gate the scan's lapsed/holdover branch on the eligibility verdict. #6721/#6722 wire the cohort walker to spawn renewalWorkflow and move holdover into the workflow (Phase 3, dark) — these two arms are deleted four days later. #6737 gate the cutover arms per property, not fleet-wide.

2026-09 — the Sept-3 incident, the architecture decision, then scope/permission work

• 2026-09-02/03 — the ADR-0045 namespace cut. #6809/#6814/#6815/#6818/#6822 fixed pre-cut defects (the migration script could find 1 of the 9 live renewals; Step 4 never flipped TEMPORAL_ADDRESS; the contract was missing 4 live schedules; the gate could not see a schedule firing six hours off). Cut completed 2026-09-03T15:48:53Z; #6838 swept propflow-renewal-prod → propflow-prod; earliest decommission 2026-10-03.
• INCIDENT 2026-09-03 — two starters. The cohort walker was switched on for Camellia while the original daily scan kept running; nothing coordinated them. From ~21:42 the night before to 08:00–08:02 Mountain: 11 renewal cases opened (the walker's 120-day window vs the daily job's 90-day rule), 5 of them ~a month early, 7 of 11 sent one text and one call, 10 PM pages went out twice (two starters, two separate "did we already page" lists), 3 failed at the AppFolio step with the real error swallowed by a generic wrapper, and 1 record (unit 417) went hollow when a retry wrote the wrong ID type into the tenant field. No tenant was contacted twice; no delinquent or on-hold tenant was contacted.
• 2026-09-03 ~30 renewal PRs land in one day: #6849 auto-close renewals AppFolio already handled, #6850 route timeout/budget PMS failures to engineering not the PM, #6856 retry bootstrap carries the PMS tenant id, #6857 unify PM-escalation dedupe, #6871 attribute renewal touches to their lane, #6876 widen renewal-call identity (co-tenants + fuzzy names), #6893 scope the daily scan to armed properties, #6898 flip stable workflow identity (ADR-0108 D2) to armed by default, #6899 daily-backoff retry for INFRA prepare failures, #6902 the deletion (below), #6909 outbound calls speak the offer to whoever answers, #6913 Willows live-run harness, #6961 stop Willows test renewals touching JP's real AppFolio, #6962 renewal pages stop reading every property's renewals, #7016 a new start path can no longer skip the rulebook, #7028 prove a change against a whole month of scans.
• 2026-09-04 #7038 a renewal keeps the offer document the PMS created, #7040 the proof run stops grading itself green on an empty run, #7067/#7068 archived sagas leaking into GSI4 open-saga reads, #7069 exclude Willows-harness sagas, #7079 undo the shared-read change to the renewals pages, #7094 an NTV date written in words counts, #7101 our own unanswered offer no longer blocks the MTM rollover, #7104 group the day-before heads-up into one email per property per working day, #7106 retire two more overdue patched() guards.
• INCIDENT 2026-09-05/06 — three unwanted MTM conversions at Camellia. Per fede-priorities.html: the renewal fix that shipped 2026-09-04 without a gate converted three leases the next morning (units 420, 522, 504). 420 and 522 were what the July policy always intended; unit 504 had an open human case — the resident had said on paper they wanted to renew — and rolled anyway, because the fix looked at timing, not at whether a human owned the case. Recommendation on the page: fix only 504 by hand in AppFolio, leave the other two. The "human owns this" check on the conversion step is a separate fix, built dark.
• 2026-09-05/06 #7133 the office MTM notice no longer promises a fresh renewal offer. #7137 (labelled [HOLD], hold-for-review, merged 2026-09-06T04:10Z) stops opening a new renewal offer after an MTM rollover — month-to-month is now the end state. #7145 exclude isTest bench properties from the lapsed-renewal alert. #7152 stop double-routing a renewal-thread maintenance mention.
• 2026-09-10→17 Scope/portfolio work takes over: #7563 stuck-saga paging suppression (and #7066, still open), #7933 one portfolio-wide renewals call per account (dark, per-account arm), #7956 renewal birth paths declare the birth so the org stamp runs, #7988 the live dashboard's counts are the caller's not the deployment's, #8004 the renewals list asks whose building it is, #8263/#9718 the renewal batch stops texting from the global test line, #8550/#8572, #8803 renewal-auto-start.ts reads office hours through the walked chain, #9089 stop accepting two renewal settings fields nothing reads, #9165 the selection bounds the query not a post-filter, #9325 (merged 09-18) a per-property pmsWritesAllowedWhileTest opt-in so Willows can write to Test Property 45 again.
• 2026-09-20/21 #10071/#10425/#10430/#10439 pin the renewal saga's scope and re-resolve it before first contact and before every tenant-facing and staff-facing send (p9-workflow-pins). #9838/#10431 retire pm_action_reminder_countersign_v1, #renewal_honor_pause_v1 and renewal_workflow_owned_dispatch_v1 (ADR-0108 D5). #10110/#10111/#10112 de-fork the renewal worker's activity registration after a push-main-red.
• 2026-09-23 (today) Permission and honesty polish: #10993/#11001 approve/decision/outreach require property scope + leasing:edit, #11009 the auto-renewal switch requires settings edit, #10985 "Not on file" instead of "$0/mo", #11015 the renewals tile says "—" not 0 when its numbers did not load, #11089 an unread lease is Unknown not MTM, #11133 a scope_moved stop cancels the countersign reminder cadence, plus four latency PRs.

---

2. Decision register

Newest ruling wins. Source column: git/gh = PR body or commit; adr = /Users/federicochapa/.claude/propflowai/docs/adr/; doc = published page local copy in /Users/federicochapa/.claude/propflow-docs/artifacts/; mem = a session memory file under /Users/federicochapa/.claude/projects/*/memory/.

2.1 Policy and product rulings (Fede)

Standing rules with no single date: never expose renewal-policy knowledge fields (rent strategy, max increase, MTM premium, delinquency threshold) to tenants (mem feedback_renewal_policies_tenant_visibility.md); the offer SMS and the letter PDF are one atomic send, never decoupled (mem feedback_renewal_sms_pdf_atomic.md); do not build browser automation for notice-to-vacate creation — residents self-serve in the AppFolio portal (mem propflow_ntv_self_serve.md); opt-out preferences do not apply to the resident portal as a required signing channel (mem propflow_portal_optout_policy.md); do not propose another mass-text campaign to collect tenant emails — it already failed (mem propflow_add_contact_rows_reality.md); do not add an intentToVacateCount KPI — it is a soft prediction (mem propflow_intent_to_vacate.md).

2.2 Architecture decisions (ADRs)

Renewal ADRs in creation order, with the one-line call. Full table in the subagent detail: 0016 reset-source registry (2026-05-01) · 0025 adopt Temporal (05-14) · 0036 email the offer to no-phone tenants (05-27) · 0037 moveOutDate transition is the canonical formal-NTV trigger (05-27) · 0045 one Temporal namespace propflow-prod (06-02, rewritten 07-05) · 0046 month-to-month holdover + execution notices (06-03) · 0047 keep the DDB saga as the read-model (06-04) · 0055 the UI reflects workflow state, never infers it (06-11) · 0066 collapse the two-job pipeline so the verdict actually gates the send (06-22) · 0067 serialize AppFolio browser jobs per account (06-24) · 0074 detect transfers vs move-outs (07-01) · 0076 transfers: label correctly, change nothing else (07-02) · 0081 guard the wrong-unit offer (07-08) · 0085 shard the saga GSI4 hot partition (07-10) · 0091 the PMS is the system of record; reconcile against it (07-15) · 0098 executed-lease notice pipeline (07-16) · 0100 PM-decided month-to-month (07-17) · 0108 one spine, workflow-owned dispatch, stable identity (07-22, Accepted 07-23) · 0118 internal transfers get their own bucket (07-28) · 0122 evidence-gated notifications (08-02).

2.3 Contradictions to flag

1. Holdover ownership — a live documentation contradiction. The published priorities page (/Users/federicochapa/.claude/propflow-docs/artifacts/fede-priorities.html) says "Holdover handling moved inside the renewal workflow… Fede (Option B) Sept 4." PR #6902 (merged 2026-09-03) did the opposite: it deleted workflow-owned holdover, leaving the daily scanner as the sole, unconditional owner. The code is the truth; the page is wrong.
2. ADR-0046 D2 vs the 2026-09-05 ruling. The ADR body still describes re-offering next cycle. A banner later in the same file kills it. Read to the banner or you will build the wrong thing.
3. ADR-0074 C1 vs ADR-0076. 0076 was written to reverse 0074's turnover-suppression call after a live incident, but 0074 is still marked "Proposed" and its C1 text is unmarked.
4. ADR-0091 vs its own three addenda. Successive rulings (07-17 twice, 09-03) stripped nearly every human-confirm gate from the original Decision 3, which now reads as obsolete on its own.
5. Two renewal-rate formulas coexist on purpose. The Yale-locked formula (Renewed + Transfers) ÷ Expired (2026-07-13) and the dashboard's strict signedRenewed ÷ (signedRenewed + declined + intentToVacate) are both live; the memory notes this is deliberate, and that the two surfaces can still diverge on edge cases.
6. Delinquency threshold drifted three times — >1 month (2026-04-16 scope) → >2 months (2026-05-21 PM policy) → 2.0 months + 6 late payments + 25-day grace (Policy v2, locked 2026-07-23). Only the last is current.
7. Twenty-two duplicate ADR numbers exist repo-wide, including 0104 (a floor-plan-media ADR is filed under the same number as PM action reminders) and 0055.

---

3. Sessions that worked on renewals, and what each left unfinished

Fourteen session directories under /Users/federicochapa/.claude/projects/ were read. Twelve hold substantive renewal memories; agents-010, -federicochapa and -federicoc hold none beyond aspirational product specs.

---

4. Skeletons — built then turned off, abandoned, or carrying a retirement date

4.1 Deleted outright, not merely disabled

• Cohort-walker spawn wiring and workflow-owned holdover — PR #6902, 2026-09-03. The walker's ability to start a renewal was deleted rather than switched off, on the stated reasoning that "a switched-off-but-present starter is exactly the kind of thing that gets accidentally re-armed." The walker survives look-only, permanently Phase-1 shadow.
• transitionSaga + state-machine.ts — PR #1250, 2026-05-20, ~12,834 lines removed.
• Renewal-nudge Lambda and its scheduler — PR #1005, 2026-05-18.
• The old saga-reconciler cron — PR #1075, 2026-05-18, with no replacement, which is what orphaned the ~15 sagas.
• RENEWAL_PREPARE_RETRY_ARMED — deleted 2026-07-07, PR #3257, retry made unconditional.
• RENEWAL_AUTO_START_ENABLED — env fallback retired 2026-07-07, replaced by the durable CONFIG/RENEWAL_ARMS.autoStart row. arm-store.test.ts and renewal-auto-start.test.ts pin that the env var can no longer arm anything.
• TEMPORAL_SHADOW_ENABLED / TEMPORAL_SHADOW_PROPERTY_ALLOWLIST (2026-07-26), RENEWAL_COHORT_WALKER_ENABLED (2026-07-07), SCHEDULING_ENGAGED_AUTONOMOUS_SENDING (2026-07-09), and the original 0025 gating trio TEMPORAL_ACTIVITIES_EFFECT_MODE / TEMPORAL_LIVE_PROPERTY_ALLOWLIST / RENEWAL_OUTREACH_KILL_SWITCH (2026-05-24).
• countersignOnRenewIntent — deleted by ADR-0122.

4.2 Reverted

• PR #3060 co-signer sync, shipped 2026-07-05 and reverted by #3068 the same window for minting phantom Person records; replaced by the narrower signer_missing_email gate (#3062).
• PR #6961 blocked Willows test renewals from touching JP's real AppFolio; reverted on Fede's "the Willows is our test property," then re-solved properly by a per-property pmsWritesAllowedWhileTest opt-in (#9325, merged 2026-09-18).
• PR #7079 undid the shared-read change to the renewals pages (2026-09-04).

4.3 Abandoned plans still sitting in the repo

• docs/planning/renewal-saga-retirement-handoff.md — the whole saga-deletion plan, superseded by ADR-0047 two days after it was written; its blueprint branch fede/phase-c-saga-deletion is 693 commits stale. The doc now says "do not execute it," but a reader who finds the plan first will build the wrong system.
• docs/planning/renewal-saga-gsi-hot-partition.md — ADR-0085's 16-way shard, "Owner: TBD… not yet built."
• docs/planning/ntv-holdover-firm-routing.md (2026-08-31) — closes with an open decision explicitly held for Fede: "this is a decision for Fede, not for me — raised rather than chosen."
• The branch that made the UI query Temporal Cloud directly (fede/ui-temporal-queries) — abandoned as architecturally backwards.

4.4 Arms and gates live today

/Users/federicochapa/.claude/propflowai/src/lib/domain/admin/arms-registry.ts carries three renewal arms. Two are two-factor: a global env token and a per-property flag, both required, fail-closed.

Also live: EMAIL_NTV_FIRM_ROUTING_ENABLED (armed), PROPFLOW_ROSTER_GATE (armed 2026-09-12), RENEWAL_TASK_QUEUE_OVERRIDE (harness only), TEMPORAL_NONDETERMINISM_METRICS_ALERT. Arm state moved from env vars to durable DDB on 2026-06-09 (PRs #2069, #2088) precisely because every worker deploy had been silently resetting arms to disarmed.

Current per-property state, per the memories: Camellia sending and holdover ON (confirmed intentional 2026-07-23); Willows and Yale OFF; Camellia's lease-execution notice gate OFF.

4.5 Temporal patches carrying a retirement date

All 45 retireBy markers live in one file: /Users/federicochapa/.claude/propflowai/src/__tests__/temporal-patched-ledger.drift.test.ts. This is ADR-0108 D5 in code — every live patched() guard in the renewal workflow must carry a retireBy (landed + 60 days); the drift test warns once it passes and fails once retireBy + 14 days has passed.

Live renewal patches and their dates: renewal_infra_classifier_budget_v1 (landed 2026-09-03, retire 2026-11-02) · countersign_reminder_requires_signature_v1 (2026-07-31 → 2026-09-29) · renewal_commitment_stated_phase_v1 and renewal_negotiating_intent_v1 (2026-08-01 → 2026-09-30) · renewal_scope_pin_v1 (retire 2026-11-19) · renewal_scope_pin_v2/v3/v4 (retire 2026-11-20) · outreach_min_gap_v1 and outreach_progress_projection_v1.

Nineteen are already deprecated, including phase0_load_saga_state_v1, letter_mms_in_workflow_v1 and outreach_parallel_v2 (landed 2026-05-16/17, retired 2026-07-23); a six-patch batch retired 2026-08-15; defer_outreach_to_send_window_v1 and renewal_transient_prepare_resilience_v1 (2026-09-05); renewal_holdover_in_workflow_v1 (2026-09-03); renewal_workflow_owned_dispatch_v1 (2026-09-21). The regime is visibly working: retirement PRs landed 2026-09-04 (#7106), 09-14 (#8550), 09-15 (#8608), 09-20 (#9838) and 09-21 (#10431), several of them explicitly racing a ledger freeze date.

4.6 Known residuals deliberately accepted

The 09:00 UTC cron that fires at 3 AM Denver, inside quiet hours. P18 non-AppFolio silent-SENT. The saga/activity-log drift with no tracking (B4). The letter-MMS leg with no already-sent-this-cycle guard (B8). The two divergent renewal-rate formulas. Walk-in move-ins with no application getting no notice. Holdover changing the rent without flipping AppFolio's lease-level month-to-month flag. No eviction or legal-hold gate at all, by explicit ruling.

---

5. What the 2026-09-03 architecture decision decided, and what shipped

Source: /Users/federicochapa/.claude/propflow-docs/artifacts/renewals-architecture-decision-2026-09-03.html.

5.1 The choice

Four options were put up. Option B was chosen: "one starter, one owner, fix in place." Option A was patch-only; Option C was to finish the cohort-walker cutover; Option D, a full rewrite, was rejected on volume — 133 lifetime renewals did not justify it, with a note to revisit if volume grows tenfold. The problem being solved was that two half-built systems could each start a renewal, and the newer one (the cohort walker) had run one live morning and miscounted five tenants about a month early, because it used a 120-day window where the scanner used 90.

Five sub-decisions:

• Q2 — delete the walker's start capability outright, rather than switch it off, because "a switched-off-but-present starter is exactly the kind of thing that gets accidentally re-armed."
• Q3 — make stable renewal addressing default-on, the one deliberate exception to off-by-default.
• Q4 — let the five early offers stand and pause their ladder rather than claw them back.
• Q5 — yes: text and call for a missing email before paging a PM.
• Cadence, in Fede's words: "reminder 3 times like we do today with leases. business days only. once per day max."

5.2 What shipped

Essentially all of it, the same day or within 48 hours.

Follow-through in the fortnight after: #7026/#7035/#7038 (record the PMS reference, save the right AppFolio id, keep the offer document), #7067/#7068/#7069 (archived and harness sagas leaking into the open-saga reads), #7104 (group the day-before heads-up into one email per property per working day), #7106 (retire two overdue patches).

5.3 What did not go to plan

• #6913, the full Willows live-run harness for the real start path, was flagged as needing Fede's manual merge — the one piece of the decision left hanging.
• #6961, which stopped Willows test renewals touching JP's real AppFolio, was reverted the next day on "the Willows is our test property," and only properly re-solved two weeks later by #9325.
• #7101 (2026-09-04) fixed the rollover so our own unanswered offer no longer blocks it — and shipped with no gate, converting three units the next morning instead of the intended one. That is what produced both the "silence is not approval" ruling and the "i dont want to offer anything, just roll mtm" ruling, and #7137 the day after.
• The published priorities page still describes Option B as having moved holdover into the workflow. #6902 moved it out. (Inference: the page was written from the pre-decision option list and never corrected.)

Source: scratchpad/report-temporal.md

Temporal health check — renewals (READ-ONLY)

Date of check: 2026-09-23 (queries run ~23:10–23:40 UTC) Namespace: propflow-prod.hmqma @ propflow-prod.hmqma.tmprl.cloud:7233 CLI: temporal 1.7.0 (Server 1.31.0, UI 2.49.1), at /opt/homebrew/bin/temporal Auth: Keychain propflow-temporal-api-key-prod (404-char API key). TEMPORAL_ADDRESS / TEMPORAL_NAMESPACE were set explicitly per instructions; the Keychain copies are stale. Window: StartTime BETWEEN '2026-06-25T00:00:00Z' AND '2026-09-24T00:00:00Z' Scope: list / count / describe / show only. No terminate, signal, reset, cancel, or repo edit.

Hard caveat on the 90-day window. The old namespace propflow-renewal-prod.hmqma is gone — nslookup propflow-renewal-prod.hmqma.tmprl.cloud returns NXDOMAIN, and every CLI call against it fails with failed reaching server: no children to pick from. So executions before the 2026-09-03 cut are not queryable at all; the numbers below cover roughly 2026-09-03 → 2026-09-23 (20 days), not 90. Anything claiming a full-quarter renewal trend would be fabricated. The cut is described in /Users/federicochapa/.claude/propflowai/docs/runbooks/temporal-namespace-cut.md (ADR-0045).

---

1. Inventory (from the repo)

Repo root: /Users/federicochapa/.claude/propflowai

Renewal task queue

• propflow-renewal — declared inline in src/lib/temporal/client.ts:135 (TASK_QUEUE) and src/lib/temporal/executed-lease-fetch-client.ts:36; overridable only by RENEWAL_TASK_QUEUE_OVERRIDE (test-harness only, must never be set on the prod task def). Confirmed live via temporal task-queue describe, and it is the queue on all 16 running renewalWorkflow, all 19 running executedLeaseFetchWorkflow, and both renewal schedules.
• Sibling queues: propflow-leasing, propflow-leasing-eval, propflow-tour, propflow-turnover, propflow-maintenance, propflow-maintenance-comms, propflow-vendor-chase, propflow-collections-chase, propflow-escalation, propflow-inbound-package, propflow-mass-comms, propflow-pms-sync-eval, propflow-review, propflow-onsite-pricing, propflow-conversation-topics, propflow-conversation-rationale, propflow-conversation-grade, propflow-promise.
• src/lib/temporal/connection.ts holds no queue names — only TEMPORAL_ADDRESS / TEMPORAL_NAMESPACE (namespace is fail-closed, no default, per ADR-0045) and auth selection (API key → mTLS → localhost).

Where the renewal worker actually runs in production

Not src/lib/temporal/workers/renewal-worker.ts — that is the local-dev runner. The deployed entrypoint is:

• services/renewal-worker/index.ts (449 lines) — one process, bundleWorkflowCode({ workflowsPath: require.resolve('src/lib/temporal/workflows') }) built once and shared across 17 Worker.create calls (renewal, tour, onsite-pricing, turnover, maintenance, maintenance-comms, vendor-chase, collections-chase, mass-comms, conversation-topics, conversation-rationale, conversation-grade, promise, tenant-confirmation-review, leasing, leasing-eval, inbound-package, escalation). Identity = ${taskQueue}-${buildId}-${ecsTaskId}, which is exactly the shape seen in the live poller list (§6). Per-worker concurrency default 5/5. Has a hard-exit watchdog added 2026-08-29 after propflow-promise hung in DRAINING and every restart ended in SIGKILL (exit 137).
• services/renewal-worker/Dockerfile (node:24-slim, two-stage, runs tsx), services/renewal-worker/healthcheck.js.
• infra/temporal-worker/task-definition.template.json — family propflow-renewal-worker-__ENV__, cpu 512, memory 3072, ECR 194925971150.dkr.ecr.us-east-1.amazonaws.com/propflow-renewal-worker, stopTimeout: 120, SENTRY_DSN + SENTRY_ENVIRONMENT + RENEWAL_AUTONOMOUS_SENDING + TEMPORAL_ADDRESS/NAMESPACE.
• infra/temporal-worker/{provision.sh,bootstrap-secrets.sh,preflight-secrets.py,ecr-lifecycle-policy.json,iam-*.json} — shell/CLI provisioning. No terraform, CDK, fly.io, Railway, systemd or launchd anywhere.
• Deploy: .github/workflows/deploy-renewal-worker.yml — triggered by workflow_run on CI-completed/main (only when conclusion == success && event == push) plus workflow_dispatch; no cron. ECS cluster propflow-renewal-worker-prod, service renewal-worker, desiredCount 2 in prod (1 stage), minimumHealthyPercent=100 / maximumPercent=200, circuit breaker with rollback, --force-new-deployment, then aws ecs wait services-stable. Redundant builds skipped by a source-tree-hash ECR tag (deployed-<env>-<srchash>).
• Activities: src/lib/temporal/workers/renewal-worker-activities.ts — single source of truth, spreading 8 modules (renewal, renewal-auto-start, renewal-cohort-walker, renewal-scope → pinRenewalScopeActivity / checkpointRenewalScopeActivity, pm-action-reminder-renewal-bridge, executed-lease-fetch, conversation-review, grader-coverage). Extracted 2026-09-20 precisely because the dev runner and the Fargate entrypoint each hand-maintained a copy; parity is now pinned by src/__tests__/renewal-worker-bridge-registration.test.ts. (This is the fix for the §4 failures.)

Workflow types addressed at propflow-renewal

renewalWorkflow (RENEWAL_WORKFLOW_TYPE, renewal-workflow.ts:464), renewalAutoStartScanWorkflow, walkRenewalCohortWorkflow, conversationReviewScanWorkflow, graderCoverageScanWorkflow, executedLeaseFetchWorkflow. The whole 33-type barrel src/lib/temporal/workflows/index.ts is bundled for every worker; routing is by (workflowType, taskQueue), there is no per-queue subsetting.

Schedule definitions in repo

Specs live in the client modules (src/lib/temporal/client.ts, pm-action-reminder-backstop-client.ts, tour-client.ts, turnover-client.ts, onsite-pricing-client.ts, …); scripts/temporal/upsert-*-schedule.ts are thin CLI wrappers (--cron, --tz, --armed/--paused, --note). Contract source of truth: scripts/temporal/adr0045-namespace-contract.ts (SCHEDULES, cron/tz read off the live source namespace on 2026-09-02, not code defaults; SEARCH_ATTRIBUTES = renewalId, leaseId, propertyId, currentStage, conversationId, workOrderId, traceId, all Keyword).

Nightly renewal harness canary

.github/workflows/nightly-renewal-harness.yml — a **GitHub Actions cron (0 9 *, 09:00 UTC), not a Temporal Schedule.** No-real-comms tiers only (Tier 0, no-comms Tier 1, Tier 4), tenant tenant-gauntlet-appfolio-45, owned Twilio number +18334085783; posts failures to Slack #alerts (C0BGTNSP04C). The heavier run_willows_live_run (a real renewalWorkflow on an isolated queue) is workflow_dispatch-only and default off. Also: .github/workflows/renewal-replay.yml (PR-triggered, path-filtered, hermetic 30-simulated-day replay), renewal-evals.yml, renewal-evals-sms.yml, renewal-evals-scoping.yml, and schedule-drift.yml (30 7 *) — which reconciles EventBridge + vercel.json crons against config/automations.toml but does not cover Temporal Schedules at all.

---

2. Execution counts (2026-06-25 → 2026-09-24, effectively 2026-09-03 →)

Namespace-wide, grouped by status

temporal workflow count --query "StartTime BETWEEN ... GROUP BY ExecutionStatus" → Total 59,677

Renewal-related, per type

GROUP BY is only supported on ExecutionStatus in Temporal Cloud (GROUP BY WorkflowType is rejected: "'GROUP BY' clause is not supported for search attribute WorkflowType"), so each type was counted individually.

walkRenewalCohortWorkflow = 20 and renewalAutoStartScanWorkflow = 22 are consistent with ~20 daily fires since the 2026-09-03 cut, i.e. no missed days — not a 90-day gap.

Zero ContinuedAsNew anywhere in the renewal family. Verified explicitly for renewalWorkflow, executedLeaseFetchWorkflow, prospectOutreachWorkflow, tourWorkflow, turnoverWorkflow, collectionsChaseWorkflow — all Total: 0. All 19,718 ContinuedAsNew executions are conversationGraderWorkflow.

---

3. Currently Running renewal workflows

16 running renewalWorkflow. Oldest start 2026-09-03T15:18:05Z; 15 of the 16 started in a 17-second burst at 2026-09-03T15:18:05 → 15:18:22. That burst is the ADR-0045 migration recreating the cohort on the new namespace, so "oldest start time" is a migration artifact, not real age — true age of the underlying renewals predates it and is unrecoverable (namespace deleted). The 16th started 2026-09-18T14:30:06Z.

Workflow ids encode the lease end date, and every one is in the future — 2026-10-31 (5), 2026-11-30 (7), 2026-12-31 (4). Nothing is running past its lease end.

Sample of 6 described:

Assessment: none of the 16 is stuck. Zero pending activities, zero pending children, no retry backoff anywhere, history ~104–122 events / ~20–25 KB — two orders of magnitude below any Temporal warning threshold.

What they are holding on. Tail of renewal-lease_fa611644-…-2026-12-31:

 94 2026-09-12T15:18:10 ACTIVITY_TASK_SCHEDULED act=sendReminderSms
 96 2026-09-12T15:18:12 ACTIVITY_TASK_COMPLETED
100 2026-09-12T15:18:12 MARKER_RECORDED
101 2026-09-12T15:18:12 UPSERT_WORKFLOW_SEARCH_ATTRIBUTES
104 2026-09-12T15:18:12 TIMER_STARTED  timer=5  dur=6856907.765s

Last real work was a successful sendReminderSms on 2026-09-12, then it parked on one timer of 6,856,907 s ≈ 79.4 days — a single sleep to the next renewal milestone. Correct behaviour, but see §7: one 79-day timer means 79 days of silence with nothing to alert on if it is wrong.

Flagged: executedLeaseFetchWorkflow — 19 of 22 Running, unbounded poll loop

Oldest: exec-lease-fetch-1773625953462-transfer-1031, started 2026-09-03T15:45:09Z, still running after 20 days, history length 693, 0 pending activities.

Event census for that run:

WORKFLOW_EXECUTION_STARTED 1 | WORKFLOW_TASK_* 126 each
ACTIVITY_TASK_SCHEDULED 63 | STARTED 63 | COMPLETED 63
TIMER_STARTED 63 | TIMER_FIRED 62
...
687 2026-09-23T16:20:14 ACTIVITY_TASK_SCHEDULED act=fetchAndCacheExecutedLeaseActivity
689 2026-09-23T16:20:33 ACTIVITY_TASK_COMPLETED
693 2026-09-23T16:20:33 TIMER_STARTED dur=86400s

So: 63 successful poll iterations, each one fetchAndCacheExecutedLeaseActivity → success → sleep 86,400 s, loop, forever. The activity never fails (so no retry alarm ever fires) and the workflow never gives up. executed-lease-fetch-workflow.ts does contain a continueAsNew path, but it has never fired in production — the observed ContinuedAsNew count for this type is Total: 0, so in practice history grows ~11 events/iteration with no reset. One id is literally exec-lease-fetch-appfolio-403-transfer-890 (started 2026-09-13T16:30:08) — named after an AppFolio 403, still polling 10 days later. This is the one genuinely unhealthy pattern in the renewal family: 19 workflows that will poll AppFolio daily forever for an executed lease that is apparently never going to appear.

---

4. Failed / Terminated / TimedOut

Failed — 25 namespace-wide, only 2 are renewalWorkflow

Both are harness probes, both on 2026-09-20, both historyLength: 29:

• worker-version-probe-1789895665729 — started 2026-09-20T09:14:26Z, closed 09:14:42Z
• smith-reprobe-1789896489692 — started 2026-09-20T09:28:09Z, closed 09:28:25Z

Root cause (identical for both), from the ACTIVITY_TASK_FAILED event:

Activity function pinRenewalScopeActivity is not registered on this Worker,
available activities: ["classifyPrepareFailure","decideOfferPreparedTransition",
"dispatchAppFolioWrite","dispatchPmsPrepare","dispatchVoiceCall",
"escalateHeldRenewalActivity","escalateToPM","extractPrepFailureDetail","loadSa…
type: NotFoundError

This is a worker/workflow-code skew: workflow code calling pinRenewalScopeActivity was live while the deployed worker did not register it. It is exactly the failure class Worker Versioning / Build IDs exists to prevent, and the queue is UNVERSIONED (§6). This also explains the single red nightly harness run, GitHub Actions run 35501662838, 2026-09-20T09:12:25Z, failure in 2m26s — its log shows Posted the harness failure alert to #alerts. So the alerting path worked.

The other 23 Failed are not renewal: 22 maintenanceCommsWorkflow (maintenance-comms-wo-WILL-0029xx…003381, 2026-09-04 → 2026-09-22, ~1/day) and 1 benchRobotCallWorkflow (bench-robocall, 2026-09-04T14:39:51). Sample cause on maintenance-comms-wo-WILL-003381: Maestro comms: WO WILL-003381 not found / type InvalidPayload. Steady daily rate, different worker, worth its own ticket but outside renewals.

Terminated — 319 namespace-wide, 132 are renewalWorkflow — none are customer renewals

Every terminated renewalWorkflow has a saga_<uuid> workflow id (e.g. saga_0ee5311e-3e39-4d6d-a1a2-eb97fbbff86f, saga_bfcd0c7d-8726-40fc-8670-bdd7de5c4105), not the customer renewal-lease_…-<leaseEnd> shape. Termination reasons sampled: matrix cell cleanup (×4) and matrix cleanup (×2), all at 2026-09-23T09:18–09:20Z, history 52–124 events.

Daily distribution is a flat 6/day from 2026-09-05 to 2026-09-23 (21 on 09-04, 3 on 09-03, and 09-20 missing — the day the harness went red). This is the nightly eval matrix tearing down its own cells, i.e. expected harness hygiene, not production breakage. It does mean the raw "132 terminated renewals" number is badly misleading on any dashboard that does not filter saga_*.

TimedOut — 50, zero renewal

Examples: turnover-cohort-walker-wf-2026-09-23T11:03:00Z (start 11:03:00, close 11:13:00, history length 6) — a 10-minute run timeout hit with only 6 events, i.e. the run never got past its first workflow task; collections-cohort-walker-daily-wf-2026-09-23T09:00:00Z; maintenance-comms-wo-WILL-003082 (2026-09-09T07:31:48). 18 walker timeouts against 9,692 fires is ~0.19%, but the 6-event shape says "no worker progress", not "slow work".

Non-determinism

No non-determinism errors surfaced in the renewal family in the window: 0 renewalWorkflow TimedOut, and the only 2 Failed are the registration skew above. A renewalWorkflow non-determinism error would normally appear as a wedged run with a stuck workflow task — none of the 16 Running has one.

---

5. Schedules — 12 registered on propflow-prod.hmqma

• missedCatchupWindow is null (zero) on every schedule checked — no catch-up misses.
• The 10 unpaused schedules carry the note ADR-0045 cut — activating target schedules.
• Both paused schedules are paused intentionally, per their own notes: conversation-review-daily — "Daily deterministic conversation pre-filter. The LLM reviewer pass is retired (2026-08-28, audit gap…)"; availability-warm-cache-refresh — "Background refresher for the warm tour-availability cache (Willows-first rollout gate — only touches…)". Neither is a renewal schedule silently dead; both frozen at 2026-09-03 because that is the cut date.
• The two renewal schedules and the pm-action-reminder backstop are all healthy and current (last fire within the hour of this check).

Repo-side schedule facts worth carrying

• conversation-review-daily is paused by a standing human directive recorded in its live Temporal note: "Killed by Fede 2026-08-15 — the 22:00Z 20-parallel-call volley; do not unpause without his say-so." Do not unpause.
• availability-warm-cache-refresh never existed on the source namespace; it is a Willows-first rollout gate, paused by design.
• Cron drift is real and documented. renewal-auto-start-daily runs live at 30 8 America/Denver while the code default in client.ts is 0 9 UTC — anyone re-upserting with defaults moves it ~6 hours. adr0045-namespace-contract.ts exists specifically to pin the live values.
• EXCLUDED_SCHEDULES — grader-coverage-daily, maintenance-eval-daily, pms-sync-eval-daily — are declared in code but registered on no namespace, which is why only 12 of the 15 defined schedules appear above.
• scheduling-engaged-walker was orphaned (its workflow was deleted) and dropped at the cut; TOMBSTONE_SCHEDULES is intentionally empty.
• pm-action-reminder-backstop ships PAUSED from scripts/temporal/upsert-pm-action-reminder-backstop-schedule.ts unless --armed is passed; it is correctly armed in prod (488 actions).

---

6. Worker health

Live pollers on propflow-renewal (temporal task-queue describe)

BuildID       Type      ApproximateBacklogCount  BacklogAge  TasksAddRate  TasksDispatchRate
UNVERSIONED   activity                        0          0s             0                  0
UNVERSIONED   workflow                        0          0s             0                  0

UNVERSIONED  activity  propflow-renewal-45d628b9cf0f-ip-172-31-6-144.ec2.internal    21s ago
UNVERSIONED  activity  propflow-renewal-37d1bc5f5ba7-ip-172-31-77-6.ec2.internal     22s ago
UNVERSIONED  activity  propflow-renewal-37d1bc5f5ba7-ip-172-31-6-5.ec2.internal      24s ago
UNVERSIONED  activity  propflow-renewal-45d628b9cf0f-ip-172-31-65-244.ec2.internal   29s ago
UNVERSIONED  workflow  propflow-renewal-45d628b9cf0f-ip-172-31-6-144.ec2.internal    24s ago
UNVERSIONED  workflow  propflow-renewal-37d1bc5f5ba7-ip-172-31-6-5.ec2.internal      25s ago
UNVERSIONED  workflow  propflow-renewal-45d628b9cf0f-ip-172-31-65-244.ec2.internal   41s ago
UNVERSIONED  workflow  propflow-renewal-37d1bc5f5ba7-ip-172-31-77-6.ec2.internal     53s ago

• 4 worker processes polling, last access 21–53 s ago, zero backlog, zero backlog age. The queue is not starved.
• Build ID is UNVERSIONED for every poller — Worker Versioning is not in use (see §7).
• Two distinct task/image hashes are polling at once (45d628b9cf0f, 37d1bc5f5ba7), consistent with the in-flight deploy below. Running executions carry 4–6 entries in their BuildIds search attribute (["unversioned","unversioned:3af2605880a7","unversioned:ec661ba713dd","unversioned:f6869e8c3ce9"] on one sample) — mixed-code-version execution is normal here.

Last deploys — gh run list --workflow deploy-renewal-worker.yml --limit 5 (no --watch)

Deploys fire off every successful CI run on main (workflow_run chained, no cron), ~10–15 min each. Three deploys were in flight inside 26 minutes — 35930422076 (15m12s, from 22:49) was still running when 35931136168 started at 22:57, and 35932127952 started at 23:09.

Note on the 4 pollers: the prod service runs desiredCount: 2 with maximumPercent: 200, so 2 old + 2 new tasks during a rolling deploy is the expected steady state mid-deploy, not a leak. What is not ideal is the rate — chained workflow_run deploys with no concurrency group mean a new rollout can begin before aws ecs wait services-stable has settled the previous one, which widens the window in which two different code versions serve the same queue.

Nightly renewal harness — gh run list --workflow nightly-renewal-harness.yml --limit 5

4/5 green; the one red is the activity-registration skew in §4, and it did post to #alerts.

Renewal replay gate — gh run list --workflow renewal-replay.yml --limit 5

5/5 success (2026-09-22T23:08Z → 2026-09-23T20:57Z), all pull_request-triggered. History replay is running per-PR and passing — this is the main defence against non-determinism, and it is working.

Sentry

Not queried (optional, and querying it was outside what this read-only pass ran). The helper does exist: .claude/skills/sentry/SKILL.md (/sentry issues|issue <id>|investigate <id>|stats), org propflow-ai, project javascript-nextjs, token from Keychain propflow-sentry-token:

SENTRY_TOKEN=$(security find-generic-password -a sentry -s propflow-sentry-token -w)
curl -s -H "Authorization: Bearer $SENTRY_TOKEN" \
  "https://sentry.io/api/0/projects/propflow-ai/javascript-nextjs/issues/?query=is:unresolved&statsPeriod=24h&limit=25"

Temporal-relevant runbooks to pair with it: docs/runbooks/sentry-temporal-unreachable.md, docs/runbooks/sentry-temporal-api-key-expiring.md, docs/runbooks/sentry-turnover-stall.md. No Sentry numbers are stated here rather than guessed.

Nondeterminism alerting — a stub, and it is off

• src/lib/temporal/nondeterminism-alert.ts (ADR-0052) exports captureNondeterminismAlert(), isNondeterminismFailureReason() (matches nondetermin* or code TMPRL1100) and TEMPORAL_WORKFLOW_TASK_FAILED_METRIC = 'temporal_workflow_task_execution_failed'. It was written after the letter_mms_in_workflow_v1 patch wedged migrated Camellia renewals for a week with zero alerting.
• src/lib/temporal/nondeterminism-metrics-drain.ts — startNondeterminismMetricsAlert() is called from services/renewal-worker/index.ts, but it is feature-flagged off by default (TEMPORAL_NONDETERMINISM_METRICS_ALERT=true) and the MetricsBuffer.retrieveUpdates() wiring was never implemented — drainFn defaults to returning nothing. A known bug-in-waiting is documented inline: the Sentry task_queue tag is hardcoded from opts.taskQueue, so once the drain does land, tour/turnover/maintenance non-determinism will be mis-tagged propflow-renewal.
• So the live defence against non-determinism is entirely pre-merge: src/__tests__/renewal-workflow-replay-corpus.test.ts + .github/workflows/renewal-replay.yml (5/5 green above), the patch ledger guard src/__tests__/temporal-patched-ledger.drift.test.ts, and the prod-history canary scripts/temporal/export-recent-histories.ts. There is no runtime alarm.

---

6b. Renewal workflow shape (src/lib/temporal/workflows/renewal-workflow.ts, 3,743 lines)

• continueAsNew: NO. renewalWorkflow never calls it. Only maintenanceCommsWorkflow, prospectReengagementWorkflow, executedLeaseFetchWorkflow and conversationGraderWorkflow do — and of those, only conversationGraderWorkflow actually fires it in prod. client.ts:239 states outright that "continueAsNew before the ceiling is the real fix and remains out of scope".
• Signals (6): pmsChanged, pmsFailed, deliveryStatus, tenantIntent, pmAction, pmStatusOverride. Updates (3): retryLetter, externalResolution, pmDecision. Query (1): getSnapshot.
• Long waits: condition(() => !isPaused() || isSettledOrTerminal()) with no timeout (unbounded pause hold, line 1356); holdover park condition(isSettledOrTerminal) with no timeout (2471) plus a wake-at timer (2499); awaiting response 24 h; reminder step 1 24 h, step 2 7 days; awaiting countersign 14 days; expiry nudges per expiry-nudge-schedule.ts. All overridable via input.timeouts.
• Versioning: patched() / deprecatePatch() — no getVersion, no version constant. 8 live patch gates (renewal_scope_pin_v1…_v4, renewal_commitment_stated_phase_v1, countersign_reminder_requires_signature_v1, renewal_infra_classifier_budget_v1, renewal_negotiating_intent_v1) and ~16 retired deprecatePatch markers kept for replayability. Worker Versioning is stamped but disabled: buildId comes from PROPFLOW_GIT_SHA/GIT_COMMIT, useVersioning is gated on TEMPORAL_USE_VERSIONING === 'true' which is unset in the task def — matching the UNVERSIONED build id on every live poller.
• Retry policies are inline at the proxyActivities call sites, not in retry-policies.ts: shortActivities 60 s startToClose, 1 s/×2/60 s/5 attempts; projectionActivities 5 s, 500 ms/×2/2 s/2; longActivities (dispatchVoiceCall, dispatchAppFolioWrite, sendRenewalLetterMmsActivity) 10 min startToClose + 60 s heartbeat, 2 s/×2/2 m/5; pmReminderActivities 30 s, 1 s/×2/30 s/3. All carry nonRetryableErrorTypes: ['InvalidPayload','InvalidCredentials','PermissionDenied'].
• Idempotency: yes, and it is the good kind. activityIdempotencyKey(name) = ` ${workflowId}-${runId}-${activityName}-${activitySeq++} — a monotone counter advanced only when an activity is scheduled, with runId in the key so a reopened workflow cannot collide. It replaced a historyLength-based key that drifted on deduped signals and caused duplicate Twilio/SES sends. Applied to sendOutreachSms, sendOutreachEmail, dispatchVoiceCall, sendReminderSms-step1/2, sendRenewalLetterMmsActivity, escalateToPM, dispatchPmsPrepare:${attempt} and others; retryLetter` uses an event-derived key instead.

---

7. Assessment

Overall: Temporal is solid for renewals. The evidence: 16 running customer renewals with 0 pending activities, 0 retry backoff, and 104–122-event histories; 0 renewal timeouts; 0 renewal non-determinism observed; both renewal schedules and the hourly PM-reminder backstop fired on time with 0 catch-up misses; 4 healthy pollers with 0 backlog and 0 backlog age on propflow-renewal; the per-PR replay gate green 5/5; a real patched() discipline with a ledger drift test; and a well-designed activity idempotency key that already survived one duplicate-send incident. The only production-facing renewal failures in the window were 2 synthetic harness probes, and their root cause was fixed the same day. Nothing is wedged and nothing is silently dead.

Two numbers distort the picture and must not be read as breakage: the 132 "terminated renewals" are all saga_* nightly-eval matrix cells, and the 2026-09-03 start times are a migration artifact.

The honest weak spot is not the workflows — it is observability and history growth. Runtime non-determinism alerting is a stub that is off, and nothing in the renewal family ever calls continueAsNew.

Top concrete improvements

1. Bound executedLeaseFetchWorkflow — CERTAIN. 19 of 22 are Running; exec-lease-fetch-1773625953462-transfer-1031 (started 2026-09-03T15:45:09Z) is at history 693 after 63 successful daily polls. exec-lease-fetch-appfolio-403-transfer-890 has polled for 10 days since an AppFolio 403. The continueAsNew path in the file has never fired (ContinuedAsNew Total: 0). Give the loop a deadline (lease end + N days), lower the continueAsNew threshold so it actually triggers, and escalate on give-up. Today this fails silently forever because the activity always succeeds — no retry alarm can ever catch it.

1. Wire the non-determinism metrics drain and turn it on — CERTAIN. nondeterminism-metrics-drain.ts is called from the prod entrypoint but drainFn returns nothing (MetricsBuffer.retrieveUpdates() was never implemented) and it is gated off by TEMPORAL_NONDETERMINISM_METRICS_ALERT. This is the exact gap that let letter_mms_in_workflow_v1 wedge migrated Camellia renewals for a week unnoticed. Fix the hardcoded task_queue tag at the same time, or tour/turnover/maintenance events will all report as propflow-renewal.

1. Add continueAsNew to renewalWorkflow — LIKELY. Zero ContinuedAsNew across the whole renewal family. Current histories (~104 events, ~20 KB) are far from any limit, so this is not urgent — but the workflow has a 14-day countersign wait, a 7-day reminder wait, and two condition() waits with no timeout at all (the pause hold at line 1356 and the holdover park at 2471). A renewal that pauses, holds over and re-offers has no reset point, and 15 patch markers already ride on a single run.

1. Enable Worker Versioning — LIKELY. Every poller is UNVERSIONED; buildId is already stamped from the git SHA and useVersioning is one env var away. Running executions carry 4–6 mixed unversioned:<hash> build ids, and three deploys overlapped inside 26 minutes on the day of this check. Determinism safety currently rests entirely on patched() discipline plus replay corpora — good discipline, but with no runtime net (see #2). Add a concurrency group to deploy-renewal-worker.yml so a rollout cannot start before aws ecs wait services-stable settles the previous one.

1. The 2026-09-20 skew is already fixed — verify, do not re-fix — CERTAIN. Both failed renewalWorkflow probes died on Activity function pinRenewalScopeActivity is not registered on this Worker / NotFoundError. src/lib/temporal/workers/renewal-worker-activities.ts was extracted that same day to make the dev runner and the Fargate entrypoint share one activities map, pinned by src/__tests__/renewal-worker-bridge-registration.test.ts. The harness has been green 09-21/22/23 since. Remaining residue: the two files still fork on concurrency (10/10 dev vs 5/5 prod).

1. **Filter saga_* out of renewal dashboards — CERTAIN.** 132 of 132 terminated renewals are eval matrix cells at a flat 6/day (matrix cell cleanup / matrix cleanup). Any alert or metric on "terminated renewals" is currently 100% noise, which is precisely how a real termination gets missed.

1. Shorten the 79-day timer, or add a self-check — LIKELY. One run is parked on a single 6,856,907 s timer with its last activity on 2026-09-12. That is legitimate Temporal usage, but it means ~79 days with no observable progress and nothing that would notice a mis-computed milestone. Stepped timers turn a wrong sleep into a same-week detection instead of a Q1 surprise.

1. Prune the patch stack — LIKELY. Running executions carry 14–18 TemporalChangeVersion entries (defer_outreach_to_send_window_v1, letter_mms_in_workflow_v1, outreach_parallel_v2, phase0_load_saga_state_v1, renewal_honor_pause_v1, renewal_workflow_owned_dispatch_v1, …). With only 16 live runs, all recreated 2026-09-03, most can be retired via deprecatePatch before the branches become permanent.

1. Put Temporal Schedules under the drift check — LIKELY. renewal-auto-start-daily runs live at 30 8 America/Denver while the code default is 0 9 UTC; re-upserting with defaults moves it ~6 hours. .github/workflows/schedule-drift.yml reconciles EventBridge and vercel.json crons but explicitly does not cover Temporal Schedules — the only thing pinning the live values is adr0045-namespace-contract.ts, a hand-maintained file.

1. Fix the cohort-walker run timeouts — LIKELY (outside renewals). 18 walkTurnoverCohortWorkflow and 6 walkCollectionsCohortWorkflow timed out; turnover-cohort-walker-wf-2026-09-23T11:03:00Z closed at exactly +10m00s with history length 6 — no worker progress, not slow work. 0.19% of 9,692 fires, but that shape points at worker capacity or a poison first task on propflow-turnover. Separately, 22 maintenanceCommsWorkflow failures at ~1/day, all Maestro comms: WO … not found / InvalidPayload.

1. Recover or accept the loss of pre-cut history — CERTAIN. propflow-renewal-prod.hmqma is NXDOMAIN, so no renewal execution history exists before 2026-09-03 and there is no 90-day baseline. If quarter-scale renewal trends matter, export executions somewhere durable (scripts/temporal/export-recent-histories.ts exists); otherwise every future audit restarts at the last namespace cut.

---

Queries that could not be run

• GROUP BY WorkflowType — rejected by Temporal Cloud: "operation is not supported: 'GROUP BY' clause is not supported for search attribute WorkflowType". Worked around with one workflow count per type.
• Old namespace propflow-renewal-prod.hmqma — failed reaching server: no children to pick from; nslookup returns NXDOMAIN. The namespace no longer exists, so the pre-2026-09-03 portion of the 90-day window is unavailable. Not a credentials problem.
• Sentry — not queried (optional; no repo helper confirmed read-only).

Source: scratchpad/report-camellia-history.md

Camellia Apartments — real renewal history, 2026-06-25 → 2026-12-31

Read-only analysis of production data. Property: Camellia Apartments, PropFlow property 1773625953462, AppFolio jpco.appfolio.com property 7, org org_jpco. Renewals live at Camellia since 2026-07-23 (ADR-0108). Generated 2026-09-23.

No number below is estimated unless labelled ESTIMATE. Every figure is reproducible from the scripts named beside it.

---

0. Method, and a correction to the existing tooling

Scripts used (all read-only; all in the session scratchpad, not the repo)

Environment: DYNAMODB_TABLE_NAME=propflow-prod, DATA_BACKEND=dynamodb, AWS_REGION=us-east-1, AWS identity arn:aws:iam::194925971150:user/fede-admin. Nothing was written to DynamoDB, AppFolio, Temporal or Slack. No tenant was contacted.

Two tooling defects found on the way in — both matter beyond this report

(a) scripts/_audit-camellia-renewals.ts is stale and reports 23 false CRITICAL findings. It joins sagas to tenants on saga.tenantId. That field no longer exists: production RenewalSaga records key on personId and leaseId (verified — the field set on 120 live Camellia sagas is GSI4PK, GSI4SK, closedAt, closedReason, holdoverOfficeNotifiedAt, id, lastError, lastRunStartedAt, leaseId, migratedAt, migratedFromState, negotiatingCondition, negotiatingSince, openedAt, openedBy, personId, pmsRef, policySnapshot, precededBy, propertyId, state, successorClaim, tenantSignedNotifiedPmsRef, transferredToUnitNumber, updatedAt, version, workflowId). The join therefore resolves nothing, every tenant prints as ?, and every AppFolio cross-check fails open, producing 23 spurious saga.state=EXECUTED but NO AppFolio renewal_summary row exists CRITICALs. Anyone who has run this script since the ADR-0035 D2 person-spine migration has been reading noise. Its comment also asserts that "PropFlow saga.pmsRef does NOT correspond to AppFolio OccupancyId … the only reliable cross-reference is by UnitName + tenant last name." That is now wrong too: TenantOccupancy.pmsOccupancyRef joins cleanly to renewal_summary.OccupancyId (24/43 in-window occupancies matched directly; the rest have no AppFolio renewal row at all, which is the real finding).

(b) A window filter on PropFlow Lease.endDate silently hides every successful renewal. When a renewal completes, the lease's endDate is advanced to the new end date, so the case drops out of a "lease ends in the window" query. My first pass found 43 cases and zero renewals. Re-deriving the window from AppFolio renewal_summary.PreviousLeaseEnd recovered 9 more units — 203, 210, 215, 401, 411, 417, 503, 511, 607 — all nine of them the renewals. Any dashboard or report that windows on current endDate under-reports the renewal rate to zero. Final case set: 52.

---

1. The renewal cases in the window

52 renewal cycles whose original lease end falls 2026-06-25 → 2026-12-31. Names are first-name + unit.

Rent columns: rent = rent in force; offer = the 12-month renewal rent Clara prepared; mkt = Lease.marketRent as synced from AppFolio.

Outcome totals

Resolved cases (renewed + declined/vacate + transferred) = 32. Renewal rate among resolved cases: 9/32 = 28%.

Median time from first outreach to countersignature, over the 9 renewals: 16 days (range 4–59).

---

2. The channel funnel

What actually got sent (Lease.channelOutcomes, Lease.renewal*SentAt, Lease.preparedOffer)

Reply rate by channel

Counting inbound tenant messages on the case threads (Message.role === 'tenant', direction derived per message-provenance.ts):

The voice numbers are misleading on their face: 173 "tenant" turns on voice threads are overwhelmingly transcribed voicemail greetings and call-screening robots, which the ASR records as tenant speech. See §3.

Which channel produced the decision

Of the 9 renewals:

The only decline that arrived through Clara also came by SMS: Simone (603) replied 39 minutes after the letter text, and had her notice to vacate filed in the portal 5 h 36 m after first contact.

Text is the channel that works. The call has produced zero decisions in this window.

Fede's hypothesis, quantified

"people don't answer the call for the most part"

Confirmed, and it is worse than the stored outcome flag says. 26 renewal calls were placed in the window. Classifying each from its stored transcript (Conversation.messages, kind='renewal_call'):

2 of 26 calls (7.7%) reached the person they were for. Zero produced a renewal decision.

Lease.channelOutcomes.voice says connected for 12 of these 26 calls. Only 2 of those 12 actually reached the tenant — a 83% false-positive rate on the "connected" label. The flag is set whenever the far side produces speech, so voicemail greetings ("This is Deborah, leave me a message") and screening bots ("I'll see if this person is available") are all recorded as connected. Any dashboard, eval or policy that keys off channelOutcomes.voice === 'connected' is reading a number that is wrong five times out of six.

What happened after an unanswered call

Clara leaves a voicemail — "Sorry I missed you — I will text you the details so you can look them over whenever you have a minute" — and the cadence continues on SMS. The promise is kept: every case with a recorded call also has the letter SMS.

But the sequencing is the finding. The text does not follow the call; it precedes it by about a minute. Median gap from letter SMS to the renewal call: 1.3 minutes; 26 of 27 same-cycle pairs had the call inside 5 minutes of the text. So the voicemail's "I will text you the details" describes a text the tenant already received before the phone rang. The call adds a ring, a voicemail and an AI-disclosure risk, and adds no information the SMS did not already carry 60 seconds earlier.

After the voicemail the ladder is: reminder #1 at ~2 days, reminder #2 at ~9 days, then nothing until an expiry nudge inside the last 30 days (only 3 cases reached that band). There is no second call attempt in any case in the window — voiceDispatch.attempts is 0 on all 11 leases that carry the field.

Outreach timing

Median first outreach is 89 days before the original lease end (n=31; range 14–119). Distribution: 90+ days 15 cases, 60–89 days 7, 30–59 days 6, under 30 days 3. Three cases were first contacted inside 30 days of lease end (unit 212 at 14 days, unit 414 at 21, unit 620 at 27). The 119-day cases are the 2026-12-31 cohort, contacted 2026-09-03 — a month before the 90-day window is supposed to open.

---

3. The calls, one by one

All 26 in-window renewal calls, from the stored transcripts. ElevenLabs conversation ids are given for audio pull-through.

Hallucination / wrong-fact review

I found no fabricated rents, terms or dates in any of the 26 transcripts. Every rate Clara spoke matches the preparedOffer on the lease. Specific checks:

• David 105: spoke "$1,197, 6 and 12 month" — matches preparedOffer.terms exactly.
• Eloisa 114: spoke "$1,350 / $1,350 / month-to-month $1,450" — matches exactly.
• Carolina 618: told a recording service "her lease ends December 31st" — correct.

Two non-hallucination wrong-fact moments worth naming:

1. Ron 510 — Clara narrated her own uncertainty into the recording: "Looks like I may have reached a voicemail or the line isn't connecting." That sentence was left on the tenant's voicemail.
2. Milo 303 — Clara asked a stranger "Is this Milo?" after having already opened with "this is Clara from Camellia Apartments" and the reason for the call. The unit and the fact of a lease renewal were disclosed before identity was established.

The transfer path has a separate, previously-known defect visible here: Maxwell 606 (08-30) asked for management, Clara transferred, the far side picked up and nobody spoke (transferOutcome: answered_no_voice), and the caller was dropped. A human sent a make-good text 65 minutes later.

---

4. Where it broke

Every case where the system did the wrong thing, with ids and dates.

D1 — Retry storm: 10 sagas for one lease (Luis, unit 416). lease_... unit 416, 2026-07-02 → 2026-09-08. Eight CANCELLED sagas opened in six days — 07-02 14:30, 07-07 02:54, 07-07 03:28, 07-07 04:23, 07-07 05:21, 07-08 02:30, 07-08 03:01, 07-08 03:30 — then PREPARE_FAILED on 07-13 with lastError: "PMS prepare timeout (10 minutes)", then NTV_RECEIVED on 09-08. Nine escalation events fired. The tenant received zero messages across the whole storm (channelOutcomes is null, no renewal messages on the thread). Root cause looks like the classic AbortSignal.timeout < runner maxDuration retry loop (runbook §5, PR #607 class), re-minting a saga per retry instead of resuming the claim. Unit 515 (3 sagas) and unit 524 (3 sagas) show the same shape on the same dates.

D2 — Four PREPARE_FAILED sagas still open, one for 72 days. Units 204 (open since 2026-07-13), 306 (since 2026-08-10), 220, 317, 409 (all since 2026-09-03). Errors: "PMS prepare timeout (10 minutes)" ×3, "PMS prepare failed: Activity task failed" ×3, and one AppFolio 422 on unit 515: PMS_REJECTED httpStatus=422 … HTTP 422 on /renewal_offers/317/send_all_to_tportal: {"title":"Lease could not be sent"…}. None of these self-healed and none were retried to success.

D3 — A tenant was texted a renewal rate for an offer that does not exist (Gabriel, unit 204). Most serious defect in the window. The saga has been PREPARE_FAILED since 2026-07-13. No offer was ever prepared (preparedOffer is null; there is no AppFolio row at all for the unit). On 2026-09-15 14:30 — 64 days later, 15 days before lease end — Clara sent: "Lock in your renewal rate of $1,350/mo for 12 months by signing before then — otherwise your lease rolls to month-to-month at $1,450/mo. Reply here and we'll send you the signing link." There is no signing link to send. The next day, 2026-09-16 17:00, the PM was emailed "Renewal blocked — a signer is missing an email … the PMS won't accept the offer." The tenant was quoted a price and a deadline a full day before anyone told the office the renewal was impossible. This is the holdover/expiry-nudge path firing without checking that an offer exists — the same structural class as the 2026-07-31 incident (an un-gated send path above the decision spine), recurring on a different predicate.

D4 — channelOutcomes.voice = 'connected' is wrong in 10 of 12 cases. See §2. Units 203, 610, 622, 307, 507, 215, 303, 512, 618, 609 are all recorded as connected when no human tenant was ever on the line.

D5 — Escalation tool failure during a live call (Eloisa, unit 114, 2026-09-18 14:36). The renewal_escalate tool call returned an error mid-conversation. Clara's recovery was honest — "I wasn't able to flag that just now, so I'd suggest reaching out to the leasing office directly" — but a Spanish-speaking resident who could not follow the English offer was handed the work of calling the office herself, and nothing was recorded for the team. The identical failure appears on Ekene 210 (2026-07-20 14:50): "I wasn't able to send that through just now — I'll make sure the property team gets your question." Two escalation-tool failures in 52 cases.

D6 — Stale terminal sagas still attached to live cycles. Units 512, 302, 215 each carry an EXECUTED saga from 2026-04-30 / 2026-05-05 alongside the current cycle's saga; unit 120 carries one from 2026-05-29. This is the known "page projects Renewed forever" class from the runbook. Unit 215 is the live example: it is genuinely renewed now, but it was showing an EXECUTED saga from April, five months before the renewal that actually happened.

D7 — Offers land above the property's own advertised rent in 90% of cases. 37 of the 41 prepared 12-month offers are priced above that unit's synced marketRent. Median gap +$150/mo, max +$240/mo (units 307 and 409: offered $1,240, market $1,000 — 24% above). The offer equals the tenant's current rent in every case, so this is a flat renewal, not an increase — but AppFolio's market rent for the same units dropped roughly $150 across the board, and the offer was never re-evaluated. This is exactly Paula's (607) documented complaint generalised: she counter-offered $1,000 citing the property's own website, and she was right. Nothing in the system invalidates a live OFFER_PREPARED saga when a price drop lands.

D8 — Two leases never entered the funnel at all. Units 301 and 122 (both ending 2026-11-30 / 2026-12-31) have no saga, no offer and no outreach of any kind.

D9 — Undeliverable MMS was not retried or escalated. Units 505 and 524: channelOutcomeDetails.letterMms = "Invalid or unreachable number — verify the tenant's phone in the PMS (Twilio 30005: unreachable handset)". The message names the fix, and nobody was asked to do it. Unit 524's voicemail box was also not set up (07-04 call), so that tenant was unreachable on every channel and no one was told.

D10 — No second call attempt, ever. voiceDispatch.attempts === 0 on all 11 leases carrying the field. A single dial at a single time of day is the entire voice strategy. All September calls went out in a 14:30–15:45 UTC block — 08:30–09:45 Mountain, a weekday working morning.

---

5. Where it worked well

Simone, unit 603 — the cleanest case in the dataset. Letter MMS 06-24 17:55, call to voicemail 17:56, tenant replied by SMS at 18:35 asking about her lease end date. Clara corrected her, she said she was moving back to Baltimore, Clara walked her to the portal, and she confirmed "I just submitted my notice to vacate in the portal" at 23:31 — 5 h 36 m from first contact to a filed, portal-recorded decision, entirely autonomous, no human touched it. A decline, but a perfect one: the unit was released for turnover two months early.

Aria, unit 503 — 4 days, no friction. Letter 07-02, reminder 07-04, tenant replied 48 minutes after the reminder ("I signed my renewal yesterday! Did I miss something?"), Clara confirmed her renewal state and closed an open work order in the same thread. Countersigned 07-07.

Sonya, unit 215 — the reminder did the work. Letter 09-03, call screened out, reminder #1 09-05, reminder #2 09-12 15:18 — and 12 minutes later she texted "Yes sorry I'm resigning". Clara confirmed the term and rate correctly and pointed her to the portal. Countersigned 09-16, 13 days end to end.

Ekene, unit 210 — the hardest win, and Clara's handling was right. Voicemail on 07-10, two reminders, then a long SMS on 07-20 asking about the "1 month free" promotion. Clara did not invent a concession; she flagged it and a human answered accurately that the promo was for new leases. Ekene came back on 07-23 asking why a 2-week concession wasn't in the document; Clara flagged again; the human resolved it; "Great thanks just signed!!" on 07-24. Countersigned 07-27. Sixteen days, one genuine negotiation, zero fabricated terms.

Milo, unit 303 — a refusal worth keeping. A stranger answered and said "just send me a piece of mail". Clara declined: "I'm not able to share the account details with anyone other than Milo directly." Correct privacy behaviour under pressure, unprompted.

David, unit 105 — de-escalation. Called a scammer by a resident and stayed calm, re-identified, and delivered the offer accurately. No decision, but no damage.

Autonomous renewals with no human in the loop: 6 of 9 (503, 203, 411, 511, 401, 215). Two needed a human for a concession or price question (210, 607); one bypassed Clara entirely (417).

---

6. The human side, and where PropFlow and AppFolio disagree today

What the Camellia team did by hand

• Unit 417 (Susan) — the PM ran the entire renewal. Clara prepared an offer on 09-03 but letterSentAt is empty, channelOutcomes is null, and the tenant has zero messages. The offer was flagged to the PM at 09-03 14:07. AppFolio shows it sent 09/03 and countersigned 09/16 at $1,191. The renewal happened; PropFlow contributed nothing to it after the prepare.
• Unit 210 (Ekene) — two manual_outbound messages, human-authored, sent through Clara's thread on 07-21 and 07-23 to answer the concession question. This is the takeover path working as designed.
• Unit 606 (Maxwell) — a human sent a make-good text on 08-30 after the transfer dropped him.
• Units 403 and 414 — both sagas were opened by a PM (RenewalOpened … Saga opened by pm), not the scanner.
• 10 cases were flagged to a PM (renewalFlaggedForPmAt): 518, 603, 416, 515, 220, 317, 409, 616, 607, 417. Seven of those ten were escalations about a system failure (prepare failed, missing signer email), not about a tenant.
• pm_renewal_notify emails fired correctly on completion for 203, 411, 210, 401, 511 and on blockage for 204 and 607.

Disagreements between PropFlow and AppFolio, as of 2026-09-23

Five cases. In every one, AppFolio is right and PropFlow is stale.

4 of the 9 renewals (44%) are not reflected as renewed in PropFlow's saga state. Combined with the windowing defect in §0(b), PropFlow's own view of Camellia renewals is materially wrong in both directions: it hides the successes from a date-windowed query, and for nearly half of them the saga never reached a terminal renewed state.

---

7. Opportunities, ranked

1. Stop calling first. Make the call a later, opt-in step — or drop it. 2 of 26 calls (7.7%) reached the intended tenant; 0 of 26 produced a decision; 0 of the 9 renewals came from a call. Meanwhile the letter SMS precedes the call by a median of 1.3 minutes, so the call carries no information the tenant does not already have. 21 of 26 calls hit a voicemail or a screening robot, and 5 of those screening robots were told the tenant's name, unit and lease-renewal business before hanging up. Removing the first-touch call costs nothing measurable in this dataset and removes the "shut up, scammer" failure mode (unit 105) and the third-party-disclosure exposure (units 303, 618). Numbers: §2, §3.

2. Fix channelOutcomes.voice. Right now it is wrong 83% of the time. 10 of 12 connected labels were voicemail or a screening robot. Until this is corrected, every renewal metric, eval and policy decision that reads it is built on a false signal — including any future evaluation of opportunity #1. The transcripts already contain the evidence (a tool_result carrying "At the tone, please record your message", or the classic screening-robot phrases); classify from the transcript, not from the presence of far-side audio. Numbers: §2, §3.

3. Re-price the offer when the unit's market rent drops. 37 of 41 offers (90%) sit above the property's own market rent, by a median of $150/mo. Units 307 and 409 are being asked to renew at $1,240 against a $1,000 market rent — 24% above. One resident (607) already caught this and counter-offered, and she was right; she cost the team a manual negotiation and 59 days. A live OFFER_PREPARED saga should be flagged (not auto-repriced) when a synced PRICE_CHANGE drop lands on its unit, and the PM should see it before the tenant does. Numbers: §4 D7.

4. Never send a price to a tenant when no offer exists. Gate every renewal outbound on a live prepared offer. Unit 204 was texted a $1,350 rate and a signing deadline on 09-15 for an offer that had been PREPARE_FAILED since 07-13, and the PM learned about the blockage the next day. One occurrence in 52 cases, but it is the highest-severity class here: a quoted price with no signable document, and the tenant told before the office. Numbers: §4 D3.

5. Make PREPARE_FAILED self-healing, and never leave it open for 72 days. 4 sagas are open in PREPARE_FAILED right now (units 204, 306, 220, 317, 409); the oldest has been failed for 72 days. Two distinct causes — PMS prepare timeout (10 minutes) and Activity task failed — plus one AppFolio 422. Add a bounded retry with backoff and a hard SLA that converts an unrecovered prepare into a PM task within 24 hours, not 64 days. Numbers: §4 D2.

6. Key the saga claim on the lease cycle, not the attempt. Unit 416 minted 10 sagas and contacted the tenant zero times. Eight cancelled sagas in six days on one lease, nine escalation events, no message ever sent. Units 515 and 524 show the same pattern. The claim should be (leaseId, leaseEndDate) so a retry resumes rather than re-mints. Numbers: §4 D1.

7. Close the loop from AppFolio back to the saga. 4 of 9 renewals (44%) are not marked renewed in PropFlow. Units 607, 511, 215, 417 are all countersigned in AppFolio and not EXECUTED in PropFlow; unit 306 has a live Pending offer PropFlow thinks failed. A reconciler that reads renewal_summary.CountersignedDate and drives the saga to terminal would fix all five, and would also fix the windowing problem in §0(b) by recording the original cycle end on the saga. Numbers: §6.

8. Lead with SMS and lean on reminder #2 — it is the highest-yield touch in the funnel. SMS reply rate is 20% (6 of 30 delivered), and two of the nine renewals plus the only clean decline were decided in the SMS thread. Sonya (215) answered 12 minutes after reminder #2; Ekene (210) answered the day after reminder #2; Aria (503) answered 48 minutes after reminder #1. Only 26 of 32 cases got a second reminder and only 3 ever reached the expiry-nudge band — there is room for a third touch before the last 30 days. Numbers: §2.

9. Handle Spanish. Two of the four calls that reached a human failed on language. Eloisa (114) is a Spanish-dominant resident who answered, could not follow the English offer, and got no escalation because the tool failed. Yudi (610) was screened by a Spanish-language robot. Camellia's own inbound leasing traffic is served in Spanish (unit 201's prospect thread, 06-26), so the capability exists on the leasing side and is absent on the renewal side. Numbers: §3.

10. Fix the escalation tool, and never make the resident do the escalating. renewal_escalate failed twice in 52 cases (units 114, 210). On unit 114 the recovery text told the resident to phone the office herself. A failed escalation should retry and, failing that, write a PM task — never hand the work to the tenant. Numbers: §4 D5.

11. Act on undeliverable contact details instead of recording them. Units 505 and 524 have Twilio 30005: unreachable handset on the MMS, and 524's voicemail box was also unconfigured. The stored detail string literally says "verify the tenant's phone in the PMS" and no one was asked to. These tenants are unreachable on every channel and the team does not know. Numbers: §4 D9.

12. Two leases never entered the funnel. Units 301 and 122 have no saga, no offer, no outreach. Worth a scanner-coverage check before the next cohort. Numbers: §4 D8.

---

Appendix — raw artefacts in the scratchpad

Source: scratchpad/report-harness.md

Prior art: a local renewal replay lab (Camellia, 12 months, AppFolio mocked)

Read-only research, 2026-09-23. Repo main checkout /Users/federicochapa/.claude/propflowai at e05e8826ad. Facts carry paths. Lines marked [inference] are mine, not the repo's.

---

0. Headline

The lab Fede is describing mostly already exists, in three pieces that have never been joined:

1. scripts/renewal-harness/replay/ — a hermetic, in-process 30-simulated-day walk of the real daily

renewal scan over a seeded book. Real code, fake DynamoDB, fake Temporal, fake Twilio. Runs on every renewal PR. Synthetic data only.

1. testing-harness/ (top level) — a local Temporal dev server rig with a

scenarios/production-replay.ts that reads real Camellia sagas + their event logs out of prod DDB and drives them through the real renewalWorkflow, comparing the workflow's outcome to the saga's actual final state. Real data, real Temporal, but a PoC frozen at 14 sagas and stub activities.

1. src/__tests__/renewal-workflow-replay-corpus.test.ts + scripts/canary/ — real exported prod

Temporal histories replayed against current workflow code for determinism.

The work is joining #1's hermetic fakes to #2's real-data reader and widening the window from 14 sagas to 12 months, not building a rig. Per the harness skill §0/§5, this extends scripts/renewal-harness/ and testing-harness/; it does not justify a new *-harness directory.

---

1. Inventory of existing renewal harnesses / replays / evals

Related but not renewal: evals/replay-harness/ (the atlas's RECOMMENDED conversation engine, enters at the real production entrypoint, isolation verified live against AWS STS), scripts/replay-harness/, quality-replay/.

---

2. What a "replay 12 months of real Camellia renewals in a local lab" needs

Fede's revised target: local lab, no CI, no PR review, leases ending 2025-09 → 2026-12, AppFolio mocked. I keep the 90-day framing where it changes the answer.

(a) Data capture

[inference] 12 months of Camellia is roughly 120 units (e2e/fixtures/appfolio-camellia-scrubbed.csv has 121 rows) → order-of-magnitude 100–150 renewal cycles. The testing-harness PoC covered 14. Volume is not the problem; the 2025-09→2026-05 slice predates several of today's saga fields and the 2026-05-20 cutover, so early histories will not replay at all (see §4).

(b) Sandbox

(c) Time control

[inference] Recommendation for a 12-month lab: use all three in layers. The scan-level walk (what fires, when, to whom, how often) on the simulated-day loop with no Temporal, scaled from 30 days to ~480; the per-renewal workflow behaviour (14-day countersign, reminder cadence, quiet hours) on TestWorkflowEnvironment time-skipping, because a 12-month wall-clock run is impossible otherwise; and start-dev only for the handful of cases you want to watch in the Temporal Web UI at :8233. Time-skipping is the only one of the three that makes a year of timers cheap.

(d) Tenant simulator

MISSING as a renewal-specific piece. The nearest pieces: scripts/camellia-replay-scenarios.json (verbatim PII-stripped real Camellia resident texts, scenario-shaped, leasing not renewals), scripts/coworker-harness/, scripts/journey-harness/, evals/replay-harness/. The testing-harness replayer's translateEvent() is the closest thing to a renewal tenant simulator — it already turns a real event log into ordered signals — but it replays what the saga recorded, not the resident's raw words, so it cannot answer "would Clara classify this reply the same way today?".

[inference] Two distinct experiments, don't conflate them: (1) decision replay — feed the recorded intents back and check the state machine agrees (cheap, deterministic, no LLM, no cost); (2) comprehension replay — feed the resident's raw text back through the real classifier and check the derived intent matches what was recorded (needs the subscription eval runner, scripts/lib/subscription-eval-runner.ts, never metered keys — harness skill §6).

(e) Judge / scorecard — what "broke" means

REUSE the shape, not a new grader. Existing verdict vocabularies: production-replay.ts's

PASS/MISMATCH table with sagaStateToOutcomeCategory() mapping `EXECUTED|NTV_RECEIVED|PREPARE_FAILED|

HUMAN_REVIEW_PENDING|OPENED|OFFER_PREPARED|OUTREACH_ACTIVE|INTENT_TO_RENEW|INTENT_TO_VACATE → outcome categories; the replay suite's named invariants; scripts/option-d-proof/{checks,report}.ts's four acceptance families (invariants / equivalence / status-table / stability) with a Markdown + JSON twin report; e2e-permutation-matrix.ts's per-cell readiness.md. [inference] Option D's four families map cleanly onto renewals: invariants (one saga per tenancy per cycle, ≤1 page per lease+reason, every start inside the property's own window), equivalence (replayed outcome == recorded outcome), status table (every AppFolio renewal_summary status maps through the declared enum, src/lib/integrations/appfolio/status-enum.ts), stability (re-run is byte-identical). Borrow option-d-proof/report.ts` rather than writing a fifth reporter.

(f) Mutation control

Mostly MISSING for renewals. 300+ controls in scripts/mutation-controls/; the only renewal one is renewal-replay-path-filter.control.ts, which proves the path filter reddens — nothing proves the replay's invariants redden. Precedents to copy: option-d-ddb-sandbox-guard.control.ts (plants propflow-prod, requires a throw), portfolio-harness-falsifiable.control.ts, hitl-harness-coverage.control.ts. Enforcement is scripts/check-mutation-control.ts at pre-push. Note: Fede's lab is local, no CI, no PR — so pre-push enforcement won't fire, but the skill's rule that a check with no control doesn't count still applies, and the 2026-09-19 lesson ("two 'engine defects' were grader errors that controls exposed") is exactly the failure mode a 12-month replay is prone to.

---

3. Proposed PR chain

Each ≤300 lines, one concern, mergeable dark on its own. Atlas rule: everything extends scripts/renewal-harness/ or testing-harness/; **no new top-level *-harness dir is justified. Fede said local lab, no CI/PR review — but these still land as commits so the lab is reproducible. [inference] the effort numbers are mine.**

[inference] Critical path to a first useful answer is 1 → 2 → 4 → 8 (~3 days). 5, 6, 7 deepen it; 9 keeps it honest; 10 is a separate question.

---

4. Risks

PII in fixtures. The atlas found 4 real-PII fixtures with zero scrubbing live on 2026-08-26 (scripts/after-call-harness, evals/gauntlet, data/eval, plus a scoped gap in Cerberus's own scanner). A 12-month Camellia pull is the highest-PII corpus anyone in this repo has attempted: real names, phones, emails, exact rents, exact balances, exact late-payment dates. Mitigations that already exist: renewal-eligibility-replay.ts's own header rule (never commit a real charge_detail/rent_roll pull), assertOutputDirOutsideRepo, promise-harness/scrub.ts full-replace, the no-real-names.drift.test.ts + manifest-count.drift.test.ts tripwires, and funnel-context-no-real-names.control.ts as a control precedent. [inference] Default the capture output to a path outside the repo and make committing any fixture a separate, explicit PR — the exposure here is not "a name leaks", it is a year of one customer's residents' financial history in a git history that cannot be rewritten.

AppFolio write safety. Good news: the fences are real and structural, not conventions. SandboxAppfolioPMSWriter cannot reach AppFolio (import fence + drift test + a test asserting zero l4-core calls across every op), writer-registry.ts fails closed for a test property, and set-property-pms-sandbox-mode.ts refuses any property without isTest === true. The live risk is the one the repo already paid: Willows was seeded pointing at JP's REAL AppFolio database and willows-live-run.ts dispatched a real "prepare renewal offer" into it for a fake tenant (Fede, 2026-09-03 — the reason set-property-pms-sandbox-mode.ts exists). [inference] For a mocked-AppFolio lab, don't rely on the writer at all: keep setup-env.ts's posture of deleting the credentials from the environment, so a leak is a loud failure rather than a sandboxed one. Also wire HARNESS_SUPPRESS_OUTBOUND=1 (skill §7 — quality-replay/ has a real near-miss where one outbound call slipped past interception and only that switch caught it).

Temporal determinism replaying old histories against new code. This is the sharpest technical risk and the repo has already been bitten twice. (i) 2026-05-27: PR #1214's unguarded recordWorkflowPhase froze three migrated Camellia renewals for 13 days with no alert — the reason the replay-corpus gate exists. (ii) Right now, scripts/canary/replay-verifier.ts is chronically red and marked continue-on-error on three open Camellia *-migrated workflows carrying letter_mms_in_workflow_v1 non-determinism. (iii) Fixtures get retired, not fixed, when their cohort drains: fixtures/temporal-histories/retired/ holds wedged-migrated-precutover-{a,b}.json (ADR-0108 D5 dropped their replay compatibility; the pre-2026-05-20 cutover cohort passed the 60-day run timeout) and postcutover-recovered-declined.json (2026-06-09, predates defer_outreach_to_send_window_v1 / renewal_transient_prepare_resilience_v1, retired 2026-09-05 when both patched() branches became unconditional). [inference] Concretely: Camellia renewals from 2025-09 through roughly 2026-05 will NOT replay against today's workflow code, by deliberate design decisions already taken. A 12-month lab must therefore classify each renewal as REPLAYABLE / NOT-REPLAYABLE-BY-DESIGN / DIVERGED, and treat a NOT-REPLAYABLE count as information rather than failure — otherwise the first run reports a catastrophe that is actually ADR-0108 D5 working as intended. The scan-level walk (§2c option 3) has no such problem: it doesn't replay histories, it re-runs the scan, so it covers the full 12 months.

Cost. The hermetic rig is free: no AWS, no Temporal, no LLM, and the existing 30-day CI run is 2m03s–2m15s across the last 8 runs. [inference] a 480-day walk at the same per-day cost is ~35 minutes single-fork — acceptable locally, and the reason day-batching is in PR 5. Real costs appear only if the tenant comprehension arm (PR 10) is built, and that must run on scripts/lib/subscription-eval-runner.ts — the metered-spend-guard blocks metered-key paths by design (skill §6). The prod DDB capture is reads only. Local start-dev is free. TestWorkflowEnvironment is free.

One more, unasked: testing-harness/ is the piece closest to what Fede wants and it is half-orphaned — its README still says the workflow file "moves to ../src/ in Phase 4", a migration note the atlas flagged on 2026-08-26 as never resolved, and its planned .github/workflows/temporal-scenarios.yml never landed. Its activities are stubs. [inference] Before building on it, check whether testing-harness/src/workflows/renewal-workflow.ts still matches src/lib/temporal/workflows/renewal-workflow.ts — production-replay.ts imports the real one from ../../src/lib/temporal/workflows/, so the duplicate under testing-harness/src/ may be dead code. If it is, PR 0 is deleting it.

---

5. Spare Twilio numbers (list only — nothing bought, nothing reconfigured)

From config/phone-registry.json. [inference] the "spare for lab" column is my read, not a field in the file.

[inference] For a mocked-AppFolio local lab you need no phone number at all — doubles.ts stands in for the Twilio HTTP call and records every send. Numbers only matter if the lab graduates to live comms, and that is a separate Fede go under the external-writes gate.

Source: scratchpad/report-customer-context.md

Renewals for a centralized team — Western Slope, Situs, and what our org model requires

Read-only research, 2026-09-23. Sources: #transcripts raw per-speaker threads (channel C0BE1NFTA0K), the Clara onboarding playbook + WS knowledge gold set, Gera's org-architecture page, the WS go-live tracker, the repo's AppFolio skill + scraped AppFolio help KB.

---

1. Western Slope's renewal process today, as they described it

Who they are. Western Slope Property Management, Grand Junction CO — a true third-party manager, ~250 doors / 70 properties in our org record, scattered single-family and small multifamily. Situs Group owns 25% of them (Eileen O'Malley, 2026-09-01: Jay at Western Slope "is the model third-party operator — accounting and leasing dialed"). People: Jason Fish and Jay Taylor (org_admin), leasing agents Kat and Bev, Cheryl. Fede's word on the call, 2026-09-04: "And it's centralized, well…" — WS is the customer that forced the centralized model.

They do renewals out of AppFolio's LEASING flow, not its RENEWALS flow. This is the single most load-bearing fact.

JasonFish (2026-09-09 kickoff): "we've been using the AppFolio leasing function for our leases for a while… we also use the leasing function for our renewals, as opposed to the renewals function, right? So we're utilizing a handful of amendments in the leasing function, and in doing so, we've, like, bypassed the ability to leverage some of the… Optionality, like, AppFolio and renewals function allows me to send a letter that's like, hey, if you want a 6-month renewal, it's this, a 9-month, it's this, a 12-month, it's this, and forces us to, like, work that whole thing out with the tenant."

JasonFish (same call): "It also means some of the reporting functionality that relies on pulling a renewal report as opposed to a leasing report isn't working the way we need."

JasonFish: "with AppFolio, we weren't using the renewal functions to the best it could be, and, like, I'm assuming that you guys might require some setup from us… if you're like, hey, in order for it to do renewals, you're gonna have to get set up on this, great, we'll get set up on that, all for it."

JasonFish: "The ability to start over from scratch is, like, my dream… a lot of the stuff that the AppFolio integration team put in there is some of the stuff that we're trying to clean up now, years later."

So: renewals today = a lease + hand-picked amendments/addenda sent through Send Lease or Addendum, no renewal-offer records, no multi-term option letter, and renewal reporting that doesn't work. Fede's reply, same call: "I think it helps if it's, like, if we're consistent and you guys have, like, one process for your whole portfolio, and, like, maybe one template, like, one addendum… because sometimes you might have, like, 10 different templates, and it's like, oh, which one is it?"

Lease terms and notice (from the client-confirmed knowledge gold set, approved by Fede 2026-09-15):

• Standard term 12 months; Ember Estates runs a promotion of 14–18 month terms (client correction: "at ember estates for our promotional offering we are doing longer term leases of 14 18 months").
• Month-to-month after the lease ends adds $150/month on top of rent (knowledge.lease-length, verdict Wrong only on the Ember detail).
• MTM notice = 30 days' written notice, client-confirmed (knowledge.mtm-notice-period). Our draft had flagged that their lease template library holds five versions that disagree on this; the go-live tracker records the conflict as "month-to-month notice 21 vs 30 days across five lease templates." Jason's answer settled it at 30 days, matching three of the five templates. Their template library is inconsistent — that is a real renewals blocker.
• Notice-to-vacate already reaches Clara: JasonFish (2026-09-09) "I saw we got a notice to vacate, uh, last night, and Clara was CC'd on it, which is cool."
• Colorado deposit return within 60 days of move-out (confirmed Correct in the gold set).
• No rent-increase policy was stated by WS in any transcript. They never gave a standard increase %, a rent floor, or a term-steering rule. Do not assume one.

Notably absent from the knowledge base by decision. The KB pass-2 row on the tracker: 11 items were cut, including "renewals" and "tenant money rules" — renewal policy is deliberately not client knowledge today.

Why renewals come BEFORE maintenance — the MCC contract. Their after-hours maintenance answering service is MCC, reached today by pressing 9 on their RingCentral tree, which simply forwards to MCC.

JasonFish (2026-09-09): "the fact that we can leave the MCC thing as it is… if that's a good way for us to move forward here without having to rip the maintenance band-aid today, then… That makes that very easy for me. We are going to have to pay for MCC through April 30th of 2027, no matter what. Um, so, though I'd like to get rid of it long before then, I think there's a chance I might have to pay for it until then, and that's fine. But it means that we've got time to work on other stuff. And so if we're going to focus leasing and then renewals and then maintenance, I think that's fine."

Fede (2026-09-09): "seems like you guys prefer to do renewals before maintenance?"

Restated internally on 2026-09-23 — Fede to Sean: "they wanted renewals first, and then… Maintenance last, remember in the last call, because of a contract they have… the Maintenance phone line, like, they already have that contract till next year… so it would be more valuable to the renewals." Sean's written proposal still says leasing → maintenance → renewals; the client's stated order wins.

Jason's own framing of the prize: "renewals is gonna be a big piece" (2026-09-09). On 2026-09-16 he set the sequence himself: "Okay, then we take over the rest of the lease. We'll start with that, and then we can move on to leases and renewals."

AppFolio tier: they moved to Plus during onboarding — JasonFish, 2026-09-09: "today's Wednesday, right? We took a demo with… or we had a conversation with AppFolio about Plus, signed a DocuSign this morning, got the API key a little bit ago. I mean, we're moving."

2. What they asked Clara to do

Nothing about renewals was demoed to them working — Jason, 2026-09-09: "I didn't really check the renewal… thing, you know, like, hey, I'd like to renew this property. I didn't test that either… I know renewal stuff was a little bit later in your pipeline of, like, onboarding." Fede: "that's not hooked up to the prototype right now."

What was promised to them is Sean's pitch on the 2026-09-04 demo call:

Sean: "we have a renewal workflow where we proactively automate renewals, like… we like to reach out, like, 90 days before the lease is expiring, and we give them a renewal offer." Sean: "you can see these are the renewals we have upcoming for the month of September." Sean: "we do the proactive outreach, right? And then if someone says they're not renewing…" JasonFish, reading back the integration: "there's outputs and inputs that your model is giving into AppFolio to manage guest cards, send renewals out in the renewal module…"

So Jason's mental model is explicitly that Clara writes into AppFolio's renewal module — the module they don't currently use. Their ask, in their words: tell us the AppFolio setup best practices and we'll adopt them.

Timing they expect: fast. Jason: "we want to break the record for onboarding"; "we're small and nimble… I'd love to figure out how we could speedrun this." They are a design partner ("we're used to working as a design partner") and expect to be told what to change on their side.

Where renewals actually stand for WS today (go-live tracker, read 2026-09-23):

• Org org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38 "Western Slope Property Management", type centralized, purpose customer. Jay Taylor's org_admin invite accepted 2026-09-11.
• Stored modules read 2026-09-23: leasing ON; renewals, maintenance, collections, lease-billing OFF. (Fede's call 2026-09-10: "leasing.")
• Open tracker row: "Routing: module check before any specialist (renewals had none); WS = leasing only" — the renewals specialist had no check for whether the renewals module was even on before it engaged, so WS calls could be misrouted into it. PRs #11124, #11306; remaining ungated legs in issue #11307. This is a live correctness bug in the renewals path.
• Related open row: "Tenants reaching a leasing-only line: decision" — residents already reach Clara on the forwarded main line and are recognized org-wide; the maintenance capability is granted on identity.type==='tenant' with no read of Property.capabilityStage.maintenance (='off' for WS). Same class of gap will apply to renewal asks from residents.
• Internal target from the 2026-09-23 standup: renewals is next week's work, Fede owning renewals + leasing while Gera runs Citus onboarding.

3. Situs Group (and Hugo / MMG)

Situs Real Estate Corp, Denver — owner-operator + syndicator, ~550 units B/C class in Lakewood/Arvada/Denver, GPs Hugo and Noel; Eileen O'Malley was VP of Operations (leasing, maintenance, turnovers, renewals) and has since left — the 2026-09-01 whiteboard deep-dive was her last week, which is why her account is the record.

Renewals is Eileen's #1 ROI pick, and there is no process:

"The one that I think would get the hugest ROI… would be the renewals." She discovered there is no renewal process — it's Miriam nagging people by call/text/email. AppFolio's auto-email tells tenants to respond by the lease-end date, contradicting the lease's required 30-day notice. A renewal incentive tracker was discovered only six weeks before the session, explaining rents that "must be an error"; no checks and balances beyond one manually updated sheet. Non-renewal outcomes are not entered — the vacancy tracker hadn't been fed renewal outcomes for ~3 months and nobody knew. Her wish: predictive renewal pricing off the pro forma + market comps + unit condition, with multi-term option menus like Yardi — e.g. 1-month at a punitive rate, 12-month standard, and penalize lease-ends landing in Nov–Feb. She "deliberately paused building a new renewal process once PropFlow entered the picture — better that change 'comes from you' than from her." Fede's answer on the call: PropFlow already runs autonomous renewals at 90 days — set a building policy, the agent generates and sends offers, holds back exceptions (evictions, chronic late payers, via ledger access), nags every two weeks. Eileen: "I would love that."

Rent roll and vacancy data are "almost never correct" (move-ins unrecorded, leases uncountersigned, transfers papered later) — Eileen: "we're gonna live or die by the sword" on data hygiene.

Sequencing for Situs/MMG is NOT renewals-first. 2026-09-18 call with Hugo and Eileen: Clara replaces MCC after-hours, and "Modules turn on incrementally: leasing first, then maintenance, then renewals. The phone-line cutover is the LAST step." Sean on that call: "we'll start with the leasing, and then when you guys are ready, we can turn on maintenance, and then when it's ready, we can turn on renewal." Gera's arch page also records decision D4 "Maintenance line first for Situs" as Fede's, no gate. Inference: the two documents conflict on whether Situs starts with the maintenance line or leasing after-hours; worth confirming with Fede before planning renewals work against Situs.

Hugo's own demo (2026-08-25) shows what he expects from renewal automation — the guardrail, in his words:

"if they try to negotiate, the AI won't do that, it'll say, we will talk to the manager, and then you'll get an email saying, hey, the tenant will renew if, you know, they offer X, and then you can make the judgment call." "if you go to the upcoming renewals, so this is showing what we have upcoming… and then you can filter by, like, oh, if I want to see, like, what are my August… September…"

Hugo/MMG runs one main number with no per-property trees, so a renewals pilot cannot be scoped to a subset of properties — the funnel is by intent only. Same constraint as WS.

4. What our org model requires for renewals (Gera's portfolio architecture, docs.propflowai.co/a/portfolio-architecture-how)

The model, in its own words: "The org is the customer, the contract and the wall." A building is a room inside it. Figure 16 draws Western Slope explicitly: "WESTERN SLOPE — ONE ORG, SIXTEEN HOMES, EVERYTHING ON THE ORG … The Western Slope leasing line: one number, all homes. One calendar: two leasing people. Policies · fees: set once, up here." (Sixteen homes was the Sep-7 snapshot; the production org now carries 70 properties.)

What that requires of a renewals build:

1. Renewal policy is an org-level attachment, with a property override. Capabilities are <node>/ATTACH#<kind>#<slot>#<startedAt> rows on ORG# or PROP#, read by one resolver that walks building → org and answers nearest-wins, with a lock the org can set. Rule as written: "Attach to the org what the whole customer shares; attach to the building what only that building uses; a building without its own answer inherits the org's" and "nearest-wins: the building's attachment beats the org's." Decision D11: "None — nearest-wins with the company's lock available is 'portfolio wins' when the company chooses it and 'the building knows better' when it does not." Decision D2: every existing key ships as a nearest-wins PARAMETER with today's constant as absentMeans; the registry classes keys POLICY / PARAMETER / IDENTITY. So: rent-increase rules, term menus, notice windows, the 90-day trigger, the nag cadence and the exception list are org-level parameter keys with a property override, never per-building-only settings. Fede's standing rulings agree (tour length is company-level; no per-building coverage; property overrides org on knowledge conflicts unless the company value is locked).
2. Renewal outreach goes out on the org's channels. ADDR#<channel>#<address>/HEAD is the platform-unique claim that a number or mailbox belongs to one node; for WS the line, the mailbox and the calendar all hang on the org. Renewal email therefore sends from the org mailbox (leasing@westernslopepm.com today, with the standing rule: org mailbox is the default, a property may override, nearest wins) and renewal texts/calls from the single org leasing line. There is no per-property renewal sender at a centralized customer, and creating 70 of them is explicitly what the model rejects — Sean, 2026-09-17: "if it's a centralized model, like Western or Citus, you only need one inbox… they have 70 properties, you're not gonna create 70."
3. Escalations follow escalation.owner, classed DYNAMIC (nearest-wins). Decision D2 reverses the Sep-1 identity classing specifically so escalation ownership inherits org → property. For renewals that means a negotiation hand-off (Hugo's "we will talk to the manager") resolves to the org's named owner unless a property names its own. Fede's standing rule routes escalations to Property.propertyEmail — at a centralized customer that value must resolve through the org attachment, not be typed per home.
4. Roles. "Owner" is retired as a bare word in favour of three: org_admin (Jay Taylor at WS; the only role that may hand out manage_roles; at least one live admin always, the last of whom cannot self-remove), property owner (grant widened Sep 8 to reports · financials · occupancy · work_orders · documents for the buildings they own, with conversations grantable and OFF by default for tenant privacy), and PMS credential holder. Implication for renewals: a property owner can see renewal/occupancy/financial outcomes for their own homes but not the resident conversations unless granted. A renewals dashboard shown to owners must be built on the report grant, not on conversations.
5. Membership is a PersonRole scoped to an org, a group or a building. Leasing agents Kat and Bev hold org-scoped roles, so "Leasing agents see just leasing and renewals" (Fede, 2026-09-17) — renewals is in the leasing role's visibility, org-wide, not per home.
6. The known gaps the bench already measures. The isolation gauntlet records T6 CANNOT-EXPRESS — "The one resolver returns a building id; the customer is only ever derived through a building" — and T14 FAILS: a company-level line "silently becomes one home's line, chosen by roster order." T9 CANNOT-EXPRESS: calendars are still building-attached. So today an org-level renewal action still has to borrow a building to resolve, and org-level line/calendar attachment is not shipped. Inference: a renewals build that assumes an org-level sender or an org-level policy row exists today would be building against rows that are still proposed; the tracker's own number was 113 of 179 ladder rows merged as of 2026-09-13.
7. The umbrella tripwire (D9). WS's scattered homes sat under a single placeholder building, accepted "for Western Slope's first weeks with the tripwire, re-key once after 5a." Any renewal keyed off that placeholder inherits the re-key.

5. AppFolio renewal features, and the tier caveats

From the scraped AppFolio help KB (~/.claude/pms-knowledge-base/appfolio/help-articles/), article "AppFolio's Renewals Flow" and "FAQs: Lease Renewals":

• Two different flows, and they are not interchangeable. Send Renewal Offer prepares a lease renewal offer (from the tenant page or the Renewals tab) and, if you allow tenants to give notice in the portal, emails you when the tenant declines. Send Lease or Addendum sends additional documents to sign. WS uses the second for renewals — that is why their renewal reports are empty.
• Lease settings drive it. Default lease + renewal templates are applied at the property page; "Renew by Default" (auto-roll into a new term at expiry) is configured in Lease Settings — and it "does NOT apply to renewals using PDF form templates, it only applies to renewals using APM lease templates." WS's five-version template library is exactly the thing that breaks this.
• Two entry points: the Lease Expiration Detail by Month report (filter out those who gave notice / are moving out / you won't renew) and the Renewal Index page (Leasing → Renewals), which tracks sent offers, what was offered, who signed, resend and reminder links, and countersigning.
• Renewal notice letter — a cover letter, mailable or emailable before or with the offers; AppFolio auto-populates term lengths and rent amounts; resendable as many times as you like with different templates until acceptance.
• Deadline to respond — shows in the resident portal and in reminder emails; AppFolio itself sends an automated reminder 7 days before the deadline; tracked in the Renewal Summary report. (Coordinate with Clara's cadence or residents get two nags.)
• Multiple term offers — up to five offers plus one month-to-month option, mixing term lengths and rents; the MTM offer can carry an additional fee; rent can be raised by a set % or $, tracked in the Renewal Summary report for rent-control compliance. This is the exact capability Jason said they bypassed and Eileen asked for.
• Autoroll + proration — monthly charges editable inside the renewal flow; the prorated charge is created when the renewal is countersigned; autoroll mid-month credits back the overcharge.
• API surface (repo skill /Users/federicochapa/.claude/propflowai/.claude/skills/appfolio/SKILL.md): lease fields LeaseFrom, LeaseTo, LastLeaseRenewal, LastRentIncrease, NextRentIncrease, NextRentAdjustment; endpoints include lease_expirations, renewals, lease_renewals, tenant_renewal(s), notices; tenant_tickler carries lifecycle events incl. "renewal signed"; property_directory carries per-property renewal fees.

Tier caveats (article "AppFolio Property Manager Plus Features"):

• The AppFolio Reporting API is Plus-only. So is AppFolio Report Connection, Custom Fields, Custom User Roles, Audit Center, Affordable Housing (LIHTC / PBS8, income certifications, TRACS), Bulk Pricing, Bulk Move Out, Realm-X Flows, Leasing Metrics Dashboard, Performance Insights.
• "Bulk Lease Renewals Workflow" — prepare and send lease renewals in bulk by property or property group — is Plus-only. That matters for a centralized team: bulk-by-property-group is the AppFolio-native shape of "one team renews 70 properties."
• WS is on Plus (signed 2026-09-09), which also explains their affordable-housing interest (Courtyard, Lincoln) and gives us the Reporting API. Inference, not confirmed: Situs/MMG's tier is not stated in any source I read — if they are not on Plus, neither the Reporting API nor bulk renewals is available to them, which would change the Situs renewals design.
• The base renewals flow itself (Send Renewal Offer, Renewal Index, notice letter, multi-term offers, autoroll) is not listed as Plus-exclusive — it is standard.

6. Western Slope leases ending in the next 90 days

No 90-day expiration pull found. What does exist, from the go-live tracker (read 2026-09-23):

• The 2026-09-13 real AppFolio import (PMS_IMPORT#org_c42d9150…/ACCOUNT#appfolio#westernslopepm#17a5) wrote tenant: 142, lease: 142 in its "People and leases" stage.
• 356 occupancy rows across 55 of WS's 70 properties (PERSON#/OCCUPANCY# via the phone-index GSI).

No file, report or tracker row I found breaks those 142 leases down by LeaseTo. Getting the number is a single read-only lease_expirations or rent_roll call against westernslopepm.appfolio.com with the Reporting API key (Plus, provisioned 2026-09-09) — not run here. Do not quote a 90-day figure until that pull exists.

A dedicated read-only filesystem sweep (completed 2026-09-23) confirms this: propflowai/data/leases.json holds test data only, propflowai/scripts/data/western-slope-proto-seed.json holds unit/listing data with no lease dates, and agents/007/org-cleanup-2026-09-08/ holds org profiles and unit refs with no lease records. The 142 imported leases live in the production DynamoDB table, never exported locally. The only Western Slope renewal-adjacent doc is the general propflowai/docs/runbooks/renewal-orchestration.md, which is not WS-specific.

---

The one-line answer to the question asked

"Renewals for a centralized team" at Western Slope means: one leasing team of two people, working one queue of ~142 leases across 70 scattered properties, off one phone line, one mailbox and one calendar that all hang on the org — with renewal policy set once at the company level and overridden only where a single home differs. It also means fixing their AppFolio setup first: they renew through the leasing flow with ad-hoc amendments, their five lease templates disagree on the month-to-month notice, and their renewal reports are empty. The client put renewals ahead of maintenance for one concrete reason — they are locked into the MCC maintenance answering contract through April 30, 2027, so there is no money to save by automating maintenance first.

Source: scratchpad/report-ws-lease-volume.md

Lease volume (read-only DDB query, 2026-09-23)

Query: aws dynamodb query --table-name propflow-prod --index-name entityType-createdAt-index GSI3PK=OCC#<orgId> (TenantOccupancy rows, canonical lease locator) WS org: org_c42d9150-b9ad-46f8-8f5f-b0fe56bacf38 ; Camellia: org_jpco / property 1773625953462

Western Slope: 364 occupancy rows (350 active, 7 pending, 7 former)

• lease-end by month: Oct-26 11, Nov-26 11, Dec-26 20, Jan-27 16, Feb-27 19, Mar-27 20
• empty leaseEnd: 26; status=mtm rows: 0
• ending within 90 days (through 2026-12-22): 43
• leaseEnd already before 2026-09-23 but mostly still status=active: 62 (data-quality flag: no MTM rollover recorded)

Camellia: 187 rows (126 active, 61 former)

• lease-end by month: Oct-26 7, Nov-26 13, Dec-26 8, Jan-27 7, Feb-27 10, Mar-27 8
• empty leaseEnd: 23; mtm: 0
• ending within 90 days: 26
• leaseEnd before today: 22

Source: scratchpad/report-ws-appfolio-setup.md

Western Slope vs Camellia — AppFolio renewals setup audit (read-only, 2026-09-23)

Method: read the existing deterministic capture at ~/appfolio-dumps/westernslopepm/ (taken 2026-09-07/08, before the 2026-09-09 Plus upgrade); no new browser session. Camellia facts from engineering records.

Side by side

MTM handling

AppFolio's Lease Expiration Detail buckets 89 of ~91 rows as month-to-month (09-08). PropFlow's 62 expired-active rows come from PropFlow's own table; not reconciled in this audit.

Risks

1. Two templates promise 21 days' MTM notice vs. the client's confirmed 30 — legal exposure if handed to a resident.
2. MTM-only template does not show the $150 fee where the other four do.
3. "Sample Lease Template" is live in the selectable list.
4. 89-of-91 MTM rate is unusually high — real or a stale field.
5. 27 of 43 renewal-eligible occupancies have no offer object, so the reminder path is dead for most.
6. Per-property owner approval not visible either way.

Checklist for Western Slope

Must-do before turn-on:

1. Fix both WSPM templates from 21 to 30 days' MTM notice.
2. Consolidate to one canonical renewal template instead of 5.
3. Confirm the $150 MTM fee appears in the MTM-only template.
4. Create renewal-offer objects for all eligible leases (only 9 of 43 today) so reminders, the Renewal Index and 90-day outreach have something to work from.
5. Give the Ember Estates 14–18 month promo a real template.

Nice-to-have:

1. Retire or label the Sample Lease Template.
2. Verify the 89 MTM units with Jason (real occupancy vs. data cleanup).
3. Use the existing property groups for bulk renewal sends once Plus bulk is confirmed on.
4. Ask directly about per-property owner-approval requirements.

What we change on our side

• No single-constant template pattern (Camellia's JPCO_TEMPLATES); Western Slope needs per-property template resolution.
• Keep the read-only write lock on westernslopepm as is.
• Notice logic reads the per-template value (21 vs. 30), never a company constant.
• Do not infer "not renewing" from an empty Renewal Index; 27 of 43 likely renewed through the leasing flow.

Sources: ~/appfolio-dumps/westernslopepm/reports/*.csv, renewals/index.json, settings_docs/templates/ (ids 1,2,3,5,15); appfolio-browser-agent/lib/{accountDefaults,readonlyLock,multiTenantConfig}.ts

Source: scratchpad/lab/README-lab-A.md

Lab A — replay Camellia's real renewals against today's renewal scan

Local lab. No CI, no PR. Built 2026-09-23 in the worktree /Users/federicochapa/.claude/propflowai-lab-renewal-replay-corpus, branch lab/renewal-replay-corpus (three commits, unpushed).

Nothing was written to production DynamoDB, AppFolio, Temporal Cloud or Slack. The capture is reads only; the replay runs with AWS, Temporal and Twilio credentials deleted from the environment, HARNESS_SUPPRESS_OUTBOUND=1, and a fake table name (propflow-replay-harness-does-not-exist). No LLM key of any kind is used — the lab has no LLM step.

---

1. Run it from a fresh shell

cd /Users/federicochapa/.claude/propflowai-lab-renewal-replay-corpus
export LAB=/private/tmp/claude-501/-Users-federicochapa-agents-004/268439c3-a006-4372-897c-3735a55d3990/scratchpad/lab

# 1) capture (READ-ONLY against prod DDB + the AppFolio HTTP API)
mkdir -p $LAB/corpus
npx tsx scripts/renewal-harness/replay/capture-camellia.ts --out $LAB/corpus
#   optional: --from 2025-09-01 --to 2026-12-31 --no-appfolio

# 2) scrub — the driver reads ONLY the twin this writes
npx tsx scripts/renewal-harness/replay/scrub-corpus.ts \
  --in $LAB/corpus --out $LAB/corpus/scrubbed

# 3) replay + scorecard
RENEWAL_CORPUS_DIR=$LAB/corpus/scrubbed RENEWAL_CORPUS_OUT=$LAB \
  npx vitest run --config scripts/renewal-harness/replay/corpus/vitest.config.ts
#   knobs: RENEWAL_CORPUS_EPOCH (default 2025-09-01T16:00:00.000Z — 09:00 America/Denver)
#          RENEWAL_CORPUS_DAYS  (default 487 = 2025-09-01 .. 2026-12-31 inclusive)
#          RENEWAL_CORPUS_STRIDE(default 1; scan every Nth simulated day)

# 4) the two mutation controls
npx tsx scripts/renewal-harness/replay/corpus/controls/window-regression.control.ts
npx tsx scripts/renewal-harness/replay/corpus/controls/prod-table-guard.control.ts

# 5) the synthetic CI path, unchanged, to prove nothing regressed
npm run test:harness:renewal-replay

Outputs: $LAB/scorecard.md and $LAB/scorecard.json. The corpus lives at $LAB/corpus (raw, never committed) and $LAB/corpus/scrubbed (the only thing the driver opens; loadCorpus refuses a directory whose manifest does not say scrubbed: true).

2. What was built

Everything extends scripts/renewal-harness/replay/. No new top-level harness dir.

3. Corpus counts (capture of 2026-09-23T23:26Z, contentHash 2f48e2b2e032aaab…)

• 165 renewal sagas in prod; 120 at Camellia (property 1773625953462)
• 513 activity-log events across those 120 sagas
• 149 tenant rows, 120 units, 103 leases, 133 persons, 187 occupancies
• 115 AppFolio renewal_summary rows for AppFolio property 7; 63 of 120 sagas join to at least one

The AppFolio join works without the browser robot. It runs over the HTTP API (AppfolioClient.listAll('renewal_summary')) with the Camellia API clientId/clientSecret already on file in prod DDB. One request, one page, 115 rows.

By saga state: NTV_RECEIVED 28, EXECUTED 23, MIGRATED_TO_WORKFLOW 20, CANCELLED 18, HOLDOVER 9, PREPARE_FAILED 8, TRANSFERRED 7, OFFER_PREPARED 5, HUMAN_REVIEW_PENDING 1, INTENT_TO_VACATE 1.

By month the saga opened: 2026-04 8 · 2026-05 21 · 2026-06 10 · 2026-07 37 · 2026-08 15 · 2026-09 29.

By month of the tenancy's (current) lease end: 2026-04 1 · 05 2 · 06 3 · 07 4 · 08 4 · 09 14 · 10 6 · 11 8 · 12 8 · 2027-01 1 · 02 2 · 03 3 · 04 5 · 05 3 · 06 7 · 07 19 · 08 9 · 09 4 · 10 2 · 12 3.

Finding 0, and it reshapes the brief: there are no 12 months of Camellia renewals to replay. The oldest renewal saga in production opened 2026-04-30. The saga store covers just under five months, not a year. The 2025-09-01 → 2026-12-31 walk is still the right window (it is the window leases END in), but nothing before 2026-04-30 has a production counterpart to compare against.

4. Scorecard (487 simulated days, stride 1, 10.9 s)

171 renewals scored.

Invariants:

NOT RUN is not a pass. i2 and i4 are vacuous for a structural reason, not an oversight: this lab replays the daily SCAN, and the scan's job ends at opening a cycle. Outreach, PM pages and quiet-hours deferral all happen inside the renewal Temporal workflow, which is stood in for by a workflow starter that only reproduces workflow-id idempotency. The invariants are wired and their controls prove the machinery reddens; they have nothing to score until the workflow arm exists.

AppFolio tape: 353 hits / 126 misses (a miss = the walk asked about a unit with no renewal_summary row, recorded rather than silently answered clean).

5. Findings

F1 — the signer-email gate now catches renewals that used to fail at AppFolio prepare. (product finding, not a bug in current code.) The only two DIVERGED rows are both PREPARE_FAILED sagas that today's scan refuses to open because the Person spine holds no email for the signer:

• saga_33866181-674f-44b0-8855-9c645c51cc5b, unit 204, lease end 2026-09-30, opened 2026-07-13, prod error PMS prepare timeout (10 minutes)
• saga_67326c3c-0c63-4337-a1dc-20511b98f447, unit 409, lease end 2026-11-30, opened 2026-09-03, prod error PMS prepare failed: Activity task failed

Widening past what the walk could reach: 4 of the 8 PREPARE_FAILED sagas at Camellia belong to residents with no email claim on the spine (only phone + pms_external_id). The other four have an email and failed for other reasons (AppFolio field_value_sets returned 0 populated values, PMS_REJECTED httpStatus=422, two timeouts). Reproduction: scripts/renewal-harness/replay/corpus/ per §1, then jq '.rows[] | select(.verdict=="DIVERGED")' $LAB/scorecard.json.

F2 — the saga store does not go back a year (§3, Finding 0). Any claim about "12 months of renewals" at Camellia is, today, a claim about five.

F3 — saga.pmsRef still does not join to AppFolio, confirmed again on this pull. The only working cross-reference is unit name, which is why 57 of 120 sagas have no AppFolio row: the unit has no renewal_summary row at all, usually because the cycle predates the report's retention or the tenancy has since turned over.

F4 — 20 sagas sit in MIGRATED_TO_WORKFLOW. Their outcome is in the Temporal history, not the saga row, so a saga-level replay can say nothing about them. They are the largest single block of real renewals this lab cannot grade.

No product bug was found that needs fixing. The two divergences are the current code being stricter than the code that ran, in the direction that prevents the failure production actually hit. Nothing was changed in production renewal code.

6. Why 165 rows are NOT-REPLAYABLE-BY-DESIGN

Calling any of these a divergence would have manufactured a finding. Breakdown:

The first, second, sixth and seventh rows are all the same root cause and it is the lab's biggest limitation: the corpus is a point-in-time snapshot of the book, not a time series. 100 of 165 unreplayable renewals are unreplayable because the book we seed is today's book, not the book as it stood on the day the saga opened.

7. Mutation controls (both green)

• controls/window-regression.control.ts — builds two hand-written replay logs over the same book: one where every start is 30–89 days out, one where a single start is 120 days out against Camellia's 90-day property (the 2026-09-03 incident's exact shape). Requires i3 to PASS on the first and FAIL with exactly one offender on the second. PASSED.
• controls/prod-table-guard.control.ts — requires the sandbox env to be accepted and four plants to be refused: DYNAMODB_TABLE_NAME=propflow-prod, a leftover AWS_ACCESS_KEY_ID, a leftover TEMPORAL_API_KEY, and HARNESS_SUPPRESS_OUTBOUND unset. PASSED, all four refused.

8. Runtime

Day-batching (RENEWAL_CORPUS_STRIDE) is implemented but was not needed. The pre-work estimate of ~35 minutes for a 480-day walk was wrong by two orders of magnitude — one property with 108 live tenancies is far cheaper per day than the synthetic three-property book.

9. What is left unbuilt

1. A time-rewound book. The single highest-value next piece: reconstruct each tenancy's state as of the day its saga opened (AppFolio's PreviousLeaseStart / PreviousLeaseEnd carry the expiring lease, and the per-saga event log carries the transitions). That would move most of the 100 snapshot-cohort rows into a real verdict.
2. The workflow arm. i2 and i4 stay NOT RUN until one captured renewal is driven through the real renewalWorkflow on TestWorkflowEnvironment time-skipping, so the 14-day countersign, the reminder cadence and quiet-hours deferral are really exercised. That was going to be PR 6 of the prior-art plan; it is not here.
3. Balances. No AppFolio charge_detail was captured, so every tenancy is seeded with a clean balance and the lab cannot reproduce a hold that production applied because a resident owed rent. fetchRenewalFeatures says so in its provenance rather than pretending.
4. Prod Temporal histories. scripts/temporal/export-recent-histories.ts is still bounded at --limit=10 --closed-within-days=30; the 12-month pull (prior-art PR 3) was not built, so the 20 MIGRATED_TO_WORKFLOW sagas remain ungraded.
5. The comprehension arm. Replaying residents' raw replies through the real classifier (prior-art PR 10) — not attempted; it needs the subscription eval runner.
6. A third control over the classifier itself (plant a fake DIVERGED and require the totals to move). The two controls cover the window invariant and the sandbox guard, not the verdict logic.
7. Atlas registration. The harness skill's step 4 (a row on the Harness Atlas page) is not done — this is a local lab, and registering it is a publish, which is a separate call.