[IAmJSD]

Summary

This PR fixes one boundary of #361: the purchases spend cap. MaxPurchaseAmount on a group permission, or max_amount on an API key, is denominated in USD. Before this PR it was compared against the raw amount of a purchase in any currency. The other boundaries are listed in the table below.

Refs #361

Root cause

The cloud-commitments-go side of the class (go#124, closed) added common.Recommendation.CommitmentCurrency. The pinned AWS parsers set it for RIs and Savings Plans, and so do the pinned GCP Compute Engine, Cloud SQL and Memorystore clients. The platform lost it at the first boundary:

• scheduler.convertRecommendations built a config.RecommendationRecord with no currency field, so the stored recommendation, the execution row and every rec handed to enforcePurchaseConstraints carried bare numbers.
• purchaseConstraintSets then put the batch's total commitment into MaxPurchaseAmount. The auth matcher compared it against the USD cap.

The result: a purchase priced at 2,400 EUR passed an approve-any cap of 2,400 USD (2400 <= 2400) and was bought. In general, whichever way the exchange rate points, the comparison either lets through a purchase over the operator's ceiling or refuses a legal one.

Fix

• internal/config/types.go: new RecommendationRecord.CommitmentCurrency (commitment_currency). It is persisted inside the recommendations row's JSONB payload and the execution's recommendations JSONB. No DDL and no migration. An empty value means unknown. It is never defaulted to USD.

• internal/scheduler/scheduler.go: convertRecommendations copies the provider's CommitmentCurrency onto the record.

• internal/planstep/resolve.go: size takes the currency from the stored row it prices from, not from the displayed row. The costs are the stored row's, so their currency must be too.

• internal/api/purchase_currency.go (new) and enforcePurchaseConstraints: if any rec in the batch is not provably USD (another currency, or empty or whitespace), the constraint sets are checked with an amount the matcher can never satisfy (math.MaxFloat64).

  • A grant that carries any MaxPurchaseAmount refuses the batch with a 403 that names the currency. The message still contains "constraints".
  • A grant with no amount cap still allows it.
  • If another dimension (account, provider, service, region, or a malformed negative cap) also refuses the batch, that dimension's own error is returned, as before.
  • An auth backend error is returned unchanged and not retried.

  This is the same rule checkAzureExecuteConstraints already applies on the Azure RI exchange path. Because enforcePurchaseConstraints is the single choke point, the rule covers every money path that calls it:

  • web execute
  • direct execute (execute-any/own)
  • session approve and token approve (approve-any/own)
  • run-now
  • retry
  • all four post-claim re-checks (claimed_row_check.go)

• Where the currency comes from. priceFromStored copies the stored row (out := *stored), so the currency used on the web execute path is the stored one. A request body that says "commitment_currency":"USD" cannot lift the refusal, and a test pins this.

I chose fail-closed over conversion because the issue rules out FX conversion and a currency field on the cap ("deliberately not in scope", PR #1515). A guardrail that cannot establish the denomination of the amount it checks has not checked anything.

Boundaries of #361: status after this PR

Boundary	Where	Status
Purchases MaxPurchaseAmount / API-key max_amount vs rec amounts	enforcePurchaseConstraints (all purchase money paths)	Fixed here
Recommendation currency dropped at collection	scheduler.convertRecommendations	Fixed here
Plan-step pricing takes currency from the right row	planstep.size	Fixed here
AWS RI exchange max_payment_due_usd vs quote currency	go ExecuteExchange (go#203)	Covered by go#203. Open PR #1212 (fix/issue-521) maps ErrQuoteNotUSD to 422. Not duplicated here
Azure RI exchange MaxPurchaseAmount vs exchange currency	checkAzureExecuteConstraints	Already fail-closed on main
maxPayment, _ := maxRat.Float64() drops the exactness flag	handler_ri_exchange.go	Left alone. The file is touched by open PRs #1212, #1116, #1191, #1243, #1246, #1172, #1175
firstNonEmptyCurrency defaults reshape output to "USD"	handler_ri_exchange.go	Deferred for the same reason. #1246 (fix/issue-1206) edits the function that calls it
Plan max_step_commitment vs step total (auto-purchase, and the email-token approver with no approve verb)	purchase.CheckStepCommitmentCap, requirePlanStepCap	Not fixed. Needs an owner decision. Every auto-purchase step must have this cap, and the pinned Azure provider never sets CommitmentCurrency. Failing closed here would stop every Azure auto-purchase plan until the go side populates Azure currency. The edit is small (about 20 lines in step_cap.go, separate from #1245's hunk in the same file)
Azure revoke refund-divergence guard	handler_purchases_revoke.go	Its own issue (cli#1555). checkConfirmedRefund already refuses a currency mismatch
ri_exchange_history.payment_due has no currency column	daily-cap ledger	Out of scope per the issue, until a second currency is supported
Azure recommendations carry no currency	pinned providers/azure 3def3f89	Go side. Until a go bump populates it, Azure recs are "unknown" (see below)

Behavior change to review

• Existing stored recommendations have no currency until the next collection. Until then, a user or API key with a spend cap is refused on every purchase. Users and keys without a cap, and the admin key, are not affected. The 403 tells the caller to refresh recommendations. AWS and GCP recs carry a currency after one refresh.
• Azure purchases under a capped grant stay refused until the go Azure parsers set CommitmentCurrency. That is fail-closed by design: the cap cannot be checked against an amount of unknown currency.
• Pending executions created before deploy also carry no currency. A capped approve-any/approve-own approver is refused on them. They can be approved by an uncapped approver or the admin key, or cancelled and resubmitted after a refresh.

Verification

All evidence below is unit tests against mocks/fixtures, plus real-Postgres integration tests on the shared testcontainers Postgres. No real cloud API was called and nothing was purchased. Tests ran with AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null AWS_EC2_METADATA_DISABLED=true.

New tests:

• internal/api/purchase_currency_test.go (unit; the mock answers with the real auth.PermissionsAllowForConstraintSets):
  • TestEnforcePurchaseConstraints_NonUSDUnderCapRefused: 900 EUR / JPY / empty / whitespace against a 1,000 USD cap, for execute, execute-any, approve-any and approve-own.
  • ..._MixedBatchRefused
  • ..._USDStillComparedAgainstCap: USD, usd, USD. Over the cap is still refused.
  • ..._NonUSDWithoutCapAllowed
  • ..._NonUSDOtherDimensionKeepsItsError
  • ..._NonUSDBackendErrorPropagates: exactly one auth call.
  • TestHandler_executePurchase_NonUSDStoredPriceUnderCapRefused: the full web execute path with a stored EUR row and a request claiming USD. Nothing is saved.
• internal/planstep/resolve_test.go: TestResolveTakesCurrencyFromStoredRow.
• internal/scheduler/scheduler_test.go: TestScheduler_ConvertRecommendations_CommitmentCurrency.
• internal/api/combined_plan_purchase_integration_test.go (real Postgres): TestCombinedPlanPurchase_NonUSDApprovalRefusedUnderCap. A 2,400 EUR stored recommendation goes through UpsertRecommendations, then the scheduler's plan-step attach (SendUpcomingPurchaseNotifications), then the purchase_executions row. The test asserts EUR round-trips to the execution row. Then POST /api/purchases/approve/{id} with an approve-any cap of 2,400 and of 1,000,000 must be 403 naming EUR, with nothing bought. With no cap it must be 200 and complete.

Existing fixtures that model USD recs under a cap now say CommitmentCurrency: "USD" (they had no currency, which now means unknown). fanoutRecs() and the combined-plan fixture default to USD, so the existing claimed-row and combined-plan integration tests still exercise the USD cap. No assertion was weakened.

Fail before. I put back origin/main's handler_purchases.go, planstep/resolve.go and scheduler/scheduler.go and kept the new tests:

• Unit: TestEnforcePurchaseConstraints_NonUSDUnderCapRefused, ..._MixedBatchRefused, TestHandler_executePurchase_NonUSDStoredPriceUnderCapRefused, TestResolveTakesCurrencyFromStoredRow and TestScheduler_ConvertRecommendations_CommitmentCurrency all fail.
• Real Postgres: TestCombinedPlanPurchase_NonUSDApprovalRefusedUnderCap fails with expected: 403, actual: 200 and body {"status":"completed"}. The 2,400 EUR step was approved under the 2,400 USD cap and bought: f.service.recorded() is non-empty.

Pass after. Commands:

go build ./... && go vet ./... && go vet -tags integration ./...
go test ./internal/api/ -count=1          # ok
go test ./internal/planstep/ -count=1     # ok
go test ./internal/scheduler/ -count=1    # ok
go test ./internal/config/ -count=1       # ok
go test ./internal/mocks/ -count=1        # ok
go test -tags integration -count=1 -timeout 60m -run 'TestCombinedPlanPurchase_|TestClaimedRowCheck_Postgres' ./internal/api/   # ok
golangci-lint v2.10.1 run --allow-parallel-runners [--build-tags integration] ./internal/api/ ./internal/planstep/ ./internal/scheduler/ ./internal/config/   # 0 issues (both)
gocyclo -over 10 -ignore "_test\.go" <changed non-test files>   # silent
bash scripts/gosec-hook.sh <changed non-test .go files>        # clean
gofmt -l internal/                                              # clean

The machine was heavily loaded (load average about 24, about 50 containers from parallel suites). Two integration runs hit testcontainers start-up flakes: a reaper container in "removing" state, and 90-second subtests. Each test passed when re-run. The full run of the targeted set passed once with all green. I did not run whole integration packages or git-secrets here; the combined-tree run covers them.

Combined-tree verification. This branch was tested together with the other queued branches on a local, never-pushed tree: queue/platform @ 936996ad = origin/main a14dc8f2 plus these heads, merged in this order:

Branch	Tested head
fix/issue-337	ff3420c
fix/issue-169	7d75eb5
fix/issue-342	66b221f
fix/issue-310	5e11c21
fix/issue-326	5f0ea59
fix/issue-243	365e959
fix/issue-343	6c94036
fix/issue-312	d2848a8
fix/issue-316	acd60dd
fix/issue-339	75ea9b9
fix/issue-339-commitment-type	73bdb19
fix/issue-353	5d25fcd
fix/issue-313	3156bc4
fix/issue-357	53d9e58
fix/issue-368	0ba727d
fix/issue-419	61648c9
fix/issue-111	b04c372
fix/issue-686	0ad90b7
fix/issue-674	793095d
fix/issue-1055	4ec96f1
fix/issue-559	dfa9525
fix/issue-558	034eed4
fix/issue-874	1720539
fix/issue-666	1e120da
fix/issue-668	fb26345
fix/issue-568	ce04173
fix/issue-311	e54f250
fix/issue-177	0cbb88a
fix/issue-151	c21377c
fix/issue-166	41fb77b
fix/issue-27	2d67622
fix/issue-323	69288ae
fix/issue-59	36463e8
fix/issue-43	35e4069
fix/issue-158	6f76f8a
fix/issue-104	bb00491
fix/issue-55	971ef1b
fix/issue-361	89ac220
fix/issue-120	b458719
fix/issue-36	42bac6e
fix/issue-525	57c97dd
fix/issue-712	e5bcda0
fix/issue-72	6cc63ed

fix/issue-72 and fix/issue-312 conflict on one line in internal/api/handler_dashboard.go (both change the calculateCommitmentMetrics call). The tree used #72's side with #312's validated provider variable; whichever PR merges second takes that same resolution.

Linux, Go 1.26.9, AWS_CONFIG_FILE=/dev/null AWS_SHARED_CREDENTIALS_FILE=/dev/null AWS_EC2_METADATA_DISABLED=true; Docker Postgres via testcontainers:

• Passed at 936996ad: go build ./..., go vet ./..., go vet -tags integration ./... and the full go test -race -short -count=1 ./....
• Static checks at 936996ad: golangci-lint v2.10.1 found 0 issues on every changed package, with and without --build-tags integration. tests/e2e is a separate module, so it was vetted under its own e2e tag. gocyclo -over 10 is silent on the changed non-test files.
• Integration tests, every changed package, one package at a time (-tags integration -count=1, 60-minute local timeout because the VM was shared):
  • At 936996ad, these pass: internal/server, internal/credentials, internal/scheduler, internal/database/postgres/migrations, internal/purchase and internal/api.
  • internal/config passes except TestPostgresStoreDB_ResolveStaleRIExchange_ValidatesCloudCheck, which fails the same way on unmodified main (fixed by fix(config): compare resolve checked_at at the database's microsecond precision #1252).
  • These were run on the first build of this tree (26795376, same branches at earlier heads): internal/analytics, internal/auth, internal/commitmentopts, internal/database and cmd/lambda/clear-rate-limit all pass. The later fixes don't touch those packages.
• What the combined run caught, each fixed on its own branch before this PR opened:
  • a compile break between fix/issue-104's test and fix/issue-326's httpToLambdaRequest signature change;
  • fix/issue-316 rejecting legacy-keyed plans;
  • fix/issue-120 versus main's global-filter test.
• Secrets: git-secrets, using the repo's scripts/setup-git-secrets.sh patterns in a fresh repo with an isolated HOME, found nothing in the changed files, and a planted fake key was flagged. scripts/test-git-secrets-allowlist.sh: 137 PASS, 0 FAIL.
• Nothing was applied to any cloud.

Not in scope

• The plan max_step_commitment boundary and the two handler_ri_exchange.go items. See the table for why each was deferred.
• Populating Azure CommitmentCurrency. That belongs to cloud-commitments-go.
• A Money type, or a currency field on the caps. The issue rules both out.

Frontend follow-up for the UI owner

No frontend files are changed. The recommendations API now returns commitment_currency on each rec, and the field is omitted when unknown. Two UI changes would help:

• The recommendations and purchase screens hard-code $. They could show the currency, or flag a rec with an unknown or non-USD currency.
• They could warn that a capped user's purchase of such a rec will be refused.

The new 403 is a plain {"error": ...} message, so the existing error toast already shows it.

Labels

A maintainer, please mirror the issue's triage labels: priority/p2, severity/high, urgency/this-quarter, impact/few, effort/l, type/bug, triaged.

🤖 Generated with Claude Code

[coderabbitai]

Caution

Review failed

The pull request is closed.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: APPROVE ac1dda6fa0d459e56890e31cdea3f7851f9758d6

Blocking:

• none

Non-blocking:

• internal/api/purchase_currency.go: the fail-closed rule has a large blast radius on deploy. Every stored rec and every pending execution has no commitment_currency until the next collection, and the pinned Azure provider never sets it. So every capped user or capped API key is refused on every Azure purchase, and on every AWS/GCP purchase until a refresh. The PR body says so. The acting owner should accept that consciously and ideally schedule the go-side Azure currency bump alongside.
• The max_step_commitment plan-step cap (purchase.CheckStepCommitmentCap, requirePlanStepCap) still compares a non-USD step total against a USD cap on the auto-purchase and email-token paths. It is disclosed as needing an owner decision, and Refs #361 (not Closes) is correct. Neither of the issue's two named instances in handler_ri_exchange.go is fixed here either.
• The combined-tree table lists fix/issue-361 at 89ac220, not this head (ac1dda6). I re-ran the relevant checks on this head and on this head merged with current main (eb9e480, 81 commits ahead of the merge base). Both are clean.

Attacked:

• Matcher semantics. In matchPurchaseAmountConstraint, a cap of 0 means no cap, so the math.MaxFloat64 sentinel refuses any positive cap and passes an uncapped grant. It is not Inf, so invalidRequestedAmount does not trip early. The second check uses amount 0, which always passes a well-formed cap, so it isolates other-dimension denials. A negative cap stays deny-all, and an auth backend error short-circuits with one call. The admin key still bypasses in requirePermissionConstraints.
• Currency provenance. The Postgres store reads recs back from JSONB payload, so the field round-trips. priceFromStored takes the currency from the stored row (out := *stored), so a client "commitment_currency":"USD" is ignored. planstep.size takes it from the stored row too. scheduler.convertRecommendations is the only non-test place that constructs a RecommendationRecord, so no other path rebuilds recs field by field and drops the currency. recommendationID doesn't include the currency, so rec IDs don't change. In the pinned AWS parser, commitmentCurrency returns the CE currency for all three payment options when the legs are complete.
• Ran: go build ./...; go vet (plain and -tags integration) on api/planstep/scheduler/config; go test -race -short -count=1 on the same four packages (ok); go test -race -tags integration -run 'TestCombinedPlanPurchase_|TestClaimedRowCheck_Postgres' ./internal/api/ (ok; TestCombinedPlanPurchase_NonUSDApprovalRefusedUnderCap confirmed to run, not skip, 8.9s on real Postgres); golangci-lint v2.10.1 with and without the integration tag (0 issues); gocyclo -over 10 on the changed files (silent). The same build, vet and unit run on a local merge with current main also passed.
• Fail-before: I checked out the merge-base versions of handler_purchases.go, planstep/resolve.go and scheduler/scheduler.go and kept the new tests. TestEnforcePurchaseConstraints_NonUSDUnderCapRefused, TestResolveTakesCurrencyFromStoredRow and TestScheduler_ConvertRecommendations_CommitmentCurrency all fail. Restored afterwards. (Main's current handler_purchases.go no longer compiles against this branch, so "put back origin/main's" in the body now means the merge base.)

Body-stale:

• "Fail before. I put back origin/main's handler_purchases.go ...": against today's main that file no longer compiles with the branch. The claim holds against the merge base (1c5787a), which is where I reproduced it.

_{Reviewer: rB22. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths.}

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): VERDICT: APPROVE ac1dda6fa0d459e56890e31cdea3f7851f9758d6

Blocking:

• none

Non-blocking:

• Rollout / product decision (owner): once this deploys, every user or API key with a MaxPurchaseAmount/max_amount is refused on every purchase until the next recommendation collection. Stored recs and pending executions have no commitment_currency, so they read as "unknown". Capped Azure purchases stay refused until cloud-commitments-go populates Azure CommitmentCurrency; the pinned providers/azure never sets it (I checked the module cache: only providers/aws recommendations/parser_{ri,sp}.go and gcp computeengine/cloudsql/memorystore set it). This is fail-closed and matches sec(money): currency is dropped at every layer boundary, so USD-denominated caps are compared against non-USD amounts [platform part] #361's stated rule. Still, the acting owner should sign off on it and plan a recommendations refresh right after deploy. The body discloses all of this.
• Coverage gap (disclosed): the plan max_step_commitment path (purchase.CheckStepCommitmentCap / requirePlanStepCap) still compares non-USD totals against a USD cap. That covers auto-purchase and the email-token approver with no approve verb. Refs #361, not Closes, is correct for that reason.
• internal/api/purchase_currency.go:58: requireUncappedPurchaseGrant makes two auth round-trips when the sentinel check is refused. That only happens on the denial path, so it is fine.

Attacked:

• Currency provenance: every enforcePurchaseConstraints caller (web execute through priceFromStored's out := *stored, direct execute, session and token approve, retry, the claimed-row re-checks) gets recs from the store or from the persisted execution row, never from a client-supplied currency. recommendationID doesn't hash the new field, so rec IDs stay stable. Sentinel semantics against matchPurchaseAmountConstraint: math.MaxFloat64 is finite, so it isn't rejected as invalid, and any positive cap refuses it. A cap of 0 (no cap) still allows. The second check with amount 0 correctly separates a cap denial from an account/provider/service/region denial, including with multiple grants. The admin API key short-circuits as before.
• Fail-before: I disabled the nonUSDPurchaseCurrency branch in enforcePurchaseConstraints and the scheduler copy. TestEnforcePurchaseConstraints_NonUSDUnderCapRefused, TestHandler_executePurchase_NonUSDStoredPriceUnderCapRefused and TestScheduler_ConvertRecommendations_CommitmentCurrency failed, and so did the real-Postgres TestCombinedPlanPurchase_NonUSDApprovalRefusedUnderCap: 200 {"status":"completed"}, with the EUR step bought. Restored afterwards.
• Ran go build ./..., go vet ./..., go vet -tags integration ./..., go test -race -short -count=1 and go test -race -tags integration -count=1 on internal/{api,config,planstep,scheduler} (all ok), golangci-lint with and without the integration tag (0 issues) and gocyclo -over 10 on the changed files (silent).

Body-stale:

• The boundary table says "Open PR fix(ri-exchange): answer the go exchange refusals with 422 instead of 500 #1212 (fix/issue-521) maps ErrQuoteNotUSD to 422". fix(ri-exchange): answer the go exchange refusals with 422 instead of 500 #1212 is now merged.
• (From an earlier review, confirmed:) the combined-tree table and the "Fail before" section refer to head 89ac220 and "origin/main's" files. Today's main handler_purchases.go no longer compiles with this branch, so that claim only holds against the merge base.
• (From an earlier review, confirmed:) neither of the two instances sec(money): currency is dropped at every layer boundary, so USD-denominated caps are compared against non-USD amounts [platform part] #361 names in handler_ri_exchange.go (max_payment_due_usd, firstNonEmptyCurrency) is fixed here. Refs is right, and those still need their own PRs.

_{Reviewer: rB24. Bar while the maintainers are away (set by IAmJSD as acting owner): one approving independent review on the head, two for money, auth and security paths.}

[cristim]

Independent review 1 (cold, fresh context):

VERDICT: APPROVE ac1dda6

Reviewed: git diff origin/main...ac1dda6 (one non-merge commit 89ac220 plus a merge of main 1c5787a). PR OPEN. CI: 34 pass, 1 skipping.

Findings:

• low (behavior change, disclosed) internal/api/purchase_currency.go:29 - empty currency is "unknown". Azure recs from the pinned providers/azure 3def3f89 never set CommitmentCurrency, and stored or pending rows from before deploy carry none. So every capped user or API key is refused on Azure purchases and on legacy pending executions until a refresh and a go bump. Fail-closed is the intended effect. Needs operator awareness.
• nit internal/api/purchase_currency.go:65 - the 403 echoes the provider-supplied currency string verbatim. Low risk because it is JSON-encoded and comes from provider data, not the request (priceFromStored copies the stored row, purchase_pricing.go:148).
• nit internal/api/purchase_currency.go:44 - the second probe (amount 0) is an extra auth round-trip, taken only on refusal. Acceptable.

Attacked:

• Entry points: every money path reaches enforcePurchaseConstraints before a provider call. Web execute: purchase_pricing.go:23, which prices from the stored row first. Direct execute any/own: handler_purchases.go:1583/1599, plus the post-claim check claimed_row_check.go:59. Session approve: :1226/:1240, plus the claim check. Token approve with a held verb: :1275/:1284. Run-now: :441, plus claimed_row_check.go:32. Retry: :2284. The AWS RI exchange is USD-checked in go pkg/exchange/exchange.go:360 (ErrQuoteNotUSD). The Azure RI exchange is already fail-closed (handler_ri_exchange.go:1124). Marketplace, ladder-resolve and revoke/cancel constraint calls carry no amount.
• Currency comes from data. The scheduler copies rec.CommitmentCurrency (scheduler.go:1755), and the only RecommendationRecord literal in non-test code is that one. The JSONB payload round-trips it (store_postgres_recommendations.go:156/371). recommendationID does not include the currency, so rec IDs do not change. planstep size takes it from the stored row. The pinned go modules set it: AWS parser_ri.go:237 and parser_sp.go:268 (empty unless every leg is proven), and GCP computeengine, cloudsql and memorystore. Azure sets none.
• Inputs: "" and whitespace give unknown and are refused. "usd" and " USD " are treated as USD (EqualFold + TrimSpace, tested). EUR/JPY are refused. In a mixed batch, one non-USD rec refuses the whole batch. A request body claiming USD cannot override the stored row.
• Matcher semantics (auth/purchase_amount_cap.go:28): the MaxFloat64 sentinel fails any cap > 0 and passes cap == 0. A negative or NaN cap denies both probes, so its own error is returned. An auth backend error is returned unchanged (not a 403). For API keys, both the key and the owner must pass (service_apikeys_api.go:426). With multiple permissions, an uncapped grant allows the batch, which is correct.
• State on refusal: pre-CAS refusal returns 403 with nothing written; the row stays pending or failed and can be retried by an uncapped approver. A post-claim refusal ends the row failed with no_submission (existing behavior).
• Test edits only add CommitmentCurrency:"USD" to fixtures. No assertion was weakened.
• Tests (scratch, mocks only): go build ./...; go test -race ./internal/api ./internal/planstep ./internal/scheduler ./internal/config all pass (5349 tests). Integration (real Postgres, testcontainers): TestCombinedPlanPurchase_* pass, including NonUSDApprovalRefusedUnderCap (ran with -v, PASS).
• Mutation probes (all KILLED, files restored and cmp byte-identical to the archive):
  m1 disable the currency branch in enforcePurchaseConstraints: 19 fails.
  m2 treat empty currency as USD: 9 fails.
  m3 drop the scheduler currency copy: 1 fail.
  m4 skip the other-dimension second probe: 1 fail.
  m5 drop the planstep currency copy: 1 fail.
  m6 treat a backend error as a 403 refusal: 1 fail.

One further finding, pre-existing and not introduced by this PR, has been reported privately to the maintainers.

[cristim]

Independent review 2 (claude-fleet, cold): REQUEST_CHANGES at ac1dda6

Blocking
One blocking finding has been reported privately to the maintainers.

Non-blocking

1. Entry-point coverage. The refusal sits in the choke point at internal/api/handler_purchases.go:3017-3026. Unit tests drive it directly and through the web execute path (purchase_currency_test.go:114).
   • Swapping the call for the currency-blind check at retry (handler_purchases.go:2284), direct execute-any (:1583) or session approve-any (:1226) leaves the unit suite green.
   • Approve-any is caught only by the integration test. Retry and direct execute are caught by nothing.
   • One table test per entry point would pin the routing.
2. purchase_currency.go:66-69: the error message says to "refresh the recommendations so they carry a USD price". A refresh cannot fix either of two cases, so the message should say so:
   • Azure recs, because the pinned provider never tags them;
   • non-USD GCP billing.
3. purchase_currency.go:26 accepts " usd " via TrimSpace and EqualFold. That is harmless today, because every path takes the currency from a server-side source (below). It is still looser than "provably USD", and a strict "USD" comparison would be simpler.

Entry point and per-purchase cap (MaxPurchaseAmount on a group permission or API-key max_amount): does the head refuse a price that is not provably USD?

• Web execute, which MCP also uses through the API (purchase_pricing.go:23): yes. The currency comes from the stored row (priceFromStored :150).
• Direct execute-any/own (:1583, :1599) and its post-claim check (claimed_row_check.go:59-62): yes.
• Session approve-any/own (:1226, :1240) and its post-claim check: yes.
• Token approve by a session that holds an approve verb (:1275, :1284): yes.
• Run-now (:441) and its post-claim check (claimed_row_check.go:32): yes.
• Retry (:2284): yes, using the currency persisted on the failed row.
• Azure RI exchange (handler_ri_exchange.go:1067): already fail-closed on main and untouched here.

Currency inputs. The currency flows from the go parser (scheduler.go:1755), into the JSONB payload, then through size or priceFromStored.

• "" becomes "unknown" and is refused under a cap (a test covers this, and probe M1 is caught). Whitespace only is refused (M2b).
• "usd", " USD " and "USD " are treated as USD and still compared against the cap. Over the cap is refused (USDStillComparedAgainstCap, M2).
• EUR, JPY and other ISO codes are refused under any cap and allowed with no cap.
• Old stored rows with no field have empty JSON, so the purchase fails closed. Nothing defaults to USD (M10 caught).
• A batch that mixes USD with EUR, or USD with empty, is refused (MixedBatchRefused, M6).
• A client-supplied "commitment_currency":"USD" is overwritten by the stored row (out := *stored). M4 caught.
• The AWS parser (providers/aws parser_ri.go:233-277) leaves the field empty unless every payment leg is known, with no USD default. GCP sets it from the pricing currency.
• The check runs inside enforcePurchaseConstraints, on the same slice that is priced and before the matcher, so nothing can change between the check and its use.

Fail-closed

• A pre-claim refusal returns 403 as a ClientError before any save or claim. The web test asserts that SavePurchaseExecution is never called (purchase_currency_test.go:134).
• The integration test (combined_plan_purchase_integration_test.go:333) covers both sides:
  • With a 2400 or 1e6 cap, the result is 403 naming EUR, and nothing is recorded.
  • With no cap, the result is 200 and the purchase completes.
• A post-claim refusal ends the row as failed with no_submission (claimed_row_check.go:11-21). This is unchanged, and nothing is left in running.
• Multi-rec batches are judged as a whole, so nothing is partially bought. A backend error is returned once and not retried (BackendErrorPropagates).
• No new email is sent on refusal.

Callers and consumers

• enforcePurchaseConstraints has the 11 call sites listed above.
• RecommendationRecord.CommitmentCurrency is new and omitempty. It is not part of recommendationID (scheduler.go:1148), RecIdentityKey or purchaseIdempotencyKey (:3383), so IDs and dedupe are unchanged.
• planstep.size has two callers, resolve.go:355 and :361.
• Nothing relied on "unknown currency means USD" except test fixtures, which now say USD. The diff only rewrites fixtures; no assertion was removed.
• One documented behaviour change: capped users are refused on pre-deploy rows and on Azure recs until a refresh or a go-side fix.

Migrations: none.

Probes (head export; each restored with cp and checked with cmp; the final diff against git archive is clean)

• Caught:
  • M1, empty treated as USD.
  • M2, strict case comparison. M2b, no trim.
  • M4, trust the client currency.
  • M6, the sentinel set to 0.
  • M7, drop the second check that tells currency refusals apart from other refusals.
  • M8, drop the currency in size.
  • M9, take the currency from the shown row.
  • M10, the scheduler defaults to USD.
• Partly caught:
  • M3b, drop the check at session approve-any: survives the unit suite, caught by integration.
  • M3c, drop it at run-now: caught only by the zero-commitment test.
• Survived:
  • M3a, drop the check at retry.
  • M3d, drop it at direct execute-any.
  • M5, check after the cap comparison. This one is decision-equivalent: only the error text differs.

Commands (GOTOOLCHAIN=go1.26.10, no cloud credentials)

• Fail-before: I ran the head tests against base handler_purchases.go, resolve.go and scheduler.go, without purchase_currency.go. NonUSDUnderCapRefused, MixedBatchRefused, NonUSDStoredPriceUnderCapRefused, TestResolveTakesCurrencyFromStoredRow and ConvertRecommendations_CommitmentCurrency all FAIL.
• Head:
  • go build ./... is ok.
  • go vet, with and without -tags integration, on api, planstep, scheduler and config: ok.
  • gofmt is clean.
  • Unit tests on those packages are ok.
  • golangci-lint 2.11.4 reports 0 issues, with and without integration tags.
• Integration, under the heavy lock: api -run 'TestCombinedPlanPurchase_|TestClaimedRowCheck_Postgres' is ok. The planstep, scheduler, config and purchase packages pass in full. I did not run the full api integration package.
• git show --remerge-diff on ac1dda6 is empty.
• merge-tree onto origin/main f316add is clean (tree 308cec8b). On the merged tree, build, vet and unit tests are ok, and the targeted integration tests pass.

Reviewed by an independent agent with no author context (second reviewer). Review only: nothing was pushed, and the GitHub review state is unchanged.

[IAmJSD]

Merged current main (6b586cc) into the branch. The merge was clean, with no conflicts. New head: cb36102547229bbe7a0e172cd40d369f6c56f7d4.

Checks on the merged tree, with no cloud credentials:

• go build ./..., go vet ./..., go vet -tags integration ./... and the e2e vet all pass.
• golangci-lint v2.10.1 (with and without --build-tags integration) and gocyclo -over 10 are clean on the changed packages.
• go test -race -short passes on internal/{api,config,planstep,scheduler}.
• go test -race -tags integration passes on internal/{api,config,scheduler} (testcontainers Postgres).
• The secrets scan prints "clean; planted key flagged", and scripts/test-git-secrets-allowlist.sh passes.

[IAmJSD]

Local verification at cb36102547229bbe7a0e172cd40d369f6c56f7d4 merged onto main (c8bb869f), together with #1296 in that order (combined tree 37eae2a1, Linux, Go 1.26.10): go build ./..., go vet with and without -tags integration, the full go test -race -short -count=1 ./..., and go test -race -tags integration -count=1 on every changed package, against Docker Postgres. All pass. CI Success and pre-commit are green on this head, with 3 approving independent review(s) on it. Nothing was run against any cloud.

[IAmJSD]

Merged by IAmJSD's agent at IAmJSD's request (IAmJSD is acting owner while the maintainers are away), under the bar IAmJSD set: 3 approving independent review(s) on cb361025 (two required: money, auth or security path), green CI, and the combined-tree verification above. Squash-merged at exactly cb36102547229bbe7a0e172cd40d369f6c56f7d4.