Assignment class selection

# Assignment class selection

Add a checkbox list to the New Assignment form so teachers can choose which of their actual classes (1st period, 3rd period English Lit, etc.) to push the assignment to — one, several, or all.

## Problem

The New Assignment form currently has a "Student Course" dropdown that selects the AssignmentType (the essay template), and no way to target specific classes. Teachers with multiple sections have to create the same assignment once per period. A teacher with 1st, 3rd, and 5th period sections creates the same assignment three times — pure busywork.

The label "Student Course" is also confusing: it's selecting the type of assignment, not the class, and should be renamed to reflect that.

## Goals

- Let a teacher push one assignment creation to any combination of their classes in a single action.
- Provide a "Select all" shortcut for the common case of assigning to every class.
- Rename "Student Course" to something that accurately describes what it is (the assignment type/template).
- Keep the form compact — it's a modal.

## Non-goals

- Different prompts or due dates per class in a single flow (each selected class gets identical settings; differentiation means creating a separate assignment).
- Rearranging or renaming classes from within this form.

## Domain notes

Post-assignments-unification, the two things the form touches are distinct:

- **AssignmentType** — the template: essay type, prompt, tutor context. Currently selected by the "Student Course" dropdown. One AssignmentType is created per form submission.
- **Course** — a teacher's actual class section (1st period, 3rd period English Lit, etc.). Each is its own Course record. The new checkbox list maps to these.
- **Assignment** — one instance per student per Course. When the teacher selects N classes, Assignment rows fan out to every enrolled student across those N Courses.

The "Student Course" label is a holdover from the pre-unification model. It should be relabeled to **"Assignment Type"** to reflect what it actually selects.

## UX sketch

The updated modal has two distinct fields where there was previously one:

```
Assignment Type               ← renamed from "Student Course"
[ The Thesis-Driven Essay ▾ ]   ← dropdown, unchanged behavior

Classes                  ← new section
[x] Select all
────────────────────────────────────────────
[x] Grade 10 • Period 1 — Kevin's Playground
[ ] Grade 10 • Period 3 — Kevin's Playground
[x] Grade 11 • Period 5 — AP Lang
```

Behavior:
- "Select all" checks every class at once. Unchecking any individual class unchecks "Select all" automatically.
- Checking all classes individually re-checks "Select all."
- At least one class must be checked; "Create Assignment" stays disabled until the selection is non-empty.
- Classes listed in the teacher's natural order (same as dashboard).
- If teacher has only one class, show it pre-checked; "Select all" still present but redundant.
- If teacher has no classes, show a message — "You don't have any classes yet." — and disable "Create Assignment."

Everything else on the form (Title, Prompt Source, Prompt, Tutor Context, Due Date) is unchanged.

## Data model implications

This is additive — no destructive migration. The creation endpoint currently accepts a single course ID; it needs to accept an array.

On submission:
1. One `AssignmentType` row is created (same as today).
2. For each selected Course, `Assignment` rows are created for every enrolled student in that Course.

No schema change to AssignmentType itself. The fan-out is purely at the Assignment-creation layer.

Existing single-class assignment creation is fully backward-compatible — a single-element array behaves identically to the current single-ID call.

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

- `services/web-app/app/components/NewAssignmentModal` (or equivalent) — add checkbox list, rename dropdown label
- `services/web-app/app/routes/assignments` (or API handler) — accept array of course IDs instead of single ID; fan out Assignment rows
- Wherever assignments are listed per-class — verify assignments show up correctly for each targeted class

## Open questions

- [x] Class name disambiguation: Course names already include grade and period in the name itself (e.g. "Grade 10 • Period 1 — Kevin's Playground") — no duplicate problem, no extra field needed. Use the Course name as-is in the checkbox list.
- [x] Exact rename for "Student Course" → **"Assignment Type"**. "Essay Type" was rejected — Daily Pages aren't essays, so the label needs to work for all assignment kinds.

## Edge cases

- Teacher has one class: pre-checked, "Select all" present but redundant. No weird state.
- Teacher has no classes: informational message, "Create Assignment" disabled.
- Selected class has no enrolled students: fan-out produces zero Assignment rows, no error — consistent with existing behavior.
- Very long class list (10+ sections): list scrolls; "Select all" stays pinned at the top.

## Test plan

- Unit: creating an assignment with an array of N course IDs fans out Assignment rows to all enrolled students across those N courses.
- Unit: "Select all" resolves server-side to the teacher's actual course list (client checkbox state is not trusted).
- Integration: assignment created for 3 classes appears correctly on the teacher dashboard for each.
- Integration: assignment created for 1 class still works (regression on existing behavior).
- Manual QA: teacher with multiple sections — checkbox list shows all, "Select all" works, submit fans out correctly.
- Manual QA: teacher with one section — pre-checked, no broken state.
- Manual QA: teacher with no sections — empty state shown, button disabled.

## Rollout

Feature flag — default OFF. Pilot with UA professor first (highest section count), then Washington and Birmingham City, then broad release. The existing single-class path stays fully functional while the flag is off.

## 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.

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