Workspace + Feature: Why Two Dimensions Beat One
Most tools collapse everything into a single timeline. We split the world into a workspace dimension and a feature dimension — and the boundary is what makes confirmation-driven automation possible.
When you live in a codebase long enough, you start noticing that some changes touch the whole system — and some only touch one slice of work in progress. Both feel like "edits," but they have completely different blast radii.
Fabriq makes that distinction explicit at the data layer: every artifact lives under one of two dimensions.
The two dimensions
- Workspace dimension — the long-lived home for documentation, repo metadata, knowledge, and audit history. Lives under
docs/,repos/,.dapei/. Survives feature closure. - Feature dimension — the short-lived workspace for one unit of work. Lives under
features/<f>/. Closed and either merged back into the workspace or discarded.
Both dimensions are first-class on disk. The desktop shell renders them as distinct surfaces, and every capability call declares which dimension it operates on.
Why it matters
A capability that mutates a workspace asset cannot run inside a feature checkout without the user noticing — the shell enforces that. A capability that operates on a feature cannot accidentally promote into the workspace until you explicitly close the feature through the close wizard.
"If you can't see where the change will land, you can't make a confident click."
That sentence is the entire reason Fabriq ships two dimensions instead of one. Confirmation gates only work when the target of an action is visible and unambiguous.
What's next
In the next post we'll look at how the AI Scanner + Engine Validator model — covered in the CDR design doc — uses those two dimensions to keep evidence honest while LLM agents extract business rules.
Related articles
AI Scanner, Engine Validator: Why We Don't Ask LLMs to Count Lines
Pure static analysis is brittle. Pure LLM analysis hallucinates. Fabriq's third path draws a clean line: Tree-sitter and ASTs answer 'where is X called?' deterministically; LLMs answer 'why is X called?' with fuzzy reasoning. The orchestrator ties them together with evidence chains that are auditable by construction.
Cursor vs Fabriq: Why Agent-Agnostic Architecture Wins
Most AI coding tools lock you into one agent. Fabriq's agent-agnostic architecture works with OpenCode, Claude Code, or any ACP-compatible backend — and the protocol is more important than any single model vendor.
Local-First vs Cloud-First: Why AI Dev Tools Should Run on Your Machine
The AI coding industry trends toward cloud-hosted agents. Fabriq goes the other way: local-first, offline-capable, putting data sovereignty and team control above convenience. Here's the reasoning behind that bet.