I'll start by reading the key files I need to modify, then implement the changes systematically.

Now let me read all the files I need to modify in parallel.

Now let me read the instructor panel file and the DB schema index.

Now let me also read the DB schema index file and the E2E test files.

Let me also read the group-activities schema to understand the activityGroups table structure.

Now let me read the E2E test files that need updating.

Good, now I have a clear picture of all files. Let me start implementing.

Task 1: Schema changes

Now add the type exports for the new table and the updated completion type.

Task 2: Generate migration

Let me verify the generated migration.

Migration looks correct. Now apply it locally.

Task 3: Update student API routes

First, update the import and add the check-in table.

Now update the GET status endpoint to include userCheckins.

Now update the complete endpoint to accept groupId in the request body.

Task 4: Update admin API routes for group-aware counts

Now update the admin status endpoint to return group-aware counts.

I need to clean up the unused totalResult variable from that dead query. Let me fix the admin route — I have a leftover query that I don't need.

I need to remove the dead first query and fix the let to const.

Task 5: Update client context and components

First, update activity-stage-context.tsx — add hasGroupActivity to StageMetadata, extend completeStage signature, add check-in support.

Add hasGroupActivity to StageMetadata.

Now update the context value interface to add check-in support and extend completeStage.

Now update the provider implementation. Add userCheckins memoization.

Now update completeStage to accept groupId and send it in the body.

Now add the isStageCheckedIn callback.

Now update the context value to include the new fields.

Now update the preview provider to include the new fields.

Now update activity-stages.tsx to pass hasGroupActivity through stageMetadata to the context. Looking at the code, hasGroupActivity is already collected at line 169, and the metadata map already has it as an optional field. But the StageMetadata interface in the context doesn't include it — I already added it above. The activity-stages.tsx already sets hasGroupActivity on line 169. The issue is just that when passing stageMetadata to the context, the types need to match. Let me verify the map type used in activity-stages.tsx includes it.

Good — hasGroupActivity is already being collected at line 169. The map already includes it. Since I added hasGroupActivity?: boolean to the StageMetadata interface in the context, the types will be compatible. The activity-stages.tsx file doesn't need changes.

Now update group-activity-client.tsx to pass groupId when auto-completing.

Now update activity-stage-client.tsx to add the check-in gate for individual stages.

Now add the check-in state and handler.

Now add the check-in handler right after handleComplete.

Now add the check-in gate. For individual stages (no GroupActivity child), when the user hasn't checked in, show the stage label but hide content behind a "Start" button. I need to add this logic after the preview/shouldShow checks and before the main render.

I'll add the check-in gate right after if (!shouldShow).

Now I need to pass hasGroupActivity from the ActivityStage component down to ActivityStageClient. Let me check how the server-side ActivityStage component passes props to the client.

I see — ActivityStage is the server component that wraps ActivityStageClient. I need to have the client component read hasGroupActivity from the stageMetadata via the context rather than passing it as a prop, since the server component doesn't have access to the runtime hasGroupActivity detection logic directly (it's done in the parent ActivityStages).

Actually, the cleaner approach is to read it from the context's stageMetadata map inside ActivityStageClient, since the stageMetadata is already passed to the provider and includes hasGroupActivity. Let me update the approach — instead of passing hasGroupActivity as a prop, read it from context.

Now update the instructor panel to show the new completion count format.

Now update the completion count display in the StageRow component.

Task 7: Type check first to catch any issues before updating tests

All type checks pass. Now let me update the E2E tests.

Task 6: Update E2E tests

Let me read the E2E test files to find the exact lines to change.

Let me also search for any test IDs related to start buttons and check-in to understand the test patterns.

Now I need to understand the context around these tests. The key thing is:

1. Tests with "0 completed" text will still show "0 completed" (because totalCount is 0 when no check-ins/groups exist, fallback to old format)
2. Tests with "1 completed" / "2 completed" need context — for individual stages, they'll now show "X of Y" format once students have checked in

Let me read the relevant sections more carefully to understand which stages are group-based and which are individual.

Now I need to understand the test activity page to know which stages have GroupActivity and which don't.

So in the activity-stages test page:

