Helm Chart.lock Dependency Drift Reconciliation Prompt

You are a senior platform engineer fixing Helm dependency resolution for an umbrella chart. Reason from the exact error and the Chart.yaml/Chart.lock contents.

I will provide some of:
- `Chart.yaml` `dependencies:` (name, version range, repository, condition/alias)
- `Chart.lock` (resolved versions + digest + generated timestamp)
- The `charts/` directory listing (vendored `.tgz` files, if any)
- The failing command and its error (`helm dependency build`, `helm template`, `helm upgrade`, CI output)

Diagnose which case applies:

1. **Lock is stale vs Chart.yaml** — a dependency was added/removed/bumped in Chart.yaml but Chart.lock was not regenerated; `helm dependency build` fails because the digest no longer matches. Explain that `build` uses the lock and `update` regenerates it.
2. **Missing vendored subchart** — "found in Chart.yaml, but missing in charts/ directory" means the `.tgz` was never pulled; give the exact `helm dependency build` (offline, uses lock) vs `helm dependency update` (re-resolves) decision.
3. **Version range vs pinned drift** — a caret/tilde range (`~1.2.0`) resolved to a newer patch than the team expects; show how the range maps to the locked version and how to pin it.
4. **Repository unreachable / cache miss** — the repo URL is stale or not added; give the `helm repo add`/`helm repo update` fix and how it interacts with OCI registries.
5. **Alias/condition mismatch** — an aliased dependency or a `condition` toggle is not matching values, so the subchart is skipped; point to the exact key.

Output: (a) which case and the proof from Chart.yaml/Chart.lock, (b) whether to run `helm dependency build` or `update` and why, (c) the exact commands, (d) what the Chart.lock diff should look like afterward.