eve-registry-portinglisted

# eve-registry-porting — borrow the bricks, not the agent The eve ecosystem has spawned **"shadcn for agents"** registries — you copy source, not a dependency. They are a great **catalog + code mine**. But their unit of distribution is a **standalone agent** (one eve project that runs itself on a cron or from Slack), which is the **opposite** of a multi-tenant app where **one interpreter wears profiles from a DB** and delegates in a hierarchy. So the rule is: **port the components (tool / connection / skill), never the agent-as-a-runtime**, and rewrite each one to be tenant-safe. ## Where porting sits — the sourcing priority Porting is **third choice**, not first. Before vendoring third-party source, prefer a maintained option higher up the list: 1. **eve's official integrations** — discover + install from the CLI: **`eve registry search <cap>`** → **`eve add <kind>/<name>`** (catalog at <https://eve.dev/integrations> — 50+ MCP/OpenAPI connections, 11+ channels, official extensions). If the service is there, install and stop — don't port. (`eve-agent` → §Install from the registry FIRST / Connection / Channel.) 2. **Install a third-party registry as a source** — the community registries below are **shadcn-registry format**, so you can register one as an eve source (**`eve registry add @name=https://…/r/{name}.json`**, stored in `package.json#registries`) and pull with **`eve add @name/<slug>`**. That's an *install* (files written, dep tracked) — prefer it over porting whe