Manifest-driven ingest
Assembly never hardcodes paths into a design system. A manifest.yaml in the corpus directory declares where things live and what they are, mapping paths to one of four doc types:
doc_type | What it tags |
|---|---|
component_doc | Prose documentation — usage guidance, props, examples |
component_source | The component implementation itself |
story | Usage examples / stories |
token | Design tokens — color, spacing, typography, etc. |
The doc type drives everything downstream: how chunks are ordered in get_component_docs (docs → source → stories), what get_design_tokens returns, and how results are labeled in search.
Pointing Assembly at a different design system is a new manifest, not a code change.
The manifest schema is documented in corpus/README.md in the repo.
What ships in the repo
Two corpora are bundled:
- shadcn/ui, pinned at
shadcn@4.13.0. The payload is cloned bymake corpusfrom the upstream repo and kept out of git; only the version pin is committed. The vendored corpus keeps its own MIT license. @halcyon/ui3.4.0 — a small, entirely fictional design system (38 files, 93 chunks) stored locally in the repo. It exists so retrieval can be benchmarked against a corpus no frontier model can possibly have memorized. See Evals & benchmarks.
Swapping in yours
- Put your corpus somewhere the ingest workers can read — a local directory (like halcyon) or a cloneable source (like shadcn/ui).
- Write a
manifest.yamlmapping its paths to the four doc types. - Run
make reingestto scan, chunk, embed, and index it.
Your agent’s answers now come from your components. Nothing in the retrieval stack, the MCP tools, or the generation pipeline changes.
Why a fictional corpus matters
Benchmarking retrieval against shadcn/ui is unconvincing: frontier models have seen it during training, so a “bare” model scores artificially well. Halcyon was invented specifically to remove that confound — if a model gets halcyon right, it’s because retrieval put the answer in context, not because it remembered the docs.