feat(api,recs): execute-any/own permission gate on direct execute (closes #289)

[cristim]

Summary

Implements #289: permission-gated direct purchase execute via two new RBAC verbs.

• execute-any:purchases -- holder can directly execute any purchase, bypassing the approval email.
• execute-own:purchases -- holder can directly execute purchases they themselves submitted.
• Admins implicitly satisfy the gate (role check short-circuits permission lookup).
• Neither verb is in DefaultUserPermissions; granting them is an explicit opt-in by a superadmin.

Backend (commit 45f0fed)

• auth/types.go: ActionExecuteOwn + ActionExecuteAny constants.
• config/types.go: three nullable audit fields on PurchaseExecution (executed_by_user_id, executed_at, pre_approval_skip_reason).
• Migration 000057: ALTER TABLE purchase_executions ADD COLUMN IF NOT EXISTS for the three audit columns + partial index idx_executions_direct_execute.
• store_postgres.go: INSERT, all SELECT RETURNING clauses, and scanExecutionRows updated to carry the new columns.
• handler_purchases.go: authorizeSessionExecuteDirect (fail-closed, nil-safe), directExecutePurchase (stamps audit fields, delegates to ApproveAndExecute), and execute_mode="direct" branch in executePurchase.
• 4 new handler test scenarios covering the permission matrix.

Frontend (commit d85d9e3)

• permissions.ts: 'execute-own' and 'execute-any' added to the Action union.
• api/purchases.ts: optional executeMode param forwarded as execute_mode in POST body.
• api/types.ts: direct_execute?: boolean on PurchaseResult.
• recommendations.ts: currentExecuteMode module state with getExecuteMode / clearExecuteMode exports; openPurchaseModal conditionally renders the radio-group toggle + warning callout for privileged sessions, plain approval note otherwise.
• app.ts: reads execute mode in handleExecutePurchase; confirmation copy, toast, and button label vary by mode.
• 6 new tests in execute-mode-toggle.test.ts.

Test plan

• go test ./internal/api/ ./internal/auth/ ./internal/config/ -- all pass (2407 tests).
• frontend: jest --testPathPattern='execute-mode-toggle' -- 6 pass.
• frontend: jest --testPathPattern='recommendations-permissions' -- 5 pass.
• go build ./... clean.
• npx tsc --noEmit clean.
• go run ./cmd/gen-permissions -- no diff to permissions.generated.ts (new verbs not in DefaultUserPermissions).
• Manual: admin session sees toggle in purchase modal; non-admin sees only approval note.
• Manual: selecting "Execute Now" changes button label to "Execute Purchase Now" and shows red confirmation dialog.
• Manual: execute_mode:"direct" appears in POST body only when toggle is on.
• Manual: backend returns 403 for a session without execute-any/own when execute_mode=direct is posted.
• Manual: successful direct execute returns direct_execute: true in response and skips approval email.

[coderabbitai]

Warning

Rate limit exceeded

@cristim has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 38 minutes and 48 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 5ba6deb2-25bb-43b5-9f1a-802823d6a541

📥 Commits

Reviewing files that changed from the base of the PR and between 4956d66 and a14ca03.

📒 Files selected for processing (14)

• frontend/src/__tests__/execute-mode-toggle.test.ts
• frontend/src/api/purchases.ts
• frontend/src/api/types.ts
• frontend/src/app.ts
• frontend/src/permissions.ts
• frontend/src/recommendations.ts
• internal/api/handler_purchases.go
• internal/api/handler_purchases_test.go
• internal/auth/types.go
• internal/config/store_postgres.go
• internal/config/store_postgres_pgxmock_test.go
• internal/config/types.go
• internal/database/postgres/migrations/000058_purchase_executions_direct_execute_audit.down.sql
• internal/database/postgres/migrations/000058_purchase_executions_direct_execute_audit.up.sql

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/289-wave3

---

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

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[cristim]

_pr-iterate: CR has not delivered a substantive review on this PR despite 5 @coderabbitai review pings since May 28. The May 28 reply explicitly stated "Your organization has run out of usage credits"; subsequent pings (May 30, Jun 1 x3, Jun 3) only triggered the "Review triggered" auto-reply with no follow-up review body, consistent with an ongoing CR-side billing block. Per the pr-iterate skill's Phase 5b Case B (org credits exhausted) + Case E (CR unreachable after 15min) the loop is stopped without further auto-pings.

PR otherwise merge-ready:

• mergeStateStatus: CLEAN
• mergeable: MERGEABLE
• statusCheckRollup: 5/5 SUCCESS (AWS Sanity, Azure Sanity, Frontend build, pre-commit, CodeRabbit status)
• 4 commits, +802 / -53 LoC, last commit a14ca0370 extracts buildApprovalPendingResponse to keep executePurchase under the gocyclo budget.

Independent permission-bypass audit (manual, in lieu of CR):

• ActionExecuteOwn / ActionExecuteAny are deliberately NOT in DefaultUserPermissions(); the code comment flags them as finance-impacting + explicit-grant-only.
• authorizeSessionExecuteDirect is a hard 403 gate called between persistExecutionAndSuppressions and ApproveAndExecute, not a soft-fallback to the email flow.
• The execute-own ownership check explicitly defends against the empty-string collision (session.UserID != "" && creatorID != "" && creatorID == session.UserID).
• nil-auth returns 500 (fail-closed), not 200.
• Admin API-key path (Role: "admin" from requirePermission) correctly admitted via the role short-circuit; no new escalation.
• A 403 from the direct-execute gate leaves the row in pending and degrades naturally to the approval flow (no harmful side-effect).
• Test coverage (internal/api/handler_purchases_test.go): 4 new scenarios, including the no-permission 403, execute-any 200, execute-own owner 200, and execute-own non-owner 403; all green locally (go test ./internal/api/... -run 'DirectExec|authorizeSessionExecuteDirect' -count=1).

Re-invoke /pr-iterate 803 after the org's CR billing is topped up to get a substantive CR pass. To clear the wave-level marker after billing is fixed: rm ~/.claude/agent-comms/cr-rate-limit-deadline.txt.

[coderabbitai]

@cristim — thanks for the detailed manual audit and the patience through the billing disruption. The security reasoning you've documented looks thorough:

• Fail-closed nil-auth (500 not 200) ✓
• Empty-string collision guard on execute-own ✓
• Hard 403 gate (not a fallback) between persist and execute ✓
• New verbs absent from DefaultUserPermissions ✓
• Admin role short-circuit doesn't introduce new escalation paths ✓
• 403 degrades gracefully back to the pending/approval flow ✓

I'll kick off a full review pass now to give the PR a proper automated look.

(╯°□°）╯ ᵒʰ ᶰᵒ... credits! → 🐇 ✅ back in action

---

🧠 Learnings used

Learnt from: cristim
Repo: LeanerCloud/CUDly PR: 0
File: :0-0
Timestamp: 2026-05-05T15:44:54.463Z
Learning: In the LeanerCloud/CUDly repository, when a CodeRabbit review flags something as "outside-diff" that was already implemented in an earlier commit of the same PR, it is likely a stale-snapshot artifact where the review diff was generated against a pre-fix view. The inline comment convention `(CR pass on PR #<number> Finding N)` is used by the maintainer (cristim) to mark lines that were changed in direct response to a prior CodeRabbit review pass.

---

Learnt from: cristim
Repo: LeanerCloud/CUDly PR: 507
File: frontend/src/app.ts:388-395
Timestamp: 2026-05-20T08:26:42.493Z
Learning: In `frontend/src/app.ts` (CUDly project), `openArcheraOfferModal('purchase')` is intentionally called immediately after the `executePurchase` approval-submission API call returns success (in `handleExecutePurchase` and `handleFanOutExecute`), NOT after the async email-link execution completes. This timing was explicitly revised from the original issue `#499` requirement. The offer is gated on the submission success path only (never on failure/throw), and the fan-out path requires at least one successful submission (`succeeded > 0`).

---

Learnt from: cristim
Repo: LeanerCloud/CUDly PR: 507
File: frontend/src/app.ts:388-395
Timestamp: 2026-05-20T08:26:36.680Z
Learning: In `frontend/src/app.ts` (CUDly project), `openArcheraOfferModal('purchase')` is intentionally called immediately after the `executePurchase` approval-submission API call returns success (in `handleExecutePurchase` and `handleFanOutExecute`), NOT after the async email-link execution completes. This timing was explicitly revised from the original issue `#499` requirement. The offer is gated on the submission success path only (never on failure/throw), and the fan-out path requires at least one successful submission (`succeeded > 0`).

✅ Actions performed

Full review triggered.