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.
1Confirmed PII exposure on propflow-stage: 8 un-anonymized production rows (4 real tenant phone numbers, 2 real gmail addresses, 1 person row, 1 prospect-email row) readable on the shared non-prod table since 2026-05-18. Remediation sequencing, and is it reportable?
In plain terms. Some real tenant contact details have been sitting in our test environment since May — four phone numbers and two email addresses belonging to actual Camellia people, plus two related records. They should have been scrambled into fake ones on the way in, and weren't. Our own checker has been flagging this the whole time and nobody saw it. Nothing outside the company can reach it, but more people can see the test system than can see the live one. I can delete them today, which stops it immediately and loses nothing, since the real records still live in AppFolio. The proper repair afterwards is a job the pipeline owner runs. What I can't decide for you is whether this counts as an incident you'd want to write up.
Fable recommends: Delete them today, then have the pipeline owner do the proper repair Stopping it does not need to wait for the permanent fix, and deleting costs nothing: AppFolio and the live table are still the record, and I have already written down exactly what was there, so we keep the evidence without keeping the exposure. It has been three months. I am deliberately NOT choosing between deleting quietly and writing it up, because whether this is reportable is your call about the company, not an engineering question. One warning for whoever does the permanent repair: do NOT make the cleanup tool treat these rows as deletable by removing its provenance exemption. That would make it treat the entire mirror as deletable and wipe about 129,000 rows. The exemption is correct. Tried first, unsuccessfully: No valid verdict on my side: my fable-decide run errored (receipt fd36889fe) and correctly refused to report from a single surviving pass. The other operator holds a valid receipt f1ef49a6f which settled only the FACTUAL half (the leak is real, matched against prod), not the remediation sequencing I am asking about.
464b7b84 (adopted from 3d35fe0d) is parked on this.
2Prod cookie jar expires Aug 27 12:13am CT — the automated nightly refresh has been correctly refusing to run for at least 4 nights because SMOKE_PASSWORD is missing from the mini's .env.local. Who supplies the value?
In plain terms. The nightly robot that keeps your login-cookie fresh for the compliance checker needs a password that's only stored in GitHub's locked secret vault. Someone already decided a week ago to copy that password onto this machine so the robot could do it automatically — but it never actually got copied over. Cookie expires in about 23 hours; either paste that password onto the mini, or do the usual manual browser-login-and-copy-the-cookie routine one more time.
Fable recommends: Place the real SMOKE_PASSWORD (same value as the propflowai repo's SMOKE_PASSWORD GH Actions secret) into ~/code/PropFlow/propflowai/.env.local on the mini — the nightly prod-cookie-refresh job then self-heals with no further action This exact fix was already decided once (b86228042, answered 2026-08-19: 'place SMOKE_PASSWORD in the mini's .env.local — next week's refresh happens without you') but the file's mtime (Aug 17 08:59) shows it was never actually written — the job has been silently, safely refusing every night since (it detects the missing secret and refuses to sign in rather than risk locking the shared smoke account), so this closes the loop for good instead of buying one more week of manual /browse runs Tried first, unsuccessfully: Investigated the alert end-to-end: confirmed the automated prod-cookie-refresh job ran every night since PR #5634 merged (2026-08-21) and self-diagnosed the exact cause each time (signInReady() in refresh-prod-cookies.ts refuses cleanly with 'SMOKE_PASSWORD is not set'); ruled out the #6130 2FA-cookie bug (irrelevant — smoke@ is MFA-exempt); confirmed SMOKE_PASSWORD is absent from the mini's .env.local (grep + file mtime Aug 17, before the Aug 19 decision) and is not recoverable from AWS SSM/Secrets Manager (only exists as a GH Actions secret, which is write-only) or from my own tool access (no /browse skill available to this session). Did not attempt a live sign-in — the script's own comments warn a bad-password attempt risks a lockout on the shared prod smoke account, and I have no way to supply a correct one.
464b7b84 (adopted from 5f2d1ada) is parked on this.
3Camellia's carrier registration describes maintenance texts, not rent. Fix it (the line goes dark while it re-reviews) or close it and accept the mismatch?
In plain terms. The phone number Camellia texts from is registered with the carriers, and that registration is approved — but it describes maintenance messages and never mentions rent. We have now sent a rent text on it and it went through fine, and renewal messages have been going out on it for months under the same description. To make the paperwork match reality we would have to delete the registration and file it again, and while it is being re-reviewed that number cannot send ANY texts — maintenance and work orders too, not just rent. So the safe-sounding option is the one that costs something. My recommendation is to leave it and accept the mismatch.
Fable recommends: Close it — accept the mismatch. Nothing changes, the line keeps sending. The resident-facing disclosure is already correct and live, outbound renewal traffic has ridden this same number under this same summary for months, and the first real rent text delivered clean with no carrier error. Fixing it is the only action here with a guaranteed cost — every text from that number stops, maintenance and work orders included, for as long as the re-review takes. Tried first, unsuccessfully: I read Twilio's own onboarding guide rather than trusting my earlier claim, and it reversed my advice: there is NO edit-in-place for an approved toll-free verification, so changing the use case or the opt-in flow means delete-and-resubmit, and a resubmitted number sits in Pending — which cannot send at all — at the back of the review queue. Content changes need no resubmission. I also confirmed the registration is genuinely approved and that the mismatch is real: the summary describes inbound maintenance help and never mentions rent, and the opt-in is declared as a web form when the real source is the number the resident gave the property. What I cannot tell you is how a carrier would treat that mismatch if a resident complained — only the toll-free aggregator can answer that.
464b7b84 (adopted from a7390069) is parked on this.
4Four nightly jobs are not failing — they are NOT SCHEDULED, and have not run since July. You answered decision b87721567 with 'Drive all four to green now', but that answer was given when we all believed they were running and failing. VERIFIED on the mini just now: turnover-eval-daily, maintenance-eval-daily, morpheus-nightly-daily and git-hygiene-main-drift have ZERO plists in ~/Library/LaunchAgents (37 exist, none match), ZERO entries in launchctl list (25 propflow jobs loaded, none match), and no crontab lines. Their local logs simply stop in July — consistent with not running, not with failing. The fifth, graphify-refresh-daily, is a Temporal Cloud schedule (tools-prod) I cannot reach from here, so it is genuinely unknown rather than confirmed either way. Why I did not just reinstall them: they hit the prod bench (appfolio-45), post to Slack, and spend model tokens every run — your named 'name the risk and wait' class — and descheduling can be deliberate here, since the registry marks marketing-daily 'SUPERSEDED, plist exists but is not loaded'. Do you want these four back on a schedule, or were they retired?
In plain terms. Do you want four nightly jobs put back on a schedule, retired, or some of each? They have not run since July — not failing, simply never scheduled. You said earlier to drive them all to green, but that was when we believed they were running and failing. Putting them back means nightly runs that write to a live test property, post to Slack and spend model time.
Fable recommends: Reinstall all four on their registry schedules — they were meant to run and quietly fell off (RECOMMENDED if they are still wanted) Only as the most likely intent, not as something I should have done unasked. Each still carries a registry row with a concrete schedule and log path, which is what a LIVE job looks like — a retired one gets marked SUPERSEDED the way marketing-daily was. So the evidence leans toward 'fell off' rather than 'retired'. But the cost runs the other way: reinstalling four decommissioned jobs means nightly prod-bench writes, Slack posts and token spend someone then has to notice and unwind, while asking costs one round-trip on jobs already dark seven weeks. The lesson underneath is worth more than the fix: a job whose only voice is its own log is invisible the moment it stops. That is the same shape as the reviewer-token pipeline's 'cycle done' canary, which exists because dead things do not speak. Tried first, unsuccessfully: Fable RESOLVED this (receipt ff838188e, held under option reversal, high confidence both ways) and its resolution was itself 'surface the finding and let Gera decide — the premise of his answer changed'. So this raise EXECUTES that recommendation rather than overriding it; there is no disagreement to record. Fable's two reasons: (1) Gera's own global rules name cron schedules and infra blast radius as the one exception to drive-by-default, and installing four launchd jobs that hit a prod bench, post to Slack and spend tokens nightly is that class; (2) the registry itself shows descheduling can be deliberate — marketing-daily is marked 'SUPERSEDED, plist exists but is not loaded' — so these four may be retired rather than broken, and only Gera knows intent. It also noted his 'drive to green' consent was consent to FIXING RUNNING JOBS, not to re-creating schedules. What Fable tried before landing there: it re-verified the plist/launchctl/crontab counts independently and checked the registry for prior-art on deliberate descheduling.
464b7b84 (adopted from 592da2d2) is parked on this.
5The mini kernel-panicked on 2026-09-01 at 13:06 after 81 hours up: 88 Claude Code sessions held 114.8 GB on a 64 GB machine, free memory hit 14.9 MB, and the pageout path reclaimed 23 of the 3,090 pages it asked for, so watchdogd could not check in and the kernel panicked deliberately. Session memory grows with context (fresh ~157 MB, mature ~1.6 GB), so the real ceiling is ~35 mature sessions and nothing today reaps or caps them. host-headroom (local-bin#58) now samples the host every 300s and shows it on /agents?tab=Systems, but it deliberately only measures. How should session lifecycle be enforced?
In plain terms. The mini crashed on September 1st because too many Claude sessions were running at once and between them they used up all of its memory — it had to restart itself. Nothing is stopping that from happening again. The safest fix is to refuse to START new sessions once we are near the limit, which never interrupts work already in progress; the trade-off is that finished sessions sit around holding slots until someone clears them. The alternative is letting the machine automatically close sessions it judges to be idle — tidier, but it has mistakenly shut down live work before, so it would be killing work on its own judgement rather than yours.
Fable recommends: Cap only: refuse to start new sessions beyond a concurrency ceiling (~35 on this hardware), never killing a running one A refused start is reversible; a killed session's context is not — and ADR-0003 puts worth-continuing judgements at rung 3, not in a reflex. On 2026-08-08 this fleet's own idleness detection misread a transient probe failure and retired 7 of 10 loops whose tasks were still active, so an automatic reaper is the option with a measured history of killing live work. Known cost if wrong: the cap counts sessions rather than bytes, so a few unusually large ones could still exhaust RAM, and lingering finished panes will hold slots until someone clears them — both are visible on the Systems tab and tunable without reversing the decision. Tried first, unsuccessfully: OVERRIDING A RESOLVED ROUND, DELIBERATELY. fable-decide ran two reversed-order concurrent rounds (receipt f52fec659) and came back RESOLVED, not NEEDS HUMAN, recommending 'Cap only' — its reasoning is adopted verbatim as the recommendation above, including its stated cost-if-wrong. Raising anyway for two reasons: (1) Gera asked for this as a decision page in conversation on 2026-09-01; (2) it sets policy over whether running sessions may be killed, which is his standing reserved class (changes touching running sessions, cron schedules, and destructive writes are his call, not driven autonomously), and Fable's own answer leans on that same rule. So this is a policy ratification, not a question Fable failed to settle.