# 0066 — Optional dev-box services use reviewed lifecycle selection

Status: Accepted. Date: 27 October 2026. Extends decision 0065.

Decision 0065 made Zammad the first optional Argo CD service and selected it
through `PROFILES=zammad`. That is sufficient for installation, but the ordinary
deployment path cannot safely infer that omitting a profile authorises deletion.
Keeping a service forever after trying it wastes dev-box resources; removing it
through a full reset also discards unrelated platform data.

## Decision

**The dev-box setup lifecycle owns optional-service selection and removal.**
Pharos DX presents the closed catalogue on the **Dev box** page. The CLI uses the
same controller and catalogue. A selection replaces the target's previous
selection; comma-separated and whitespace-separated profile names are accepted.

Adding a service is an ordinary reviewed setup followed by full deployment.
Removing a service is an expiring destructive review which names the removed
services and requires a separate acknowledgement. Direct `make deploy` may add a
profile, but refuses to remove one.

The removal agent:

1. records maintenance ownership and suspends the root Application and each
   selected optional Application with UID and resource-version tests;
2. rechecks the reviewed inventory;
3. deletes only the optional Application, its namespace, its namespace-owned
   volumes and buckets, and its catalogued edge resources;
4. replaces only the service's database through a short-lived, constrained Job
   using the installed pinned PostgreSQL image; and
5. runs the normal full deployment with the replacement profile selection, then
   requires every selected Application to be healthy and every removed
   Application and namespace to be absent.

The catalogue holds the service's profile, component, Application, namespace,
database, credentials and edge resources. GitOps composition and the DX lifecycle
derive their optional-service contracts from it. Zammad is the first entry.

## Consequences

- A developer can enable Zammad for several sessions and later recover its
  approximately 4 GiB memory allocation without resetting the dev box.
- Removing Zammad permanently deletes its tickets, search index, Redis state,
  uploads and database. Other services, databases and platform storage remain.
- Re-enabling a removed service creates and configures a fresh instance.
- Adding another optional system requires one catalogue entry plus its GitOps
  component and service-specific qualification. The selection syntax already
  supports several profiles.
- An interrupted removal keeps maintenance ownership and can be reviewed again
  from the resources which remain. Unknown finalisers and changed identities stop
  deletion for inspection.

## Cluster-wide dependencies

KServe also uses this selection catalogue, with the `site-agent` Argo project.
Its serving APIs and workloads span Project namespaces, so the service-local
removal workflow cannot safely retire it. The catalogue marks it for retention:
selection removal is refused before mutation, and reset preserves its Application,
namespace and storage. Its separate reviewed uninstall must first retire dependent
workloads. See the [serving guide](../../gitops/manifests/kserve/README.md).