LoomWeaver

Zero domain logic, on purpose

LoomWeaver gives you a plugin registry, extension points, a default-deny capability broker, a theming engine, sandboxing, RPC and a plugin loader — and nothing about your domain. Products run as plugin bundles (“weavers”) on top of it. The model follows VS Code, Backstage and Eclipse Theia: the core stays small because it cannot grow domain logic.

One contract for every plugin

A weaver consumes one uniform ctx from @loom/plugin-sdk. First-party and third-party plugins take the same path — there is no privileged host API.

Default-deny by construction

A plugin gets a capability only if the distribution granted it and the plugin declared it. Users can revoke what was granted, and untrusted plugins run in an isolated iframe.

Frontend-only platform

LoomWeaver ships no server. The backend seam is expressed as frontend ports — SettingsStore and AuthSource — that your own backend implements, in any stack.

Your product is a distribution

A thin app composes @loom/shell plus your weavers and brands itself. You never fork the core, the way VSCodium never forks VS Code.

Built for AI assistants too

The whole platform is described in two machine-readable briefs: a curated llms.txt entry point and a single-fetch llms-full.txt that carries the complete contract. The same scaffolding runs three ways: @loom/cli from any command line, @loom/devkit as Nx generators, and @loom/mcp as MCP tools — so an assistant in your repository can generate a weaver, a distribution or a sandboxed plugin without a LoomWeaver checkout.