Protected ReadonlydbStaticinstanceThe process default: built from each dependency's own instance().
ACTIVE → DISABLED. Disabling a disabled rule is a no-op success.
The approval a payment needs: the steps of every ACTIVE rule that matches,
grouped by rule name. A rule matches when every key it sets matches
(productIds and categories on the payment's product, minAmountUsd
against the BE-6 figure, inclusive). A payment with no USD figure (target
amount only) matches an amount rule, so dual control is never bypassed.
approverKeys are what the rail's confirm action checks, plus
transactions/metadata:w: an approver executes the payment. The requester
never counts as an approver (D4).
Creates a rule, or edits an ACTIVE one when rule.id is set. Edits never
touch in-flight requests: a request snapshots its requirements.
The dashboard user (cdu_…) writing the rule.
Rule CRUD for customer admins, and
requirementsFor, which the payment confirm flow calls to learn what approval a payment needs. Recording thetransactionApprovalRule.*activities is the caller's job, as for every other dashboard action (createUserActivity).