The Debugging Should Start Before The Bug.

Most of my recent Scarab Diagnostic Suite posts have been field-test reports.

Open WebUI.

Vite.

Terraform.

Kubernetes.

Next.js.

VS Code.

Moby.

LangChain.

Deno.

Real repos. Real issues. Real failure boundaries.

Those field tests matter because they show Scarab operating outside my own projects. They show it can be dropped into an existing issue, surface a useful diagnostic boundary, and help constrain a repair lane.

But that is only one side of the product.

The public field tests show Scarab in recovery mode.

The original use case was active development.

Scarab was built because I was working with AI coding agents and kept seeing the same pattern: code would appear quickly, checks might pass, the app might run, but the repo would become less trustworthy underneath.

Responsibilities would blur. Files would bloat. Tests would start proving the patch instead of the contract. Framework-native paths would get bypassed. The repo would still move forward, but it would become harder to say what was actually true.

That is what Scarab was designed to catch.

Not after the repo becomes a mess.

During development.

The idea is simple:

AI agent changes the repo.

Scarab checks the change against accepted repo truth.

If a boundary breaks, the contradiction surfaces immediately.

The human, team, or coding agent decides the repair or governance update.

Scarab runs again to verify whether the repo now aligns.

That is a very different posture from traditional debugging.

Traditional debugging often starts after the damage has spread.

A bug appears. A test fails. A deployment breaks. Someone has to reconstruct what happened.

Scarab’s original purpose is to catch the contradiction closer to the moment it enters the repo.

That is why the field tests are interesting.

They are not just showing that Scarab can help with old issues.

They are showing the same diagnostic lens holding up across different kinds of software:

• Open WebUI: provider/config and retrieval-context truth
• Vite: dev/build contract truth
• Terraform: value presentation and cache authority
• Kubernetes: API machinery and watch-cache boundaries
• Next.js: artifact provenance and resource governance
• VS Code: editor input geometry
• LangChain: agent streaming vs structured-output timing
• Deno: JavaScript stream cancellation vs native runtime lifecycle

Different systems. Different languages. Different layers.

Same deeper pattern:

A system stops preserving a truth that another part of the system depends on.

That is the kind of boundary Scarab is built to surface.

The field tests prove the recovery side.

The deeper product is the guardrail.

I wrote the longer version of this on Substack here:

The Debugging Should Start Before the Bug

Scarab began as a guardrail for AI-assisted development. The field tests are proving it can diagnose software truth drift across major codebases.

scarabsystems.substack.com