D0014 — Scheduled sessions: go, after three fixes (corrected)

[obotclaw[bot]]

Decision artifact D0014: https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-15-scheduled-sessions-readiness/

The question: you asked what still has to happen before the scheduled (nightly-trigger, no-human-launch) session lane turns on next week. The artifact answers from the last 24 hours of live failures — each traced to what it would do to a run nobody is watching at 3am.

Recommendation: go — enable late next week, gated on four blocking fixes plus one supervised end-to-end rehearsal. About one agent-day of building and ~10 minutes of your hands.

• S1 — turn it on next week? Recommended: yes, gated on the four fixes. The guardrails on what a run may write held and were re-tested live (including a dry-run proving a clinical release branch still demands your approval); what is missing is everything around a run that fails.
• S2 — approve the unsticking batch? The permission lines (held on your local blockers list), your sign-off line on the blocked guardrail-hardening PR, and a standing deny-then-park rule so a denied unattended write parks with a digest instead of stalling unrecorded. Recommended: approve all three as one fix.
• S3 — the overnight watchdog? Extend the proven Navigator sweep: overnight session health, scheduled-workflow conclusions in all seven repos (the demo-study pipeline has been red and silent for twelve days — the exact blind spot), and a 07:00 missing-digest dead-man check. Recommended: build it; no overnight phone pushes in week one — every remaining overnight outcome is a safe stop that keeps until morning.
• S4 — first scope? Recommended: operational repos only for week one, widening to the clinical libraries' working branches after one clean watchdog week.

"Recommendations approved" is a complete answer; any single S-number works too (e.g. "S3 approved, but push to my phone on X").

---

This comment was drafted by Claude Code using Fable 5 and reviewed by @jwildfire

[obotclaw[bot]]

Correction — one of the four fixes is withdrawn

The most alarming thing in this summary was not true. The page said the permission layer had refused the agents' own sanctioned merge command in every form, and had also blocked the agent from writing down that it happened. That is what made "unstick the lanes" the first blocking fix, and what made permission gaps the evening's focus.

It does not reproduce. Four agents have now re-run those commands independently and none was refused. This morning's run, done specifically to check the page rather than trust it (06:03–06:07 local, before anything was edited):

• The merge tool's check mode, in all four ways an agent might type it — plain, relative, absolute, under an explicit shell — ran every time, no prompt.
• A live dry-run against the open clinical release candidate answered correctly and instantly: your approval required.
• The blocker-log write ran and reported the ledger clean; the session capture line ran directly and its line is in today's file.

The real obstruction was an ordinary merge conflict. It was resolved, and the work merged last night.

Where the wrong claim came from

One agent, mid-afternoon on 15 August, reported four denied attempts and two blocked recording paths. That was relayed onward as fact and written onto the page as fact. Nobody re-ran the command before publishing — it was never treated as a claim. The claim is retracted in public on the page rather than quietly deleted, with the two ledger rows struck through in place and what actually happened beside them.

What still stands: the earlier finding that one particular spelling of the merge command sits outside the allowlist and is refused about two times in three. Real, bounded, already recorded. The error was escalating that to "every sanctioned form" in a single relay.

What changes for you

• Verdict is now: go — gated on 3 blocking fixes + 1 rehearsal, not four.
• Your hands-on cost drops from ~10 minutes to one sign-off line (Fix 3).
• S2 has changed what it asks. It no longer asks you to approve permission edits — those are unnecessary. All that is left of it is whether the deny-then-park rule is worth building; the recommendation is yes, but as a nice-to-have rather than a precondition.
• S1, S3, S4 are unaffected. Fixes 2, 3 and 4 keep their numbers so yesterday's references still resolve.

One thing you should know before answering S1

The work that was wrongly reported as stuck did something real. The merge tool now reads what a pull request changes, and forces the lane that needs your recorded sign-off whenever a guardrail file is touched — or whenever its own copy of the rulebook differs from the published one. Nothing was loosened to achieve it: the fixed table of all thirty lane verdicts is identical before and after, re-run this morning.

The consequence: that was the last guardrail change that could merge on the routine lane. Every future one needs your approval — including Fix 3 on this page. An overnight run that concludes the guardrails need adjusting can no longer adjust them; it has to stop and write you a question. Worth knowing before you decide about unattended nights, rather than discovering it in a morning digest.

Full correction, with the run log and the struck-through ledger: https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-15-scheduled-sessions-readiness/

---

This comment was drafted by Claude Code using Opus 5 and reviewed by @jwildfire