Add a `terraform` policy to the policy registry

[bkd-dotcom]

What this is

signetry-core ships a policy registry: a directory of YAML files, one per repository
shape, that says which paths an AI agent may touch for a given task and which it may not.
Six ship today (signetry_core/policies/):
python-library, node-service, monorepo-service, docs-only, dependency-bump,
ci-workflow-fix. A Terraform module tree is missing.

This is the highest-leverage thing you can contribute without touching the kernel: one new
file, no Python, and no test to write — tests/test_policy_registry.py is parametrized
over every file in that directory, so your policy is validated the moment it exists.

The deliverable

One file: signetry_core/policies/terraform.yaml. Copy
python-library.yaml
as your starting shape — the # @policy header comments are load-bearing metadata, not
decoration.

A starting point, not a spec to type in verbatim — argue with it, the reasoning is the
contribution:

# @policy id: terraform
# @policy title: Terraform (module tree, validate + fmt, plan-only)
# @policy summary: A Terraform repository. The agent may change module source, variables and docs, and
#   must keep `terraform validate` and `fmt -check` green. State, auto-loaded variable
#   files, the backend and production environments stay off-limits.
# @policy stack: terraform, opentofu, hcl
# @policy author: your-github-handle
# @policy blocks: terraform.tfstate, prod.auto.tfvars, backend.tf, environments/prod/main.tf, .github/workflows/apply.yml
# @policy allows: modules/vpc/main.tf, modules/vpc/variables.tf, modules/vpc/outputs.tf, environments/staging/main.tf, README.md
version: 2
task_type: feature-work

allowed_paths:
  - "modules/**"
  - "environments/**"
  - "*.tf"
  - "*.tfvars.example"
  - "README.md"
  - "CHANGELOG.md"

forbidden_paths:
  # State is the record of what actually exists. Editing it doesn't change
  # infrastructure — it changes Terraform's belief about infrastructure, so the next
  # apply destroys or duplicates real resources while the plan looks clean.
  - "**/*.tfstate"
  - "**/*.tfstate.*"
  - "**/.terraform/**"
  # A *.auto.tfvars file is loaded with NO CLI flag. Changing an instance count or a
  # CIDR there takes effect on the next apply with nothing at the call site.
  - "**/*.auto.tfvars"
  - "**/*.tfvars"
  # backend.tf decides WHERE state lives. Repointing it silently forks state.
  - "backend.tf"
  - "**/backend.tf"
  - "**/backend.hcl"
  # Inside environments/** which is otherwise allowed, so staging stays in scope.
  - "environments/prod/**"
  - "environments/production/**"
  - ".github/**"
  - "**/.env*"
  - "**/*secret*"

max_files_changed: 10
required_checks:
  - "terraform fmt -check -recursive"
  - "terraform init -backend=false"
  - "terraform validate"

policy_owner: your-team
policy_version: "1.0"

The part people get wrong

Your blocks list must include at least one path that sits inside your own
allowed_paths. Carving an exception out of a directory you otherwise own is the whole
skill. For a Terraform module tree that exception is:

environments/prod/** — environments/** is allowed so the agent can iterate on
staging; production is the same file shape with a blast radius that isn't.

The Terraform trap worth a comment in the file

This policy needs a caution:. validate and fmt -check prove the HCL parses
and is well-formed; they prove nothing about what an apply would do. A green required check
here is a weaker claim than a green pytest, and the receipt shouldn't imply otherwise —
say that in caution and signetry init will print it at adoption time. Being honest about
a permissive policy is how ci-workflow-fix got merged.

Acceptance criteria

• signetry_core/policies/terraform.yaml exists; filename matches @policy id.
• blocks and allows each list 3–4 realistic paths for this stack, and don't overlap.
• At least one blocks entry is inside allowed_paths.
• Every forbidden_paths entry that isn't self-evident carries a comment saying why,
  not just that it is. python-library forbids conftest.py at any depth and the comment
  explains it executes at collection time on every developer machine — that is the bar.
• pytest tests/test_policy_registry.py is green. The suite proves each claimed block is
  actually refused by the real evaluate_contract, so a policy that misleads adopters
  fails CI rather than shipping.
• If the policy permits something risky, it says so in a caution: — signetry init
  prints it at adoption time. A risky policy with no caution gets sent back; a risky
  policy that's honest is fine.

Getting started

The full numbered walkthrough, including what makes a policy worth merging, is in
docs/site/policy-registry.md → "Contributing a policy".

git clone https://github.com/Signetry/core && cd core
uv sync
uv run pytest tests/test_policy_registry.py -q
uv run signetry policies          # your entry should appear here once the file exists

Comment to claim it — one policy per contributor so nobody's work gets duplicated. Happy to
review a half-finished scope list; the reasoning matters more than the YAML.