skills/vibe-terraform/references/terraform-delivery-audit.md

# Terraform Delivery Audit

## Operation

Inspect the named boundary and report supported findings. Do not edit product code. Include concrete evidence, impact, the owning source, one remediation direction and a meaningful validation route. Severity follows actual impact, not a category example.

## Goal and scope

Audit Terraform ownership from configuration and module contracts through state, plan review, apply serialization, refactor, and recovery.

## Domain invariants

- Each environment has an explicit backend/state identity, access boundary, encryption/retention policy, and locking or apply-serialization mechanism.
- Module inputs, outputs, provider requirements, resource addresses, lifecycle rules, and ownership form a stable public contract rather than leaking environment internals.
- The reviewed plan is generated from the exact commit, variable set, workspace/backend, provider lock file, and credentials intended for apply.
- Destroy, replacement, force-new, unknown, sensitive, and externally managed fields are surfaced explicitly; targeted apply is not used as routine convergence.
- Address refactors use declarative moved/import mechanisms or a reviewed state operation so identity is preserved instead of recreating live resources.
- Provider and module versions are constrained and locked; credentials and sensitive values do not enter code, state outputs, plan logs, or generated artifacts unnecessarily.
- Drift is classified as desired adoption, intentional external ownership, or unauthorized change before configuration is modified.
- Interrupted apply, partial provider success, lock loss, and rollback/forward-fix behavior have an operator-safe recovery path.

## Audit method

1. Map configuration addresses, module boundaries, provider aliases, backend/workspace, variable sources, generated plan, state ownership, and apply identity.
2. Inspect the exact plan for replacements, destroys, unknown values, dependency order, lifecycle suppression, sensitive exposure, and cross-environment references.
3. Compare configuration, state, and provider reality for the selected resources; classify drift without blindly importing or overwriting it.
4. For refactors, prove old-to-new address identity and determine whether moved/import blocks or a controlled state operation is required.
5. Trace CI approvals, concurrency/locking, artifact retention, credentials, failure notification, and recovery after partial apply.

## Priority model

- **P0:** state corruption, destructive replacement, secret exposure, loss of remote ownership, or unrecoverable infrastructure change.
- **P1:** a material plan, provider, module, locking, drift, or rollout defect.
- **P2:** a lower-risk but concrete maintainability, policy, or operator-safety issue.