# Protected Files — NEVER overwritten by stack-update

These files contain customer configuration. `exe-os stack-update` MUST NOT
touch them. If a file needs to change, the update should add a NEW file
and log a migration notice, not replace the existing one.

## Config files (bind-mounted, customer-owned after first setup)
- `.env` — all secrets, tokens, passwords (PATCHED, never replaced)
- `gateway.json` — WhatsApp adapter config, account names
- `branding.json` — customer brand colors, fonts, logo
- `clickhouse-config.xml` — ClickHouse memory/log guardrails
- `cloudflared/config.yml` — tunnel ID, credentials, ingress routes
- `cloudflared/*.json` — tunnel credential files

## Data volumes (Docker managed, persist across updates)
- `postgres_data` — all database data (CRM, wiki, graph, raw, gateway)
- `gateway_data` — Baileys WhatsApp auth state (creds.json, sessions)
- `wiki_data` — uploaded documents, workspace storage
- `crm_data` — CRM local file storage
- `monitor_hub_data` — PocketBase data, alert history
- `monitor_agent_data` — agent metrics cache
- `redis_data` — CRM job queue, session cache
- `clickhouse_data` — CRM analytics
- `exe_os_data` — daemon state, SQLCipher memory DB

## What CAN be updated safely
- Docker images (pulled, not built locally)
- `init-db.sql` (only runs on FIRST postgres boot, not on restarts)
- `docker-compose.yml` (can be replaced — it references configs by path)
- Deploy scripts (setup.sh, backup.sh, status.sh)

## Golden rule
If `docker compose down && docker compose up -d` loses customer data
or config, the compose is WRONG. Volumes and bind mounts must survive
any container lifecycle operation EXCEPT `docker compose down -v`.