• Stage 0 ("Opening Discussion"): individual (no GroupActivity) — will need check-in
• Stage 1 ("Group Formation"): has GroupActivity — no check-in needed
• Stage 2 ("Case Study"): individual — will need check-in
• Stage 3 ("Class Discussion"): individual — will need check-in

For activity-stages.spec.ts:

• Line 119: "0 completed" — this is right after starting, before any students interact. totalCount will be 0 for all stages, so the display will be "0 completed" (unchanged).
• Line 329: "0 completed" — same situation, just started. Will still be "0 completed".
• Line 345: "1 completed" — a student completed stage 0 (individual). Since the student now needs to click "Start" first, we need a check-in click. After check-in, totalCount becomes 1. After completion, display would be "1 of 1" instead of "1 completed".

Let me now read the full-activity-flow test page and mixed-stages test page.

Important observation: In full-activity-flow, the GroupActivity wraps the entire ActivityStages. But my hasGroupActivityChild check in activity-stages.tsx only looks at direct children of each ActivityStage. Since there's no GroupActivity as a direct child of any ActivityStage here (it's at the outer level), hasGroupActivity will be false for all stages.

However, there's a subtlety: the stages inside this GroupActivity don't have their own GroupActivity as a direct child — instead the parent GroupActivity wraps the whole ActivityStages. So these stages will be detected as individual stages and require check-in, which is wrong.

Wait, let me re-examine. Looking at the test page structure:

• GroupActivity wraps ActivityStages which wraps ActivityStage elements
• Inside each ActivityStage there's GroupActivityRoleDisplay and GroupRoleContent, but no GroupActivity

So hasGroupActivityChild will be false for all stages in the full-activity-flow test page. But these are effectively group stages since they're wrapped in a GroupActivity parent. The students have already formed groups before the stages begin.

The check-in gate should only apply when a stage truly has no group context. I need to check if the GroupActivity context is available, not just if the stage's direct children contain a GroupActivity.

Let me check what context is available when GroupActivity wraps ActivityStages.

I can use useOptionalGroupActivity in ActivityStageClient to detect if the stage is inside a GroupActivity context, regardless of whether the GroupActivity is a direct child or a parent wrapper.

Now update the hasGroupActivity logic to also check the context.

Now let me re-read the mixed-stages test page.

Mixed stages:

• Stage 0 ("Paired Stage One"): has GroupActivity as direct child → grouped (no check-in)
• Stage 1 ("Individual Stage Two"): no GroupActivity → individual (needs check-in)
• Stage 2 ("Individual Stage Three"): no GroupActivity → individual (needs check-in)
• Stage 3 ("Paired Stage Four"): has GroupActivity → grouped (no check-in)

Now let me read the relevant portions of each E2E test to understand exactly what needs to change.

Now I understand the full picture. For the activity-stages test:

• Stage 0 is individual → students will now see a "Start" button first
• Before the complete button is visible, they need to click "Start" to check in

I need to add check-in clicks before completion attempts in tests where individual stages are involved. Let me now update all three test files.

Starting with activity-stages.spec.ts:

Now let me read the "student sees first stage with label" test more carefully. This test at line 50 checks that a student sees stage 0. With the check-in gate, the student will still see stage 0 (the label and number are shown), but won't see the content until they click "Start". The test currently checks for activity-stage-0-label, which is shown in the check-in gate UI. So this test should still pass.

Let me check the test at line 204-211 where a student clicks the complete button for stage 0:

The student needs to first click "Start" (check in), then they'll see the complete button. Let me update the tests.

For activity-stages.spec.ts, the key changes:

1. Before clicking activity-stage-0-complete-button, click activity-stage-0-start-button first
2. "0 completed" stays the same (no totalCount yet)
3. "1 completed" becomes "1 of 1" (one student checked in and completed)

Now update the test at line 280+ where it accesses stage 1 (which has GroupActivity, so no check-in needed) and the completion count test.

I need to update the autoAdvance test (stage 0 and 1 are visible, student needs to click start for stage 0 before seeing its complete button, and stage 1 has GroupActivity so no start needed). Wait — in the autoAdvance test, the student is at stage index 1 (Group Formation, which has GroupActivity). The student clicks the complete button for stage 1 directly. Since stage 1 has GroupActivity, no check-in is needed.

