Settings cleanup strategy

About 160 things a person or a script can set in PropFlow today. Under half are reachable in the product, a third are on/off switches sessions left behind, and turning one customer live means flipping seventeen of them per building. This is the plan to cut, level and surface the whole set — in Gera's portfolio model, with today's behavior as every default.

Proposed — pending review (2026-09-10) · Fede's rulings of Sep 9 are binding · companion to the new-customer onboarding page and to Gera's portfolio architecture

Update, 2026-09-17: Property.emailShadowMode, Property.smsShadowMode and scripts/set-property-sms-shadow-mode.ts named below no longer exist — deleted by PR #9162, not merged into a new key as this proposal suggested. Staff notices now always reach the real recipient and tour texts are always sent, with no per-property shadow gate. Read the shadow-mode mentions on this page as history, not the current field set.

1. The problem, in plain English

PropFlow has grown a settings layer nobody designed. A code sweep and a signed-in walk of the live product on Sep 9 found 159 separate things a person or a script can set. Only 56 of them are editable by a customer. Seventy-three have no screen anywhere — they are changed by editing the database or running a script. Twenty-two live on an internal staff page. Thirteen only change when we deploy.

Four separate problems are tangled together in that number:

1. Switches nobody removed. Fifty-five of the 159 rows are on/off switches, modes or stages, and 44 of them sit on the single building record. Most were added to ship one change safely, were turned on, and were never deleted. A few were added for a bug fix that should never have had a switch at all.
2. Company decisions typed per building. Renewal terms, turnover timing, fees, tour rules, who gets notified, where availability comes from — all of it is stored per building. Western Slope has 82 buildings. Camellia's own settings would have to be re-typed 82 times to onboard them.
3. Decisions split across several fields with hidden fallbacks. "What happens when a caller asks for a person" is decided by three fields on two different screens, with a fallback chain, and a fourth and fifth field decide who gets told when the call fails. A building with all five empty lets a caller ask for a human, dials nothing, and leaves no record that anyone asked.
4. Things in the wrong place. The follow-up chase settings sit on a building page but rewrite the whole company. Which properties are hidden is stored per person, so two admins at one company see different portfolios. The onboarding-guide state is stored once for the entire platform although it is per person.

Sources: the Sep 9 settings inventory (code sweep of the main checkout plus a signed-in walk of production as staff, with screenshots of every settings screen), and live read-only database reads of the three reference properties.

2. The target model, in Gera's terms

Nothing here invents a new mechanism. Gera's portfolio design already defines exactly the machinery this cleanup needs, and this plan is written to fit it rather than beside it.

Levels

A value hangs on one node of the chain building → group → company, or on a person. There is no platform level: a value that applies to everyone is the company's value, or it is a constant in the code — not a setting. Fede's ruling that every setting gets a level (company, building or person) and Gera's writableAt list are the same rule stated twice.

Registry

Every key is declared once in code with a class — POLICY (the company decides, a building may not override), PARAMETER (a company default a building may override), IDENTITY (a fact about one building, never inherited) — plus the one field that matters most here: absentMeans, "the one place a default lives". Our whole migration story is that field: absentMeans is set to what PropFlow does today.

Attach rows

A value is a row, <node>/ATTACH#setting#<key>#<startedAt>, on ORG#, GROUP#, PROP# or a person. One live row per key per node; a change is an insert plus an end, never an edit and never a move. So "changing a setting" and "raising a setting to the company" are the same operation, and both are auditable.

Nearest wins, and the company can lock

Reading a setting walks building → group → company and takes the first value it finds. A company row marked locked stops any building from holding its own value. That gives us the two things the product needs and does not have: type it once for 82 buildings, and let one building differ where it genuinely does.

Defaults = today, so migration is nothing

No backfill, no data migration, no cutover. Each key's absentMeans is set to the value production resolves today. A building with no rows behaves exactly as it does now. The proof is a Camellia replay that comes out byte-identical.

3. The cleanup rules

4. The switches: their own deep clean

Every switch gets one of three verdicts.

• DELETE The switch gated a correctness fix, or it is already on everywhere, or nothing reads it. The behavior becomes the default and the field is removed. Rule: Fede, Sep 3 — no switches for correctness fixes.
• KEEP It gates genuinely new customer-facing behavior that is not finished or not approved. One switch per behavior, at the company, shipped dark, with a delete-by date.
• CONVERT It is not a yes/no at all — it is a value. Ten autonomy booleans plus the stage field and the module flags are one question with three answers: is this area off, in drafts, or live.

