# 2. Account Verification — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: account_verification.md — every feature, sub-feature, and rule covered

---

## Test Execution Policy
- Zero tolerance: any deviation from documented behavior = FAILED = bug
- Every bug is immediately logged/reported (Bug ID, feature, sub-feature, expected vs actual, severity) and fixed 100% before the group passes
- Feature group passes only at 100% test pass rate

## Coverage Matrix
| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 2.1 Email Verification | Verification email with single-use time-limited link | TC-SA-01-02-001, TC-SA-01-02-002 |
| 2.1 Email Verification | Verification code alternative | TC-SA-01-02-003 |
| 2.1 Email Verification | Resend with cooldown and maximum count | TC-SA-01-02-004, TC-SA-01-02-005 |
| 2.1 Email Verification | Expired-link handling | TC-SA-01-02-006 |
| 2.1 Email Verification | Limited functionality during verification | TC-SA-01-02-007 |
| 2.1 Email Verification | Verification completion | TC-SA-01-02-008 |
| 2.1 Email Verification | Admin view of unverified accounts | TC-SA-01-02-009 |
| 2.1 Email Verification | Automatic expiry/deactivation | TC-SA-01-02-010 |
| 2.1 Email Verification | Logging of all verification events | TC-SA-01-02-011 |
| 2.1 Email Verification | Rule: link single-use and account-bound | TC-SA-01-02-012 |
| 2.1 Email Verification | Rule: resends rate-limited, support-assisted beyond max | TC-SA-01-02-013 |
| 2.1 Email Verification | Rule: email change triggers fresh verification | TC-SA-01-02-014 |
| 2.1 Email Verification | Rule: deactivation reversible within retention window | TC-SA-01-02-015 |
| 2.1 Email Verification | Rule: events visible in account activity history | TC-SA-01-02-016 |
| 2.1 Email Verification | Rule: verification required before gated actions | TC-SA-01-02-017 |
| 2.2 Phone Number Verification via OTP | OTP sent via SMS at registration and on change | TC-SA-01-02-018 |
| 2.2 Phone Number Verification via OTP | 6-digit code, validity window, attempt limit | TC-SA-01-02-019, TC-SA-01-02-020 |
| 2.2 Phone Number Verification via OTP | Resend cooldown and maximum count | TC-SA-01-02-021 |
| 2.2 Phone Number Verification via OTP | Country-code-aware entry with format validation | TC-SA-01-02-022 |
| 2.2 Phone Number Verification via OTP | Voice-call OTP fallback | TC-SA-01-02-023 |
| 2.2 Phone Number Verification via OTP | Verification completion enables SMS features | TC-SA-01-02-024 |
| 2.2 Phone Number Verification via OTP | Number change flow with identity check | TC-SA-01-02-025 |
| 2.2 Phone Number Verification via OTP | Admin view of unverified/failed phone accounts | TC-SA-01-02-026 |
| 2.2 Phone Number Verification via OTP | Delivery-failure handling with distinct outcomes | TC-SA-01-02-027 |
| 2.2 Phone Number Verification via OTP | Logging of all OTP and delivery outcomes | TC-SA-01-02-028 |
| 2.2 Phone Number Verification via OTP | Rule: OTP single-use, expires, fresh issuance after limit | TC-SA-01-02-029 |
| 2.2 Phone Number Verification via OTP | Rule: one number bound to one active account | TC-SA-01-02-030 |
| 2.2 Phone Number Verification via OTP | Rule: number change requires new-number + identity verification | TC-SA-01-02-031 |
| 2.2 Phone Number Verification via OTP | Rule: SMS failures produce retry path with voice fallback | TC-SA-01-02-032 |
| 2.2 Phone Number Verification via OTP | Rule: resends rate-limited per number and account | TC-SA-01-02-033 |
| 2.2 Phone Number Verification via OTP | Rule: events logged with channel/outcome/timestamp, failures reportable | TC-SA-01-02-034 |
| 2.2 Phone Number Verification via OTP | Rule: prerequisite for SMS login and SMS 2FA | TC-SA-01-02-035 |
| 2.3 Age Verification | DOB capture with validation and plausibility checks | TC-SA-01-02-036 |
| 2.3 Age Verification | Minimum-age policy configuration | TC-SA-01-02-037 |
| 2.3 Age Verification | Age-band classification | TC-SA-01-02-038 |
| 2.3 Age Verification | Feature gating for age-restricted features | TC-SA-01-02-039 |
| 2.3 Age Verification | Age re-verification with evidence | TC-SA-01-02-040 |
| 2.3 Age Verification | Parental routing below threshold | TC-SA-01-02-041 |
| 2.3 Age Verification | Admin view: age-band distribution and unconfirmed list | TC-SA-01-02-042 |
| 2.3 Age Verification | Logging of age events | TC-SA-01-02-043 |
| 2.3 Age Verification | Rule: age from DOB on record only | TC-SA-01-02-044 |
| 2.3 Age Verification | Rule: below minimum cannot self-register | TC-SA-01-02-045 |
| 2.3 Age Verification | Rule: gating enforced server-side | TC-SA-01-02-046 |
| 2.3 Age Verification | Rule: corrections require admin-assisted verification | TC-SA-01-02-047 |
| 2.3 Age Verification | Rule: age band drives consent requirements | TC-SA-01-02-048 |
| 2.3 Age Verification | Rule: age events audit-logged | TC-SA-01-02-049 |
| 2.3 Age Verification | Rule: stricter local-law threshold applies | TC-SA-01-02-050 |
| 2.4 Parental Consent Verification for Minors | Guardian identification at registration | TC-SA-01-02-051 |
| 2.4 Parental Consent Verification for Minors | Guardian identity verification | TC-SA-01-02-052 |
| 2.4 Parental Consent Verification for Minors | Guardian authority confirmation | TC-SA-01-02-053 |
| 2.4 Parental Consent Verification for Minors | Informed consent capture | TC-SA-01-02-054 |
| 2.4 Parental Consent Verification for Minors | Consent record linked to minor's account | TC-SA-01-02-055 |
| 2.4 Parental Consent Verification for Minors | Ongoing consent: review and withdrawal | TC-SA-01-02-056 |
| 2.4 Parental Consent Verification for Minors | Payment authorization by guardian | TC-SA-01-02-057 |
| 2.4 Parental Consent Verification for Minors | Admin view of minor consent status | TC-SA-01-02-058 |
| 2.4 Parental Consent Verification for Minors | Re-consent on material policy changes | TC-SA-01-02-059 |
| 2.4 Parental Consent Verification for Minors | Full audit logging of consent lifecycle | TC-SA-01-02-060 |
| 2.4 Parental Consent Verification for Minors | Rule: no full activity without verified consent | TC-SA-01-02-061 |
| 2.4 Parental Consent Verification for Minors | Rule: guardian identity verification mandatory | TC-SA-01-02-062 |
| 2.4 Parental Consent Verification for Minors | Rule: one guardian, multiple minor accounts | TC-SA-01-02-063 |
| 2.4 Parental Consent Verification for Minors | Rule: withdrawal honored per policy, minor notified | TC-SA-01-02-064 |
| 2.4 Parental Consent Verification for Minors | Rule: minor payments require guardian consent | TC-SA-01-02-065 |
| 2.4 Parental Consent Verification for Minors | Rule: versioned documents, re-consent on material change | TC-SA-01-02-066 |
| 2.4 Parental Consent Verification for Minors | Rule: lifecycle events audit-logged with guardian identity | TC-SA-01-02-067 |
| 2.4 Parental Consent Verification for Minors | Rule: stricter local child-protection law applies | TC-SA-01-02-068 |

