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

Let me read the E2E test file fully to understand the timing tests.

Now I have a complete picture. Let me create tasks and implement everything.

Step 1: Add totalPausedMsAtStart column to schema

Step 2: Update API — start, advance, and status endpoints

Start endpoint — set totalPausedMsAtStart: 0 explicitly for stage 0:

Advance endpoint — set totalPausedMsAtStart to session's current totalPausedMs:

Status endpoint — include totalPausedMsAtStart in stage response:

Step 3: Rewrite frontend — StageStatus type, props, and SessionTimingIndicator

Add totalPausedMsAtStart to StageStatus interface:

Pass stages to SessionTimingIndicator:

Rewrite SessionTimingIndicator — props, calculation, and rendering:

Step 4: Update E2E tests

Now let me read the full test section I need to update to see the exact test code around the timing assertions.

Now I need to update each timing test assertion. Let me apply them one by one:

Test 1: "on schedule initially" — pace=on-schedule, now=ahead (full budget remaining)

Test 2: "behind when over estimated" — both pace and now are behind (converged, overrunning)

Test 3: "on schedule near estimated" — both on-schedule (converged at exact estimate)

Test 4: "freezes when paused" — both on-schedule before pause and after pause

Test 5: "accumulates across stages" — both ahead

Step 5: Generate migration, type check, and run tests

Good, migration generated. Now apply it locally and run type check in parallel.

Type check passes. Now let me check if the dev server is running and then run the E2E tests.

All 33 tests pass, including all 5 timing indicator tests.

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

Schema (packages/db/src/schema/activity-stages.ts): Added totalPausedMsAtStart integer column to activityStageTimings table, with default 0.

Migration: Auto-generated drizzle/0017_tranquil_thanos.sql.

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

• Start endpoint: explicitly sets totalPausedMsAtStart: 0 for all stages
• Advance endpoint: sets totalPausedMsAtStart to session's current totalPausedMs when starting a new stage
• Status endpoint: includes totalPausedMsAtStart in each stage's response data

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

• Added totalPausedMsAtStart to StageStatus interface
• Passes stages array to SessionTimingIndicator
• Replaced single bufferSeconds with dual paceBuffer/nowBuffer calculations:
  • Pace: Uses per-stage totalPausedMsAtStart for accurate completed-stage timing; only counts overrun in current stage
  • Now: Simple budgetThroughCurrentStage - totalElapsed
• Extracted TimingPill component for rendering each indicator with · pace: Xm ahead / · now: Xm ahead format

E2E tests (testing/e2e/tests/activity-stage-timing.spec.ts): Updated all 5 timing assertions to use session-timing-pace-* and session-timing-now-* data-testids. All 33 tests pass.

The diff looks clean — no debugging statements or stray logging. The two untracked files (0017_tranquil_thanos.sql and 0017_snapshot.json) are the generated migration and should be committed with everything else.

This all belongs in one commit:

Committed as 912cca1. One commit covering all 7 files:

• packages/db/src/schema/activity-stages.ts — new totalPausedMsAtStart column
• packages/db/drizzle/0017_tranquil_thanos.sql + meta/ — generated migration
• apps/api/src/routes/admin/activity-stages.ts — set field on start/advance, expose in status
• apps/web/components/mdx/activity-stage-instructor.tsx — dual pace/now indicator logic
• testing/e2e/tests/activity-stage-timing.spec.ts — updated assertions to session-timing-pace-* / session-timing-now-*

Good question. Let me check what testing infrastructure already exists.

There's already a test page at /testing/components/activity-stages that you can visit directly. If you're logged in as an instructor on [local-hostname], you'll see the instructor controls with the timing indicators.

The question is whether you're currently authenticated as an instructor when you visit that page. Let me check how auth works for the testing pages.

So the test page works in dev mode. You can just go to:

https://[local-hostname]/testing/components/activity-stages

If you're logged in as an instructor, you'll see the instructor controls and can:

1. Start a session
2. Watch the pace and now pills appear
3. Wait / advance stages to see them diverge and converge
4. Pause/resume to verify pause handling

The stage estimates are 3m, 2m, 10m, 5m — so you can advance early to see "ahead" or wait past the estimate to see "behind". No extra script needed — that page is purpose-built for this kind of manual testing.

Ah, the page capture system! Let me understand what's there.

The capture system already supports local testing. The Tampermonkey script at /api/admin/capture-tokens/script.user.js is dynamically generated with the API URL from your environment, so when running locally it'll point to https://[local-hostname].

The flow is:

1. Visit https://[local-hostname]/profile as an instructor
2. Generate a capture token
3. Click "Install Capture Script" — Tampermonkey picks it up with the local API URL baked in
4. Browse any page, click "Capture This Page" from the Tampermonkey menu
5. View captures at https://[local-hostname]/capture

Were you asking about testing without Tampermonkey? For example, a bookmarklet version or a simple test page that lets you submit a URL/content directly?

The changes are entirely formatting/whitespace — a formatter pass touched profile/client.tsx, activity-stage-instructor.tsx, captures.spec.ts, and reformatted the Drizzle snapshot JSON (arrays condensed to single lines) plus added trailing newlines to the JSON files. No functional changes, no debug statements.

One clean commit:

Done — 4e56288. All formatting, nothing functional.

Clean — just a turbo bump from 2.8.10 → 2.8.11 in package.json and the corresponding bun.lock update. No debug statements, no untracked files.

Done — 3bf2d92.

Good question about Playwright (which this project uses) and userscript managers. Let me explore the existing capture tests and infrastructure first, and research the Playwright + userscript angle.

Good research findings. The short answer: no, you can't practically load Tampermonkey in Playwright (requires persistent context + headed mode). But we don't need to — the userscript is just a thin wrapper around a POST to /api/captures?token=.... The real value is testing the full flow: generate token, capture page content, verify it appears in the UI.

Let me design a plan.

Now let me check what data-testids exist on the capture display page for the capture items.

The capture list items don't have individual data-testid attributes yet — I'll need to add some for the test to verify content. Now let me look at the E2E test helpers to understand how API calls are typically made from tests.

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

Now let me check how getContext works to understand what's available for making authenticated API calls.

I see — getContext returns { context, page }. The context has cookies set, and I can use context.request or page.request to make API calls that carry those cookies. But for the capture API endpoint, we need the token (not the session cookie) — it's token-based auth. Let me also check the getSessionCookie helper.

Now I have the full picture. The flow will be:

1. Use page.request (which carries the session cookie) to generate a capture token via POST /api/admin/capture-tokens
2. Use a standalone fetch (no cookies needed) to POST to /api/captures?token=...
3. Reload /capture and check the result

Let me write the plan.