Open Mission daemon runtime cleanup and cancellation semantics must be anchored in one daemon-owned runtime supervision model rather than spread across unrelated registries, OS process scans, or log heuristics.
The daemon is the authoritative runtime supervisor for everything started by the Mission product inside the server runtime. That includes Repository-scoped management sessions, Mission-scoped runtime state, Task-scoped live work, Agent executions, mission terminals, Agent execution terminals, and future daemon-started provider or socket resources. Open Mission surfaces remain operator clients; they do not own runtime cleanup policy or runtime relationship truth.
The daemon-owned runtime supervision graph is the canonical relationship model for live runtime ownership. It records which Repository, Mission, Task, Agent execution, and Runtime lease records belong together. Runtime leases cover external runtime resources such as PTY terminals, child processes, sockets, or future provider sessions. A Runtime lease is not only a raw PID or terminal tab label; it carries owner identity, lifecycle, and cleanup responsibility.
Daemon runtime registries may remain separate implementation modules when that is practical, but they must converge on one daemon-owned runtime supervision graph and shared ownership vocabulary. A registry that manages Agent executions, terminals, or future runtime resources must publish enough structured ownership data for the daemon runtime supervisor to answer these questions without surface help or log parsing:
- which Task, Mission, Repository, or system owner currently owns this runtime resource
- which Agent executions belong to a Task or Mission
- which Runtime leases belong to an Agent execution or Mission terminal session
- which cleanup actions are required when an owner is cancelled, terminated, replaced, or reconciled after a crash
Lifecycle operations cascade through ownership, not through UI-specific call chains. If an operator cancels a Task from an Open Mission surface, the daemon must interpret that as a domain lifecycle operation on the Task owner and cascade the required runtime cleanup through the supervision graph. That cascade may include cancelling or terminating owned Agent executions, closing owned terminals, killing owned child processes, releasing owned Runtime leases, and marking resulting runtime state accordingly. The surface requests the Task command; the daemon decides the cleanup fan-out.
Startup recovery follows the same model. Persisted daemon runtime supervision state may exist in the daemon runtime directory as recovery material. On startup, the daemon reconciles persisted Runtime leases and ownership records against the current daemon identity and the OS. If the persisted owner daemon is gone, the new daemon reaps orphaned Runtime leases, clears stale runtime supervision state, and rebuilds live registries. Logs remain audit material and the OS process table remains recovery evidence, but neither is the canonical runtime ownership model.
Shutdown uses authoritative cleanup through the daemon runtime supervisor. Before the daemon releases its runtime lock and socket, it must request cleanup through the runtime supervision graph so daemon-owned Runtime leases are released intentionally instead of becoming orphaned. Best-effort OS process cleanup is part of that shutdown path, but only as execution of the daemon-owned cleanup decision, not as the decision model itself.
This decision does not require a single monolithic class named RuntimeManager. The load-bearing rule is ownership consolidation, not a class name. Mission may use multiple daemon runtime modules internally, but those modules must converge on one typed runtime supervision graph and one cleanup policy owned by the daemon.
Logs stay in their current role from ADR-0006.07 as daemon audit material. Process inspection stays a runtime reconciliation tool. Neither replaces daemon-owned runtime supervision state.
The daemon may publish aggregate runtime supervision counts through the System status snapshot. Those counts are a diagnostic read model over the runtime supervision graph, not a second ownership model.
The daemon may also publish AgentExecutionProcess health derived from the graph and runtime registries. AgentExecutionProcess health describes attachment and communication posture such as attached, detached, degraded, orphaned, protocol-incompatible, or reconciling. It does not replace AgentExecution lifecycle state; it informs commandability, operator diagnostics, and cleanup decisions until semantic state is journaled. AgentExecution-local state must use process, activity, message, health, or Entity vocabulary rather than introducing a second AgentExecution runtime layer; runtime remains reserved for daemon runtime supervision and Runtime leases.