[cristim]

Part of #1746 (slice A, A4: the step cap for bound plans). Builds on #1774 (bound plan validation), #1834 (bound group resolution and the arming re-check) and #1843 (display and bound_count), all merged.

What

A bound plan (allocation_mode: bound_groups) has groups with their own caps, so the step cap has to be checked per group, not only for the whole step.

• StepCapApplies now includes bound plans (internal/purchase/step_cap.go). The two approval sites share it, so they cannot drift: the attach path (internal/purchase/plan_step_attach.go) and the email approval path (internal/api/handler_purchases.go) both call it instead of their own AutoPurchase || MaxStepCommitment != nil test.
• checkBoundStepCap maps every recommendation in a step to a bound group, whether or not a cap is set:
  • a recommendation outside every group is refused with ErrRecOutsideBoundGroups, which wraps ErrStepCommitmentCap, so existing handling of that error still applies;
  • each group is kept under its own cap, and the step total under the plan cap, so the effective cap is the smaller of the two;
  • an auto-purchase bound plan still needs a plan cap; a manual one, where a human approves each row, may have none, and still gets its group caps and mapping checked.
• The function is split into three small helpers (boundGroupOf, boundStepTotals, checkBoundGroupCaps) so each stays under the repo's gocyclo limit of 10.

Tests

internal/purchase/step_cap_bound_test.go (new): a group over its own cap is refused and named; groups within their caps and the plan cap pass; the plan cap still applies to the total; a recommendation in no group is refused; an auto plan with no plan cap is refused even with group caps; a manual plan with no caps checks only the mapping; a manual plan with no plan cap still checks group caps; StepCapApplies itself; and a guard that unmarked plans behave exactly as before.

Verification

Local, macOS, on a fresh branch off main at the time of the push, cherry-picked and committed with every pre-commit hook:

• go build ./... OK;
• go test -p 2 on internal/purchase and internal/api passes;
• golangci-lint v2.10.1 on ./internal/...: 0 issues.

The change is on the purchase approval path, but it only adds refusals: a recommendation outside its group, or a group or step over its cap, is refused before approval, and unmarked plans are unaffected (guard test). No purchase is made by any test or check. Integration suites run in CI.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 39 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: LeanerCloud/cloud-commitments-platform
• Branch: feat/1746-step-cap-per-group
• File: .coderabbit.yaml
• Commit: 0bde75a
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 135ebe6e-e860-4d3c-82ca-ed2ec193b6c3

Commits

Reviewing files that changed from the base of the PR and between a534930 and 0bde75a.

Files selected for processing: 7

• internal/api/handler_purchases.go
• internal/api/handler_purchases_plan_step_approve_test.go
• internal/purchase/errnotes.go
• internal/purchase/plan_step_attach.go
• internal/purchase/plan_step_attach_integration_test.go
• internal/purchase/step_cap.go
• internal/purchase/step_cap_bound_test.go

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

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

[cristim]

CHANGES REQUESTED b1183e2 by claude-qa-ui-3

Cold review (money path). The cap logic is right for every value I tried, and unmarked plans behave as before. Three findings: two test gaps that leave the PR's main claims unpinned, and one fail-open edge in the group cap.

Findings

1. internal/purchase/plan_step_attach.go:187 and internal/api/handler_purchases.go:1507 (should-fix, test gap): nothing pins that either site uses StepCapApplies.

   • Reverting the attach site to locked.AutoPurchase || locked.MaxStepCommitment != nil leaves internal/purchase green, and reverting the handler to !plan.AutoPurchase && plan.MaxStepCommitment == nil leaves internal/api green.
   • What the revert would let through: a manual bound plan with group caps and no plan cap is skipped by the old gate. Its group caps and its "recommendation outside every group" refusal would never run at attach, nor for an email-link approver.
   • That is the case the PR exists for, and the body says the sites share the function so they cannot drift. Every new test calls CheckStepCommitmentCap directly.
   • Fix: add a manual-bound-plan test at each site.
     • Handler: a manual bound plan with no plan cap and an over-cap group should answer 403 from approveConstraintsForSession. The fixtures in handler_purchases_plan_step_approve_test.go:219-246 already cover the plan-cap version.
     • Attach: the same case in TestAttachIntegration_NoMatchAndCap (plan_step_attach_integration_test.go:125), since attachWithinCap needs a transaction.

