# Feature: Student Administration

## Overview
A read-only studio-admin area to browse students and drill into one student's
history and upcoming activity — lessons and group-class enrolments — without
digging through individual records.

## Data Model
No new tables. The views are composed from existing data:
- Students are WordPress users with the `us_student` role (`get_users`, `get_userdata`).
- Lessons come from `{prefix}us_lessons` (with `{prefix}us_availability` for slot times).
- Group-class enrolments come from `{prefix}us_group_enrollments`.
- Policy acceptances come from `{prefix}us_policy_acceptances` (with the policy
  and version tables for titles/numbers).
- Intake answers come from `{prefix}us_question_answers` (with `{prefix}us_questions`
  for labels).
- Payments come from `{prefix}us_payments`.

## Admin Interface
**Students** in wp-admin (`manage_students`, studio admin only):

- **List** — every `us_student` user: display name, email, registered date, and
  quick counts (upcoming lessons, active group enrolments). Each row links to the
  detail view.
- **Detail** (`?student_id=`):
  - **Account** — display name, email, registered date.
  - **Upcoming lessons** and **Past lessons** — split by the linked availability
    slot's `start_dt`; each shows date/time, offering, instructor, and status.
  - **Group-class enrolments** — active/past, with offering title and status.
  - **Policy acceptances** — every acceptance the student has recorded, newest
    first: policy title, version, context (account signup / lesson / enrolment),
    and when it was accepted.
  - **Intake answers** — every registration-question answer, newest first:
    question label, answer, and the registration it was given for.
  - **Payment history** (`manage_billing` only) — every payment, newest first:
    date, context, method, status, subtotal, HST, total, and receipt number.

Read-only in this iteration; cancel/edit actions are a possible follow-up (#70).

## Capabilities
- `manage_students` — studio admin (administrators inherit it via the
  `user_has_cap` filter). No new capabilities or tables.

## Implementation
- Admin controller: `Unsupervised\Schedular\Auth\StudentController` (list + detail)
- Templates: `templates/admin/students.php`, `templates/admin/student-detail.php`
- Reuses `Booking\BookingRepository::findByStudent` + `countUpcomingForStudent`,
  `Availability\AvailabilityRepository::findById`,
  `Offering\OfferingRepository::findById`,
  `GroupClass\EnrollmentRepository::findByStudent` + `countActiveForStudent`
- History sections: `Auth\StudentHistory` builds the display rows from
  `Policy\AcceptanceRepository::findByStudent`,
  `Registration\AnswerRepository::findByStudent`, and
  `Payment\PaymentRepository::findByStudent`, resolving policy/version titles and
  question labels (unit-tested with mocked repositories).
- Upcoming/past split: `Auth\StudentSchedule::partition()` (pure, unit-tested)
- The upcoming/past split is extracted into a small pure helper so it is
  unit-testable (the controller itself follows the repo convention of not being
  unit-tested).

## Tests
- `tests/Unit/Auth/StudentScheduleTest.php` (the pure upcoming/past split helper)
- `tests/Unit/Auth/StudentHistoryTest.php` (history display rows + fallbacks)
- `findByStudent` coverage in `tests/Unit/Policy/AcceptanceRepositoryTest.php`,
  `tests/Unit/Registration/AnswerRepositoryTest.php`, and
  `tests/Unit/Payment/PaymentRepositoryTest.php`