Glossary
Key terms used throughout Fabriq — what they mean and why they matter.
ACP (Agent Communication Protocol)
The stdio JSON-RPC bridge that connects Fabriq to an agent backend (OpenCode or Claude Code). One agent process, multiple UI surfaces — Fabriq sends typed capability calls, the agent executes, Fabriq surfaces the results. Why it matters: any ACP-compatible agent works with Fabriq. → Connecting Agents
Agent Backend
The AI coding agent Fabriq communicates with — currently OpenCode or Claude Code. You install one on your machine, configure it in Fabriq, and the ACP bridge handles the rest. Why it matters: your choice affects cost, capabilities, and setup complexity. → Agent Setup Guide
Capability
A named, typed operation that goes through Fabriq's IPC layer — e.g., feature.create, validation.run, agent.injectContext. Every user action maps to a capability. All capabilities are observable and auditable. Why it matters: capability availability depends on engine mode — if a button is greyed out, check the mode. → Engine Modes
CDR (Cognitive Derivation & Reverse Engineering)
A pipeline that scans your source code and extracts structured knowledge — behaviors, business rules, state machines, evidence. The output is a navigable knowledge graph for both humans and agents. Why it matters: agents can query the cognitive index instead of re-scanning the codebase every time. → CDR Overview
Confirmation Gate
A UI prompt that surfaces before any state-changing action executes. Shows the target file, dimension, payload, and expected effect. Three choices: Approve, Reject, or Skip. Why it matters: this is Fabriq's core differentiator — nothing hits disk without your approval. → Confirmation Gates
Dimension
The surface context of an operation — workspace (long-lived shared assets) or feature (short-lived worktree). Every capability call is tagged with its dimension. Cross-dimension writes are rejected by the engine. Why it matters: prevents the agent from accidentally modifying shared docs while working on a feature. → Two Surfaces
Engine Mode
Controls which capabilities are available. Modes: Stub (mock responses for UI dev), Inline (same process, full feature set), Subprocess (separate process, production mode), Local (all capabilities on local machine). Why it matters: if a feature button is greyed out, your engine mode is the first thing to check. → Engine Modes
Feature
A unit of work for the AI agent — from a small bug fix to a multi-file feature. Lives in an isolated git worktree with its own docs, tests, and reports. Has a lifecycle stage (Design → Implement → Review → Close). Why it matters: everything the agent does happens inside a feature. → Feature Lifecycle
Feature Workbench
The main UI cockpit for working on a feature. Shows the pipeline stage, activity log (real-time agent actions), changes panel (files modified), and confirmation queue (pending approvals). Why it matters: this is where you spend most of your time in Fabriq. → Creating Features
Gate (Stage Gate)
A deterministic check triggered when advancing a feature to the next stage. Verifies prerequisites — doc existence, testability completeness, validation results. If a prerequisite is missing, the gate blocks advancement with a specific error message. Why it matters: gates enforce process without blocking you — you can see exactly what's missing. → Stage Gates
Knowledge Boundary
An HTML comment header embedded in markdown files that declares the document's dimension, scope, write permissions, and forbidden paths. Used by the agent to understand where it can and cannot write. Why it matters: it's the runtime contract between agent and workspace — violating it blocks the agent. → Injecting Context
Stage
One phase in the feature lifecycle. Fabriq uses stages: Analysis (Current State) → Solution Design → Technical Design → Implementation → Validation → Review → Close. Each stage has doc requirements and gate checks. Why it matters: progress is binary — you can't skip from design to validation without passing the intervening gates. → Feature Lifecycle
Worktree
A git worktree add — a physically isolated working directory for a git branch. Fabriq creates one for each feature, branching from the base repo. Changes in one feature's worktree never affect another. Why it matters: worktree isolation is the guarantee that agent actions are contained and reversible. → Workspace vs Feature
Workspace
The root directory Fabriq manages — contains .dapei/, docs/, repos/, features/. The structured contract between Fabriq, your team, and your agent. Why it matters: everything starts with a workspace. Without one, Fabriq can't operate. → Workspaces
Workspace Browser
The main launch screen showing both surfaces: workspace assets (docs, repos) on one panel, features (active worktrees) on the other. Entry point for creating features, browsing knowledge, and managing repositories. Why it matters: this is the first screen you see when you launch Fabriq. → Workspaces
Next steps
- Start with Your First 15 Minutes to see these concepts in action
- Read Workspace vs Feature for the deepest concept
- Browse Creating Features for a hands-on guide
Last updated on