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.
1The nightly job that re-mints the prod login cookie: should it run from your working copy of propflowai, or from a pinned clean copy?
In plain terms. Smith is about to start refreshing the production login cookie by itself every week, so nobody gets paged for it. The one open question is which copy of the code it runs. Right now it would run out of the same propflowai folder you work in day to day — so whatever branch you happened to leave it on is what runs that night. The alternative is a ten-line launcher that grabs a clean copy of the reviewed code first. It costs a bit more plumbing, and that launcher is a file that lives on the mini and never goes through a PR. I'd go with the clean copy: this job writes a real production credential, and the two other nightly jobs that touch this repo already work exactly that way.
Fable recommends: B: add a run-daily.sh wrapper that pins to a fresh origin/main worktree This job WRITES a production credential, and option A runs whatever code is sitting in a folder you edit. The worker justified A as 'the same trade every cwd=_SMITH job already makes' — I checked nightly_queue.py and that precedent does not hold: the _SMITH jobs run Smith's own deployed runtime, and BOTH jobs that run against the propflowai checkout (spine-health, pms-sync-canary) already use exactly this kind of wrapper. The same file documents the failure this invites: on 2026-07-27 turnover-eval silently ran on a 5-day-stale checkout for five nights. Worst part of A is that the script's own self-check is unpinned too, so the 'it would fail loudly' safety net is the very thing that breaks when the checkout is bad. B costs ~10 lines of uncommittable shell and still reads your .env.local, so it loses nothing A gives you. Fable was asked, and escalated. Receipt f7a7154a0 — NEEDS HUMAN. Both passes agreed on 'B: add a ~/.claude/scripts/prod-cookie-refresh/run-daily.sh wrapper — pins to a reviewed origin/main commit like spine-health and pms-sync-canary do, at the cost of unreviewed uncommittable code on disk', 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 missed the correct… Tried first, unsuccessfully: Fable receipt f7a7154a0 (and a second pass, ff678f017) both landed on B, held under reversal. It could not settle it itself: the first pass escalated on a keyword tripwire (it read the word 'commit' as a commitment to a person). Raising anyway because it changes a scheduled workflow on a prod-credential write path and contradicts the worker's own recommendation.
7c954519 is parked on this.
2DEADLINE TONIGHT 9:57pm CT — put the smoke-account password on the mini so this stops needing you?
In plain terms. This one has a clock on it now, so it is a deadline rather than a decision. The production login cookie expires tonight at 9:57pm Central (about 4.5 hours from when I'm writing this), and I checked — nobody has refreshed it by hand today. Nothing automated can beat that: the new code is written and tested but unpushed by your instruction, so tonight's refresh is a manual job either way, and the morning alert will fire. What I'm asking for is the fix for NEXT week and every week after. Smith cannot do the refresh itself without the password for the smoke@propflowai.co test account — it lives as a GitHub secret and GitHub won't hand it back out, so it has to be pasted into the propflowai .env.local file on the mini by hand. One line, no deploy. That file already holds 143 other secrets including that same account's two-factor code, and per our own ADR-0069 the account is a read-only login on the demo tenant with no customer data on it. If you'd rather not, nothing breaks — you just keep doing this by hand every week, which is what today was.
Fable recommends: A: place SMOKE_PASSWORD in the mini's .env.local — next week's refresh happens without you VERIFIED CLOCK: PROD_COOKIES_JSON updated_at is 2026-08-02T02:57:33Z, unchanged as of 22:26 UTC today, so its 7-day life ends 2026-08-09T02:57Z — ~4.5 hours out and nobody has touched it. Tonight is already lost to a manual refresh regardless of this answer; this decides whether next Saturday is too. On the security question the two Fable passes split, so I read ADR-0069 myself: smoke@propflowai.co is a read-only admin on the DEMO tenant with no customer data, worst-case leak bounded to 'that one demo account'. The pessimistic pass had assumed MFA-exemption made it a full prod login; it does not. Its TOTP secret already sits in that same file, so adding the password widens the blast radius by roughly nothing. I cannot do this myself — I have never had the value. Fable was asked, and escalated. Receipt f40d7b7b0 — NEEDS HUMAN. THE TWO PASSES DISAGREED, AND ONLY THE OPTION ORDER DIFFERED. as-given → 'B: leave it out — the job no-ops on healthy nights and reports red when the cookie actually needs refreshing, keeping the human-run chore' (medium) reversed → "A: place SMOKE_PASSWORD in the mini's gitignored .env.local, enabling the automated weekly refresh" (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: The brief's own facts decide it: nothing regresses under B — the red row plus the existing pre… Tried first, unsuccessfully: Fable receipt f40d7b7b0: the two passes DISAGREED with only option order differing — as-given picked B (medium), reversed picked A (high). Position bias, escalated with both readings. The split turned on this credential's blast radius; I settled that myself against ADR-0069 (read-only demo-tenant admin, no customer data), which supports the reversed pass. Raising regardless because placing a credential on disk needs your hands, not mine. Re-raised from b86176327 to carry the expiry deadline in its own text.