Deferred follow-up to the config-gated verification policy: a grace mode letting an unverified user try a bounded amount of value before verifying.
Why deferred / blocking constraints:
- Granting any ability requires provisioning an org, which fires the signup grant (welcome units) → an unverified throwaway account would get the full free budget. Grace needs a separate small verified-gated budget OR signup-grant suppression for unverified orgs FIRST.
- The "verified" enforcement must live in the billing quota check (
assertCanExecute) or a requireVerified route middleware, NEVER a CASL condition (the user is never the policy subject).
Build only after the budget guard is designed. Backlog.
Created via /dev:issue
Deferred follow-up to the config-gated verification policy: a
gracemode letting an unverified user try a bounded amount of value before verifying.Why deferred / blocking constraints:
assertCanExecute) or arequireVerifiedroute middleware, NEVER a CASL condition (the user is never the policy subject).Build only after the budget guard is designed. Backlog.
Created via /dev:issue