Propflow Propflow Docs
Acceptedmarkdown source

0143 — Turnover and new-lease automation follow the gatekeeper; Supervised holds their property-software writes

Context

Turnover automation and the new-lease pipeline were each turned on by their own switches, and the company's gatekeeper module status was not asked:

So the one switch staff and customers look at (ADR-0139) did not say whether these ran. Gera, 2026-10-15: stop relying on the old switches; the gatekeeper status governs.

Decision

1. One gate per feature, the module status. Turnover follows the building's Maintenance status; the new-lease pipeline follows the building's Leasing (leasing.prospects) status, the module the staff registry already files every new-lease switch under. The status is the existing per-building answer (resolveModuleStateForOrg: the building's own row, else its company's, under the company plan ceiling). For turnover the one reader is src/lib/temporal/turnover-gate.ts (turnoverModeAt).

2. What each status means for these features.

Status Behavior
Off None of it runs.
Supervised It runs. Every outbound message to a resident, prospect or vendor is held by the existing Supervised doors (ADR-0139 §9). Every write it would make to the property software (tenant charges, work-order create/sync, the move-out draft, unit availability, the lease send) is held for a person to approve through the held-write flow (HeldPmsWrite, shown on /review beside the held messages, with exactly what would be written). A write that flow cannot carry yet is skipped, never made, and named in the PR that gates it. Notes to the customer's own staff go, as everywhere (hot rule 10).
Live It runs and acts.

A held write is a person's decision. If the building later moves to Live, the Live path does not write the same change itself, and it does not close the hold: a waiting hold still waits for a person, an approved one is written once, and a rejected one stays unwritten.

An unreadable status is unresolved: a Temporal activity throws so it retries; a hook that is not retried reads it as off.

3. This extends Supervised for these features only. The rule elsewhere stays "Supervised holds outbound messages only; property-software writes go". Turnover and new-lease writes are the exception because they change a tenant's ledger, a work order of record or a lease, which a manager must see before it happens (Gera: "on supervised, we should see like pms writes to change charges").

4. The lease send. Approving a new-lease item always drafts the lease. It is SENT for signature only when Leasing is Live AND the company setting "Send leases for signature" is on (off by default; Fede turns it on per company, like turnover.auto_release). Otherwise the send is held in the plain sense: not sent, and staff send it from the property software. There is no second approval item.

5. The old switches are retired. The per-building flags, the platform arm fields, their staff rows and their registry entries are removed once both features read the module status. Their stored values are left in place (orphaned rows are fine); nothing reads them.

Consequences

Alternatives considered