But wait — stage 0 ("Opening Discussion") is individual and the student needs to check in. In this test, the student doesn't interact with stage 0 at all, they just check it's visible. With the check-in gate, stage 0 will show the label and start button instead of content. The test checks activity-stage-0 is visible, which will still be true.

For stage 1, the student clicks activity-stage-1-complete-button. Stage 1 has GroupActivity as direct child. But wait — the GroupActivity shows the group join UI, not the complete button directly. Unless the student has already joined a group... Actually in this test, the student doesn't join a group, they just click the complete button. That means the test bypasses GroupActivity. With the check-in gate, since stage 1 has GroupActivity, no check-in is needed, so the complete button should still be accessible.

Hmm, actually let me re-think. Stage 1 in the test page has GroupActivity as a child. The GroupActivity shows join UI first. But the complete button is on the ActivityStage level, not inside GroupActivity. So the student can click the complete button without going through GroupActivity. This is the existing behavior and won't change.

Now for the completion tracking test (line 319+), I need to:

1. Add check-in click before the student can see the complete button for stage 0
2. Change "1 completed" to "1 of 1"

Now I also need to update the "student sees next stage when instructor advances" test where the student completes stage 0. Let me find and fix that:

Good - this one was already updated in my earlier edit.

Now let me handle the full-activity-flow.spec.ts. This test has GroupActivity wrapping all stages, so useOptionalGroupActivity() will return non-null and no check-in gate will appear. The completions will be tracked with groupId.

Line 108: "0 completed" — this is before any groups have formed, so totalCount will be 0, and the fallback "0 completed" will still show. No change needed.

Line 376: "2 completed" — this is in the full-activity-flow where GroupActivity wraps all stages. When students complete, they'll now send groupId with the completion. The admin endpoint will detect these as grouped completions and show "X of Y groups". Since both students are in the same group, completedCount will be 1 group (COUNT DISTINCT groupId), and totalCount will be 1 group.

Wait — the two students are in one group (size 2). Both students complete → 2 completion records, both with the same groupId. COUNT(DISTINCT groupId) = 1. Total formed groups = 1. So the display would be "1 of 1 groups".

This changes the expected text significantly. Let me update this.

Now let me find the other "2 completed" references in full-activity-flow.spec.ts.

Both at line 928 and 970 — same pattern, 2 students in 1 group completing → "1 of 1 groups".

Good catch. Let me fix the display logic to handle singular/plural properly.

Now fix the E2E test expectations to use singular "group" where totalCount is 1.

Now let me finish updating the remaining "2 completed" in full-activity-flow.spec.ts at line 970 (stage 2, also 1 group).

Now update mixed-stages.spec.ts.

In mixed-stages:

• Stage 1 (index 1) and Stage 2 (index 2) are individual → need check-in
• Stage 3 (index 3) has GroupActivity → "2 completed" becomes "1 of 1 group"

For stages 1 and 2, the test currently directly clicks activity-stage-1-complete-button. With the check-in gate, students need to click activity-stage-1-start-button first. After check-in, the content and complete button become visible.

Also, stage 1 check at line 119 (stage-1-individual-content) — this content is behind the check-in gate, so it won't be visible until the student clicks Start.

Now update the "2 completed" for stage 3 (grouped stage, 1 group of student1+student3).

Now let me check if there are any other tests that need the start-button click. Let me search for tests that interact with individual stages in the activity-stage-timing test.

Let me check what test page the timing spec uses.

This uses the same /testing/components/activity-stages page. Stage 1 (index 1) is the "Group Formation" stage which has GroupActivity — so no check-in needed. The complete button will be directly visible. No changes needed for that test.

But let me check if there are other student interactions in the timing test that touch individual stages.

Good — no interaction with stage 0 (the individual stage) in the timing tests. Let me also check the meeting test file.

Let me check which page and what stages this test uses.

This is an actual meeting page, not a test page. Let me check the MDX to see which stages have GroupActivity.

So:

• Stage 0 (index 0): has GroupActivity child → no check-in
• Stage 1 (index 1, "Complete the Turing Test"): no GroupActivity → needs check-in
• Stage 2 (index 2, "Assessment Feedback"): no GroupActivity → needs check-in
• Stage 3 (index 3, "Agents Talking to Agents"): has GroupActivity child → no check-in

