BongSuCHOI Debugging
Diagnose before fixing unless the user explicitly requests implementation.
Choose the smallest investigation
- For a direct local symptom, reproduce once, inspect the nearest evidence and state the cause.
- For an unclear, intermittent or multi-layer failure, record the exact runtime/build identity and first build the cheapest runnable feedback loop that can detect the user's exact symptom. Then form distinguishable hypotheses and collect only evidence that separates them.
- When execution is blocked, use
references/methodology/partial-runtime-evidence.mdand state the confidence limit.
Feedback loop
A useful loop is red-capable: it exercises the relevant path and can fail on the reported symptom rather than merely proving that the process starts. Prefer the smallest fitting surface, such as a focused test, direct CLI or HTTP invocation, browser reproduction, captured-input replay, or minimal driver. Run it at least once before treating it as evidence, keep it bounded and deterministic enough to distinguish a change, and tighten it only when doing so materially reduces diagnostic uncertainty.
The loop is an evidence tool, not ceremony. Skip additional harness work when a direct reproduction already isolates the cause. When the runtime cannot be executed, do not invent a red loop or block all analysis; use the partial-runtime path and keep the conclusion within the available evidence.
Confirm a root cause by showing that it predicts the failure or that changing the suspected condition changes the result. If asked to fix, make the smallest change and run the closest regression check. Remove temporary instrumentation, restore modified runtime state and report remaining uncertainty. Use a journal only for repeated rounds or multiple temporary artifacts.
If the same exact symptom remains after the proposed fix, treat the previous cause or its claimed scope as incomplete. Reproduce that counterexample under the same runtime identity, revise the distinguishable hypotheses, and gather new separating evidence before changing another parameter or stacking another fix.
Runtime references
Load only the matching runtime card:
- Python:
references/runtimes/python.md - Node.js, Bun, Deno:
references/runtimes/node.md - Go:
references/runtimes/go.md - Rust:
references/runtimes/rust.md - Native binary:
references/runtimes/native-binary.md - Bundled JavaScript binary:
references/runtimes/bundled-js-binary.md
Use references/methodology/cleanup.md after a complex session with temporary processes, files or debugger settings.
Specialist tools
Route browser-only reproduction to $cx-browser-automation. Use LLDB/GDB for native processes and load references/tools/ghidra.md, pwndbg.md or pwntools.md only when that capability is warranted and authorized.
For one-off Python tools, prefer pinned uv run --with or uvx; for one-off Node CLIs, prefer pinned npx. Reuse the repository environment when the debugger must import the target project. Do not install tools globally. If a required runtime, debugger, OS package or browser binary is missing, explain the capability and propose the exact platform command. Preserve attach, symbol, permission, target-process and script failures as their real failure type.