time atmos terraform apply \
    --labels deployment:$app-dev \
    --max-concurrency 3 \
    -auto-approve \
    --dry-run

--profile

--heatmap

Found it. #2807 intentionally skips unmatched labels before state reads, but our deployment label is a two-pass template: it
  references base_environment_stage, which is itself a template. The scope check sees it still unresolved and conservatively
  renders every component—hence 3,451 S3 reads.

  I'm flattening that label expression everywhere it uses this pattern; same final label, resolvable in one pass.

• Ran set -e
  │ selector_files=$(rg -l -U 'labels:\n(?:[^\n]*\n)*?\s+deployment:.*base_environment_stage' stacks)
  │ perl -0pi -e 's/deployment: "\{\{ \.vars\.app \}\}-\{\{ \.vars\.base_environment_stage \}\}"/deployment:
  │ … +5 lines
  └ (no output)

• Confirmed. Atmos deliberately does not cache a missing state, so every fallback reference re-reads S3. But successful
  Terraform nodes already invalidate that exact cache entry afterward, which makes negative caching safe for this process.

  I'm changing the cache to retain "not provisioned" until that invalidation.

i believe we cache each

!terraform.state

read (unless something broke) so we don't read the data from the same key more than once

!terraform.state