The problem
A simulator can replay the same inputs and still leave a developer with a difficult question: where did its behavior first change? Looking through an entire run is slow, and a test that fails for the wrong reason is not useful evidence. I built ReplayForge to make the starting point of that investigation explicit: record the states, compare them with a baseline, and point to the first divergence.
What I demonstrate
The example is a small integer-grid reference simulator, not a production game engine. ReplayForge runs a supplied replay and saves its state trace. It compares that trace with a known-good run, exposes the first differing frame and field, and generates an executable regression witness from the actual artifacts.
For the fault demonstration, I intentionally change the starting position from 2 to 3 in an isolated clone. The generated test must fail on the intended state assertion—not on a missing import or a broken command. The same test passes on the control. The proposed extension in draft MR !1 adds a third, separate revision that restores the starting position and passes again. The test and replay hashes stay unchanged across those three runs. This proves a controlled fault/restoration handoff; it does not claim an independently discovered repair or general production reliability.
Where GitLab Duo fits
The deterministic tools produce the evidence. GitLab Duo handles a post-code task around it: the existing finished session 9303980 took the work item about missing post-restoration evidence, changed the integration test and README, and opened draft MR !1. Its workload pipeline 2936867145 succeeded. I review the proposed result rather than approving each intermediate action, so this is a supervised workflow—not an unattended deployment loop.
The recorded demonstration uses MR revision a8f4226190b8510949e4a710aa48ce16ce30495b. Both its branch pipeline 2936990232 and MR pipeline 2936990255 passed. The public MR test report enumerates 247 successful tests, and the anonymously readable Python job log confirms that all three integration tests passed. These hosted results are separate from the local fault/restoration receipt and from the Duo workload. The MR is still a draft; I do not describe its extension as merged into the default branch.
Implementation and trade-offs
The simulator, comparer, generated witness, inspector and renderer use Python 3.10+ and the standard library. Git binds the handoff to concrete revisions. Node 18+ is used for the suite-authoring checks. The repository includes fixtures, reproduction instructions, CI configuration and a detected MIT license.
The most important design choice was to reject a misleading red result. A failure only supports the demonstration when it is the expected state assertion. Distinct revisions, identical test/replay hashes and a trace matching the baseline after restoration make that distinction inspectable. I also kept the initial failed Duo attempt visible instead of presenting the later success as an uninterrupted run.
Scope and provenance
The project is deliberately narrow: one reference simulator and synthetic fixtures, with no claim of a private engine integration, deployed service, independent repair, adoption or performance improvement. I published the sanitized source on October 11. Its retained private Git root is dated October 8; the public export does not include that full development history, and a publication date is not evidence of when every component was written. Runtime dependencies are not presented as newly authored project work.
Reproduce the result
Start with the public repository and its README. To reproduce the proposed post-restoration extension, check out the exact MR revision demonstrated in the video rather than assuming it is already on main. Run the replay and integration suite with Python 3.10+ and Git; on macOS, use a real task-local temporary directory as documented by the retained execution checks.
My next step is to review the proposed change for integration and add adapters beyond the reference simulator without weakening the evidence contract.
Jacob Scott-Metoyer
Log in or sign up for Devpost to join the conversation.