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.
1
In plain terms. Will a founder run the one-record update that moves one admin's saved building choice to the new per-company field, so the old field can be deleted?
The full question, as raised
p10-core-scope marker part 2 retires the legacy chosen-list pair (User.propertyListChosenInOrgId + propertyListChosenAt), now replaced by the per-company map User.propertyListChosenIn (#18210, merged). A read-only count of propflow-prod User rows (34 total, positive control 5/34) found exactly 1 row still carrying the legacy pair with no map entry. The backfill is ONE conditional update on that row: SET propertyListChosenIn = {<org>: <same chosen-at>} REMOVE the legacy pair, only if the row still matches the read (else nothing is written). Command: bash .../lanes/p10-core-scope/p2-backfill.sh (aws dynamodb update-item --table-name propflow-prod … --condition-expression 'propertyListChosenInOrgId = :o AND propertyListChosenAt = :t AND attribute_not_exists(propertyListChosenIn)'). Dry-run match: 1 row. No customer-visible change, because the new code already reads the legacy pair as that same entry. After it, a recount must read 0, then a PR deletes the legacy fields.
Why, and what was tried
The session raising this recommends: Yes, I'll run it It changes no customer-visible behaviour, touches exactly one record, and unblocks deleting the old field Tried first, unsuccessfully: Standing rule for this session: prod writes are founder-run on direct approval of the exact step (CLAUDE.md prod-data bullet; this driver is unattended, so it never runs prod writes itself). No model may approve a write to propflow-prod, so this is the founder's question by rule.
19d51f87 is parked on this.
2
In plain terms. The reviewer passwords keep getting overwritten from Fede's GitHub login (89 times since 17:32 today, in three repos) — will Gera or Fede turn off the copy of the password refresher running on Fede's side, so only the Mac mini refreshes them?
The full question, as raised
The 'outside writer' of the reviewer token secrets is identified by the GitHub org audit log (metadata only): actor fede-propflow, GitHub CLI 2.88.1, with 89 secret writes since the mini's 17:32Z 10-09 publish, across propflowai, appfolio-browser-agent and sales-machine. Most likely a second copy of the token publisher running on Fede's machine under his login, so two publishers overwrite each other's pools and reviews break in between. Agents never read or rotate secrets.
Why, and what was tried
The session raising this recommends: Fede turns his copy off Two refreshers fighting over the same passwords is what keeps breaking code reviews; the mini's is the documented publisher Tried first, unsuccessfully: Decider f0b171390 ruled: pursue stopping the outside writer in parallel. The audit log now names the actor (fede-propflow), so this is a founder-to-founder coordination question about credentials on Fede's machine, which agents may not touch.
19d51f87 is parked on this.
3Build a runtime check that makes Clara look up tour times before offering a tour (4 real conversations in 30 days)?
In plain terms. Clara sometimes offers a tour without checking open times; it happened in about 4 real conversations last month, none last week — should we build a check that makes her look first?
Why, and what was tried
The session raising this recommends: Not now, close it Gera's 2026-09-01 ruling (b87703542) says no rewrite loop until measurement shows an omission only a rewrite fixes; 6 of 209 turns with 0 in the latest week does not clear that bar, and the decider split on it. Model receiptFABLE was asked, and escalated. Receipt fbf3bf5fc — NEEDS HUMAN. THE TWO PASSES DISAGREED, AND ONLY THE OPTION ORDER DIFFERED. as-given → 'b: do not build a gate now: record the measured rate (6/209, ~4 conversations, 0 in the latest week) and the honest eval number on the row, close it as a known low-rate residual, and re-open if the rate rises' (medium) reversed → 'build it: a post-draft retry gate at the existing gate site that, on a leasing reply offering a tour with no calendar lookup that turn, retries once forcing check_availability/get_tour_slots; ship under the guard-change merge gate (30-day replay, every would-alter labelled), no switch' (hig…
19d51f87 is parked on this.
Answered and withdrawn (25)
b90914477 Three quick calls from the fleet board. Will Fede set up a test inbox, relax one narrow voice testing rule, and say whether the guard-proof check must block merges? Each item is built as far as it can go and is now waiting only on these answers. — answered: inbox: I had made one on Outlook and I'm pretty sure all the information is on first sell. Like the so you have these. OUTLOOK_TEST_EMAIL_PASSWORD OUTLOOK_TEAM_PASSWORD · voicerule: I'm not sure — go find out · mutation: Make it block merges
b90919518 What does the 'one record per person' foundation item cover? It reads as done but names no changes, and the board can't trust that. Pick its scope: just the code that creates the person records (5 changes), that plus stamping every record with its person (14 changes), or also the tenant-prospect merge, which isn't finished, so the item would stay open. — answered: So, I mean, if it's not done, we have to drive it. But the idea is that, like, at first, it's not always guaranteed. Like, someone emails us and they call us and then text us. Like, we won't know the email is the same person as the caller, even if the name's the same. But the moment we are able to join the conversation, we should. Like, if we see a guest card, for example. that has a email and phone number and then we combine it. So in moments like that, we want to have like one conversation, one record per person. And then the other thing was when a person calls about two different properties, we actually want to keep that. So all the people are kind of tied to the org, right? So one person per org when possible. So we have like a continuous thread on them. Go make sure that's currently the design though.
b90932551 Who should own keeping the shared Claude settings folder on the mini up to date, and how often? It has drifted: today it's missing 26 merged fixes, including one safety guard, and holds 43 local changes no tool can merge on its own. The earlier ruling says it needs a named person and a schedule. — answered: Agent Smith, which is a local kind of owner of the Mini. And they do have a daily pool, like in the mornings. But maybe it should be every, like, six hours. So it's tries to stay fresh.
b90954295 When the safety check on pushes runs out of time before it can tell whether this session is working a board item, should it refuse the push (you just retry) or let it through with a warning like today? — answered: I'm not sure — go find out
b90954508 Fede: the voice test-call tool can't reach webhook code before it ships, and there's no safe way to make it, so may your rule say those changes get tested right after deploy instead of before the PR? — answered: Yes, narrow it as written
b90955288 Gera: I checked the code against what you described (one record per person per company, joined once a guest card gives both phone and email), and it matches, so may I close the a0-spine item on the 8 changes that built it? — answered: Yes, close it on the eight
b90956076 Gera: the overnight check that catches tests secretly touching the real database stopped running when a duplicate nightly job was removed; may I add it back as its own small nightly job? — answered: Yes, add the nightly check
b90960997 Gera: the fix that combines a renter's duplicate records when their own rental application shows both their email and phone would, on its first run, merge 3 pairs of records at one customer (and nothing else) — and a merge can't be undone; may it go live? — answered: Yes, merge it
b91159509 Should we remove the shortcut where the word urgent in a commit title ships code to every live Lambda without the full test run? Emergency fixes would go through the existing deploy button, which asks for a commit and a reason. — answered: Keep a shortcut under a new, logged keyword
b91159527 Can the Lambda deploy use the same GitHub key our other deploy already uses, so its bookmark stops getting stuck? Until it does, every green build re-sends the same release to production. — answered: Use the existing broad token, merge the fix
b91161568 Can you add the outside test inbox to the repo settings and start the email check once the send freeze lifts? Everything else for it is built; that one run is the proof that closes the item. — answered: I will set the inbox and run it
b91344675 Three things only you can decide: which machines run local-bin's new automatic tests (cheap Linux, or Mac at about ten times the cost); whether we may fix the test company's listing data so a real test call can prove Clara now asks which area first; and whether you will run the prepared cleanup that removes real customer records copied into the test company? — answered: lbci: I'm not sure — go find out · fhdata: Yes, fix the test company's listings · copyclean: Yes, I will run it
b91379725 Should we fix Clara's two customer-facing mistakes now? — answered: Fix those two now
b91386826 Should Clara changes with no passing test be blocked from merging? — answered: I'm not sure — go find out
b91391690 Should Clara's full tests run every night on the live code? — answered: ask in the engineering bridge
b91402023 The deposit fix is live, but none of the test company's homes has a deposit, so the real email test couldn't check it. May a worker put a $1,500 deposit on ONE test-company home, re-send the test email, then remove the deposit again? — answered: Yes, one test home
b91433137 Can you fix the GitHub billing on your personal account (gera-propflow)? Since about 03:43 UTC every GitHub Actions job there stops before running ('recent account payments have failed or your spending limit needs to be increased'). The company repos are fine, but local-bin's checks can't run, so its ready fixes (the pause-inbox fix #470 and the rest) can't merge. — answered: I'm not sure — go find out
b91462078 To keep GitHub checks running on local-bin and dotclaude, will you fix the card or spending limit on your personal GitHub account, or move both repos into the company account? Both are private, so their checks bill to your personal account, which has refused every job since about 03:43 UTC with 'recent account payments have failed or your spending limit needs to be increased'. — answered: Move both to the company
b91538705 Will Gera restore the login that local-bin's code reviewer uses, so its pull requests can be reviewed and merged again? — withdrawn
b91574626 May the driver run the Supervisor's deploy script now to turn on the new stopped-helper alert, which restarts the Supervisor on the Mac mini? — withdrawn
b91581914 Will Gera find and stop whatever outside our tools keeps overwriting propflowai's code reviewer logins, last at 21:05 UTC today? — withdrawn
b91601120 When a message is sent to a session by an 8-character id, that id can match two sessions, so the tool now refuses it. But a session can also be NAMED with 8 hex-looking letters (like 'facade12'). Should the tool refuse anything that looks like an id, even when a session has exactly that name? — withdrawn
b91616044 One Clara test says she must never mention the closed day at all. Three others (one locked by the owner, built from a real email) say she should say plainly, once, that the day is closed, then offer other times. Real conversations since Oct 1: 0 problems. Which rule is right? — withdrawn
b91620341 Clara tells prospects 'I'll send a confirmation once it's booked' (12 times since Oct 1). But when the team approves a requested tour, nothing tells the prospect (that message was removed on purpose in August). So the sentence is untrue for requests. Should Clara say what actually happens instead (the team confirms the time and they get a reminder), keeping the sentence only when the tour is booked on the spot? — withdrawn
b91632315 When a session can't clean up its memory, the machine pops up an alert on every retry. Making it alert just once kept getting fooled by wrong clocks, which could hide a real alert. The fix both decider passes agreed on: tell one stretch of failures from the next by which clean-up record is newest, not by the clock, and also post it to the team channel. OK to build it that way? — withdrawn