P3 [CRF-4] The best-effort delivery and partial-failure isolation are genuine logic with zero coverage, and the test double can't exercise them. (Bisky P3, Chopper)

Under coverage, every uncovered block in notifyBudgetThresholdCrossings is the delivery-failure path: the user-enqueue error append, the admin-enqueue error append, and errors.Join on a non-empty slice. FakeEnqueuer.enqueueWithDataLock always returns (id, nil) (notificationstest/fake_enqueuer.go:78), so the behavior the PR description sells ("a failure to enqueue is logged and never blocks recording") is asserted nowhere. If append(errs, ...); continue ever regressed to return err, one admin's failed enqueue would silently drop every later admin and, for a multi-crossing interception, the remaining user notification.

Give FakeEnqueuer an error hook (or wrap it to fail one specific admin ID), then assert the surviving recipients still received their notifications and RecordTokenUsage returned no error. The same test double gap blocks proving the CRF-3 fix: add a case where GetUsers errors and the user notification still fires.

🤖

We already have TestRecordTokenUsageBudgetNotificationBestEffort, which covers similar scenario. That said, your suggestion is interesting—I’ll consider adding another test for it in a follow-up PR.

P3 [CRF-7] notifyBudgetThresholdCrossings accepts a []budgetThresholdCrossing but derives the notified user, group, and admin recipients from crossings[0] alone, silently assuming every element shares the same user and group. (Meruem)

The homogeneity contract lives only in a doc comment and in detectBudgetThresholdCrossings building all crossings from one intc.InitiatorID/cost.effectiveGroupID. Nothing in the signature enforces it. A future caller that batches crossings across interceptions or users (the natural next step if crossings are ever accumulated before flushing) would resolve user/group/admins from element 0 and then mail every admin a notification naming crossings[0].userID while carrying another user's threshold, silently. Not a live bug; the sole caller passes homogeneous crossings. Make the shared identity visible in the type instead of position 0: notifyBudgetThresholdCrossings(ctx, userID, effectiveGroupID uuid.UUID, thresholds []crossedThreshold), where the slice carries only the per-threshold varying data. Then a mixed-user batch cannot be expressed.

🤖

Sounds reasonable. I'll try to refactor it in a follow-up PR.

Nit [CRF-9] Admin subject lines start with a bare lowercase username: "alice is approaching their monthly AI budget limit" (and the same at line 46, "alice has reached..."). (Leorio)

The rendered subject opens an email with a lowercase word. Every other admin/entity notification in this migration tree capitalizes and quotes the name (User account "..." created, Workspace "..." deleted), and your own body two lines down already writes User **{{.Labels.username}}** has used more than.... The title diverges from both the codebase convention and its own body. Fix both templates: E'User {{.Labels.username}} is approaching their {{.Labels.period}} AI budget limit' and E'User {{.Labels.username}} has reached their {{.Labels.period}} AI budget limit'.

🤖

Nit [CRF-10] Two comments restate what the code already shows, and one is slightly wrong about the mechanism. (Gon)

// Notify the user who crossed the threshold. above EnqueueWithData(notifCtx, userID, c.userNotificationTemplate, ...) carries no invariant the target and template don't already state. The // Notify admins, naming the affected user. comment (line 173) is worse: "naming the affected user" implies the trailing userID argument names the user, but the name reaches the template through the shared "username": user.Username label; the trailing userID is the notification target/dedup key. An imprecise comment about the mechanism is worse than none. Delete both.

🤖

Note [CRF-1] budgetNotificationAdmins selects recipients via GetUsers filtered only by RbacRole, so suspended owners and user admins still receive the admin email/inbox notification. (Netero)

GetUsers applies no status filter unless Status is set. This matches the two existing admin-notification call sites (reports/generator.go:299, provisionerdserver.go:1447), which also pass only RbacRole, so it is consistent with the codebase, not a regression. Flagging because the affected user must be active to generate spend while the admin recipients are not status-checked. If suspended admins should not be notified, add Status: []database.UserStatus{database.UserStatusActive} here and fix the sibling sites too.

🤖

Note [CRF-2] Admin-recipient lookup repeats the GetUsers(RbacRole: ...) + build-recipient-slice idiom found in two other packages. (Netero)

reports/generator.go and provisionerdserver.go build the same "fetch users by role, filter into a recipient slice" shape with different roles. No shared helper exists and the role sets and exclusion logic differ, so extracting one now is not clearly warranted. Recording it so the pattern is visible if a fourth site appears.

🤖

Note [CRF-11] The template literal "user_override" duplicates codersdk.AIBudgetLimitSourceUserOverride with no test pinning them together. (Gon, Knuckle, Zoro; Melody confirmed they agree today)

The template branches on {{- if eq .Labels.limit_source "user_override"}}, while the producer emits string(c.limitSource) from the Go constant (codersdk/aibridge.go:24). The wire chain is intact today (Melody verified end to end), but if the constant's value is ever renamed, cost.go emits the new string, the template's eq fails, and the override line silently vanishes from admin mail with no crash. The golden test feeds a hardcoded "user_override" label rather than the constant, so it would still pass while production drifts. Cheap insurance: source the golden test's label value from string(codersdk.AIBudgetLimitSourceUserOverride) so a rename breaks the test instead of production.

🤖

Another obligatory reminder to check migration number before merge