Repro

Repro is an evidence-first triage tool for a deliberately narrow class of Python/pytest bug reports. It captures a reviewable regression test and verifies a behavioral difference: the test must fail on a declared broken revision and pass on a declared fixed revision.

Status

Proof-of-concept. The repository has a runnable Python scaffold, typed manifest/proof models, a CLI bootstrap, test coverage, CI configuration, one verified real-world showcase fixture, and two clearly labelled simulated demo fixtures. The public build has an opt-in GPT-5.6 hypothesis call; deterministic evidence generation remains the source of every verification decision.

How Codex Was Used

Codex accelerated Repro's requirements refinement, architecture, implementation, test coverage, debugging, UI iteration, and release validation. GPT-5.6 is used in the product's opt-in hypothesis stage; deterministic verification evidence remains the source of the final decision.

What It Proves

The included showcase fixture uses a real pytest regression from PR #13053.

• Broken revision: 53f8b4e634c5066c4f797a87b20060edbb086240
• Fixed revision: b55ab2aabb68c0ce94c3903139b062d0c2790152
• Golden proof: broken fails twice, fixed passes twice

See Showcase Fixture, project.json, and golden-proof.json.

The fixture catalog also contains click-path-newline-simulated and markupsafe-striptags-simulated so the Docker demo can show multiple projects. Their manifests, test files, and evidence shapes are real Repro inputs, but their revisions and recorded outcomes are explicitly simulated. They are not upstream verification claims.

Product Boundary

Repro currently supports prepared Python/pytest project fixtures with pinned revisions. It does not generate patches or claim root cause. Its goal is a bounded evidence bundle: a regression test that fails on the broken revision and passes on the fixed revision.

Live GPT-5.6 Hypotheses

Repro has an opt-in, live GPT-5.6 hypothesis stage. It calls the Responses API once for a prepared manifest and returns a schema-validated hypothesis with a concise summary, suspected failure mechanism, bounded reproduction plan, evidence needs, confidence, and limitations.

This is deliberately not an autonomous repair loop. The model does not generate a test or patch, execute a repository, or decide whether an issue is reproducible. repro verify still reads the recorded fixture proof to determine the terminal verification status. A hypothesis is context for a reviewer; the proof bundle is the evidence.

Set the key locally; do not commit it or paste it into issue evidence:

export OPENAI_API_KEY="..."
repro hypothesize pytest-importlib-13053 pytest-13053
repro verify pytest-importlib-13053 pytest-13053 --adapter openai --output bundle.json

The first command prints the hypothesis as JSON. The second writes the same hypothesis under the bundle's audit metadata alongside its model, response ID, and prompt version. Treat the model's confidence as a stated uncertainty, not a verification score.

The default model is gpt-5.6-terra. Override it for a single command with --model, or set REPRO_OPENAI_MODEL for your shell:

repro hypothesize pytest-importlib-13053 pytest-13053 --model gpt-5.6-terra

The API key is read only from OPENAI_API_KEY, is not written into an evidence bundle, and must never be committed. The call uses a bounded response, a 20-second timeout, and disables response storage. The Docker UI intentionally shows recorded verification only; it does not make a browser session perform a live model call. See OpenAI's GPT-5.6 guidance.

Security note for live hypotheses

repro hypothesize sends the prepared manifest's issue ID, title, symptom contract, declared revisions, test path, and command to the OpenAI Responses API over HTTPS. Review and redact that metadata before enabling live mode: do not include credentials, customer data, private repository details, or other sensitive material in a manifest. Repro does not send repository contents or run commands as part of this network call. Treat model output as untrusted text and keep execution of untrusted repositories inside an appropriately isolated environment.

Quick Start

Requirements: Python 3.10 or newer, Git, and network access for the golden-proof command (it fetches the pinned pytest revisions).

Install and run checks:

python3 -m pip install -e ".[dev]"
make check

Or run everything in Docker:

docker compose build
docker compose run --rm repro make check

Start the Docker demo UI:

docker compose up repro

Open http://localhost:8000 and click Open recorded verification. The Docker interface reads the included recorded proof; it does not execute pytest from the browser session. If port 8000 is busy, run REPRO_UI_PORT=8088 docker compose up repro and open http://localhost:8088.

Run the included golden proof:

make prove-golden

Basic CLI smoke test:

repro doctor

Run the local judge path:

repro verify pytest-importlib-13053 pytest-13053 --output bundle.json
repro judge pytest-importlib-13053 pytest-13053 --output judge.html

Explore post-MVP extension boundaries:

repro frameworks
repro onboard demo-project https://github.com/example/project --output-dir /tmp/repro-template
repro deployment-readiness

make check runs linting, strict type checking, the full test suite, and a coverage threshold. make prove-golden performs the real revision comparison and may take longer because it creates isolated virtual environments.

Expected result

After installation, repro doctor prints repro: ok. A successful golden proof reports two failures for the broken revision and two passes for the fixed revision, and writes the evidence to fixtures/showcase/pytest-importlib-13053/proof/golden-proof.json.

Scope and limitations

This release only supports prepared manifests for Python projects and pytest commands. It does not infer a bug from free-form text, generate a patch, prove root cause, or provide a hosted service. Revisions and runtime metadata are explicit so a reviewer can inspect the evidence. Do not treat the proof artifact as a security boundary: run untrusted repositories in an appropriately isolated environment.

The local judge UI is generated as static HTML for repeatable review. The service layer also exposes API-shaped run state, bounded SSE events, review actions, and redacted ZIP bundle export for tests and future web integration.

Post-MVP extension commands intentionally stay conservative. They create local templates, normalize issue metadata, describe framework support, keep patch/PR generation deferred, and report hosted-deployment readiness gaps rather than performing unsafe external writes.

License

The repository is published under the terms in LICENSE. The pytest fixture is sourced from the MIT-licensed pytest project; its provenance is documented in the fixture notes.

Repository Layout

• src/repro/: core typed models, manifest loading, and proof runner
• tests/: unit and integration tests
• fixtures/showcase/: verified pytest regression fixture and proof artifact
• scripts/: repeatable proof script
• docs/showcase-fixture.md: public fixture notes
• docs/docker-local.md: local Docker build and manual-test guide
• docs/Implementation-Tracker.md: implementation decisions and test history