Automation Overview

Much of what keeps LisaOS coherent happens when no one is watching. A set of scheduled background jobs runs the recurring protocols — consolidating memory, refreshing indexes, taking backups, monitoring the world — so that each interactive session starts against a current system rather than a stale one.

Two schedulers

Jobs run on whichever substrate suits them:

• The local shell's scheduler (macOS launchd) runs jobs that need the local environment — full-disk access, the local vault sync, the message bridge, and the headless sessions that drive skills unattended.
• The server's scheduler (cron and systemd timers) runs jobs that must survive the local machine being off — the always-on services and the server-side backups.

The two are complementary, not redundant. A job lives wherever its dependencies live.

Describe-by-function

Job identifiers, script locations, service names, hosts, ports, and log paths are deployment coordinates and are withheld by design — this page describes each job by what it does, which is the part that is architecturally interesting. The authoritative operational registry lives in the vault; this is the public shape of it.

Design constraints

A few constraints shape how these jobs are built:

• Headless sessions run non-interactively. Jobs that need LISA's own reasoning spawn a headless shell in an automatic permission mode — no human is present to answer a prompt.
• Best-effort, fail-open. A job that cannot reach the gateway or a dependency logs the failure and exits without blocking; automation enriches the system, it is never a hard dependency of it.
• Bounded retention. Log output and rolling artefacts (security scans, backups) are retained to a fixed depth, not indefinitely.
• GUI-free. Scheduled jobs cannot rely on a foreground application being available; anything requiring a window is out of scope for automation.

See the scheduled jobs catalogue for what actually runs, and vault sync for how the vault and skill set stay consistent across the two doors.