I'll implement the dynamic Table of Contents updates. Let me first read the current implementation.

Now I understand the current implementation. I'll add the MutationObserver with debouncing to detect when headings are added/removed.

Let me verify the implementation by reading the updated file.

The implementation looks good. Let me run TypeScript type checking to ensure there are no errors.

The TypeScript errors are in a different file (activity-stage-instructor.tsx), not in the file I modified. Let me verify my changes compile correctly by running tsc just on the web app's table-of-contents file.

Let me run lint to verify the code quality.

No lint errors. The implementation is complete. Here's a summary of the changes made to apps/web/components/table-of-contents.tsx:

Added:

1. REBUILD_DEBOUNCE_MS constant (100ms) for debouncing
2. rebuildTimeoutRef to track the debounce timeout
3. rebuildToc callback - extracts TOC building logic and returns the data
4. scheduleRebuild callback - debounced rebuild for MutationObserver
5. MutationObserver in the main useEffect that watches for:
   • Added nodes containing h2[id] or h3[id]
   • Removed nodes containing h2[id] or h3[id]
6. Cleanup for both the observer and timeout on unmount

The TOC will now automatically update when:

• Activity stages are unlocked (new headings appear)
• "View as student" toggle changes visibility
• Any other dynamic content adds/removes headings

The pre-existing TypeScript errors in activity-stage-instructor.tsx are unrelated to this change.

Let me run tsc again to see the exact errors.

Let me look at the specific lines with errors. Looking at lines 50-70 for the parseStartTime function and line 609.

Now I understand all the errors. Let me fix them.

Now let me fix the activity-stages.tsx file.

Let me run tsc to verify all errors are fixed.

Let me fix the remaining errors.

All TypeScript errors are fixed. Let me run lint to make sure everything passes.

The lint errors are pre-existing and not related to my changes. Let me verify the files I modified pass lint.

All fixed. Here's a summary of the TypeScript fixes:

apps/web/components/mdx/activity-stage-instructor.tsx:

• Fixed parseStartTime - added proper null checks for regex capture groups (match12?.[1] && match12[2] && match12[3])
• Fixed stagesWithTimes reduce - assigned acc[acc.length - 1] to a variable prev before accessing properties

apps/web/components/mdx/activity-stages.tsx:

• Fixed extractNotesText - properly typed the element as React.ReactElement<{ children?: React.ReactNode }>
• Fixed extractFacilitationNotes - added generic type parameter to React.isValidElement<{ children?: React.ReactNode }>

apps/web/lib/time.ts:

• Fixed getCurrentTime - extracted mock time to a variable before returning to avoid undefined type issue
• Fixed advanceMockTime - extracted current mock time to a variable before arithmetic

Let me find the code entry component to understand the current implementation.

Let me read the current implementation to understand the code format and entry flow.

I can see the current implementation. The code is 6 alphanumeric characters (like "ABC123"), displayed without a dash. Students currently enter it in a single text field. Let me implement a 6-cell segmented input which is cleaner and more intuitive.

Now let me update the input section to use the new CodeInput component.

Let me verify the changes compile correctly and check if there are any E2E tests that reference the old input.

Let me fix the TypeScript error and check what's on line 44.

Now let me update the E2E tests that reference the old input.

The tests use .fill() which won't work directly with segmented inputs. I need to create a helper function. Let me read one of the test files to understand the structure, then add a helper.

I need to add a helper function to fill the segmented code input. Let me update both test files.

Now let me update the full-activity-flow.spec.ts file.

Let me verify all references are updated.

All test references updated. Let me run type checking and lint.

No errors, just pre-existing warnings. Let me check if the dev server is running and we can do a quick test.

Dev server is running. Let me run the group activity E2E tests to verify everything works.

Let me fix both issues.

Now let me fix the lint warnings by wrapping members in useMemo.

The time package is fixed. Let me also fix the pre-existing errors in useSocket.ts and socket.ts.

The socket property is never used. I can remove it from the return type to fix the lint error.

Now fix the socket.ts import warning.

All lint errors fixed. Let me verify TypeScript compiles.

All clean. Let me run the group activity E2E tests to verify the segmented code input works.

All 13 tests pass. Here's a summary of everything that was fixed:

Segmented Code Input (group-activity-client.tsx):

• Replaced single text input with 6-cell segmented input
• Added CodeInput component with:
  • Auto-advance to next cell on input
  • Backspace navigates to previous cell
  • Paste support for full codes
  • Arrow key navigation
• Wrapped members in useMemo to fix lint warnings
• Updated E2E tests with fillPartnerCode helper

Time Package (packages/time/):

• Added eslint.config.js to fix missing eslint config error

Socket Files (hooks/useSocket.ts, lib/socket.ts):

• Removed unused socket return value from useSocket hook
• Fixed type-only import for Socket
• Removed unused useCallback import

Activity Stage Context (activity-stage-context.tsx):

