Student details panel

# Student details panel

A richer side panel that gives teachers a meaningful snapshot of a student — work organized by assignment, grade averages, and other at-a-glance signals — replacing the current flat, unsorted list of papers.

## Problem

When a teacher clicks "view details" on a student in their student list, the panel shows the student's name, email, and then a flat list of papers with no grouping or context. For a student who has submitted work across multiple assignments over a semester, this list becomes a wall of text with no way to quickly answer the question a teacher actually has: "How is this student doing, and on what?"

The panel is real estate that could answer that question in seconds. Right now it doesn't.

## Goals

- Organize submissions by assignment so a teacher can scan work in context.
- Surface an average grade so the teacher gets a quick health-check number.
- Make the panel a useful first stop before clicking into individual submissions.

## Non-goals

- This is not a full gradebook replacement. Don't try to replicate spreadsheet-style grade entry here.
- No inline grading from this panel — clicking a submission still navigates to the submission view.
- No comparison across students (that's a class-level feature, not a student-detail feature).

## Domain notes

- The panel operates on a single **Course** + **Student** pair.
- Submissions are snapshots tied to **Assignment** instances. Grouping by assignment means grouping by the `Assignment` record associated with each `Submission`.
- Grades live on `Submission`. Average grade is computed client-side from released grades on that student's submissions within the course.
- Only released grades should factor into the displayed average — unreleased grades are not visible to the student and should not appear in teacher-facing aggregate either (consistency, avoid confusion).
- If no grades are released yet for a student, show "No grades released yet" rather than a 0 or blank.

## UX sketch

The panel header stays the same: student name and email at the top.

Below the header, the body reorganizes into assignment-grouped sections:

```
+------------------------------------------+
| Jane Smith                               |
| jane@school.edu                          |
|                                          |
| Average grade: 84%          (released)   |
|                                          |
| ── Essay 1: The Great Gatsby ──          |
|   Draft 1          submitted Oct 3  72%  |
|   Revision         submitted Oct 12 85%  |
|                                          |
| ── Essay 2: Of Mice and Men ──           |
|   Draft 1          submitted Oct 24 88%  |
|                                          |
| ── Daily pages ──                        |
|   Oct 1 entry      submitted Oct 1       |
|   Oct 2 entry      submitted Oct 2       |
|   (no grade)                             |
+------------------------------------------+
```

- Assignments are listed chronologically by their due date or creation date (whichever is available).
- Within an assignment, submissions list chronologically (earliest first — draft before revision).
- Grade shown inline if released; blank if unreleased (teacher sees the grade; this panel is teacher-only).
- Daily pages and ungraded assignment types still appear — omitting them would make the list feel incomplete and create confusion ("where did that paper go?").
- Empty state if the student has no submissions in this course: "No submissions yet."

## Data model implications

No new fields or tables required for the initial version. The panel is a read-only view assembled from existing `Submission`, `Assignment`, and `AssignmentType` records.

If average grade computation becomes expensive at scale (teacher with 150+ students all opening panels), a denormalized `average_released_grade` field on `Enrollment` or a similar join table could be added later. Design that as a read-replica or event-sourced aggregate — not a write-path concern for v1.

## File paths in `yawp-2.0` likely to change

- `services/web-app/app/components/StudentDetailsPanel` (or wherever the current panel lives — the component rendering name, email, and the flat paper list)
- `services/web-app/app/routes/` — any loader that fetches the student's submissions for this panel will need to join through `Assignment`
- Possibly a new or expanded query in `packages/db/` if the current query doesn't return assignment context alongside submissions

## Open questions

- [ ] Does the current panel query return assignment data, or just raw submissions? (Bryant — quick lookup)
- [ ] Should unreleased grades be shown to the teacher in this panel, or only released ones? Current thinking: show all grades to the teacher (they own the data), but mark unreleased ones visually so the teacher knows the student can't see them yet.
- [ ] Is there other per-student data worth surfacing here — e.g., last active date, paste alert count, feedback request count? Flag for a v2 pass once the assignment grouping lands.

## Edge cases

- Student with submissions spanning multiple courses: the panel is scoped to the course context it was opened from — only show that course's submissions.
- Student with submissions in an assignment that has since been deleted or archived: still show the submission, label the assignment as "(removed)" or similar.
- Submissions with no associated assignment (legacy data or daily pages that predate the Assignment model): group under a catch-all "Unassigned" section at the bottom.
- Average grade with a mix of numeric and letter grades: defer to v2; v1 can assume numeric grades only and skip non-numeric ones in the average.
- Teacher opens panel for a student with 50+ submissions: the list should be scrollable within the panel without affecting the main page scroll.

## Test plan

- Unit: grade average calculation — released only, excludes unreleased, handles zero-grade case, handles no-released-grades case.
- Integration: loader returns submissions correctly grouped by assignment in the expected order.
- Manual QA:
  - Open panel for a student with submissions across 3 assignments — verify grouping, order, and grades.
  - Open panel for a student with no submissions — verify empty state.
  - Open panel for a student whose submissions include one with a released grade and one without — verify only released grade counts toward average.
  - Verify panel scroll is independent of main page scroll.

## Rollout

Feature flag on. Roll out to UA professor first (highest volume — stress test the list length). Expand to Washington and Birmingham City after one week with no issues.

## Engineering handoff checklist

A spec is `ready-for-engineering` only when all of these are true. Mark them off in the spec itself before flipping status.

- [ ] Domain context covered
- [ ] File paths in `yawp-2.0` listed
- [ ] Data model implications spelled out, including backward-compat plan
- [ ] UX sketch in prose
- [ ] Edge cases enumerated
- [ ] Test plan written
- [ ] Rollout plan decided