Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1Two PRs shipped the SAME maintenance send-gate 21 minutes apart tonight, both held, neither merging. #9978 (branch wo-maintenance-module-gate, +779/-18 over 13 files, covers the tenant work-order ack, the rating prompt and the sync dispatcher, review PASSED) and #9979 (branch fix/maintenance-module-gates-wo-texts, +667/-0 over 29 files, builds ONE shared gate function covering the tenant ack, the rating prompt and the handyman page, review FAILED). Both carry hold-for-review so both read MERGEABLE/BLOCKED and neither can land. Both implement the answer you already gave on b89851802 ('stop the texts now'). The full audit of all 38 outbound lanes is at docs.propflowai.co/a/module-toggles-outbound-audit-2026-09; its central finding is that hand-copied gates drift apart — the two SMS doors already disagree on a renewal opt-out default — so the one-shared-function shape is the recommended one.
In plain terms. Which of the two fixes do we keep? Both were built tonight, twenty minutes apart, for the same problem, and both are frozen so neither is helping anyone. One is tidier and reuses a single check everywhere, but its review is failing. The other passes review but adds a second copy of a check we already have too many copies of.
The session raising this recommends: Keep the tidier one and fix its review The audit's core finding is that copied-by-hand checks drift apart and two of ours already have. The tidier PR is the single shared version; the other adds one more copy. A failing review costs less than a shape we redo. Tried first, unsuccessfully: Ran a three-lane read-only audit of every toggle and all 38 customer-reaching outbound paths before touching anything. Found this duplicate only while checking whether a lane was already building your b89851802 answer, so nothing new was started. I will not pick between two of your own PRs.
bc5e9567 is parked on this.
2Design fork that decides the shape of the whole module send-gate. We have 83 outbound message types; 23 of them belong to NO module — the biggest group being clara_reply / clara_email_reply, i.e. Clara answering a human who just texted her, plus manual_outbound (a person typed it), escalated_thread_ack, the emergency kinds, and the 12 staff pm_* kinds. There is no topic field at any send door and voice carries no message kind at all, so the module cannot be inferred for those 23 — they have to be exempted by name or gated by declaration. Concretely: at a company with Maintenance switched off, a tenant texts 'my sink is leaking'. Today Clara answers. Both open PRs (#9978, #9979) gate the PROACTIVE maintenance sends and leave the reactive reply alone, which is a choice nobody has ratified. Full audit: docs.propflowai.co/a/module-toggles-outbound-audit-2026-09
In plain terms. If a company has turned Maintenance off and one of their tenants texts us 'my sink is leaking', should Clara still reply? Turning the module off clearly means we stop sending them repair updates on our own. It is not clear whether it also means going silent when a resident writes in first. Both fixes being built right now assume she still replies, and nobody has confirmed that.
The session raising this recommends: Clara still answers — the module only stops us starting conversations Silence to someone with a leak is the worst outcome and they texted a number we published. It also matches what both PRs already do, so it ratifies the behaviour instead of changing it late. Tried first, unsuccessfully: Audited all 38 customer-reaching outbound paths and every toggle first, so this is the one question the code genuinely cannot answer. Tried deriving the module from message type, conversation topic and follow-up scenario; all three fail for exactly this group of 23.