dsh-bisect-debug

"The bug is in the current code, but where exactly?" — Guessing and shotgun debugging rarely converge. You patch three places, things break in new ways, and you are no closer to the root cause. dsh-bisect-debug turns binary-search bisection into a concrete agent workflow: every round halves the search space, you verify, then halve again—until the culprit is pin-pointed to a specific function, data-flow boundary, or commit.

The plugin ships three complementary bisection modes. Code bisection comments out or disables half the modules to narrow the scope—ideal when you know the bug lives in the current source but cannot see which function is responsible. Boundary bisection walks the data flow hop by hop using curl, logs, or database queries, designed for "is it the frontend or the backend, the gateway or the downstream?" scenarios—a typical run needs three curl calls and zero code changes. Commit bisection encodes the good/bad check as an exit-code script and hands it to git bisect run for fully automated convergence through submission history. The three modes compose naturally: locate the layer first with boundary bisection, then locate the function within that layer using code bisection.

Built-in discipline rules keep the process honest: if two consecutive edits have not resolved the issue, stop and return to bisection; never modify multiple places in one round; confirm symptoms with curl, logs, or pings before reading source; and follow a fallback strategy when the bug is intermittent or one-off. If you frequently hit "changed it a dozen times and still cannot find the root cause"—especially in front-end/back-end split stacks, microservice chains, or long git histories—this workflow turns bug-hunting from a shot in the dark into deterministic convergence.