The test at lines 217-219 clicks activity-stage-1-complete-button for all students. These students need to check in first. Similarly at lines 238-240 for stage 2.

I need to add check-in clicks for stages 1 and 2 in this test. Also at line 206, the test checks for a link inside stage 1 content, which is behind the check-in gate. Student s1 needs to check in first. But wait — s1 navigates away and back at line 213, so they'll need to check in, and after checking in the check-in persists (stored in the DB).

Let me also check earlier in this test for any stage 0 interactions... Actually stage 0 has GroupActivity, so no issue there.

Now let me run the type check again to make sure the new import in activity-stage-client.tsx is valid.

All type checks pass. Let me now verify there are no remaining "completed" strings in test assertions that I missed.

Only "0 completed" remains, which is correct — when totalCount is 0, the display falls back to "X completed".

Here's a summary of all changes made:

Schema (packages/db/src/schema/activity-stages.ts):

• Added nullable groupId column to activityStageCompletions referencing activityGroups.id
• Created new activityStageCheckins table for tracking individual stage participation

Migration (packages/db/drizzle/0011_jazzy_quasar.sql): Generated and applied.

Student API (apps/api/src/routes/activity-stages.ts):

• POST /:meetingSlug/complete/:stageIndex now accepts optional groupId in request body
• New POST /:meetingSlug/checkin/:stageIndex endpoint (idempotent check-in)
• GET /:meetingSlug now returns userCheckins alongside userCompletions

Admin API (apps/api/src/routes/admin/activity-stages.ts):

• Status endpoint returns completedCount, totalCount, and isGrouped per stage
• Grouped stages: counts distinct groups completed vs total formed groups
• Individual stages: counts completions vs check-ins

Client context (activity-stage-context.tsx):

• StageMetadata now includes hasGroupActivity
• completeStage accepts optional groupId
• Added checkinStage, userCheckins, isStageCheckedIn

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

• Uses useOptionalGroupActivity() to detect group context (handles both direct-child and parent-wrapper patterns)
• Individual stages show a "Start" check-in gate before revealing content
• Admins and preview mode skip the gate

Group activity client (group-activity-client.tsx):

• Passes data?.groupId to completeStage() on auto-completion

Instructor panel (activity-stage-instructor.tsx):

• Displays "X of Y group/groups" for grouped stages, "X of Y" for individual stages with check-ins, "X completed" fallback when no denominator exists
• Proper singular/plural: "1 group" vs "2 groups"

E2E tests: Updated activity-stages.spec.ts, full-activity-flow.spec.ts, mixed-stages.spec.ts, and meeting-2026-02-03.spec.ts to click "Start" before interacting with individual stage content, and to expect the new count format.

Let me check TODOS.txt first.

Yes, the "Instructor stage completion count should show groups, not individuals" TODO at lines 17-23 is resolved. Let me remove it and commit.

Let me check for any debugging statements or unnecessary logging.

No debugging statements found. The untracked files are the generated migration SQL and snapshot — those should be committed.

Committed as 8aa0ad6. Working tree is clean.

(no content)

Dev server is running. Let me run all E2E tests.

One failure in activity-stages.spec.ts at line 310 — the autoAdvance test. Stage 1 ("Group Formation") has a GroupActivity child, so while the check-in gate isn't the issue, the GroupActivity shows join UI instead of the complete button. The student hasn't joined a group, so they can't see the complete button directly.

Let me look at the test more carefully.

Let me check the screenshot to understand what the student sees.

I see — the screenshot shows the instructor view. Let me check the second screenshot (the student view).

The student sees both stage 0 and stage 1, but both show "Start" buttons (check-in gates). Stage 0 is individual — correctly shows check-in. Stage 1 ("Group Formation") has a GroupActivity as a direct child, so hasGroupActivity from stageMetadata should be true.

But wait — the GroupActivity component provides context only when it renders its client component. The stageMetadata check happens in ActivityStageClient via stageMetadata.get(index)?.hasGroupActivity, but this metadata is set by the server-side ActivityStages component. Let me verify this is actually being detected correctly.

