Caught to Closed: How Vigil Turns Every Bug Your Team Finds Into a Test-Backed Fix

By the SynaptixLabs Team

---

A QA tester catches a checkout crash on a Friday afternoon. She does everything right: she screenshots it, she writes the steps in a ticket, she drops a screen recording into a Slack thread so engineering can see exactly what she saw.

Six weeks later the bug is still open.

The repro steps live in a Jira comment. The recording is buried in someone's DMs. The console errors were never captured at all — and the actual context, the precise state of the page at the moment it broke, died with the browser tab she closed that afternoon. The fix never shipped, not because it was hard, but because nobody could cheaply rebuild the moment it broke.

This is the most expensive failure mode in software, and almost nobody names it: bugs get found, then lost.

The broken link in the loop

We have spent twenty years industrializing the finding of bugs. We have error trackers, session replay, observability dashboards, and on-call rotations. What we never industrialized is the handoff — the moment a bug stops being something a human noticed and becomes something a machine can act on.

At that seam, everything leaks. A bug arrives at engineering as a vague paragraph instead of a reproducible artifact. An engineer reads it, can't reproduce it, asks a clarifying question, waits a day for the answer, half-reproduces it, and by then three other fires are burning. The bug slides down the backlog. Multiply that by a real team and a real quarter and you get the quiet truth of most roadmaps: the limiting factor is not finding problems. It is carrying them, intact, across the gap between "found" and "fixed."

That gap is the thing Vigil is built to close.

Capture the whole story, not a paragraph

Vigil is a three-tier bug discovery and resolution platform. A Chrome extension (Manifest V3) captures bugs via rrweb DOM recording; a Node/Express server stores them in Neon PostgreSQL; and a React dashboard manages them. It is deployed live on Vercel and Neon at vigil-two.vercel.app.

The first design decision that matters is what gets captured. When a bug happens, Vigil does not ask a human to describe it. It snapshots the whole story at the instant it occurs: an rrweb recording that survives across page navigations, screenshots, repro steps, the console, the network log, a DOM snapshot, and the environment — all as a single context bundle. The capture UI runs in a Shadow-DOM-isolated overlay (the extension calls it "GOD MODE") that never interferes with the host app it is watching.

The point is not to collect more telemetry. It is to make the handoff lossless. The bundle is the difference between handing engineering a paragraph and handing it a reproducible artifact — and, as we will see, the difference between an agent that guesses and an agent that can actually act.

Below is a guided walk through that journey — the same six-station loop the bug travels, from the real session where it was caught to the pull request where it is closed. You can drag to pan, scroll to zoom, click any station to inspect it, and — if you are quick — catch the bug ticket as it rides the belt.

Figure: Vigil's test-to-fix loop. The on-belt figures — "12 passed · 0 failed", "PR #418 merged", a "+1 −1" patch — are illustrative constants that make the story legible, not live metrics. The grounded numbers live in the text: 267 Vitest tests behind the suite, and a fix capped at three iterations before it escalates to a human.

The handoff: from "human found it" to "machine can act on it"

Once the context bundle exists, Vigil's real differentiator kicks in: it hands that bundle to agents.

The AI handoff is real and standards-based. The Vigil server exposes an MCP server — the README lists eight tools, including vigil_get_bug, vigil_update_bug, and vigil_close_bug — plus a Session Report API (GET /api/sessions/:id/report) that emits an LLM-readable markdown rendering of any session. That means an agent such as Claude Code can read a bug, understand its full context, apply a fix, and close it, all through a standard protocol rather than a bespoke integration.

Two agents do the load-bearing work. A router (triage) agent classifies each captured bug, deduplicates it against the existing backlog, and assigns a priority. A coder agent then drafts a minimal patch scoped to the failing path. Neither of these is a demo prop; in the figure above, "router agent" and "coder agent" name real production agents.

The crucial point is what those agents are not. They are not part of Vigil.

Consume, don't reimplement

