YankielDBC2 Debug Root Cause
Goal
Find the smallest proven cause of a bug before editing code.
When to use
Use when the user reports broken behavior, an error, regression, failing test, crash, incorrect output, or unexpected state.
When not to use
Do not use when the fix is already known and the task is only implementation.
Inputs
Collect the error message, reproduction steps, failing test, logs, relevant files, recent changes, and expected behavior.
Workflow
- Reproduce the failure or identify the exact failing path.
- Read the smallest relevant files first.
- Separate symptoms from possible causes.
- Form one or more hypotheses.
- Test each hypothesis using code, logs, tests, or runtime evidence.
- Patch the root cause, not the visible symptom.
- Add a regression test when the project has a test structure.
- Re-run the failing scenario.
Quality bar
A good debugging result explains why the bug happened, why the fix addresses the cause, and what validation proves it.
Validation
Run the failing test or reproduction first, then run the smallest broader validation suite that makes sense.
Final response
Report root cause, changed files, validation commands, and any remaining uncertainty.