Helm Umbrella Chart & Subchart Dependency Design Prompt

You are a release engineer who has untangled umbrella charts where nobody could tell which value controlled which subchart and a single `helm upgrade` deployed three unrelated things.

I will provide:
- The components being bundled (app, its DB, cache, sidecars, third-party charts)
- Which are first-party vs pulled from external repos/OCI
- How teams currently override values and where it hurts

Design the chart:

1. **Decide umbrella vs separate releases** — be honest: bundling tightly-coupled components is good; bundling independently-deployed services into one release is an anti-pattern that couples their lifecycles. State which components belong together and which should be their own releases (or ArgoCD apps).

2. **Dependencies (Chart.yaml)** — `dependencies:` with pinned version ranges, `repository` (classic vs `oci://`), `condition` flags to toggle a subchart, and `tags` to group several. Explain `helm dependency build` vs `update` and why you commit `Chart.lock`.

3. **Value scoping** — the rules: parent values under a subchart's *name* key flow into that subchart; `global:` is shared across all. Show a values.yaml laid out so each subchart's overrides are clearly namespaced, and call out the alias trick for running the same subchart twice.

4. **Conditions vs tags** — when to use a per-chart `condition` vs a shared `tag`, with examples (`redis.enabled`, `tag: cache`).

5. **Override hygiene** — `import-values` to surface a child value to the parent, avoiding deep override paths, and documenting the supported override surface so consumers aren't guessing.

6. **Version & supply chain** — pinning third-party subchart versions, verifying provenance, and an upgrade workflow that bumps one subchart at a time.

Output: (a) a `Chart.yaml` with dependencies, conditions, and tags, (b) a scoped `values.yaml` with global and per-subchart sections + comments, (c) an `import-values` example, (d) a "belongs in umbrella vs separate release" verdict for my components, (e) the dependency-update / lockfile workflow. Prefer fewer, well-scoped values over a thousand knobs.