Inspiration
A team fixes an authorization bug, then months later repeats the same mistake through a new endpoint. The incident exists in an issue, but the knowledge never becomes an executable safeguard. We built Time Machine CI for maintainers who need incident memory to participate in code review and testing.
What it does
Time Machine CI retrieves relevant incidents for a GitLab merge request, asks a real GitLab Duo investigator whether the changed code repeats a cited failure mode, and validates the resulting structured assessment. For the supported notes-export ownership pattern, a deterministic generator produces a reviewed Pytest assertion. Actual GitLab CI decides whether the risk is reproduced or cleared; a model confidence score never confirms a vulnerability.
In the recorded synthetic demonstration, Bob could export Alice's private note. The generated assertion failed a real pipeline and GitLab blocked the ready MR. An ownership repair then passed the byte-identical test. Human approval was required before merging.
How we built it
Python/FastAPI provides a deliberately small notes fixture. A seeded GitLab issue and local incident fixture become normalized, cited records in SQLite FTS5. The MR collector reads metadata, a complete bounded diff and metadata again, binding the assessment to a stable source SHA and checksum. Pydantic validation constrains IDs, citations, route, actors and denial statuses. The CI wrapper validates Git ancestry, generates one fixed template, runs Pytest and records JUnit plus evidence hashes.
GitLab Duo Agent Platform is real: the original private custom-agent session produced the assessment used by the CI demonstration. Its exact output was transferred manually into the manifest. A later official two-stage Mention-triggered flow independently retrieves MR/issue evidence and reports its review; it finished with all 25/25 files after a documented read-only pagination fix. This flow automates retrieval and reporting, not manifest creation or CI invocation. These two executions are clearly distinguished in the evidence.
Challenges
GitLab account fallback settings initially prevented use of the provisioned hackathon credits; selecting the hackathon default Duo group resolved access. The specialized diff tool returned only 20/25 files. The first flow correctly kept its result inconclusive, and the updated flow uses the documented read-only API GET capability with per_page=100, file-count checks and a stable-SHA recheck. A runner image initially lacked Git; the setup failure was labeled inconclusive, and Git was then installed explicitly. None of these failures was presented as regression proof.
Accomplishments
The screen-recorded demo also captures a fresh regression job starting, running and passing: job #17479402208, executed at commit 50c8b72a. Its independently downloaded evidence reports cleared with the same test and manifest hashes as the original proof. Waiting is trimmed in the video. The incident-to-test chain is inspectable in real GitLab history. The red and green jobs preserve matching manifest and test hashes, including byte-identical generated Python. The final implementation MR passed 60 tests. Protected main requires a successful pipeline and merges remain human-approved. The later two-stage flow is reproducible from published YAML and setup instructions.
What we learned
Historical similarity is only a lead. Useful automation must preserve provenance, reject incomplete inputs and separate model suspicion from an executable assertion. Conservative failure classification matters: missing routes, timeouts and malformed output cannot be reported as confirmed vulnerabilities.
What's next
Replace the manual assessment-to-manifest transfer with a supported, validated flow bridge; add execution deduplication for repeated SHAs; broaden the reviewed template library. The current MVP intentionally supports one authorization pattern. No production deployment, Google Cloud bonus, autonomous remediation or sustainability measurement is claimed.
Execution evidence
- Public MIT repository and setup
- Incident-to-CI evidence and matching hashes
- Official flow configuration and completed session
All identities, notes and historical incidents are intentionally seeded synthetic examples. All linked model sessions and pipeline results are actual executions. Target: Path A, Supervised, with the manual assessment handoff disclosed above.
Log in or sign up for Devpost to join the conversation.