Playbook-First Landing — Click-Through Attempt BLOCKED

2026-09-01 · Account: peytontianyan@gmail.com · 0 of 23 scenarios walked

What happened: The QA account's Brain was wiped cleanly and is ready (verified 0 rows across 11 tables, wallet $15.17). But every attempt to log Chrome into that account failed before the first click — the QA login-link script hands Chrome an already-redeemed magic-link token. Root cause confirmed by reading scripts/prove/lib.ts's mintMagicLink(): it calls Supabase's /auth/v1/verify itself (to also mint an API token) before returning the link for Chrome to click — burning the one-time code first. 3/3 fresh tokens failed identically.

Screenshot 1 — first attempt landed on the WRONG account

Loading screen — Initial navigation to /brain, still resolving the (as it turned out, stale) session.

Screenshot 2 — resolved into a stale, unrelated session

Logged in as the wrong account, Peyton WP, $206.02 balance — Landed on /brain logged in as "Peyton WP" ($206.02) — a leftover session from unrelated prior work in this Chrome profile, not caused by the magic link itself. Caught before any click; signed out immediately via the sidebar.

Console evidence of the real root cause

gtm.oldUrlFragment: "error=access_denied&error_code=otp_expired&error_description=Email+link+is+invalid+or+has+expired&sb="

Scenario scorecard

Scenario	Result
CT-PBF-00 through CT-PBF-22 (all 23)	BLOCKED — QA login tooling bug (scripts/prove/lib.ts mintMagicLink)

What's needed to unblock

A code fix to scripts/prove/lib.ts's mintMagicLink() so the action_link handed to a browser is never redeemed server-side first — e.g. return the raw action_link without the internal verify() call, or mint two independent one-time codes for the two different callers (browser navigation vs. API accessToken) that currently share one. Once fixed, the walk can resume immediately — the account is already wiped and ready, no re-reset needed.