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. Should Clara step in when a customer's own staff member promises a resident a repair ticket and then never files it? We can see those promises because we mirror their mailbox, and in two weeks we found one resident whose broken washer was lost exactly that way. Acting on it means Clara opens real jobs in the customer's system off a colleague's half-sentence, which could create tickets nobody asked for; leaving it means that resident waits. We have also never counted how often this happens - we have one case, not a rate.
The full question, as raised
Clara mirrors the customer's connected mailbox, so she can SEE a staff member promise a resident a work order. Today she does nothing with it. A 14-day read of 83 adjudicated conversations found a resident whose broken washer was promised a work order by a HUMAN at the customer (zero of 49 messages Clara-authored; every outbound writerId pms.inbox-mirror; "virtual maintenance coordinator" absent from our source against a control that hits) and never filed. Should Clara act on another party's promise?
Why, and what was tried
BOTH decider passes independently chose B and it was escalated anyway, correctly: the question turns on a commitment made to a person, which is not a model's to settle. Receipt fc6288560. Its reasoning, worth reading: the corrected prod read settles the facts, and the session that adjudicated all 83 candidates filed three defects OF OURS as rows (the address lookup missing an address we hold, the callback subject erasing urgency 17 of 17, the mis-threading) and deliberately did NOT file "act on staff promises" - it classed the washer case a customer-process matter, not ours. Hot rule 4: an LLM-decided action needs replay proof, and a promise-versus-already-done classifier has NO CORPUS until someone counts; the method exists (the two-leg rule plus hand adjudication already ran over 83 candidates). Rule 8's own origin warns against default-off switches nobody ever presses. Note the one measured lost repair was caused by OUR defect (the address lookup), not by an unfiled staff promise - so B also sequences the cheaper, certain fix first.
The session raising this recommends: Leave it to the office, and count how often it happens first Both decider passes chose it independently. We have one case, not a rate, and telling a promise apart from an already-done job needs a body of examples nobody has built yet. The one repair we can prove was lost went missing through a fault of our own that is already written up - fixing that is cheaper and certain. Model receiptFABLE was asked, and escalated. Receipt fc6288560 — NEEDS HUMAN. Both passes agreed on "B: stay out of it - do not act on another party's promise; instead measure how often this happens and fix our own confirmed defects first, leaving the customer's internal process to them", and it is being escalated anyway: this question turns on money or a commitment to a person (matched 'promise'), which is not a model's to settle however confident it sounds.
Paid for on 2026-08-07: the unit-607 renewal rate came back RESOLVED from both passes at high confidence and was wrong — Fable found the standup ruling about the move-in SPECIAL and missed the correction posted 2h…
a6bbe2cd is parked on this.
2
In plain terms. When Clara takes a call she cannot finish, the office gets an email, and we are changing its subject line to say what the call was ABOUT instead of just saying callback. One of her phone lines handles rent, balances and lease-terms questions together, so for those calls we cannot tell which of the two it was. Saying collections on that line would be right some of the time and wrong the rest, and the office sorts its inbox by that subject. Leaving the topic off means those subjects name the person and the fact they rang, and nothing more.
The full question, as raised
Clara's specialist roster is a closed set of nine slugs and the subject's TeamArea is derived from which specialist answered, before anyone speaks. Seven map cleanly. lease_and_billing is scoped 'verified-tenant rent / balance / lease terms lookups', spanning collections and renewals; turnover_intake has no TeamArea. Map both to the honest 'general', or assign lease_and_billing a specific area?
Why, and what was tried
The session raising this recommends: Leave the topic off when the call could be either That line takes rent calls and lease-terms calls on the same number, so naming a desk is a guess the office reads as fact — and the collections label has no other producer today, so we would be minting it on that guess. Model receiptFABLE was asked, and escalated. Receipt fdd6c3879 — NEEDS HUMAN. Both passes agreed on "Map both ambiguous slugs to 'general'. Only the seven unambiguous specialists name an area. The subject then says the person and, where the door knows it, the matter - and where the door genuinely does not know, it says nothing it cannot support rather than guessing a desk.", and it is being escalated anyway: this question turns on money or a commitment to a person (matched 'rent'), which is not a model's to settle however confident it sounds.
Paid for on 2026-08-07: the unit-607 renewal rate came back RESOLVED from both passes at high confidence and was wrong — Fable f…
a6bbe2cd is parked on this.
319 questions on this
In plain terms. Two things need Gera. First: the finished fix for the thing that jammed the shared code folder twice is tested and green, and the rules reserve that file to a person, so merging it is a click Gera has to make - leaving it means the jam can happen a third time. Second: a check that catches broken cross-references in our code keeps being silenced by unrelated nearby wording, and two attempts to fix it have failed; patching it once more costs one more review round, while removing the shortcut entirely deletes the problem for good but needs real wording edits across eight files.
0 of 19 answered
1The fix for the thing that jammed the shared code folder twice is finished, reviewed and green, and the rules deliberately will not let any robot merge it because it touches a file that can delete Gera's work. Should Gera merge it?
In plain terms. Should Gera merge the finished fix for the shared-folder jam? It is tested and green, and the rules reserve that one file to a person rather than a robot.
Why the raiser recommends it
The session raising this recommends: Merge it Everything a merge needs is already true and I checked both of GitHub's separate gate stores at the exact commit: ten checks green, nothing failed, nothing pending, and both reviewers non-blocking with their verdicts naming that commit. Nothing is wrong with it - the only thing holding it is a rule that reserves this file set to a person, and that rule is working as designed. It is the fix for a jam that has already happened twice.
2A safety check that spots broken cross-references in our own code goes quiet whenever a nearby sentence says a name is old. Two attempts to make it judge the RIGHT reference have failed, and the second attempt broke a case the first one had caught. Should this session keep the quiet-down rule and fix how it picks which reference it is looking at, or remove the rule and require every reference to either work or lose its code formatting?
In plain terms. Should this session patch the broken-reference check one more time, or take away the shortcut that silences it? Two fixes have already failed, and the second broke a case the first had caught.
Why the raiser recommends it
The session raising this recommends: Fix how it picks the reference Smallest change that closes the measured defect. Three different readers now disagree on how many references a line has, and asking the check to re-derive which one it is judging is exactly what failed twice. Handing it the guard's own result removes the disagreement rather than patching around it. I am asking rather than authorising a third attempt because the repo's own rule says a fix that creates the next defect in the same mechanism is a sign the shape is wrong and the choice belongs to a person - and because the deeper limit cannot be fixed at all: a phrase matcher cannot tell WHICH name a sentence is retracting, so no version of this will ever truly name what it excuses. That limit is already written down, with five legitimate cases registered by name and count so a sixth cannot be added quietly.
3Delete the nightly topic-labelling job from production scheduling? Its code was removed from the repo on 2026-10-05 by pull request 16563, but the schedule itself is still switched on and still firing every night at 09:00 UTC, starting a job no worker can run any more - the last five fires were 2026-10-22 through 2026-10-26. That pull request asked Gera yes or no in its own description and nobody answered, so it has been firing into nothing for about 21 days. Removing a live production schedule is a founder act, and an agent may only run it on Gera approving that exact step.
In plain terms. Should Gera delete a nightly job that has woken up every night for three weeks to run code this repo no longer contains? It achieves nothing when it fires, but deleting it changes production, so the call is Gera and not this session.
Why the raiser recommends it
The session raising this recommends: Delete it, and record that it was retired on purpose Nothing can run the job it starts, so every fire is pure waste, and the nightly report cannot go quiet while it is still switched on - the pull request that found it deliberately refused to silence that report rather than file a live problem as a known one.
4Merge the two fixes that give the documentation repo a spare login for its review bot, and make it say why it failed? Open as pull requests 374 and 375 on the docs repo. That repo reads one single login with no spare and no retry, so when that login is capped or expired the bot dies in under half a second having read none of the change, and posts a line that reads like an acknowledgement. Five pull requests there have been left with no verdict this way, and one of them is itself the fix for a board item, which leaves three items waiting behind it. Neither fix can be approved automatically, because both change the reviewer own workflow and the reviewer refuses to review that by design - so the merge has to be a person.
In plain terms. Should Gera merge two small fixes so the documentation review bot can fall back to a spare login instead of silently giving up? The bot is not allowed to review changes to itself, so nothing can approve these two automatically and the merge has to be Gera rather than this session.
Why the raiser recommends it
The session raising this recommends: Merge both The two halves answer different halves of the failure and neither covers the other: spare logins stop one capped seat from killing every review, and the reason-naming turns a silent death into a line saying whether to wait or to re-mint. Both were tested against a fake network with three deliberately broken versions, to prove the tests can fail.
5Re-arm pull request 22508, the fix that stops a health card reading Healthy through a real outage? It is green and approved at its current commit and nothing about it has changed. This session armed it at 19:48 and ONE MINUTE LATER a different account removed it from the merge line. GitHub own note on that removal says a person, a session or a re-entry guard did it and that nothing happens automatically there - and no such guard exists on this machine, main is not red, there is no hold label and it is not a draft, so the removal was a choice somebody or something made and this session cannot tell which. It had also been removed once before that, by GitHub own queue bot after a machine was reclaimed mid-run, which is why this session re-armed it the first time and verified the approval was exact to the commit before doing so. This session will not arm a third time against an account that pulled out the second one.
In plain terms. Should Gera re-arm a finished fix that something pulled out of the merge line one minute after this session sent it? It is approved and nothing about it changed, but a different account removed it on purpose, so this session stopped rather than sending it a third time.
Why the raiser recommends it
The session raising this recommends: Re-arm it It is green at the exact commit that was approved and nothing changed between the two arms, and what it fixes is a card that showed Healthy while every reviewer login was refused - but if the removal was a person deciding, that decision stands and this session will not out-click it.
6Three real people emailed in today, a safety check held Clara reply to each of them, and as of 22:09Z all three are still waiting with nothing back - 386, 308 and 293 minutes. None received anything from Clara and none from a human. Verified read-only against production with controls: the reader that found the zeros DOES see post-hold messages (it found a team escalation email written 0.9 seconds after one of the holds) and DOES see human takeovers (three staff-authored replies on those same threads earlier the same afternoon). One is at a company whose shared mailbox receives these directly, so by design no alert was raised at all and the only surface is the email sitting in their inbox. One alerted the team twice, by email and in the alerts channel, and nobody has picked it up. One alerted and was then closed by one of our own bots. Answering a resident is a customer send and is a founder call, so this session did not and will not.
In plain terms. Three people who emailed today have had no reply for five to six hours because a safety check stopped Clara answering - should Gera answer them, or ask the two property teams to? This session cannot send to a resident.
Why the raiser recommends it
The session raising this recommends: Answer all three now They have been waiting five to six hours on messages they sent today, the hold was a safety check being cautious rather than anything they did, and two of the three have no working alert path - one by design and one because a bot switched it off.
7One of our own bots closed a property-team hold card in the alerts channel, replying 4 minutes 52 seconds after the card that it came from an engineering rerun and no answer was owed. That claim is false on every field anyone can check, and no human ever saw the card. The checks: a real production email ingestion record exists for that moment with status completed, routed via ai, no error, and a trace id matching the conversation own turn key; the sender hash is identical to the thread real first email hours earlier and is a consumer mail domain rather than an internal one; the subject is neither a forward nor a reply and its hash is identical; and the text shares a common prefix of ZERO characters with every earlier inbound on that thread and is a substring of none. It was new text from the same real person. The bot id is the same one that posted the card, so it is either the card-thread handler or a session posting as it - which it is decides who fixes it. Compounding it, neither the inbound nor the held draft was written as a message row, so that thread appears to end 84 minutes earlier and a staff member would see no sign anything arrived.
In plain terms. Should Gera have someone stop a bot that closes team alert cards on the team behalf? It did that today on a real person held message, saying nobody was waiting, and that was wrong on every fact this session could check.
Why the raiser recommends it
The session raising this recommends: Route it and stop the bot closing cards The paging surface worked and an agent switched it off with a statement contradicted by every checkable field, so the one alert that did reach a team was cancelled by us rather than by them - and the missing message rows are what made the false story look plausible to anyone glancing at the thread.
8The alarm that should shout when the code reviewer runs out of accounts was watching the wrong set of accounts, so it stayed silent through a 14 and a half hour outage in which every reviewer account was being refused and six finished pieces of work sat unreviewed. The fix is written and proved, open as pull request 323 on the dotclaude repository. That repository has no automated checks at all, so no robot verdict can ever be earned on it, and the change sits next to credentials. A second, separate act is also needed: merging it does not reach this machine, because the copy running here is not following that repository, so the rotator here would keep watching the wrong set until somebody updates it by hand. Does Gera read the change and merge it, and then have the copy on the mini brought up to date?
In plain terms. Does Gera read and merge the fix for the reviewer alarm, and then have the copy on this machine updated? The alarm that tells us our code reviewer has run out of fuel was looking at the wrong fuel gauge and said nothing for over fourteen hours while finished work piled up unreviewed. The fix is ready and tested, but that project has nothing automatic to check it, so a person has to read it. And merging it alone does not help this machine, which is running an older copy, so that copy needs updating too.
Why the raiser recommends it
The session raising this recommends: Read it and merge it, then update the copy on the mini The silence is measured, not predicted: eight cycles in a row, every reviewer account refused, and the alarm quiet through all eight. Both halves of the proof were run - it shouts on that night's recorded state and stays quiet on a healthy day.
9Every piece of code needed to witness the renewal filing fix is now merged. The only thing left is the test data: to make a real model run exercise the branch, the bench needs a seeded history on a test persona. Two things make that a decision rather than a task. First, the persona is SHARED, so seeding it can corrupt any other bench run happening in the same window. Second, a safety rail we deliberately shipped exists to DELETE exactly that kind of seeded data, so every seeding fights that rail and the fight repeats every time the rail runs. The Driver has been holding this and has never asked, which is the real defect here. Does Gera want a separate unshared test persona built first so the witness is repeatable, or a one-time seeding on the shared persona in a quiet window, or the fix left unwitnessed on the strength of the checks already shipped?
In plain terms. Does Gera want a separate test tenant built first, or a one-time seeding of the shared one, or to leave this unproven? To prove the repair works end to end we need a test tenant with some history behind them. The one we have is shared, so setting it up can spoil someone else's test running at the same moment, and one of our own safety features is built to wipe that kind of setup data - so we would be fighting it every time it runs. Building a private test tenant costs more now and works every time after.
Why the raiser recommends it
The session raising this recommends: Build a separate unshared test persona first, then witness it Seeding the shared one fights a safety rail we shipped on purpose, and that fight comes back every time the rail runs, so the cheap option is only cheap once. A separate persona also removes the risk of spoiling another run that happens to be going at the same time.
10When a safety check stops one of Clara's replies to a resident, that stopped reply gets no entry in any queue. There is no approve-or-reject row and no clock, so nothing ever closes it - the three people waiting since this afternoon are waiting in nothing. The obvious fix is to give it a queue entry, and that is where it stops being a task. The only writer we have for a stopped text message is attached to a sweep that CLOSES anything still pending after 24 hours WITHOUT SENDING IT. So giving these a queue entry as things stand means a resident's reply gets destroyed, unsent, at the one-day mark. Exempting them from that sweep instead creates an entry that never expires and can sit forever. Doing it for email only dodges the sweep but leaves the resident who texted exactly where she is now. A further catch found while checking: if we add a queue entry we must also retire the alert card in the same change, because a queue entry AND a card for one stopped reply is two doors to the same thing. Which way does Gera want it?
In plain terms. Which way does Gera want a stopped reply to a resident to be queued? Right now when a safety check stops one of Clara's replies, it goes into no list at all, so there is no button to approve it and nothing that ever chases it - which is why three people have been waiting since this afternoon. Putting it in the existing list would hand it to a clean-up job that deletes anything older than a day without sending it, which would be worse. So the choice is between leaving it out of the clean-up, doing it for email only, or leaving things as they are.
Why the raiser recommends it
The session raising this recommends: Add the queue entry and exempt it from the 24-hour auto-close Nothing silently destroying a resident's reply is the floor; an entry that sits too long is visible and fixable, while one that closes unsent is not. The sweep's own purpose is tidying automated sends, not discarding a person's answer.
11A real rental prospect at Western Slope has gone unanswered since 2026-10-26 15:34:35Z - about 11 hours. Clara's first reply was HELD (first_email_check_failed) and NO DRAFT was ever stamped, so the human-approval rail we shipped tonight has nothing to approve: it can only release a draft that exists. Answering this person is a founder act and re-running the intent to produce a draft is a production write on a real customer - and Fede's own guard, merged hours ago, now refuses exactly that. What should happen for this prospect?
In plain terms. Do we answer a renter who has been waiting eleven hours, and who sends it? They enquired about renting yesterday morning, Clara's reply was held back for a safety check, and no draft was ever saved - so there is nothing for anyone to approve and send, and the clean-up after last night's test incident deleted the only visible sign that somebody was waiting. Only a founder can authorise an answer to a renter - Gera or Fede, not this session.
Why the raiser recommends it
The session raising this recommends: Answer them today, staff or founder-approved draft Fable resolved this under reversal at high/high confidence and ruled an agent must neither send nor re-run: guest-card-rerun-one.ts states its dry run drafts nothing, so a read-only re-run gives the rail nothing to show, and a draft-producing run is a prod write whose engine turn may book in the turn - circumventing a founder's hours-old guard (#22504). Precedent on three prior blocks routes a held first email to a human who approves a fresh draft, fail-closed. Leaving it as the customer's own queue breaks the standing rule that PropFlow's side is never parked as the customer's call, and the incident clean-up erased the only visible trace. Fable also said this belongs in the engineering-bridge thread and not only here - I have NOT posted it there, because I could not establish an existing incident thread to add to and starting one is yours to choose. Receipt: fable ffebdcdcb.
12A resident can receive the same approval email twice, and we have proved exactly how. The approval screen's duplicate check asks 'is there a saved record of a sent email after the hold?' and treats 'no record' as 'not sent'. But the email goes out first and the record is saved afterwards, best-effort, by code that deliberately never reports a save failure back to its caller - so a send that lands and fails to save leaves the screen looking like nobody replied, and the next approver sends it again. A crash between the carrier accepting the email and the record being written reaches the same state with no alert at all. Nothing is built or changed; which design should close it?
In plain terms. To stop a renter getting the same email from us twice, should the mini write down that it is about to send an email BEFORE sending, instead of relying on the copy saved afterwards? Right now the approval screen a property team works from decides whether we already replied by looking for that saved copy - and the email is sent first, saved second, so if the save quietly fails the screen still says nobody replied and the next person approves it again. This session proved it can really happen and changed nothing yet.
Why the raiser recommends it
The session raising this recommends: Write the intent before we send It is the only option that also covers the crash route, and that is measured rather than argued: a process death between the carrier accepting the email and the record being written reaches the identical state AND kills the alert, so no amount of in-process care or retrying can close it - only evidence written BEFORE the send can. Asking the provider is good corroboration but depends on a third party being reachable at approval time. Adding an alert and waiting leaves a resident-facing double-send live while we measure it. One constraint must survive whichever is chosen: a failure to save a record must still never be reported to the caller as a failed send (ADR-0119) - that rule is correct, and the defect is that the approval rail reads it backwards, inferring 'no record, so not sent'. Whichever way this goes, the function's own docstring should stop saying it appends the record 'IFF' the send reached the recipient, because that sentence is what licenses the wrong inference. NOTE ON PROVENANCE: the decider was asked first and returned NEEDS HUMAN with no recommendation - the two rungs did not resolve. This recommendation is the Driver's own, formed from the measurement, not a decider ruling.
13When one of Clara's own safety checks holds a reply mid-conversation, that held reply gets NO queue row, no owner and no expiry clock - it is not waiting in a queue, it is waiting in nothing. That is why three real residents waited 462, 385 and 370 minutes on 2026-10-26 with nobody alerted. The obvious fix - put these holds on the existing review list - was investigated and NOT built, because it also arms a Send button: the release buttons render on the single condition state==='pending' (HeldMessageView.tsx:204-207), the state enum has no visible-but-not-releasable option ('pending'|'approved'|'rejected', types.ts:23201), and heldBy appears in NEITHER approve function, so it buys no restraint. Both approve paths end in a real carrier send. Arming that is a founder act, so nothing was written. There is a second route that needs no send path at all: make the alarm fire instead - the reply clock currently declines to page a held reply on the stated premise that 'the team was told', which these holds disprove. Which route?
In plain terms. Should the mini fix the ALARM for Clara's stuck messages rather than putting them on the review list? When a safety check stops one of Clara's replies, that message currently lands nowhere - no list, no owner, no timer - which is why three renters waited six hours on 26 October and nobody was told. Putting them on the review list would fix the visibility, but it would also give staff a Send button for them, and pressing it messages a real renter - so that is Gera's or Fede's call and nothing was built. Fixing the alarm instead would make sure somebody is told, sends nothing to anybody, and needs no permission.
Why the raiser recommends it
The session raising this recommends: Fix the alarm, not the queue It closes the actual harm - nobody finding out - without arming anything, so it needs no founder authorisation and can ship today. The invisibility is what cost those three residents their afternoon; the missing Send button is not what hurt them, and a human was already reachable by email and by card on two of the three paths. Routing these holds into the review list is the bigger change AND the riskier one: the lane measured that a genuinely safe version needs either a fourth hold state or a no-release discriminator honoured in four separate places, and a miss in any one of those four IS a send to a resident. Meanwhile the alarm route has a row already open and measured (the reply clock stands down at inbound-reply-clock.ts:97 because 'a designed hold, the team was told' - a premise this incident refutes) and a second compounding arm beside it (a 24-hour ceiling at :93, so the longer someone waits the quieter the alarm gets). Fixing those two makes a held reply impossible to lose silently, with zero delivery risk. The queue route can then be decided calmly, and if it is ever wanted it should be built on a no-send state rather than bolted onto 'pending'. NOTE ON PROVENANCE: nothing has been built or changed; a lane investigated, hit the stop condition this Driver wrote, and shipped nothing. This recommendation is the Driver's own.
14Three real customer conversations are missing their stay-quiet marker while three abandoned duplicate rows still carry it. The code fix landed and is live, so no NEW marker can land on the wrong row, but it backfills nothing and these three predate it. Measured by keyed read-only prod queries, no scans, re-run 2026-10-26: all three are status=active with autoReplyHold ABSENT (two at appfolio-163, one at western-slope-front-door), with a projection control proving the absence is the row's state and not an artifact of the query. Consequence: the send door reads only the stored marker (dispatch-envelope.ts:464), so for these three the only remaining net is a last-author scan on one wake path - one net instead of two, and a second net by luck rather than design. STILL LATENT: no evidence was found of Clara sending on top of a staff reply on any of the three. The repair is ONE conditional SET on three rows, and because the marker is MONOTONIC with no release path it is at once a prod-data repair AND a permanent change to what those residents hear. This has never been asked before today - it was filed 2026-10-25 and nobody was asked, which is my failure, not a new finding.
In plain terms. Should the mini make Clara stay quiet on three real resident conversations where a staff member has already replied? Those three lost that setting because of a bug that is now fixed, but the fix does not go back and repair conversations that already exist, and these three are the ones left over. Nothing bad has happened on them yet - one safety check is still catching it - but there is only one check instead of two. The catch is that it can never be undone once done, so Clara is permanently silent on those three; on conversations where a person already replied, that is probably what Gera would want anyway.
Why the raiser recommends it
The session raising this recommends: Stop Clara replying on those three The permanence objection is weaker than it first looks, and that is the crux. The marker means 'a person already replied here, stay quiet'. On these three threads a person DID reply - that is why the leftover duplicate row carries it - so Clara staying quiet permanently is the state we would choose for them anyway, not a loss we are accepting. Against that, what it prevents is Clara messaging a real resident on top of their staff member's reply: a visible customer-facing error, and the exact failure the original row was opened for. The exposure has been latent for days on one net instead of two, and latent is not safe - it means we have not been unlucky yet. Making it undoable first is the tidier engineering answer and I would prefer it if these were ten threads, but it leaves the exposure open for as long as that takes to design and ship, for three threads where silence is the right outcome regardless. Leaving them is defensible precisely because it is latent, and it is right if a founder judges Clara's silence on an active thread to be worse than a possible duplicate reply - that is a product judgement I should not make. ⚠️ TWO EXECUTION CONDITIONS WHICHEVER IS CHOSEN: under the 2026-10-05 ruling an agent may run this only on approval of the EXACT command with counts from its own dry run taken AT THAT MOMENT, so the figures above must be re-measured before anything is written - they are from 2026-10-26. And the three leftover duplicate rows' keys were never recorded at filing, so that half of the check is carried rather than re-measured; whoever repairs should key them from their own ids at that moment. NOTE ON PROVENANCE: this recommendation is mine, not a decider ruling.
15Three test buildings are all named "The Willows" (appfolio-45 in org_sandbox; fairhaven-thistledown-402 and ws-mirror-appfolio-45 in a second test org), sharing seeded phone numbers, so one phone returns two live claims in two orgs and the bench keeps manufacturing cross-org identity collisions that look like product bugs. The cleanup script is written, merged and proven; the only step left is a destructive write against propflow-prod, which the hard floor reserves to a founder and which an unattended session may never run even with approval. DRY RUN RE-TAKEN JUST NOW (read-only, exit 0, runId f26ac59e-3641-4536-98b0-7051aa26971b): 204 property rows scanned, 3 share the name, all isTest=true. Planned: 33 deletes (17 phone claims, 16 org sentinels), 11 CONTACT re-projections, 44 archive rows written first, 1 transaction. SET sha256=ce0d195a67f5da5faf0ba4bccc37c2557d4dcd171f88472595a3677c2f14a939 — IDENTICAL to the set recorded three days ago, so nothing has drifted. 1 org sentinel is deliberately left in place (it is a different person's own uniqueness row) and 3 duplicate persons that own live rows (19 conversations, 1 renewal saga, one with 7 colliding phones) are HELD and untouched, so this reduces the collision rather than eliminating it. THE EXACT COMMAND: DATA_BACKEND=dynamodb DYNAMODB_TABLE_NAME=propflow-prod AWS_REGION=us-east-1 npx tsx scripts/dedupe-duplicate-test-property-claims.ts --primary=appfolio-45 --apply --confirm-table=propflow-prod --expect-set-sha=ce0d195a67f5da5faf0ba4bccc37c2557d4dcd171f88472595a3677c2f14a939 . Will Gera run it?
In plain terms. Should Gera run a one-command cleanup on live data so that three pretend test buildings stop sharing a name and the same pretend phone numbers? Today the system cannot tell which of those buildings a texter lives in, so it pages a person instead of opening the repair job, and the cleanup is already written and tested — a founder is the only one allowed to run it.
Why the raiser recommends it
The session raising this recommends: Run the cleanup now Every row is archived before deletion, each property must read isTest or the run aborts, the table name is re-proved at write time, a drifted set sha aborts, and --restore=f26ac59e-3641-4536-98b0-7051aa26971b puts it all back.
16Our own team's test identities are showing on a real customer's conversation list, and the switch built for exactly this is sitting unset. MEASURED JUST NOW, both surfaces, each with a passing control: TEST_TRAFFIC_INTERNAL_SENDERS is ABSENT from the prod worker's ECS task definition (21 env vars + 24 secrets; control DYNAMODB_TABLE_NAME present; no TEST_TRAFFIC var of any kind) and ABSENT from Vercel production (191 entries; controls TWILIO_AUTH_TOKEN and four AWS/DYNAMODB vars present). Note the instrument: 'vercel env ls' lists NAMES even when values read Encrypted, so a zero on the name is real evidence here rather than the empty a sensitive-variable pull would give. WHY THIS IS THE RIGHT CURE AND NOT A DATA CLEANUP: the marker was built for this exact shape and says so in its own words - 'MARKER 6 - internal-tester senders, CONFIGURED AT RUNTIME, never hardcoded ... Covers the shape none of markers 1-5 can: a person on the team dialing or texting a LIVE, correctly-unflagged prod property to verify a change (2026-08-19 QA pass, B7 - six voice conversations from one internal tester's real number surfaced in the grading queue as resident activity)'. That incident was at the SAME customer building this finding is about. Setting it excludes the WHOLE row - the cached name, the unit and the tenant id - whereas a data fix reaches one attribute, and a worker that investigated this found a script could not close it at all: a writer verb exists for the name only, the person id cannot be re-pointed because the spine requires it, and 28 of the 32 affected rows render a placeholder rather than a name, so a scrub would be a no-op on most of them. WHAT IS EXPOSED TODAY: our own test and staff identities anchoring threads on a real customer's list, four of which render a name. It is OUR people, never another customer's residents, which is why this is low severity rather than urgent. TWO COSTS, BOTH STATED: it also DROPS those threads from grading, which is a product decision and not a cleanup; and the module warns in its own words that 'a false positive on THIS predicate hides a real tenant from their property manager. That is strictly worse than letting a bench row through', so the sender list must be exact. It is configuration on two production surfaces, reversible, and touches no customer data.
In plain terms. Should Gera switch on a setting that stops our own team's test phone numbers and email addresses from showing up as if they were residents on a real customer's conversation list? The switch already exists and was built for this, it changes no customer data and can be switched back, but it also stops those conversations being scored for quality, and a wrong entry in its list would hide a genuine resident from their property manager.
Why the raiser recommends it
The session raising this recommends: Stop showing our test accounts It is reversible configuration that touches no customer data, the module was built for this exact case, and it removes the whole row rather than one field - but the sender list must be exact, because a wrong entry would hide a real resident from their manager.
17AN APPROVED APPLICANT TOLD US IN WRITING THAT THE LEASE WE SENT HAD THE WRONG TERM, AND NOTHING HAS GONE BACK IN 64 DAYS. Camellia, unit 311, final inbound 2026-08-24T22:00:07Z: she received the lease and the dates read 12 months instead of the 6 that had been agreed and confirmed in the same thread. VERIFIED BY ME, not relayed: the conversation's newest message row is hers, assistantAfterInbound is false, and a bounded read of her person index shows ONE sibling thread with ZERO sends after that inbound. So there is no reply anywhere in our record. THE SEQUENCE MATTERS AND IT IS NOT A CLARA FAILURE: staff had taken this thread over. Clara's last written reply was four days earlier; every assistant message after it carries a whole-second timestamp against Clara's millisecond ones and the last is signed by a community manager. Nine minutes before the unanswered message, staff wrote 'We will send over the lease now. We will see you soon.' And the message before THAT one says, verbatim, 'Sorry, we didn't respond' - so this thread had already slipped once before this gap. ⚠️ ONE CAVEAT I COULD NOT SETTLE, and it is the reason this is a question rather than a report: she said she would come to the office within the hour to collect keys, so the term may have been corrected face to face and never written down. I tried to settle it from the executed lease and FAILED - there is no tenant row under that property in the shape I queried (positive control: the same shape returns a row at another property, so the query works; that property's residents are stored under a different shape, which I did not chase). So the record neither shows an answer nor shows a resolution. WHY IT REACHED NOBODY: the reply clock stops looking past 24 hours by design, which is right for 'is Clara down' and wrong for 'is a person waiting', and it is silent in the one direction nobody guesses - the worse the wait, the quieter the alarm. A full re-derivation found SEVEN such threads, not the four the board recorded (all three company partitions exhausted, 1,648 rows, no page cap). FIVE of the seven need nothing - a thank-you, a 'the ball is in my court', a staff test card. TWO do not: this one, and a 60-day-old thread where a person asked for a human, Clara forwarded it to the property manager and said she would come back, and nothing has. I am not asking about that one here; it needs no housing decision, but the promise is unkept. ⛔ I have drafted nothing and contacted nobody. Outbound to a customer is a founder's call.
In plain terms. An applicant told us two months ago that the lease we sent her was for twelve months instead of the six she had agreed, and nobody wrote back - should Gera reply to her today? The property's own staff were handling that conversation at the time, not Clara. She was about to collect her keys in person, so it may have been sorted at the desk and never written down, but nothing in our records shows an answer either way.
Why the raiser recommends it
The session raising this recommends: Reply to the applicant today Sixty-four days of silence on a document error she flagged is worse than an unnecessary note; if it was fixed in person a one-line confirmation costs nothing, and if it was not she may be on a twelve-month lease she never agreed to.
18Three resident conversations are missing the note that stops Clara replying after staff already answered; the note sits on phantom copies instead of the real conversations. Putting it back is a write to live customer data and it is permanent - there is no way to lift it, so Clara would never reply on those three threads again and staff would carry them by hand from now on. Should the note be put back on all three?
In plain terms. Gera or Fede: should Clara be permanently stopped from replying on three resident conversations where staff already answered? Those three lost the note that does that, so Clara has one safety net on them instead of two. Putting it back cannot be undone, which is why nobody has done it, and nothing has gone wrong on these threads yet.
Why the raiser recommends it
The session raising this recommends: Put the note back on all three threads It restores the state the existing rule already chose - Fede's own words in the code are that if another human replies we stop - rather than deciding anything new.
19Our audit log records a signed-lease fetch as a SUCCESS when the document was thrown away seconds later as the wrong one. Two ways to fix the record. Which do you want?
In plain terms. When we fetch a signed lease and then throw it away as the wrong document, should our records add a second honest line saying so, or should we change what the existing line means? Right now the record says the fetch worked, full stop. Four stuck notices have logged 'worked' between 29 and 64 times in a row while the email they exist to send never went out. The second option reads better later, but two safety checks currently forbid it and I am not willing to loosen a safety check just to make our own fix fit.
Why the raiser recommends it
The session raising this recommends: Add a second, honest audit line It is built, reviewed and green, and changes nothing for the twelve existing readers. The other option is not merely more work: two drift guards currently forbid it, and I will not loosen a guard to make a fix fit. The worker that built this says plainly that nothing it measured ruled out your other option, so the call is yours and not a measurement.
Why, and what was tried
Tried first, unsuccessfully: fable-decide was asked a DIFFERENT question first: whether to authorise a third attempt by the lane with the design change named, or stop. Both passes, options reversed, high confidence each, answered STOP AND PUT IT TO A HUMAN (receipt fbaecf2d7). Its reasoning corrected my framing: propflowai/CLAUDE.md:182 names this exact shape, and the rule PRESUMES the session has already named the design change - so 'I can name it' is the remedy's precondition, not an exception to it. It also noted my 'the prescription changed between rounds' carve-out is personal rather than written, and that I had conceded the regression breaks the analogy I was leaning on. So this raise EXECUTES that ruling rather than overriding it. The design pick itself was never put to Fable, because Fable's own answer was that it is not a model's to settle. The merge-press question is bundled because its predecessor row b92857298 resolved on the question it actually asked, and what remained was an act rather than a question.
a6bbe2cd is parked on this.
Answered and withdrawn (3)
b92855966 Should the nightly repair test keep writing a one-line reason for each failure into its permanent record? That record is kept in plain text forever and our own rule says a resident's name must never appear in it - but the tool we rely on to strip personal details only removes phone numbers and email addresses, not names. Keeping the reasons means also fixing that tool; dropping them means the morning read goes back to seeing that a test failed without seeing why. — answered: Stop writing reasons there; keep them somewhere that expires
b92857298 The fix that stops the daily "main checkout stuck" alarm has been correct for six review rounds, but each round the reviewer keeps finding small polish items in the safety-net code I added on top, and the review bot will not give a green light until it finds nothing. Choosing "stop" means we merge it as soon as the reviewer has no blocking complaint (and once the separately held one-word check fix is approved), and leftover polish moves into the bigger rewrite you already have open. Choosing "keep going" means I keep doing rounds until the bot is fully green, however many that takes. — answered: Stop polishing; merge once nothing blocks.
b92866004 Session a6bbe2cd is frozen on a prompt in its terminal (tmux pane %146) that Smith will not answer. Deciding here records your choice on the block; the keystroke itself still has to happen at the pane — nothing will type into a live menu on your behalf. — withdrawn