← Paul Barrick

// optimus / test-driver

Test-driver

An agent that walks a feature end-to-end, captures evidence, scores severity, and writes the run manifest back into the world-context engine.

live · scheduled

The problem

Agentic features are non-deterministic. Snapshot tests pass or fail on the wrong things. Coverage isn't the question — repeatable evidence is. When an LLM-backed feature regresses, the operator wants to see what actually happened during a real walk: which screens loaded, which assertions held, what severity the failure had, which commit made it worse.

Test-driver is the agent that produces that evidence on a schedule so the operator never has to ask "is the build still good?" without a recent answer in front of them.

How it works

Schedule

A weekly LaunchAgent fires npm run test-driver from the Optimus repo every Monday at 09:00. Output gets pushed straight to the test-drive UI in Optimus. On-demand runs are a click away from the same UI when the operator wants confirmation before a release.

What a manifest looks like

{
  "run_id": "2026-05-04T20-22-30",
  "kind": "walk",
  "started_at": "2026-05-04T20:22:30Z",
  "finished_at": "2026-05-04T20:24:11Z",
  "duration_ms": 101_312,
  "feature_slug": "goals-rollup",
  "screen_count": 9,
  "link_count": 14,
  "exit_code": 0,
  "totals": {
    "high_severity": 0,
    "medium_severity": 1,
    "low_severity": 0,
    "not_applicable": 2
  },
  "entries": [
    {
      "id": "TS-1",
      "title": "Goal card opens detail pane on click",
      "category": "table-stakes",
      "rationale": "Regression risk after Svelte 5.50 store reactivity bugs.",
      "result": "pass",
      "severity": "N/A"
    },
    /* ... */
  ]
}

Dogfooding

Test-driver walks itself. The test-drive UI in Optimus is the first feature that gets exercised on every scheduled run, so a regression in the verification layer surfaces in its own evidence stream before it reaches anywhere else.