🎯 Change
Today a cezar task can only be started by hand. A user who wants recurring local maintenance — triaging new issues every morning, sweeping stale PRs each weekday, drafting a release report before a release — has to press Start task every time, or move the work out of cezar into an OS cron entry, a GitHub Action, or a long-lived monitoring agent.
The request: let me point an ordinary task definition (prompt + workflow/skill + runner/model + variants + autonomy) at a schedule I define — "every weekday at 08:00 Europe/Warsaw" — and have cezar create the run itself when it becomes due.
Reported by the maintainer as the live half of #771: one-time postponement is already in flight on #846, recurrence has no implementation and no open PR.
📋 Scope
Implement .ai/specs/2026-08-01-recurring-tasks.md on top of the postponed-task foundation from #846. Recurrence is an added recurring timing discriminant on the existing scheduled-task definitions — one coordinator, one occurrence model, one ordinary RunManager.startRun/startVariants launch path, one Scheduled management surface. No second scheduler, store, or route family.
Spec Phase 1 (daily + weekly, end to end) ships and is verified before Phase 2 adds bounded minute/hour/month cadences and hardening; the spec's Implementation Plan steps 1–12 are the execution order.
Explicit non-goals, from the spec: running while cezar is stopped; OS cron/launchd/systemd, another daemon, or a hosted scheduler; raw cron text, RRULE, or natural-language timing; replaying every missed occurrence or promising an exact wall-clock start; per-schedule allow/replace concurrency; reusable browser-uploaded attachments; GitHub event filters (Automations, #670, stays a separate capability).
✅ Done when
- A daily or weekly schedule can be created, saved, paused, resumed, run now, edited, duplicated and deleted, with a plain-language summary and a preview of the next five exact instants produced by the same server calculator that executes them.
- A due occurrence launches as an ordinary run through
RunManager, so workspace/per-project capacity, worktrees, run persistence, review gates and provider degradation stay authoritative — and the occurrence links bidirectionally to the run or variant group it created.
- Occurrence history records
launched, skipped-overlap, catch-up, configuration-error and launch-error with a reason.
- Cost safety is proven by test, not by prose: after downtime at most one catch-up occurrence for the latest missed time; a schedule never overlaps itself (fixed skip policy, including a prior occurrence parked at review); cadence bounds enforced (daily 1–365, weekly 1–260; then minute 15–1,440, hour 1–168, month 1–120 on day 1–28).
- DST is covered by fake-clock tests: a nonexistent local time advances to the first valid instant after the gap; an ambiguous repeated time runs once, at the earlier instant.
- Crash and restart reconciliation can neither duplicate nor lose a launch (durable pre-launch receipt), and missing, corrupt or read-only project state still boots and degrades with a clear local-write message.
- Protected surfaces unchanged:
POST /api/v1/runs, immediate New task, /new deep links and bookmarklets, workflow YAML, skill Markdown, GitHub Automation wire shapes. No new required config, daemon, or CEZ_* variable.
- Configured validation gate green, plus real-browser evidence for the daily/weekly journey.
📝 Spec
Both spec files currently live only on #770's branch spec/scheduled-tasks; they reach main when that PR merges.
⚠️ Open questions
🎯 Change
Today a cezar task can only be started by hand. A user who wants recurring local maintenance — triaging new issues every morning, sweeping stale PRs each weekday, drafting a release report before a release — has to press Start task every time, or move the work out of cezar into an OS cron entry, a GitHub Action, or a long-lived monitoring agent.
The request: let me point an ordinary task definition (prompt + workflow/skill + runner/model + variants + autonomy) at a schedule I define — "every weekday at 08:00 Europe/Warsaw" — and have cezar create the run itself when it becomes due.
Reported by the maintainer as the live half of #771: one-time postponement is already in flight on #846, recurrence has no implementation and no open PR.
📋 Scope
Implement
.ai/specs/2026-08-01-recurring-tasks.mdon top of the postponed-task foundation from #846. Recurrence is an addedrecurringtiming discriminant on the existing scheduled-task definitions — one coordinator, one occurrence model, one ordinaryRunManager.startRun/startVariantslaunch path, one Scheduled management surface. No second scheduler, store, or route family.Spec Phase 1 (daily + weekly, end to end) ships and is verified before Phase 2 adds bounded minute/hour/month cadences and hardening; the spec's Implementation Plan steps 1–12 are the execution order.
Explicit non-goals, from the spec: running while cezar is stopped; OS cron/launchd/systemd, another daemon, or a hosted scheduler; raw cron text, RRULE, or natural-language timing; replaying every missed occurrence or promising an exact wall-clock start; per-schedule allow/replace concurrency; reusable browser-uploaded attachments; GitHub event filters (Automations, #670, stays a separate capability).
✅ Done when
RunManager, so workspace/per-project capacity, worktrees, run persistence, review gates and provider degradation stay authoritative — and the occurrence links bidirectionally to the run or variant group it created.launched,skipped-overlap,catch-up,configuration-errorandlaunch-errorwith a reason.POST /api/v1/runs, immediate New task,/newdeep links and bookmarklets, workflow YAML, skill Markdown, GitHub Automation wire shapes. No new required config, daemon, orCEZ_*variable.📝 Spec
2026-08-01-recurring-tasks.md2026-08-01-postponed-tasks.mdBoth spec files currently live only on #770's branch
spec/scheduled-tasks; they reachmainwhen that PR merges.Recurringchoice live? The spec puts it on the New task composer's clock pill next toNowandLater. feat(scheduled-tasks): implement one-time postponed tasks (Phase 1 of #771) #846 deliberately did not touch the composer (to keep the immediate-submit path,/newdeep links and bookmarklets untouched) and asks in its own description whether composer integration should be a follow-up PR. Assumption applied autonomously and not yet human-confirmed: ship recurrence in the Scheduled editor, matching feat(scheduled-tasks): implement one-time postponed tasks (Phase 1 of #771) #846's shape, and add the composer pill only when composer integration lands. Confirm before spec step 5.