Bring existing services into Cella

Current status: later planned migration track; separate from first Service Cell startup and first Channel support.

Adoption transfers an existing systemd, Docker, Compose, or manually managed service into a governed Service Cell. It does not retroactively protect the source process or treat a live-process checkpoint as a reproducible runtime.

Read-only discovery and reviewed plan

Discovery makes no source changes. The plan records executable/artifact, configuration, service account, ports, dependencies, data paths, secret references, health checks, resources, downtime, and rollback limits. Inferred mounts, routes, credentials, and privileges are untrusted proposals.

The user/organization approves the exact plan digest before quiescing. Unattended adoption needs narrow pre-authorization for that service class. Reproducible runtime inputs become a sealed revision; a live host repository is never retained as a mount.

Durable migration and rollback cutoff

The transaction covers discover, plan, approve, quiesce, consistent snapshot, stop, import, start, verify, complete, and rollback. Declared data is copied, moved, cloned, or placed under exclusive Cella ownership as managed volumes; database-specific flush/snapshot procedures establish consistency. Project Secret Sets/Connections replace plaintext environment and credential files without leaking values into Agent Cells, plans, logs, or evidence.

The service is managed only after health, data, network, policy, and Channel verification. Pre-write failures restore the original service without data loss. Once the new generation accepts writes, automatic rollback may be unsafe; later failure must expose the data reconciliation requirement rather than claim lossless rollback.

Evidence binds source identity, discovered facts, plan/policy, approval, quiescing, snapshot, revision, secret/volume references, lifecycle transitions, health, completion, and rollback outcome.

Example: a reviewed systemd collector moves into a Service Cell with consistent data and explicit rollback limits, rather than an undocumented sequence of mounts, secret copies, and process-manager changes.

See service adoption architecture and adoption requirements.