Terraform/HCL config values aren't linked into the cross-repo config-key graph (unlike Kubernetes)

[dsh971]

Problem

Gortex already resolves cross-repo configuration coupling for Kubernetes manifests — internal/parser/languages/kubernetes.go extracts container.env[], envFrom, and valueFrom into KindConfigKey nodes connected via EdgeUsesEnv edges, the same id-space that os.Getenv() reads in application code resolve against. So a config value set in a K8s manifest in one repo is already matched, cross-repo, to the code that consumes it.

Terraform/HCL doesn't get the same treatment. internal/parser/languages/hcl.go parses resource/variable/output/module/data blocks into graph nodes, but reference edges are explicitly scoped to "the file's directory — the Terraform module boundary." A Terraform-defined value never reaches the shared config graph.

This matters because Terraform frequently sets the environment values that Kubernetes-native YAML would otherwise set directly — ECS task definition environment entries, Lambda environment blocks, or Terraform-managed kubernetes_config_map/kubernetes_secret resources. Any of those currently fall into the same blind spot Kubernetes manifests already solved.

Example

Repo A's Terraform defines a variable (or an ECS/Lambda environment entry) like MAX_BATCH_SIZE with a default value. Repo B's application code reads it via os.Getenv("MAX_BATCH_SIZE"), with no import or shared package linking the two repos. Today, gortex contracts has no way to surface that link — the same value set via a Kubernetes manifest instead would already be caught.

Proposed scope

• Extend the HCL extractor so variable/output blocks representing runtime config, and specific resource types that set service environment values (ECS task definitions, Lambda environment blocks, kubernetes_config_map/kubernetes_secret via the Terraform Kubernetes/Helm providers), emit the same KindConfigKey node + EdgeUsesEnv edge that Kubernetes manifests already produce.
• No changes to the existing contract-matcher expected — feeding it this new input should be enough for cross-repo matching to work the same way it already does for env vars/K8s.
• Static parsing only, no terraform plan/state evaluation — consistent with how every other input is handled.
• Existing Terraform reference resolution (module-scoped resource/variable/output edges) stays untouched — this is additive.

Questions for maintainers

• Is this something you'd want, and does the proposed scope (ECS/Lambda/K8s-provider resources as a starting set) match how you'd shape it, or would you prefer a different starting point?
• Single PR, or staged (variables/outputs first, provider-specific resource types as follow-ups)?

Happy to put together a PR with test coverage (same-repo match, cross-repo match, and a regression check against existing K8s/env-var matching) if this is a direction you'd want

[zzet]

Hey @dsh971, thank you for your interest to the project.

Is this something you'd want

Yes, this part is in the roadmap and we haven't reached the point yet. The IaaC is a crucial part in the cross-repositories contracts.

does the proposed scope (ECS/Lambda/K8s-provider resources as a starting set) match how you'd shape it, or would you prefer a different starting point

I haven't explored yet the cartesian product of various cases and any starting point in such a case seems valid.

Single PR, or staged

I'd rather a single PR because it shows the full picture.

Happy to put together a PR with test coverage

You're welcome.

[dsh971]

@zzet after digging into the actual matching mechanism during planning, with claude's help, it found the original framing was wrong in an important way — wanted to correct it before going further, since it changes the scope of what I'd be proposing.

The correction

Gortex has two separate mechanisms that both touch "env vars," and I conflated them:

• Graph-level (KindConfigKey + EdgeUsesEnv, what kubernetes.go/dockerfile.go produce) shares a node ID convention (cfg::env::<NAME>) — but the indexer rewrites every node ID to <repoPrefix>/<id> before committing to the graph, so this never collides across repos. It's same-repo traceability only.
• Contract-level (internal/contracts/matcher.go + Registry) is the actual cross-repo mechanism. Its env-var source, EnvVarExtractor, is a separate regex extractor recognizing only .env files, docker-compose.yml, and os.Setenv — it has no Kubernetes branch at all. So Kubernetes-declared env values don't reach cross-repo matching today either, contrary to what I assumed above.

So "mirror kubernetes.go and the existing matcher picks it up for free" isn't correct. Getting genuine cross-repo matching for Terraform means adding a new provider path into the contract-level mechanism specifically — a different package (internal/contracts), not just extending the HCL extractor.

Corrected scope

• Still ship the graph-level mirror (variable/output blocks, Lambda environment blocks, kubernetes_config_map/kubernetes_secret resources) — same-repo value, low risk, precedented.
• Add a new TreeAwareExtractor in internal/contracts/ (mirroring HTTPExtractor's pattern, since .tf files already have a tree-sitter parse tree available) that emits Contract{Type: ContractEnv, Role: RoleProvider} records — the piece that actually delivers cross-repo matching.
• v1 contract-level coverage narrowed to Lambda environment.variables only. I initially planned to cover variable/output blocks and ConfigMap/Secret keys too, but on reflection those don't have a structurally verifiable env-var binding (a variable block name has no inherent tie to an env var; a ConfigMap/Secret key depends on a separate Pod's envFrom/valueFrom this extractor can't see) — minting providers from them would produce false matches. Lambda's environment.variables key is the one case where the key genuinely is the runtime env var name.

Two things worth flagging before any code gets written

1. This will start firing your PR-review-gate's BLOCK verdict on new findings. computeContractImpact treats a contract-boundary break as a hard block. Once Terraform values become providers, existing repos may see new BLOCK verdicts that never fired before — intentional (it's the detection working), but a real behavior change worth knowing about upfront.
2. A standing inconsistency, not something I'm fixing: a kubernetes_config_map resource defined via Terraform would become visible to contracts/api_impact/the review gate, but still invisible to handleAnalyzeK8sResources's infra graph — while the same resource defined via hand-written K8s YAML is the reverse. Worth knowing this PR doesn't unify that, just adds one more disconnected data point.

Given this is a bigger ask than what I originally described, wanted to check you're still fine with this direction before I put time into it — happy to scope it down further, split it into separate PRs (graph-level vs. contract-level), or hear if you'd rather I not touch internal/contracts/ at all.

[zzet]

@dsh971 the k8s support is near greenfield, and I'm open to (even) radical changes which will improve cross-service code linking.
Feel free to reach me on the Discord server if you'd like to discuss some details in real time (or drop your doubts or when you can't make a decision in this issue).

Regarding flagged concerns:

1. This will start firing your PR-review-gate's BLOCK verdict on new findings.
   I don't see any issues in the described behaviour change. Step-by-step coverage will be increased, and such a warning will appear.

2. A standing inconsistency, not something I'm fixing.
   This part is dangerous. While we can have disconnected data for now - which is OK - later this data should be connected (otherwise, why is it needed?). Worth keeping in mind how it can be connected (or resolved in terms of the project).

I imagine the scope is big and it may span across multiple PRs. I don't see a problem with it.

or hear if you'd rather I not touch internal/contracts/ at all.

I would say the contracts are the reason why this feature is needed. If you have doubts, feel free to reach out to me, and we can discuss.