Skip to content

Latest commit

 

History

History
58 lines (43 loc) · 1.8 KB

File metadata and controls

58 lines (43 loc) · 1.8 KB
title Patching
description Explicit fix workflow for individual findings

Patching

clawpatch fix is explicit and finding-scoped.

clawpatch fix --finding <findingId>

Current behavior:

  • reads the selected finding
  • checks the worktree is clean outside .clawpatch/ when configured
  • creates a patch attempt record
  • asks the provider for a fix plan
  • lets the provider edit the worktree during the explicit fix command
  • runs the configured formatter, feature-specific tests, typecheck, lint, and configured test command, with duplicates removed (see Validation)
  • records source edits even when the provider fails before validation
  • records command results
  • links the patch attempt to the finding

When --root selects a subdirectory of a Git repository, dirty checks and patch file records are scoped to that project. Its state directory and sibling-project changes are excluded; renames record both the old and new project-relative paths.

Status updates:

  • validation success marks the finding uncertain
  • validation failure keeps the finding open

The CLI does not currently mark a finding fixed from the patch pass alone. Use clawpatch revalidate --finding <id> for a second pass.

Opening a PR

After reviewing the applied worktree changes, create a GitHub PR explicitly:

clawpatch open-pr --patch <patchAttemptId> --draft

open-pr requires an applied or validated patch attempt with recorded changed files. It refuses failed validation unless --force is passed, commits only the recorded patch files, pushes the branch, and calls the GitHub CLI. Use --dry-run to preview the branch, title, body, and commands without touching git.

Not implemented yet:

  • fixing by severity or category
  • batching multiple findings
  • auto-commit
  • rollback snapshots