> UAISP26
/login
All Sessions

Plan: E2E Tests for Page Capture System

February 25, 20266:35 AM – 7:18 AM(43 min)5 turns
Model: claude-opus-4-6, claude-sonnet-4-6
Edit20Read18Grep10Bash8TaskUpdate4TaskCreate2Write2Task2EnterPlanMode1AskUserQuestion1ExitPlanMode1
6:35 AM

Implement the following plan:

Plan: E2E Tests for Page Capture System

Context

The page capture system (profile page, capture tokens, Tampermonkey userscript, capture browsing) was just implemented but has no E2E tests and no data-testid attributes. We need to add test IDs to the components and create a Playwright test suite covering access control, the token lifecycle, and navigation.

Also: the capture empty state still references "Chrome extension" — fix that while adding test IDs.

Changes

1. Add data-testid attributes to profile client

File: apps/web/app/profile/client.tsx

AttributeElement
profile-pageOutermost <div> (line 113)
profile-name<p> showing profile.name (line 123)
profile-email<p> showing profile.email (line 124)
profile-role<span> showing profile.role (line 125)
preferred-name-inputPreferred name <input> (line 138)
preferred-name-saveSave <Button> (line 146)
preferred-name-messageSave confirmation <p> (line 151)
capture-token-sectionCapture section outer <div> (line 174)
capture-generate-token"Generate Token" <Button> (line 226)
capture-install-link"Install Capture Script" <a> (line 177)
capture-regenerate-token"Regenerate Token" <Button> (line 183)
capture-revoke-token"Revoke" <Button> (line 190)

2. Add data-testid attributes to capture client

File: apps/web/app/capture/client.tsx

AttributeElement
capture-page-emptyEmpty state wrapper <div> (line 56)
capture-pageNon-empty state wrapper <div> (line 66)

Also: change line 59 from "Use the Chrome extension to capture web pages." to "Use the Tampermonkey userscript to capture web pages."

3. Add data-testid to user menu profile link

File: apps/web/components/user-menu.tsx

Add data-testid="user-menu-profile-link" to the <Link href="/profile"> DropdownMenuItem (line 66).

4. Add Playwright config project

File: testing/e2e/playwright.config.ts

Add project entry:

{
  name: "captures",
  testMatch: /captures\.spec\.ts/,
  use: { ...devices["Desktop Chrome"] },
  dependencies: deps,
},

5. Create test file

File: testing/e2e/tests/captures.spec.ts (new)

Uses the auth fixture (../fixtures/auth.fixture). Test structure:

Profile Page
  Access Control
    - unauthenticated user redirected to /login
  Student Profile
    - student sees name, email, role
    - student can edit and save preferred name
    - student does NOT see capture token section
  Instructor Profile
    - instructor sees capture token section
    - instructor generates token → install link, regenerate, revoke appear
    - instructor revokes token → returns to generate state
    - install link href contains /api/admin/capture-tokens/script.user.js

Capture Page
  Access Control
    - unauthenticated user redirected to /login
    - student sees empty capture page (silently fails on admin API)
    - instructor can access capture page (sees empty state)

Navigation
  - instructor sees "capture" in more dropdown (nav-more-trigger → nav-capture)
  - student does NOT see "capture" in more dropdown

Nav tests follow the existing pattern from navigation.spec.ts and chat.spec.ts: open nav-more-trigger, check nav-more-dropdown, assert nav-capture visible/absent.

Files Summary

ActionFile
Modifyapps/web/app/profile/client.tsx — add 12 data-testid attributes
Modifyapps/web/app/capture/client.tsx — add 2 data-testid attributes, fix stale Chrome extension text
Modifyapps/web/components/user-menu.tsx — add 1 data-testid
Modifytesting/e2e/playwright.config.ts — add "captures" project
Createtesting/e2e/tests/captures.spec.ts — new test file

Verification

# Run just the captures tests
cd testing/e2e && CI=true bunx playwright test --project=captures

# Type check
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/acd3438b-89e7-4b95-8032-1907e302e65d.jsonl

I'll start by reading all the files I need to modify in parallel.

Now let me read an existing test file and the auth fixture to understand the patterns.

Let me also check how existing tests handle instructor vs student navigation.

Let me check the navigation component for the capture link and how nav items are structured.

Good, the nav item has label: "capture" so the test ID will be nav-capture. Now I have all the information I need. Let me implement all the changes.

Now let me apply all the data-testid edits in parallel.

Now edit the capture client and user menu.

Now add the captures project to Playwright config and create the test file.

Now create the test file.

Now let me run the type check and the tests.

TypeScript passes. Now let me check the dev server and run the E2E tests.

All 18 tests pass. Let me mark the task as complete.

All done. Here's a summary of the changes:

Modified files:

  • apps/web/app/profile/client.tsx — added 12 data-testid attributes (profile-page, profile-name, profile-email, profile-role, preferred-name-input, preferred-name-save, preferred-name-message, capture-token-section, capture-generate-token, capture-install-link, capture-regenerate-token, capture-revoke-token)
  • apps/web/app/capture/client.tsx — added 2 data-testid attributes (capture-page-empty, capture-page) and fixed "Chrome extension" → "Tampermonkey userscript"
  • apps/web/components/user-menu.tsx — added data-testid="user-menu-profile-link" to profile link
  • testing/e2e/playwright.config.ts — added "captures" project entry

