# ADR 009: Terraform state and static checks

- HTML version: https://robbiepalmer.me/projects/personal-engineering-platform/adrs/009-infrastructure-operations
- Project: Personal Engineering Platform (https://robbiepalmer.me/projects/personal-engineering-platform.md)
- Status: Accepted
- Date: 2026-09-15
- Initiatives: Semi-autonomous Software Development (https://robbiepalmer.me/initiatives/semi-autonomous-software-development.md)

## Context

Selecting Terraform does not answer where shared state lives or how projects
check configuration beyond `terraform validate`. Both concerns recur across
the public platform infrastructure used by the Personal Knowledge Graph,
Recipe Site, Agentic Code Review, and the Work Graph.

## Decision

Require TFLint when Terraform is the selected provisioner. Prefer Terraform
Cloud when a project needs a remote state backend.

The state backend remains a preferred slot because local experiments can use
local state without claiming shared operation. Projects that deploy from CI or
share a state file should activate it.

## Consequences

TFLint catches provider and Terraform conventions before a plan. Terraform
Cloud supplies protected remote state and locking without requiring the
projects to operate another state service.

Projects still own workspace boundaries, credentials, imports, recovery, and
review of destructive plans. The backend stores state; it does not make an
unsafe change safe.

---

Markdown index of this site: https://robbiepalmer.me/llms.txt