Documented stores.<name>.kind is unreadable by terraform-provider-utils 2.6.0 (vendors atmos 1.220.0), breaking every utils_component_config lookup #2930

Describe the Bug

kind: was added in 1.222.0 as the preferred store backend selector, and the secrets docs use it throughout. Adopting it breaks every component that uses the remote-state module.

terraform-provider-utils 2.6.0 (newest) vendors atmos v1.220.0, whose StoreConfig is {Type, Identity, Options} — no Kind field. NewStoreRegistry switches on Type, so kind:-only config yields Type == "" → default: → ErrStoreTypeNotFound.

Blast radius comes from where that runs: processStoreConfig is called unconditionally during config load, so one unparseable store fails the entire atmos.yaml load. utils_component_config loads that config to resolve remote state, so every lookup fails — including ones referencing no store.

Not a regression — existing type: config works in both versions, nothing previously-working broke. It's a forward-compat trap: the newly-preferred spelling is unreadable by Cloud Posse's own provider.

!terraform.state is the better approach and sidesteps this entirely — but it doesn't dissolve the issue. The published aws-ecs-service component (v3.0.0, current, not archived) makes 10 remote-state lookups in src/remote-state.tf.

Expected Behavior

The documented kind: spelling shouldn't break unrelated remote-state lookups.

Two hardening asks, both still live in 1.225.0:

• Blast radius. NewStoreRegistry is eager and fails closed on the first bad store, even for stores nothing references. Lazy construction — or collect-and-warn for unreferenced stores — would contain this class of failure.
• Diagnosability. ErrStoreTypeNotFound omits the store name though name is in scope: fmt.Errorf("%w: %s", ErrStoreTypeNotFound, kind). The adjacent ErrSecretBackendNotEncrypted does include store %q. On the legacy path the value is empty, so the entire message is store type not found: — no name, no field, no value.

Steps to Reproduce

Add a store to atmos.yaml, copying the shape straight from the docs:

stores:
  secrets/ssm:
    kind: aws/ssm
    secret: true
    options:
      region: us-east-2
      prefix: /atmos/example/secrets

Then atmos terraform plan <component> -s <stack> on any component using remote-state:

│ Error: store type not found:
│
│   with module.vpc.data.utils_component_config.config[0],
│   on .terraform/modules/vpc/modules/remote-state/main.tf line 1, in data "utils_component_config" "config":
│    1: data "utils_component_config" "config" {

Reproduces without Terraform or AWS — it fails during config load, so any subcommand shows it:

$ atmos_1.220.0 version
👽 Atmos 1.220.0 on darwin/arm64
 WARN  Could not load config error="store type not found: "

Adding type: aws-ssm-parameter-store alongside kind: clears it: 1.225 prefers kind via resolveKind(), 1.220 reads type, both resolve to the same backend.

Environment

• OS: macOS (darwin/arm64)
• Atmos: 1.225.0 (CLI) / 1.220.0 (vendored in provider)
• OpenTofu: v1.11.2
• cloudposse/utils: 2.6.0 · remote-state: 2.0.0 · aws-ecs-service: v3.0.0

Additional Context

The provider was already behind when kind shipped: atmos v1.220.0 (2026-05-28) → utils v2.6.0 (2026-06-03) → atmos v1.222.0 adds kind (2026-07-02).

Prior art: #2376 was the same shape — an atmos-side change surfacing as a utils_component_config failure — and was fixed in this repo.

The direct fix is a terraform-provider-utils release vendoring atmos >= 1.222 — happy to open that separately. Filing here because Cloud Posse owns both sides, the docs steer users into it, and the two hardening items are atmos-side regardless.

Workaround — set both, and keep type: until the provider bumps:

stores:
  secrets/ssm:
    kind: aws/ssm
    type: aws-ssm-parameter-store   # for terraform-provider-utils' vendored atmos 1.220.0
    secret: true