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.
18 questions on this
In plain terms. Should we clean up fifteen leftover scripts that nobody runs on a schedule? Some of them write to live customer data or call a real phone if anyone runs them by accident. Seven questions decide what happens to each group.
0 of 8 answered
1scripts/eval/probe-appfolio-description-lag.ts has every argument defaulted, so a bare run takes the bench lock and POSTs a REAL work order to a real customer's AppFolio property (jpco property 45, via createWorkOrderL4). Its own header says 'authoring only — do NOT run without human approval; this is a real bench WRITE.' Its one documented use is a single past bench run for #3593. Delete it, or keep it and make it preview-unless---write immediately?
In plain terms. Should we delete a leftover test script that files a real repair ticket on a real customer's account if anyone runs it by accident? The one job it was built for is already finished and written up.
Why the raiser recommends it
The session raising this recommends: Delete it Its purpose is finished — the one run it exists for is already written up on #3593 — and a kept copy cannot stay armed either way, so keeping it buys a disarm job and no capability.
2Three scripts under scripts/vendor-calling (bench-agent.ts, bench-qa-robot.ts, bench-sync.ts) are the toolkit for one bench that was parked on 2026-07-28. Each has one authoring commit, zero references outside its own header, zero launchd/cron entries and zero fleet wrappers. Delete all three, or keep them against the bench being restarted?
In plain terms. Should we delete three scripts that belong to a test setup we parked in July? Nothing has run them since, and nothing is scheduled to.
Why the raiser recommends it
The session raising this recommends: Delete all three The bench they serve has been parked eleven weeks with nothing scheduled to run them; git history restores all three in one command if it restarts.
3scripts/vendor-calling/front-gate-probe.ts silently dials a stranger's phone line with no --list and no --dry-run option. It was a one-shot reconnaissance sweep and that sweep is written up at docs.propflowai.co/a/vendor-front-gate-recon. Delete it?
In plain terms. Should we delete a leftover script that calls a stranger's phone the moment anyone runs it? The job it was built for is finished and published.
Why the raiser recommends it
The session raising this recommends: Delete it The sweep it was built for is finished and published, and a script whose bare run dials a person who never agreed to be called is the worst thing to leave lying around unflagged.
4Two scripts under scripts/labeler-benchmark (round3-micro-corpus.ts, round3-reasoning-probe.ts) belong to a round-3 investigation that our own notes and board page record as concluded. The first makes two real model calls per case against 32 hardcoded ids; the second reads a gitignored corpus of real customer mail and, given no ids, exits 0 having measured nothing. Delete both?
In plain terms. Should we delete two scripts from an investigation we finished and wrote up? One of them quietly reports success while actually measuring nothing.
Why the raiser recommends it
The session raising this recommends: Delete both The investigation is recorded as concluded in two places, and the second script already exits successfully while measuring nothing, which is the shape that produces a false all-clear later.
5Two read-only scripts (scripts/eval/replay-office-hours-refusal.ts, scripts/eval/replay-start-scope.ts) are the one-shot replays our guard-change rule requires, for guard changes that are now live on main (verified this week: the office-hours refusal returns a null statement, and the suppression gate reads governingSuppressionEvent). Each has zero references outside its own file. Delete both?
In plain terms. Should we delete two scripts that each exist to double-check one change we already shipped and verified, or keep them as examples for next time?
Why the raiser recommends it
The session raising this recommends: Delete both Each proves one specific change that already shipped, so neither can be re-run meaningfully; the next guard change writes its own replay against its own guard, which is what the rule asks for.
6scripts/labeler-benchmark/upload-corpora-to-s3.sh copies raw and labelled customer mail out of a gitignored directory to s3://propflow-training-data. It is the one sanctioned path for that corpus to leave the machine, run by hand when the corpus is refreshed, and it deliberately has no npm entry (ruled, and the ruling holds). Its header cites the PII rule. No owner is named anywhere. Keep it?
In plain terms. Should we name an owner for the one approved script that moves our labelled customer email to storage? It should stay, but right now nobody is named as the person who decides when it runs.
Why the raiser recommends it
The session raising this recommends: Keep it, and name an owner It is the only sanctioned route for that corpus and has a real job, but it moves real customer mail off the machine and nothing in the repo or the docs says whose call it is to run — which is the gap the whole row exists to close.
7Eighteen remaining files (13 command-line scripts plus 5 libraries that follow their importer) have a recorded reason for having no npm entry, zero launchd/cron entries and zero fleet references — controls non-zero, so the searches ran. Several are armed on a bare run: demo-loop-harness.ts writes real rows on propflow-prod and pages the PM by email and SMS twice per run; detect-fakes.ts has an INVERTED arm, where writing rows is the default and --dry-run suppresses it. 'No runner found' does not discharge our deletion bar for these. What happens to the set?
In plain terms. Should we make eighteen leftover scripts preview-only first and decide what to keep afterwards? They have no owner and no schedule, and a few write to live data or text a property manager if run by accident.
Why the raiser recommends it
The session raising this recommends: Make them all harmless first Deleting eighteen files on 'we could not find a runner' is the one thing our deletion bar refuses, but leaving them armed means an accidental run writes to production and texts a property manager. Making them harmless is reversible and makes the keep-or-delete call per script unhurried.
8A finished, tested fix to the row fence itself cannot be pushed: the fence refuses it because no board row covers it, and filing that row is refused because filing requires already holding it. Which way out?
In plain terms. Could Gera add one line to the board so a finished safety fix can go out? The gate that stops two workers writing over each other's work can be talked past — it printed a refusal and then reported success, so the write went through anyway. It is fixed and tested both ways, but the gate will not let the fix through without a matching job listed on the board, and it will not let this session create that job either, because creating one needs the job to already exist. Nothing is lost while it waits and nothing is at risk on Gera's side. Shall the one line be sent over to paste?
Why the raiser recommends it
The session raising this recommends: Gera adds the board row The other two cost something real. Naming a row that is not the right one is the exact error the fence's own refusal warns about — it says fencing against a guessed item guards a row nobody is racing in while the real item goes unfenced — and doing it once for a good reason is how it becomes habit. Waiting leaves a tested fix on one machine's disk indefinitely. Adding the row is one line. LIMITS OF MY EVIDENCE: the decider could NOT settle this (ladder did not resolve, no recommendation), so this is my reading, not a ruling. Separately, the hole is live on this box regardless of this fix, because the installed guard is 106 commits behind main — that reconciliation is its own item and also Gera's. The fix itself: dotclaude #268, committed at 361f0af64f64, 1333/1333 and 17/17 both exit 0, with the regression reproduced red-first against pristine main before the fix.
Why, and what was tried
Tried first, unsuccessfully: fable-decide receipt fc396e167 RESOLVED this (Astra answered; Fable's as-given pass timed out, so the order-reversal check did not run). Its ruling was: 'One founder card over all 21: name an owner and cadence, or agree they are deleted.' This card IS that ruled action — it is not an override. Two refinements the ruling did not fix: 28 rows not 21, because the seven tour-decider-replay files are keeps with no nameable runner, the same class as the unknowns, so covering 21 would only produce a second card; and the rows are grouped into 7 calls rather than 28, because 5 library files follow their importer and four groups share one disposition each. An earlier citation pass found no runner for any of the 15 - zero launchd, zero cron, zero fleet wrappers, 10 with zero references, and the five apparent hits dismissed individually, including a header citing an npm key that does not exist. Controls were non-zero (repo docs 605, docs site 219, launchd 73, fleet 1963), so the searches ran.
8d699f3b is parked on this.
24 questions on this
In plain terms. Two questions about commercial buildings that were meant to reach Gera on 8 October and never did. Three separate places record them as sent; neither was ever actually raised, and both pieces of work have sat still since.
0 of 4 answered
1vocabulary.<asset_type> for today's three storable asset types (your ruling b91487292, 'Keep today's four'): what are the default nouns (space, occupant, agreement, charge) for each - in particular, what does a COMMERCIAL building call a unit? Residential and sfh are uncontested in all three options: residential=(unit, resident, lease, rent) and sfh=(home, resident, lease, rent). Only the commercial tuple differs. Decider f1237075f returned NEEDS HUMAN with no recommendation: it was answered by Astra rather than Fable (only one of Fable's two passes came back, so the order-reversal check could not run), and it escalated on the word 'charge'. Three documents say this card was queued; it was never raised, and the noun work has been parked on it since 2026-10-08.
In plain terms. What should Clara call a rented area in a commercial building - a suite, or a space? And should she say tenant, lease and rent there, or occupant, agreement and charge? Residential and houses are already settled.
Why the raiser recommends it
The session raising this recommends: Space, tenant, lease, rent Our commercial type merges retail, office AND industrial (property-type.ts:51), and suite is office-specific - the same design record that proposes suite partitions it as office and bay as industrial, so suite was never the merged-type word. Space covers all three. Tenant, lease and rent are what commercial people actually say; occupant, agreement and charge are our internal field names and would be the first jargon a commercial PM ever heard from Clara. I first recommended suite and changed to space on that industrial point.
2PR #18189 (p9-unit-ask-wiring, part 3a) has been parked as a DRAFT since 2026-10-09 waiting on an attended proof that was recorded as a queued founder card and never raised. The proof: stamp the Test Property with assetType residential, run the armed eval lifecycle on both sides of the change, and send the preview SMS. It is a founder act because it stamps a property and sends a message, and this session is unattended. Meanwhile the PR has gone stale - it is CONFLICTING, and seven commits have landed on handle-create-work-order.ts since it was opened, including #19322 editing the same region, with two more open PRs on that handler. Its last real activity was 2026-10-09. Do you want to run the proof, or should the PR be rebuilt from today's main first?
In plain terms. Should Gera run the waiting test now, or should the mini first refresh the change against todays code? It has sat four days because the request to Gera was recorded as sent and never actually was, and the code it touches has moved on since.
Why the raiser recommends it
The session raising this recommends: Rebuild it off today's main first The proof is only worth what it proves, and the branch it would run against is four days and seven commits behind on the exact file it changes - so a pass could be a pass on code that will not be what ships. Rebuilding costs a review round; running the proof on a stale branch risks proving the wrong thing and needing the proof again.
3Our own test mailbox propflow.ai@outlook.com was signed out of the Test Property's leasing calendar around 2026-09-26, so tours booked there reach no calendar at all. The decision was already settled on receipt f26839e69 (yes, do the two-minute sign-in); only the ACT is a human's, and in nine days nobody has been asked. Will Gera sign it back in? How: signed in to propflowai.co as an admin, open /api/integrations/outlook/authorize?propertyId=appfolio-45&returnUrl=/properties , pick propflow.ai@outlook.com at Microsoft, accept. It writes only the Test Property's calendar connection; no customer is touched.
In plain terms. Will Gera spend two minutes signing our own test email account back into the test building's calendar? It got signed out nine days ago, so test tours book into nothing, and nobody ever actually asked him to fix it.
Why the raiser recommends it
The session raising this recommends: Yes, I'll sign it in It is the single act standing between Phase 10 and its last two rows. The bench receipt for the real calendar provider cannot be produced without it, that receipt gates p10-core-replay, and replay is a conjunct of p10-core-exit, which the phase cannot close without. Four tours PRs (#16676, #16686, #16689, #16692) wait behind the same sign-in. As far as customers go it is inert: one OAuth consent on OUR OWN mailbox, against the Test Property only. The reason to raise it now rather than later is that it was never raised at all - the receipt has sat NEEDS HUMAN since 2026-10-06 with ZERO block rows naming it, verified with a positive control, which is the never-reaches-a-human defect this dock has an open row about. It must be Gera or Fede because it is an interactive Microsoft sign-in on our own mailbox; no agent can click it. Appended here rather than raised as a fourth block because the three-block cap is full and all three are genuinely waiting on him.
4A link names a company the same login also holds, and the active company is a different one. Should opening it switch the active company, or refuse and say why?
In plain terms. When a manager clicks a link to a building at one of their companies while the screen is showing a different one, should Propflow switch them over, or stop and say the link belongs somewhere else? That person is allowed to see both companies either way, so switching takes nothing away — the only reason to refuse is if which company is on screen should feel like a deliberate choice rather than something that moves on its own. This has sat unasked since the first of October, and it is the last thing standing between one whole section of the board and finished. Which does Gera want?
Why the raiser recommends it
The session raising this recommends: Switch the active company The login already holds both companies, so switching grants nothing it did not have — it saves a person who clicked a legitimate link from being refused and then having to find the switcher themselves. Refusing is safer only if the active company is meant to be a deliberate posture rather than a convenience, and that is the part only a founder knows. LIMITS OF MY EVIDENCE: this is receipt f4ede1806 from 1 October, which reached NEEDS HUMAN and was never put to anybody; its follow-up f48bdd4d1 only matters once this is answered. I have not re-measured the code behind it, so the recommendation is a reading of the trade-off, not a ruling. This is the last open row in the UI/switcher group, so an answer clears a whole section of the board.
Why, and what was tried
Model receiptFABLE was asked, and escalated. Receipt f9b49a1ce — NEEDS HUMAN. Both passes agreed on 'C: commercial = space, tenant, lease, rent', and it is being escalated anyway: this question turns on money or a commitment to a person (matched 'charge'), 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 2h21m later saying she had actually asked about the RATE.
The reasoning, which is still worth reading before you decide: Ruling b91487292 (asset-t…
8d699f3b is parked on this.
3
In plain terms. Should the 'wrong company' page have a Switch button on it, or should it just send Gera to the company menu? It happens when someone sends Gera a link to a building that belongs to his other company: the page correctly refuses to open it, and the only question left is how he gets there from that page.
The full question, as raised
The last open row in UI/switcher (ui-s-b). A link names a company the signed-in user also holds, but is not the one they are currently in. It is already settled, and not being re-asked, that a link must NEVER switch companies by itself - decider receipts f4ede1806 and f48bdd4d1 - so the page refuses. The only thing left is where the recovery lives: does the refusal page carry its own 'switch to that company and open this' button, or does it point at the account menu so company switching lives in exactly one place? Astra, on a fresh pass today (fecb35f8d), both orders: 'Gera must choose whether contextual recovery is worth another visible entry point, or whether account-menu exclusivity matters more than the extra navigation. The inspected record does not establish that preference.' Both options are safe; this is taste, which is why it is his. Answering it closes the last open row in UI/switcher and clears that whole section of the board.
Why, and what was tried
The session raising this recommends: Put the switch button on the refusal page Gera's own empty-state rule is what picks it: 'empty state copy is two short sentences - a title, then the next action.' A refusal page is an empty state, and the next action here is switching. Pointing at a menu makes him carry the intent across a hop and then find the building again by hand. It also fits 'less tabs, less things to learn': a button is one thing to read on the page in front of him, where a menu is a place he has to learn. The safety contract is untouched either way, because the button is still an explicit human pick - which is exactly what the active-org route requires at route.ts:20-27 ('an explicit pick is the entire point of the row; it never infers the pick from anything'). What was ruled out is a URL switching for him, not a button he presses. The honest argument against it, and the reason this is not obvious: a pick rewrites the per-user stored selection and clears the selection cookie (route.ts:145-150), so pressing it flips every other tab and device he has open to the other company. ADR-0137 calls that the 'one company's name over another company's money' hazard. That is true of the account menu too - it is a property of switching, not of where the control sits - but on a button someone presses in a hurry it deserves to be said on the button itself. Model receiptFABLE was asked, and escalated. Receipt fecb35f8d — NEEDS HUMAN. ANSWERED BY ASTRA, NOT FABLE — Fable did not answer because only one of its two passes came back, so the order-reversal check could not run.
Gera must choose whether contextual recovery is worth another visible entry point, or whether account-menu exclusivity matters more than the extra navigation. The inspected record does not establish that preference.
(both passes said so.)
What Fable said when it was asked first: as-given: (answered) reversed: timed out after 600s
8d699f3b is parked on this.
Answered and withdrawn (2)
b91932423 Should claiming a new phone number for a building also narrow which buildings the old shared line covers? It is the only way the old line's greeting can stop naming the whole company without someone editing it a second time - but it means a screen in the product would write something we currently only let staff scripts write. — withdrawn
b92131743 Someone sends you a link to a building that belongs to your OTHER company. Should that page have a 'Switch to that company' button on it, or should it just tell you to use the company menu at the top? — withdrawn