If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/hashicorp/terraform shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit today
• 11 active contributors
• Distributed ownership (top contributor 27% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live hashicorp/terraform repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/hashicorp/terraform.

What it runs against: a local clone of hashicorp/terraform — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in hashicorp/terraform | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of hashicorp/terraform. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/hashicorp/terraform.git
#   cd terraform
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of hashicorp/terraform and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "hashicorp/terraform(\\.git)?\\b" \\
  && ok "origin remote is hashicorp/terraform" \\
  || miss "origin remote is not hashicorp/terraform (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/hashicorp/terraform"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Terraform is a declarative Infrastructure as Code (IaC) tool written in Go that enables users to define, preview, and manage cloud and on-premises resources through HCL configuration files. It solves the problem of infrastructure management at scale by providing execution plans, resource graphs for parallel provisioning, and version-controlled infrastructure definitions that work across 1000+ providers including AWS, Azure, GCP, and Kubernetes. Monolithic Go application with clear internal package structure: internal/backend/* for state storage backends (azure, consul, gcs, cos), internal/ for core logic. Configuration is written in HCL (33KB present) while shell scripts and Makefiles handle build/test orchestration. The .changes/ directory uses a structured changelog system (YAML per version/change-type) rather than a flat CHANGELOG.md, suggesting changie-based release management.

DevOps engineers, platform engineers, and SREs who need to provision and manage multi-cloud infrastructure programmatically; also contributes used by Terraform provider developers building integrations for specific cloud platforms or services.

Terraform is production-ready and actively maintained at scale. The codebase is large (18.3MB of Go code) with extensive HCL configuration examples and comprehensive CI/CD setup via GitHub Actions. Recent activity shows multiple bug fixes and enhancements in 2025 (v1.15 and v1.16 branches), indicating ongoing active development and rapid iteration on stability.

The repo has a substantial dependency footprint (hashicorp/go-plugin, hashicorp/hcl/v2, terraform-registry-address, go-tfe for cloud integration) which increases maintenance surface area. There is notable complexity around state management and backend coordination (azure, consul, cos, gcs backends visible), and the extensive use of Go plugins means version mismatches can silently break provider functionality. Breaking changes appear to be tracked via UPGRADE NOTES in the changelog (e.g., .changes/v1.16/UPGRADE NOTES-20260330-145227.yaml).

Active development on v1.15 and v1.16 branches with multiple bug fixes in April–May 2025 (e.g., BUG FIXES entries on 20260501, 20260506), new features being added (NEW FEATURES entries for terraform operations, ENHANCEMENTS for resource handling), and upgrade notes being documented for breaking changes. The .changie.yaml config suggests automated changelog generation from unreleased change fragments.

Clone and build with: git clone https://github.com/hashicorp/terraform.git && cd terraform && go build -o terraform ./cmd/terraform. Consult the Makefile for task runners: make will show available targets. Requires Go 1.25.8+ per go.mod.

Daily commands: Build: go build -o terraform ./cmd/terraform (produces terraform binary). Run: ./terraform --help to verify. For development/testing, examine the Makefile: typical dev tasks likely use make test and make build. No docker compose or external services required for basic CLI operation, though testing against actual cloud providers requires credentials.

• cmd/terraform/main.go: Entry point for the terraform CLI binary; defines top-level command routing
• go.mod: Go module definition with all direct dependencies; shows that terraform requires go 1.25.8 and uses hashicorp/go-plugin, hcl/v2, go-tfe, and multiple backend implementations
• .changie.yaml: Configuration for automated changelog management; defines how bug fixes, features, and upgrade notes are organized per version
• .changes/v1.16/: Active v1.16 release notes directory showing recent enhancements, new features, and upgrade notes in progress
• internal/backend/: Core state backend implementations (azure, consul, gcs, cos, etc.); critical for understanding remote state management and locking
• .github/workflows/: CI/CD pipeline definitions for testing, building, and releasing; shows test coverage, go-version matrix, and release processes

Core command logic: start in cmd/terraform/ for CLI entrypoints. State/backend changes: modify internal/backend/ subdirectories (e.g., internal/backend/remote-state/gcs/ for GCS backend). Resource graph/planning logic: likely in internal/ core packages. Configuration parsing: internal/hcl2/ or similar for HCL semantics. Always reference the changelog pattern in .changes/ when adding features (create YAML fragments, not manual edits to release notes).

1. State locking and consistency: Backend operations (especially Consul and Azure) require careful handling of locks and eventual consistency; misconfigured state backends can corrupt state. 2. Plugin protocol versioning: Terraform providers are external Go plugins communicating via gRPC; provider version mismatches or protocol incompatibilities are not always obvious until apply time. 3. HCL2 evaluation order: Variable and resource evaluation depends on dynamic graph construction; circular dependencies or undefined references fail late in planning, not parsing. 4. Changelog workflow: Must use .changes/ fragments (YAML files named TYPE-TIMESTAMP.yaml) rather than editing CHANGELOG.md directly; the build/release process regenerates it from fragments via changie. 5. Environment variables: Terraform Cloud integration (go-tfe) requires TFE_TOKEN or similar in some operations; missing credentials fail silently in some contexts.

• Resource Graph & DAG (Directed Acyclic Graph) — Terraform builds a dependency graph of all resources to parallelize creation and determine safe apply order; understanding this is essential for debugging apply failures and resource ordering issues
• State Locking & Remote State Backends — Terraform uses pessimistic locking on shared state (via Consul, DynamoDB, etc.) to prevent concurrent modifications; misconfiguration causes state corruption in team environments
• HCL Dynamic Block Evaluation & Splat Syntax — Terraform's configuration language uses dynamic blocks and for-each splat syntax for conditional and bulk resource creation; understanding evaluation order prevents subtle planning bugs
• Provider Plugin Protocol (gRPC-based) — Providers communicate with Terraform core via gRPC; breaking changes in the protocol version silently fail provider integrations across major versions
• Execution Plans (Plan & Apply Phases) — Terraform separates planning (dry-run with resource diffing) from apply (actual state mutations); understanding the plan structure is critical for writing safe automation and debugging unexpected changes
• State Snapshots & Drift Detection — Terraform's state file is a snapshot of known infrastructure; detecting drift (real resources modified outside Terraform) requires careful refresh and diff logic
• Changie-based Changelog Management — This repo uses YAML fragment files in .changes/VERSION/ instead of manual CHANGELOG.md entries; the build process auto-generates release notes, so contributors must follow this pattern

• hashicorp/terraform-provider-aws — The official AWS provider; essential companion repo showing how to build providers that integrate with Terraform's plugin architecture
• hashicorp/go-tfe — Terraform Cloud API client library (vendored/imported in this repo); manages remote state and runs in cloud mode
• hashicorp/go-plugin — The gRPC-based plugin system underlying Terraform providers; core to understanding how terraform communicates with external provider binaries
• hashicorp/hcl — HCL (HashiCorp Configuration Language) v2 parser and evaluator; the language engine behind Terraform configuration syntax
• opentofu/opentofu — Community fork/alternative to Terraform; relevant for understanding how Terraform's design influenced later IaC tools and licensing debates

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Implement changelog entry validation in CI pipeline

The repo uses a changelog management system (.changes directory with version-specific YAML files tracked by .changie.yaml), but there's no evidence of automated validation in the CI workflows to ensure PR authors create required changelog entries. This would prevent incomplete releases and ensure consistency in changelog formatting across contributors.

• [ ] Review .changie.yaml configuration to understand changelog schema requirements
• [ ] Examine existing .changes/v1.15/*.yaml files to document the exact format expected (BUG FIXES, ENHANCEMENTS, NEW FEATURES, UPGRADE NOTES categories)
• [ ] Create a new GitHub Action workflow in .github/workflows/ (e.g., changelog-validation.yml) that runs on pull_request events
• [ ] Add validation logic to check: PR modified source files but changelog entry missing, or validate YAML structure against schema
• [ ] Update .github/pull_request_template.md to remind contributors about changelog requirements

Add comprehensive integration tests for remote state backends

The go.mod shows terraform depends on multiple remote-state backend implementations (azure, consul, cos, gcs, k, etc.) but the repo structure suggests these are vendored or imported modules. Add integration tests that verify backend initialization, state locking, and migration scenarios across different backends to catch breaking changes early.

• [ ] Survey existing backend test patterns in internal/backend/remote-state directories
• [ ] Create a new test suite in internal/backend/remote-state/integration_test.go that uses test containers or cloud emulators
• [ ] Implement test cases for: backend initialization with various credentials, state read/write operations, concurrent access/locking, and state migration between backends
• [ ] Add a new GitHub Action workflow in .github/workflows/ (e.g., backend-integration-tests.yml) to run these tests on pull requests affecting backend code
• [ ] Document setup requirements in CONTRIBUTING.md for running backend tests locally

Add Go version compatibility testing across supported versions

The repo specifies Go 1.25.8 in .go-version and 1.25.8 in go.mod, but there's no visible CI matrix testing against multiple Go versions (1.25.x, 1.26.x if available, etc.). This would catch version-specific issues early and ensure broader compatibility.

• [ ] Review .github/workflows/build.yml and checks.yml to understand current CI structure
• [ ] Modify the build workflow to include a Go version matrix (e.g., [1.24.x, 1.25.8, 1.26.x if applicable])
• [ ] Ensure each Go version builds successfully and unit tests pass via the matrix configuration
• [ ] Add a documentation note in CONTRIBUTING.md listing the minimum and tested Go versions
• [ ] Consider adding the Go version test results to the build status badge or release notes documentation

• Add unit tests for the Consul backend remote-state implementation (internal/backend/remote-state/consul/); the presence of other backends suggests this one may have gaps.
• Document the .changes/ changelog fragment format and workflow in CONTRIBUTING.md; currently only a README.md stub exists and contributor confusion about changie usage is common.
• Implement a validation pass for missing required provider attributes in HCL parsing; gaps in attribute coverage detection would improve early error reporting before planning.

Terraform's security posture is generally solid, with proper use of Go as a compiled language and attention to infrastructure-as-code security. However, there are opportunities for improvement in container image hardening, dependency pinning, and supply chain security. The main concerns are: (1) lack of specific version pinning for the Docker base image, (2) inclusion of unnecessary packages (openssh) in the runtime image, (3) development

• Medium · Outdated Go Version — .go-version, go.mod. The .go-version file and go.mod specify Go 1.25.8, which may contain known vulnerabilities. Go versions should be kept current with the latest stable release, and security patches should be applied promptly. Fix: Regularly update Go to the latest stable version and monitor Go security advisories at https://github.com/golang/go/issues. Implement automated dependency checking in CI/CD.
• Medium · Permissive Docker Base Image — Dockerfile. The Dockerfile uses 'golang:alpine' from docker.mirror.hashicorp.services without specifying a specific version tag. This could lead to unpredictable base image updates with unverified security patches. Fix: Pin the Alpine Go base image to a specific version (e.g., 'golang:1.25.8-alpine3.21') and regularly audit base image vulnerabilities. Implement image scanning in the build pipeline.
• Medium · Broad Package Installation in Docker — Dockerfile (RUN apk add --no-cache). The Dockerfile installs packages including 'bash', 'openssh', and 'ca-certificates' in the final image. The 'openssh' package in particular expands the attack surface unnecessarily for a compiled binary distribution. Fix: Use multi-stage builds to separate build environment from runtime. Remove unnecessary packages like 'openssh' from the final image. Only include 'ca-certificates' if TLS verification is required.
• Medium · No Image Signature Verification — Dockerfile (FROM statement). The Dockerfile uses docker.mirror.hashicorp.services without verifying image signatures or digests, making it vulnerable to supply chain attacks or MITM attacks. Fix: Use image digests (SHA256 hashes) instead of tags. Implement image signing and verification using Docker Content Trust or similar mechanisms.
• Low · Development Environment Variables in Production Image — Dockerfile (ENV statements). The Dockerfile sets TF_DEV=true and TF_RELEASE=1 environment variables, which may enable development features or non-hardened build paths in a production-intended image. Fix: Review whether TF_DEV=true is appropriate for production distributions. Consider using build arguments (ARG) instead of environment variables for build-time configuration, and only set production-appropriate environment variables.
• Low · No Security Scanning in Build Process — .release/, .github/workflows/. The provided build configuration files (.release/security-scan.hcl exists) but there's no evidence of SBOM generation, vulnerability scanning, or signed releases in the visible CI/CD workflows. Fix: Implement automated security scanning in CI/CD (trivy, snyk, or grype). Generate and publish SBOMs (Software Bill of Materials). Sign releases with GPG keys and verify signatures during distribution.
• Low · Potential Unverified Dependencies — go.mod (replace directives). The go.mod contains multiple replace directives for internal backends (azure, consul, cos, gcs, k...) with placeholder versions '0.0.0-00010101000000-000000000000', indicating local/development dependencies that may not be properly vetted. Fix: Ensure all replace directives point to specific, vetted versions or commit hashes. Implement dependency verification checks in the build process using 'go mod verify' and 'go mod tidy'.
• Low · Missing Repository Security Configuration — Repository configuration (GitHub). No evidence of branch protection rules, required code review enforcement, or commit signing requirements visible in the repository structure. Fix: Configure branch protection rules requiring at least 2 code reviews, dismiss stale reviews, require status checks to pass, and enforce signed commits for main/release branches.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.