run orcr as a service

orcr server enable registers the server to start at login. this matters mainly for loops: a scheduled loop can only fire while the server is running, so if the machine reboots and nothing runs an orcr command, a loop that was due would miss its fire until the next command auto-starts the server. registering the server closes that gap.

orcr server enable
orcr server disable

• enable registers the platform unit and starts the server.
• disable removes the registration. a running server and the store are left untouched.

per platform

enable writes an absolute-path unit that runs orcr server start --foreground, propagates your ORCR_HOME and ORCR_HERDR_BIN, and redirects logs. it picks the platform for you.

macOS: launchd

creates a launchd agent:

~/Library/LaunchAgents/dev.orchestratr.orcr.plist
  label:  dev.orchestratr.orcr
  argv:   orcr server start --foreground
  RunAtLoad, KeepAlive on crash

Linux: systemd

creates a systemd user unit:

~/.config/systemd/user/orcr.service
  Restart=on-failure

Windows: not yet

Windows support lands together with general Windows support. enable on Windows will create a Task Scheduler logon task (schtasks /create … /sc onlogon); until then, and on any other platform, enable fails with unsupported_platform (exit 2).

verify it

enable echoes the created unit path and the exact platform command to verify the registration. the typical forms are:

# Linux
systemctl --user status orcr.service

# macOS
launchctl list | grep dev.orchestratr.orcr

use the command enable printed; it is the authoritative one for your platform.

next

• manage the server: start, stop, status, and logs.
• schedule work with loops: the reason to register the server.