## 2.1 Email Verification

### TC-SA-01-02-001 — Verification email with single-use time-limited link sent at registration
**Type:** Positive
**Covers:** 2.1 → Verification email with a single-use, time-limited link sent at registration
**Preconditions:** A new registration is possible; the configured link validity is known (e.g., 24 hours).
**Steps:**
1. Register a new account with a monitored test email address.
2. Observe the verification email arrival and its content.
3. Note the link and its stated validity.
**Expected Result:** A verification email arrives at the registered address containing a verification link; the link is time-limited per the configured validity (e.g., 24 hours); the email identifies the platform and the action required.
**Priority:** Critical

### TC-SA-01-02-002 — Verification link works within its validity window
**Type:** Positive
**Covers:** 2.1 → Verification link (functional within validity)
**Preconditions:** A fresh verification email with an unexpired link.
**Steps:**
1. Click the verification link from the email.
2. Observe the confirmation screen and the account state.
**Expected Result:** The link verifies the email successfully; the account is marked verified; the confirmation screen confirms success; the event is logged.
**Priority:** Critical

### TC-SA-01-02-003 — Verification code alternative works
**Type:** Positive
**Covers:** 2.1 → Verification code alternative for clients where links are inconvenient
**Preconditions:** A registration where the code alternative is available (e.g., mobile client).
**Steps:**
1. Register and receive the verification email containing the code.
2. Enter the code on the verification screen instead of clicking the link.
3. Observe the account state.
**Expected Result:** The code is accepted and the email is verified; the account reaches the verified state identically to the link path; the code method is logged as the verification method.
**Priority:** High

### TC-SA-01-02-004 — Resend verification with cooldown
**Type:** Positive
**Covers:** 2.1 → Resend verification with cooldown
**Preconditions:** An unverified account; the resend cooldown known.
**Steps:**
1. Trigger a resend of the verification email.
2. Observe the cooldown state of the resend control.
3. Wait for the cooldown and resend again.
**Expected Result:** A fresh verification email is sent on resend; the resend control shows a cooldown (disabled with countdown) after each send; resends after the cooldown succeed; each resend is logged.
**Priority:** High

### TC-SA-01-02-005 — Maximum resend count enforced
**Type:** Edge
**Covers:** 2.1 → Maximum resend count
**Preconditions:** An unverified account; the documented maximum resend count known (e.g., 3).
**Steps:**
1. Resend the verification email until the maximum count is reached.
2. Attempt one more resend.
3. Observe the offered alternative.
**Expected Result:** Resends succeed up to the maximum; beyond it, no further self-service resend is offered; the support-assisted resend path is presented; the limit and each resend are logged.
**Priority:** High

### TC-SA-01-02-006 — Expired link shows clear message with resend option
**Type:** Edge
**Covers:** 2.1 → Expired-link handling
**Preconditions:** A verification link that has passed its validity window.
**Steps:**
1. Click the expired link.
2. Read the message and available actions.
3. Use the resend option and verify with the fresh link.
**Expected Result:** The screen shows a clear "link expired" message (not a generic error) with a working resend option; the fresh link completes verification; the expiry event is logged.
**Priority:** High

### TC-SA-01-02-007 — Limited functionality during verification
**Type:** Edge
**Covers:** 2.1 → Account state during verification: limited functionality
**Preconditions:** A registered but unverified account.
**Steps:**
1. Log in with the unverified account.
2. Observe the persistent "verify your email" banner.
3. Attempt a restricted action (e.g., purchasing a membership).
4. Attempt an allowed action (e.g., browsing content).
**Expected Result:** The user can log in but sees the persistent verification banner; restricted actions are blocked with a message pointing to verification; allowed actions work; the limited state matches the documented restrictions.
**Priority:** High

### TC-SA-01-02-008 — Verification completion unlocks full functionality
**Type:** Positive
**Covers:** 2.1 → Verification completion
**Preconditions:** An unverified account with the banner and restrictions active.
**Steps:**
1. Complete email verification (link or code).
2. Observe the banner state.
3. Attempt the previously restricted action.
4. Check the account status in the directory and the event log.
**Expected Result:** The account is marked verified; the banner is removed; full functionality is unlocked (the previously restricted action now succeeds); the verification event is logged; the directory shows "Verified".
**Priority:** Critical

