# Durable changes, cleanup and publication

## Change flow

1. Inspect `guide` and the affected live subject.
2. Check `git_status`; preserve unrelated user changes.
3. Search the canonical checkout and edit the smallest source of truth.
4. Validate syntax and Compose before deployment.
5. Deploy only the affected service unless the requested change genuinely
   spans the core stack.
6. Verify container health and one real function, not just process existence.
7. Update documentation and the container/model inventory when architecture,
   models, ports, modes or ownership changed.
8. Commit and push only after checks pass. Verify the remote result.

Use an asynchronous operator job only once and poll it with
`athena_operator_job`; never launch a duplicate because a long task is quiet.

## Cleanup proof

Before deletion, prove that an item is unused by checking:

- current Compose projects and Docker labels;
- router and controller source references;
- mounts, volumes and model manifests;
- `docs/TESTED_MODELS.md` and any rollback requirement;
- whether a stopped container is an intentional on-demand worker.

Prefer precise targets. Never perform broad recursive deletion from `/`,
`/data`, `/opt` or a variable that was not resolved and printed first. Build
cache can be pruned after confirming no build is running. Do not prune named
volumes or active images generically.

After storage-affecting work, report exactly what was removed and free space,
run the existing manual backup operation, and verify the produced archive.

## Safety and secrets

Never reboot or shut down Athena or alter SSH, networking, WireGuard, firewall,
kernel, boot, partitions or mounts without a separate explicit current user
instruction. Do not print environment dumps, tokens, API keys, private keys or
the contents of `/etc/mike-ai`. Redact accidental secret material from reports
and never commit it.