version: "1.0.0" 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.

1. Reproduce with the authenticated browser session the user supplied.
2. Capture the final URL, visible state, console errors, failed requests,

timestamps, status codes, and request IDs without exposing secrets or customer records.

1. 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.

1. Trace the owning route and authentication boundary in source. Add a focused

regression test before changing behavior when practical.

1. 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 validate, deployment, or log-retention blocker without widening the patch.