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** — <https://eve.dev/integrations> (50+ MCP/OpenAPI connections, 11+ channels, official extensions). If the service is there, wire the connection/channel and stop — don't port. (`eve-agent` → Connection / Channel.) 2. **An extension package** — a versioned npm bundle you install and `pnpm up` (`agent/extensions/<name>.ts`). (`eve-agent` → Extension.) 3. **Port / vendor from a public registry** — *this skill*. Use it when there's **no** official integration or maintained package **and** you need to own/modify the source. You take on tenant-hardening **and** maintenance by hand. 4. **Hand-write** from scratch — when nothing exists to borrow (`eve-agent` boilerplate). Go down a rung only when the o