Scheduler and local jobs

AI OS uses named scheduler commands so each job has an explicit owner and recovery path.

bun run scheduler:status
bun run scheduler:run
bun run scheduler:agents:run
bun run scheduler:agents:status
bun run scheduler:trend-finder:run
bun run scheduler:trend-finder:status
bun run scheduler:dream:run
bun run scheduler:dream:status

Use the matching :status command to inspect safe status for a scoped job. Status can report that a job has not run yet on a fresh checkout. That is different from a failed run.

Job boundaries

• scheduler:agents:run refreshes host and local agent data.
• scheduler:trend-finder:run refreshes Trend Finder data only.
• scheduler:dream:run runs the review-oriented Dream workflow.
• scheduler:run keeps the compatibility full-aggregate path.

Timer installation remains local machine setup. The scheduler writes private run state and logs outside the public documentation and demo boundaries.

For Linux, AI OS ships validated templates for all four service/timer pairs and a confined renderer that does not install or activate them. Follow Local services lifecycle for the full bring-up, catch-up review, verification, reversible shutdown, and recovery procedure.

State and overlap

Jobs use per-job locks and bounded status summaries. Expected states include first-run, success, warning-only, degraded, failed, timeout, blocked, skipped, and stale-lock recovery. A first-run state means no completed local run has been recorded; it is not a data parse failure.

Scoped jobs preserve unrelated generated branches. The full compatibility job remains available when the operator intentionally wants the complete writer. Do not launch parallel writers against the same generated data.

Cadence

The browser can store reviewed cadence intent for supported jobs, but a saved choice does not prove an operating-system timer is installed. Use the matching status command to inspect the latest actual run. Dream timer installation is documented in the Dream guide.