DELETE — 26 switches

KEEP — 12 switches, one per new behavior, all dark

Each of these gates behavior a customer has not seen yet. They keep exactly one switch, at the company, never per building, and each carries an owner and a delete-by date.

CONVERT — 17 booleans become one question with three answers

Ten autonomy switches, the stage field and the module flags are all asking the same thing about one product area. They become capability_stage.<area> — Gera's key, already in his registry — with three values: off (the customer does not see it), drafts (Clara prepares, nothing leaves), live (Clara sends). The two shadow-mode switches become observe.sms and observe.email, his keys for the same idea on one channel.

The global brakes stay as they are and are not settings: the platform email and SMS kill switches, the renewal auto-start and send arms, the collections halt, the excluded-people list, and the permission overrides. They are operational brakes we pull in an incident, they live outside the customer settings registry, and Gera's model has no platform tier for them by design.

What each switch is set to in production today

Read on Sep 9 from the production table with a consistent read, read-only. absent means the attribute is not stored on the record at all, so the code's own default applies. This is the evidence for every deletion below it: a switch that is off at a real property is a bake still running, not a delete.

Two things worth naming from this read. Yale is nearly empty: only four of these fields are stored on it at all, so Yale runs almost entirely on code defaults — which is why a default that equals today's behavior is the whole migration. And the seven "kill switches" on the staff page have never been written anywhere: they read as ON from their code default, which makes them a deletion with no production value to preserve. The global brakes read: platform email on, SMS on, vendor quote and dispatch emails on, renewal auto-start on, renewal sending on, holdover conversion on, collections not halted.

The safe deletion order

Per switch, in this order, one switch per pull request:

