Fix & monitor
The fix loop
Findings become durable threads: your agent pulls specs over MCP, fixes in your repo, and the re-run's wire evidence flips the verdict.
Every published finding in your workspace becomes a fix thread: a durable object that survives across cycles, carries an evidence-cited fix spec, and walks a closed lifecycle. Your coding agent connects over MCP, pulls the thread with its evidence and acceptance criteria, implements the change in your repository, submits a plain-text fix note, and requests re-verification. The verdict flips only when the re-run completes and its recorded wire evidence ingests. Data flows one way: findings, evidence, and specs out; notes and re-verification requests in. We never see your code.
Connect
Auth is an org API token (create one in Settings, shown once). One URL, one header:
claude mcp add --transport http vorza-fix-loop \ https://www.vorza.dev/api/mcp/fix-loop \ --header "Authorization: Bearer vrz_..."
initialize and tools/list succeed without the header; every tool call needs it. Every tool description carries this sentence, verbatim, because it is the contract:
The state machine
Statuses are a closed set. Two of them are special: verified fixed and regressed are system-only resolutions of ingested cycle results. Nobody can set them by hand, including us. A customer saying “we fixed it” is a fix note, rendered neutrally; the verdict waits for the wire.
| from | to | who | gate |
|---|---|---|---|
| open | acknowledged | you, your agent | none |
| open, acknowledged, fix submitted, regressed | fix submitted | you, your agent | a non-empty fix note (the note is the transition) |
| open, acknowledged, fix submitted, regressed | re-verifying | you, your agent | the re-verification enqueue succeeds; the event records the bound cycle |
| re-verifying | verified fixed | system only | the bound cycle completed, no recurrence, every affected client measured |
| re-verifying | open | system only | the bound cycle completed with a recurrence |
| re-verifying | (prior status) | system only | the cycle failed or was inconclusive; revert to where the thread was |
| verified fixed | regressed | system only | a later completed cycle ingested the same failure again |
| open, acknowledged, fix submitted, regressed | won't fix | you only (never MCP) | none |
| won't fix | open | you only | none (reopen) |
Everything not in the table is refused. Every transition writes one append-only event with actor attribution (you, your agent via its token, or the system with the evidence that gated it), so a thread's history is a complete audit trail.
What verified fixed means
Re-verification is a standard cycle of the thread's bound source: an identical run of the bound eval (same spec, same clients, same n), or the audit's affected scenarios, with real coding agents in fresh sandboxes. A thread turns verified fixed only when that cycle completes, ingests no recurrence of this failure, and every affected client has at least one measured run. The plain meaning, stated on every surface: this specific failure did not reproduce across n fresh verified runs. The per-client k/n is on the event; n is the eval's configured run count, not a promise of impossibility. An unmeasured client, a skipped judge (for judge-derived findings), or a failed cycle makes the re-run inconclusive, never a pass.
Two rules protect the gate: a cycle that was already running when you requested re-verification is refused (its runs started before your fix could have deployed, and a flaky defect that happens not to reproduce in pre-fix runs must never turn verified), and a recurrence in any later completed cycle flips a verified thread to regressed automatically.
Fix specs
Where the failure mechanics dictate the change, the spec is assembled deterministically from the finding's own evidence; where judgment is needed, it is AI-drafted. Either way, every change cites stored run evidence through a verbatim quote gate, and a spec whose citations fail that gate is suppressed entirely rather than shipped degraded. Acceptance criteria are not stored in the spec: they derive at read time from what re-verification will actually run, so they can never drift.
The tools
| tool | what it does |
|---|---|
list_findings | Your workspace's fix threads, most severe first, with status, source, and recurrence count. |
get_finding | One thread in full: evidence with indices, the fix spec (or why it was suppressed), acceptance criteria, binding, history. |
get_fix_spec | The packaged brief: problem, per-surface changes, acceptance criteria, and the verification step. |
get_evidence | The cited trace events, sliced from the stored scrubbed artifact and fenced as untrusted data. |
list_agent_readiness_specs | The agent-readiness reference library index. |
get_agent_readiness_spec | One library entry in full, chunked. |
submit_fix_note | Records what you changed (plain text) and moves the thread to fix submitted. |
request_reverification | Enqueues the standard re-run of the bound source; returns the bound cycle. |
get_reverification_status | The bound cycle's status, then the system resolution with per-client k/n. |
There is also a prompt: /fix_finding fix_… pulls the complete brief and asks the agent to implement it in the current repository. Fix notes are stored as plain text, rendered as plain text, never executed, and never fed to a model.
Sources that cannot re-run
An archived eval, a credential-less target, or a refunded audit retires the thread's source. The thread stays fully visible with its history; acknowledging, noting, and won't-fix still work; re-verification refuses with the action that would unblock it; and verified fixed is unreachable by design, because there is no runnable source to prove it. The surface says so in neutral ink.
The audit-scoped server
Audits keep their own per-audit MCP server at /api/mcp/audit (bearer credential from the results page, 90-day expiry, one audit's findings and re-run allowance and nothing else). Its verification door also updates org-owned threads, so both doors land on the same lifecycle. See the MCP reference for both servers.
A verified fix also leaves an org-private changelog draft (what broke, what you changed, the k/n behind the verification) under Fix Loop → Changelog drafts, ready for wherever you publish release notes.