About Repro
Why I built it
I have seen plenty of bug reports that sound completely believable but still leave a maintainer with the same question: can I actually reproduce this, and does the proposed test prove the fix?
That is the problem I wanted to focus on with Repro. A report is much more useful when it comes with a small, reviewable piece of evidence: the same test fails on the known-broken version and passes on the version that fixed the issue.
What it does
Repro turns a prepared Python/pytest issue into a maintainer-friendly verification record. Instead of only showing a green result, it keeps the details someone needs to trust that result: the issue, revisions, command, runtime, test path, attempts, logs, provenance, and limitations.
The demo uses a real pytest regression involving an ImportError. The reproduction fails twice on
pytest 8.3.4 and passes twice on pytest 8.3.5. From there, Repro produces a redacted JSON evidence
bundle and a portable report that a maintainer can review, approve, dispute, or download.
How I built it
I kept the product intentionally small and focused. The core is a typed Python application that validates the fixture before it runs, compares the declared broken and fixed revisions, classifies the outcome, redacts evidence, and renders a human-readable report.
I also built a local Docker UI around the workflow. I wanted it to feel like a real triage tool, not a landing page or a generic test dashboard. The first screen shows the issue under review, the verification plan, and the decision conditions. The next screen shows the evidence matrix, the controlled comparison, artifact provenance, and reviewer actions.
Codex was part of the build process from the beginning. I used it to work through requirements,
architecture, implementation, test cases, debugging, UI iterations, and final validation. In the
submission, I will include the factual GPT-5.6/Codex workflow and the relevant /feedback Session
ID from the project thread.
One important design choice: I did not want the UI to pretend that recorded evidence was a fresh model run. The Docker demo reads a versioned proof artifact and says that clearly. There is a credential-gated GPT-5.6 adapter boundary in the code, but the displayed verification decision is based on deterministic evidence, not model confidence.
Challenges I faced
The biggest challenge was finding the right balance between a compelling demo and an honest one. It is easy to make a polished interface look more magical than the underlying evidence really is. I had to keep asking: what can this screen prove, and what can it not prove?
That led to the evidence-first design. I added pinned revisions, the exact command, runtime identity, repeat attempts, artifact checksums, redaction counts, and visible limitations. I also made the result usable for a non-technical viewer without hiding the information a maintainer would care about.
The other challenge was release discipline. I added Docker validation, a 90% coverage gate, and a strict submission preflight so placeholder links, missing evidence, or stale submission details do not accidentally look complete.
What I learned
I learned that an AI-native developer tool needs more than an AI label. Trust comes from being able to see what ran, under what conditions, what failed, what passed, and what the result does not claim.
The idea behind Repro is simple: a bug report becomes much more valuable when it becomes reproducible evidence.
Log in or sign up for Devpost to join the conversation.