Everything I could decide myself is decided. What's left needs
you. Each one has a recommendation from Fable — if you agree, pick it and
press Done. "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.
1Local-review found the SAME two defect classes in all 30 open PRs: (1) comments/PR bodies/ADRs asserting a bound the code doesn't deliver — written in the diff, false on arrival, and three of them tell the next reader NOT to fix the thing behind them; (2) guards that assert presence instead of behaviour, staying green after the property they name is gone. Both are mechanically catchable before push. Add a pre-push guard?
In plain terms. Local-review found the SAME two defect classes in all 30 open PRs: (1) comments/PR bodies/ADRs asserting a bound the code doesn't deliver — written in the diff, false on arrival, and three of them tell the next reader NOT to fix the thing behind them; (2) guards that assert presence instead of behaviour, staying green after the property they name is gone. Both are mechanically catchable before push. Add a pre-push guard?
Fable recommends: Add both pre-push checks — grep every changed symbol across the repo (kills class 1), and require each new guard to ship a mutation control that reddens it for the stated reason (kills class 2) Five independent reviewers with no knowledge of each other converged on these two classes, and batch D found four of six PRs were FIXING an instance of one class while shipping a fresh instance of the other — which is what a review lens alone has already failed to prevent, since these are the repo's own lenses. A lens asks people to remember; a guard derives it. Tried first, unsuccessfully: Not delegated to Fable — this came out of the 30-PR local-review sweep you asked for, where five fresh-context subagents each ran the repo's own reviewer definition independently. I did not implement it because it changes the pre-push contract for every session in the fleet, which is a workflow decision rather than a fix.
cc4ad587 (adopted from 9a7a3194) is parked on this.
2Collections now drafts every past-due text to /review and sends nothing until a person approves — that shipped tonight. But the send path has NEVER been executed end-to-end: the only bench property is isTest:true, and the code refuses test properties before any write, so the first time an approved text is actually dispatched it will go to a REAL resident at Camellia. How do you want that first send handled?
In plain terms. Collections now drafts every past-due text to /review and sends nothing until a person approves — that shipped tonight. But the send path has NEVER been executed end-to-end: the only bench property is isTest:true, and the code refuses test properties before any write, so the first time an approved text is actually dispatched it will go to a REAL resident at Camellia. How do you want that first send handled?
Fable recommends: You approve one specific draft to one specific resident, with me watching the dispatch live and ready to halt the cadence — a deliberate first send rather than a routine one Cheapest option that removes the unknown. Option 2 is more thorough but costs a day and a new property in prod data to prove what one deliberately-chosen real send proves. Option 3 is the same first send with nobody watching — identical risk, worse information. Tried first, unsuccessfully: Not delegated. The collections session has restated this gap at every handoff tonight and it is the one thing neither #5492 nor #5506 closes. I verified the mechanism rather than relaying it: appfolio-45 is isTest:true ('The Willows'), and isSimulatedOnlyProperty refuses every isTest property before any write — so no bench run can reach the wire, by construction. Nothing has gone wrong: this is a gap in EVIDENCE, not a defect. The gate itself IS verified live on main — 0 dispatcher imports in collections-chase.ts, send-mode.ts deleted, and the witness type makes calling the sender with an unapproved row a compile error. I would rather name this before the first send than explain it after.
cc4ad587 (adopted from 9a7a3194) is parked on this.