dev-debug-logs

Inspect browser, backend, proxy, and frontend dev server logs captured by fusebase dev start.

5|2|Updated Feb 9, 2026
One-click install
npx skills add https://github.com/ryan-haver/fusebase-mcp --skill dev-debug-logs-ryan-haver
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dev-debug-logs
Source: https://github.com/ryan-haver/fusebase-mcp/tree/main/apps/client-portal-dashboard/.claude/skills/dev-debug-logs
Command: npx skills add https://github.com/ryan-haver/fusebase-mcp --skill dev-debug-logs-ryan-haver

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When debugging a locally running FuseBase app, log output is scattered across browser consoles, backend processes, frontend dev servers, and proxied API traffic, making it hard to know where to look for each symptom. This Skill maps every symptom to the correct per-session log file so you can diagnose issues quickly. ## Core Features & Use Cases - Log file routing: Explains the four JSONL log files (browser, backend, access, frontend dev server) written to logs/dev-<timestamp>/ and which symptoms each one covers. - Request correlation: Uses requestId and the x-fusebase-dev-request-id header in access-logs.jsonl to trace a single /api call through the local proxy. - CORS vs NotFound runbook: Provides an ordered diagnostic flow for PostgreSQL/Gate-backed features, checking preflight, /me token context, and store discovery before changing code. - Use Case: A UI shows a failed /api fetch. Start in browser-logs.jsonl to confirm the symptom, correlate the request in access-logs.jsonl, then check backend-logs.jsonl for the matching stack trace. ## Quick Start Ask the assistant to debug why the local app started with fusebase dev start shows a failing API request by inspecting the latest dev session logs.

Frequently Asked Questions about dev-debug-logs

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a FuseBase app running with fusebase dev start?▼

Run the app with fusebase dev start, then open the latest logs/dev-<timestamp>/ directory inside the app folder. Pick the log file matching your symptom: browser-logs.jsonl for console errors, access-logs.jsonl for /api traffic, backend-logs.jsonl or frontend-dev-server-logs.jsonl for process output.

How do I trace a failing /api request in local development?▼

Find the request record in access-logs.jsonl and use its requestId to locate the matching response or proxy-error record. The same ID is forwarded as the x-fusebase-dev-request-id header, so you can correlate it with backend-logs.jsonl entries around the same timestamp.

Where are browser console logs stored during local development?▼

Browser console output, uncaught errors, and unhandled rejections are written to browser-logs.jsonl in the session log directory. It only works when the app is opened through the CLI proxy, which injects a debug script into proxied HTML pages.

Can I use these logs for a deployed FuseBase app?▼

No, these logs are local development artifacts only, created by fusebase dev start on your machine. For deployed app backends, use the remote-logs skill with the fusebase remote-logs command instead.

Why does Vite keep reloading when logs are written?▼

Log writes inside the app directory can trigger Vite's file watcher and cause HMR reloads. Add server.watch.ignored: ['**/logs/**'] to the app's vite.config.ts so log files are excluded from watching.

How do I tell a CORS failure from a missing store in Gate/PostgreSQL flows?▼

Check browser-logs.jsonl and access-logs.jsonl for preflight/OPTIONS failures first, then call the Gate /me endpoint with the current x-app-feature-token to verify identity and scopes. A valid /me with an empty store list indicates an org or source-scope configuration issue, not app code.