ReproLab /
Make the failure useful.
Reproduce a bug in an isolated Node execution environment, review a bounded repair and verify it against the original tests.
- Practice
- AI & automation
- Built by
- Lumia Digital
- Application
- Independent source & workspace
- Current release
- Local / September 2026
An engineering dashboard built around evidence.
A dark-navigation SaaS interface surfaces failing baselines, verification states, active executions and the next review action. Insights describe recorded checks rather than deployment claims.
CodeMirror repair editorSee how ReproLab thinks.
Every Lumia system earns its own operating language. This view shows the decision surface, evidence trail and human checkpoint built around this workflow.
01 describe('settlement adapter', () => {02 it('replays the vendor payload', async () => {03 const result = await adapter.settle(fixture)04 expect(result.currency).toBe('INR')05 expect(result.entries).toHaveLength(14)06 })07 })
Interface study / controlled local workspace / human review remains in the loop.
The problem worth solving.
A useful bug report needs more than a plausible explanation. A maintainer must identify the source revision, reproduce the reported behavior and determine whether a proposed change fixes the same regression. When those facts sit in separate terminal histories or chat messages, review becomes difficult: the successful output might belong to a different commit or a test that was quietly changed.
ReproLab brings that sequence into one local workspace. An authorized source snapshot becomes an immutable revision. The operator describes the failure, runs its existing regression tests and stages a bounded source replacement. The application displays the original result beside verification of the candidate and exports the evidence with an applicable diff. The purpose is a reviewable technical decision, with human judgment retained over the report, patch and eventual merge.
This independent Lumia application was exercised with an owned, dependency-free addition example that deliberately subtracts its inputs. That small fixture makes the before-and-after behavior inspectable; it is not evidence of customer adoption or a claim that arbitrary repositories can be repaired. The design favors a narrow executable path whose evidence can be examined over an unsupported promise to fix every bug.
Designed for: Software maintainers and small engineering teams reviewing reproducible JavaScript regressions in authorized, dependency-free Node projects.
From input to a useful result.
Import the revision
Choose a source folder and give the snapshot a recognizable name. The supported import retains bounded UTF-8 source files and excludes Git metadata, dependencies and generated output. Inspect the file list before creating a run. The imported revision is a saved source snapshot, not a connection to a remote repository that will silently follow later commits.
Establish the failure
Write the expected behavior, actual result and relevant input. Run the baseline using the existing node --test suite. Read the exit result and log before proceeding. A compilation problem, missing dependency or interrupted executor should lead to investigation rather than being treated as proof that the reported functional regression was reproduced.
Review and stage a repair
Select an existing non-test source file and enter its complete replacement. Review the generated diff. Tests and package manifests remain protected by the bounded patch contract. Optional model output is a proposal to inspect; the manual patch route can complete the workflow without making a model request.
Verify and retain evidence
Run the candidate against the preserved regression suite. Compare both execution records and download the evidence ZIP, containing evidence.json and candidate.diff. Reload the workspace to reopen the saved run. Apply and review the diff through the team's normal repository process; exporting evidence does not merge code or deploy the repair.
What the software actually did.
These results come from internal workflow testing of the local product. The records are controlled test inputs; customer deployments and commercial impact have not been measured.
An actual failing baseline and passing candidate
The HTTP execution suite passed 14 ReproLab checks. Its synthetic sum implementation returned zero for one plus one; the original regression command exited1. Replacing subtraction with addition produced an actual exit 0 verification against the unchanged test. The package retained both results. These observations establish the fixture's repair, not general defect-detection accuracy.
The same sequence through the browser
A separate headed browser pass registered a workspace, imported the folder, created the report, ran the baseline, staged sum.js, reviewed its diff and verified it. The downloaded ZIP contained matching evidence and patch content. Reload retained the verified run. Desktop 1440 px and mobile 390 px / 320 px layouts were visually inspected, including the candidate view.
Patch boundaries and an applicable export
The API rejected test-file and package-manifest patches, new-file additions and traversal paths in the bounded acceptance scenarios. A separately exported diff passed actual git apply --check against the original clean fixture. That check did not modify the repository and is narrower than testing every possible multi-file diff or newline combination.
Make the boundary clear.
- Supported imports are dependency-free Node 22 UTF-8 projects, bounded to 100 files,30 KB per file and200,000 total characters in the inspected interface.
- The manual patch path targets existing non-test source files. It does not install packages, modify test expectations or merge a remote branch.
- Passing the supplied regression suite is evidence for those tests, not proof that every behavior is correct.
- Model requests require a configured provider and the application's consent gate. Confidential customer code was not used in the recorded model test.
- The forced recovery test covered completed evidence awaiting delivery; it did not force every lease-expiry, mid-command crash or production disaster scenario.
Questions before you start.
Does ReproLab need AI to verify a repair?
No. The demonstrated manual route imports source, runs a real baseline, stages a source replacement and verifies it without a model request. A configured model can suggest a candidate, which remains subject to review and execution.
What does verified mean?
The saved candidate passed the supported regression command for the recorded revision. Read the baseline, candidate log and diff together. The status does not certify untested requirements, security or production compatibility.
Can it run an arbitrary GitHub repository?
The tested import contract is a bounded, authorized, dependency-free Node 22 source snapshot. Network package installation, arbitrary build environments and remote repository permissions are outside this local workflow.
What happens if result delivery fails?
The local runner retains completed evidence for reconciliation. The controlled recovery test delivered that same result after restart without repeating its command. Other interruption modes still require checking execution status and operational logs.