---
name: tuturuuu-browser-vercel-debugging
description: "Reproduce deployed Tuturuuu bugs and correlate browser evidence with Vercel logs."
---

# Tuturuuu Browser And Vercel Debugging

## Core Workflow

Use browser evidence and Vercel evidence as two views of the same request:

1. Identify the owning app, domain, workspace, route, deployment, and expected
   behavior.
2. Reproduce with the authenticated browser session the user supplied.
3. Capture the final URL, visible state, console errors, failed requests,
   timestamps, status codes, and request IDs without exposing secrets or
   customer records.
4. Use the Vercel CLI to resolve the alias to a deployment and query a bounded
   runtime-log window for the same host, route, time, status, or request ID.
5. Trace the owning route and authentication boundary in source. Add a focused
   regression test before changing behavior when practical.
6. Patch the smallest owning surface, run focused validation, and only claim
   production verification after the fix is deployed.

Read `references/production-debugging-playbook.md` for browser selection,
Vercel CLI commands, common Tuturuuu failure signatures, performance/cost
investigation, and product-improvement checks.

## Production Safety

- Keep production browser and Vercel work read-only by default.
- Do not create, edit, delete, submit, approve, invoice, attend, move, or bulk
  update production data unless the user explicitly authorizes that mutation.
- When mutation is required, prefer a test-owned or personal workspace and
  clearly identify cleanup responsibility. Never reuse customer records as
  test fixtures.
- Never print cookies, authorization headers, session tokens, environment
  values, raw customer payloads, or private logs. Report environment variable
  names and sanitized metadata only.
- Do not use `vercel deploy`, project removal, alias changes, environment
  mutation, rollback, or promotion commands unless the user explicitly asks.
- Bound log queries with `--since`, `--until`, `--limit`, route/status filters,
  or a request ID. Use `--follow` only for an explicit monitoring task.

## Browser Selection

- Prefer the in-app Browser plugin when the user says they logged in there or
  its authenticated state is already available.
- Use the Chrome plugin when Chrome was explicitly requested, the in-app
  session is stale, or the required authenticated state exists only in Chrome.
- Reuse or create a named task tab, leave user-owned tabs alone, and finalize
  only tabs opened for the task.
- Prefer semantic DOM snapshots and targeted console/network inspection over
  repeated screenshots. Use screenshots when visual layout, responsiveness,
  clipping, contrast, or loading state is part of the bug.

## Evidence Standard

Distinguish these states in updates and final reports:

- **Reproduced:** the current deployed behavior was observed.
- **Diagnosed:** browser and server evidence identify the failing boundary.
- **Fixed locally:** source and focused tests support the patch.
- **Deployed:** Vercel resolves the production alias to a deployment containing
  the fix.
- **Verified in production:** the deployed flow was rechecked safely.

Do not collapse “tests pass” into “verified in production.” If safe production
verification would require a mutation that was not authorized, say so.

## Product Improvement Loop

For a requested product audit, select the relevant checks below. A focused bug
fix does not require this broader audit:

- exercise English and Vietnamese, desktop and narrow/mobile layouts, keyboard
  navigation, empty/loading/error states, and restricted-role behavior
- identify raw translation keys, noisy retries, duplicate fetches, hydration or
  hook-order errors, rewrite hops, and unnecessary server invocations
- correlate high-frequency routes and slow/error-prone requests with the
  owning client polling, cache, or server-rendering behavior
- measure before changing caching; never cache user-specific, permissioned, or
  Supabase-authenticated data as if it were public
- add a focused regression test when it can meaningfully reproduce the failure

## Verification

Run the smallest source checks that prove the fix, then the repo-required
validation for touched files. Keep browser verification read-only unless the
user authorized a test mutation. Record any unrelated `bun check`, deployment,
or log-retention blocker without widening the patch.