Recurring scheduled dispatches — cyberine cron

Cyberine can re-dispatch a task on a schedule. Jobs are persisted in <CYBERINE_HOME>/cron.json (so they survive restarts) and are dispatched as detached background runs (cyberine run --bg) when a cyberine cron tick fires. There is no long-lived Cyberine daemon — the timer is provided by your OS scheduler (launchd, systemd, cron, GitHub Actions, etc.).

cyberine cron add @daily "review yesterday's TODO comments and rank by priority"
cyberine cron add 2h "run a health-check on the API"
cyberine cron add "0 9 * * 1" "weekly dependency audit"
cyberine cron add 09:30 "morning standup summary"

Supported schedule formats:

Manage jobs:

cyberine cron list                       # show id, enabled, schedule, last-run, task preview
cyberine cron pause <id>                 # stop a job from firing (persists)
cyberine cron resume <id>                # re-enable a paused job
cyberine cron disable <id>               # alias for pause
cyberine cron enable <id>                # alias for resume
cyberine cron remove <id>                # delete a job permanently

Run due jobs manually or from your scheduler:

cyberine cron tick                       # dispatch every due job once, update lastRun

Each tick dispatches due enabled jobs via launchBackgroundRun, so they appear in cyberine agents like any other background run. The scheduler itself is external — wire cyberine cron tick into the timer of your choice. Example crontab (every 15 minutes):

*/15 * * * * cd /path/to/project && /usr/local/bin/cyberine cron tick >> ~/.cyberine/cron.log 2>&1

Jobs remember the cwd they were created in; the dispatched run uses that directory so relative paths, .local/runs, and project rules all resolve correctly even when cyberine cron tick runs from elsewhere.

cyberine schedule is the same job store and the same action set (add|list|remove|pause|resume| enable|disable|tick) reachable under a second name; use whichever reads better in a script. The only practical difference is add's default syntax: cron add <schedule> "<task>" is positional, schedule add --at <schedule> "<task>" [--notify] [--webhook <url>] [--retries N] [--backoff-ms MS] is flag-driven with retry/notification options -- but both accept either syntax, since they share one parser. A job added with one name shows up, and can be paused/enabled/ticked, with the other.

cyberine schedule add --at 2h "run a health-check on the API" --notify --retries 5
cyberine cron add 2h "run a health-check on the API" --notify --retries 5   # equivalent

Known limitations: cron list and schedule list render different columns (schedule's table adds kind and retries) and each command's own --help names itself, not its alias -- cosmetic only, never a behavior difference, since both read and write the identical <CYBERINE_HOME>/cron.json.