Wrong type. Broken import. Function called with 3 args when it takes 2. XFBA scans every edit before it lands — AST-level, cross-file, before the code touches disk. If something's wrong, it offers to fix it, not just flag it.
Connect with GitHub — it's freeXFBA intercepts every code change at the PreToolUse stage. The edit hasn't touched disk yet. AST scan, import verification, type check, arity check — all run against the incoming change before it's applied. If there's a violation, the edit doesn't happen.
Changing a function signature? XFBA finds every caller in every file that just broke. Adding a new import? XFBA verifies it resolves. The check isn't limited to the file you're editing — it traces what depends on it across your entire codebase.
Violations come with a specific fix target: what's wrong, where it is, and what the corrected code looks like. Claude Code gets an action item, not a warning. The repair plan is the block reason — visible to both Claude Code and you in the conversation.
'Fix it, suppress it, or proceed?' You're always in control. Suppress for confirmed false positives. Proceed when the violation is intentional. Fix when it's a real bug. Nothing changes without your answer.
XFBA is Stage 1: it catches contract violations. XSIA is Stage 2: it maps cascade impact across the codebase. They always run together on every edit. XFBA is the gate. XSIA is the consequence map. Fix the contract first, then see what else breaks.
You ask Claude to edit or write code.
XFBA fires at PreToolUse — before the edit reaches disk.
AST scan + cross-file call graph check runs against the incoming change.
Clean: stamp fires, bypass token set, edit proceeds on retry.
Violation: edit blocked. Repair plan surfaces in conversation. 'Fix it, suppress it, or proceed?'
XSIA runs immediately after regardless of XFBA result.