fix(frontend): fan-out modal says an incompatible bucket is skipped, then submits it

[cristim]

Summary

When a bulk selection produces a bucket whose term and payment combination is unsupported, the fan-out modal renders 'This bucket will be skipped'. The execute handler then maps over every bucket with no compatibility filter and submits it anyway, and the backend only warns for that combination. An approval email is minted for a commitment the UI said would not be submitted, and the modal's total upfront and total savings header counts that bucket's money too.

Location

frontend/src/recommendations.ts:4336 at 3c0f8ac

Failure scenario

A bulk selection produces two buckets, one of which fails isBucketPaymentCompatible (for example AWS RDS 3yr + no-upfront). renderFanOutBucketSection renders "Invalid combo: … This bucket will be skipped." handleFanOutExecute in frontend/src/app.ts:534 maps over buckets with no compatibility filter, so both buckets are POSTed. The backend only warns for that combination (cmd/validators.go:warnRDS3YearNoUpfront), so an approval email is minted for a commitment the UI just told the user would not be submitted. The confirm dialog and the "Total upfront / Total savings" header (computeFanOutTotals, line 4295) also count the skipped bucket's money.

Evidence

status.textContent = compat
  ? `${b.capacityPercent}% capacity · ${b.term}yr · ${b.payment}`
  : `Invalid combo: ${b.provider} / ${serviceLabel} doesn't support ${b.term}yr + ${b.payment}. This bucket will be skipped.`;
// app.ts:534 — no filter:
const promises = buckets.map((b) => api.executePurchase(b.recs.map(...), b.capacityPercent));

Suggested fix

Filter incompatible buckets out of currentFanOutBuckets before handleFanOutExecute runs (or exclude them from getFanOutBuckets), and exclude them from computeFanOutTotals and the email count.

---

Found by the 2026-09-02 codebase audit, finding A12-002, reported by one reviewer and independently confirmed by a second. Full report: docs/audits/codebase-audit-2026-09-02.md.

[cristim]

Merged: PR #2071 at596680d0350fb4f324120bde1fa338e66c62ee51 (reviewed head23b6dc27422b18471057b6c12cd66507af12a852).\n\nVerified: the shared eligibility predicate now drives fan-out status, totals, approval-email count and submitted buckets. Actual Chrome/production-bundle fixtures covered two compatible buckets, a mixed eligible/skipped selection (only EC2 submitted), and an all-skipped selection (zero totals/counts, Execute disabled, no confirmation or POST). Unsupported RDS choices were deliberately injected to exercise defensive paths; they are not naturally offered options. Captured browser requests were intercepted at loopback, with nonlocal requests blocked and no real cloud purchase or email.\n\nAll14 Chrome scenarios passed. Native frontend91suites/2944tests passed with1skip; typecheck/lint/build and audit passed. Fresh-context Astra full final-HEAD review and substantive CodeRabbit full five-file review were clean, and all six exact-head CI workflows passed before normal merge. Post-merge runs remain separately monitored; deployed behavior is not claimed.\n\nThe issue was automatically closed by the merge. Fan-out payment repricing remains #2070; lifecycle/account grouping remain LeanerCloud/cloud-commitments-platform#331/#2088. Proof and limitations: #2071 (comment) .

[cristim]

Post-merge update: all nine workflows passed for merged commit 596680d. Read-only checks on all three dev deployments confirm the changed app.ts and recommendations.ts source matches that commit exactly. Cloud workflow health/smoke checks passed. Deployed Chrome navigation was blocked by the browser connector before page access; no deployed UI pass or real purchase is claimed. Full evidence and limitations: #2071 (comment) . Existing local Chrome and regression proof remains in the earlier verification comment.