2. internal/purchase/step_cap.go:96 and :148 (should-fix, test gap): the cap boundary is not tested. Changing total > cap to >= at either site (plan cap on the bound path, group cap) leaves the suite green. The tests use 100 against 150, or 200 against 150, never a total at the cap.

   • The current behavior is the right one and consistent with the unbound rule: a step exactly at the cap passes.
   • Fix: a short table for both the plan cap and a group cap, at cap minus 0.01, cap and cap plus 0.01.

3. internal/purchase/step_cap.go:148 (should-fix, small production change): a group cap that is NaN or +Inf passes everything. I ran the edge values against the checker, with a 100.00 step and a plan cap of 1e9:

   group cap	result
   99.99	refused
   100 (equal)	passes
   100.01	passes
   0 and -5	refused
   NaN	passes
   +Inf	passes

   The plan-level cap refuses the same values: 0, -5 and NaN each answer "plan has no max_step_commitment set". planCapUsable exists so a bad stored cap fails closed, and this function is documented as failing closed. The group path has no equivalent.

   • Write-time validation (StepCapCents in validation_bound_groups.go:81-84) rejects such caps, so they can't be saved through the validated API. A plan edited directly in the store, or by an older writer, could still carry one, and then the group cap is silently off.
   • Fix: refuse an unusable group cap at check time (finite and greater than 0, as planCapUsable does), or at least write the comparison as !(totals[g] <= *gc), which refuses NaN. Add a test for NaN and +Inf.

Attacked and holds

• Where it is enforced. Not only at write time.
  • CheckStepCommitmentCap itself dispatches on bound plans (step_cap.go:53-55), so the scheduler's pre-execution check (manager.go:985) and the post-claim re-check (step_cap.go:169-176) pick up the group caps with no further change.
  • Approval re-reads the plan, so a cap lowered after a step was attached is caught at approval.
  • A plan that is not marked bound takes the old path, which is identical.
• Plan cap 0, negative or NaN. Refused as "no cap", also for a manual plan that sets a cap pointer to 0 (step_cap.go:89).
• Groups with no cap. On an auto plan with a plan cap they count toward the plan total. On a manual plan with no caps only the mapping is checked, which the test pins. Unmarked behavior is pinned by the guard test.
• Identity in two groups. The map built by boundGroupOf takes the last group in map order, so it would be non-deterministic. Validation refuses it (checkGroupBindings, validation_bound_groups.go:105-117), so a validated plan can't hold one.
• Probes killed by existing tests:
  • rec outside every group no longer refused (killed by TestCheckStepCommitmentCap_BoundPlans);
  • auto bound plan allowed without a plan cap (same test);
  • StepCapApplies ignoring bound plans (TestStepCapApplies);
  • the bound dispatch removed from CheckStepCommitmentCap (TestCheckStepCommitmentCap_BoundPlans).
• API error shape (observation, not a finding). The email-link path answers 403 with the full error text (handler_purchases.go:1510). The new refusals add the group key and the recommendation ID to that text. The plan-level message already carried the amounts, and the approver holds the step anyway. Other surfaces collapse a cap error to its fixed sentinel text via ServerNoteMessage, so the stored reason will not distinguish "outside a group" from "over a cap".
• Session approvers with an approve verb. They are held to their own constraints and not to this cap (approveConstraintsForSession). That is the same as for the plan cap before this PR, and attach already refuses an over-cap step.

Probes (scratch worktree, scoped -run, heavy-review-2): baseline passes, go vet clean.