### TC-SA-01-02-009 — Admin view lists unverified accounts with registration date
**Type:** Positive
**Covers:** 2.1 → Admin view: list of unverified accounts
**Preconditions:** Multiple unverified accounts with known registration dates; Super Admin access to the user directory.
**Steps:**
1. Open the user directory.
2. Apply the "Unverified email" filter.
3. Verify the list contents and sorting.
**Expected Result:** The filtered list shows exactly the unverified accounts, each with its registration date; the list is sortable by registration date; verified accounts do not appear in the filtered view.
**Priority:** Medium

### TC-SA-01-02-010 — Automatic deactivation after policy period
**Type:** Edge
**Covers:** 2.1 → Automatic expiry: unverified accounts deactivated after the policy period
**Preconditions:** Unverified accounts older than the configured deactivation period (e.g., 7 or 14 days); the policy period known.
**Steps:**
1. Wait for/trigger the deactivation cycle for the aged unverified accounts.
2. Inspect the accounts' status.
3. Review the deactivation batch in the activity log.
**Expected Result:** The aged unverified accounts are automatically deactivated; each deactivation carries a notification to the user; the batch is reviewable in the activity log with the count matching the eligible accounts; younger unverified accounts are untouched.
**Priority:** High

### TC-SA-01-02-011 — All verification events logged
**Type:** Positive
**Covers:** 2.1 → Logging of all verification events (sent, clicked, verified, expired, resent)
**Preconditions:** Scenarios to produce each event type; log access available.
**Steps:**
1. Produce a send, a resend, a click, a successful verification, and an expiry.
2. Locate all five events in the verification log.
3. Inspect each event's fields.
**Expected Result:** All five event types are present with timestamps and account context; the sequence matches the actual operations; each event type is distinguishable.
**Priority:** High

### TC-SA-01-02-012 — Link is single-use and account-bound
**Type:** Negative
**Covers:** 2.1 → Rule: link single-use and bound to the account
**Preconditions:** A verification link that has already been used (account verified).
**Steps:**
1. Click the already-used link again.
2. Attempt to use the link from a different account context (logged in as another user).
**Expected Result:** Both attempts show the appropriate "already verified" or "invalid" message; no state change occurs; the link cannot be replayed or applied to a different account; the attempts are logged.
**Priority:** Critical

### TC-SA-01-02-013 — Resend abuse prevented; support-assisted beyond max
**Type:** Negative
**Covers:** 2.1 → Rule: resends rate-limited; exceeding maximum requires support-assisted resend
**Preconditions:** An unverified account; the maximum resend count known.
**Steps:**
1. Attempt rapid successive resends during the cooldown.
2. Exhaust the maximum count.
3. Attempt further self-service resends.
**Expected Result:** Rapid resends during cooldown are blocked; after the maximum, self-service resends are unavailable and the support-assisted resend path is the only option; all attempts (allowed and blocked) are logged; no email burst can be triggered.
**Priority:** High

### TC-SA-01-02-014 — Changing a verified email triggers fresh verification
**Type:** Edge
**Covers:** 2.1 → Rule: verified email later changed → fresh verification of the new address
**Preconditions:** A fully verified account; access to change the account email.
**Steps:**
1. Change the account email to a new (monitored) address.
2. Observe the account state immediately after the change.
3. Complete verification of the new address.
4. Observe the account state after verification.
**Expected Result:** After the change the account re-enters the limited/unverified state for the new address (banner, restrictions); the new address receives a verification email; after verifying the new address the account returns to fully verified; both the change and the re-verification are logged.
**Priority:** Critical

### TC-SA-01-02-015 — Deactivated unverified account restored on re-verification
**Type:** Edge
**Covers:** 2.1 → Rule: deactivation reversible within the retention window
**Preconditions:** An account deactivated for long-unverified email; still within the retention window.
**Steps:**
1. Trigger/complete re-verification for the deactivated account (admin resend + user verification).
2. Inspect the account state and its data.
**Expected Result:** The account is restored to active with its data intact; the restoration is logged; the user regains full functionality; accounts beyond the retention window are not restored by this path.
**Priority:** High

### TC-SA-01-02-016 — Verification events visible in account activity history
**Type:** Positive
**Covers:** 2.1 → Rule: all verification events visible in the account's activity history
**Preconditions:** An account with multiple verification events; Super Admin access to the account record.
**Steps:**
1. Open the account record's activity history.
2. Locate the verification events (sent, resent, verified, etc.).
3. Verify each event's details.
**Expected Result:** All verification events for the account appear in its activity history with timestamps and outcomes; the history matches the central verification log; no event is missing.
**Priority:** Medium

### TC-SA-01-02-017 — Gated actions blocked until verification
**Type:** Negative
**Covers:** 2.1 → Rule: verification required before certain actions per policy
**Preconditions:** An unverified account; policy gating configured (e.g., purchasing a membership, receiving OTP logins to that email).
**Steps:**
1. Attempt a gated action (e.g., start a membership purchase) while unverified.
2. Attempt to receive an OTP-based login to the unverified email.
3. Complete verification and repeat both actions.
**Expected Result:** Both gated actions are blocked while unverified with a message requiring verification; after verification both succeed; the gating matches the policy configuration exactly.
**Priority:** High

## 2.2 Phone Number Verification via OTP

### TC-SA-01-02-018 — OTP sent via SMS at registration and on number change
**Type:** Positive
**Covers:** 2.2 → OTP sent via SMS at registration (and on number change)
**Preconditions:** A registration flow with phone entry; a monitored test number.
**Steps:**
1. Register with the test phone number and trigger the verification OTP.
2. Observe the SMS delivery.
3. Later, initiate a number change and observe the OTP to the new number.
**Expected Result:** An SMS OTP is delivered to the entered number at registration; on a number change, an OTP is delivered to the new number; both deliveries are logged with the channel.
**Priority:** Critical

### TC-SA-01-02-019 — Phone OTP is 6-digit with validity window
**Type:** Positive
**Covers:** 2.2 → 6-digit code with validity window
**Preconditions:** A phone verification in progress; the configured validity known (e.g., 5 minutes).
**Steps:**
1. Trigger the OTP and inspect its format.
2. Observe the countdown on the entry screen.
3. Wait past the validity window and submit the code.
**Expected Result:** The code is exactly 6 numeric digits; the entry screen shows the validity countdown; after the window the code is rejected as expired with a resend option; the expiry is logged.
**Priority:** High

