Every session starts with a prompt. That prompt is infinite — it can mean anything, go anywhere, expand without bound. XFFI intercepts before any work starts and classifies the session into one of four modes: Code, Create, Concept, or Operate. It grounds the spec in verified Roots — facts confirmed from your actual project — then decomposes into four MECE limbs: Build, Understand, Specify, Operate. Every terminal is atomic and non-overlapping. The rest of XF executes against that spec. Without XFFI, you're enforcing execution on undefined intent. With it, done is defined before work begins.
Part of Decomposition Engine
Connect with GitHub — it's freeXFFI is the first module in the stack. Before XFTD routes a tool, before XFBA checks a contract, before XSIA maps impact — XFFI produces the spec every other module executes against. You can't enforce what you haven't defined. XFFI defines it.
XFFI decomposes your intent into four bounded limbs: Build (what gets made), Understand (what informs the work), Specify (the rules and constraints), Operate (how it runs and deploys). Each limb is recursively explored until every node is atomic. Nothing leaks between boundaries. Nothing is double-counted. The result is a finite set of terminals — not a roadmap, not a backlog, a closed list.
The output isn't a plan. It's a spec sheet: a finite list of binary outcomes the implementation must satisfy. Each terminal is a verifiable condition — met or not met. XFXA reads this spec at ship time and enforces it mechanically. XFFI defines done. XFXA proves it.
Before decomposition runs, XFFI confirms Roots — the evidence your spec is allowed to reference. Four sources feed them, and you see which ones contributed before you confirm: (1) XFMT conversation history — every prior session you have stored, semantically matched to your current intent (so decisions from three weeks ago still inform today's spec); (2) your project filesystem — actual code, configs, docs, and prior specs read in-session (so the spec respects what is already built, not what the model imagines is built); (3) active session signals — what you have just typed, decided, or referenced right now; (4) sibling specs — when you split a multi-scope intent into a family, completed sibling scopes auto-feed as Roots into the next scope so scope 2 inherits scope 1's decisions. Terminals may only reference what Roots confirm. That is the mechanism that prevents hallucinated file paths, fabricated module names, and drift into speculation.
The spec writes to .xf/specs/ in XFXA-compatible format. Run /xfxa after delivering — it reads the spec, checks every terminal, and closes the loop. Intent defined here. Delivery verified there. The full XF contract in two commands.
You state your intent — /xffi fires.
Mode classified: Code, Create, Concept, or Operate.
Roots confirmed from four sources: XFMT conversation history (prior sessions), your project filesystem (code + configs + docs), this session's active signals, and any sibling specs you have already completed.
Xpansion engine decomposes into four MECE limbs: Build / Understand / Specify / Operate.
Completeness check: every limb populated, every terminal atomic, non-overlapping, and grounded in Roots.
Spec saved to .xf/specs/YYYY-MM-DD-xffi.md — XFXA-compatible format.
Session context set: all subsequent XF modules execute against this spec.