Diagnose and repair complex failures
Reproduce the failure in a disposable environment before touching the code, repair it, and keep the reproduction and the regression test as evidence that it is actually fixed.
What does this reliability workflow workflow cover?
Reproduce the failure in a disposable environment before touching the code, repair it, and keep the reproduction and the regression test as evidence that it is actually fixed.
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.
The problem
A test fails once a day in CI and passes locally. The stack trace points at a queue worker, the logs are in one tool, and the only person who understands that service is on holiday. Nobody wants to hand this to an agent, because an unreproduced fix is a guess with a diff attached.
The current workflow
The BranchRunner workflow
- 01Gather the context
The task carries the failing job, the trace and the log excerpt. Repository inspection happens in the workspace, not from memory.
- 02Reproduce first
The first requirement is a reliable reproduction. Until a check fails on demand, no repair is attempted.
- 03Repair, with the cause named
The session records the cause as a decision with evidence, then changes the code. A symptom patch is visible as one.
- 04Prove it twice
The reproduction must now pass, and the new regression test must fail against the old code. Both results are attached.
- 05Keep the environment
The workspace and logs are retained for the run, so the next person can reproduce the original failure themselves.
In the product
Run 31 on TASK-474: an intermittent checkout test. The reproduction came first, the cause is named, and the regression test is the evidence.
Run context
Decision recorded: the worker reused a database connection across retries, so a rolled-back transaction leaked into the next attempt. Evidence: reproduction log lines 412–418.
Interface built from the product model. Repository, task and log content are examples.
Where a person stays in control
The workflow blocks the repair step until a check fails on demand, so guesses cannot be shipped.
The stated cause and its evidence are read by a reviewer before the diff is accepted.
Reproduction runs against seeded data in the workspace. Access to real systems requires an approval.
Failed and repaired runs keep their workspace and logs, so the diagnosis can be checked later.
What to expect
Deployment considerations
Give the flaky test a reproduction
Disposable environments make reproduction cheap, and evidence makes the fix believable.