The @evestack registry

evestack ships as an eve registry in the shadcn registry-item format — the same mechanism eve add channel/slack uses for the official catalog.

eve registry add @evestack=https://raw.githubusercontent.com/SammyTourani/evestack/main/registry/r/{name}.json
eve add @evestack/memory

This is the reason evestack doesn't fork eve: anyone already running a vanilla eve init project can take exactly the piece they want.

Seven items, which is what registry/r/ contains. This table listed four for long enough that three shipped items were reachable only by guessing their names — derive it rather than trust it:

ls registry/r/          # every item, plus registry.json (the index)

Verified end to end against a stock eve init project: eve add @evestack/memory installs all four files at their correct targets — lib/memory.ts plus the remember, recall and forget tools — the installed content is byte-identical to what ships in templates/default (the build script inlines from the real, tested source rather than a maintained copy), and tsc --noEmit passes with no edits to package.json or tsconfig.json.

That verification was run against eve 0.29.5. templates/default now pins ^0.30.8, and @evestack/basic-auth requires >=0.30, so the recorded run is older than the code it describes. The CI gate below keeps the content honest; nobody has re-run the end-to-end install since.

That last part is the part that is easy to get wrong. A stock eve project maps only "#*": "./agent/*" and carries no tsconfig paths, and TypeScript's bundler module resolution ignores package.json imports outright — so an item whose files import each other through a #-subpath cannot be made to typecheck there without the user editing two files. The memory tools therefore import lib/memory.ts by relative path, in templates/default too, so the tested code and the shipped item are the same code.

Dependencies are pinned to the ranges templates/default is tested against, generated from that manifest at build time. @evestack/memory carries pg@^8.20.3, @ai-sdk/openai@^4.0.0 and ai-sdk-ollama@^4.1.0 — only what its own files import, not the template's whole dependency list, and the third is there because the memory tools take either embedding provider. A bare, unversioned name would resolve to whatever npm calls latest on the day you run it, and the pin is what stops an item installing a major version the code was never exercised against.

ai is deliberately not among them even though lib/memory.ts imports embed from it. Every eve project already depends on ai and carries an overrides entry pinning it, so an item that declared it directly would fail the install with EOVERRIDE rather than resolve.

This paragraph used to read @ai-sdk/openai@^2.0.0 and warn against ending up on v4. The repo moved to v4 deliberately (@ai-sdk/openai@4.0.30 made execution-denied a first-class tool result), so the warning had inverted into a caution against the current, tested state. Read the pin out of the item rather than out of this sentence:

node -e "console.log(require('./registry/r/memory.json').dependencies)"

Where the registry is hosted

The URL is raw.githubusercontent.com and not registry.evestack.dev because evestack owns no domain. evestack.dev is unregistered — it returns NXDOMAIN — so the branded URL that used to be documented here died with getaddrinfo ENOTFOUND on the first command a stranger ran. Serving the JSON straight off main costs nothing and works today.

If you ever buy evestack.dev, point it at registry/r/ and change the URL in the five places that carry it: this file, README.md, docs/channels/slack.mdx, docs/channels/telegram.mdx, and the example in the header comment of registry/build.mjs. (llms.txt links the docs by raw URL for the same reason, but those are docs pages, not registry items.) Nothing in the shipped code reads the registry URL — it only ever lands in a user's own package.json under registries, written there by eve registry add.

Two constraints on any replacement host, both read out of eve's registry client (eve/dist/src/cli/commands/registry-project.js and eve's bundled shadcn client):

• The URL must contain the literal {name} placeholder. eve registry add rejects the mapping outright otherwise, before it ever touches the network.
• The Content-Type does not matter. raw.githubusercontent.com serves these files as text/plain; charset=utf-8 and eve parses the body as JSON anyway; it reads content-type only on the error path, to pull a message out of a non-2xx response.

The one real cost of the raw URL is caching: GitHub sends cache-control: max-age=300, so a freshly pushed registry change can take up to five minutes to reach users.