CI: 42 pass, 1 neutral (CodeRabbit) at this SHA. All three findings can be closed with tests plus a one-line change; no design change is needed.

[cristim]

CHANGES REQUESTED b1183e2 by claude-ui-fix-1

Cold review of a purchase-approval cap, with a cold reviewer and compile-checked mutation probes (go test -run 'StepCap|BoundStep|Bound' ./internal/purchase/; the api cap tests pass at baseline). I found no correctness defect in the production code. Three money-path behaviors are unproven by the tests, because their mutants survive, and they should be pinned before this merges. CI was still running when I looked: pre-commit, Frontend build and the sentinel are green, and CI - Build & Test is in progress.

Required (test gaps; each is a surviving mutant):

1. No boundary tests (internal/purchase/step_cap_bound_test.go, whole file). Every over-cap case is 200 against 150, so changing > to >= on the group cap (step_cap.go:148) and on the bound plan cap (step_cap.go:96) both survive. Add C-1, C and C+0.01 for both the group cap and the plan cap: a step exactly at the cap must pass and one cent over must refuse.
2. The monthly part of the total is never exercised. Every fixture has MonthlyCost nil, so the "upfront only" mutant survives. Add a recommendation with a MonthlyCost and a group cap that only the monthly part pushes over.
3. A nil group cap next to a plan cap is untested. The mutant gc == nil || totals[g] > *gc (a nil group cap read as a zero cap) survives. Add: plan cap 1000, group A with a nil cap, group B capped, recommendations in both, expect no error.

Low (suggested in the same round):
4. boundGroupOf (step_cap.go:104-111) ignores ServiceConfig.Enabled, but the resolver (planstep/resolve.go:228, boundServiceOf) treats only enabled groups as owners. A recommendation bound only by a disabled group maps to it and passes under its cap where the resolver would not judge it. Permissive, and only reachable by a stored step approved after the operator disabled the group. Skip disabled groups (so the recommendation is refused as outside every group), or document why not, with a test.
5. If two groups hold the same identity (stored data from before write-time validation rejected it), the last one wins in map order, which is nondeterministic. Iterate in sorted key order and refuse a duplicate.
6. A stored NaN group cap makes totals > NaN false, so it silently means no cap. Write time rejects it (StepCapCents, validation_bound_groups.go:81), but the plan cap fails closed through planCapUsable; a gc > 0 guard would make the group path symmetric.
7. errnotes.go:214 returns only the generic cap text for any wrapped error, so the "group X over cap" detail never reaches the live-response notes. The 403 on the email-approval path (handler_purchases.go:1510) carries the full text.

Follow-up (pre-existing, not a regression): the per-group cap is enforced at attach, at the scheduler claim for auto plans, and at email-token approval. Approved or scheduled rows (scheduled_fire.go, reaper.go, claim.go) are not rechecked at fire time. That is already true of the plan cap, so a step approved by a session holder or the admin key, or approved before a group was widened, can execute over a group cap. Worth an issue.

What held:

• Boundary and units: the group path uses the same total helper as the plan cap (capCommitment → upfront + monthly × term × 12, USD or empty currency) and the same strict >, so there is no new drift.
• Group mapping: it uses config.RecIdentityKey, the same function and key set as the resolver, so term, payment and account differences map to "outside every group". Fresh steps always map, since the resolver and Precheck guarantee it.
• Plan cap: nil, non-positive, NaN and Inf plan caps fail closed. Group-cap write validation applies at write time.
• Behavior change: a manual bound plan with no caps now has its mapping checked at attach and at email approval. I found no flow that is newly refused, and unmarked plans are untouched (guard test).
• Arming: an auto bound plan with no plan cap is already not armed and is refused at run time and at attach. StepCapApplies only adds the manual bound case.
• Error shape: 403 with a message naming only the plan's own group, a recommendation id and amounts. The wrap keeps errors.Is(ErrStepCommitmentCap) true for every existing caller.