### TC-SA-01-02-020 — Phone OTP attempt limit enforced
**Type:** Negative
**Covers:** 2.2 → Attempt limit (e.g., 5)
**Preconditions:** A fresh phone OTP; the documented attempt limit known.
**Steps:**
1. Enter wrong codes until the limit is reached, reading the message each time.
2. Enter the correct (originally issued) code after the limit.
**Expected Result:** Each wrong entry decrements the visible attempt count; after the limit the code is invalidated ("request a new code" state); the originally correct code is now rejected; a fresh issuance is required; all attempts are logged.
**Priority:** Critical

### TC-SA-01-02-021 — Phone OTP resend cooldown and maximum
**Type:** Positive
**Covers:** 2.2 → Resend with cooldown and maximum resend count
**Preconditions:** A phone verification in progress; cooldown (30–60s) and maximum known.
**Steps:**
1. Observe the resend control state immediately after issuance.
2. Resend after each cooldown until the maximum.
3. Attempt a resend beyond the maximum.
**Expected Result:** The resend control is disabled with a countdown during the cooldown; resends succeed after it; the maximum caps total resends; beyond it the support-assisted path is offered; all resends are logged.
**Priority:** High

### TC-SA-01-02-022 — Country-code-aware number entry with format validation
**Type:** Edge
**Covers:** 2.2 → Country-code-aware number entry with format validation per region
**Preconditions:** The phone entry screen; numbers from multiple regions available.
**Steps:**
1. Enter a valid number for region A with the correct country code.
2. Enter an invalid format for region A (too short, letters, wrong code).
3. Enter a valid number for region B with its country code.
**Expected Result:** Valid regional formats are accepted with the correct country-code handling; invalid formats produce clear inline validation errors specific to the region's format; no invalid number reaches the OTP delivery stage.
**Priority:** High

### TC-SA-01-02-023 — Voice-call OTP fallback on SMS failure
**Type:** Edge
**Covers:** 2.2 → Voice-call OTP fallback where SMS delivery fails or is unavailable
**Preconditions:** A phone verification where SMS delivery fails; voice-call fallback enabled.
**Steps:**
1. Trigger the OTP with SMS failing.
2. Observe the fallback offer.
3. Select the voice-call channel and complete verification with the spoken code.
**Expected Result:** On SMS failure the voice-call fallback is offered; the voice call delivers the 6-digit code; verification completes with the spoken code; the channel switch and both delivery attempts are logged.
**Priority:** High

### TC-SA-01-02-024 — Verification completion enables SMS-dependent features
**Type:** Positive
**Covers:** 2.2 → Verification completion: number marked verified, enabling SMS-dependent features
**Preconditions:** An account with an unverified phone; SMS login and SMS 2FA available as options.
**Steps:**
1. Complete phone verification with a valid OTP.
2. Check the phone status on the account.
3. Attempt to use SMS-based OTP login and SMS-based 2FA.
**Expected Result:** The number is marked verified; SMS-based login and SMS-based 2FA become available and functional for the user; the completion event is logged.
**Priority:** Critical

### TC-SA-01-02-025 — Number change requires new-number verification and identity check
**Type:** Edge
**Covers:** 2.2 → Number change flow with identity check
**Preconditions:** A verified account with an existing trusted channel (password or verified phone).
**Steps:**
1. Initiate a phone number change to a new (monitored) number.
2. Complete the identity check (current password or existing verified channel).
3. Verify the new number with its OTP.
4. Inspect the account's phone and the audit entries.
**Expected Result:** The number is swapped only after BOTH the identity check and the new-number OTP verification; the audit entries show both verifications recorded for the change; the old number is no longer the account's verified phone; the change is audit-logged.
**Priority:** Critical

### TC-SA-01-02-026 — Admin view of unverified/failed phone accounts
**Type:** Positive
**Covers:** 2.2 → Admin view: list of accounts with unverified or failed phone verification
**Preconditions:** Accounts with unverified phones and accounts with failed OTP outcomes; Super Admin directory access.
**Steps:**
1. Open the user directory and filter by "Phone unverified".
2. Inspect the list fields (registration date, last OTP attempt outcome).
3. Open the delivery-failure report and inspect a failure cluster.
**Expected Result:** The filtered list shows exactly the unverified/failed accounts with registration dates and last OTP attempt outcomes; the delivery-failure report surfaces carrier/region patterns; the data matches the actual OTP events.
**Priority:** Medium

### TC-SA-01-02-027 — Delivery failures produce distinct outcomes
**Type:** Negative
**Covers:** 2.2 → Delivery-failure handling: carrier failures, invalid numbers, throttling
**Preconditions:** Scenarios for carrier failure, invalid number, and carrier throttling.
**Steps:**
1. Trigger an OTP to a number experiencing carrier failure; observe the outcome.
2. Trigger an OTP to an invalid number; observe the outcome.
3. Trigger an OTP under carrier throttling; observe the outcome.
**Expected Result:** Each failure type produces its distinct documented outcome (retry path, invalid-number error, throttling notice with retry); none is a silent failure; each is logged with the failure type and is separately reportable.
**Priority:** High

### TC-SA-01-02-028 — All phone OTP and delivery events logged
**Type:** Positive
**Covers:** 2.2 → Logging of all OTP issuances, verifications, failures, and delivery outcomes
**Preconditions:** Scenarios producing issuance, verification, failure, and delivery outcomes; log access.
**Steps:**
1. Produce each event type (issuance, successful verification, wrong-entry failure, delivery failure).
2. Locate all events in the log.
3. Inspect channel, outcome, and timestamp fields.
**Expected Result:** All event types are present with channel (SMS/voice), outcome, and timestamp; delivery failures are separately reportable; the sequence matches the actual operations.
**Priority:** High

