# breakpilot-app

App plane (formerly "Data plane" in the May 18 doc). Two VMs in one cluster:

- **`vm-app-prod`** — production workloads, customer data, real keys
- **`vm-app-stage`** — staging workloads, demo data, sandbox tenant

Becomes its own Gitea repo `platform/breakpilot-app` at migration time.

## Services

### Prod ([`services/prod/`](./services/prod/), 9 services)

| Service | Purpose |
|---|---|
| `admin-compliance.toml` | Compliance back-office admin |
| `ai-compliance-sdk.toml` | LLM-mediated compliance SDK |
| `backend-compliance.toml` | Compliance scanner backend |
| `certifai-dashboard.toml` | CERTifAI dashboard (first product) |
| `litellm.toml` | LLM gateway |
| `minio.toml` | S3-compatible object store |
| `mongodb.toml` | Compliance + CERTifAI data |
| `pg-app.toml` | Per-tenant application Postgres (SPOF — RISK-1 in `§7`) |
| `qdrant.toml` | Vector store (rebuildable) |

### Stage ([`services/stage/`](./services/stage/), 11 services)

| Service | Purpose |
|---|---|
| `admin-compliance.toml` | Stage admin |
| `ai-compliance-sdk.toml` | Stage SDK |
| `backend-compliance.toml` | Stage backend |
| `certifai-dashboard.toml` | Stage CERTifAI |
| `customer-portal.toml` | Stage portal (calls prod KC + prod tenant-registry with `tenant.kind = "stage"`) |
| `litellm.toml` | Stage LLM gateway (may reuse prod) |
| `mongodb-stage.toml` | Stage Mongo |
| `orca-proxy.toml` | Per-node ingress on `vm-app-stage` |
| `pg-app-stage.toml` | Stage Postgres |
| `qdrant-stage.toml` | Stage vector store |
| `tenant-registry.toml` | (placeholder; stage calls prod registry — manifest exists for parity) |

## SLA targets (per `INFRASTRUCTURE.md §6`)

```
Owns:    DATA_RESIDENCY — all customer data (MongoDB, pg-app, MinIO) must stay EU
         RPO (product)  — compliance records ≤ 6h; chat history ≤ 24h
         DATA_ISOLATION — every query scoped by org_id / tenant_id
         AUDIT_TRAIL    — product-level actions
         AVAILABILITY   — CERTifAI ≥ 99.5%; compliance ≥ 99.5%
```

## Why one cluster, two VMs

- **Same orca-platform config, different physical workloads.** Stage and
  prod don't drift on infra config because they're in the same cluster.
- **No "oops touched prod" accidents.** Per-service `placement.node`
  pins which VM each container lands on; prod manifests live in `prod/`,
  stage in `stage/`.
- **Blast radius is physical.** A stage misconfiguration cannot exhaust
  `vm-app-prod`'s memory because they share nothing but the Orca control
  socket.

## Stage isolation contract

Stage services never:
- email real customers (Stalwart accept-rule on `breakpilot-control` drops
  recipients not matching `*+stage@*`)
- trigger real Polar charges (`POLAR_API_URL` points at sandbox)
- carry real customer data (sandbox tenant resets nightly)

Stage services always:
- authenticate via prod Keycloak with `tenant.kind = "stage"`
- read tenant config from prod `tenant-registry` (read-only for stage tenants)
- expose `*.stage.breakpilot.com` (or whatever the staging subdomain is)

See `INFRASTRUCTURE.md §5` for the full stage-prod sharing contract.

## Sandbox tenant

The `sandbox` tenant in `stage/` is the only place that accepts writes
from public demo visitors. A nightly cron (lands as `sandbox-reset.toml`
when seed-data fixtures are wired in M13.1) resets its Mongo collections
and Keycloak user attributes from a versioned seed.