Mutation probes: 10 mutants; 6 caught (skip group caps, skip the outside-every-group refusal, drop the plan-cap total check, ignore bound plans, drop the no-cap skip, drop the auto/plan-cap-required check) and 4 survived (the first three findings above, plus the >= on the plan cap).

Once the three required tests land (and they should kill those four mutants), I'll re-run the probes and approve the new head.

[cristim]

APPROVE @ b1183e2 by claude-nibblets

Cold review of #1872 (Part of #1746, A4: the step cap for bound plans, +214/-4, money path).

Read: StepCapApplies now includes bound plans, and the two approval sites that had their own test (internal/purchase/plan_step_attach.go:187 and internal/api/handler_purchases.go:1507) call it, so they cannot drift. checkBoundStepCap (internal/purchase/step_cap.go) maps every rec to its group by identity and refuses one outside every group (ErrRecOutsideBoundGroups, which wraps ErrStepCommitmentCap, so existing handling of that error still applies); an auto-purchase bound plan, or one with a set plan cap that is unusable, still needs a usable plan cap (errNoPlanCap, fail closed); each group is held under its own cap and the step total under the plan cap. A manual bound plan with no caps is still mapped and group-capped. Each rec's commitment goes through capCommitment (USD only, positive and finite) wherever a cap applies to it.

Attacks I tried that do not work: an identity in two groups would make the rec-to-group map depend on map iteration order, but validateBoundGroups refuses an identity bound twice, within or across groups, and group caps go through StepCapCents at save; the other cap sites are consistent (the auto-approve check in internal/purchase/manager.go:985 and the post-claim recheck at :261 only run for auto-claimed rows and call the same CheckStepCommitmentCap).

Scoped probes (go test -run StepCap|BoundStep|StepCommitment|PlanStep, scratch worktree at this head, baselines for internal/purchase and internal/api ok), killed: bound plans not subject to the cap (TestStepCapApplies); unmapped rec allowed, plan-cap total not checked, group cap not enforced, auto bound plan without a cap accepted (all TestCheckStepCommitmentCap_BoundPlans).

Non-blocking:

• A probe that loosened the group-cap comparison by one dollar (totals[g] > *gc to totals[g] >= *gc+1) survived: no test puts a group total just above its cap (for example cap plus 0.01) or pins the equal-to-cap case, so please add one boundary row to TestCheckStepCommitmentCap_BoundPlans.
• planCapUsable exists so an unusable plan cap fails closed, but a group's cap is not run through the same check at read time; save-time validation (StepCapCents) covers it and JSON cannot hold NaN or Inf, so I treat it as a hardening nit.

CI at this head: 42 pass, 1 skipping (CodeRabbit); mergeStateStatus was still UNKNOWN when I looked.

[cristim]

Round 2 at 0bde75a: the fix commit 8c6e7db plus a merge of current main (fast-forward from b1183e2, no force push). It answers both CHANGES REQUESTED verdicts at b1183e2 (claude-qa-ui-3 and claude-ui-fix-1).

Tests the reviewers asked for (internal/purchase/step_cap_bound_test.go unless noted):

• Boundaries (both): TestCheckStepCommitmentCap_BoundCapBoundary runs the plan cap and a group cap at cap plus a cent, the cap, and cap minus a cent: the first two pass and the last is refused. Both > to >= mutants are killed.
• Monthly cost (ui-fix-1): ..._BoundCountsMonthlyCost uses a rec of 50 upfront plus 10 a month (170 total); a cap of 150 refuses it and 170 passes. A mutant that sums only the upfront part is killed.
• Nil group cap under a plan cap (ui-fix-1): ..._BoundNilGroupCapUnderAPlanCap.
• Both approval sites use StepCapApplies (qa-ui-3):
  • Handler: TestApproveViaToken_PlanStep_ManualBoundPlanGroupCaps (internal/api) runs a manual bound plan with group caps and no plan cap through the email-link approval: 403 over cap, 403 for a rec outside every group, and a pass under the cap. Reverting the handler to the old condition fails it.
  • Attach: a new subtest in TestAttachIntegration_NoMatchAndCap runs the same plan against real PostgreSQL, attaching into its pre-created root row: the step is marked failed with the group named. Reverting the attach site to the old condition makes exactly this subtest fail, which I ran before pushing.

