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.
1Four READ-ONLY prod canaries had a live 'propflow-prod' default that the resolve-table fix removed — their documented run commands now exit 1. How should they get their table? (scripts/canary/property-data-integrity-canary.ts, scripts/canary/voice-personalization-no-leak.ts, scripts/integration/email-signature-no-leak.ts, scripts/canary/e2e-test-property.ts)
In plain terms. We're making every admin script say out loud which database it's about to touch, so a message can never again land in the test database while you're staring at the live one. Four read-only health-check scripts used to just assume "the live one" on their own — that assumption is exactly what we're removing everywhere else, but for these four it was the right answer, and the written instructions for running them never say which database to use. So they're broken right now. Option A: update those instructions so whoever runs the check types the database in — strictest, no exceptions anywhere, but anyone following the old written steps gets an error until they relearn them. Option C (my pick): leave the four alone but make them announce "live database" every time they run — they keep working, and the silence that caused the original problem is still gone. Either way nothing gets sent and nothing changes for residents; these four only read.
Fable recommends: C: Route these four through the exemption the PR ALREADY has and already argued — the canary bootstrapEnv pin that overwrites on purpose because a prod canary must hit prod whatever the shell says — and make that pin print. No new exception category is invented. B is mechanically weak: the resolver deliberately does not write process.env and the data layer freezes the table name at import, so B's return value is discarded at these four sites unless you revive the fragile above-imports env write. C reuses a category your reviewer already accepted, keeps the documented commands working, and still ends the silence — which was the actual complaint. Fable was asked, and escalated. Receipt ff040bcfa — NEEDS HUMAN. THE TWO PASSES DISAGREED, AND ONLY THE OPTION ORDER DIFFERED. as-given → 'B: a declared, printed, per-script default in the resolver — ends the silence but keeps a sanctioned default' (medium) reversed → 'A: move the table into the caller — update documented invocations and the doc, canaries refuse loudly when unset, zero exceptions in the rule' (high) An answer a reordering can flip is not an independent judgement, it is position bias wearing one. Escalating with both readings attached.
as-given reasoning: Read PR #5663's body, the doc (lines 52-70), and list-all-properties.ts. Three t… Tried first, unsuccessfully: fable-decide receipt ff040bcfa — NEEDS HUMAN. Asked twice with the options reversed; the two passes DISAGREED on order alone (as-given picked B, medium confidence; reversed picked A, high confidence), which means neither is an independent judgement. Both passes surfaced a real fact the other missed: the as-given pass found the PR already exempts 27 unconditional pins including the canary bootstrapEnv, described in the PR body as 'a loud decision, not a default that pretends to be a safety net' — which is where option C comes from. The reversed pass found that the resolver by design does not write process.env, so option B does nothing at these sites without reviving the above-imports write. Fable could not settle which principle wins: 'no script picks a table on the caller's behalf' (A) versus 'a prod canary must hit prod whatever the shell says' (C).