Summary

pkg/bundler/deployer/helmfile/releases.go:216 keys the disableValidation: true flag off f.Parent, so injected -pre / -post wrapper folders inherit the flag from their primary component. Visible in goldens like pkg/bundler/deployer/helmfile/testdata/mixed_gpu_operator/helmfile.yaml:

- name: gpu-operator-post
  namespace: gpu-operator
  chart: ./002-gpu-operator-post
  values:
    - ./002-gpu-operator-post/values.yaml
  needs:
    - gpu-operator
  disableValidation: true

gpu-operator-post here is a local-helm wrapper around a single RuntimeClass manifest. It doesn't ship the chart's crds/, doesn't reference any CRD that's not already registered by the predecessor gpu-operator release, and doesn't self-reference any kind. There's no operational reason to disable helm-diff's mapper sanity check on it.

Impact

Low — the post-folder loses helm-diff's REST-mapper validation, so a typo in a resource kind in a pre/post manifest would render successfully at diff time and fail at apply time. Not a functional regression vs. main, but a small loss of defense-in-depth.

Options

1. Scope the flag to the primary release only. Track folder kind in the per-release decision so only KindUpstreamHelm (or whichever shape carries the actual self-ref CRD) gets disableValidation: true.
2. Keep the cascade but document why. Today the inline comment says "Keyed by f.Parent so injected -pre / -post folders inherit the same flag." That reads as accidental coupling. If the cascade is intentional, the comment should explain why we want it (e.g., a self-ref CRD in the primary chart's crds/ could be referenced by a post-manifest in some scenarios).

Acceptance Criteria

• Pick option 1 or 2.
• If option 1: update releases.go and regenerate goldens (go test -update ./pkg/bundler/deployer/helmfile/...).
• If option 2: rewrite the inline comment at releases.go:209-215 to explain the cascade rationale.

Related

• PR fix(bundler): stratify helmfile bundle by DAG level (#914) #926
• Review comment: fix(bundler): stratify helmfile bundle by DAG level (#914) #926 (comment)