Skip to content

XpansionFramework/Dispatch

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

292 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Xpansion Framework

Xpansion Framework

Code enforces what the LLM cannot be trusted to do reliably alone.

GitHub Stars   Python 3.8+   MIT License   Works with Claude Code

xpansion.dev  ·  How It Works  ·  Commands


Claude Code is powerful. It's not accountable.

It will tell you the function is fixed when it isn't. It will say the edit is clean when it breaks three callers. It will ship code that drifts from what you intended and call it done. Not because it's broken — because language models can't be trusted to verify their own output.

Xpansion Framework is the enforcement layer that closes that gap. Six modules, wired into Claude Code as hooks, running on every session. They catch what Claude misses, verify what Claude claims, and remember what Claude forgets — not by trusting the model more, but by checking mechanically where the model can't be trusted.


What's in the box

Module What it enforces BYOK (free) Pro / Team
XF Tool Dispatch Right tool for the task — from 16,500+ available
XF Boundary Auditor Code contract correctness before the edit lands ✓ basic ✓ full
XF System Impact Auditor Downstream blast radius before you commit
XF Token Control Context fill monitoring — nudge at 60%, warn at 85%
XF Memory Session snapshots — every session picks up where the last left off
XF De-Bug Spec verification — terminals met or not met, no LLM trust required

The modules

XF Tool Dispatch — right tool, right moment

Claude picks from defaults. There are 16,500+ tools in the ecosystem. The best one for what you're building right now — you've probably never heard of it.

XFTD runs as a hook on every message. When it detects a task shift — you moved from debugging an API to writing a test suite — it maps the shift to a category and surfaces grouped recommendations by type: Plugins, Skills, MCPs. One notice per topic per session.

Before high-value tool calls, XFTD intercepts and scores marketplace alternatives. If a purpose-built tool beats Claude's default by 10+ points, it surfaces the comparison and waits for your call. If nothing beats it, it exits silently.

Every session ends with a one-line digest — 12 calls audited, 0 blocked — so you know it was running even when it correctly stayed quiet.


XF Boundary Auditor — contract verification

Every Edit and Write fires XFBA. It indexes your entire project, walks the cross-file call graph, and checks every change against the contracts of the code it touches. Most of the time you see:

◈ XFBA  ✓  0 violations

When something's wrong, you see it in plain English before it lands:

◈ XFBA  ✗  1 violation found
  The payment function is being called without an amount — it'll fail silently.
  Repair: pass amount as second argument.

  Fix it, or show you what changed first?

What it catches: arity mismatches across files, broken imports where a symbol was renamed or moved, missing environment variables accessed with os.environ["KEY"], consumed stubs with active callers.

Supported languages: Python, TypeScript, TSX, Dart, Bash.

BYOK: Core arity and import checks. Pro: Full four-stage pipeline — AST scan → cascade analysis → concrete repair → graduated consent.


XF System Impact Auditor — blast radius mapping (Pro)

XFBA catches what's broken. XSIA maps what else breaks when the change lands.

A function signature changes. XFBA clears it. XSIA maps every caller across every file, every data flow that depends on the return type, every side effect on shared state. It asks one question: "Address these, or leave them for now?" You decide. If you say leave them, XF records the decision and steps back.

XSIA builds on XFBA. It never fires on broken code — XFBA is the gate, XSIA is the consequence map.


XF Token Control — context hygiene

Context fills faster than you think. When it's gone, you lose the thread — decisions, open questions, files changed, mid-thought reasoning. Compacting without saving means starting over.

XFTC watches your context fill and nudges before it's a problem:

  • 60% — "Snapshot and compact now, or keep going?" — soft nudge
  • 85% — hard warning — "Compact now. Snapshot first."

It also flags token hogs: CLAUDE.md files over 200 lines, verbose MCP calls, models running where they shouldn't.


XF Memory — session continuity

Every session, XF writes a snapshot. Every new session loads the last one. You don't lose the thread.

◈ XF-MEM  ✓  Session loaded
  Last session: yesterday
  You were: adding Stripe webhook handling
  Open: payment confirmation email not wired