1. Read the live value at Camellia, Yale and the Willows with a consistent read, and confirm every real property already resolves the on-state. A switch that is off somewhere real is not a delete — it is a bake still running.
2. Pin the on-state as the default in code: delete the read of the switch, make the behavior unconditional. No fallback, no "if unset" branch left behind.
3. A regression test that fails on the old code and passes on the new — the behavior itself, not an assertion that a constant is true.
4. Camellia replay byte-identical (Gera's control fitness function, green at every step), then before/after screenshots of the settings screens at the Willows.
5. Strip the field from the type and leave a tombstone the drift guard checks, so the next session cannot reintroduce the same name.
6. Delete the stored attribute from the property records last, in a verified sweep, and never before the code has stopped reading it.

The rule that stops the pile growing back

Western Slope goes live on one switch

5. The verdict, setting by setting

Every row in the Sep 9 inventory gets one verdict. KEEP — stays as it is, already right. SURFACE — stays, but gets a screen it does not have. MERGE — folded into another setting. MOVE — same setting, different level. DELETE — gone. Level is where the value may be set: company, building, person, or brake (an operational switch we pull, not a customer setting). "Default = today" is the value production resolves right now, and it is what absentMeans gets set to.

Voice and phone

Tours

Leasing intake, applications and leases

Channels: email, calendar, texting, the PMS

Knowledge, fees and policies

Renewals

Maintenance and turnovers

Notifications, reports and follow-ups

Areas, stages and account

Added 2026-09-13 — switches this page did not yet cover

Second read, 2026-09-13, live from the production table, read-only. The Sep 9 pass had no Western Slope column and predates the two switches that now implement its dark hold. absent means the code default applies.

Counts from this pass: 14 REMOVE, 3 CONVERT, 1 KEEP as the single dark hold. The one genuine hold — portfolio-arrived records are recorded, never replied to — does not exist in the code today and has to be built before any of the fourteen can come out. Facts read live; two inferences are labelled in the working file ~/agents/006/hidden-flags-audit-2026-09-13.md.

6. Decisions for Fede

Only the ones that change what a customer experiences. Each is a yes or no, with a recommendation.

Numbers 2, 4, 5, 6 and 10 turn on at properties where the behavior is off today. They are correctness fixes, so under the Sep 3 rule they ship without a switch — but they still ship dark to prod first, get tested at the Willows, and only reach a customer property with your explicit go.

7. The plan, in phases

Aligned to Gera's ladder, and honest about what does not need it. His four-part step mechanic applies throughout: write the new rows while nobody reads them, prove parity offline against recorded inputs, cut one reader at a time behind the existing fail-closed switch, then strip the old field and leave a tombstone. Camellia is flipped last at every step and its replay stays byte-identical the whole way.

Phase 0 — inside the Western Slope window, on today's rails

Needs nothing from the ladder. This is the deep clean.

• Delete the 26 switches, one pull request each, in the safe order above.
• Delete the six settings nothing reads.
• Ship the arms registry and its CI check, so the pile cannot grow back while the rest of this runs.
• Fold the who-answers fields into one setting, and put the one Connect Microsoft 365 / Google button on the company screen.

Proof: a regression test per deleted switch that fails on the old code; Camellia replay byte-identical; before-and-after screenshots of every settings screen at the Willows; the CI check failing on a deliberately added switch.

Phase 1 — the registry and the rows, dark (Gera steps 0–2, targeting Oct 13–23)

• Declare every surviving key with its class and its absentMeans set to the value production resolves today.
• Write attach rows from today's fields. Nobody reads them yet.
• Put the resolver in the parity replay as his key #1.

Proof: scope-parity-replay.ts mismatches at zero against recorded inputs; one live row per key per node; the roster stamp complete and staying complete on the nightly check.

Phase 2 — the company screens (Gera step 7, keys one at a time)

• Cut readers over one key at a time, his order, the who-answers destination first.
• Each key's screen ships with it: Who answers, Office hours, Tours, Renewals, Turnovers & maintenance, Notifications, Follow-ups, Availability.
• The building page keeps an Overrides tab that shows only what differs from the company.
• Pending addition: tour gap, booking notice and reminder lead (Fede, Sep 13) ship with the Tours screen — dark, on their proposed defaults, no customer value changes.

Proof: per key, the pre-pin keys resolve at the company; Camellia byte-identical after each cut; the settings screen shows the same effective value before and after.

Phase 3 — Western Slope goes live on one switch (Gera steps 3a → 3b → 4 → 5a, Nov 18 – Dec 17)

• Their shared leasing line, their calendar and their mailbox attach to the company, not to 82 buildings.
• Leasing only: the leasing area's status goes to live at the company; renewals, maintenance and collections stay off.
• The flip is refused by name while any key it depends on is still unset, so the settings cannot be skipped.

Proof: the refusal naming the missing keys, then a real inbound call and a real inbound text answered on their line, and a row on the Western Slope go-live tracker with the production evidence link.

Phase 4 — after the window (Gera steps 8–10)

• Company locks where a value must not vary, using his lock sweep.
• Any class narrowing through his reclassification sweep, one key at a time.
• Strip the deleted fields from the types, leave tombstones, and let the drift guard keep them dead.

Proof: the lock sweep's dry run and pre-image; the drift guard failing when a tombstoned name is reintroduced; the arms registry with no row past its delete-by date.

8. Conflicts with Gera's design

Two, both small, both needing one edit to his registry rather than a change to this plan. Everything else in this document lands on keys he has already declared — capability_stage.<function>, observe.sms, observe.email, office_hours, holiday_policy, tour.minLeadMinutes, tour.dayPolicy, tour.durationMinutes, consent_model, application_link, new_lease_template, jurisdiction, vendor_roster.<trade>, outreach.cadence, fees.*, pets.policy, listings.feed_url, pms_delivery_mode. Three more are proposed and not yet in his registry: tour.gapMinutes, tour.minBookingNoticeMinutes and tour.reminderLeadMinutes (Fede, Sep 13) — same shape, nearest-wins, pending his registry entry.

1. Four keys where Fede ruled there is one. His registry declares office_phone, transfer.<role>, escalation.owner and escalation.cc as separate keys. Fede's ruling of Sep 9 is that "when a caller asks for a person" is one setting whose value is either a number to ring or an address to send the taken message to. Proposed resolution: implement it as transfer.<role> with a number-or-address value, retire escalation.owner and escalation.cc as separate keys, keep emergency_phone distinct for life safety, and keep office_phone only as the public number Clara reads out — a building fact, not a destination. One registry edit, Gera's call.
2. Our master brakes sit above the company, and his model has no level there. The platform email and SMS kill switches, the renewal auto-start and send arms, the collections halt and the permission overrides all apply above any one customer. His registry deliberately has no platform tier — a building is stopped only by its own company's lock or a statutory floor. Proposed resolution: these are not settings and never become registry keys. They stay operational brakes on their own internal page, outside the settings model, and nothing in the customer settings path reads them. Naming it here so nobody adds a platform tier later to make them fit.

Checked and found aligned, not conflicting: which state's rules apply stays a building fact that is never inherited; texting consent stays a company policy a building may not override; the vendor roster keeps the company-then-building inheritance it already has; the follow-up cadences stay company rows.