Motivation

On large polyglot repositories the scanner builds a single OPA payload containing every parsed document across all platforms, then evaluates each rule query against the full cross-platform payload. This means, for example, that every Ansible rule rebuilds its task index over thousands of Kubernetes, Helm-rendered, CloudFormation, and Terraform documents that are irrelevant to it. On a real-world Go monorepo (49 k YAML files, ~48 k parsed documents), a single Ansible rule takes ~27 s to evaluate due to this cross-platform document scanning; with ~221 Ansible rules the total Ansible eval time exceeds 100 minutes. The same mechanism inflates eval time for CloudFormation and Kubernetes rules on large mixed repos.

Changes

Platform classification

A new ClassifyFile function in the analyzer package determines a file's platform from its extension and content, mirroring the per-file detection already done by the analyzer but making it available to the parsing layer. Kind is used as the authoritative signal for unambiguous types (Helm→kubernetes, Terraform→terraform, Bicep→azureresourcemanager, Dockerfile→dockerfile, GRPC→grpc, INI/CFG→ansible); ambiguous YAML/JSON files fall back to content-based regex classification.

Scan pipeline

Both the regular sink and the resolver sink now populate a Platform field on each FileMetadata at parse time. Synthetic Terraform module documents inherit the platform of their parent file via FileMetadata cloning.

Rule engine

Inspect partitions the combined document set by platform and builds one OPA payload per platform that is actually queried in that scan. Each rule query receives only its own platform's documents. Documents whose platform could not be determined are included in every platform's payload so no rule loses coverage. common-platform queries (force-enabled by the engine and not observed in production slow-rule telemetry) continue to receive the full cross-platform payload. Two small helpers, normalizePlatformKey and selectPlatformPayload, handle the query-metadata-to-platform-key mapping (e.g. k8s↔kubernetes, Bicep↔azureresourcemanager).

Author Checklist

• I have reviewed my own PR.
• I have added or updated relevant unit tests where necessary. If no tests are added, I've explained why.
• All new and existing tests pass.
• I have tested my changes on staging (if applicable).
• I have updated any relevant documentation (if applicable).

QA Instruction

1. go test ./pkg/engine/... ./pkg/analyzer/... ./pkg/runner/... ./pkg/model/... ./pkg/scan/... — all packages should pass.
2. Scan a fixture directory that contains multiple platform types (e.g. test/fixtures/test_helm alongside a Terraform or Ansible fixture) and confirm the SARIF output is identical to the output produced by main.
3. On a large mixed-platform repository, confirm per-rule eval times drop significantly for Ansible and CloudFormation rules by comparing scan durations.

Blast Radius

This change affects all scans that parse more than one platform type. Scans of a single platform are unaffected (the per-platform payload equals the full payload). The findings set is unchanged, validated by a findings diff on a 1 048-file mixed repository (Kubernetes, Helm-rendered, Ansible, Terraform, CloudFormation) showing identical results (1 016 findings, zero lost, zero gained) against the main baseline.

Additional Notes

Measured on a real-world monorepo (49 k YAML files):

• Single Ansible rule eval: 27.4 s → 3.1 ms (~8 800×)
• Full scan of 1 048-file mixed subset: ~16 min (baseline) → ~9 s (this PR)

I submit this contribution under the Apache-2.0 license.