> UAISP26
/login
All Sessions

Plan: E2E Test for Page Capture Flow

February 26, 20266:22 AM – 7:17 AM(55 min)8 turns
Model: claude-opus-4-6, claude-sonnet-4-6
Bash9AskUserQuestion8Read7Edit6Grep4Task3Write2Glob2ExitPlanMode1
6:22 AM

Implement the following plan:

Plan: E2E Test for Page Capture Flow

Context

The page capture system has E2E tests for UI elements (token management on profile page, navigation visibility, empty states) but nothing tests the actual capture pipeline: generate token → capture a page's content → verify it appears in the /capture list. The Tampermonkey userscript can't be loaded in Playwright (requires persistent context + headed mode), but it's just a thin wrapper around POST /api/captures?token=..., so we can test the real flow by making the same API call.

Approach

Add a test that exercises the full pipeline:

  1. Create instructor, generate a capture token via authenticated API call
  2. Navigate to a page on the dev server (the syllabus — deterministic, no external dependency)
  3. Grab page.content(), page.title(), page.url() — exactly what the userscript captures
  4. POST to /api/captures?token=... — simulating the userscript's GM_xmlhttpRequest
  5. Navigate to /capture and verify the capture appears with correct URL

Also add data-testid attributes to the capture list UI so the test can target individual items.

Changes

1. Add data-testids to capture list items

File: apps/web/app/capture/client.tsx (~line 72)

Add testids to the capture item container and key fields:

  • data-testid="capture-item" on each capture row's outer <div>
  • data-testid="capture-item-url" on the URL <p> element

2. Add capture flow test

File: testing/e2e/tests/captures.spec.ts

Add a new test.describe("Capture Flow") section. Key details:

  • Use page.request (inherits the browser context's cookies) to call POST ${API_URL}/api/admin/capture-tokens — this returns { token, captureUrl }.
  • Navigate to /spring2026/syllabus and grab content via page.content(), title via page.title(), URL via page.url().
  • Use a standalone fetch() (from Node, no cookies needed) to POST to ${API_URL}/api/captures?token=${token} with { url, title, content }.
  • Navigate to /capture and assert capture-page is visible (not capture-page-empty), capture-item has count 1, and capture-item-url contains "syllabus".
test.describe("Capture Flow", () => {
  test("capture a page and verify it appears in the list", async ({ testUsers }) => {
    await testUsers.create([{ id: "instructor1", role: "instructor" }]);
    const { page } = await testUsers.getContext("instructor1");

    // Generate a capture token (page.request inherits cookies)
    const tokenRes = await page.request.post(
      `${API_URL}/api/admin/capture-tokens`
    );
    expect(tokenRes.ok()).toBeTruthy();
    const { token } = await tokenRes.json();

    // Navigate to a deterministic page on the dev server
    await page.goto("/spring2026/syllabus");
    await expect(page.getByTestId("syllabus-page")).toBeVisible({ timeout: 10000 });
    const capturedContent = await page.content();
    const capturedTitle = await page.title();
    const capturedUrl = page.url();

    // Simulate the userscript: POST capture with token-based auth
    const captureRes = await fetch(`${API_URL}/api/captures?token=${token}`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        url: capturedUrl,
        title: capturedTitle,
        content: capturedContent,
      }),
    });
    expect(captureRes.status).toBe(201);

    // Verify capture appears in the list
    await page.goto("/capture");
    await expect(page.getByTestId("capture-page")).toBeVisible({ timeout: 10000 });
    await expect(page.getByTestId("capture-item")).toHaveCount(1);
    await expect(page.getByTestId("capture-item-url")).toContainText("syllabus");
  });
});

Note: Using Node fetch() for the capture POST (not page.request) since the capture endpoint uses token auth, not session cookies. The API is HTTPS with a self-signed cert in dev, so we may need NODE_TLS_REJECT_UNAUTHORIZED=0 or use page.request with the token in the URL.

Actually, page.request with ignoreHTTPSErrors: true (already set on the context) is simpler and avoids TLS issues:

const captureRes = await page.request.post(
  `${API_URL}/api/captures?token=${token}`,
  { data: { url: capturedUrl, title: capturedTitle, content: capturedContent } }
);
expect(captureRes.ok()).toBeTruthy();

Files Summary

ActionFile
Modifyapps/web/app/capture/client.tsx — add data-testid to capture items
Modifytesting/e2e/tests/captures.spec.ts — add capture flow E2E test

Verification

cd testing/e2e && CI=true bunx playwright test --project=captures

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/a68b4305-e212-4833-9782-5d16b994e085.jsonl

Now let me check the test fixtures and config to understand the API_URL pattern and test setup.

Let me see the captures project config in playwright.config.ts.

Good, the project is already configured. Now let me also quickly check the capture token API endpoint to understand the response format.

Now I have all the context I need. Let me implement both changes.

Now let me add the capture flow test to the existing test file.

Now add the capture flow test at the end of the file.

Let me verify the dev server is running before running the tests.

Dev server is running. Let me run the tests.