Vigil has an architectural prime directive, written into its constitution: "Vigil NEVER owns LLM inference — it is a consumer of the platform's llm_core."

Read that twice, because it is the whole thesis. Vigil owns zero model weights and zero inference code. The intelligence its agents run on lives in a separate Agents-as-a-Service layer (in the repository it is named AGENTS / nightingale — a Python FastAPI service running Groq's llama-3.1-8b-instant behind a single llm_core seam). On our website we productize that same consume-don't-reimplement layer under the name Nexus. The name on the box differs; the pattern is identical, and it is the pattern that matters.

This is what Agents-as-a-Service actually buys a product team. Because Vigil consumes llm_core rather than embedding a model, the provider behind the seam can change — Groq today, something else tomorrow — without touching a line of Vigil. A configuration flag (llmMode) flips the same agents between a mock backend and a live one. Vigil stays small, focused, and provider-agnostic, and the hard, fast-moving, expensive parts of running models in production stay where they belong: in the platform, governed once, for every product that consumes it.

And Vigil contributes something back up that seam that most callers do not: memory. The rrweb context bundle and the LLM-readable Session Report give the platform's agents a reproducible artifact to reason over instead of a vague paragraph. The quality of an agent's fix is bounded by the quality of its context — and capturing context whole is exactly what Vigil is good at.

Governed by a green test

Autonomy without a gate is just a faster way to ship the wrong thing. Vigil's loop is governed, and the governance is not a policy document — it is the control flow.

The resolution loop is strictly test-first, red then green. The fix routine writes a failing regression test first (tests/e2e/regression/BUG-XXX.spec.ts), then implements the fix — capped at maxFixIterations: 3 — confirms the suite is green, and only then calls vigil_close_bug. The autonomous agent introduced in Sprint 07 runs that full red-to-green loop over a queue, and it commits to a branch only, never to main. Every patch is queued for human review. A bug closes only when its regression test passes.

So when the conveyor in the figure flips from red to green at "Verify," that is not decoration. It is the gate. Quality is enforced by tests — 267 Vitest unit and integration tests plus Playwright E2E — and the quality gate forbids marking any bug done without a regression test written and green for that fix. The committed vigil.config.json ships with llmMode: 'mock' by default: the full-auto loop is real, but it is a reviewed, branch-only, test-gated loop, not a hands-off robot pushing to production.

There is a quiet elegance in that last constraint. Every bug Vigil resolves leaves behind a permanent Playwright regression spec. The crash your tester caught on a Friday does not just get fixed — it becomes the test that guarantees it can never silently come back. The bug becomes its own antibody.

Where Vigil is now

Vigil is live. It is deployed on Vercel and Neon PostgreSQL at vigil-two.vercel.app, currently at v2.1.0, with sprints 00 through 07 done and Sprint 08 — session resilience, the GOD MODE overlay, a dashboard redesign, the LLM API, and the MCP tools — active.

One detail is worth lingering on, because it is the most honest thing we can say about the project: Vigil is built by Claude Code agent teams. Its .claude/ directory holds role commands — cto, cpto, dev-ext, dev-server, dev-dashboard, dev-qa, bug-fix — and reusable skills. The product dogfoods the exact agentic-development pattern it sells. The thing that fixes your bugs on a governed, test-first loop is itself built on a governed, test-first loop.

The walkthrough above is a guided run over a single seeded bug report — BUG-2231, a checkout crash — not live customer data and not a fix executing in your browser. But the loop it traces is the real one, and the engine underneath it is real: capture the whole story, hand it to agents on Nexus, gate every close behind a green regression test.

The bug your team finds should not die in a Slack thread. It should become the test that protects you from it next time. That is the entire point of closing the gap between "found" and "fixed" — and it is a gap you can watch close.

---

Vigil is a SynaptixLabs product. The agents it relies on run on Nexus — our Agents-as-a-Service layer — by design: a product should consume intelligence, not reimplement it. Talk to us.

— The SynaptixLabs Team