I'll implement the instructor view for GroupActivity. Let me start by reading the relevant files.

Let me also check the roles library to understand the existing pattern.

Now I have all the context. Let me create a todo list and implement the changes.

The TypeScript errors are pre-existing in a different file (lib/time.ts), not related to my changes. Let me verify my changes compile correctly by checking the specific files.

Those errors are from running tsc outside the Next.js project context. Let me check if there are any lint issues and verify the dev server still works.

The lint warnings are pre-existing (not from my changes). Let me check if the dev server is running.

Implementation complete. Here's a summary of the changes:

Files modified:

1. group-activity-context.tsx - Added isAdmin: boolean to GroupActivityContextValue interface

2. group-activity.tsx - Added instructor detection using isInstructor() and isViewingAsStudent() from @/lib/roles, passing both values to the client component

3. group-activity-client.tsx - Added isAdmin and viewAsStudent props, calculates effectiveAdmin (admin but not viewing as student), and renders an instructor view that bypasses the "Find a Partner" dialog with an "Instructor View" banner

4. group-role-content.tsx - When isAdmin is true, shows all role content with amber badges indicating the role name

To verify:

1. Log in as instructor → navigate to a GroupActivity (e.g., AI Scavenger Hunt)
2. Should see "Instructor View" banner and all content directly (no partner dialog)
3. All GroupRoleContent sections should be visible with role badges
4. Toggle "View as Student" → should see the normal "Find a Partner" dialog

The changes look clean with no debugging statements or unnecessary logging. All 4 modified files are related to the same feature (instructor view for GroupActivity).

Here's a summary of the changes:

• group-activity.tsx: Added instructor detection using isInstructor() and isViewingAsStudent()
• group-activity-client.tsx: Added instructor view rendering that bypasses the "Find a Partner" dialog
• group-activity-context.tsx: Added isAdmin to the context type
• group-role-content.tsx: Shows all role content with badges for instructors

Committed successfully: 697f705 - "Add instructor view for GroupActivity"

Let me explore how sessions work with GroupActivity and ActivityStages to answer your questions.

Great questions. Here's what I found:

GroupActivity: No Session Required

GroupActivity operates independently of ActivityStages sessions. Students can form groups at any time without you starting a session first. The group formation flow:

1. Student visits → gets a join code (e.g., ABC-DEF)
2. Partner enters code → both are paired
3. Group status becomes "complete" → content is revealed

So you don't need to start a session for group formation to work.

ActivityStages Timing Display

Currently, timing information (soft/hard caps, elapsed time) is only shown after you start a session. Before that, instructors just see the stage list without any timing details.

Your idea makes sense - showing the configured timing even before starting would help you preview what students will experience. Let me check what the instructor view currently looks like without a session.

I see the issue. When no session exists, the instructor controls only show "Start Session" without any preview of the configured stages and timing. The stageMetadata is available (it has all the timing info), but it's not displayed until after the session starts.

Would you like me to add a preview section that shows the stage list with configured timing before the session starts? Something like:

Instructor Controls

No active session.

Stage Preview:
  1. Brainstorm Ideas          soft:5m | hard:10m | countdown:1m
  2. Discuss with Partner      soft:3m | hard:5m
  3. Share Results             (no timing caps)

[Start Session]

This would let you see the timing configuration at a glance before starting. Want me to implement this?

Now let me add the StagePreviewRow component at the end of the file.

Let me verify the changes look correct.

Done. The instructor controls now show a stage preview before the session starts:

Changes:

• Added "Stage Preview" section showing all stages with their configured timing
• Each row displays: stage number, label, and timing info (soft/hard caps, countdown)
• Stages without timing show "no timing" in italics
• Made the Start Session button full-width for consistency

You can now see the timing configuration at a glance before starting a session. The dev server should pick up the changes automatically.

Let me check the meeting file for tomorrow (2026-01-27).

You're correct - no timing caps are configured. The stages have time="10m" but that's just informational metadata (shown in your facilitation notes). It doesn't create actual timing behavior.

For real timing controls, you'd need props like:

• softCap="8m" - shows "wrap up" warning
• hardCap="10m" - auto-advances (or forces manual advance)
• countdown="1m" - shows countdown timer starting at 9 minutes

Currently your stages look like:

<ActivityStage label="The Confabulator" time="10m" rotateRoles>

To add timing, you'd change to something like:

<ActivityStage label="The Confabulator" softCap="8m" hardCap="10m" countdown="1m" rotateRoles>

Would you like me to add timing caps to the stages? Based on your schedule:

• 4 stages at 10 minutes each → softCap="8m" hardCap="10m" countdown="1m"
• Challenge Items at 30 minutes → softCap="25m" hardCap="30m" countdown="2m"
• Synthesis at 10 minutes → softCap="8m" hardCap="10m" countdown="1m"