### TC-SA-01-02-029 — Phone OTP single-use and expiring
**Type:** Negative
**Covers:** 2.2 → Rule: OTP single-use and expires; wrong attempts beyond limit require fresh issuance
**Preconditions:** A phone OTP that has been verified once (then the user re-initiates verification on a test account).
**Steps:**
1. Attempt to reuse the previously verified code in a new verification.
2. Attempt to use an expired code.
**Expected Result:** The reused code is rejected (single-use); the expired code is rejected with the expired message; both require a fresh issuance; both rejections are logged.
**Priority:** Critical

### TC-SA-01-02-030 — One phone number bound to one active account
**Type:** Negative
**Covers:** 2.2 → Rule: a verified number cannot be bound to a second active account
**Preconditions:** A number already verified on an active account; a new registration available.
**Steps:**
1. Register a second account using the already-verified number.
2. Observe the system's response.
**Expected Result:** The second account's verification with that number is blocked with a clear message (the number is already bound to an active account); no duplicate binding is created; the block is logged; the original account's binding is unaffected.
**Priority:** Critical

### TC-SA-01-02-031 — Number change without identity check is blocked
**Type:** Negative
**Covers:** 2.2 → Rule: number changes always require new-number verification AND identity confirmation
**Preconditions:** A verified account; a number change initiated.
**Steps:**
1. Initiate a number change and skip/fail the identity check step.
2. Observe whether the new-number OTP stage is reachable.
3. For a user with no other verified channel, observe the offered path.
**Expected Result:** The change cannot proceed without the identity check (the new-number stage is not reached); for a user with no other verified channel, the support-assisted path is offered instead; all blocked attempts are logged.
**Priority:** Critical

### TC-SA-01-02-032 — SMS failure retry path with voice fallback
**Type:** Edge
**Covers:** 2.2 → Rule: delivery failures produce a retry path with voice-call fallback where enabled
**Preconditions:** SMS delivery failing (carrier throttling); voice-call fallback enabled.
**Steps:**
1. Trigger an OTP with SMS failing.
2. Use the retry path.
3. Switch to the voice-call fallback and complete verification.
**Expected Result:** The retry path is offered on failure; the voice-call fallback is available where enabled and completes verification; the full sequence (failure, retry, fallback, success) is logged with channels.
**Priority:** High

### TC-SA-01-02-033 — Resend rate limiting per number and per account
**Type:** Negative
**Covers:** 2.2 → Rule: resends rate-limited per number and per account to prevent SMS pumping
**Preconditions:** Multiple accounts; the per-number and per-account resend limits known.
**Steps:**
1. From one account, trigger resends to the same number beyond the per-number limit.
2. From multiple accounts, trigger resends beyond the per-account aggregate limit.
3. Observe enforcement and logging.
**Expected Result:** The per-number limit caps resends to a single number; the per-account limit caps aggregate resends; SMS pumping (mass delivery) is not possible; all limit events are logged.
**Priority:** High

### TC-SA-01-02-034 — Phone verification events logged with channel, outcome, timestamp
**Type:** Positive
**Covers:** 2.2 → Rule: events logged with channel, outcome, timestamp; delivery failures separately reportable
**Preconditions:** Multiple phone verification events including delivery failures; log access.
**Steps:**
1. Produce verification events across SMS and voice channels, including a delivery failure.
2. Inspect each event's channel, outcome, and timestamp.
3. Run the delivery-failure report.
**Expected Result:** Every event carries channel, outcome, and timestamp; delivery failures are separately reportable in the report view; no event lacks any of the three fields.
**Priority:** Medium

### TC-SA-01-02-035 — SMS login and SMS 2FA unavailable until phone verified
**Type:** Negative
**Covers:** 2.2 → Rule: verification is a prerequisite for SMS-based login and SMS-based 2FA
**Preconditions:** An account with an unverified phone; SMS login and SMS 2FA as configured options.
**Steps:**
1. Attempt to select SMS-based OTP login while the phone is unverified.
2. Attempt to enroll in SMS-based 2FA while the phone is unverified.
3. Verify the phone and repeat both.
**Expected Result:** Both options are unavailable while the phone is unverified (hidden or blocked with a verification-required message); after verification both become available and functional; the state change is logged.
**Priority:** High

## 2.3 Age Verification

### TC-SA-01-02-036 — DOB capture with format validation and plausibility checks
**Type:** Edge
**Covers:** 2.3 → Date-of-birth capture with format validation and plausibility checks
**Preconditions:** The registration screen with the DOB field.
**Steps:**
1. Enter a valid DOB; observe acceptance.
2. Enter a future date; observe the validation.
3. Enter an implausible date (e.g., year 1800); observe the validation.
4. Enter a malformed format; observe the validation.
**Expected Result:** Valid DOBs are accepted; future dates are rejected with a clear error; implausible dates are rejected with a clear error; malformed formats are rejected with a format error; no implausible DOB is stored.
**Priority:** High

### TC-SA-01-02-037 — Minimum-age policy configuration
**Type:** Positive
**Covers:** 2.3 → Minimum-age policy configuration
**Preconditions:** Super Admin access to System Settings → Account Policy → Age Policy.
**Steps:**
1. Open the Age Policy screen.
2. Verify the configured thresholds (e.g., 13+ self-registration; 18+ features).
3. Change a threshold and save; verify the change takes effect.
**Expected Result:** The thresholds are visible and editable; the change applies to registration gating and feature gating immediately after save; the policy change is audit-logged.
**Priority:** High

### TC-SA-01-02-038 — Age-band classification (minor vs adult)
**Type:** Positive
**Covers:** 2.3 → Age-band classification
**Preconditions:** Accounts with DOBs on both sides of the thresholds (e.g., 12, 15, 17, 20).
**Steps:**
1. Register/inspect accounts with each DOB.
2. Check each account's assigned age band.
3. Verify which consent and feature-gating rules apply to each band.
**Expected Result:** Each account is classified into the correct band (minor/adult per the thresholds); the band drives the applicable consent flow (parental for minors) and feature gating (18+ features locked for minors); the classification is consistent with the DOB on record.
**Priority:** Critical

