Customer approval and PR creation

Before approving a pull request

Use this page after Review-only patches has produced a safe draft and the customer is ready to approve repository write access for that exact change. Pull request creation is a connected write action, so approval_status must belong to the same patch, repository, branch and fix task. Do not use this page to bypass review. PR creation must stay disabled until approval_status is ready for the approved draft and no-secret checks are clear.

Approve and create the pull request

Follow the path `Review-only patch → Customer approval → Target branch → Pull request creation → Status sync or fallback`.

1. Open /fix-tasks/{fixTask}/pull-request from the approved review-only patch. Result: approval_status, patch_review_status and target repository context are visible before PR creation.
2. Review patch_diff_summary, target branch and branch_name before creating the PR. Result: the customer can confirm the branch, changed files and purpose match the approved patch.
3. Confirm customer approval in the product flow. Result: approval_status is ready and the Create pull request action becomes available only for that approved draft.
4. Create the pull request from the enabled action. Result: WebRiskOps creates the provider branch and pull request without adding extra unapproved changes.
5. Record pull_request_status and pull_request_url after the provider returns. Result: the customer can open the PR, review provider checks and track status sync.
6. Use fallback or revoke paths if approval, provider access, branch creation or no-secret checks fail. Result: unsafe or unapproved changes do not enter the repository.

Ready approval states

Continue only when the product shows an approved and safe state.

• Approval ready means approval_status is ready for the exact review-only patch and target repository.
• Branch prepared means branch_name is generated for this fix task and does not collide with existing customer work.
• PR creation enabled means the customer-approved action is available after no-secret and scope checks pass.
• Created PR means pull_request_status is created and pull_request_url points to the provider pull request.
• Status sync active means provider checks, merge state or follow-up errors can be tracked from the WebRiskOps fix task.

Blocked or unsafe PR states

Do not work around an unsafe PR state. Use fallback or revoke paths before any repository write is attempted.

• Approval missing means keep the patch in review and do not create a branch, commit or pull request.
• Provider error means retry only after repository access and provider status recover.
• Revoked access means reconnect through the product flow or use Ticket-only fallback.
• Branch conflict means choose a new generated branch_name or stop before writing to the repository.
• Secret boundary risk means discard the draft and use Revoke and no-secret boundaries before continuing.
• Scope changed means return to Review-only patches so the customer approves the current diff, not an older draft.

Continue to revoke and no-secret boundaries

Continue to Revoke and no-secret boundaries when access must be removed, a token or provider state changes, or any source-secret concern appears after PR creation. Use Ticket-only fallback when approval, branch creation, provider access, no-secret checks or status sync cannot complete safely. Use Connected access requirements and Automation boundaries when the customer needs to understand why the PR action is unavailable.