Or would you prefer different timing?

time does nothing - it's not in the ActivityStageProps interface. React silently ignores unknown props, so time="10m" is just passing through without any effect.

The valid timing props are:

• softCap - shows "wrap up" hint
• hardCap - auto-advances when exceeded
• countdown - shows countdown timer before hard cap

So time="10m" is effectively just a comment. You could:

1. Remove it - since it's misleading
2. Replace with real timing - use softCap/hardCap/countdown
3. Keep for documentation - but readers might think it does something

Want me to replace time with actual timing caps for tomorrow's activity?

That's a good idea. An estimatedTime prop would serve as documentation that shows in the instructor preview, but doesn't create any automatic behavior. It's explicit that timing is instructor-controlled.

Let me first remove the dead time props from tomorrow's activity.

Removed all the time props.

For estimatedTime, the design would be:

• Purely informational - shown in instructor preview/controls
• No automatic behavior - instructor advances manually
• Clear visual distinction - so it's obvious this isn't a cap

The preview could show something like:

Stage Preview
  1. The Confabulator     ~10m (manual)
  2. The Yes-Man          ~10m (manual)
  ...

vs. stages with real caps:

  3. Some Timed Stage     soft:8m hard:10m countdown:1m

Want me to implement estimatedTime? Or is the instructor notes table at the top (with times) sufficient for now?

Yes, exactly! The schedule table at the top is manually maintained and duplicates the stage information. That's error-prone.

If we add estimatedTime to the stages, we could:

1. Use the instructor preview as the source of truth - the preview panel we just built already lists stages with timing. Add estimatedTime there and the manual table becomes redundant.

2. Auto-generate the schedule table - create a component like <ActivitySchedule startTime="2:05pm" /> that reads the ActivityStage children and builds the table automatically.

Option 2 is cleaner for documentation but more complex. Option 1 is simpler - just remove the manual table and rely on the instructor controls preview.

Which direction appeals to you? Or maybe a hybrid: add estimatedTime, show it in the preview, and remove the manual schedule table from the MDX?

Yes, definitely possible. The ActivityStages component already iterates over children to inject the index prop - we can extend that to gather metadata.

Design could be:

<ActivityStages meetingSlug="..." startTime="2:05pm">

<ActivityStage label="The Confabulator" estimatedTime="10m" rotateRoles>
  <FacilitationNotes>
  Philosophy: Students discover AI hallucinations through direct experimentation.
  </FacilitationNotes>
  
  ## The Confabulator
  ...content...
</ActivityStage>

<ActivityStage label="The Yes-Man" estimatedTime="10m" rotateRoles>
  <FacilitationNotes>
  Watch for the A → B → A flip pattern. Some students struggle to find debatable topics.
  </FacilitationNotes>
  
  ## The Yes-Man
  ...
</ActivityStage>

</ActivityStages>

Then the instructor controls would auto-generate:

Start times calculated automatically from startTime + cumulative estimatedTime.

Want me to implement this? The pieces would be:

1. Add estimatedTime prop to ActivityStage
2. Add FacilitationNotes component (instructor-only, extracted for table)
3. Add startTime prop to ActivityStages
4. Generate the schedule table in instructor controls

Let me start implementing. First, I'll add estimatedTime to ActivityStage.

Now let me update tomorrow's meeting to use these new features and remove the manual schedule table.

Done! Here's what I implemented:

New features:

1. estimatedTime prop on ActivityStage - for instructor-controlled timing (no auto-advance)
2. FacilitationNotes component - extracted and shown in the schedule table, not rendered for students
3. startTime prop on ActivityStages - base time for calculating stage start times
4. Auto-generated schedule table - replaces the manual table in instructor controls

Tomorrow's meeting now looks like:

<ActivityStages meetingSlug="..." startTime="2:05pm">

<ActivityStage label="The Confabulator" estimatedTime="10m" rotateRoles>
<FacilitationNotes>
Students discover AI hallucinations. Niche academic topics work best.
</FacilitationNotes>

## The Confabulator
...
</ActivityStage>

The instructor controls will show a schedule table with:

The start times are calculated automatically from startTime + cumulative durations. You can check it in the dev server now.

I'll update FacilitationNotes to display inline for instructors using the activity stages context.

Done! FacilitationNotes now displays inline for instructors with an amber-styled box showing "Facilitation Notes" as a header.

What instructors see:

• Schedule table in controls (with notes column)
• Inline notes box at the start of each stage

What students see:

• Nothing (notes are hidden)

The dev server should show this now. Each stage will display the facilitation notes in an amber box right below the stage header for instructors.

