Trust

Status and roadmap

What works today, the current limits, and the order in which the gaps close.

Current release: 0.1.0. The engine, CLI and Vault are tested end to end (extract → capture → add → doctor) on Linux, macOS and Windows. The Builder, Scanner and Worker work and you can use them, but they may still change.

What works today

Tool	Status	Notes
brico CLI	Available	extract, capture, list, search, add, upgrade, remove, doctor, publish, pull, diff
Terminal UI	Available	Browse, filter, details, doctor, extract
Vault	Available	Local git Vault, semver resolution, publish and pull through any git remote
Builder	Preview	Invite-only at builder.bricowerx.com; creates new Next.js bricks
Scanner	Preview	Load unpacked; Chrome Web Store review in progress
Worker	Preview	Local or Docker; needs Postgres and a Mistral key
MCP server	Planned	Part of the knowledge layer, now in progress
`brico create`	Planned	Project templates; not registered until a template produces a real project

Current limits

A tool that writes into your repository has to be predictable before it is impressive. Today:

brico add copies; it doesn’t compose. Wiring steps are printed, not applied.
Brick-to-brick dependencies aren’t resolved. bricoDependencies is recorded, but adding a brick won’t pull in the bricks it needs.
Imports aren’t adapted between projects. A captured module keeps its original aliases. Bricks avoid this by following the brick rules.
Scanning uses patterns, not a parser. Dynamic import() and destructured process.env are missed. The brick rules forbid both.
Hooks are recorded, not run. Manifest hooks will run behind an explicit allow-list.
The Builder only creates. Editing an existing brick through its spec isn’t supported yet.
Two frameworks. NestJS and Next.js, in TypeScript.

Security-relevant limits are listed separately in the security model.

Roadmap

Four phases, in this order:

Phase	Focus	What it adds
A · Now	Knowledge layer	Summaries written at capture, meaning-based search, and the MCP server
B	AI piece kinds	Prompts and agent skills captured and versioned like code
C	Accounting and graph	What was reused where, and what depends on what
D	Team scale	Shared Vaults, a review flow, and an optional hosted tier

Engine work across the phases

a real TypeScript parser in place of pattern matching, with no CGO, so the binary stays a single file;
content hashing, a brico.lock lockfile and drift detection;
resolving brick-to-brick dependencies;
adaptation seams, so a brick captured from an app using @/ installs cleanly into one using ~/, detected from the target’s own tsconfig.json;
wiring applied to your code instead of printed;
path confinement in add and remove, and authentication for the Worker bridge;
a public registry with mandatory @scope/name names and signed, reproducible releases;
more adapters: Express, Fastify, Hono, Django, Spring and others.

Versioning

BricoWerx follows semantic versioning. From 1.0.0, the manifest schemaVersion, the brico.json and brico.lock formats, and the registry API are covered by it: breaking any of them needs a major version. The engine and the Scanner share a version line, but their patch numbers can differ because store review runs on its own schedule.