Behaviour changes (all fail closed; one small production change):

• Unusable group cap (both): a group cap that is NaN, +Inf, zero or negative now refuses the step with "no usable max_step_commitment". A shared capUsable predicate (step_cap.go) is used by the plan cap and the group cap, which closes the NaN and +Inf gap.
• Disabled groups (ui-fix-1): boundGroupOf skips a disabled group, as the resolver does, so a rec bound only to one is outside every group.
• Duplicate identity (both): an identity bound by two groups is refused, with the pair named from sorted keys so the note is stable. Validation already rejects this, but a stored plan could hold one.
• History notes (both): the group-level refusals now reach the History note with their group key, as closed text (a key plus amounts). "Outside every group" keeps only the fixed head, because its message carries a rec id and so an account.

Independent pre-commit review (two passes by the same Opus reviewer, no actionable findings): 13 of its 16 probes were killed at first, and I fixed the 3 survivors (zero cap assertion, the duplicate pair order, the exponent branch of the note pattern), which are now killed too.

Noted, not changed: the email-link 403 returns the raw cap error text, as it already did for other refusals such as the non-USD message, so an approver can see a rec id there. The other concern, whether an approved or scheduled step is re-checked at fire time, is filed as #1873, worded as unconfirmed.

Gates: go build, go vet -tags integration, the unit suites for internal/purchase and internal/api, and golangci-lint (0 new issues against main) on the merged tree. CI is running on 0bde75a.

@claude-qa-ui-3 @claude-ui-fix-1 deltas over b1183e2..0bde75a please, covering the fix commit and a clean merge of main. Per the landing rule I merge once "CI Success" and "Run pre-commit hooks" are green, and I will fix first anything you post at this head.

[cristim]

APPROVED 0bde75a by claude-qa-ui-3

Delta review from my CHANGES REQUESTED at b1183e2. All three findings are fixed and killed by tests, and I found nothing new. The delta is the fix commit 8c6e7db (+261 across 5 files, about 40 lines of it production) and a merge of main whose --remerge-diff is empty, so there was no hand resolution.

My findings, each closed

1. The call sites (was plan_step_attach.go:187, handler_purchases.go:1507): fixed.
   • Reverting the handler to the old gate now fails TestApproveViaToken_PlanStep_ManualBoundPlanGroupCaps (403 over a group cap with no plan cap, 403 for a rec outside every group, a pass under the cap).
   • Reverting the attach site to the old gate fails TestAttachIntegration_NoMatchAndCap against real PostgreSQL. I ran this one myself.
2. The cap boundary (was step_cap.go:96 and :148): fixed. Changing > to >= at the plan cap or at a group cap is killed by TestCheckStepCommitmentCap_BoundCapBoundary, which tests cap plus a cent, the cap and cap minus a cent, plus the monthly-cost and nil-group-cap tests.
3. A group cap of NaN or +Inf failing open (was step_cap.go:148): fixed.
   • A shared capUsable (step_cap.go:73-81, a positive finite number) now serves both the plan cap and the group cap, and an unusable group cap refuses the step, naming the group (:176-178).
   • A capUsable that accepts NaN, one that accepts +Inf, and a dropped group-cap check are each killed by ..._BoundGroupCapUnusableFailsClosed and ..._BoundRefusalNotesKeepTheGroup.

The new behavior, probed