Good catch. Let me explore how the sidebar/table of contents is currently generated.

Right, the "use client" directive makes the helper functions unavailable on the server. Let me split this into two files - one for the client component, one for the server-side extraction utilities.

Fixed. The extraction functions are now inlined in the server component (activity-stages.tsx), while FacilitationNotes remains a client component that uses context to check isAdmin.

The dev server should work now. You mentioned the sidebar issue with "View as Student" - would you like me to look into that next?

Connection pool exhaustion. Quick fix - restart the database:

bun run db:stop && bun run db:start

This happens in dev when hot reloading creates new connections faster than they're released. If it keeps recurring, we may need to look at the connection pool configuration in the db package.

You can kill idle connections directly in PostgreSQL:

docker exec -it usingandunderstanding-postgres psql -U postgres -d usingandunderstanding -c "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle' AND pid <> pg_backend_pid();"

Or just restart the dev server (not the database) - the old connections will eventually timeout and the new server will get fresh ones.

Let me look at how the database connections are managed.

The issue is connection leaks during hot reloading. Each reload creates a new connection pool without closing the old one. The fix is to use the global object pattern to persist connections across hot reloads.

You're right to question this. Let me check how this is typically handled.

Yes, it's a well-known issue. The standard solution is the globalThis singleton pattern to persist the connection across hot reloads. Let me implement it.

Done. The fix uses globalThis to persist the database connection across hot reloads - the standard pattern for Next.js/Drizzle/Postgres.

You'll need to restart the dev server once to pick up this change to the db package. After that, hot reloads will reuse the same connection instead of creating new ones.

Sources:

• Drizzle Team - PostgresError: sorry, too many clients already
• Prisma Issue #1983 - too many clients in develop mode

Changes:

1. apps/web/components/mdx/activity-stage-instructor.tsx - Added schedule table, startTime support, estimatedTime/facilitationNotes in StageMetadata
2. apps/web/components/mdx/activity-stage.tsx - Added estimatedTime prop
3. apps/web/components/mdx/activity-stages.tsx - Added startTime prop, FacilitationNotes extraction logic
4. apps/web/mdx-components.tsx - Added FacilitationNotes to MDX components
5. content/spring2026/meetings/2026-01-27-ai-scavenger-hunt.mdx - Updated to use new props, removed manual schedule table
6. packages/db/src/client.ts - Fixed connection pool exhaustion with globalThis pattern

Untracked file:

• apps/web/components/mdx/facilitation-notes.tsx - New component

These changes fall into two logical groups:1. The FacilitationNotes/schedule table feature (all the activity-stage stuff + the MDX content update) 2. The database connection pool fix

I should offer to commit these as two separate commits since they're unrelated.

Let me check for any debugging statements or unnecessary logging. Looking at the diff, I don't see any console.log or debug statements that shouldn't be there. The code looks clean. </thinking>

I see changes that fall into two logical groups:

1. FacilitationNotes & Schedule Table feature:

• apps/web/components/mdx/activity-stage-instructor.tsx - Schedule table generation
• apps/web/components/mdx/activity-stage.tsx - estimatedTime prop
• apps/web/components/mdx/activity-stages.tsx - startTime prop, FacilitationNotes extraction
• apps/web/components/mdx/facilitation-notes.tsx - New component (untracked)
• apps/web/mdx-components.tsx - Register FacilitationNotes
• content/spring2026/meetings/2026-01-27-ai-scavenger-hunt.mdx - Use new features

2. Database connection pool fix:

• packages/db/src/client.ts - globalThis pattern for hot reload

No debugging statements or unnecessary logging found.

Done. Created two commits:

• 5c16976 - FacilitationNotes component and auto-generated schedule table
• ee3f538 - Fix database connection pool exhaustion during hot reload

This is a different task - creating a comprehensive E2E test for the full activity flow. Let me explore the existing E2E testing infrastructure and understand how to set this up.

Excellent! I now have a comprehensive understanding of both the E2E testing infrastructure and the activity flow. Let me design the test plan.

I've written a comprehensive plan for the full activity flow E2E test. Key points:

Test Setup:

• 1 instructor + 4 students (forming 2 pairs)
• Dedicated test meeting at e2e-activity-test.mdx with 3 stages
• GroupActivity with driver/observer roles and rotation

Flow Tested:

1. Session start by instructor
2. Group formation (2 pairs via join codes)
3. Role assignment verification
4. Stage completion by all students
5. Instructor advancement with role rotation
6. Pause/Resume functionality
7. FacilitationNotes visibility (instructor-only)
8. Session reset

Files to Create:

• content/spring2026/meetings/e2e-activity-test.mdx - Test meeting
• testing/e2e/full-activity-flow.spec.ts - Test spec