Review-only patches

Before drafting a patch

Use this page after Code mapping has found an explainable candidate file and before any customer-approved pull request can exist. A review-only patch is a proposed diff for customer review; it is not a branch, commit, pull request or implementation claim. Keep the draft inside the product review flow. The customer should see patch_review_status, patch_diff_summary and approval_status before any connected repository write action is available.

Generate a review-only patch

Follow the path `Code mapping → Review-only patch draft → Customer review → Approval state → PR creation or fallback`.

1. Open /reports/{report} and choose a mapped finding that is eligible for a patch draft. Result: patch_review_status and approval_status are visible before any draft is generated.
2. Generate the review-only patch from the mapped finding. Result: patch_diff_summary explains proposed files and changes without creating a branch, commit, pull request or implementation claim.
3. Review changed files, rationale, issue evidence and no-secret checks. Result: the customer can inspect why the patch exists and what it would change.
4. Keep the patch pending until customer approval is recorded. Result: no PR creation or connected write action happens from a draft alone.
5. Discard or route to fallback when the draft is unsafe. Result: secrets, wrong repository, broad scope, low confidence or unsupported changes do not continue.
6. Continue to Customer approval and PR creation only after approval_status is ready. Result: the next step has an explicit customer-approved patch boundary.

Ready patch states

Continue only when the product shows a ready or reviewable state.

• Patch draft ready means patch_review_status is ready and patch_diff_summary explains the proposed file changes.
• Review pending means the customer can inspect the diff, rationale, evidence and remaining_risk_notes without repository writes.
• Approval required means approval_status still blocks pull request creation and connected write actions.
• Ticket fallback ready means the draft can be converted to ticket-only remediation when repository changes are not safe.
• PR eligible means approval_status is ready and the next page can handle customer-approved pull request creation.

Blocked or unsafe patch states

Do not work around an unsafe patch state. Use fallback or revoke paths before source context spreads to tickets, prompts, branches or pull requests.

• Secrets in diff means discard the draft, stop patch generation and use Revoke and no-secret boundaries before continuing.
• Missing approval means no pull request, branch, commit or connected write action may be created.
• Low-confidence mapping means return to Code mapping or use Ticket-only fallback.
• Wrong repository means return to repository connection and correct repository_full_name before drafting again.
• Broad scope request means split the work into a narrower mapped finding before review.
• Unsafe patch means route the finding to fallback instead of asking the customer to approve a risky diff.

Continue to approval

Continue to Customer approval and PR creation only when approval_status shows the customer has approved the review-only draft and the no-secret checks are clear. Use Ticket-only fallback when the patch is unsafe, unsupported, low-confidence, missing approval or blocked by repository access. Use Automation boundaries and Safe fallback paths when the automated repository flow cannot proceed without broader access.