Skip to content

feat(routines): bots ask for routines with schedule_routine - #72

Merged
httpsphl merged 2 commits into
mainfrom
feat/schedule-routine
Sep 30, 2026
Merged

httpsphl merged 2 commits into
mainfrom
feat/schedule-routine

Conversation

@httpsphl

Copy link
Copy Markdown
Owner

Built on top of #70 (its commit is the first one here); merge #70 first with a merge commit and this diff shrinks to one commit.

Problem

Bots could not create Botloft routines (spec 20.10 left it for later), so when the owner asked for something at a set time they reached for Claude Code's own scheduler, which #70 turns off. This gives them the real thing.

Change

  • schedule_routine MCP tool (any bot, not only the chief): name, prompt, schedule (same JSON as spec 20.2), optional bot (handle of another crew bot) and timezone (defaults to the computer's zone, read with jiff, as the app does).
  • Checked like routines.create before the owner sees anything; impossible requests (too often, unknown zone, unknown handle, extra fields) go back to the bot as errors.
  • Approval card in the asking bot's chat: name, what to do, when and "More options", the same fields as the routine editor. "Create routine" / "Not now" with a note. The owner's changes are checked in approvals.answer before the request closes, so a bad schedule is shown on the card in the owner's language and the card stays open.
  • Tool result: what was saved (the owner may have changed it), the zone and the next run in local time. Declined or expired: "Nothing was scheduled: do not say it is."
  • bypass_permissions creates it at once, like suggest_bot.
  • Bot rules: work at set times goes through schedule_routine, the only way to schedule.
  • Spec: new section 20.12, tool table in 10, notes in 10.1 and 10.2; the item leaves "Fora desta etapa".

Tests

  • crates/botloftd/tests/routine_requests.rs: approve, change before approving (a too-frequent change is refused and the request stays open), decline, a routine for another bot plus an unknown handle, impossible requests never reaching the owner, and bypass with the default zone.
  • app/src/features/routines/routineRequest.test.tsx: create as asked, change the schedule, a routine for another bot, decline with a note.
  • cargo fmt, clippy -D warnings, cargo test --workspace and pnpm check pass.

Tested with real Claude Code (2.1.284, Haiku, dev daemon in a separate home)

  • Asked to "have @email check the inbox every weekday at 8", the chief loaded the tool with ToolSearch, called crew_roster, then schedule_routine with bot: "email", weekdays at 08:00. The zone came out as the system's America/Sao_Paulo. After approval, routines.list showed the routine on Email with its next run at 08:00 local.
  • The Email bot, asked the same thing directly, created its own routine (every day at 08:00).
  • The debug log had no message text.

Manual check in the app

  1. Ask any bot to do something at a set time.
  2. Approve the card, once as it came and once after changing the time.
  3. The routine should appear in the bot's Routines tab.

Asked to check something every day, bots called CronCreate. That job
lives only in the bot's process: it dies on a restart, expires in 7 days
and never shows in the Routines tab. Bots now run with --disallowedTools
for CronCreate, CronDelete, CronList, ScheduleWakeup and RemoteTrigger,
and their rules send the owner to the Routines tab instead.
A bot asked to do something at set times now calls schedule_routine:
a name, what to do each time and when, for itself or, by handle, for
another bot of its crew. The daemon checks it like routines.create
before the owner sees it; the owner gets a card in the bot's chat with
the same fields as the routine editor, may change them and creates or
declines it. Changes are checked again before the request closes, so a
bad schedule is worded on the card and it stays open. A bot that
bypasses permissions creates it at once. Without a zone, the computer's
zone is used, as in the app.
@httpsphl
httpsphl merged commit ff2d461 into main Sep 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant