# 2. Account Creation & Editing — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: account_creation_editing.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 Create User Accounts Manually | Creation form per account type (Sub Admin, Student, Parent, Affiliate, Institute) with type-specific required fields | TC-SA-03-02-001 |
| 2.1 Create User Accounts Manually | Provisional credentials: system-generated temporary password (or invite link) delivered to the user's email/phone | TC-SA-03-02-002 |
| 2.1 Create User Accounts Manually | Forced first-login password change for provisionally-credentialed accounts | TC-SA-03-02-003 |
| 2.1 Create User Accounts Manually | Role assignment at creation (for staff) or at first login (guided) | TC-SA-03-02-004 |
| 2.1 Create User Accounts Manually | Institute/staff creation: create the institute account and its staff accounts together | TC-SA-03-02-005 |
| 2.1 Create User Accounts Manually | Verification state set appropriately (admin-created email marked pending user confirmation where policy requires) | TC-SA-03-02-006 |
| 2.1 Create User Accounts Manually | Audit logging of admin-created accounts with the creating admin | TC-SA-03-02-007 |
| 2.1 Create User Accounts Manually | Rule: admin-created accounts marked with provenance; distinguishable from self-registrations | TC-SA-03-02-008 |
| 2.1 Create User Accounts Manually | Rule: provisional credentials force a password change; the temporary password is never shown again | TC-SA-03-02-003 |
| 2.1 Create User Accounts Manually | Rule: email uniqueness enforced; the existing account is surfaced | TC-SA-03-02-009 |
| 2.1 Create User Accounts Manually | Rule: role assignment at creation applies immediately; access correct from first login | TC-SA-03-02-010 |
| 2.1 Create User Accounts Manually | Rule: admin creation does not bypass verification policy | TC-SA-03-02-006 |
| 2.1 Create User Accounts Manually | Rule: every admin-created account audit-logged with the creating admin and initial configuration | TC-SA-03-02-007 |
| 2.2 Edit User Profile Information | Editable fields per account type (name, email, phone, address, institute link, DOB via correction flow) | TC-SA-03-02-011 |
| 2.2 Edit User Profile Information | Validation on save (format, uniqueness for email/phone) | TC-SA-03-02-012 |
| 2.2 Edit User Profile Information | Change history: before/after values per field, with the acting admin and timestamp | TC-SA-03-02-013 |
| 2.2 Edit User Profile Information | User notification on admin-initiated profile changes (per policy) | TC-SA-03-02-014 |
| 2.2 Edit User Profile Information | Sensitive-field edits (email, phone, DOB) require confirmation and route through the relevant verification/correction flow | TC-SA-03-02-015 |
| 2.2 Edit User Profile Information | Audit logging of every admin edit | TC-SA-03-02-016 |
| 2.2 Edit User Profile Information | Rule: email/phone changes uniqueness-checked; a value bound to another active account is rejected | TC-SA-03-02-017 |
| 2.2 Edit User Profile Information | Rule: changing the login email or phone triggers re-verification before use for authentication | TC-SA-03-02-018 |
| 2.2 Edit User Profile Information | Rule: DOB changes route through the age-correction flow with evidence | TC-SA-03-02-019 |
| 2.2 Edit User Profile Information | Rule: admin edits attributed to the acting admin; distinct from self-service edits | TC-SA-03-02-020 |
| 2.2 Edit User Profile Information | Rule: the user is notified of admin-initiated changes per policy | TC-SA-03-02-014 |
| 2.2 Edit User Profile Information | Rule: every edit audit-logged with before/after state | TC-SA-03-02-016 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | CSV template download with required and optional columns | TC-SA-03-02-021 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Upload with row-level validation (format, required fields, duplicates within the file and against existing accounts) | TC-SA-03-02-022 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Pre-commit preview: valid rows, error rows with specific error messages, and duplicate rows | TC-SA-03-02-023 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Commit: create the valid accounts linked to the institute, with provisional credentials or invite links | TC-SA-03-02-024 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Error report download: the failed rows with reasons, for correction and re-upload | TC-SA-03-02-025 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Progress and completion summary (created, failed, duplicates skipped) | TC-SA-03-02-026 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Audit logging of the bulk operation (file, row counts, acting admin) | TC-SA-03-02-027 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Rule: validation is row-level and specific; each error names the row and the problem | TC-SA-03-02-022 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Rule: duplicates are not silently created; reported and mapped to the existing account | TC-SA-03-02-028 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Rule: the commit is a deliberate step after preview; nothing is created until confirmed | TC-SA-03-02-029 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Rule: created accounts follow the same policy as individually created ones | TC-SA-03-02-030 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Rule: the error report preserves the original rows for correction and re-upload | TC-SA-03-02-025 |
| 2.3 Bulk Student Registration (CSV Upload) for Institutes | Rule: the bulk operation is audit-logged as a single event with the full row-count breakdown | TC-SA-03-02-027 |
| 2.4 Account Type-Specific Fields and Requirements | Type-specific required fields (institute: license seat count, contact; staff: role; student: guardian, DOB; affiliate: commission profile) | TC-SA-03-02-031 |
| 2.4 Account Type-Specific Fields and Requirements | Type-specific verification requirements (minors: parental consent; affiliates: identity verification) | TC-SA-03-02-032 |
| 2.4 Account Type-Specific Fields and Requirements | Type-specific downstream setup (institute: license provisioning; staff: role and permissions; student: seat allocation) | TC-SA-03-02-033 |
| 2.4 Account Type-Specific Fields and Requirements | Completeness indicator per account (which required items are pending) | TC-SA-03-02-034 |
| 2.4 Account Type-Specific Fields and Requirements | Guidance prompts for missing required items | TC-SA-03-02-035 |
| 2.4 Account Type-Specific Fields and Requirements | Consistency between the type's fields and its available actions | TC-SA-03-02-036 |
| 2.4 Account Type-Specific Fields and Requirements | Rule: required fields block save until complete; the form shows exactly what is missing | TC-SA-03-02-037 |
| 2.4 Account Type-Specific Fields and Requirements | Rule: type-specific verification requirements are enforced, not optional | TC-SA-03-02-038 |
| 2.4 Account Type-Specific Fields and Requirements | Rule: downstream setup happens as part of creation; the account is usable immediately after | TC-SA-03-02-039 |
| 2.4 Account Type-Specific Fields and Requirements | Rule: the completeness indicator surfaces pending items without blocking the account's existence | TC-SA-03-02-034 |
| 2.4 Account Type-Specific Fields and Requirements | Rule: fields are type-appropriate; the form never shows fields that do not apply | TC-SA-03-02-040 |
| 2.4 Account Type-Specific Fields and Requirements | Rule: all type-specific creation and editing is audit-logged like any other account change | TC-SA-03-02-041 |

## 2.1 Create User Accounts Manually

### TC-SA-03-02-001 — Creation form adapts per account type with type-specific required fields
**Type:** Positive
**Covers:** 2.1 → Creation form per account type (Sub Admin, Student, Parent, Affiliate, Institute) with type-specific required fields
**Preconditions:** Super Admin logged in.
**Steps:**
1. Open Create Account and select each type in turn: Sub Admin, Student, Parent, Affiliate, Institute.
2. For each type, verify the form shows the type-specific required fields (e.g., Institute: license seat count, contact; Student: guardian, DOB).
**Expected Result:** The form adapts to the selected type — each type shows exactly its required fields, no more, no less.
**Priority:** Critical

### TC-SA-03-02-002 — Provisional credentials are generated and delivered to the user's email/phone
**Type:** Positive
**Covers:** 2.1 → Provisional credentials: system-generated temporary password (or invite link) delivered to the user's email/phone
**Preconditions:** A new staff account is being created with a valid email.
**Steps:**
1. Create the account with provisional credentials.
2. Check the user's email for the invite with the temporary credential.
3. Verify the credential works for first login.
**Expected Result:** A system-generated temporary password (or invite link) is delivered to the user's email/phone and works for first login.
**Priority:** Critical

### TC-SA-03-02-003 — First login forces a password change; the temporary password is never shown again
**Type:** Positive
**Covers:** 2.1 → Forced first-login password change; Rule: the temporary password is never shown again after issuance
**Preconditions:** A provisionally-credentialed account has received its invite.
**Steps:**
1. Log in with the temporary password.
2. Observe the forced password-change step.
3. Attempt to view the temporary password again (in the account record, the invite, or any admin surface).
**Expected Result:** First login forces a password change before any other access; the temporary password is never shown again after issuance.
**Priority:** Critical

### TC-SA-03-02-004 — Role assignment at creation (staff) or guided at first login
**Type:** Positive
**Covers:** 2.1 → Role assignment at creation (for staff) or at first login (guided)
**Preconditions:** A staff account is being created.
**Steps:**
1. Create the staff account and assign the role "Teacher/Content Creator" at creation.
2. For a second staff account, leave the role unassigned and complete first login.
**Expected Result:** The first account has the role from creation; the second account is guided through role assignment at first login.
**Priority:** High

### TC-SA-03-02-005 — Institute and its staff accounts can be created together
**Type:** Positive
**Covers:** 2.1 → Institute/staff creation: create the institute account and its staff accounts together
**Preconditions:** A new institute contract is ready.
**Steps:**
1. Create the institute account (name, contact, email, phone, address, license seat count).
2. In the same flow, create the institute's staff accounts (Sub Admin type) with their roles.
3. Verify all accounts are linked to the institute.
**Expected Result:** The institute and its staff accounts are created together, each with its invite, and all are linked to the institute.
**Priority:** High

### TC-SA-03-02-006 — Verification state is set appropriately; admin creation does not bypass verification policy
**Type:** Positive
**Covers:** 2.1 → Verification state set appropriately (admin-created email marked pending user confirmation where policy requires); Rule: admin creation does not bypass verification policy
**Preconditions:** Policy requires user confirmation for phone verification.
**Steps:**
1. Create an account with a phone number.
2. Check the account's verification state.
3. Complete the user confirmation (OTP).
**Expected Result:** The account reflects the pending state until the user confirms — admin creation did not bypass the verification policy; after confirmation, the state updates.
**Priority:** High

### TC-SA-03-02-007 — Every admin-created account is audit-logged with the creating admin and initial configuration
**Type:** Positive
**Covers:** 2.1 → Audit logging of admin-created accounts with the creating admin; Rule: every admin-created account is audit-logged with the creating admin and the initial configuration
**Preconditions:** Super Admin creates three accounts of different types.
**Steps:**
1. Create the three accounts.
2. Open the audit trail and filter by "account created".
3. Verify each entry.
**Expected Result:** Each creation is audit-logged with the creating admin, the account, the initial configuration (type, role, fields), and the timestamp.
**Priority:** Critical

### TC-SA-03-02-008 — Admin-created accounts carry provenance and are distinguishable from self-registrations
**Type:** Positive
**Covers:** 2.1 → Rule: admin-created accounts are marked with provenance (created by which admin) and are distinguishable from self-registrations
**Preconditions:** One admin-created account and one self-registered account exist.
**Steps:**
1. Open the admin-created account's record and check its provenance.
2. Open the self-registered account's record and check its provenance.
**Expected Result:** The admin-created account shows "created by [admin]" provenance; the self-registered account shows self-registration — the two are clearly distinguishable.
**Priority:** High

### TC-SA-03-02-009 — Email uniqueness is enforced at creation; the existing account is surfaced
**Type:** Negative
**Covers:** 2.1 → Rule: email uniqueness is enforced; an account cannot be created with an email that already exists (the existing account is surfaced instead)
**Preconditions:** An account with email "existing@example.com" exists.
**Steps:**
1. Attempt to create a new account with email "existing@example.com".
**Expected Result:** Creation is blocked; the existing account is surfaced to the Super Admin instead of creating a duplicate.
**Priority:** Critical

### TC-SA-03-02-010 — Role assignment at creation applies immediately; access is correct from first login
**Type:** Positive
**Covers:** 2.1 → Rule: role assignment at creation applies immediately; the user's access is correct from first login
**Preconditions:** A staff account is created with the role "Billing Administrator".
**Steps:**
1. Complete the account's first login (set password).
2. Immediately attempt a Billing Administrator action (e.g., open the billing view).
3. Attempt an action outside the role.
**Expected Result:** The role is active from first login — the in-role action works and the out-of-role action is denied.
**Priority:** Critical

## 2.2 Edit User Profile Information

### TC-SA-03-02-011 — Editable fields per account type are available
**Type:** Positive
**Covers:** 2.2 → Editable fields per account type (name, email, phone, address, institute link, date of birth via correction flow)
**Preconditions:** A student account record is open.
**Steps:**
1. Edit the name, phone, address, and institute link fields.
2. Attempt to edit the date of birth.
**Expected Result:** Name, phone, address, and institute link are directly editable; the DOB is not a simple edit — it routes to the correction flow.
**Priority:** High

### TC-SA-03-02-012 — Validation on save: format and uniqueness for email/phone
**Type:** Negative
**Covers:** 2.2 → Validation on save (format, uniqueness for email/phone)
**Preconditions:** A student account record is open; another active account holds phone "9999999999".
**Steps:**
1. Enter an invalid phone format and save.
2. Enter the phone "9999999999" (bound to another active account) and save.
**Expected Result:** Both saves are rejected: the first for format, the second for uniqueness — with specific error messages.
**Priority:** Critical

### TC-SA-03-02-013 — Change history records before/after values, the acting admin, and timestamp
**Type:** Positive
**Covers:** 2.2 → Change history: before/after values per field, with the acting admin and timestamp
**Preconditions:** A student account's phone is edited from "1111111111" to "2222222222".
**Steps:**
1. Perform the edit.
2. Open the account's change history tab.
**Expected Result:** The history entry shows the field (phone), before ("1111111111"), after ("2222222222"), the acting admin, and the timestamp.
**Priority:** Critical

### TC-SA-03-02-014 — The user is notified of admin-initiated profile changes per policy
**Type:** Positive
**Covers:** 2.2 → User notification on admin-initiated profile changes (per policy); Rule: the user is notified of admin-initiated changes per policy
**Preconditions:** Policy requires notification for phone changes.
**Steps:**
1. Edit the student's phone number.
2. Check the student's notifications.
**Expected Result:** The student receives a notification: "Your phone number was updated by an administrator" — the change is not silent.
**Priority:** High

### TC-SA-03-02-015 — Sensitive-field edits require confirmation and route through the verification/correction flow
**Type:** Positive
**Covers:** 2.2 → Sensitive-field edits (email, phone, DOB) require confirmation and route through the relevant verification/correction flow
**Preconditions:** A student account's phone is to be changed.
**Steps:**
1. Edit the phone field and save.
2. Observe the routing to the verification flow.
3. Complete the OTP confirmation with the new number.
**Expected Result:** The edit requires confirmation; the new number enters the verification flow and is confirmed with an OTP before SMS-based features use it.
**Priority:** High

### TC-SA-03-02-016 — Every admin edit is audit-logged with before/after state
**Type:** Positive
**Covers:** 2.2 → Audit logging of every admin edit; Rule: every edit is audit-logged with before/after state
**Preconditions:** Two admin edits are performed on an account (name and address).
**Steps:**
1. Perform both edits.
2. Open the audit trail for the account.
**Expected Result:** Both edits are audit-logged with before/after state, the acting admin, and the timestamp.
**Priority:** Critical

### TC-SA-03-02-017 — Email/phone changes bound to another active account are rejected
**Type:** Negative
**Covers:** 2.2 → Rule: email and phone changes are uniqueness-checked; a value bound to another active account is rejected
**Preconditions:** An active account holds email "taken@example.com".
**Steps:**
1. Edit a different account's email to "taken@example.com" and save.
**Expected Result:** The change is rejected — the value is bound to another active account.
**Priority:** Critical

### TC-SA-03-02-018 — Changing the login email triggers re-verification before it is used for authentication
**Type:** Positive
**Covers:** 2.2 → Rule: changing the login email or phone triggers re-verification of the new value before it is used for authentication
**Preconditions:** A staff account's login email is to be changed.
**Steps:**
1. Edit the login email to the new address and save.
2. Attempt to log in with the new email before confirming.
3. Complete the confirmation (verification link sent to the new email).
4. Log in with the new email.
**Expected Result:** The new email cannot be used for authentication until confirmed; after confirmation, login with the new email succeeds.
**Priority:** Critical

### TC-SA-03-02-019 — DOB changes route through the age-correction flow with evidence
**Type:** Edge
**Covers:** 2.2 → Rule: date-of-birth changes do not go through a simple edit; they route through the age-correction flow with evidence
**Preconditions:** A student account's DOB needs correction.
**Steps:**
1. Attempt to edit the DOB directly.
2. Follow the routed age-correction flow and provide the required evidence.
**Expected Result:** The direct edit is unavailable; the DOB changes only through the age-correction flow with evidence.
**Priority:** High

### TC-SA-03-02-020 — Admin edits are attributed to the acting admin and distinct from self-service edits
**Type:** Positive
**Covers:** 2.2 → Rule: admin edits are always attributed to the acting admin and are distinct from self-service edits in the history
**Preconditions:** An account has one admin edit and one self-service edit.
**Steps:**
1. Open the account's change history.
2. Compare the two entries.
**Expected Result:** The admin edit is attributed to the acting admin and marked as admin-initiated; the self-service edit is marked as user-initiated — the two are distinct.
**Priority:** High

## 2.3 Bulk Student Registration (CSV Upload) for Institutes

### TC-SA-03-02-021 — CSV template download includes required and optional columns
**Type:** Positive
**Covers:** 2.3 → CSV template download with required and optional columns (name, email, phone, DOB, class/grade, guardian contact)
**Preconditions:** Super Admin logged in.
**Steps:**
1. Download the CSV template.
2. Inspect the columns.
**Expected Result:** The template contains the required and optional columns: name, email, phone, DOB, class/grade, guardian contact — clearly marked.
**Priority:** High

### TC-SA-03-02-022 — Upload performs row-level validation with specific per-row errors
**Type:** Positive
**Covers:** 2.3 → Upload with row-level validation (format, required fields, duplicates within the file and against existing accounts); Rule: validation is row-level and specific; each error names the row and the problem
**Preconditions:** A CSV with 200 rows: 190 valid, 8 with errors (missing phone, invalid email format), 2 duplicates against existing accounts.
**Steps:**
1. Upload the CSV.
2. Review the validation results.
**Expected Result:** Validation is row-level: the 8 error rows each name the row and the specific problem (missing phone, invalid email format); the 2 duplicates are identified.
**Priority:** Critical

### TC-SA-03-02-023 — Pre-commit preview shows valid rows, error rows with messages, and duplicate rows
**Type:** Positive
**Covers:** 2.3 → Pre-commit preview: valid rows, error rows with specific error messages, and duplicate rows
**Preconditions:** A CSV upload has been validated (190 valid, 8 errors, 2 duplicates).
**Steps:**
1. Open the pre-commit preview.
2. Verify the three sections: valid count, error list with per-row reasons, duplicate list.
**Expected Result:** The preview shows all three sections accurately — the Super Admin can review before committing.
**Priority:** Critical

### TC-SA-03-02-024 — Commit creates the valid accounts linked to the institute with provisional credentials
**Type:** Positive
**Covers:** 2.3 → Commit: create the valid accounts linked to the institute, with provisional credentials or invite links
**Preconditions:** The pre-commit preview shows 198 valid rows (after a corrected re-upload).
**Steps:**
1. Commit the upload.
2. Verify the created accounts in the directory (filtered by institute + status "invite pending").
3. Verify each account is linked to the institute and has an invite link.
**Expected Result:** 198 student accounts are created, linked to the institute, with invite links sent to each student's email/phone.
**Priority:** Critical

### TC-SA-03-02-025 — Error report download preserves the original rows with reasons for re-upload
**Type:** Positive
**Covers:** 2.3 → Error report download: the failed rows with reasons, for correction and re-upload; Rule: the error report preserves the original rows so the institute can correct and re-upload without re-keying
**Preconditions:** A CSV upload produced 8 error rows.
**Steps:**
1. Download the error report.
2. Verify each failed row is present with its original data and the reason.
3. Correct the rows and re-upload.
**Expected Result:** The error report preserves the original rows with reasons; the corrected rows re-upload successfully without re-keying.
**Priority:** High

### TC-SA-03-02-026 — Progress and completion summary shows created, failed, and duplicates skipped
**Type:** Positive
**Covers:** 2.3 → Progress and completion summary (created, failed, duplicates skipped)
**Preconditions:** A CSV upload is committed (198 created, 0 failed, 2 duplicates skipped).
**Steps:**
1. Observe the progress during the commit.
2. Review the completion summary.
**Expected Result:** Progress is shown during the operation; the completion summary reports created (198), failed (0), and duplicates skipped (2).
**Priority:** High

### TC-SA-03-02-027 — The bulk operation is audit-logged as a single event with the full row-count breakdown
**Type:** Positive
**Covers:** 2.3 → Audit logging of the bulk operation (file, row counts, acting admin); Rule: the bulk operation is audit-logged as a single event with the full row-count breakdown
**Preconditions:** A CSV upload is committed.
**Steps:**
1. Open the audit trail and locate the bulk operation entry.
2. Verify the entry's fields.
**Expected Result:** A single audit event records the file reference, the row counts (created/failed/duplicates), the acting admin, and the timestamp.
**Priority:** Critical

### TC-SA-03-02-028 — Duplicates are not silently created; they are reported and mapped to the existing account
**Type:** Negative
**Covers:** 2.3 → Rule: duplicates (within the file or against existing accounts) are not silently created; they are reported and mapped to the existing account
**Preconditions:** A CSV contains 2 rows whose emails match existing accounts, and 2 rows that duplicate each other within the file.
**Steps:**
1. Upload the CSV.
2. Review the duplicate handling.
3. Verify no duplicate accounts were created.
**Expected Result:** All 4 duplicates are reported (not silently created); the against-existing duplicates are mapped to the existing accounts; the within-file duplicates are flagged.
**Priority:** Critical

### TC-SA-03-02-029 — The commit is a deliberate step after preview; nothing is created until confirmed
**Type:** Negative
**Covers:** 2.3 → Rule: the commit is a deliberate step after preview; nothing is created until the Super Admin confirms
**Preconditions:** A CSV upload has been validated and the preview is shown.
**Steps:**
1. Do not commit — navigate away from the preview.
2. Check the directory for newly created accounts.
3. Return and commit.
4. Check the directory again.
**Expected Result:** Before the commit, no accounts are created; after the commit, the valid accounts are created — the commit is the deliberate trigger.
**Priority:** Critical

### TC-SA-03-02-030 — Created accounts follow the same policy as individually created ones
**Type:** Positive
**Covers:** 2.3 → Rule: created accounts follow the same policy as individually created ones (verification, provisional credentials, institute link)
**Preconditions:** A bulk upload creates student accounts.
**Steps:**
1. Commit the upload.
2. Open one created account and verify its verification state, provisional credential, and institute link.
3. Compare with an individually created student account.
**Expected Result:** The bulk-created account follows the same policy as the individually created one — verification state, provisional credentials, and institute link are identical in treatment.
**Priority:** High

## 2.4 Account Type-Specific Fields and Requirements

### TC-SA-03-02-031 — Type-specific required fields are enforced per account type
**Type:** Positive
**Covers:** 2.4 → Type-specific required fields (institute: license seat count, contact; staff: role; student: guardian, DOB; affiliate: commission profile)
**Preconditions:** Super Admin logged in.
**Steps:**
1. Create an institute account — verify license seat count and contact are required.
2. Create a staff account — verify role is required.
3. Create a student account — verify guardian and DOB are required.
4. Create an affiliate account — verify commission profile fields are required.
**Expected Result:** Each type's required fields are present and enforced — the form matches the type's requirements exactly.
**Priority:** Critical

### TC-SA-03-02-032 — Type-specific verification requirements are enforced (minors: parental consent; affiliates: identity verification)
**Type:** Positive
**Covers:** 2.4 → Type-specific verification requirements (minors: parental consent; affiliates: identity verification)
**Preconditions:** A minor student account and an affiliate account are being created.
**Steps:**
1. Create the minor's account — verify it routes to the parental consent flow.
2. Create the affiliate account — verify it routes to identity verification.
**Expected Result:** The minor's account shows "consent pending" until the guardian completes consent; the affiliate account requires identity verification — both are enforced, not optional.
**Priority:** Critical

### TC-SA-03-02-033 — Type-specific downstream setup happens as part of creation
**Type:** Positive
**Covers:** 2.4 → Type-specific downstream setup (institute: license provisioning; staff: role and permissions; student: seat allocation)
**Preconditions:** An institute, a staff member, and a student are being created.
**Steps:**
1. Create the institute account with a license seat count — verify the license is provisioned.
2. Create the staff account with a role — verify the role and permissions are applied.
3. Create the student account linked to the institute — verify the seat is allocated.
**Expected Result:** Each account's downstream setup (license, role/permissions, seat) happens as part of creation — the account is usable immediately after.
**Priority:** Critical

### TC-SA-03-02-034 — Completeness indicator shows pending items without blocking the account's existence
**Type:** Positive
**Covers:** 2.4 → Completeness indicator per account (which required items are pending); Rule: the completeness indicator surfaces pending items without blocking the account's existence
**Preconditions:** A recently created student has phone verification pending but a seat allocated.
**Steps:**
1. Open the student's record.
2. Verify the completeness indicator.
3. Verify the account exists and is usable despite the pending item.
**Expected Result:** The indicator shows "phone verification pending, seat allocated" — the pending item is surfaced without blocking the account's existence.
**Priority:** High

### TC-SA-03-02-035 — Guidance prompts appear for missing required items
**Type:** Positive
**Covers:** 2.4 → Guidance prompts for missing required items
**Preconditions:** A student account is missing the guardian link.
**Steps:**
1. Open the student's record.
2. Observe the guidance prompt for the missing guardian.
**Expected Result:** A guidance prompt identifies the missing required item (guardian) and directs the Super Admin to complete it.
**Priority:** Medium

### TC-SA-03-02-036 — Consistency between the type's fields and its available actions
**Type:** Positive
**Covers:** 2.4 → Consistency between the type's fields and its available actions
**Preconditions:** Accounts of each type exist.
**Steps:**
1. For each account type, verify the available actions match the type's fields (e.g., an institute has license actions; a student has seat actions).
**Expected Result:** Each type's available actions are consistent with its fields — no action references a field the type does not have.
**Priority:** Medium

### TC-SA-03-02-037 — Required fields block save until complete; the form shows exactly what is missing
**Type:** Negative
**Covers:** 2.4 → Rule: required fields block save until complete; the form shows exactly what is missing
**Preconditions:** An institute account form is open with the license seat count left blank.
**Steps:**
1. Attempt to save the incomplete form.
2. Observe the error message.
**Expected Result:** The save is blocked; the form shows exactly what is missing (license seat count) — no vague error.
**Priority:** Critical

### TC-SA-03-02-038 — A minor's account cannot be fully active without guardian consent
**Type:** Negative
**Covers:** 2.4 → Rule: type-specific verification requirements are enforced, not optional (a minor's account cannot be fully active without guardian consent)
**Preconditions:** A minor's account is created but the guardian has not completed consent.
**Steps:**
1. Attempt to activate the minor's account to full status.
2. Complete the guardian consent.
3. Attempt the activation again.
**Expected Result:** The activation is blocked until the guardian consent is complete; after consent, the activation succeeds.
**Priority:** Critical

### TC-SA-03-02-039 — Downstream setup makes the account usable immediately after creation
**Type:** Positive
**Covers:** 2.4 → Rule: downstream setup (license, role, seat) happens as part of creation, so the account is usable immediately after
**Preconditions:** A staff account is created with the role "Teacher/Content Creator".
**Steps:**
1. Complete the staff member's first login.
2. Immediately attempt a role action (create a course draft).
**Expected Result:** The account is usable immediately after creation — the role action works from first login.
**Priority:** High

### TC-SA-03-02-040 — The form never shows fields that do not apply to the account type
**Type:** Negative
**Covers:** 2.4 → Rule: fields are type-appropriate; the form never shows fields that do not apply to the account type
**Preconditions:** A student account form is open.
**Steps:**
1. Inspect the student form for institute-only fields (license seat count, billing contact).
2. Inspect the institute form for student-only fields (guardian, DOB).
**Expected Result:** The student form shows no license fields; the institute form shows no guardian/DOB fields — fields are strictly type-appropriate.
**Priority:** High

### TC-SA-03-02-041 — All type-specific creation and editing is audit-logged like any other account change
**Type:** Positive
**Covers:** 2.4 → Rule: all type-specific creation and editing is audit-logged like any other account change
**Preconditions:** Type-specific creations and edits have been performed (institute license change, student guardian update).
**Steps:**
1. Open the audit trail for each account.
2. Verify the type-specific changes are logged.
**Expected Result:** Every type-specific creation and edit is audit-logged with the acting admin, the change, and the timestamp — identical in treatment to any other account change.
**Priority:** High