How to use ReproLab /
A practical path through ReproLab, from the first input to a saved, reviewable result.
Reproduce a bug in an isolated Node execution environment, review a bounded repair and verify it against the original tests.
Before you begin
Explore the overview and insight screens with example records, or open the private dashboard to see metrics calculated from your saved workflow records.
Create an account in ReproLab and work in its own private workspace. Accounts and records from another Lumia product are separate. Software maintainers and small engineering teams reviewing reproducible JavaScript regressions in authorized, dependency-free Node projects.
Follow the workflow below to understand the application. Contact Lumia for a guided walkthrough; account access is private. An exported file reflects the record at the time of export.
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.
Operating the product
Start with the public interface preview to explore overview and insights using example records. Open /dashboard for account-scoped metrics calculated from your saved records, or /desk for the underlying workflow.
Start the local application, Docker daemon and this product's runner before requesting execution. Use the documented pinned runtime and product-specific storage paths.
After an interruption, inspect the saved run and execution status before starting another job. Preserve the job journal when investigating a delivery failure.
Keep the source snapshot, evidence ZIP and reviewed diff together. A later repository revision should receive a separate review against its own tests.
Re-run the regression suite and review the patch in the destination repository before any merge or deployment. No remote source-control write is part of this local path.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief