Task: Generate per-environment plain-systemd units from service_dependency

Systemd becomes the local orchestration substrate for the native/dev deployment mode (Quadlet/podman for remote hosts and decommissioning process_supervisor~/~ores.controller.service are tracked separately – see "Out of scope" below):

• One concrete systemd unit per (service, environment) pair (e.g. ores.iam.service-swift_curie.service), fully resolved at generation time from that environment's own .env – not a template unit instantiated via systemd's %i specifier. An earlier design used %i, including a compound instance name for ores.compute.wrapper's 5 hot replicas, and hit a real systemd specifier-expansion bug when resolving a dependency on that compound instance; see the Notes below for the full incident and why concrete units were chosen instead. ExecStart= points directly at that environment's build/output/<preset>/publish/bin/<binary>; EnvironmentFile= points at that environment's own .env. User-level (systemctl --user), not system-level – matches every other per-checkout dev convention (ports, NATS subject prefix, DB name all already keyed by environment label, and now the unit names themselves). ores.compute.wrapper gets 5 concrete units (-1 through -5) for its hot replicas, each with a literal replica index/host-id/work-dir baked in (all independent, all subscribing to the same NATS queue group – no leader/passive concept needed).
• The generator reads service_definition~/~service_dependency once and renders After=~/~Requires= between the generated units. A per-environment .target (ores-<env>.target) aggregates NATS + every service instance via Wants=, so systemctl --user start/stop ores-<env>.target starts/stops an entire environment (e.g. "swift_curie") in one command. systemctl --user status ores-<env>.target shows the aggregate status of every unit in that environment "for free" (real systemd units, no bespoke status tooling needed); likewise journalctl --user -u 'ores*-swift_curie*' (or a single service's own unit name) gives standard log access with no extra plumbing.
• compass systemd generate renders the units; compass systemd deploy actually installs them into ~/.config/systemd/user/ and reloads the user manager, so the generator is usable end-to-end without manual copy/reload steps.
• Readiness gating: add sd_notify(READY=1) to ores.service's runner right where it already logs "Service ready." (small, idiomatic, no new dependency) so systemd's own After= waits for actual readiness, not just process-start.

• A generator reads service_definition~/~service_dependency and renders concrete, per-environment systemd units for native/local use, with no hand-editing of the output. VERIFIED: 25 units generated for swift_curie (19 singleton services, 5 ores.compute.wrapper replicas, NATS, target).
• compass systemd deploy installs the generated units into ~/.config/systemd/user/ (sync-if-changed, reload only when something changed) with no manual copy/reload step required. VERIFIED live.
• systemctl --user start ores-<env>.target starts NATS plus every service for that environment, in dependency order, confirmed via a real multi-service startup that ores.iam.service-<env> is genuinely active (running) (its own sd_notify(READY=1) received) before ores.refdata.service-<env> (one of its dependents) starts, not just process-launched – confirmed via journal timestamps. stop on the same target stops the whole environment. VERIFIED live: full 25-unit fleet started in one command, stopped cleanly.
• Changing a dependency edge in the DB and re-running the generator changes the emitted ordering, with no code change.
• ores.compute.wrapper-<env>-1 through -5 run as 5 concurrent hot instances, verified via systemctl --user list-units 'ores.compute.wrapper-<env>-*' – all active (running) simultaneously.
• ores.service's runner emits sd_notify(READY=1) at the same point it logs "Service ready.", and a dependent unit's After= genuinely waits for that (not just for the process to start) – verified via real IAM -> refdata journal timestamps (see above); the artificial startup-delay variant of this check was not additionally run.
• systemctl --user status ores-<env>.target shows every service in that environment and its state; journalctl --user -u <unit-name> (single service) and a target-wide equivalent both show that service's real log output, with no separate log-file convention needed on top of what systemd already captures.

• Quadlet/podman rendering for remote hosts (Newton) – tracked as "Generate Quadlet (podman) units for remote hosts from the same dependency graph".
• Decommissioning ores.controller.service~/~process_supervisor – tracked as "Decommission ores.controller.service and process_supervisor", to follow once both the plain-systemd and Quadlet paths are verified.
• The broader resource-management/cgroup-limits work (per-environment Claude slices, compass services onto systemctl, build admission control) – tracked in the sibling story "Systemd resource management and per-environment isolation".

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Shipped compass systemd generate=/=compass systemd deploy (projects/ores.compass/src/systemd_generate.py), rendering concrete, per-environment systemd units from service_definition~/ ~service_dependency – one file per (service, environment) pair, no %i templating – plus sd_notify(READY=1) wired into ores.service's three runner variants (domain_service_runner_impl.hpp, signing_service_runner_impl.hpp, wt_service_runner.hpp) via a new ores.service/service/systemd_notify helper.

All narrowed acceptance criteria verified live against swift_curie: 25 units generated and deployed; every unit started individually (including the 5 ores.compute.wrapper replicas); the full fleet started in one command via ores-swift_curie.target with real dependency ordering (IAM's sd_notify genuinely gating ores.refdata.service's start, confirmed via journal timestamps); a clean stop; the manager healthy throughout the final verification pass. systemd-analyze --user verify on the full generated set: exit 0, no output.

Two real bugs were found and fixed during verification (a shell quoting collision, and systemd's own $VAR expansion intercepting shell-only variables), and a third issue – the actual root cause of a systemd specifier-expansion bug that wedged the systemctl --user manager twice during testing – led to abandoning template units (%i) in favour of the concrete-unit design landed here. Full incident writeup in the Notes above.

Local build clean (linux-clang-debug-make); ctest 73/74 suites passed (99%), 428393/428426 assertions passed. The one failing suite (ores.ore.core.tests, FX exotic-mapper quant tests, 18/478 cases) is unrelated to this change – nothing here touches the quant/analytics domain – and pre-dates this branch.

Out of scope, tracked as follow-up tasks/story: Quadlet/podman rendering, ores.controller.service~/~process_supervisor decommissioning, and the broader per-environment resource-management work (new story "Systemd resource management and per-environment isolation").