Vibe Code Guardian · workflow demo

Evidence before merge.

Five steps. One reviewable record. A 40-second synthetic walkthrough.

01 / 05 · Synthetic audit record

Start with a scoped failure.

The supplied record deliberately marks one required rule, C-rule, as FAIL. F-rule is a medium-severity synthetic finding; no real application defect is asserted.

A required rule can block acceptance even at medium severity.

WHAT THE FIXTURE RECORDS
snapshot
synthetic-fixture-v1
required check
C-rule · FAIL
decision
BLOCKED
00:00 / 00:40 · Step 1 of 5

Playback advances every eight seconds and stops after one pass. Step controls pause playback. These controls only navigate this storyboard; they cannot grant approval or execute a change.

Read all five steps
  1. Audit: The synthetic input records C-rule as a required FAIL and F-rule as an unresolved medium finding. The decision is BLOCKED.
  2. Plan: The rendered plan proposes T-repair, then dependent T-verify. It specifies prerequisites, a verification oracle and stop conditions.
  3. Approve: In a real host, the user would review a specific plan, target and batch before authorizing changes. No approval is recorded or granted here.
  4. Fix: After real scoped approval and target revalidation, the host could implement the permitted batch. In this fixture T-repair remains PROPOSED and no change is recorded.
  5. Retest: A real run would replay the first failure and legitimate behavior. T-verify remains PROPOSED, no retest is recorded and the existing required FAIL keeps the decision BLOCKED.