Summary
Constrain admin implicit verification so it is only allowed from VerificationPending, requires a stored email, and fails hard in all other cases.
Problem
The specification allows an admin to implicitly verify a user, but only in a very narrow and explicit situation:
- the user must currently be in
VerificationPending
- the user must already have an email stored
- the transition must complete verification without code entry
- all other states must reject the override
Without this guard, admin override becomes ambiguous and can corrupt lifecycle integrity.
Why This Matters
This rule protects:
- correctness of the membership state machine
- auditability of manual intervention
- integrity of the verification lifecycle
- consistency between bot-side and web/API-side behavior
It also ensures that manual override is a point-in-time operational action, not a loosely defined shortcut.
Required Behavior
- Admin implicit verification is valid only when the current member state is
VerificationPending.
- If the current state is anything else, the override request is rejected.
- If the user has no stored email, the override fails hard.
- A valid override completes the transition
VerificationPending -> Verified.
- Every accepted and rejected attempt must be auditable with a reason code.
Acceptance Criteria
- Override request from
VerificationPending succeeds only when email exists.
- Override request from any other state is rejected.
- Missing email produces hard failure, not silent fallback.
- Successful override writes transition source and reason code.
- Rejected override writes failure reason or audit record as specified.
Suggested Implementation Targets
- src/events/interactionCreate.ts
- src/services/PostgresDatabaseService.ts
- prisma/schema.prisma
Suggested Technical Direction
Model admin implicit verification as a guarded state transition, not as a loose role mutation.
The write path should validate:
- expected state
- expected version
- email presence
- transition source = manual override
If any precondition fails, no state mutation should occur.
Validation
- unit test: override succeeds only from
VerificationPending
- unit test: override fails from
Verified
- unit test: override fails from any pre-verification state
- unit test: missing email causes hard failure
- integration test: successful override emits correct transition metadata
Traceability
- Spec: docs/specs/issue-93-specification.md
- Matrix rules:
- Related docs:
- docs/specs/traceability-matrix.md
- docs/specs/issue-drafts.md
- docs/specs/state-machine.md
- docs/specs/bpmn-lifecycle.md
Related Issues
Summary
Constrain admin implicit verification so it is only allowed from
VerificationPending, requires a stored email, and fails hard in all other cases.Problem
The specification allows an admin to implicitly verify a user, but only in a very narrow and explicit situation:
VerificationPendingWithout this guard, admin override becomes ambiguous and can corrupt lifecycle integrity.
Why This Matters
This rule protects:
It also ensures that manual override is a point-in-time operational action, not a loosely defined shortcut.
Required Behavior
VerificationPending.VerificationPending -> Verified.Acceptance Criteria
VerificationPendingsucceeds only when email exists.Suggested Implementation Targets
Suggested Technical Direction
Model admin implicit verification as a guarded state transition, not as a loose role mutation.
The write path should validate:
If any precondition fails, no state mutation should occur.
Validation
VerificationPendingVerifiedTraceability
Related Issues