This is a clean, well-motivated refactor. It decouples HTTP serving from the initial provider load so /healthz answers as soon as the listener binds, splits liveness (/healthz, process up) from readiness (/readyz, daemon connected plus providers loaded), and enables the Helm startup and liveness probes by default. The shutdown choreography is careful: the daemon is anchored to context.Background() so in-flight requests keep their DRPC connection while httpServer.Shutdown drains, and only then is the daemon closed. The timeout budget (300+5+5=310s) stays under terminationGracePeriodSeconds (330s), and TestStandaloneGatewayRun_ShutdownLifetimes proves the daemon outlives a draining request via channel handshakes rather than sleeps. Multiple reviewers ran the suite under -race with no concurrency findings.

The one theme worth acting on before merge is test coverage of the failure paths. The refactor deleted TestLoadProviders_AIBridgedDoneStopsRetry (and alwaysFailReloader), the only test exercising the daemon-death short-circuit in loadProviders; that branch survived verbatim but now runs at 0% coverage, and it is genuinely reachable in production (a wrong gateway key makes aibridged connect() close Done()). Separately, no test asserts run() ever returns a non-nil error, so the whole errors.Join aggregation and the serve-error path are unwitnessed. The happy paths are proven beautifully; the failure paths are not.

Severity count: 3 P3, 5 Note, 6 Nit. Nothing blocking.

Process note: the commit subject is 79 characters (the project caps subjects at 72) and lowercases "http" where the PR body writes "HTTP". Consider tightening and matching capitalization, e.g. "fix: start AI Gateway HTTP listener before initial provider load".

As Bisky put it: "you pried one stone out of the setting and left the empty prong."

helm/ai-gateway/values.yaml:198

Nit [CRF-11] The terminationGracePeriodSeconds comment names only the 300s HTTP timeout, but the budget now has three components. (Ryosuke)

This cross-file budget has no mechanical enforcement, so the comment is the only link.

The CLI comment now states the sum of shutdownTimeout + daemonShutdownTimeout + traceShutdownTimeout (310s), while this comment still reads "the binary's 300-second shutdown timeout plus termination headroom." Update it to name the daemon and trace timeouts too, so the next bump to any constant does not silently eat the 20s headroom.

🤖

🤖 This review was automatically generated with Coder Agents.

Round 2 verified. All 14 round-1 findings are genuinely fixed, not just claimed: the panel ran coverage and stress tests rather than trusting labels. loadProviders is back to 100% coverage with a real regression guard (TestStandaloneGatewayLoadProviders_DaemonDoneStopsRetry closes the daemon inside Reload, deterministically, no timing hack), the unreachable watch-escalation send is gone, both inline shutdowns route through shutdownWithTimeout again, the grace-period comment now itemizes the 300+5+5+20 budget, and the naming/doc fixes all landed. The restructure into runStandaloneGateway + serve reads well and the shutdown-ordering invariant (daemon outlives the HTTP drain) is now proven by TestStandaloneGatewayServe_ShutdownOrder.

One new issue is worth fixing before merge. The CRF-3 fix added an initialProviderLoadErr select arm that duplicates the daemon.Done() arm on the terminal-failure path: on a bad gateway key both arms become ready and Go picks one at random, so the process reports either "AI Gateway daemon exited" or "initialize ai providers". The new TestRunStandaloneGateway_DaemonExited hard-asserts one of the two, which turns that benign nondeterminism into a CI flake. Two reviewers reproduced it independently (Netero naturally at ~2/1000; Komugi deterministically by inserting a scheduling delay). This is the round-1 nondeterministic-exit-text note, dropped then as cosmetic, now given teeth by a test that pins one branch. Fixing only the assertion papers over the fact that the arm is dead machinery (0% coverage, can never deterministically win); the root-cause fix removes the flake, the dead arm, and the nondeterministic message at once.

Severity count (new this round): 1 P2, 1 P3, 2 Note, 2 Nit. Nothing blocking.

Process note: Coder squash-merges the PR title into main's permanent history, so the title matters. It is 79 characters (the project caps subjects at 72) and lowercases "http" where the body writes "HTTP"; consider tightening and matching casing, e.g. "fix(enterprise/cli): decouple AI Gateway HTTP listener from provider load".

As Bisky put it: "this round is lovely ... Real stones."

🤖 This review was automatically generated with Coder Agents.

Round 3 verified. All six round-2 findings have genuine fixes, checked against the code rather than the labels. The CRF-15 flake is cured at the root, not re-shadowed: the load goroutine now suppresses the duplicate send, so daemon.Done() is the sole terminal reporter and TestRunStandaloneGateway_DaemonExited is deterministic (multiple reviewers ran it -race at counts of 300-500, clean). The CRF-18 shutdown budget is now split into four sequential timeouts (providerSync 5s + HTTP 300s + daemon 5s + trace 5s = 315s < 330s), and the const comment and values.yaml agree. CRF-20's new TestStandaloneGatewayHealthAndReadiness drives the real newGatewayMux/ready() composition to /readyz 200 with a genuinely connected daemon, then proves readiness drops on disconnect and recovers on reconnect. CRF-16/17/19 landed as claimed.

One round-2 finding is only half-resolved. The CRF-15 fix removed the flake and the nondeterministic message but suppressed the duplicate send instead of removing it, so initialProviderLoadErr, its send, and its serve arm are now provably unreachable dead code (0% coverage, confirmed by static proof: loadProviders only ever returns while daemon.Done() or the reload context is already closed). It is P3, not the original P2, because the CI flake is genuinely gone; the residual is dead machinery plus a latent-reactivation trap. Details on the re-raised thread. Two smaller new items: the central function's doc comment describes connect-then-serve (contradicting the independence this PR delivers), and the provider-reload goroutine is now named with two prefixes.

Severity count (this round): 2 P3, 1 Nit, 1 Note. Nothing blocking.

Process notes. (1) CI is broadly red, but the PR's own diff is clean locally at head: go build ./enterprise/cli/... ./cli/..., gofmt -l, go vet, the AI-gateway Go tests, and the helm ai-gateway golden tests all pass. The changes path-filter job failed first and the red spans checks this diff cannot affect (test-js, Storybook, sqlc-vet, offlinedocs), so the failure appears to originate outside this diff (the rebase/stack/base or CI infra); worth confirming against the job logs before merge. (2) Coder squash-merges the PR title into permanent history; it is 79 characters (the project caps subjects at 72) and lowercases "http" where the body writes "HTTP".

As Hisoka put it: "Round 2 left a corpse on the floor and the author only cleaned up the blood, not the body."

🤖 This review was automatically generated with Coder Agents.

I don't have any blocking concerns, just a few follow-up suggestions. 👍