Review and repair a proposed change
Run an independent review against requirements, route findings into bounded repairs, and rerun the evidence that matters.
What does this review workflow workflow cover?
Run an independent review against requirements, route findings into bounded repairs, and rerun the evidence that matters.
What should an evaluator inspect?
Inspect the stated requirements, workspace boundary, validation evidence, approval points, and stated deployment scope rather than inferring results from an example workflow.
Is this customer proof?
No. Workflow pages describe an evaluation model and may use fictional product artifacts. They do not assert customer adoption, outcome, or availability evidence.
Can we run this workflow today?
A released self-managed artifact and tested quickstart are not published. Review the self-hosted requirements or register interest in future Cloud or Enterprise offerings.
What is the next step?
Use the ungated sample run and pilot scorecard to frame the evaluation, then choose a request path only if the operating model fits.
Starting condition and desired outcome
A pull request exists, but review findings, repair attempts, and rerun checks are split across tools. The outcome is an attributable finding set and a repaired diff whose checks were rerun after the change.
The current manual workflow
The BranchRunner workflow
- 01Import the change
Attach the pull request, requirements, and repository checks to a review task.
- 02Review independently
A reviewer without authoring context records concrete findings against the diff.
- 03Approve repair scope
A person accepts, rejects, or narrows findings before repair begins.
- 04Repair and rerun
A separate workspace applies approved repairs and reruns affected validation.
Evidence produced
The run keeps claims separate from checks and decisions. The evidence below describes the record, not a guaranteed outcome.
Product example. Repository, checks, and identities are illustrative; configure them for your system.
Where a person stays in control
A person decides which findings enter the repair scope.
Review stays read-only; repair receives only required edit and command access.
Required reruns are explicit rather than inferred.
Normal repository review and merge policy still applies.
What the workflow can produce
Integrations, deployment, and edition fit
Validate the workflow against one real repository
Bring the starting condition, required checks, and approval boundaries. We will identify what can be configured today and what remains deployment work.