ReproLens

• 

  Follow a report reference to its original log line.

• 

  After a rewrite, the old source match is removed and manual comparison is required.

• 

  Export a confirmed Markdown issue with only the cited excerpts.

• 

  Local AI organizes exact source fragments into an editable issue.

Inspiration

A bug report often arrives as several pieces: a short message, a log, a description of what should have happened and a later correction. Putting those into a template is easy; checking whether the finished report still agrees with the original material takes more care. ReproLens explores a small, concrete workflow for students and independent developers preparing these reports.

The audience is a product hypothesis. There are no claimed user interviews, adoption numbers or measured time savings.

What it does

ReproLens keeps deliberately supplied sources beside an editable issue with environment, steps, actual and expected results. A configured local AI can propose categories, but the reviewer controls the final wording. Each section can show the exact source locations of its current text. Click a reference to inspect the original line; edit the wording and the old match is recalculated immediately.

After reviewing content and privacy, confirm that version and export Markdown. Include just the cited excerpts when useful, or separately opt into attaching full sources. Saved history retains the original AI proposal and later edits. Restoring a version creates a new draft instead of deleting the later work.

How it was built

The application uses Python, FastAPI, Pydantic, SQLite WAL and native JavaScript/CSS. The optional local Qwen3.5-4B model selects references and categories; application code copies the exact source fragments and validates their line and Unicode character offsets. A typed LangGraph workflow runs inside durable SQLite-backed jobs. A page refresh does not discard the job, and a result based on an old revision cannot overwrite newer saved work.

I built ReproLens as a solo entry with Codex and the Devpost Learn Skill Pack. The Skill Pack provided the structure for the scope, PRD, specification, build checklist and shipping preparation. The public repository includes these planning documents and the instructions needed to run the application.

Demonstration

The video follows an actually executed, deliberately faulty CSV reader. Two files contain the same purchase rows: plain UTF-8 returns 12.50; the BOM variant raises KeyError for amount. Those real outputs become source files in ReproLens. The demonstration includes a real local-model call, source inspection, a manual rewrite that loses automatic linkage, confirmation, selective evidence export and version history.

This is a controlled reproducible example, not a customer incident. ReproLens itself does not execute supplied code or independently reproduce a bug.

Challenges

Exact quotations did not guarantee correct categories or complete reports. Fresh diagnostics exposed mixed paragraphs assigned to one section and later corrections being omitted. The first fragment approach allowed overlapping full-line and fragment selections; it failed closed. The current adapter offers non-overlapping units and retains the failed records. Missing expectations, corrections and follow-up questions remain known model limitations.

Accomplishments and limits

The result is a complete local review workflow with traceability that responds to edits, selective export and recoverable versions. A 121-test mechanical regression suite passes. A ten-case diagnostic model review judged seven results sufficient and three partial; these constructed, reused cases are not a general accuracy estimate or an independent user study.

What is next

Observe target users preparing the same real report with a Markdown template and ReproLens. Compare omissions, correction effort and elapsed time without assuming improvement. Improve correction/expectation coverage only after collecting representative examples and preserving a genuinely unseen evaluation set.

My contribution and what I learned

I entered this competition on my own to build something useful and aim for a good result. My expectations were clear: the product should work from start to finish, its results should be backed by evidence, and the demo should be easy to follow. A long feature list or a passing test suite would not be enough on its own.

One detail from this project is worth remembering: a model can copy the source correctly and still produce a bad report. It can put a sentence in the wrong section or leave out a later correction. A valid quotation will not catch either problem. What matters to me is being able to go back to the original text, and checking the link again after the report is edited. That gives the person using it a clearer view of what still needs their attention.

Passing tests does not mean the product is useful yet. It still misses expectations and corrections, and there is no real user feedback showing that it saves effort compared with writing Markdown directly. Next, I want to address those gaps and have people who actually prepare bug reports try both approaches with the same material. The omissions, corrections and time taken will tell us more than another feature list.

Run it locally

Verified platform: Python 3.12 on Windows. The public MIT-licensed repository includes installation instructions and the Skill Pack planning files in devpost/scope.md, devpost/prd.md and devpost/spec.md. Manual editing works without a model or paid service; AI organization needs a separately configured local model. No public hosted app is claimed.

Built With

• fastapi
• javascript
• langgraph
• pydantic
• python
• sqlite