Engineering inside ReproLab /
The data model, constraints and recovery decisions behind ReproLab.
Reproduce a bug in an isolated Node execution environment, review a bounded repair and verify it against the original tests.
Interface and interaction architecture
CodeMirror supplies the source-editing surface. The real workbench keeps isolated execution, protected test files, source snapshots and evidence packages separate from the dashboard preview.
Immutable input and bounded changes
The repository record stores the imported files and source identity; a candidate is a separate source change associated with a run. Restricting edits to existing non-test files preserves the tested baseline for this supported workflow. The exported unified diff describes the actual replacement instead of substituting a prose description for a patch.
A separate executable boundary
An application API creates a persisted execution job; a local runner claims it and invokes a restricted Docker environment. The displayed contract uses pinned Node 22, no network, a memory and CPU cap, and bounded command duration. Docker and the runner must both be available. The browser does not execute repository code itself.
Review state belongs to records
Authenticated workspace records carry versions and content digests. Mutations require a session, matching origin, CSRF token and idempotency key. Workspace-scoped reads prevent another QA registration from opening the run. These controls support traceable local changes; the current local authentication mode is not a configured public multi-tenant deployment.
Evidence survives delivery failure
The runner saves completed result data locally before acknowledging delivery to the application. A recovery test forced a completion response to fail, terminated only the isolated QA runner, then restarted it. It delivered the saved result without another Docker execution. This verifies a particular completed-result recovery path, not every possible infrastructure failure.
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.
Independent by construction
ReproLab has its own application source, build configuration, local server, database, object store and session cookie. The fifteen applications reuse copies of a common foundation, but their operational data and credentials are independent. A shared dependency cache on this Mac saves disk space; each product includes a lockfile and a command to install its own dependencies.
Mutations validate the workspace and current record version. Approval binds the reviewed content digest; an idempotency key prevents an identical retry from becoming a second action. These controls are implemented in the server, alongside the product-specific rules described above.
A similar problem in your business?
Bring a real workflow, representative inputs and the result that needs to be reliable.
Shape a project brief