P3 [CRF-27] The env override guard scans only coder.env, so the collision CRF-7 fixed still crashes the container through coder.envFrom. (Hisoka)

The CRF-7 fix loops over .Values.coder.env and rejects any owned name, including CODER_AI_GATEWAY_KEY. But the container also gets .Values.coder.envFrom (_aigateway.tpl:78-81, verified), and the guard never looks there. envFrom keys are opaque at render time, so the loop cannot inspect them, which means this is not fixable by extending the loop.

Two consequences, both verified from the code + CLI:

• The chart always emits CODER_AI_GATEWAY_KEY_FILE, and resolveAIGatewayKey (enterprise/cli/aigatewaystart.go:366) aborts when both CODER_AI_GATEWAY_KEY and CODER_AI_GATEWAY_KEY_FILE are set. An operator who ships CODER_AI_GATEWAY_KEY via a ConfigMap/Secret referenced by coder.envFrom bypasses the guard and lands in CrashLoopBackOff on the same confusing "mutually exclusive" error.
• For the other owned names, Kubernetes gives env precedence over envFrom, so an envFrom override is silently ignored, which contradicts the values.yaml:4 promise "Chart-owned variables cannot be overridden."

The guarantee is only true for coder.env. Fix: scope the values.yaml comment and README to coder.env explicitly and warn that envFrom is not guarded (and that CODER_AI_GATEWAY_KEY there is a startup crash), or drop the absolute wording. Related: the derived owned-set is also dynamic (Mafuuu, Kurapika) so the TLS file-path vars are unguarded when their secret is unset; both reviewers judged that self-inflicted (the referenced file just does not exist), not an attack surface.

🤖

P3 [CRF-28] The startupProbe comment tells operators to keep it disabled "until /healthz is independent of initial provider load," a condition the architecture never satisfies, and following it while enabling liveness reintroduces the CRF-4 cold-start crashloop. (Mafuuu P3, Pariston Note, Meruem Note)

Both the startupProbe (line 119) and livenessProbe (line 125) blocks carry the identical comment. ai-gateway start never opens its /healthz listener until loadProviders has connected to coderd (aigatewaystart.go: loadProviders blocks, net.Listen runs afterward), so /healthz is coupled to provider load by design and the condition is never met. For liveness the disable is sound and matches the sibling coder chart. For the startup probe the reasoning is inverted: a startupProbe with a generous failureThreshold is precisely the mechanism that makes liveness safe under that ordering. The chart's own custom.yaml fixture proves it (startupProbe enabled, failureThreshold: 12, liveness off).

Consequence: an operator who wants liveness in production reads this comment, keeps startupProbe off, enables livenessProbe, and gets back the ~30s CrashLoopBackOff that CRF-4 removed from the defaults. Meruem adds a second angle: with liveness off there is no restart-on-hang, so a deadlocked (not crashed) replica lingers forever under replicaCount > 1, silently shrinking capacity. Reword the startup-probe comment: enable startupProbe with a generous failureThreshold first, then livenessProbe is safe; /healthz depends on provider load by design, so the startupProbe is required, not deferred. Note that liveness-off means no automatic recovery from a post-startup hang.

🤖

P4 [CRF-29] The livenessProbe render branch is the only one of the three probe blocks with zero golden coverage. (Bisky)

readinessProbe renders in all 9 goldens and startupProbe in 2 (custom, custom_coder), but livenessProbe renders in none: the sole case that sets it, custom.yaml, sets enabled: false, and every other case leaves the default off, so lines 112-124 never execute in the suite. The block is a copy of the startup/readiness blocks with a different values key and path; it reads correctly today, but copy-paste blocks are exactly where a wrong key or a /readyz typo hides, and the startup golden would not catch it. This is a user-enableable surface CRF-14 added. Add coder.livenessProbe.enabled: true to one values case and snapshot it so the block is pinned like its two siblings. P4 because the code is verified correct by reading.

🤖

Nit [CRF-30] Secret references in the aigateway block are inconsistent: three use .name, one uses .secretName. (Gon)

keySecret.name, coderTLS.caSecret.name, and coderTLS.clientSecret.name all use name, but listenerTLS.secretName uses secretName for the same concept (the name of a Kubernetes Secret). listenerTLS.secretName does mirror the coder chart's coder.tls.secretName, so the outlier has a cross-chart rationale, but the block is internally inconsistent. additionalProperties: false caps the harm (a wrong guess fails loudly). Cheapest to settle now, before this new chart's values API stabilizes. (ingress.tls.secretName mirrors the native Ingress field and should stay.)

🤖

Nit [CRF-31] terminationGracePeriodSeconds: 330 is coupled to the binary's shutdown timeout with nothing recording the coupling. (Gon)

CRF-19 raised that the previous value (300) equaled the binary's 5m shutdown timeout, so SIGKILL cut in-flight streams; the fix bumped it to 330 for headroom, which is correct. But no comment states that 330 is "binary shutdown timeout (~300s) plus headroom." A maintainer tuning this later sees only 330, cannot know it is anchored to an external timeout, and can lower it below the shutdown timeout, silently reintroducing CRF-19. Add a one-line comment tying the number to the binary's shutdown timeout. (Gon rated this P3; recorded as Nit since the consequence is regressing a Note-level issue and the fix is a comment.)

🤖

Nit [CRF-32] The prerequisite says the Secret must live "in the chart namespace," but the kubectl create secret command has no -n. (Leorio)

README.md:12 states the Secret must be "in the chart namespace," then the command runs kubectl create secret generic coder-ai-gateway-key ... with no namespace flag, and helm install later also has no -n. On the happy path (current context namespace) this works. An operator who installs the release into a dedicated namespace but runs the secret command verbatim creates the Secret in default; the pod then fails to mount secretName: coder-ai-gateway-key and never starts, with only a Kubernetes mount error to debug. Add -n <release-namespace> to the command, or state that the Secret and the release must share a namespace.

🤖

Nit [CRF-34] The probe field-projection block is triplicated verbatim across startupProbe, livenessProbe, and readinessProbe. (Meruem Nit, Robin Note)

The same range $field := list "periodSeconds" "timeoutSeconds" "successThreshold" "failureThreshold" / hasKey loop is copied three times (lines 106-110, 119-123, 132-136), differing only in the probe key and path. A define "coder-ai-gateway.probe" taking (probeName, path, scheme) would collapse the three and remove the drift risk when a field is added. The sibling coder chart duplicates the same logic (and less cleanly), so this extends a pre-existing pattern rather than introducing one; purely a maintainability nit.

🤖