D0019 — Scheduled sessions: not yet, and here is the finish line

[obotclaw[bot]]

You asked to be told when the machine is ready to run itself on a schedule. It is not ready. This page is the finish line rather than an argument for a verdict — five gates, what each costs, who has to do it, and the check you can run yourself to see whether it has been met.

https://jwildfire.github.io/obot.roadmap/reports/decisions/2026-08-16-scheduled-sessions-assessment/

It supersedes D0014 rather than restating it, and it re-derives the answer from live state, because the thing that turns out to matter most was not on any earlier page.

The answer in one paragraph

Not yet. The blocker that dwarfs the others is the host. This laptop suspends when the lid closes, and today it was shut for eleven hours and fifty-three minutes. Inside that window the machine was conscious for about four minutes in total, no agent did any work for nine hours, and the five-minute watcher ran thirteen times instead of a hundred and forty-two — and every time it did run it could not reach GitHub, while still writing a line that read like a healthy sweep. A scheduled run at 3am on this machine would not fail loudly; it would get a few seconds of processor, die on its first network call, and leave a log that looks fine.

The five gates

• Gate one, and it is yours rather than ours: a host that stays awake. Your own words tonight are the fix — "Hopefully moving everything to devoted machine later this week, and then we can really turn on automation." Everything else can be built while you wait; none of it can be proven on a host that sleeps.
• Gate two: hard stops on the routes that destroy things. Fourteen destructive commands were fed to the guard today. It refused one, the merge, and passed the other thirteen — repository deletion, branch deletion, force-push to main, tag and release deletion, hard reset. Cost: one to two agent-hours, ten minutes of your hands for the server-side rules, and your signature.
• Gate three: detection that does not sleep with the host. None of the three checks the closed page called blocking exists. The one check that reads job records ignores, by construction, any job that has not already finished — which is exactly the set that stalls or dies. Cost: about half an agent-day, plus two to three hours to host the morning dead-man check off the machine.
• Gate four: a trigger, and one supervised rehearsal. Nothing anywhere invokes the launcher on a schedule, and no autonomous session has run since 1 August. Cost: an agent-hour or two, plus one evening of yours.
• Gate five: a ceiling on what one night can spend. Today there is a four-hour clock and no cost limit at all. Until now the ceiling was you. Cost: two or three agent-hours; the number is yours.

The questions

• H1 (D0019.1) — does the lane wait for a machine that does not sleep? Recommended: wait, and build gates two, three and five meanwhile.
• H2 (D0019.2) — where does the overnight detection live? Recommended: session-health checks on the host, but the 7am missing-digest alarm moves off the machine entirely.
• H3 (D0019.3) — local guard only, or guard plus branch protection on the branches agents merge into? Recommended: both, server-side first.
• H4 (D0019.4) — what is one unattended night allowed to spend? Recommended: a nightly ceiling you name, enforced by the run parking itself.
• H5 (D0019.5) — operational repos only for week one? Recommended: yes, then widen.

Two corrections, made before publishing

The brief that commissioned this page put the suspension at 08:28:59; that lid-close lasted about three minutes, and the one that stranded the day began at 09:33:59. The session log's apparent eleven-hour gap is twelve — the machine's clock moved from Paris to London while it slept. Neither changes the conclusion, and both are on the page, because D0014 died of the opposite habit.

D0014, D0015 and D0016 are closed, in your words, with each saying what state it was actually in rather than closing all three identically.

---

This discussion was drafted by Claude Code using Opus 5, in an unattended worker session (W0013), and reviewed by @jwildfire.