debugging-lab-notebooklisted

# Debugging Lab Notebook ## Purpose Turn hard debugging into a recorded experiment loop instead of a sequence of guesses. ## Preserves Systematic debugging and error interpretation. ## Required Evidence - Symptom and reproduction attempt. - Logs, traces, metrics, failing command, or user report if available. - Code area or workflow likely involved. ## Failure Signs - A patch is proposed before a hypothesis. - Only one favored hypothesis is kept. - Negative findings are dropped. ## When To Use - A bug is hard, flaky, or poorly understood. - The failure crosses services, time, state, or concurrency boundaries. - AI starts proposing fixes without a hypothesis. - Negative findings need to be preserved. ## When Not To Use - Simple bugs that already have a failing test. - Purely visual defects with an obvious screenshot reproduction. - Incidents where immediate mitigation must happen before root-cause analysis. ## Inputs Expected - Symptom and reproduction attempt. - Logs, traces, metrics, failing command, or user report if available. - Code area or workflow likely involved. - Constraints on instrumentation or environment access. ## Output Expected ```md Reproduction: Hypotheses: Experiment: Result: Next hypothesis: Regression proof: ``` ## Process 1. Build the smallest available reproduction or observation signal. 2. Write competing hypotheses. 3. Add instrumentation that distinguishes between hypotheses. 4. Run one experiment at a time. 5. Record negative findin