A Unified Debugging Approach via LLM-Based Multi-Agent Synergy: Verify the Repair

A unified debugging approach via LLM based multi agent synergy is useful only when its agents leave evidence that survives their own conversation. A localizer can sound certain, a repairer can emit a patch, and a reviewer can approve it while the original failure was never reproduced or the decisive boundary case was never tested. The reasonable default is therefore: let specialist agents propose and challenge a repair, but promote the patch only after a linked receipt proves reproduction, lineage, test coverage, oracle quality, and review. That operating rule follows the architecture of the FixAgent paper without confusing research results with a production guarantee. The paper separates fault localization, patch generation, and post error analysis across specialist agents. It also distinguishes a plausible patch that passes the available tests from a correct patch established through manual verification. That distinction is the health boundary. What the FixAgent result proves—and what it does not FixAgent’s published design is more specific than “ask several models to debug.” Its methodology uses a localizer, repairer, and revisitor, plus an input crafting agent for additional tests. The agents explain their reasoning, track important variables, and pass prior stage results downstream. If the generated patch fails, the repair stage can be sampled again with test feedback. The paper reports strong results on QuixBugs, Codeflaws, and ConDefects. Those are research results under the paper’s datasets, models, prompts, and verification procedure. They do not establish that an arbitrary repository patch is safe to merge. Two details from the primary source change the operational decision: 1. The paper defines a plausible patch as one that passes the human written tests, while correctness requires separate manual verification. 2. Its limitations section says the extra test input agent cannot calculate expected outputs by itself. A generated input without a trustworthy oracle is not a complete test. The released Rudra implementation makes the boundary inspectable. Its multi round runner treats zero observed failing cases as a successful repair and returns that flag to the launcher. That is appropriate for an experiment’s test loop. An operator still needs to ask which suites ran, whether their oracle is trustworthy, whether the result belongs to this patch, and whether a reviewer accepted the actual diff. The lesson is not that agent review is useless. Specialist disagreement can expose bad localization or a weak patch. The lesson is that one agent’s text must not be the only evidence consumed by the next. Link every debugging stage with a repair receipt A minimal repair receipt can be content free. It does not need prompts, source code, test output, or model reasoning. It needs stable identities and verdicts that let a human or deterministic gate reconstruct the boundary: Boundary Minimum receipt fields Failure it catches Reproduction run ID, command hash, original failure observed A patch for a bug that was never reproduced Localization run ID, source revision, evidence timestamp A localizer result reused from another revision Patch patch hash, parent revision, changed line count An empty, stale, or unrelated repair Validation required suite IDs, observed suite IDs, failed count “All tests pass” when a required suite never ran Oracle verified, unknown, or disputed Generated cases with no trustworthy expected result Review approved, rejected, or owned wait Model agreement mistaken for merge authority Outcome completion claim and destination receipt A completed run whose patch was not verified or delivered The run ID is especially important. A localization answer from run old must not silently justify a patch from run 42 . The patch hash is equally important: a green test record for one diff cannot be attached to a later resample. This is ordinary lineage, but agent workflows often lose it because conversational context makes nearby messages look related. Here is the shape used by the accompanying fixture: The strings are identifiers, not stored content. In a real system, the hashes should be computed over canonical inputs and artifacts, and the test record should include tool version, configuration revision, start time, finish time, and exit provenance. Secrets, prompts, file contents, and raw tool arguments should stay outside the health receipt. Replay nine inconvenient states before trusting green The article artifact contains nine synthetic cases and a precedence ordered Node.js classifier. Run it from the article report directory: The observed result is: The cases are deliberately inconvenient: UNREPRODUCED stops the workflow before a confident patch can hide a missing baseline. LOCALIZATION DRIFT catches a localizer receipt from a different run. NO EFFECTIVE PATCH refuses a missing hash or a zero line change. TEST GAP reports a required integration suite that never ran, even when observed suites are green. ORACLE UNCERTAIN preserves uncertainty when generated inputs have no verified expected outputs. REVIEW REJECTED keeps a technically green patch from becoming an approved one. WAITING represents a legitimate dependency only when the receipt names an owner and deadline. FALSE COMPLETE outranks a completion claim when any observed test still fails. VERIFIED REPAIR requires all prior boundaries to agree. The ordering matters. A completion claim cannot override a failing test. A zero failure counter cannot override a missing suite. A generated boundary case cannot establish correctness without an oracle. A review wait should not be classified as a stall when it has an owner and deadline. This experiment also shows why a single health score is a poor debugging artifact. Both the suite gap and verified repair cases report zero failed tests, yet their operational states differ because one never ran the required integration suite. The missing evidence is more important than the green counter. Add the gate to a real coding agent workflow Start with a small promotion boundary rather than rebuilding the agent framework: 1. Freeze the input revision. Record the repository commit or workspace snapshot before localization. 2. Reproduce the failure. Store a command/config hash and a structured result. If reproduction is flaky, label it uncertain and do not treat an eventual green run as proof of repair. 3. Link each handoff. Require the localizer, repairer, and reviewer receipts to reference the same run and parent revision. 4. Bound resampling. The FixAgent paper’s feedback loop is useful, but retries consume budget and can change the patch. Give every new patch its own hash, cap attempts, and invalidate prior test evidence when the diff changes. 5. Declare required suites before execution. Otherwise an agent can redefine “all tests” after seeing the results. 6. Separate test execution from oracle authority. Generated inputs can improve coverage, but a person, specification, reference implementation, or independent deterministic rule must supply the expected result. 7. Keep merge or deployment authority human controlled. An approved receipt can prepare the decision; it should not broaden the agent’s permission. 8. Verify the destination. If the task was to open a pull request, update an issue, or produce a release artifact, verify that destination independently. A local patch is activity, not necessarily the requested outcome. For an approval pause, use an explicit record: Do not page simply because the agent is quiet while that record is current. Escalate when the deadline expires, the owner is missing, or the resumed run produces no new evidence. Waiting is not stuck; repeated activity without an outcome delta is not progress. The boundary for Sidewisp The supportable thesis is narrow: multi agent debugging becomes operationally trustworthy when specialist outputs are joined to deterministic repair evidence, and green is withheld when lineage, coverage, oracle quality, review, or outcome evidence is missing. The nine case fixture falsifies the shortcut “zero observed failures means verified repair” because two zero failure cases reach different verdicts. This is an operating pattern, not a claim that Sidewisp currently runs FixAgent or monitors coding agent repairs. Sidewisp is currently in private preview. It is an AI agent health platform, but the production monitoring engine, runtime adapters, and recovery executor are not generally shipped. The intended health layer is relevant here because it distinguishes useful progress, legitimate waiting, false completion, and uncertain evidence while leaving merge authority with the human. Use the receipt first on one repeated debugging workflow. If it cannot tell a missing suite from a verified repair without reading the transcript, the evidence contract is still too weak.