• Added memoized stages array to fix dependency warnings
• Extracted isPaused, pausedAt, totalPausedMs to variables
• Removed unused useEffect import

Activity Stage Client (activity-stage-client.tsx):

• Prefixed unused rotateRoles prop with underscore

All checks pass now. The output shows:

• Tasks: 34 successful, 34 total
• Prettier ran and formatted the code

The two issues fixed were:

1. Removed unused sql import from apps/api/src/routes/admin/activity-stages.ts
2. Changed Socket to type-only import in apps/api/src/socket.ts

Let me explore what's currently set up for the activity flow.

Correct - there's no submission system yet. Here's the current state:

What works now:

• Students form pairs using 6-character codes (now with the nice segmented input)
• Role assignment (driver/observer) with automatic rotation between stages
• Instructor controls: start session, advance stages, pause/resume, reset
• Students see their role-specific content and mark stages complete
• Completion counts visible to instructor
• Timers (soft cap warnings, hard cap countdown)
• Real-time updates via websockets

If you ran it tomorrow:

1. You'd start the session from instructor controls
2. Students pair up by exchanging codes
3. They'd see Stage 1 content with their assigned role (driver/observer)
4. They follow the prompts manually (talk to ChatGPT, try the challenges)
5. They click "Mark Complete" when done
6. You advance to next stage, roles rotate
7. Repeat through all stages

What's missing:

• No submission capture - students do the work but nothing is saved
• They can't paste transcripts, upload screenshots, or record what they found
• You can't see what they discovered after the fact
• No synthesis/reflection form at the end

Is that OK for tomorrow? It could work as a "follow-along" activity where the value is in the doing, not the collecting. Students explore AI limitations together, discuss with their partner, and the learning happens in real-time. You'd just be trusting they're engaging rather than verifying via submissions.

Would you like me to add a simple submission mechanism, or is the current flow sufficient for tomorrow?

Yes, there's a comprehensive E2E test suite at testing/e2e/tests/full-activity-flow.spec.ts. Let me confirm what it covers.

Yes! The test suite covers the full flow. Let me run it to confirm everything passes.

Great! The test suite covers:

• Setup Phase - instructor sees schedule/start button, students see waiting state
• Session Start - instructor controls, facilitation notes display
• Group Formation - pairs form using codes, role content displays correctly
• Stage Completion - students complete stages, see "waiting for instructor" message
• Stage Progression - instructor advances, students see new content
• Role Rotation - roles swap when advancing to stages with rotateRoles
• Pause/Resume - instructor can pause activity, students see paused overlay
• Session Reset - instructor can reset and start fresh
• Full Flow Integration - end-to-end test of the complete activity

Let me know how they go!

Let me check how student roles are currently defined.

Good news - any logged-in @illinois.edu user already gets the "student" role by default. The role assignment logic is:

1. Check if email matches an instructor → "instructor" role
2. Check if email matches staff → "staff" role
3. Everyone else → "student" role

There's no enrollment check on the activity APIs. They just require authentication (authMiddleware), not enrollment status.

So if someone with an @illinois.edu email logs in via Azure AD, they'll:

• Get a session
• Be assigned "student" role (unless they're in the instructor/staff list)
• Have full access to the group activity features

You don't need to change anything - it's already open to any @illinois.edu user who can authenticate. Applied students, random grad students, anyone with a valid Illinois login can participate.

The only thing that checks enrollment is the Canvas sync for things like the roster. The activities themselves are wide open to any authenticated user.

This is a different task - I'll start fresh planning for the /chat page. Let me explore the codebase to understand the existing patterns.

Excellent! I have a good understanding of the existing infrastructure. Key findings:

1. Database schema already exists - conversations and messages tables are ready
2. LLM package ready - chat() and chatStream() functions for Azure OpenAI
3. Agent system - Can load agents with system prompts from markdown files
4. RAG pipeline - Can augment responses with course content
5. UI patterns - Clear patterns for authenticated pages, sidebars, forms

Let me have a Plan agent design the implementation.

Let me verify what API routes actually exist before finalizing the plan.

Excellent! The backend is fully built. Both /api/conversations and /api/chat endpoints exist with streaming support, RAG, agent system, and conversation persistence. I only need to build the frontend.

Let me write the final plan.

The plan is ready. Key points:

Good news: The entire backend already exists - conversations API, chat API with streaming, RAG, and agent system. This is purely frontend work.

Scope:

• 6 files to create (page + client + 4 components)
• Add /chat to header navigation
• Copy format: ## User / ## Assistant with --- separators (readable by humans and parseable by machines)

The chat will automatically:

• Use the default "course-assistant" agent
• Include RAG context from course materials
• Save all conversations to the database

Good point! I'll update the plan to use /chat/[id] for persistent conversation URLs.

Updated the plan with persistent URLs:

• /chat - Start new conversation
• /chat/[id] - Load existing conversation (shareable link)
• First message redirects to /chat/{newId} so URL becomes persistent
• Added layout.tsx for shared sidebar across routes