I don't see the capture script install button on the /capture page in product...

All 25 package.json files bumped from 2026.3.1 → 2026.3.2. No debugging statements — just a version bump. Committing now.

Committed: Bump version to 2026.3.2 — all 25 package.json files updated from 2026.3.1 → 2026.3.2.

Let me look at the capture page code to understand how the install button is displayed.

I found the issue. Let me check one more thing about the env setup.

Here's what I found. There are two issues with the install button on the capture page:

1. No way to generate a token from the UI

The install button (client.tsx:92) only renders when captureToken?.token is truthy. But if no token exists, the API returns { token: null } (capture-tokens.ts:23), and there's no "Generate Token" button anywhere in the UI. The POST endpoint to create tokens exists (capture-tokens.ts:34-63), but nothing in the client calls it.

2. Silent error swallowing

In page.tsx:46-51, if the serverApiFetch for the token fails (auth issue, network, role check), the error is silently caught and captureToken stays null — so the button disappears with no indication of why.

The captures list fetch (page.tsx:39-44) has the same silent catch, so if both fail you'd just see an empty page with "No captures yet" and no install button.

Secondary issue: page.tsx:53 sets apiUrl = process.env.API_URL || "http://localhost:3001". In production, your .env.production has NEXT_PUBLIC_API_URL but I don't see a plain API_URL, so the install link might point to localhost:3001.

Do you want me to fix this by adding a "Generate Token" button to the UI (for when no token exists)?

OK so you do have a token — the profile page shows the install button. Let me check the git history to see if the capture page's install button was added in a recent commit that might not be deployed.

Good point — the profile page already has that generate/install flow. The /capture page should too, instead of silently showing nothing when there's no token.

You're right — there's no reason the token needs to be a separate manual step. The GET endpoint could just auto-create a token if one doesn't exist. That way visiting /capture (or /profile) always has a working install link ready.

The change would be in capture-tokens.ts — the GET handler at line 22 currently returns { token: null } when no token exists. Instead it could just create one:

Now the GET endpoint auto-provisions a token, so both /capture and /profile will always have a working install link. The "Generate Token" button on the profile page becomes unnecessary, but it still works as "Regenerate" if someone wants to rotate their token.

Done — your capture token has been deleted. Try visiting /capture now and it should auto-generate a new one and show the install button.

I'll add a section about running SQL directly against the local Docker postgres container, right after the "Local Development" section.

Done. Added a note to the Database > Local Development section in CLAUDE.md explaining to use docker exec instead of psql directly.

The test expects a "Generate Token" button, but now the token is auto-generated so the install link shows immediately. Let me read the test.

Since tokens are now auto-generated on GET, the "generate token" step no longer exists. The tests at lines 64-118 need to be updated — an instructor will immediately see the install link, regenerate, and revoke buttons. The revoke test (line 85) still makes sense since revoking sets the client state to { token: null }, but the page will re-auto-generate on next visit.

Also need to update the Capture Flow test which explicitly POSTs to generate a token — that's no longer needed since GET auto-generates:

All 19 tests pass. The changes were:

• Removed the "generate token first" steps since tokens are now auto-generated on GET
• Changed the Capture Flow test to use GET instead of POST to obtain the token

The package.json files jumped from 2026.3.2 → 2026.3.4 (skipping .3). I'll flag that but proceed with two commits — one for the functional changes, one for the version bump.

No debugging statements in the code changes. Committing:

Done. Two commits:

1. Auto-generate capture token on first access — the functional change + CLAUDE.md + test updates
2. Bump version to 2026.3.4

One thing to note: the version jumped from 2026.3.2 → 2026.3.4, skipping .3. Looks like something bumped it twice before this commit. Worth checking if bun run ncu:apply or similar ran twice unexpectedly.

Let me also check the web app's page.tsx which has the same pattern:

Same issue in both capture/page.tsx and profile/page.tsx.

Now let me check that API_URL is set in .env.development so local dev still works:

Good — .env.development has it, and K8s manifests set it for both prod and dev. But the API deployment doesn't set API_URL. Let me check what env vars the API pod gets:

Yes — the API pod in production doesn't have API_URL set, which is why the script was using localhost:3001. It needs to be added to both k8s/api.yaml and k8s/dev-api.yaml:

Also need to make sure API_URL is in turbo's passthrough so it reaches the API server:

API_URL is already in globalPassThroughEnv. All set.

Summary of changes:

• Removed the || "http://localhost:3001" fallback from all 3 files (capture-tokens.ts, capture/page.tsx, profile/page.tsx) — now throws if API_URL is not set
• Added API_URL to k8s/api.yaml (prod) and k8s/dev-api.yaml (dev) so the API pods have it

No — bun run deploy:prod only builds Docker images, pushes them, and restarts deployments. It doesn't kubectl apply the yaml manifests. The new API_URL env var in api.yaml / dev-api.yaml won't take effect until you apply them.

You'll need to run kubectl apply separately:

kubectl apply -f k8s/api.yaml
kubectl apply -f k8s/dev-api.yaml

Or use bun run k8s:deploy which applies all manifests. After that, the restart from the normal deploy will pick up the new env var.

Clean changes, no debugging. Committing:

Done. One commit: Require API_URL to be set; add it to K8s api deployments.

Remember to run kubectl apply -f k8s/api.yaml && kubectl apply -f k8s/dev-api.yaml before or after deploying to get the new env var into the running pods.