Start scheduled automations at a random time in a window, like a coworker (GODM-32)

[danielehrhardt]

What does this change?

Scheduled automations can start at a random time within a window, like a coworker who starts somewhere between 8:00 and 9:30 instead of on the dot (GODM-32).

• Trigger: schedule gets an optional startWindowMinutes (0–720). "0 8 * * 1-5" + 90 = weekdays, somewhere between 08:00 and 09:30, drawn anew for every run.
• Scheduler: a routine with a window gets a one-off croner job at the start drawn for its next time slot. When that job fires, the job for the following slot is set up before the run starts.
  • The offset is a hash of the routine id and the slot. The drawn start survives restarts and unrelated edits.
  • A slot whose window is still open when the core restarts still runs.
  • A slot that already ran (latest schedule event, or the slot that just fired) never runs twice.
• Validation: the window may not be longer than the gap between two runs, so a late start can't overtake the next run.
  • The rule is startWindowLimit in @godmode/shared. Core and UI both use it; gaps shortened by a DST change don't count.
  • Edits that leave the schedule alone (pause, rename, prompt) don't check the window again.
• UI:
  • A "Random start time" card sits in the schedule editor, with a switch and chips from 15 min to 3 h. It only offers what the schedule leaves room for, and keeps a non-preset value set by an agent.
  • The summary line reads "Weekdays between 8:00 AM and 9:30 AM".
  • The automation list, overview and search use the same wording. "Next run" shows a shuffle icon and the exact drawn time in its tooltip.
• Godmode agent: the routine_create / routine_update tools and the orchestrator prompt know startWindowMinutes, so "start sometime between 8 and 9:30 on weekdays" can be set up from one sentence. There is a new example to match in the "Describe what to automate" card.
• onTick now refreshes next_run_at for schedules too. Before, a tick skipped because the previous run was still busy left the past time in place.

How was it tested?

• pnpm typecheck: clean. pnpm build:ui: builds.
• bun test in packages/core: 679 pass, 0 fail (after merging main). New tests cover:
  • the draw stays inside the window and is stable per slot
  • an open window survives a restart; handled slots are skipped
  • a schedule event blocks re-running the slot
  • 0 = on time; invalid and too-long windows are refused
  • DST gaps (Europe/Berlin, March 2027)
  • pausing a routine whose window no longer fits
  • the one-off job fires at its drawn time and plans the next slot
  • a reload mid-window after a fire
  • the HTTP route keeps the field
• Live on macOS with core + dashboard on an isolated GODMODE_HOME:
  • An every-minute schedule with a 1-min window fired at the drawn seconds (21:47:49, then 21:48:05), each time planning the next slot.
  • "Weekdays 08:00 + 90 min" drew 09:02:37 Berlin and kept it across a core restart.
  • An hourly schedule with a 90-min window is refused in the API and flagged in the editor.
  • Light and dark screenshots are attached to GODM-32.

Checklist

• pnpm typecheck and pnpm test pass
• cargo clippy / cargo test pass (if apps/desktop/src-tauri changed) — not changed
• API changes are reflected in packages/shared and apps/desktop/src/lib/api.ts
• No secrets, tokens or personal data in code, fixtures, logs or screenshots
• Docs updated where behaviour changed (docs/ARCHITECTURE.md)