Search across every session you've ever run with /xf-memr <query>. Recall a decision from three months ago. Resume a project you haven't touched since last quarter. The context is there.

Commands: /xf-mem to snapshot now · /xf-memr <query> to search


XF De-Bug — spec verification (Pro)

Claude says it's done. XFDB checks.

Write a spec with terminals — the specific things that must be true when the work is complete. XFDB verifies each one against your actual codebase. Not what Claude said it did. What's there.

For terminals that can be verified mechanically — "this file contains this string", "this function exists" — XFDB does a direct code check. No LLM involved. The model can't hallucinate a result that code can verify deterministically. For terminals that need semantic reasoning, it calls a fast model. The two-layer approach is what makes verification reliable.

◈ XFDB  ✓  XF-Debug Complete — ready to ship
  All 5 terminals met · Iteration 2
  Delivered: payment flow, webhook handler, confirmation email

Already built something? XFDB works retroactively. Run /xfdb synthesize — XF drafts a terminal spec from your conversation and verifies your existing code against it.

Commands: /xfdb · /xfdb <path> · /xfdb synthesize


Two ways to run XF

BYOK — free, open source, self-hosted

Everything in this repo. You bring your own API keys (OpenRouter for the fast models, Anthropic for Claude). Install takes two minutes. All six modules run locally.

Free forever. No account required. MIT licensed.

What BYOK includes: full XFTD, XFBA core checks, XFTC, XF-MEM. What it doesn't include: XSIA, XFDB, the 16,500-tool catalog sync, and the managed API that keeps everything current.

Pro — managed, full catalog, full modules (xpansion.dev)

Everything in BYOK plus:

  • XSIA — systemic impact analysis on every edit
  • XFDB — spec verification with mechanical + semantic checking
  • 16,500+ tool catalog — updated daily, scored by task context
  • Managed API — no keys to rotate, no infra to run
  • Session dashboard — interception history, tool usage, XFBA/XSIA analytics

Pricing:

  • Pro: $15/month — 10-day free trial, full access
  • Founding Dispatcher: $6/month locked for life — first 250 subscribers only
  • Team: $12/seat/month

Start free trial →


Install

BYOK (self-hosted)

git clone https://github.com/XpansionFramework/XF-Dispatch.git ~/.claude/xf-dispatch
cd ~/.claude/xf-dispatch
python3 install.py

You'll need an OpenRouter API key for the fast models. Add it to ~/.claude/dispatch/config.json after install.

Pro (managed)

  1. Connect at xpansion.dev
  2. Copy your install token
  3. Run: curl -sSL https://xpansion.dev/install/<token> | bash

That's it. XF installs into ~/.claude/ and starts running on the next Claude Code session.


How it works in a session

XF runs silently. You won't see it unless it finds something. When it does:

  • It describes the problem in plain English — no jargon
  • It asks one question with two options — you decide
  • If you say fix it, it fixes it and verifies the fix
  • If you say leave it, it records the decision and steps back

It never acts without asking. It never shows you commands to run. It never assumes the fix worked — it checks.

Full walkthrough → xpansion.dev/how-it-works


Philosophy

Every XF module exists because the LLM failed at something predictably:

  • Claude missed a broken caller → XFBA
  • Claude didn't see the cascade → XSIA
  • Claude lost the session context → XF-MEM
  • Claude said it was done when it wasn't → XFDB
  • Claude picked the wrong tool → XFTD
  • Claude burned through context silently → XFTC

The pattern is always the same: the LLM is capable, but it can't be trusted to verify itself. Code can. XF is what happens when you stop prompting the model to be more careful and start building enforcement that doesn't need it to be.


Contributing

Issues and PRs welcome. The BYOK layer is fully open — if you're building on top of XF or extending a module, open an issue first so we can coordinate.

Built by Visionairy. Also: Vib8.

About

Runtime discovery layer for Claude Code — proactively surfaces the best plugins, skills, and MCPs when you shift tasks; intercepts when Claude picks the wrong one

Topics

Resources

Contributing

Stars

Watchers

Forks

Releases

No releases published

Sponsor this project

 

Packages

 
 
 

Contributors