Rebuild your debugging context after an interruption

After an interruption, the most useful debugging question is “What did I verify last?” Remembering which files were open is helpful, but it does not tell you which hypothesis survived a test.

Rebuild a small evidence chain before making another change.

Find the exact failure

Start with the failing command, test case or reproducible user action. Record the expected result and the actual result. Use current logs and test output where available.

A remembered error message may be incomplete. If you can safely reproduce the failure, confirm the exact wording and environment rather than relying on memory.

Avoid rerunning a command blindly when it changes external data or has other consequences.

Recover the last hypothesis

Look at your working note, issue description and recent diff. Identify what you were trying to explain and which observation led you there.

CiteSilo can help recover a retained screen passage or find text in supported local files. Its source-code indexing skips common dependency and build directories, which helps keep the scope focused.

A retrieved code passage may have changed since you last saw it. Check the current file and version-control state before applying the old idea.

Distinguish an attempted fix from a verified fix

Seeing an editor open on a function does not prove the function was changed. Seeing a test command in a captured terminal does not prove it passed.

Use the actual diff, saved files, exit status and test output to establish what happened. A partial screenshot may omit the final result.

Write separate lines for “changed”, “tested” and “observed”. This prevents an unfinished experiment from becoming an assumed fact.

Run one informative next experiment

Choose the smallest test that can distinguish between your leading explanations. State what each possible result would mean.

For example, if a value appears stale, compare the point where it is created with the point where it is read. Do not refactor several unrelated layers before checking where the mismatch begins.

The useful next step reduces uncertainty, even if it does not immediately fix the bug.

Save a restart note before stopping again

Keep a short note containing the failing case, the current hypothesis, the last verified result and the next command or inspection. Link to relevant code and logs through your normal development workflow.

Treat captured activity as supporting context. It is not a version-control system, a test runner or proof of modified files.

If your work includes secrets or sensitive client data, review capture exclusions before reproducing the issue. Local storage does not remove the need to choose what gets recorded.

Read choosing local search folders and choosing what gets recorded for a narrower development setup.