Implement the following plan:

Group Photo Awareness on Instructor Activity Page

Context

During in-class activities with grouped stages, the instructor controls panel shows completion counts like "2 of 10 groups" but doesn't show WHO is working with whom. The goal is to display student photos clustered by group so the instructor can see at a glance which students are paired together. Names appear on hover.

Data Flow

• Activity sessions (activitySessions) track meeting-level stage progress
• Groups (activityGroups + activityGroupMembers) track who is in which group, keyed by groupKey + activityId + semester
• Completions (activityStageCompletions) link sessions to groups via groupId column
• Photos served at /api/admin/roster/photo/:uin, with email→UIN mapping from roster CSV
• The status endpoint already detects grouped stages and counts groups, but doesn't return membership details

Files to Create

1. apps/api/src/lib/roster-utils.ts — Shared roster helpers

Extract parseRosterCsv, getDataDir, and getCurrentSemesterId from apps/api/src/routes/admin/roster.ts so both the roster route and the new groups endpoint can reuse them.

2. New API route: groups for a session

File: apps/api/src/routes/admin/activity-stages.ts (add new route)

Add GET /:meetingSlug/groups?semester=... to the existing admin activity stages router.

Logic:

1. Find the session by meetingSlug + semester
2. Get all activityStageCompletions with non-null groupId, grouped by stageIndex
3. For each stage's group IDs, look up the activityId from activityGroups
4. For each activityId, get ALL groups and members (including groups that haven't completed yet — this catches groups that formed but are still working)
5. Parse the roster CSV to build email→UIN map
6. Return:

{
  stageGroups: {
    [stageIndex: number]: Array<{
      groupId: string;
      members: Array<{
        name: string | null;
        email: string;
        uin: string | null;
        joined: boolean;
      }>;
      completed: boolean; // whether this group has completed this stage
    }>;
  }
}

Files to Modify

3. apps/api/src/routes/admin/roster.ts — Use extracted helpers

Replace inline parseRosterCsv, getDataDir, getCurrentSemesterId with imports from apps/api/src/lib/roster-utils.ts.

4. apps/web/components/mdx/activity-stage-instructor.tsx — Add group photos UI

Changes to ActivityStageInstructorControls:

• Add a second useSWR call for the groups endpoint: /api/admin/activity-stages/${meetingSlug}/groups?semester=${semester}, polling every 3s (same as status)
• Only fetch when session exists (conditional SWR)
• Pass group data to StageRow via new groups prop

Changes to StageRow:

• New optional prop: groups: Array<{ groupId, members[], completed }>
• When stage.isGrouped && groups?.length > 0, render a group visualization below the existing stage info
• Layout: A flex-wrap row of group clusters
• Each group cluster: An avatar stack of 2-3 small circular photos (h-8 w-8), slightly overlapping with negative margin (-ml-2 for 2nd+ photo)
• Completed groups: green ring/border on the cluster
• Non-completed groups: default border
• Photos with UINs: <img> with src="${env.NEXT_PUBLIC_API_URL}/api/admin/roster/photo/${uin}", title="${name}" for hover
• Photos without UINs (no photo): Show initials circle with gray background, title="${name}"
• The whole group cluster is compact — something like a pill/chip containing the overlapping avatars
• Add data-testid attributes for testing: group-cluster-{groupId}, group-member-{email}

5. testing/e2e/tests/full-activity-flow.spec.ts — Add group visualization test

Add a new test that extends the existing full-flow pattern:

test("instructor sees group clusters after students form groups and complete a stage")

Steps:

1. Create instructor + 4 students (to get 2 groups)
2. Instructor starts session
3. Two pairs of students form groups
4. Both pairs complete Stage 1
5. Verify instructor view shows group clusters via data-testid="stage-group-clusters-0"
6. Verify 2 group clusters are visible (one per pair)
7. Verify each cluster contains 2 member avatars with data-testid="group-member-avatar"
8. Verify member names are accessible via title attribute

Note: Test users won't have actual photos (no UIN/photo file), so the test verifies the initials-fallback UI. The structure and grouping logic is fully testable.

Implementation Order

1. Create apps/api/src/lib/roster-utils.ts (extract helpers)
2. Update apps/api/src/routes/admin/roster.ts (use extracted helpers)
3. Add groups endpoint to apps/api/src/routes/admin/activity-stages.ts
4. Update apps/web/components/mdx/activity-stage-instructor.tsx (fetch + display)
5. Add E2E test to testing/e2e/tests/full-activity-flow.spec.ts

Verification

1. Check dev server is running: curl -sk -o /dev/null -w "%{http_code}" https://[local-hostname]/
2. Navigate to a meeting page with group activities as instructor (e.g., /spring2026/meetings/2026-02-17-alphago-discussion)
3. Start the activity session
4. Open the meeting page in another browser/incognito as a student, form a group
5. Verify the instructor view shows photo clusters for formed groups
6. Verify hovering a photo shows the student name
7. Verify completed groups get a visual distinction
8. Run E2E test: CI=true cd testing/e2e && bunx playwright test --project=full-activity-flow
9. Run type checking: cd apps/web && bun run tsc and cd apps/api && bun run tsc

If you need specific details from before exiting plan mode (like exact code snippets, error messages, or content you generated), read the full transcript at: ~/.claude/projects/-Users-challen-www-usingandunderstanding-ai/da526847-cef4-4927-90df-fba4cbf7473c.jsonl

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Can we check if the backup task is working properly? It should have run overnight.

Amazing! Can we check for those files using local rclone and make sure the contents look sane?

I reconnected.

Nice! Thanks. This works perfectly.

Your task

First, run git status, git diff, and git log --oneline -10 to understand the current state.

Then add and commit all modified files with a descriptive message. Break the changes into multiple commits if appropriate. If there are untracked files, ask if they should be added or added to the appropriate .gitignore file. The user may also want to take over at this point, so provide an abort option as well. Always check changes for unnecessary debugging statements or logging that might have been accidentally included. Prompt the user if you find any, and offer to remove each one by one. Do not use interactive git staging (git add -p) as it does not work.

Nice! OK. Now we need another conversational assessment with questions about creativity drawn from our recent discussion and the AlphaGo documentary. This one should also be set up for students to take on their own, similar to the Turing Test one. Actually let's make it publicly accessible as well. Start by picking a few questions. For this assessment, it may be best to choose a few that ask students to choose a position, maybe similar to or identical to questions explored during yesterday's discussion. Design the questions and the assessment configuration for the two-agent approach.

One concern here is that we didn't really get to Question 4 yesterday in class, so students might not be familiar with the metaphors. Perhaps we can make this less tied to the discussion, and ask instead simply about how they think humans and AI can or can't work together effectively?

Note that I'm gone again tomorrow so I'm going to post this for students to do outside of class, so it won't be linked off of a meeting.