Debug

Use runtime evidence before changing behavior. Treat code reading as context building, not proof.

Host adaptation

Before starting, normalize the current debugging environment without preflighting the target app:

• Determine whether the session already exposes a logging endpoint, log path, session ID, ready file, or other authoritative debug configuration.
• If no authoritative logging configuration exists, determine whether a local Python 3 interpreter is available for the bundled collector. Prefer python3; otherwise allow python only when it resolves to Python 3. If no Python 3 interpreter is available, stop and tell the user you need either an existing logging session or a local Python 3 runtime before continuing in evidence-first mode.
• Determine how the host keeps long-lived processes alive: persistent PTY, detached shell, task runner, or no background support.
• Determine whether the host can open or automate browser pages. If not, rely on the collector's ready file and HTTP APIs instead of UI inspection. When browser access exists, reserve page opening for the collector dashboard by default; do not open target-app pages unless the user explicitly asked you to open the project.
• Determine whether each planned log point runs in browser/client code, server/runtime code, or both. For browser/client code, prefer direct requests to the active collector endpoint instead of adding project-local proxy routes.
• Determine how the user signals that reproduction is complete: explicit UI button, task-state action, or a short chat reply.
• Do not treat target-app startup, health checks, route probes, or compile/build checks as default preflight. Only inspect them when the user explicitly asked to debug startup behavior or when a current hypothesis is about app boot, compilation, or endpoint availability.
• Store temporary artifacts in an existing host-specific scratch directory when one already exists. Otherwise default to a workspace-local hidden directory such as .debug-logs/.

Workflow