A Feature's Journey: From Idea to Ship in Fabriq

TL;DR. What does it actually look like to build a feature in Fabriq? This post follows a fictional feature — "Add order search to the admin panel" — through the full five-stage pipeline. Each stage shows what the human does, what the agent does, and what artifacts get produced. By the end, you'll have a concrete mental model of how Fabriq's workspace shell orchestrates AI-assisted feature delivery.

---

The feature#

Feature name: Admin Order Search

One-liner: Allow admin users to search past orders by order ID, customer email, or date range.

Why it's a Feature: It can be shipped independently (a new page in the admin panel), verified independently (manually searchable), and observed independently (search usage metrics).

Stage 1: 现状分析 (Current State Analysis)#

What happens#

The human opens the Feature Workbench and initiates the feature. Fabriq creates a new feature worktree under features/admin-order-search/ with the standard directory structure:

features/admin-order-search/
├── docs/           # Stage documents
├── context/        # Runtime context for the agent
├── memory/         # Decision records
├── tasks/          # Task breakdowns
├── reports/        # Validation and review
├── repos/          # Code checkouts
└── feature.yaml    # Feature manifest

The engine's first job is to understand the current state: what exists, what doesn't, what the relevant code looks like.

What the agent does#

The agent scans the existing admin panel codebase and produces:

• A list of existing admin routes and their patterns
• The order database schema (or API response shape)
• Authentication and authorization patterns for admin endpoints

What the human sees#

The Feature Workbench shows a progress indicator for Stage 1, with a preview of the generated analysis document. The human can review the analysis, ask the agent follow-up questions, and approve the stage before moving on.

Key insight: The agent does the exploration. The human reviews the findings. No information leaves the workspace unless explicitly configured.

Artifact produced#

features/admin-order-search/docs/01-analysis.md — a structured document covering:

• Current admin panel routes and conventions
• Order data model (fields, relationships, access patterns)
• Search infrastructure status (any existing search, database indexing, API endpoints)
• Gaps and opportunities

Stage 2: 方案设计 (Solution Design)#

What happens#

With the current state documented, the human and agent collaborate on the solution design. The agent proposes approaches; the human evaluates trade-offs.

What the agent does#

The agent reads the analysis document and proposes two approaches:

Approach A: Database-level search

• LIKE queries on orders table with indexes
• Simple, minimal new code, works for small datasets
• Degrades at scale (100k+ orders)

Approach B: Dedicated search index

• Add MeiliSearch or Elasticsearch
• Complex setup, better at scale, search-relevant features (fuzzy matching, faceted search)
• Overkill for current volume (estimate: 15k orders)

What the human does#

Reviews both approaches, agrees that Approach A is the right call for current scale, but adds a requirement: the search interface should be designed so that switching to Approach B later doesn't require a frontend rewrite (repository pattern, abstracted query layer).

Artifact produced#

features/admin-order-search/docs/02-solution-design.md

Stage 3: 技术设计 (Technical Design)#

What happens#

The agent writes a detailed technical specification based on the chosen approach. This is the blueprint the implementation will follow.

What the agent does#

Produces:

• Route design: GET /admin/orders/search?q=&from=&to=
• Controller logic: validate params → call search service → format response
• Service layer: OrderSearchService with pluggable query implementation
• Frontend: search form + results table component
• Test plan: unit tests for service, integration test for endpoint, E2E test for UI
• Testability specification (testability.md): input/output contracts, edge cases

What the human verifies#

• Does the design account for pagination?
• Are error states handled (empty results, invalid date range, DB timeout)?
• Does the design match the existing admin panel patterns?

Artifact produced#

features/admin-order-search/docs/03-technical-design.md + features/admin-order-search/testability.md

Stage 4: 开发实现 (Implementation)#

What happens#

The agent implements the feature against the design specification. Every state-changing operation goes through a confirmation gate.

The confirmation flow#

When the agent wants to create a file, it doesn't just write it. The capability call surfaces in the workbench:

The agent wants to create: src/routes/admin/orders/search.ts
Estimated impact: new file, ~45 lines
Dependencies: OrderSearchService, pagination middleware

The human reviews the payload and clicks Approve or Reject. The same flow applies to every mutation — file creation, dependency addition, configuration change.

What the agent does#

Implements each piece of the design:

1. Creates the search service with the query interface
2. Creates the controller and route handler
3. Creates the frontend search component
4. Writes unit tests and integration tests

What the human does#

Reviews accumulated changes at natural checkpoints. Runs tests locally to verify correctness. Gives high-level direction ("use optimistic UI for the search results" or "add debounce to the search input").

Artifact produced#

Working code in the feature worktree, plus features/admin-order-search/tasks/ tracking progress against the design spec.

Stage 5: 验证验收 (Verification & Acceptance)#

What happens#

The feature is complete. Before it can be closed, it must pass verification gates.

The verification pipeline#

1. Code review. feature.review capability analyzes the diff against the design spec. Are there any deviations? Unplanned changes? Missing test coverage?

2. Validation run. The test suite executes. Unit tests, integration tests, and (if configured) API-level smoke tests or browser-based E2E tests. Results recorded in features/admin-order-search/reports/validation-report.md.

3. Gate check. The workflow.gate capability confirms all prerequisites:

   • All stages completed
   • Code review passed (no blocking items)
   • Validation run passed
   • Design spec deviations documented and approved

The close wizard#

With gates passed, the human initiates the Close Wizard — a structured promotion ceremony:

1. Summary. The agent drafts a feature summary: what was built, what was decided, what remains unaddressed.
2. CMR (Cognitive Merge Request). The engine proposes knowledge updates for the workspace — new behaviors, state machines, or business rules extracted from the feature's code. Each proposal has sources[] linking back to the code.
3. Human approval. The human reviews each CMR proposal and approves or rejects. Only approved proposals are written to the workspace baseline.
4. Feature archiving. The feature directory is archived to docs/feature-history/admin-order-search/. The worktree is cleaned up.

Artifact produced#

docs/feature-history/admin-order-search/
├── links.yaml          # Cross-references to related features
├── summary.md           # What was built and why
├── index.md             # Feature index entry
├── .state.json          # Close pipeline state
└── cmr/                 # Approved cognitive merge requests

The end state#

Once the feature is closed:

• The code is in the main branch (via the feature's git workflow — merge or PR).
• The knowledge is in the workspace knowledge base (via CMR approvals).
• The audit trail is in .dapei/audit/ — every capability call logged.
• The history is in docs/feature-history/ — readable months later.
• The workspace is clean — no orphaned state, no stale worktrees.

The next feature starts from a workspace that knows what the last one learned.

What this means for a team#

The five-stage pipeline enforces a rhythm:

• Discovery is documented — not lost in a Slack thread.
• Design is explicit — not implied by the code.
• Implementation is transparent — every mutation is reviewed.
• Verification is systematic — no "ship and pray."
• Knowledge is preserved — the next feature starts smarter.

Each stage gates the next. You can't start implementation without an approved design. You can't close without passing verification. The pipeline replaces process overhead with structure — the stages are the process.

---

Fabriq is open source. Download it and try the five-stage pipeline yourself, or read the capability spec for the full implementation details.