When to keep debugging work in one thread

Debugging often gets worse when evidence is split too early. Keeping the work in one thread is useful when each next step depends on the exact error, prior test output, rejected hypothesis, or environment detail from the previous step.

## Keep it together when context is cumulative
A production bug with stack traces, browser screenshots, API responses, and local reproduction attempts benefits from one continuous trail. The value is in the sequence: what was observed, what was ruled out, and what changed after each patch.

## Split only when the boundary is real
Separate work is useful when a task has a clean owner and input: design review, copy edit, database migration, or browser QA. If the new task still needs all previous reasoning to avoid repeating mistakes, it is probably not ready to split.

## Record failed paths
The fastest way to waste time is to lose the reason a tempting fix was rejected. Write down failed assumptions, not just successful commands. A short 'tried X, failed because Y' line can save more time than a polished summary.

## End with a handoff-ready state
A good thread can be handed to another person without reconstructing the investigation. It should contain the current theory, exact files or URLs, verification status, and the next safe action.

When to keep debugging work in one thread

// COMMENTS

ON THIS PAGE