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.
1PR #5393 (conversations column picker + selectable "When") is code-clean and green, but its own contract names a data backfill as a SHIPPING PRECONDITION and that backfill has not been run. Un-run, "They last replied" and "We last reached out" render em-dashes for the entire historical cohort and the sort degrades to all-rows-valueless. Nothing in the repo enforces the ordering. How do you want to sequence it?
In plain terms. PR #5393 (conversations column picker + selectable "When") is code-clean and green, but its own contract names a data backfill as a SHIPPING PRECONDITION and that backfill has not been run. Un-run, "They last replied" and "We last reached out" render em-dashes for the entire historical cohort and the sort degrades to all-rows-valueless. Nothing in the repo enforces the ordering. How do you want to sequence it?
Fable recommends: Run the backfill first, then merge — I'll get the backfill run and hold the PR until it's done The PR's own body calls the backfill a precondition rather than a follow-up, and the failure mode is user-visible on the feature's headline columns: every historical row shows an em-dash and the new sort is worthless until it runs. Merging first ships a column that looks broken. Exposure of running it first: the backfill is a prod-data write, so it needs a person either way — that is why this is on the dock rather than something I do. Exposure of merging first: a visibly-empty column for however long the gap lasts, on a surface Sean and PMs actually look at. The reviewer held this at 🟡 for two consecutive rounds for exactly this reason, with the code itself verified clean both times. Tried first, unsuccessfully: No Fable attempt — nothing is broken and nothing needs debugging. All five review findings are verified closed at head, CI is green, and I confirmed the reviewer's one live worry is already mitigated: it wrote 'auto-merge is armed', but auto-merge now reads autoMergeRequest=null with hold-for-review applied, which disarms it (auto-merge-all.yml:468/:503/:397). What remains is purely a sequencing decision about a prod-data write, which is yours by rule — I do not run backfills.
9a7a3194 is parked on this.
2PR #5380 (ADR-0126 first-contact SMS disclosure + ADR-0127 catalog) has run SIXTEEN review rounds and returned 🟡 every single time — 18 bot verdicts, ZERO 🟢. All six original findings are closed and verified, CI is green, and it is CLEAN. The loop is not converging: each round's findings are on the prose the PREVIOUS round added, and the reviewer says so itself. How do you want to land it?
In plain terms. PR #5380 (ADR-0126 first-contact SMS disclosure + ADR-0127 catalog) has run SIXTEEN review rounds and returned 🟡 every single time — 18 bot verdicts, ZERO 🟢. All six original findings are closed and verified, CI is green, and it is CLEAN. The loop is not converging: each round's findings are on the prose the PREVIOUS round added, and the reviewer says so itself. How do you want to land it?
Fable recommends: Merge it on the 🟡 — the six findings are closed, it is docs-only, and the residue is prose Findings per round went 6,4,5,3,4,3,2,3,3,4,3,4 — it PLATEAUS, it does not converge. This is a ~950-line ADR with 8 genuinely-open design questions, so every fix is prose that becomes the next round's surface; a 🟢 may not be reachable by iteration at all. CLAUDE.md says roughly three rounds without a clean verdict means the change needs a human, and we are at sixteen. Exposure of merging: it is DOCS-ONLY (Unit Tests reads 'docs-only change — skipped'), so nothing ships to a customer; the risk is that PR 2 inherits an imperfect spec. Exposure of not merging: the renumber is load-bearing — ~28 live source files already cite ADR-0125 meaning the COLLECTIONS gate, and this branch is what stops a second ADR claiming that number. FOUR findings are open at the final head; ONE is worth closing whichever option you pick — 0126's new warning calls 4,000 the pre-flight's HEALTHY reading while the section it cites says 4,000 means the cold path is INVERTED. That is a factual inversion, not prose. Tried first, unsuccessfully: No Fable attempt — this is not a technical blocker. The work is done and verified: six findings closed, renumber complete with printed grep matches, README row added for the merged collections ADR, fresh non-carried-forward verdict at the exact head. What cannot be resolved by more agent effort is whether a 950-line ADR with 8 open design questions should be held to a 🟢 that sixteen rounds of genuine work did not reach. That is an editorial judgement about a document you own.
9a7a3194 is parked on this.
3PR #5483 fixes a nightly eval false-alarm — a parking-policy case was context-starved (never set the property_policies var it needed), so it read as a Clara regression when it was a broken test. 50 changed lines, one file: evals/datasets/tenant-resident-services.yaml. It can NEVER get a bot verdict — claude-code-review's relevance classifier excludes evals/*, so review skips by design and the workflow says such paths rest on 'author + merger judgment'. Merge it?
In plain terms. PR #5483 fixes a nightly eval false-alarm — a parking-policy case was context-starved (never set the property_policies var it needed), so it read as a Clara regression when it was a broken test. 50 changed lines, one file: evals/datasets/tenant-resident-services.yaml. It can NEVER get a bot verdict — claude-code-review's relevance classifier excludes evals/*, so review skips by design and the workflow says such paths rest on 'author + merger judgment'. Merge it?
Fable recommends: Merge it — a broken eval case that cries wolf is worse than no case The diagnosis is the strong part: the nightly gate fired because tenant-resident-services dropped to 87.5% (7/8, below the 94% gate), and the root cause was reproduced rather than inferred — the failing case never set property_policies, and the eval's prompt bridge only injects policy content when a case opts in via that var. So the eval was testing whether Clara could answer from a policy it was never given. Exposure of merging: it is eval FIXTURE data only — no product code, nothing reaches a customer, and the worst case is the case still fails and we learn more. Exposure of NOT merging: the nightly keeps failing on a false alarm, which trains everyone to ignore that gate — the expensive failure mode, because the next real regression arrives looking identical. NOTE this is the ONLY route: no amount of agent work can produce a 🟢 here, so waiting for one is waiting forever. Tried first, unsuccessfully: No Fable attempt — nothing is broken and nothing needs debugging. The PR author already reproduced the root cause and the fix is 50 lines of fixture data. What blocks it is structural, not technical: evals/* is excluded from bot review by claude-code-review.yml's relevance classifier (the case list at ~:17), so reviewable=false and the review job skips. I verified that by toggling draft→ready myself and watching 'review -> skipped' while 'relevance -> success'. A human merger IS the designed reviewer for this path.