Skip to content

Guard manual implicit verification to VerificationPending with mandatory email check #131

@HunteRoi

Description

@HunteRoi

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

  1. Admin implicit verification is valid only when the current member state is VerificationPending.
  2. If the current state is anything else, the override request is rejected.
  3. If the user has no stored email, the override fails hard.
  4. A valid override completes the transition VerificationPending -> Verified.
  5. Every accepted and rejected attempt must be auditable with a reason code.

Acceptance Criteria

  1. Override request from VerificationPending succeeds only when email exists.
  2. Override request from any other state is rejected.
  3. Missing email produces hard failure, not silent fallback.
  4. Successful override writes transition source and reason code.
  5. 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:
    • TRC-008
    • TRC-009
  • Related docs:
    • docs/specs/traceability-matrix.md
    • docs/specs/issue-drafts.md
    • docs/specs/state-machine.md
    • docs/specs/bpmn-lifecycle.md

Related Issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions