BricoWerxDocs
Docs menu

Tools

The Vault

How bricks are stored: a git directory of immutable, versioned snapshots that you can publish and share.

Available

The Vault holds every brick and every version of it. It is a local directory under git, with no server, no account and no database. Git is also how it is shared: publishing pushes it to a repository and pulling fetches it back.

Where it lives

The first match wins:

  1. the --vault <path> flag;
  2. the BRICO_VAULT environment variable;
  3. vaultPath in ~/.brico/config.json;
  4. the default, ~/.brico/vault.

Layout

~/.brico/vault
index.json                  searchable summary of every brick
auth/
  0.1.0/
    brico.manifest.json     the manifest for this snapshot
    auth.module.ts          the brick's files, exactly as captured
    auth.service.ts
  0.2.0/
    ...
waitlist/
  0.1.0/
    ...

Every snapshot is the brick’s files plus its manifest, so you can open, read or review any version with ordinary tools.

Guarantees

PropertyWhat it means
Immutable versionsA version, once stored, is never overwritten. Changing a brick means a new version.
Reproducible historyEvery capture is a git commit with a fixed author and date, so the same input gives the same history.
Self-healing indexindex.json is rebuilt from disk after every write. A hand-edited or git-merged Vault reconciles itself.
Offline firstNothing needs the network. Only publish and pull talk to a remote.

Sharing a Vault

Any git remote works. A private GitHub repository is the usual choice for a team.

bash
# one person: push the Vault and remember the repository
brico publish --repo git@github.com:acme/team-vault.git

# everyone else: fetch it
brico pull --repo git@github.com:acme/team-vault.git
brico list

# later
brico publish auth             # share one brick (all its versions)
brico diff                     # what have I changed locally?
brico pull                     # get what others published

Publishing one brick clones the target repository, overlays that brick’s versions, rebuilds the index so it includes what the repository already had, and pushes. Two people can therefore publish different bricks to the same repository without overwriting each other.

To keep a personal Vault and a team Vault apart, publish selected bricks with brico publish <brick> -l, or switch Vaults per command with --vault.

The Builder’s Vault

The hosted Builder keeps its own public Vault of the bricks it has generated. Browse it at builder.bricowerx.com, or read it as JSON:

bash
curl https://builder.bricowerx.com/api/bricks
response
{
  "bricks": [
    {
      "name": "desk-booking",
      "title": "Desk Booking",
      "summary": "Members reserve a desk for a day; admins approve or cancel.",
      "status": "ok",
      "layers": ["domain", "server"]
    },
    { "name": "timekit", "title": "timekit", "status": "legacy", "layers": ["domain"] }
  ]
}

status is ok (every operation implemented and verified), partial (some operations are typed stubs) or legacy (hand-made reference bricks).

Search today, and next

brico search matches names, descriptions and tags through index.json. The planned knowledge layer adds summaries written at capture time and meaning-based search through a local index that rebuilds from the Vault. It also powers the MCP server. The git directory stays the source of truth, and the index is a cache you can always delete.