fix

/zeropath:fix

Thin entrypoint. Fixing one finding properly spans three concerns: understanding it, editing the code, and verifying the fix landed. Each concern has a dedicated subagent.

What you do

Don't probe config, creds, or CLI in chat - auto-bootstrap handles all of that. Just orchestrate:

1. Resolve the finding. Accept an explicit id or a free-form intent. Call issues.list with searchQuery (scoped to the bound repo from ~/.zeropath-agent-plugin/repo-binding.json if present) to confirm exactly one match before proceeding. If the user names a different repo explicitly, drop the binding filter.

2. Spawn zeropath-explainer for the finding. Its "What this is / Why it matters" output briefs the user on what you're about to change.

3. Locate the code locally. Read the file at the finding's reported path. If the path doesn't exist in the working tree (e.g. the finding is from a different branch), stop - do not invent.

4. Propose the fix as a unified diff. Cite the rule ID. Ask in plain chat (not a button picker). Apply only on explicit affirmative. For cross-file refactors, enumerate every file before the first edit.

5. Spawn zeropath-scanner on the edited files to verify. If the original finding's partialFingerprints no longer appear in the new SARIF, the fix landed. Report it. If it persists, surface what's still flagged - don't iterate blindly past scan.maxIterations.

6. Optional close. After a verified fix, ask in plain chat whether to:

   • Open a PR with the diff. On consent, call agent.createPatch
     • agent.triggerPrFromPatch with the bound repositoryId. Surface the PR URL.
   • Mark the finding via /zeropath:triage. Never open a PR or mutate state without explicit consent.

Don't

• Don't disable a rule (in the codebase or in ZeroPath) as a "fix." Suppression is /zeropath:triage territory.
• Don't trust the AI-suggested patch on the finding object as gospel
  • it can be wrong about imports, helpers, or framework idioms. Verify with the scanner.