Verdict

Reproduction agent for flaky bugs

Find the exact condition that makes it fail.

Some bugs only show up sometimes, so nobody can prove they are fixed. Verdict runs your test command again and again under conditions you approve, a tighter timeout, a slower upstream, no response at all, until it finds the combination that breaks it.

You get back the exact command, how often it failed, the commit range it points at and a regression plan to stop it returning. Nothing is written to your repository without your approval.

Demo condition matrix (12)Generated fixture
Selected condition 04Pinned750 ms budget / no response10 of 10 generated records
Selected condition750 ms budget / no response
Generated result10 of 10 matched
Proposed command / not runVERDICT_SCENARIO=SNAPSHOT_REGISTRATION VERDICT_REQUEST_BUDGET_MS=750 VERDICT_UPSTREAM_BEHAVIOR=NO_RESPONSE pnpm --filter @truefoundry/trueforge-core test -- tests/core/sandbox/daytonaSnapshotRegistration.test.ts --runInBand
You give itAn issue and a test command
It variesTimeouts, delays, upstream behaviour
It recordsEvery run, pass or fail
You getThe condition that reproduces it

A grid of conditions. The one that reproduces.

Each cell is one setting of the knobs you approved, run several times. The count in the corner is how many of those runs reproduced the bug. Select a cell and you see the command that produced it, the exit code and the commit it ran against. The bundled case is a fixture, and its numbers are generated rather than executed.

8
conditions per run, at most
3
repetitions per condition, at most
4
read-only GitHub tools the agent may call
1
approval gate before any public write

Every claim shows its receipt.

A result you cannot check is a rumour. Verdict keeps the command, the environment and every run record attached to the claim they produced, and it marks what it could not establish rather than quietly leaving it out.

Inspect the full evidence trail
Recorded reproductionTrueForge issue #417
Executed, integrity checked
Verdict
REPRODUCED
Failing condition
daytona-stalled-endpoint, 10 of 10 runs
Control condition
daytona-responsive-endpoint, 0 of 10 runs
Under test
@truefoundry/trueforge-core@0.1.4
sha256 a8bb5dd2Public write disabled

Find it, then narrow it, then keep it fixed.

Three stages, each one allowed to claim less than the evidence it collected.

Make it fail on demand

Hunter

Runs your command across every condition you approved and counts how many attempts reproduced the bug. Conditions that half worked stay on the board as partial.

A condition that reproduces, or an honest miss
Find what caused it

Surgeon

Takes the condition that reproduced and narrows it to the commits that could have caused it, replaying the same command across history where the code still builds.

A commit range, with its limits stated
Stop it coming back

Insurance

Turns the confirmed evidence into a regression-proof plan: the test name, the fixture and the assertion that should fail. It does not write the test, and a draft pull request is only ever opened by a workflow you approved.

A regression plan, held for your approval

What you get, even when it does not reproduce.

A run that finds nothing still costs what you agreed and still tells you what it tried.

A bounded search space

You define the knobs and the budget. The agent cannot widen its own experiment, so a run that finds nothing costs what you agreed to spend.

Records, not summaries

Every accepted observation carries its command, environment, exit code and commit. The conclusion is derived from those records rather than asserted alongside them.

Honest partial results

Partial and unresolved conditions stay on the board. A search that half worked reports as a search that half worked.

Deterministic reducers

The same records always produce the same verdict. The reducers live in a shared package and are covered by the test suite.

An approval boundary

The trusted host validates the exact repository, workflow and ref before a dispatch is offered. The default is to stay read-only.

Portable evidence

Each case exports a readable report and a machine-readable bundle, so the trail survives outside the interface.

It cannot touch your repo without you.

Until you approve a dispatch, Verdict holds four read-only GitHub tools and nothing else. When it does propose a write, you see the exact repository, workflow and files first. The default is to stay read-only.

Approval boundaryExact workflow dispatch
Repository
truefoundry/trueforge
Workflow
Trusted host policy target
Proposed files
Regression test, VERDICT.md, verdict.json
Default
Stay read-only
Publication disabled in demo

Straight answers.

Is this an autofix bot?

No. Verdict stops at a reviewable claim. It proposes a regression test and a publication manifest, and a maintainer decides whether anything is written.

What if the bug will not reproduce?

That is a result, and it is reported as one. The matrix keeps not-reproduced, partial and unresolved conditions visible instead of collapsing them into a single confident answer.

Is the interactive demo real data?

No, and it says so on every screen. The case workspace you can click through is a fixture with generated numbers. The reproduction above it is not: it was executed against @truefoundry/trueforge-core@0.1.4, and the repository carries the record and a verifier that recomputes its hash. Keeping those two apart is the same discipline the product applies to its own findings.

What does it need from my repository?

A GitHub issue, a maintainer-approved command, the condition knobs worth trying and a run budget. Repository access stays on four read tools until you approve a dispatch.

One flaky issue is enough.

Bring the bug nobody can reproduce.

See the recorded reproduction