Build the product. Not the workbench.
LoomWeaver gives your product its entire workbench UI, panes, tabs, command palette and plugin store
included, without you building any of it. It is a domain-agnostic plugin and UI platform: your domain
UI is written as plugins ("weavers"), and a product is a thin distribution that composes them with
the published @loomweaver/* npm packages. You never need this repository to build one. The platform
is frontend-only; your product brings its own backend.
It speaks AG-UI as well, so an agentic backend that already talks that standard can run your product's own commands.
| You want to… | Start here |
|---|---|
| See it running first | the live demo at demo.loomweaver.dev: a product built on the published packages |
| Try it in five minutes | Getting started: scaffold a running, branded product |
| Understand how it works | Architecture, then the concept pages for why the workbench behaves as it does |
| Build a plugin (a "weaver") | Authoring a weaver, with copyable recipes in Samples |
| Compose and brand a product | Building a distribution |
| Use Bootstrap or your own CSS framework | Bringing your own CSS framework |
| Let an AG-UI agent drive your product | Driving your product with an AG-UI agent |
| Wire your own backend | Backend integration |
| Do something from your own code | Distribution API: indexed by "I want to …" |
| Look something up | the reference pages below |
- Getting started: scaffold a running, branded product with a plugin in it (~5 min).
- Architecture: the mental model. Platform, weaver and distribution, the uniform
ctx, default-deny capabilities, auth-aware access gating, the two RPC boundaries. Read it once the tutorial has run. - Manual setup: the same app wired by hand, plus the Nx, SSR and Module Federation answers (~15 min).
- Samples: complete, copyable recipes. A sidebar view with persisted state, a routable surface, a command with its triggers, a settings section, access gating, dialogs. It says which of them the generator already writes, so you only type the rest.
- Authoring a weaver: the shape of a weaver and the map of fifteen how-to pages
under
weaver/. Surfaces in a sidebar, the content area, containers, commands, menus, unsaved changes, sandboxed surfaces, access gating, settings, i18n. One task per page. - Building a distribution: the composition root and the map of seventeen
how-to pages under
distribution/. Layout, routing, workspaces, switching capabilities off, branding, capabilities, auth, persistence, your own CSS framework, frame plugins, the plugin store, PWA. One decision per page. - The plugin system: the three rungs of trust and the four ways a plugin arrives (trusted, frame plugin, operator-deployed, community-installed), default-deny capabilities, and what the user can revoke, disable or uninstall.
- Scaffolding: generate weavers, distributions and integrations with the
@loomweaver/clicommand line, the@loomweaver/devkitNx generators or the@loomweaver/mcpserver for AI assistants, all in your own repository. - Driving your product with an AG-UI agent: generate the AG-UI connection, watch a call go through, decide which calls to ask about, and replace the stand-in with your own transport.
- Backend integration: the product hand-off. Settings, session and translations against your own backend; the platform ships no server.
Why the workbench behaves as it does, each short, each linking to the how-to pages that act on it.
- Surfaces and panes: one contract for everything shown, and a pane as a tab group.
- The address: what the address bar means with several panes open.
- Retention and unsaved work: hiding is not closing, and who asks about unsaved work.
- Capabilities and trust: default-deny, the three rungs, and why access is not a capability.
- Workspaces: a whole way of working, its baseline, and its two origins.
- Distribution API: everything your product's own code may inject and call, indexed by intent. Switches, tabs, panes, workspaces, sidebars, dialogs, settings, commands, session, appearance, plugins at runtime, windows and sync, reset. Everything a user does by hand, your code can do too, with the same guards.
- Shell anatomy: the region vocabulary (rail / panel / bar / content) and docks a distribution declares.
- Access gating: the complete
accessreference. What gates where, identity changes, and why client-side gating is not a security boundary. - Routing: the content area is the Angular router. What carries over unchanged, where a route comes from, and the two places a surface is mounted off-router.
- Callable commands: opening a command to a caller that is not the
user. Described arguments, answers, the
automationcapability and why the default is closed. - Agent tools:
@loomweaver/ag-ui, letting an AG-UI agent reach the workbench's own commands, with a hook for confirming or declining a call before it runs. - Design tokens &
<lw-*>vocabulary: the semantic tokens and host UI building blocks to use in templates (never raw palette colours). - Icons: every icon name the workbench ships, with its glyph, and how a weaver or a distribution adds its own.
- Accessibility: the WCAG 2.1 AA guardrail the host meets and weavers inherit.
- Glossary: the words these pages use, and the four that name the same thing (platform, shell, host, workbench).
The per-symbol reference is the packages themselves: @loomweaver/plugin-sdk and @loomweaver/shell ship typed
declarations with JSDoc on every public member, which your editor shows in place. The pages above
cover the concepts; a repository check verifies that no published export is missing from them.
../llms.txt (curated map) and ../llms-full.txt (the full set,
inlined) let an assistant ingest everything needed to build a distribution.
- Operations: what bites when you run, edit or verify something here, and the guards that fail on it.
- Contributing: how work happens here, from fork and branch to the checks a pull request has to pass.