# Manifests

One `service.toml` per service, grouped by host VM, per `INFRASTRUCTURE.md §2`.

| Directory       | VM            | Plane(s)         | Owner milestone of "real" config |
|---|---|---|---|
| `vm-edge/`      | vm-edge       | Identity + Infra | M2.1 (Keycloak), M3.1 (Infisical), M0.3 (PowerDNS), M2.x (Gitea), M1.2 (proxy) |
| `vm-control/`   | vm-control    | Control          | M5.1 (portal), M4.1 (tenant-registry), M8.1 (ERPNext), M3.2 (Stalwart)         |
| `vm-data/`      | vm-data       | Data             | M6.x (CERTifAI), M7.x (compliance), M4.1 (pg-app)                              |
| `stage/`        | stage         | App plane only   | promotion target of stage builds                                               |

Each file in this directory is currently a **shape-only stub** — fields are set but image references and env wiring will be finalised by the milestone listed in the file header.

## Adding a new service

1. Pick the owning VM per `INFRASTRUCTURE.md §2`.
2. Create `<vm-name>/<service-name>.toml` following the shape of an existing stub.
3. Set `placement.node = "<vm-name>"`, `resources.memory`/`cpu` per the co-tenant budget in `INFRASTRUCTURE.md §6`.
4. Reference secrets as `${secrets.NAME}` — Infisical resolves these. No plaintext values except the Keycloak bootstrap DB URI exception (`INFRASTRUCTURE.md §8 rule 3`).
5. Run `make validate` before pushing.

## Validation

`make validate` parses every TOML and checks required fields (`name`, image OR build OR module, `placement.node`, `resources.memory`). It does NOT contact a running cluster.

`make plan ENV=<env>` merges the base manifest with the matching overlay in `overlays/<env>/` and prints the resulting service definitions. It is a no-op until matching overlays exist for the env.

`make apply ENV=<env>` is gated on a real Orca controller URL — refuses to run until `ORCA_API_URL` is set (lands in M1.2).