Tessera v0.1.0

Tessera v0.1.0

UI retrieval for coding agents. Search, inspect, and reuse real interface components from
existing UI libraries before generating them from scratch.

The problem

An agent asked to build a dark developer-tool hero will write one from nothing, while
aceternity/terminal and magicui/terminal sit two searches away. The components usually exist.
What is missing is a way for an agent to find them, judge them, check the licence, and get the
actual source.

What v0.1 proves

The local retrieval loop, end to end:

search  →  inspect  →  retrieve real source  →  adapt  →  cohesive page

Concretely: 73 components across five libraries, a deterministic search that explains every score,
and a fetch that returns real upstream files with their dependencies and licence — verified
against live upstreams, not fixtures.

npm publishing is pending. The @tessera-dev scope is reserved, and the release workflow
builds, checksums and smoke-tests the packages on every tag, but no package has been published
yet — so npx @tessera-dev/cli does not resolve. Install the tarballs attached below, or run
from source.

Install

From the tarballs attached to this release. Install all four at once — the CLI
depends on the other three, and none of them are on the registry yet, so npm
cannot resolve them from a single tarball:

npm install -g ./tessera-dev-registry-0.1.0.tgz ./tessera-dev-core-0.1.0.tgz \
               ./tessera-dev-mcp-0.1.0.tgz ./tessera-dev-cli-0.1.0.tgz
tessera doctor

Or from source:

git clone https://github.com/radityama/tessera && cd tessera
pnpm install && pnpm build
node packages/cli/dist/cli.js doctor

doctor checks the runtime, which registry is loaded, that every component validates, that licences
carry evidence, and that the MCP server starts.

Connect a coding agent

Once the packages are published, the command is:

npx -y @tessera-dev/cli mcp

Inevitably, that is the command that does not work yet. Until publishing completes, point the
harness at the binary you installed from the tarballs, or at the built source tree:

{
  "mcpServers": {
    "tessera": {
      "command": "tessera",
      "args": ["mcp"]
    }
  }
}

{
  "mcpServers": {
    "tessera": {
      "command": "node",
      "args": ["/path/to/tessera/packages/cli/dist/cli.js", "mcp"]
    }
  }
}

Six tools: search_components, get_component, get_component_artifact, get_installation,
find_similar_components, search_patterns. There is a page per harness in
docs/integrations/ for eleven
of them, each checked against that harness's own documentation. Claude Code is runtime-verified;
the rest are config-verified, and the compatibility matrix says which is which.

Supported sources

Source	Components	Retrieval	Licence
Aceternity UI	8	shadcn registry	Bespoke LicenseRef-Aceternity — redistribution restricted
beUI	15	shadcn registry	MIT
Efferd	20	shadcn registry	MIT where in the open-source repo, otherwise unknown
Magic UI	18	shadcn registry	MIT
HeroUI	12	npm package	MIT

What is safe by construction

• Tessera indexes metadata. It does not store or redistribute component source. Source is
  fetched on request and handed to you.
• Every licence carries an evidence URL, or is recorded as unknown. A known licence without
  evidence fails validation and the build.
• status and redistribution are recorded separately, because a licence can be known and still
  forbid reuse. Aceternity's is exactly that case.
• fetch never overwrites a file silently and rejects upstream paths that escape the output
  directory.
• Nothing is ever executed, written unprompted, or installed.
• No telemetry, no account, no network call during search.

Known limitations

These are deliberate for v0.1, not oversights:

• fetch does not resolve registry dependencies. A component that declares them — Efferd's
  hero-1 pulls in button, @efferd/header-1 and @efferd/logo-cloud-3 — returns its own
  files only. get_component_artifact reports the dependencies, and the shadcn CLI would install
  them transitively, but Tessera does not. This is the most likely way a first fetch disappoints,
  so it is stated up front rather than discovered. Resolving them means pulling in arbitrary
  transitive registry items, which is a bigger change than a bug fix.
• Declared dependencies can under-report actual imports. magicui/terminal imports motion,
  which its registry entry does not declare. Tessera records what the provider declares and does
  not infer the rest; the fetch output and the agent both have to notice. Known instance of a
  general problem with provider metadata.
• Curated source set. Five libraries, React only. Enough to prove the loop, not enough to be
  broadly useful.
• Lexical ranking. Deterministic and explainable, but not clever. A query naming several
  intents splits its budget across them rather than preferring components that satisfy more than
  one. No embeddings, no vector search.
• fetch is all-or-nothing. No merging into an existing project, no import-alias resolution.
• add never mutates. It prints a plan; v0.1 is dry-run only.
• Some components are not fetchable. HeroUI ships compiled through npm, and providers keep
  some items behind an account. Those are reported as unavailable rather than silently absent.
• One harness is runtime-verified. The other ten are configuration-verified only. Claiming
  more would be a guess.

Verified against live upstreams

Registry snapshots are generated by pnpm registry:sync from each provider's own registry.

Before tagging, the full loop was run against live providers by pnpm dogfood:

[1] search    → 5 ranked results for "dark technical terminal hero for a developer CLI,
                subtle motion"
[2] inspect   → magicui/terminal, MIT, redistribution permitted
[3] retrieve  → 7,716 bytes from https://magicui.design/r/terminal.json
[4] adapt     → supplied the host's cn() utility the component imports
[5] compile   → the retrieved component type-checks inside a real React project

It also surfaced the two metadata limitations above, which is the point of running it rather than
asserting the thesis in prose.

Release acceptance test

The final check was not a script. Claude Code was connected to Tessera over MCP and asked to find a
reusable component for a dark developer-tool landing page, with no hint about which one to pick. It
called search_components, get_component and get_component_artifact in sequence, then reported:

I chose magicui/terminal over the higher-scoring efferd/hero-* results because it directly
matches the need and carries a verifiable licence. […] MIT, redistribution permitted. […]
Metadata reports dependencies: [], but the source imports motion/react and @/lib/utils.
Adapt its demo styling to your own tokens rather than keeping the raw look.
Search results alone were not enough — the artifact is what surfaced the dependency mismatch.

That is the thesis working, including the parts that are easy to fake:

• it rejected the top-ranked results on licensing grounds, which is what the licence fields are
  for;
• it adapted rather than vendored, unprompted;
• it found the under-declared dependency from the retrieved source, not from metadata;
• it reported the limitation instead of failing silently.

A tool that returns efferd/hero-1 at rank 1 and stops would have produced a worse outcome here,
which is why score explanations and licence status are part of the result rather than a separate
lookup.

Full changelog

See CHANGELOG.md.