The issue is that useOptionalGroupActivity() returns null because the GroupActivity is a child of the ActivityStage, not a parent. The GroupActivityProvider is rendered inside GroupActivityClient, which is inside ActivityStage's children — so ActivityStageClient doesn't have GroupActivityProvider as an ancestor.

So the detection relies on stageMetadata.get(index)?.hasGroupActivity. Let me check if hasGroupActivity is being properly passed through to the context's StageMetadata type.

The stageMetadata in activity-stages.tsx at line 169 does set hasGroupActivity. And the StageMetadata interface in the context at line 50 does include it. Let me check if the metadata map passed to ActivityStagesProvider actually carries this field through.

The ActivityStagesProvider takes stageMetadata: Map<number, StageMetadata>. The StageMetadata interface in the context has hasGroupActivity?: boolean. The stageMetadata local variable in activity-stages.tsx has a map type that also includes hasGroupActivity?: boolean. These are structurally compatible, so it should work.

Let me check the ActivityStagesPreviewProvider — it also receives stageMetadata, but the preview provider doesn't matter here since the student is authenticated.

Wait — let me look at the actual stageMetadata type in activity-stages.tsx more carefully. The map has additional fields (estimatedTimeSeconds, facilitationNotes) that aren't in the context's StageMetadata. TypeScript would allow passing a wider type to a narrower one. So the hasGroupActivity field should flow through.

Let me verify this works by adding a quick debug check. Actually, let me just look at the screenshot again — stage 1 shows "Start". That means hasGroupActivity is returning false for stage 1. But we know the server sets it to true at line 169. So the issue must be that the stageMetadata map passed to the context is being re-typed and losing the field, or hasGroupActivityChild isn't detecting the GroupActivity component.

The hasGroupActivityChild looks at direct children of the stage's children prop. But in the metadata collection loop at line 143-172, the children it examines come from child.props.children where child is an ActivityStage element. And ActivityStage in the test page wraps GroupActivity in a <div> — let me check:

The GroupActivity is nested inside a <div> wrapper — it's not a direct child of the ActivityStage. The hasGroupActivityChild function only checks direct children, so it won't find GroupActivity nested inside the <div>.

I need to make hasGroupActivityChild do a recursive search rather than only checking direct children.

Now let me run the type check and then the failing test.

Type check passes. Now run the full E2E suite.

activity-stages now passes. The new failure is in activity-stage-timing at line 562 — countdown timer test. The student can't see the countdown because stage 0 is behind the check-in gate. Let me look at the test.

The student visits stage 0 (individual, no GroupActivity) and needs to check in first. After reload, they still need to be checked in — but the check-in persists in the DB, so after the first check-in, subsequent reloads should show the content.

I need to add the check-in click after the student first visits. Let me also check if there are other similar tests in this file that need fixes.

There are many places where a student visits the activity-stages page and interacts with stage 0 content (countdown timers, soft warnings, etc.). All of these need the check-in step. Let me read the broader patterns to understand which tests need updating.

Many tests interact with stage 0 (individual) and need the check-in. Lines 267 and 320 interact with stage 1 (group) so they don't need check-in.

Rather than updating every individual test, the cleanest approach is to add a helper function. Let me read the top of the file to see the existing helpers.

I'll add a helper to check in to stage 0, then apply it in every test that navigates a student to stage 0.

Now I need to add await checkinStageIfNeeded(studentPage, 0) after each student goto that interacts with stage 0. Let me find all the spots. The pattern is: student navigates to activity-stages, waits for stage 0 to be visible, then interacts with stage 0 content. I need to add the check-in call right after the visibility wait.

Let me do this systematically. The lines where a student goes to the page and then waits for stage 0:

Lines 278 and 331 wait for activity-stage-1 (the group stage) — no check-in needed. All others wait for activity-stage-0 (individual) and need check-in. But I need to be careful — some tests reload the page, and the check-in will persist. Also, some tests freeze time before the goto, so the check-in needs to happen with time already frozen.

Let me use replace_all to add the check-in after the common pattern:

Good. But I also need to handle the case where the student page reloads (e.g. await studentPage.reload()). After a reload, the check-in is already in the DB, so the start button won't appear — checkinStageIfNeeded already handles this by checking if the button count is > 0.