• Disabled groups. boundGroupOf skips them, so a rec bound only to one is outside every group, which fails closed. Dropping the skip is killed by ..._BoundDisabledGroupIsOutside.
• Identity in two groups. It is refused, naming the pair from sorted keys. Dropping the check is killed by ..._BoundIdentityInTwoGroupsIsRefused.
• Monthly cost. A cap that counts only the upfront part is killed, including by TestAttach_CapIsCheckedOnTheLockedPlan.
• History notes. The group-level refusals reach the stored note through boundGroupCapNotePatterns (errnotes.go:103-112).
  • The group key charset is closed. The unusable-cap value pattern covers NaN, +Inf, -Inf and Go's %v numbers.
  • The "outside every group" refusal keeps only its fixed head, since it carries a rec id.
  • Changing the "has no usable" wording in the pattern is killed by ..._BoundRefusalNotesKeepTheGroup.

Probes at this SHA (scratch worktree, scoped -run, heavy-review-2)

• Baseline passes. go vet and go vet -tags integration are clean.
• All 13 probes above are killed by named tests. My first run of the handler revert and the note-pattern change were my own mistakes (a mutation that did not compile, and one that broke the regex); both were redone and are killed.

Observation, not a finding. The email-link 403 still returns the raw cap error text, as before this PR. Whether an approved or scheduled step is re-checked at fire time is filed by the author as #1873, worded as unconfirmed; I did not review that.

CI: at this SHA, 9 passed, 6 in progress and 23 queued when I posted (the integration suites, E2E, Unit Tests and Lint Code had not finished). My local probes do not replace them; merging needs CI Success and Run pre-commit hooks green at 0bde75a. 0 unresolved threads.

[cristim]

APPROVE @ 0bde75a by claude-nibblets

Delta b1183e2..0bde75a (money path): two merges of main (remerge-diffs are empty, so no conflict resolution) and one fix commit, 8c6e7db, which addresses both non-blocking notes from my first verdict.

• capUsable (internal/purchase/step_cap.go) now covers plan and group caps: a cap that is not a positive finite number refuses the step, so a NaN or Inf group cap can no longer switch the check off.
• boundGroupOf skips a disabled group (as the resolver does, so its identities are outside every group) and refuses an identity bound by two groups, visiting keys in sorted order so the refusal names the same pair every time. The group-level refusals reach the History note with the group key (closed text, key and amounts; the "outside every group" note keeps only its head because it would carry a rec id).
• Boundary tests pin cap minus a cent, the cap and plus a cent for the plan cap and a group cap, and both approval sites (email-link approval and attach) are tested as running the group check for a manual bound plan with no plan cap.

Scoped probes (go test -run StepCap|BoundStep|StepCommitment|PlanStep|ErrNote|ServerNote|History in internal/purchase, plus internal/api, scratch worktree at this head, baselines ok), each killed: NaN counted as a usable cap (TestCheckStepCommitmentCap_BoundGroupCapUnusableFailsClosed and others); disabled group not skipped (_BoundDisabledGroupIsOutside); duplicate identity not refused (_BoundIdentityInTwoGroupsIsRefused); group-cap boundary refused (_BoundCapBoundary, _BoundCountsMonthlyCost); cap plus a cent allowed (_BoundCapBoundary, the survivor I reported before); unusable group cap ignored (_BoundGroupCapUnusableFailsClosed).

CI at this head: Lint Code, Unit Tests and Integration Tests (api, purchase) pass; 39 pass, 1 pending, 1 skipping.

[cristim]

APPROVED 0bde75a by claude-ui-fix-1

Delta review of b1183e2..0bde75a (fix commit 8c6e7db and two merges of main), with a cold reviewer, 11 compile-checked mutation probes and the real-PostgreSQL attach test. All seven findings from my CHANGES REQUESTED are closed, each pinned by a test that fails under its mutant. At the time I looked, CI - Build & Test was still running; the merge needs it and Run pre-commit hooks green at this head.

Findings 1-7, all closed:

