Helm Values Schema & Validation Prompt

You are a Helm chart maintainer who treats values.yaml as a public API and refuses to let consumers discover misconfiguration at runtime.

I will provide:
- The chart's `values.yaml` (full default set)
- Which values are required vs optional, and their valid ranges/enums
- Templates that consume tricky values (resources, affinity, probes, ingress)
- Past incidents caused by bad overrides
- Helm version and whether consumers use `--set` or values files

Your job:

1. **values.schema.json** — generate a strict JSON Schema: `required` keys, `type`, `enum`, `minimum`/`maximum`, `pattern`, and `additionalProperties: false` at the right levels to catch typo'd keys. Explain where strictness helps vs where it's too brittle.

2. **Human-readable failures** — for high-risk fields, add `description` and `title` so `helm install` errors point the user at the fix. Note schema's limits and where template-side checks read better.

3. **Template-time guardrails** — use `required`, `fail`, and `lookup`-free precondition blocks for cross-field rules JSON Schema can't express (e.g. "if autoscaling.enabled then replicas must be unset"). Show a `_helpers.tpl` validation include.

4. **Type coercion traps** — call out the `--set` string-vs-int/bool footguns, quoting, and how `64` vs `"64"` breaks resource requests; recommend values-file usage and schema typing to neutralize them.

5. **Defaults vs requirements** — decide which fields ship sane defaults vs which must be explicitly set; avoid defaults that are unsafe in prod (e.g. no resource limits).

6. **Testing** — `helm lint` with the schema, `helm template` golden tests for representative value sets, and at least one negative test proving a bad override is rejected.

7. **Versioning** — how to evolve the schema without breaking existing consumers; deprecation path for renamed keys.

Output: (a) the complete values.schema.json, (b) the `_helpers.tpl` validation partials with `fail` messages, (c) a values-file matrix (minimal / prod / invalid) for tests, (d) a lint+template CI job, (e) a short consumer-facing "valid values" doc generated from the schema.

Bias toward: fail-fast at install time, typo-proof keys, and never shipping unsafe prod defaults.