I'm parked on you

Pick an option on each card and press Done; your answer goes straight back to the session. The raiser's pick is marked. "I'm not sure" and "Take it to the engineering bridge" are real answers.

1Will a founder run the one production clean-up of all six split renter records, in three steps, now that the fixes are live?

In plain terms. Will Gera or Fede run three clean-up commands on production to fix the old split renter records? Step 1 merges 9 duplicate people (5 at real companies), step 2 removes one ended duplicate tenancy row, and step 3 unhooks one staff record from a company phone line; the fixes that stop new splits are already live.

Yes, a founder runs all threethe raiser's pick Run steps 1 and 3 only Not yet I'm not sure — go find out Take it to the engineering bridge

Why, and what was tried

ONE production heal of the existing split renter records, in three steps. The save-path fixes that stop new splits are live (propflowai #25143; the company-line writer fix #25219 is merging). Every heal tool's safety fixes are merged: #25144 #25146 #25156 #25162 #25170 #25208 #25231. WHO RUNS IT: a founder, in their own terminal, from a fresh origin/main checkout (196e3007122 or later), as gera-admin. This driver session is unattended, so the repo's hard floor forbids it from running a prod-data merge or delete even with approval (Fable fa2e73056). REQUIRED ENV PREFIX on every command: DATA_BACKEND=dynamodb DYNAMODB_TABLE_NAME=propflow-prod AWS_REGION=us-east-1 (.env.local names propflow-stage). Check that the first line of each run says table=propflow-prod. Run each dry run immediately before its apply: nothing re-checks a record between plan and apply. STEP 1: merge the split prospect persons (identity merge) - Script: scripts/merge-split-prospect-persons.ts. Run it with no flags first (dry run), then add --mode=apply --confirm-table=propflow-prod. - Agent dry run on main 196e3007122, 2026-11-04 ~21:35Z: 7 groups, 9 Persons absorbed. Moves 1 conversation, 9 inquiry rows, 9 claims, 7 household rows. 35 verify reads, all keyed. 42 skipped (cross_org 28, conversation_real 6, overlapping 2, and one each of test_residue, prospect_claimless, already_merged, live_role, org_own_line, conversation_claimless). - Real companies (3 groups, 5 absorbed): - the Ecuador-phone trio 46f73428 / de2aa46b / 35e9a286 → pers_fd775980 - relay lead c08dd8c5 → pers_8e3552a0 - guest-card lead d181a905 → pers_b47627d0 - Test companies (4 groups, 4 absorbed): d1c1da11 in the Fairhaven test company, plus 1734a2bb, 01fef0ba and e57a3b31 in the sandbox. - Apply re-reads every moved row and exits 1 on any mismatch. A missed conversation fails loudly and is not rolled back. STEP 2: remove one ended duplicate tenancy row (archived first) - Script: scripts/dedup-occupancy-rows.ts with --env-file=.env.local. Dry run first, then add --mode=apply --confirm-table=propflow-prod. - An agent could NOT run its dry run (a box guard refuses full-table scans of prod), so its counts are unobserved. - Expected: record tenant_2888880e keeps the ACTIVE row (pers_816dc8e2) and archives, then deletes, the ENDED row (pers_8bba1ce1). An agent read both rows directly. - Only `former` rows can ever be deleted, inside a transaction pinned to the row as scanned. If the dry run lists more than that one group, read every group before you apply. STEP 3: repair the record that came in on a company's own line - Script: scripts/heal-org-own-line-pointer.ts --inquiry=06bfa686-6e68-5548-ac95-6527ab5e8e5b. Dry run first, then add --mode=apply --confirm-table=propflow-prod. - Agent dry run on main 196e3007122: HEAL. The prospect's link moves from the main-line call back to the person's own email thread 41946aee, and the stale company-line phone claim claim_8aefaa62 is retired, never merged. Two real splits given as controls were refused. When it is done, the driver verifies with a read-only check that the splits are gone, records it here, and the nightly spine-health check should go green.

The session raising this recommends: Yes, a founder runs all three
Decisions b93192295 and b93817802 ruled 'fix first, then heal all of them in one go'. The save-path fix is live, every heal tool's safety fix is merged, and fresh dry runs on current main match the plan exactly. The repo rule says only a founder may run a prod merge or delete from this unattended session.
Tried first, unsuccessfully: fable-decide receipt fa2e73056: RESOLVED that a founder approves and runs the commands (CLAUDE.md:172, unattended sessions never run prod-data ops); the approval itself is a person's by that rule. Supersedes b93817802, which no person had answered.

81b6cc93 is parked on this.

Answered and withdrawn (2)

b93192295 Five prospect records at Camellia and Barcelona are split from their own conversations, and one Camellia-company tenant record sits under two people. Should we fix the two save paths so they always land on the same person first, then merge the six existing records, or just merge the six records now? — folded into b93817802
b93817802 Gera or Fede: please run two clean-up commands on production to merge the old split renter records; the fix that stops new splits is already live. Step 1 merges 9 duplicate people into the right person (5 at real companies, 4 at sandbox test companies); step 2 removes one ended duplicate tenancy row and needs its own dry run first. — folded into b93827941

Pick an option above, then press Done.