1. Boundary: > to >= on the group cap or the bound plan cap fails BoundCapBoundary and BoundCountsMonthlyCost (cases 100.01, 100, 99.99).
2. Monthly cost: the upfront-only mutant fails the attach tests and BoundCountsMonthlyCost (170 against 150).
3. Nil group cap under a plan cap: a nil cap read as a refusal fails BoundNilGroupCapUnderAPlanCap; the nil-cap group counts toward the plan total and adds no group limit.
4. Disabled groups: boundGroupOf (internal/purchase/step_cap.go, ~:124) skips them as the resolver does, so a rec bound only to one is outside every group. Removing the skip fails BoundDisabledGroupIsOutside.
5. Duplicate identity: refused, naming the same pair on every check (sorted keys; 20 loops). Removing the refusal or the sort fails BoundIdentityInTwoGroupsIsRefused.
6. NaN and infinite group caps: capUsable (positive and finite) now fails closed for NaN, +Inf, 0 and negative. Accepting NaN fails BoundGroupCapUnusableFailsClosed.
7. History notes: the new patterns in errnotes.go (boundGroupCapNotePatterns) match the messages exactly and sit inside the anchored note expression, so the group detail reaches the note and nothing wider can. "Outside every group" collapses to the fixed head, with no rec id or account; a group key with a space or ; falls back to the head. Removing the patterns fails BoundRefusalNotesKeepTheGroup.

Edges:

• A group is checked only if the step has a recommendation in it, so an unusable cap on an uninvolved group does not block the step. A disabled group's cap is never reached.
• Zero-total and non-USD recommendations go through the same capCommitment as the plan cap, so they are refused identically. The only exception is a manual bound plan with no plan cap and no cap for that group, where only the group mapping is checked, as documented.
• "No usable max_step_commitment" is reachable only for plans stored outside validation (validation_bound_groups.go:82 rejects such caps at write time) and it fails closed.
• Unmarked plans behave as before: the unmarked path is the old logic refactored, capUsable adds nothing to the old !(cap>0) for NaN, and the guard test passes.

Both approval sites: TestAttachIntegration_NoMatchAndCap runs the manual-bound-plan case against real PostgreSQL (an over-cap group ends as a failed row naming the group) and fails if StepCapApplies ignores bound plans. The email-link approval site has its own test, TestApproveViaToken_PlanStep_ManualBoundPlanGroupCaps (under-cap reaches approve; over-cap and another identity return 403), which fails under the same mutant.

Merges: both merge commits equal git merge-tree --write-tree of their parents, and outside the PR's own 7 files the branch equals main.

Lint: golangci-lint v2.10.1 (CI's) with --new-from-rev=origin/main on ./internal/purchase/... and ./internal/api/... reports 0 issues.

Info, non-blocking:

• StepCapApplies(nil) returns false (handler_purchases.go:1507), where the old inline test would have panicked. It is not reachable, since GetPurchasePlan returns ErrNotFound rather than a nil plan; refusing on a nil plan would be optional hardening.
• On the attach path the stored refusal text has a trailing "(recommendations: ids)" that fails the note's end anchor, so History shows only the head there; the live-response notes and the email-approval 403 carry the group detail. This is the same for the plan cap and is pre-existing.
• gofmt -l lists internal/api/handler_ri_exchange_direct_resolve_body_test.go, which is not in this PR (it is a main-side issue).
• Follow-up, pre-existing: approved and scheduled rows are not rechecked at fire time, so a step approved before a group was widened can still execute over a group cap. Worth an issue.

[cristim]

Merged as 5d417dc (squash, --match-head-commit 0bde75a). The gate held: approvals at the head from claude-qa-ui-3 and claude-ui-fix-1 (both CHANGES REQUESTED at b1183e2 were closed by round 2), "CI Success" and "Run pre-commit hooks" green after a close-and-reopen (the first CI run never created CI Success; see the comments above), 0 open threads, CLEAN, all commits mine. #1746 stays open (slice A4 landed; the follow-ups #1857 and #1873 are filed).