---
name: config-change-deploy
risk_class: config_mutation
inputs: [service_name, change_description]
verification: "curl -sf <service_url> (or MCP get_service_status)"
docs_update_checklist: [doc_page, changelog]
---

# Config change + deploy

Goal: change a tracked config repo (Caddy, Gitea customizations, an app's
own repo) and get it live, safely.

1. MCP `preflight` — current health, the service's `config_repo`, its
   risk class, and the verification command to run after. If risk class
   requires approval (`config_mutation` or `destructive`), stop and get
   operator sign-off before editing — see `seeds/policy.yaml`.
2. Clone/pull the `config_repo` (never edit the backend's working tree
   directly — tracked configs change by commit + push, per
   [OIKOS.md](../../OIKOS.md) conventions).
3. Make the change, commit, push to `main`.
4. The Gitea webhook fires the deploy pipeline for that repo (see
   [infrastructure/auto-deploy.md](../../../archive/knowledge/infrastructure/auto-deploy.md) for
   the exact receiver/reload for this service).
5. Run the preflight's verification command. If it fails, check
   MCP `tail_log` for the reload/restart error.
6. No manual record-keeping step needed — mutations made through the API
   (e.g. via the `run` MCP tool) are recorded automatically in the
   `audit_log` table.

Docs-update checklist: update the service's `doc_page` if the change
alters its behavior, ingress route, or ownership; add a changelog entry
if the page has one.