### TC-SA-01-02-039 — Age-restricted features gated for minors
**Type:** Negative
**Covers:** 2.3 → Feature gating: age-restricted features hidden or locked with a clear message
**Preconditions:** A minor account; an 18+ feature (e.g., payment methods management).
**Steps:**
1. Log in as the minor and navigate to the area containing the 18+ feature.
2. Observe the feature's presentation.
3. Attempt to reach the feature directly (deep link / direct request).
**Expected Result:** The feature is hidden or locked for the minor with a clear age-restriction message; direct access attempts are denied (server-side enforcement); the denial is logged; an adult account sees the feature available.
**Priority:** Critical

### TC-SA-01-02-040 — Age re-verification with admin-assisted evidence
**Type:** Edge
**Covers:** 2.3 → Age re-verification: admin-assisted process with evidence
**Preconditions:** A user disputing their recorded DOB; a support request channel; evidence available (e.g., government ID per the verification standard).
**Steps:**
1. Have the user raise a support request with evidence.
2. As Super Admin/support admin, open the request and review the evidence.
3. Update the DOB record through the correction flow.
4. Inspect the audit log entry.
**Expected Result:** The correction is made only through the admin-assisted flow with evidence review; the audit entry records the before/after values, the evidence reference, and the acting admin; the user cannot self-edit the DOB outside this flow.
**Priority:** High

### TC-SA-01-02-041 — Below-threshold users routed to parental consent
**Type:** Edge
**Covers:** 2.3 → Parental routing below the self-registration threshold
**Preconditions:** A registration with a DOB below the self-registration minimum (e.g., under 13).
**Steps:**
1. Attempt registration with the below-threshold DOB.
2. Observe the flow routing.
**Expected Result:** The user cannot complete registration independently; the flow routes to the parental consent flow (feature 2.4) with the guardian steps; no self-registered account is created for the below-threshold user; the routing is logged.
**Priority:** Critical

### TC-SA-01-02-042 — Admin view: age-band distribution and unconfirmed age list
**Type:** Positive
**Covers:** 2.3 → Admin view: age-band distribution and list of accounts with unconfirmed age
**Preconditions:** A user base spanning age bands; accounts with unconfirmed age (e.g., social login without DOB); directory access.
**Steps:**
1. Open the age-band distribution view in the user directory.
2. Apply the "Age unconfirmed" filter.
3. Verify both views against known data.
**Expected Result:** The distribution view shows correct counts per age band; the unconfirmed filter lists exactly the accounts lacking a complete DOB; both views match the actual account data.
**Priority:** Medium

### TC-SA-01-02-043 — Age events logged (capture, corrections, verification)
**Type:** Positive
**Covers:** 2.3 → Logging of age capture, corrections, and verification events
**Preconditions:** Age events produced (a capture at registration, a correction, a verification); log access.
**Steps:**
1. Produce each event type.
2. Locate all events in the log.
3. Inspect their fields.
**Expected Result:** All event types are present with timestamps, account context, and (for corrections) before/after values; the events are audit-grade (actor recorded for admin actions).
**Priority:** High

### TC-SA-01-02-044 — Age determined only from DOB on record
**Type:** Edge
**Covers:** 2.3 → Rule: age from the date of birth on record; not re-derived from other signals
**Preconditions:** An account with a DOB on record; other profile signals that could suggest a different age.
**Steps:**
1. Inspect the account's age determination.
2. Introduce a conflicting signal (e.g., a profile field suggesting a different age).
3. Re-check the age determination and gating.
**Expected Result:** The age (and all gating/consent decisions) is derived solely from the DOB on record; conflicting signals do not alter the determination; only a formal correction changes the DOB.
**Priority:** Medium

### TC-SA-01-02-045 — Below-minimum user cannot complete registration independently
**Type:** Negative
**Covers:** 2.3 → Rule: below the self-registration minimum cannot complete registration independently
**Preconditions:** A registration attempt with a below-minimum DOB.
**Steps:**
1. Attempt to complete the full registration flow as the below-minimum user.
2. Observe where the flow stops or routes.
**Expected Result:** The flow does not allow independent completion; it routes to the parent/guardian step (2.4); no active account exists for the minor until the guardian flow completes; the block/routing is logged.
**Priority:** Critical

### TC-SA-01-02-046 — Age gating enforced server-side, not just UI
**Type:** Negative
**Covers:** 2.3 → Rule: age-restricted features enforced server-side
**Preconditions:** A minor account; an 18+ feature; the ability to issue direct requests bypassing the UI.
**Steps:**
1. As the minor, issue a direct request to the 18+ feature's endpoint/resource (bypassing the hidden UI).
2. Observe the server response.
**Expected Result:** The server denies the request regardless of UI visibility (the hiding is convenience only); the denial is logged; the feature's data/actions are never exposed to the minor account.
**Priority:** Critical

### TC-SA-01-02-047 — DOB cannot be self-edited outside the correction flow
**Type:** Negative
**Covers:** 2.3 → Rule: age corrections require admin-assisted verification with evidence
**Preconditions:** An existing account with a DOB; profile settings access.
**Steps:**
1. Attempt to edit the DOB directly in profile settings.
2. Observe the available controls.
**Expected Result:** The DOB is not self-editable after registration (the field is read-only or the edit is blocked); the only path to change it is the admin-assisted correction flow with evidence; any attempted self-edit is rejected and logged.
**Priority:** High

### TC-SA-01-02-048 — Age band drives consent requirements
**Type:** Positive
**Covers:** 2.3 → Rule: the age band drives consent requirements
**Preconditions:** A minor account and an adult account.
**Steps:**
1. Check the consent requirements applied to the minor account.
2. Check the consent requirements applied to the adult account.
3. Compare with the documented rules.
**Expected Result:** The minor account requires parental consent (2.4); the adult account consents for itself; the requirements match the age bands exactly; no minor account is active without the guardian consent.
**Priority:** Critical

