ReproAssertView on GitHub
Open source · Python / pytest · alpha

The test
before the fix.

Turn a public GitHub issue and an exact commit into a minimal test candidate, then verify its failure inside a locked-down Docker boundary—before this workflow changes production code.

Run it locallyInspect the verified self-fixture

Self-fixture verified. Current maximum claim: repeatable_base_failure. V0.2 selection frozen; scored benchmark: 20 / 20 evaluated, 0 accepted. No semantic-validity claim.

public issue #1 · strict profile v1verified 2026-07-09

# Public self-fixture. Generate no fix.

$ reproassert issue \
  https://github.com/Atomics-hub/reproassert/issues/1 \
  --commit 7b03e8f7f4b7... \
  --generator-command ./examples/deterministic_generator.py
claimrepeatable_base_failure
collectionpassed
base reruns3 / 3 same fingerprint
patch  evidence/live-demo/candidate.patch
report evidence/live-demo/reproassert-report.json
replay 3 / 3 same fingerprint
Self-owned fixture · fresh replay matched · not benchmark evidence
InputIssue URL + exact SHA
OutputTest patch + JSON evidence
BoundaryDocker only, network off
Benchmark0 / 20 accepted

Evidence before confidence

A claim ladder with a hard stop.

ReproAssert records what happened; it does not promote a consistent failure into semantic truth. Higher claims stay visibly locked until they earn different evidence.

  1. 01
    rejected

    Rejected

    Policy, collection, setup, or evidence failed.

    implemented
  2. 02
    collected

    Collected

    The exact candidate test exists and pytest can collect it.

    implemented
  3. 03
    repeatable_base_failure

    Repeatable base failure

    Same issue-marked failure on every bounded base rerun.

    current max
  4. 04
    differential_reproduction

    Differential reproduction

    Requires repeated buggy and fixed revision evidence.

    not produced
  5. 05
    maintainer_validated

    Maintainer validated

    Requires independent human evidence outside the CLI.

    not produced

Hostile by default

The repository is data until the sandbox says otherwise.

Issue prose is never copied into a command. Repository code and candidate tests execute only inside the strict verifier. A trusted generator adapter stays outside that boundary and receives only an explicit environment allowlist.

Read the threat model
NetworkDisabled during verification
FilesystemRead-only root and workspace
IdentityNon-root UID/GID 65532
PrivilegesAll capabilities dropped
Resources1 CPU · 1 GiB · 128 PIDs
FallbackNo native host execution

Residual risk is explicit. Docker shares a kernel on Linux, test output can be adversarial, and a user-selected generator adapter is trusted host code. A repeated failure is bounded evidence—not proof of issue semantics or complete safety.

Public benchmark selection · v0.2

Twenty evaluated. Zero accepted.

0/ 20
01contract reject
02contract reject
03oracle reject
04contract reject
05contract reject
06contract reject
07oracle reject
08contract reject
09contract reject
10contract reject
11oracle reject
12contract reject
13contract reject
14contract reject
15contract reject
16contract reject
17contract reject
18contract reject
19contract reject
20contract reject

The first measured run missed its gate. Exactly 20 calls cost $0.688111. Seventeen candidates failed the contract; three reached Docker evaluation and failed stable attribution. There is no L1, L2, human-review, or maintainer-validity claim.

Inspect the result
Continue only if the evidence trends toward all gates
≥ 6 / 20semantically valid
< 10 minmedian runtime
≈ $1median cost per success or measured path
1 + 3one validation, three willing to reuse

Thin by design

One narrow, inspectable loop.

Provider-neutral generation feeds a deterministic controller. The controller owns every execution argument and every artifact path.

  1. 01

    Pin

    Canonical issue + exact SHA

  2. 02

    Bound

    Safe archive + limited context

  3. 03

    Screen

    One test + static policy

  4. 04

    Verify

    Collect + repeat in Docker

  5. 05

    Record

    Patch + replayable report

A
candidate.patch

One new pytest file. No production edits.

B
reproassert-report.json

SHA, image, limits, exit codes, logs, fingerprints, hashes.

C
reproassert replay <report>

Fresh fetch and controller-owned rerun from bounded data.

D
benchmark replay-v02-case <bundle>

Exact source plus hash-locked dependency rebuild; no model call.

Useful locally. Open source.

Start with the boundary, not a cloud account.

The alpha supports canonical public GitHub issues and Python/pytest. Ordinary issue runs do not install repository dependencies. Published v0.2 replay bundles may rebuild reviewed hash-locked wheels. Private repositories and native host execution are unsupported.

Python 3.10+uv or venvDocker
Read the install guide
local setupno hosted account
$ uv tool install git+https://github.com/Atomics-hub/reproassert.git

$ reproassert sandbox build
$ reproassert doctor
Docker CLIready
Sandbox imagerequired
Native fallbackdisabled

Business hypothesis · not an offer

Hosted operations may be valuable. The free core stays useful.

Illustrative path only
51teams×$199/ month=$10,149MRR

Zero willingness-to-pay, conversion, retention, or margin evidence has been measured. Private-repo runners and billing wait for technical and maintainer gates.

RA / 01

Don’t trust the fix.
Reproduce the failure.

Inspect the code, the frozen benchmark, and the exact security boundary. Then run the open-source slice locally.

Open ReproAssert on GitHub