Massive Bug Hunt And Fix

Discover, inspect, choose, and resolve ClawPatch findings without default source mutation

ClawPatch bug work uses a four-step manual lifecycle: discover, inspect, choose, resolve.

The default story is deliberately staged. $bug-discovery-phase can run AFK discovery, write durable ClawPatch state, generate reports, and support triage. It does not mutate source files by default, and its findings are static-review candidates, not proven runtime root causes. $bug-resolution-phase starts after the operator chooses a finding or a bounded finding batch.

Use this when: the team wants tool-backed bug discovery, triage, and selected finding resolution.
It gives you: a staged hybrid flow: discover, inspect, choose, resolve.
It ends with: finding reports, selected classifications, bounded fixes or triage, and ClawPatch revalidation.
Wrapped phase/skills: $bug-discovery-phase, $bug-resolution-phase, optional $debugging-phase, $docs-ingest-phase, ClawPatch.

Runtime Graph

ClawPatch findings are candidates, not patches. The graph keeps discovery, inspection, selection, and resolution separate so tool output does not silently become source mutation.

Reading The Stages

Discovery is read-oriented. It writes state and reports; it does not edit source by default.
The report returns to the operator because selection matters. Choose one finding, or a bounded batch with shared cause and validation.
Resolution uses ClawPatch for context, then patches through normal Harness/Codex discipline.
Static evidence is not always enough. Runtime-dependent findings route through $debugging-phase.
Closeout updates ClawPatch status and sends debt or operator-facing knowledge to docs ingest when needed.

Entrypoints

$bug-discovery-phase: AFK ClawPatch discovery, report generation, and triage. It records scope, provider/model default or explicit override, --limit, --jobs, state directory, report path, and relevant finding IDs.
$bug-resolution-phase: selected ClawPatch finding classification and bounded resolution. It patches through normal Harness/Codex edits by default, then verifies and updates ClawPatch status.
$debugging-phase: runtime-evidence loop for findings that need reproduction, logs, traces, browser evidence, or failing tests before a patch is trusted.
$docs-ingest-phase: durable docs or debt capture after a selected finding is classified as tech debt or after a resolution changes operator-facing knowledge.

Provider Defaults

ClawPatch inherits the current agent or launcher provider by default. A Codex run should launch the Codex-backed ClawPatch default, Claude should launch the Claude-backed default, and other launchers should use their configured default.

Goals, commands, and reports should record provider/model as an automatic default unless the operator explicitly chooses a ClawPatch provider/model override. Default command examples should omit --provider and --model; include those flags only for selected overrides.

Flow

Keep the stages separate:

Discover with $bug-discovery-phase.
Generate or locate the report under .clawpatch/reports/ unless the operator supplied another path.
Inspect findings with ClawPatch state, report links, show, next, triage, status, or revalidate.
Choose one finding by default, or a bounded batch only when findings share root cause, owned files, validation path, or contract/test gap.
Resolve through $bug-resolution-phase.
Classify each selected finding as resolve-now, needs-runtime-debugging, tech-debt, false-positive, or blocked.
Patch resolve-now findings through normal Harness/Codex edits, not ClawPatch patching, unless the operator explicitly asks for a ClawPatch patch attempt.
Revalidate the finding or update its ClawPatch triage/status.

Discovery Boundary

Discovery commands are read-oriented against source by default: init, map, review, ci, report, show, next, triage, status, doctor, and revalidate.

Discovery should not run clawpatch fix --finding, clawpatch open-pr, or broad automatic source mutation. It should not create repo tech-debt docs during broad discovery. The report is a candidate ledger that helps the operator choose follow-up work.

Resolution Boundary

Resolution starts from selected findings.

$bug-resolution-phase uses ClawPatch for finding context, report linkage, triage/history, optional dry-run inspection, and revalidation. Patch work uses the normal Harness editing, validation, review, and docs discipline.

The classification route decides the next step:

resolve-now: patch within the selected scope, test, review, and revalidate.
needs-runtime-debugging: route into $debugging-phase with the ClawPatch finding as context.
tech-debt: after selected-finding classification, route durable debt/docs context through $docs-ingest-phase.
false-positive: triage in ClawPatch with a clear reason.
blocked: record missing evidence and the next human action.

Parallel resolution is allowed only for a bounded batch with explicit ownership. Final verification and ClawPatch revalidation stay centralized.

Avoid The All-In-One Default

Do not present discover-and-resolve as the normal ClawPatch workflow.

If an operator explicitly asks for a single all-in-one goal, automatic resolution should select only high-confidence findings and keep the same gates: provider/model default or explicit override, bounded scope, no unchosen broad mutation, normal Harness edits by default, centralized validation, and ClawPatch status updates.

Terminal Outcome

Discovery ends with a report path, durable .clawpatch/ state, finding IDs, provider/model default or explicit override, scope details, and a statement that findings are candidates rather than proven runtime root causes.

Resolution ends with classification, changed files or no-op reason, validation evidence, ClawPatch revalidation or triage/status update, and docs/debt routing when needed.

On this page