### TC-SA-01-02-049 — All age-related events audit-logged
**Type:** Positive
**Covers:** 2.3 → Rule: all age-related events audit-logged
**Preconditions:** Age events produced (capture, correction, verification); audit log access.
**Steps:**
1. Produce each event type.
2. Locate all events in the audit log.
3. Verify actor and timestamp on each.
**Expected Result:** Every age-related event is audit-logged with actor (user or admin) and timestamp; corrections carry before/after and evidence reference; no event is missing from the audit trail.
**Priority:** High

### TC-SA-01-02-050 — Stricter local-law threshold applies
**Type:** Edge
**Covers:** 2.3 → Rule: where local law sets a higher minimum, the stricter threshold applies
**Preconditions:** A compliance configuration with a region whose local law sets a higher minimum age than the platform default.
**Steps:**
1. Configure the compliance setting for the region with the stricter threshold.
2. Attempt registration from that region with an age between the platform default and the local-law minimum.
3. Observe the gating.
**Expected Result:** The stricter (local-law) threshold is applied for that region; the between-threshold age is treated as below-minimum (routed to guardian flow); the platform default applies elsewhere; the compliance configuration is audit-logged.
**Priority:** High

## 2.4 Parental Consent Verification for Minors

### TC-SA-01-02-051 — Guardian identification captured at minor's registration
**Type:** Positive
**Covers:** 2.4 → Guardian identification: relationship captured at registration
**Preconditions:** A minor's registration reaching the parental consent step.
**Steps:**
1. Proceed through the minor's registration to the consent step.
2. Enter the guardian's name, relationship, and email/phone.
3. Observe the captured data and the next step.
**Expected Result:** The guardian's name, relationship, and contact channel are captured and stored with the minor's registration; the consent request is sent to the guardian's channel; the captured data is visible in the account's consent record.
**Priority:** High

### TC-SA-01-02-052 — Guardian identity verification
**Type:** Positive
**Covers:** 2.4 → Guardian identity verification (email/phone OTP, document where required)
**Preconditions:** A consent request delivered to the guardian's channel.
**Steps:**
1. Have the guardian follow the consent link.
2. Complete the guardian's identity verification (OTP to their phone/email).
3. Where policy requires document verification, complete it.
**Expected Result:** The guardian's identity is verified via OTP (and document where policy requires); only after verification can the guardian proceed to the consent document; the verification method is recorded in the consent record.
**Priority:** Critical

### TC-SA-01-02-053 — Guardian authority confirmation
**Type:** Positive
**Covers:** 2.4 → Guardian authority confirmation: attestation with document evidence where required
**Preconditions:** A guardian who has passed identity verification.
**Steps:**
1. Have the guardian complete the legal-guardianship attestation.
2. Where policy requires, submit the document evidence.
3. Observe the recorded authority confirmation.
**Expected Result:** The attestation is captured; document evidence is collected where policy requires; the authority confirmation is stored with the consent record; the guardian can proceed to the consent document only after this step.
**Priority:** High

### TC-SA-01-02-054 — Informed consent capture with minor-specific document
**Type:** Positive
**Covers:** 2.4 → Informed consent capture: minor-specific consent document
**Preconditions:** A guardian who has completed identity and authority steps.
**Steps:**
1. Have the guardian review the minor-specific consent document (data processing, communications, payments, safeguarding).
2. Have the guardian accept it.
3. Inspect the consent record.
**Expected Result:** The minor-specific document (covering data processing, communications, payments, safeguarding policies) is presented; the guardian's acceptance is captured; the consent record is created with the document version, timestamp, and guardian identity; the minor's account moves from pending to active.
**Priority:** Critical

### TC-SA-01-02-055 — Consent record linked to the minor's account
**Type:** Positive
**Covers:** 2.4 → Consent record linked to the minor's account with version, timestamp, guardian identity
**Preconditions:** A completed consent; Super Admin access to the minor's account.
**Steps:**
1. Open the minor's account record.
2. Locate the linked consent record.
3. Verify its fields (version, timestamp, guardian identity).
**Expected Result:** The consent record is linked to the minor's account; it shows the document version, the acceptance timestamp, and the guardian identity (as recorded); the link is visible in the admin view and the audit trail.
**Priority:** High

