XFDB
XF De-Bug · XFDB

Replace vibe with verified — define what done means, then enforce it.

A terminal is a verifiable outcome — a specific, binary condition the code must satisfy before it ships. Not a test. Not a feeling. A finite result based on the actual intent of the feature. XFDB checks every terminal, tells Claude what's unmet, loops until they're all green, and only then calls it done.

Connect with GitHub — it's free

What it does

1

Terminals — verifiable outcomes based on the intent of the code.

A terminal is not a unit test. It's a finite, binary outcome that describes what the feature is supposed to do: 'Google OAuth redirects to /dashboard.' 'Email validation fires on blur.' 'Session persists across page refresh.' Met or unmet. No ambiguity. You define them. XFDB verifies them.

2

Spec-first verification — done is defined before code is written.

Write your terminals in a spec file before building. XFDB reads the spec and verifies the implementation against each terminal. The spec is the contract. The implementation either satisfies it or it doesn't. 'Looks right' is not a terminal. 'Renders without errors' is.

3

Loop until all terminals are met — no manual re-runs.

XFDB doesn't just report. It gives Claude a fix target for every unmet terminal. Claude fixes. XFDB re-runs. Loop continues until every terminal is green. You don't call it done — XFDB does, when the spec is fully met.

4

Shows what's missing, not just what failed.

Unmet terminals come with a description of exactly what's missing in the implementation. Not 'test failed.' Not 'assertion error.' 'Google OAuth redirects to /dashboard — redirect handler missing.' Claude gets a concrete action, not a vague failure.

5

On demand via /xfdb — run before any ship, merge, or PR.

Run /xfdb before pushing. It reads your spec, checks every terminal, and returns the full report in seconds. Gate your ship on XFDB green. No green, no ship.

6

Self-updating — re-verifies when core files change.

The spec-sync hook watches your source files. When a file that a terminal depends on is edited, XFDB re-runs that terminal automatically. Your spec stays in sync with your implementation — you don't have to remember to check.

How it works

1

Define terminals in your spec file — each is a binary outcome the feature must satisfy.

2

/xfdb fires — reads the spec, checks each terminal against the implementation.

3

Met terminals listed with ✓. Unmet listed with ✗ and what's missing.

4

Claude receives fix targets for every unmet terminal.

5

Claude fixes. /xfdb re-runs automatically.

6

Loop continues until all terminals are green. Then and only then: ship.

● ● ●
◈ XFDB 5 terminals · 4 met · 1 unmet
✓ login screen renders without errors
✓ email validation fires on blur
✓ password minimum length enforced
✓ form submits on Enter key
✗ Google OAuth redirects to /dashboard — redirect handler missing
→ Claude: fix the 1 unmet terminal. /xfdb will re-run.
Other modules