All 19 tests pass, including the new capture flow test. Here's a summary of what was changed:

apps/web/app/capture/client.tsx — Added data-testid attributes:

  • data-testid="capture-item" on each capture row's outer <div> (line 72)
  • data-testid="capture-item-url" on the URL <p> element (line 81)

testing/e2e/tests/captures.spec.ts — Added the "Capture Flow" test that:

  1. Creates an instructor and generates a capture token via POST /api/admin/capture-tokens
  2. Navigates to /spring2026/syllabus and grabs page.content(), page.title(), page.url()
  3. POSTs the captured data to /api/captures?token=... using page.request (inherits ignoreHTTPSErrors from the browser context)
  4. Navigates to /capture and verifies the capture appears with the correct URL
Read4Grep4Edit3Bash2
6:27 AM

Awesome! Can we use an external page for the capture test?

That's a good idea — capturing an external page is more realistic since that's what the userscript actually does. But there's a catch: page.content() requires navigating to the page in the Playwright browser, and navigating to an external site in E2E tests is fragile (network dependency, slow, could change or go down).

Instead, we can just construct the capture payload directly with a fake external URL — the capture API doesn't care where the content came from, it just stores whatever { url, title, content } you POST. The userscript grabs DOM content client-side and sends it; we can simulate that without actually visiting the page.

AskUserQuestion1Read1
6:28 AM

Well, I guess another option would be to fetch an external page as a fixture and serve it locally during testing.

That's a nice middle ground — real external content, no network dependency at test time. We could:

  1. Save a snapshot of an external page (e.g., example.com) as a fixture HTML file
  2. Use page.route() to intercept navigation to that URL and serve the fixture
  3. Navigate, grab content, POST to the capture API

Let me implement that.

Bash1
6:29 AM

But we'd need something that doesn't load Javascript, and that has some decent content to it (example.com is pretty minimal, but OK for a smoke test). We might want our own mock page that has some on-page Javascript, images, and so on, to make sure that we are doing the capture correctly.

Good thinking. Let me create a purpose-built mock page with JS, images, and varied content, then update the test to serve it locally via route interception.

Now update the test to serve this fixture via route interception.

Now update the test itself.

ES module — need import.meta instead.

All 19 tests pass. Here's what the test does now:

  1. Mock page fixture (testing/e2e/fixtures/capture-mock-page.html) — a realistic article page with JS (sets data-js-loaded attribute, interactive counter), an inline base64 image, a table, code blocks, styled content, and various HTML elements
  2. Route interception — page.route() intercepts navigation to https://example-university.edu/articles/neural-networks and serves the fixture HTML locally
  3. JS execution verified — waitForFunction confirms the page's JavaScript ran (checks data-js-loaded attribute) before capturing page.content()
  4. Full pipeline — generates token, captures the rendered page content, POSTs to the capture API, then verifies it appears in the /capture list with the external URL
Bash3Edit3Write1
6:46 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 debugging statements. I notice the apps/api/package.json and bun.lock changes (hono bump from 4.11.9 → 4.12.2) are unrelated to the capture E2E work and were pre-existing. I'll split these into two commits.

Two commits:

  1. Bump hono to 4.12.2 — pre-existing dependency update
  2. Add capture flow E2E test with mock external page fixture — the capture pipeline test, data-testid attributes, and the mock HTML fixture
Bash3
6:57 AM

OK! Now we need to design today's activity. I think that, given midterms are approaching, we should do the study guide lab. I'd like to also use this opportunity to reinforce effective study techniques and a bit of learning theory. Let's brainstorm together about how it should work! I'd love to hear your ideas.

Let me explore the existing activity system and content to understand the patterns and what's already in place, so I can brainstorm effectively.

This is a great opportunity — a study guide lab that's both practically useful (midterm prep) and teaches students something about how learning works. Let me share some ideas based on what I've seen in the course so far.

The core tension that makes this interesting: AI can generate beautiful study guides instantly, but the cognitive work of creating a study guide is where the learning happens. Outsourcing that work to AI is like having someone else do your reps at the gym. This connects naturally to the course's themes — AI capabilities vs. limitations, and how AI changes human behavior.

Here are some learning science ideas we could weave in:

  • Active recall — trying to remember is more effective than re-reading (the testing effect)
  • Elaboration — explaining concepts in your own words forces deeper processing (Feynman technique)
  • Illusion of competence — reading an AI-generated summary feels like understanding but often isn't
  • Retrieval practice — self-testing is one of the strongest study techniques we know

And a few structural directions:

Direction A: "The Confidence Gap" — Students first try to recall/explain concepts without AI, rate their confidence, then use AI to fill gaps, then test themselves again. The point: reveal the gap between what you think you know and what you actually know.

Direction B: "AI as Quiz Master" — Instead of using AI to generate notes, use it to generate questions. Students create study guides through retrieval practice — answering AI-generated questions, identifying weak spots, then elaborating on those areas.

Direction C: "Teach to Learn" — Pair activity where each partner explains topics to the other (no AI), then they collaboratively build a study guide, using AI only to check accuracy at the end. The explaining is the studying.

