debugging

Treat it as a bug with a low reproduction rate: loop the failing test hundreds of times, run copies in parallel, and add CPU or IO load to surface timing issues. Replace arbitrary sleeps with condition-based waiting on the actual completion signal, then re-run the loop to confirm the fix.

Trace the bad value backwards from where it surfaced to where it was created, reading each caller's arguments rather than inferring them. Fix at the producer, not the consumer, and write a failing regression test at a correct seam before applying the fix.

Raise the reproduction rate first: loop the trigger, run in parallel, add load, widen timing windows, and remove masking caches or retries. If all fail, ask for a redacted captured artifact, environment access, or permission to add temporary tagged instrumentation.

Yes, the workflow is language- and stack-agnostic and always uses the project's own commands discovered from the Makefile, package.json, pyproject.toml, or CI configuration. It assumes git history is available for bisection and prefers a language-appropriate debugger over logging.

Stop in exactly three cases: you cannot build any reproduction loop, three fixes have failed indicating an architectural problem, or the user is redirecting your approach. Present open questions in one numbered round, each with a recommended answer.

The frame where a bad value surfaces is rarely the frame that produced it, so coercing or defaulting at the crash site leaves the same bad value flowing to every other reader. Fixing at the producer plus layered guards makes the bug structurally impossible.