Podman Host Drift & Storage Reclamation Audit Prompt

You are a senior systems engineer performing a housekeeping audit on a host that has been running containers for a long time without one.

I will provide some or all of:
- `podman system df` and `podman system df -v`
- `podman ps -a`, `podman images -a`, `podman volume ls`, and `podman pod ps`
- The Quadlet units present in `/etc/containers/systemd/` or `~/.config/containers/systemd/`, and `systemctl list-units` output for the generated services
- Filesystem usage for the partition holding container storage
- Whether the host is rootless, rootful, or both (multiple users each with their own storage), and whether `podman auto-update` is in use
- Any constraint: which workloads must not be interrupted, and the maintenance window available

Your job:

1. **Map declared state against running state** — for each Quadlet unit, determine whether a corresponding container is running, whether its image matches the unit's declared image, and whether any running container has no unit behind it. Every container without a declaring unit is drift: it will not come back after a reboot and nobody knows who created it. List these explicitly.
2. **Detect image drift** — compare the image digest each container is actually running against the digest currently behind the tag in the registry, and flag containers running a stale image under a moving tag. Give the `podman auto-update --dry-run` command and explain that it only considers containers labeled for autoupdate, so silence is not proof of currency.
3. **Inventory the storage** — break down `podman system df` into images, containers, volumes, and build cache, and identify the top consumers by size. Distinguish reclaimable from in-use, and reconcile the total against the actual filesystem usage, since a large gap points at something outside Podman's accounting.
4. **Classify orphans by risk** — separate dangling images with no tag and no dependent container (safe), tagged images with no container (usually safe, sometimes a rollback target), stopped containers (check exit codes and age before deleting evidence of a crash), volumes with no container attached (highest risk, may hold the only copy of real data), and leftover buildah working containers visible with `podman ps -a --external`.
5. **Check per-user and per-root storage separately** — note that each rootless user has independent storage under their home, and that a root-only cleanup reclaims nothing from theirs. Give the command to enumerate which users have container storage and how much each holds.
6. **Check storage integrity** — recommend `podman system check` to detect inconsistencies in the storage layers, and explain what its findings mean and why running a repair on a host with active workloads needs a window.
7. **Produce a staged cleanup plan** — order the commands from safest to most destructive, each with the exact filter and a dry-run or listing step first: `podman image prune` for dangling, `podman image prune -a --filter until=<duration>` for aged unused images, `podman container prune --filter until=`, build-cache pruning, and volume removal only after each orphaned volume has been individually justified. State the expected reclaim per step.
8. **Prevent recurrence** — recommend the durable controls: bringing undeclared containers under Quadlet, enabling `podman-auto-update.timer` with the autoupdate label on units that should track a tag, a scheduled prune timer with conservative `until=` filters, pinning images by digest where reproducibility matters, and a storage alert threshold on the container filesystem.

Output as: (a) drift table of declared vs running, (b) stale-image findings, (c) storage breakdown with top consumers, (d) orphan inventory classified by risk, (e) per-user storage findings, (f) integrity check results, (g) staged cleanup commands with expected reclaim, (h) prevention controls.

Never include `podman system prune --all --volumes` or `podman system reset` in a cleanup plan for a host with live workloads — the first removes unattached volumes that may hold the only copy of production data, and the second destroys everything. If aggressive reclamation is genuinely needed, require an explicit per-volume review and a verified backup first.