Files
platform/todo/infra/opm-officer-s-own-process-manager.md
T

1.9 KiB

id, title, theme, status, created, date_source, order
id title theme status created date_source order
infra/opm-officer-s-own-process-manager OPM — Officer's own process manager, or at least its own PM2 infra open 2026-08-21 stated 0

OPM — Officer's own process manager, or at least its own PM2. Raised 2026-08-21. Taken as: give Officer's processes a manager of their own, named OPM, rather than sharing one daemon with whatever else lives on the host — worth doing for separation of concerns alone, even without any new capability.

The argument is that Officer is now a fleet of processes, not a process. pm2 jlist counts 13 officer entries on officer-dev and 19 on alpha (verified 2026-08-21), and every one of them is a peer of the server rather than a child of it. They are managed today by a generated ecosystem.config.cjs (bun run gen:ecosystem) on a PM2 daemon that belongs to the login user, not to Officer.

What sharing costs, all of it already written down in CLAUDE.md: pm2 restart ecosystem.config.cjs bounces every sidecar including the vault, so the safe habit is --only <name> and the unsafe one looks identical; a pm2 list mixes Officer's processes with other projects' and the rule "nothing here should touch them" is a convention rather than a boundary; and the documented list of entries goes stale every time a sidecar lands, because nothing owns it. Note the foreign-process case is host-dependent — mybiblepal-api and mybiblepal-audio are named in CLAUDE.md as sharing this daemon, and neither is running on officer-dev or alpha today.

Open, and the owner's call: whether OPM is a genuinely new supervisor or PM2 kept underneath with its own daemon, namespace and CLI wrapper — which would buy the separation at a fraction of the cost, since the ecosystem.config.cjs generation, the naming convention and the restart discipline all already exist.