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 #4868 (voice transfer bridge) — close it, or rebase it a third time?
Clara currently improvises a spoken handoff line when she transfers a caller to a specialist. This PR replaces that with a fixed 'One moment.' spoken by the platform on all 7 transfer routes, and deletes the 11 per-route handoff lines from her prompt.
Two things make this your call:
1. Your own ruling on 2026-08-15 — twelve days AFTER this PR was last touched — says 'one moment' alone is the wrong thing to say at a transfer, because it reads to the caller as a WAIT. Main has since added MORE per-route handoff lines (four PRs, newest merged yesterday). This PR deletes all of them.
2. Merging it changes LIVE production voice agents immediately. The merge commit itself pushes the new config to the ElevenLabs agent that answers real tenant calls — no arm, no staging step. Rollback is a revert plus another sync cycle.
The PR is not wrong about the facts: the author timed 162 real transfers and found the specialist picks up in 2 seconds (4 at worst), not the 8 seconds Clara's prompt still claims. So the prompt's stated reason for a long handoff line IS stale. But how a transfer should SOUND is a judgement about the caller's experience, and the data doesn't settle it — you already ruled on it once.
Fable recommends: Close #4868 as superseded by your 2026-08-15 ruling, and salvage its two uncontested pieces into a small separate PR It contradicts a ruling you made after it was written, and the doctrine has been reinforced four times since. Reviving it means a third rebase across five files where main has added 735 lines, plus re-deriving every prompt edit against rules that did not exist when it was authored — that is a rewrite, not a conflict fix. The two genuinely good pieces survive either way and are worth landing on their own: a drift-check fix (right now live 'transfer_message' can drift from the repo and the check passes silently — a real blind spot on main today), and a sync-order fix that prevents a dead-air window. If the 2s finding should change the doctrine, that is its own decision about how Clara sounds, and it deserves to be made on the data rather than smuggled in on a stale branch. Fable was asked, and escalated. Receipt fe5ba5607 — NEEDS HUMAN. Both passes agreed on 'Close #4868 as superseded by the 2026-08-15 owner ruling; salvage the two uncontested pieces (the destFields drift comparator, which closes a real blind spot on main today, and the sync-order fix) into a small separate PR', and it is being escalated anyway: this question turns on money or a commitment to a person (matched 'commit'), which is not Fable'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…
96c0ccfb is parked on this.
2PR #3087 (Temporal namespace sweep, opened July 5) — close it and redo it on cut day, or keep it parked?
This is the oldest open PR. Its own title says DO NOT MERGE until cut day, and cut day hasn't happened — ADR-0045 is still on Step 1 of six.
What it does: renames the Temporal namespace from propflow-renewal-prod to propflow-prod everywhere it's hardcoded. That's Step 5 of the cutover.
Three things you should know before choosing:
1. MERGING IT *IS* THE CUTOVER. Main still points the production renewal worker at the old namespace (deploy-renewal-worker.yml lines 308-309). Merging repoints it to a namespace where the search attributes aren't registered and the schedules don't exist yet — which crash-loops the pipeline. The only things standing between this PR and that are a string in its title and the hold-for-review label. Dropping that label arms auto-merge.
2. IT HAS DECAYED PAST USEFULNESS AS A PATCH. It hasn't moved in 46 days. It touches 38 files; main now carries old-namespace refs in 81. So rebasing it produces a HALF-done rename — arguably worse than none, because main would sit mid-rename with no signal about which half is which.
3. CLOSING LOSES NOTHING. The diff, your comment about not rewriting namespaces inside ADRs, and the reasoning all stay readable and linkable on a closed PR forever. The real cut-day artifact is the ADR and the migration plan, not this branch.
Fable recommends: Close #3087; author Step 5 fresh from current main on cut day, with a pointer left in the migration plan's Step 5 A sweep is cheap to regenerate and expensive to keep half-current — the branch already covers less than half its own target and the gap widens every week. Keeping it open buys reference value it keeps just as well when closed, and in exchange leaves a PR whose merge button is a production cutover guarded only by a label. One thing the fresh authoring must carry that a blind rename would get wrong, and it's your own point from the PR thread: some old-namespace references are deliberate keeps — the migration scripts and the ADR-0045 test name the old namespace as the SOURCE, and rewriting a namespace inside an ADR falsifies the record the ADR exists to preserve. Fable was asked, and escalated. Receipt f3a575878 — NEEDS HUMAN. Both passes agreed on 'Close #3087 and let Step 5 be authored fresh from current main on cut day, with a pointer left in docs/planning/temporal-namespace-migration.md Step 5', and it is being escalated anyway: this question turns on money or a commitment to a person (matched 'renewal'), which is not Fable'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 aske…