Got it — so each stage should have students actively using AI as a study tool, with the activity teaching them how to use AI effectively for studying. That's a great frame: the lab itself is study time, and the meta-lesson is "here's how to use AI well for studying."

A few follow-up questions to refine this:

That completely changes the picture — and it's a brilliant idea! Students get actual study time for their other midterms while learning AI-assisted study techniques. Intrinsic motivation is built right in.

This reframes the activity nicely:

  • Each student brings material from another course they need to study for
  • They learn study techniques that leverage AI effectively
  • The deliverable is something they'll actually use this week
  • The meta-lesson is: AI is a tool for learning, but how you use it matters

The partnering question is interesting now. If partners are in different courses, the observer becomes a "naive skeptic" — they can't be fooled by plausible-sounding AI confabulation because they don't know the subject. That's a feature: "does that actually make sense, or are you just nodding along because the AI sounds confident?" This connects back to the scavenger hunt lessons.

If partners are in the same course, they can quiz each other and validate content directly, which is also valuable.

Three rounds of 15m study + 10m share-out = 75m — that's a really clean structure. I like it. Each round teaches a different AI study technique, and the share-outs are where the learning science reflection happens.

Here's my thinking on the three rounds. Each one introduces a progressively more complex way to use AI for studying, and they build on each other:

Round 1: "The Brain Dump" — Active recall + AI gap analysis

  • Each partner writes down everything they know about a topic from memory (no notes, no AI)
  • Then feed the brain dump to AI: "What am I missing? What did I get wrong?"
  • The partner (who doesn't know the subject) serves as Skeptic: "AI says you missed X — did you actually not know that, or just forget to write it?" This forces the studier to distinguish between gaps in knowledge vs. gaps in recall.
  • Share-out: What did AI find? Did it catch real gaps? Did it add anything wrong?

Round 2: "The Quiz Master" — Retrieval practice / testing effect

  • Upload course materials to AI. Ask it to generate practice exam questions.
  • Answer them without looking at materials or AI. Partner grades honestly.
  • Share-out: Were AI-generated questions good? What kinds of questions was AI bad at writing? How did your confidence compare to your actual performance?

Round 3: "The Study Aid" — Elaboration + illusion of competence

  • Pick your weakest area (revealed by rounds 1 & 2). Use AI to help build a study aid — concept map, cheat sheet, practice problems, whatever works.
  • Partner challenges: "Explain this part to me. Can you answer a question about this without looking?" This catches the illusion of competence — having a beautiful AI-generated summary doesn't mean you understand it.
  • Share-out: Show your study aid. How much came from you vs. AI? Could you pass a quiz on everything in it?

Roles within each 15-min block:

  • Pairs alternate who goes first: ~7 min as Studier (working with AI on their material) while partner is Skeptic (watching, challenging, asking questions), then swap.

What would you like to clarify or adjust? Happy to rethink any part of this.

AskUserQuestion5Task2
7:10 AM

Yeah, I think I'm rethinking having the partner in the loop. The goal is to provide students with more effective ways of using AI to help them prepare individually for upcoming midterms or tests, and they won't necessarily have a human helper. How about this. Each round can start with students talking with their partner about a course assessment and them discussing a way to use AI to help them prepare. Then they both work individually until the share-out period.

That's a much better framing — it mirrors reality. When they're actually studying for exams, they'll be alone with AI. The pair interaction becomes about strategy (how to approach studying with AI), not about the studying itself.

So each round becomes:

  1. Pair kickoff (~3-5 min): Tell your partner about an upcoming assessment. Discuss the study technique for this round — what's the plan?
  2. Solo study (~10-12 min): Individual work with AI using that technique on your own material
  3. Share-out (~10 min): What happened? What worked? What surprised you?

The pair and share-out bookends are where they learn the meta-lesson (how to use AI for studying). The solo block is where they get actual study value.

For the three rounds, I'd still suggest techniques that build on each other:

  1. Active Recall + Gap Check: Recall from memory first, then ask AI what you're missing
  2. Practice Testing: Have AI generate exam questions, answer from memory, check yourself
  3. Build a Study Aid: Create something concrete (concept map, cheat sheet, practice problems) for your weakest area

The progression goes: find out what you don't know → test yourself → build something to fill the gaps.

AskUserQuestion1
7:11 AM

Let's also keep each of these a bit more open-ended in terms of how students use AI. Suggest something (as listed above), but also say that they can choose a different approach.

Great — so each round suggests a technique but students can choose their own approach. The pair kickoff becomes even more valuable: "here's one way to do this, but talk with your partner about what approach you want to try." That leads to more diverse share-outs too.

A few remaining details to nail down:

Perfect — learning science woven into each round, brief reflections, today's class. Let me check if there's an existing meeting file for today's date.

Let me look at the most recent meeting file to match the format, and also check the config for this week's info.

Good, I have everything I need now. Let me write the plan.

Glob2Read2AskUserQuestion1Task1Write1ExitPlanMode1