### TC-SA-01-02-056 — Guardian can review and withdraw consent
**Type:** Edge
**Covers:** 2.4 → Ongoing consent: review and withdrawal with account handling policy
**Preconditions:** An active minor account with guardian consent on record.
**Steps:**
1. Have the guardian review the existing consent.
2. Have the guardian withdraw the consent.
3. Observe the account handling (pause/close per policy), the minor's notification, session termination, and subscription handling.
**Expected Result:** The guardian can review the consent at any time; withdrawal is recorded and honored per the handling policy (the minor's account is paused or closed); the minor is notified; active sessions end; any subscription is cancelled with refund handling per policy; the withdrawal is audit-logged.
**Priority:** Critical

### TC-SA-01-02-057 — Payment authorization covered by guardian consent
**Type:** Positive
**Covers:** 2.4 → Payment authorization: guardian consent covers billing; guardian manages payment methods
**Preconditions:** An active minor account with guardian consent; a paid membership available.
**Steps:**
1. Initiate a paid membership for the minor's account.
2. Verify the billing consent is covered by the guardian's consent.
3. Verify payment methods are managed by the guardian (not the minor).
**Expected Result:** The billing for the minor's membership is covered by the guardian's consent; payment methods are added/managed by the guardian; the minor cannot independently add a payment method; the authorization chain is recorded.
**Priority:** High

### TC-SA-01-02-058 — Admin view of minor consent status
**Type:** Positive
**Covers:** 2.4 → Admin view: list of minor accounts with consent status
**Preconditions:** Minor accounts in each consent state (pending, active, withdrawn, expiring); directory access.
**Steps:**
1. Open the user directory and filter to minor accounts.
2. Verify the consent status column for each state.
3. Inspect the pending queue with days-pending.
**Expected Result:** The view lists minor accounts with their consent status (pending, active, withdrawn, expiring); the pending queue shows days-pending; the statuses match the actual consent records.
**Priority:** Medium

### TC-SA-01-02-059 — Re-consent on material policy changes
**Type:** Edge
**Covers:** 2.4 → Re-consent on material policy changes, mirroring the adult flow
**Preconditions:** Active guardian consents on a document version; a material change to the consent document.
**Steps:**
1. Publish a material change to the minor consent document (new version).
2. Observe the re-consent trigger for affected guardians.
3. Have a guardian complete re-consent.
4. Inspect the consent records before and after.
**Expected Result:** The material change triggers re-consent requests to affected guardians (mirroring the adult re-consent flow); until re-consent, the prior consent state is handled per policy; after re-consent the record shows the new version and timestamp; the re-consent events are audit-logged.
**Priority:** High

### TC-SA-01-02-060 — Full consent lifecycle audit logging
**Type:** Positive
**Covers:** 2.4 → Full audit logging of the consent lifecycle
**Preconditions:** A complete consent lifecycle produced (request, verification, acceptance, withdrawal, re-consent); audit log access.
**Steps:**
1. Produce each lifecycle event.
2. Locate all events in the audit trail for the minor account.
3. Verify guardian identity and timestamps on each.
**Expected Result:** Every lifecycle event (request, verification, acceptance, withdrawal, re-consent) is audit-logged with the guardian identity (as recorded) and timestamps; the trail is complete and in order; it supports the safeguarding review.
**Priority:** High

### TC-SA-01-02-061 — Minor account not fully active without verified consent
**Type:** Negative
**Covers:** 2.4 → Rule: no full activity without a verified guardian consent on record
**Preconditions:** A minor account in the pending-consent state.
**Steps:**
1. Log in as the minor (pending consent).
2. Observe the account state and available functionality.
3. Attempt a full-functionality action.
**Expected Result:** The account remains in the limited/pending state; full functionality is not available; the pending state is visible (banner/status) until a verified guardian consent is on record; the restriction is enforced consistently.
**Priority:** Critical

### TC-SA-01-02-062 — Consent from an unverified guardian channel is rejected
**Type:** Negative
**Covers:** 2.4 → Rule: guardian identity verification is mandatory
**Preconditions:** A consent request; a guardian who does not complete identity verification.
**Steps:**
1. Have the guardian follow the consent link but skip/fail the identity verification.
2. Attempt to reach the consent document and accept.
**Expected Result:** The consent cannot be accepted without the guardian's identity verification; the flow blocks at the verification step; no consent record is created; the blocked attempt is logged.
**Priority:** Critical

### TC-SA-01-02-063 — One guardian linked to multiple minor accounts
**Type:** Positive
**Covers:** 2.4 → Rule: one guardian can be linked to multiple minor accounts, each with its own consent record
**Preconditions:** A guardian with two minor children (siblings) to register.
**Steps:**
1. Complete the consent flow for minor A with the guardian.
2. Complete the consent flow for minor B with the same guardian.
3. Inspect both consent records and the guardian's links.
**Expected Result:** The same guardian is linked to both minor accounts; each minor has its own separate consent record (version, timestamp, guardian identity); withdrawing consent for one minor does not affect the other; both records are audit-logged.
**Priority:** High

### TC-SA-01-02-064 — Consent withdrawal honored without delay; minor notified
**Type:** Edge
**Covers:** 2.4 → Rule: withdrawal honored per policy, not ignored or delayed; minor notified
**Preconditions:** An active minor account with guardian consent.
**Steps:**
1. Have the guardian withdraw consent.
2. Observe the timing of the account handling (immediate per policy).
3. Verify the minor's notification.
**Expected Result:** The withdrawal takes effect per the handling policy without being ignored or delayed; the minor is notified of the change; the account state changes accordingly (pause/close); the withdrawal and notification are audit-logged.
**Priority:** Critical

### TC-SA-01-02-065 — Minor cannot independently add a payment method
**Type:** Negative
**Covers:** 2.4 → Rule: payments for a minor require guardian consent; minor cannot add a payment method
**Preconditions:** An active minor account with guardian consent covering billing.
**Steps:**
1. Log in as the minor and attempt to add a payment method.
2. Observe the available controls.
**Expected Result:** The minor cannot independently add a payment method (the control is unavailable or blocked with a message that the guardian manages payments); only the guardian can manage payment methods; the block is logged.
**Priority:** High

### TC-SA-01-02-066 — Consent documents versioned; material change triggers re-consent
**Type:** Edge
**Covers:** 2.4 → Rule: consent documents versioned; material change triggers re-consent
**Preconditions:** Consent records on document version 1; a material change prepared.
**Steps:**
1. Verify existing records show version 1.
2. Publish version 2 as a material change.
3. Verify the re-consent trigger and the version update after acceptance.
**Expected Result:** Documents are versioned (each record carries its version); the material change triggers re-consent from guardians; after acceptance the record reflects version 2 with a new timestamp; non-material changes do not trigger re-consent; all version events are audit-logged.
**Priority:** High

### TC-SA-01-02-067 — Consent lifecycle events carry guardian identity and timestamps
**Type:** Positive
**Covers:** 2.4 → Rule: lifecycle events audit-logged with guardian identity and timestamps
**Preconditions:** Multiple consent lifecycle events produced; audit log access.
**Steps:**
1. Produce request, verification, acceptance, and withdrawal events.
2. Inspect each audit entry's guardian identity and timestamp fields.
**Expected Result:** Every entry records the guardian identity (as recorded) and an accurate timestamp; no entry lacks either field; the entries support the safeguarding review.
**Priority:** High

### TC-SA-01-02-068 — Stricter local child-protection law applies
**Type:** Edge
**Covers:** 2.4 → Rule: stricter local child-protection requirements apply per compliance configuration
**Preconditions:** A compliance configuration with a region whose child-protection law is stricter than the platform default.
**Steps:**
1. Configure the compliance setting for the region.
2. Run the consent flow for a minor in that region.
3. Compare the applied requirements with the platform default.
**Expected Result:** The stricter local standard is applied for that region (e.g., additional verification or document requirements); the platform default applies elsewhere; the compliance configuration and its effect are audit-logged.
**Priority:** High