FaultLine

Result and evidence

• First PASS→FAIL commit in 1-5 minControlled evaluationOn small-to-medium projects.
• 1-3 h saved per investigationControlled evaluationCompared with manual bisecting.

The case

Problem

A bisect result or a CI log says where a check failed once. It does not give another engineer evidence they can verify without rerunning the repository's code.

Decision

Freeze one human-reviewed check, replay that exact check across the selected Git states in Docker sandboxes, and package the recorded results so another engineer can verify them offline.

Constraint

Proof artifacts must never carry credentials, so verification fails closed.

Example

Input: a frozen workflow check and four Git states from FaultLine's own history. Output: PASS at e8e30649, the first stable FAIL at 97c3290e, and PASS again at the fix, 07ee7f11, in a package that verified against its recorded root.

Considered and rejected

Git bisect on its own: it finds a boundary but leaves no reviewable, portable record of what was executed.

Architecture

1. Frozen checkhuman-reviewed
2. ReplayDocker, per Git state
3. Proof package
4. Offline verifierno repo code runs

Beside the path

1. Secret scanner8 rules + entropy, from Proof package

Around it

1. GitHub Actions + SigstoreCI attestation

What was built

1. A solo Go CLI that replays a frozen, human-reviewed check across Git history in Docker sandboxes. It pinpoints the first reliable PASS→FAIL commit in 1-5 minutes.
2. It automates investigation, minimisation and CI attestation with GitHub Actions and Sigstore. This saves 1-3 hours per regression investigation compared with manual bisecting, on small-to-medium projects.
3. Adversarial secret scanning with 8 detection rules plus an entropy heuristic, and fail-closed verification. Together they block credential leaks from proof artifacts.

Limitations

It shows where a frozen check first fails across the supplied Git states. It does not establish a unique root cause or an agent's intent.