Why heredocs and interpolations need special handling

A naive brace-counter would get confused by a heredoc block containing a shell script or JSON template with its own `{` and `}` characters, or by string interpolation syntax like `${var.foo}` that also uses braces for an entirely different purpose. Correctly validating block structure means the parser has to recognize when it's inside a heredoc or a string literal and stop counting those characters as structural braces at all — treating the heredoc's content as opaque text until its closing delimiter, and treating an interpolation's braces as part of the string rather than block syntax. Getting this wrong would produce false "unbalanced braces" errors on completely valid Terraform any time a resource embedded a script or JSON payload with its own braces, which is a common and legitimate pattern in real configs.

Why duplicate resource detection is worth checking for specifically

Terraform identifies every resource by the combination of its type and name (`aws_instance.web`), and defining that same type+name pair twice in the configuration is a definition conflict Terraform itself will reject at plan time — but by then, you've already written (and possibly pasted together from multiple files) a config with the mistake in it. Catching this structurally, before ever running `terraform plan`, is exactly the kind of fast pre-check that saves a round-trip to the real Terraform CLI for a mistake that's often just a copy-paste artifact from combining snippets from different sources.

The boundary between structural and semantic validation

This tool confirms the file's shape is sound — balanced delimiters, correctly labeled blocks, no duplicate resource identifiers — but it has no model of what any specific provider (AWS, GCP, Azure, or any of the hundreds of others) actually requires for a given resource type. A resource block with perfect structure and a missing required argument like `ami` on an `aws_instance` will pass this check cleanly and still fail at `terraform plan` or `apply`, because that's a provider schema requirement, not a structural one. This tool is the fast, offline first pass; the real `terraform validate` against the actual provider schemas remains the authoritative check before anything gets applied.