Created:

  • testing/e2e/tests/captures.spec.ts — 13 tests covering:
    • Profile page access control (unauthenticated redirect)
    • Student profile (sees info, edits preferred name, no capture section)
    • Instructor profile (capture section, token generate/revoke lifecycle, install link)
    • Capture page access control (unauthenticated, student, instructor)
    • Navigation (instructor sees capture in more menu, student doesn't)

All 18 tests pass (including 5 smoke dependency tests).

Edit13Read7Grep4TaskUpdate4Bash3TaskCreate2Write1
6:50 AM

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.

The changes look clean — no debug statements or stray logging. The untracked file (captures.spec.ts) should be included. All five changes belong together as a single commit.

Committed as 56fe299. Here's what went in:

  • apps/web/app/profile/client.tsx — 12 data-testid attributes added
  • apps/web/app/capture/client.tsx — 2 data-testid attributes + "Chrome extension" → "Tampermonkey userscript" fix
  • apps/web/components/user-menu.tsx — data-testid="user-menu-profile-link" on profile link
  • testing/e2e/playwright.config.ts — "captures" project registered
  • testing/e2e/tests/captures.spec.ts — new, 13 tests, all passing
Bash2
6:52 AM

There's a failing test in the activity-stage-timing project, perhaps related to recent timing changes.

Let me run that test suite to see what's failing.

The failing test expects "ahead" at time=0 but the UI shows "on schedule". Let me read the test and the timing indicator component.

I can see the issue. The test at line 1283 is named "session timing indicator shows on schedule initially" but asserts "ahead". The recent buffer-based timing change (commit 302f64d) changed the logic: at time=0 on the first stage, the buffer is 0 (no completed stages saved time, no overrun on current stage), so absDelta ≤ 30 → "on schedule". The test comment and assertion are stale from the old delta calculation.

Let me fix the test.

Now let me re-run the tests to verify the fix.

Bash2Read2Grep2Edit1
6:56 AM

Can we use data testIDs rather than ContainText? That's a bit of a smell.

Good call. Let me check how the timing indicator renders to see where to add test IDs.

Now let me see what all the timing indicator tests assert so I can fix them all at once.

And the one I already edited (which was rejected). Let me read the full context of each of these tests and the paused one too.

Now I have the full picture. There are 6 assertions using toContainText with timing status strings. Let me add data-testid attributes to the three indicator <span> elements, then update all the test assertions.

Now update all 6 test assertions. First the failing one (line 1309-1312), then the rest.

Now the two "on schedule" assertions in the paused test and the "ahead" in the accumulates test.

Let me also check for the "Stage 2 of 4" toContainText — that one is fine since it's not a timing assertion, but let me verify there are no other timing-related toContainText calls I missed.

The remaining toContainText calls are for stage progression text like "Stage 2 of 4" or "(ended)" — those are fine. All the timing-status ones have been converted. Now let me run the tests.

All 33 tests pass. Here's what I did:

Root cause: Test #29 expected "ahead" at time=0, but the buffer-based timing logic (from commit 302f64d) correctly computes buffer=0 at session start (no completed stages, no overrun) → "on schedule".

Fixes:

  1. apps/web/components/mdx/activity-stage-instructor.tsx — added data-testid attributes to the three timing indicator states: session-timing-on-schedule, session-timing-ahead, session-timing-behind
  2. testing/e2e/tests/activity-stage-timing.spec.ts — replaced all 6 toContainText("ahead"/"behind"/"on schedule") assertions with getByTestId("session-timing-*").toBeVisible(), and fixed the stale test expectation (time=0 → "on schedule", not "ahead")
Edit6Read4Grep2Bash1
7:00 AM

Yeah, I'm not 100% happy with the timing logic yet. I think when we're inside a section we should assume that it runs to time and at least also show the time prediction based on that, alongside the current real-time prediction. So if we start a 10 minute chunk and we're five minutes behind, it should show five minutes behind until we finish that chunk, or exceed the chunk timing, at which point it should update. Does that make sense? We could add this alongside the current real-time timing.

Let me make sure I understand the current logic and what you want before planning.

Let me understand the full data model — what timing data the component has access to.

Good findings. Let me explore the stage advance API to understand how to compute per-stage effective times.

Now let me check exactly what the live indicator would need vs the projected one.

Let me check what data contains (specifically stages) and whether it's available to the indicator.

Good — stages (with per-stage startedAt) is available in the parent and can be passed to the indicator. Now let me check the AdminStatusResponse type to see the stages shape.

Now I have all the information. Let me think about the approach and ask the user a key question before finalizing.

Good choices. Now I have a clear picture. Let me write the plan.

Read5Task2Grep2EnterPlanMode1AskUserQuestion1Write1ExitPlanMode1