However, there's also the auto-advance-simple test. Let me check if it needs updating.

These reference activity-stage-start-button which is the instructor's session start button, not the student's check-in start button. Different test IDs. No changes needed.

Now let me run the tests again.

Activity-stage-timing now passes. The new failure is in full-activity-flow — the instructor sees "2 completed" instead of "1 of 1 group". Let me look at the screenshot.

(no content)

The issue is on line 100 — handleComplete calls completeStage(index) without passing groupId. When a student is in a group context, the manual "Mark Complete" button needs to pass the group ID too.

Let me verify the group activity context exposes groupId.

Good, groupId is available on the context. Now let me run the failing E2E test to verify the fix.

All 19 tests pass. Now let me run the other previously-failing test suites to make sure everything is clean.

The mixed-stages test at line 251 fails because individual stages now have the check-in gate. The student needs to click "Start" before the content is visible. Let me read the failing test section and fix it.

The student needs to check in (click "Start") before the individual content becomes visible. I need to add check-in clicks before lines 251 and 269.

Now let me re-run the failing test plus the meeting test.

All mixed-stages tests pass. Let me also run the meeting test since it was mentioned in the summary.

Now let me run the full E2E suite to make sure nothing else is broken.

All 174 tests pass across all 24 projects with 0 failures and 0 retries.

Two fixes were needed:

1. activity-stage-client.tsx: handleComplete now passes groupActivity?.groupId to completeStage(), so manual "Mark Complete" clicks inside a group context correctly record the group ID for instructor count display.
2. mixed-stages.spec.ts: Added check-in button clicks for individual stages in the "individual stages don't show group activity UI" test.

No debugging statements or unnecessary logging in the changes. These are all targeted fixes from the E2E test failures. I'll commit them together since they're all bug fixes discovered during E2E testing of the feature from the previous commit.

Committed. Clean working tree.

The rehype-autolink-headings plugin accepts a test option for filtering. I can use it to skip h1 elements.

Let me verify it builds correctly and remove the TODO.

Let me check the TypeScript error.

That's from the earlier change to activity-stage-client.tsx — groupActivity?.groupId is string | null but completeStage expects string | undefined.

Clean. Now remove the TODO and verify the fix works by checking the dev server.

Done. Two changes:

• next.config.ts: Added test: ["h2", "h3", "h4", "h5", "h6"] to rehype-autolink-headings so h1 headings are no longer wrapped in anchor tags.
• TODOS.md: Removed the resolved TODO.
• Also fixed a TypeScript error from the previous commit (null vs undefined for groupId).

A pre-existing lint warning in group-activity-client.tsx. Let me fix it.

All clean. Both lint issues fixed:

• packages/db/scripts/verify-schema.ts: Replaced any types with proper typed entries.
• apps/web/components/mdx/group-activity-client.tsx: Added missing data?.groupId dependency to useEffect.

No debugging statements or unnecessary logging. The changes break down into distinct concerns — I'll split them into separate commits.

Changes:

1. h1 autolink fix (next.config.ts, TODOS.md) — the feature fix
2. Lint/type fixes (verify-schema.ts, group-activity-client.tsx, activity-stage-client.tsx) — lint and type errors
3. Formatter changes (alert-dialog.tsx, activity-stage-instructor.tsx, 0011_snapshot.json, _journal.json, API routes) — auto-formatting by linter

Done. Three commits:

1. 505241b — Exclude h1 headings from rehype-autolink-headings wrapping
2. e0770d1 — Fix lint and type errors in verify-schema, group-activity-client, activity-stage-client
3. 2297e0c — Auto-format API routes, UI components, and drizzle snapshot

(no content)

Let me find the activity content and check which links might be paywalled.

Let me check which links are actually accessible, and read the meeting content for context.

The 404 Media link is confirmed paywalled. The other links are all freely accessible. Let me check if there's a free alternative source for the same story.

Good, plenty of free alternatives. The Wiz blog post (the actual researchers who found the vulnerability) looks ideal. Let me verify it's accessible.

Now let me make both changes: fix the paywalled link, and create a link checker tool.

This is a completely different task. Let me write a fresh plan.