Sheet B · Components & dependencies · Drawn by the-metafactory · MVP critical path

Blueprint

Two things share this name. One is what gets distributed. The other is what tracks how they fit together.

1 · A metafactory blueprint the noun

Per DD-85 in the meta-factory design-decisions log, "blueprint" is the collective noun for every component published via metafactory. A skill is a blueprint. A tool is a blueprint. A playbook is a blueprint. A set of rules is a blueprint.

The word does the work of seven specific types because the lifecycle is the same for all of them: scaffold, sign, submit, sponsor-review, publish, install, audit, upgrade. Calling them all blueprints names that lifecycle as the load-bearing structure — the artifact type is a detail underneath.

Every component published via metafactory is a blueprint. The word for one of them is the word for all of them.

What that means in practice

A repository on meta-factory.ai is a blueprint repository.
An arc-manifest.yaml declares the capability surface of a blueprint.
A blueprint can contain any of seven artifact kinds (skill, tool, agent, prompt, playbook, rules, process).
Trust tiers (NEW / IDENTIFIED / PROVEN / TRUSTED / STEWARD) apply to blueprint publishers, not to individual artifacts.

2 · The blueprint CLI renaming to `depend`

There is also a small CLI tool, currently named blueprint, that tracks cross-repo dependencies across the metafactory ecosystem. Because of DD-85, the CLI is being renamed to depend post-MVP — tracked in issue #41. Until then, docs disambiguate with the blueprint CLI versus a metafactory blueprint.

The blueprint.yaml filename does not change — only the CLI binary and repo name.

What it does

Reads blueprint.yaml files from each registered repo, resolves cross-repo references into a single directed acyclic graph, detects cycles, and answers the daily-work question: what is ready, what is blocked, and what unlocks what?

Hand-drafted technical illustration of a cross-repo tech tree. Three vertical column headers across the top: ARC, GROVE, MINER. Each column has feature nodes drawn as rounded rectangles with feature IDs and statuses. Dependency arrows cross between columns. The IN-PROGRESS feature G-500 in the GROVE column is drawn with a red outline to mark the frontier. A legend at the bottom-left maps box style to status (done = unlocked, in-progress = frontier, planned = locked). A red footnote reads 'Per metafactory DD-85, blueprint is the collective noun for every published component.' — FIG. B.0 — Cross-repo tech tree · features unlock when their prerequisites are done

Each repo declares its features

schema: blueprint/v1
repo: grove

features:
  - id: G-500
    name: Network routing
    status: in-progress
    iteration: 3
    depends:
      - G-200              # local dependency
      - arc:manifest-v2    # cross-repo dependency

Status values

┌──────────────┬───────────────────────────────────────┬──────────────┐
│ STATUS       │ MEANING                               │ SET BY       │
├──────────────┼───────────────────────────────────────┼──────────────┤
│ planned      │ Identified, not started               │ Manual       │
│ in-progress  │ Currently being worked                │ Manual       │
│ done         │ Completed and merged                  │ Manual       │
│ ready        │ All deps done, available to start     │ Computed     │
│ blocked      │ Has unmet dependencies                │ Computed     │
└──────────────┴───────────────────────────────────────┴──────────────┘

The four queries

blueprint ready     # what's available to work on across all repos
blueprint blocked   # what's waiting and what it's waiting on
blueprint status    # ecosystem health overview
blueprint tree      # ASCII dependency tree
blueprint lint      # validate every blueprint.yaml

Think of it like a tech tree in a strategy game — features "unlock" when their prerequisites are done. The frontier of unlocked features is what guides daily work.

The metafactory quartet

┌──────────────┬──────────────────────────────────────────────────┐
│ REPO         │ PURPOSE                                          │
├──────────────┼──────────────────────────────────────────────────┤
│ meta-factory │ Trusted marketplace for agentic components       │
│ grove        │ Event relay and multi-agent Discord bridge       │
│ arc          │ Agentic component package manager (the client)   │
│ blueprint    │ Cross-repo dependency tracking (this repo)       │
└──────────────┴──────────────────────────────────────────────────┘

How it fits the stack

myelin is the protocol stack. cortex is the surface. arc installs blueprints. metafactory hosts them. Blueprint, the CLI, keeps the people building those things honest about what depends on what.

It is the smallest tool in the quartet and the one that makes the other three buildable in parallel — without a shared dependency view, two teams happily build mutually-incompatible halves of the same feature.

Status & roadmap

Iteration 1 — graph parsing, DAG resolution, CLI queries. In flight.
Iteration 2 — interactive React Flow tech-tree dashboard. Future.
Iteration 3 — automated status sync and notifications. Future.
Rename to depend — post-MVP, per DD-85 and issue #41.

Open the blueprint repo ↗ Back to myelin →