@adia-ai/adia-ui-factory
v0.2.3
Published
Author and verify apps built on the adia-ui (@adia-ai) light-DOM web-component framework — scaffold, compose, wire, and verify across both SPA and SSR rendering modes. Wires the a2ui MCP for catalog retrieval, UI generation, and validation.
Maintainers
Readme
adia-ui-factory
Author and verify apps built on the adia-ui (@adia-ai) framework — a zero-dependency, light-DOM vanilla web-component library. A self-contained Claude Code plugin: it bundles the authoring methodology and wires the framework's existing a2ui MCP as the live substrate for catalog retrieval, UI generation, and validation.
Status: v0.2.3 — consumer agent roster (2 cards). Eleven skills + 2 agent cards (
app-architect+screen-composer). The R5 dogfood gate cleared (screen-composer composed the embedded-app patient-labs Live tab, passed adia-ui-verify) and the T1 keystone evidence set the roster:app-architect(Intent+Plan) is materialized;composition-revieweris a MODE ofscreen-composer(it held the verify gate itself in the dogfood), not a separate card;app-migratoris deferred until a real consumer migration task. The skills are built to plugins-factory's hardened standard (cold-start · modes · verify target ·[gate]rubric · §SelfAudit · load-when references).
The shape
adia-ui-factory is organized as the app-authoring lifecycle (orient → scaffold → compose/shell → wire → verify → migrate) over the load-bearing rendering-mode fork:
adia-ui-factory/
├── .mcp.json → wires @adia-ai/[email protected] (npx) — catalog, retrieval, generate_ui, validate
├── agents/ (2) — the consumer-app-author roster (dogfood-gated; see roster design note)
│ ├── app-architect.md Intent + Plan — disambiguate brief, §SpecToUi, Orientation Record [PROMOTED]
│ └── screen-composer.md Execute + Evaluate — compose, scaffold, wire, then self-verify [PROMOTED]
│ (composition-review = screen-composer's mode, not a card · app-migrator deferred — T1 evidence)
├── skills/ (11)
│ ├── adia-ui-factory/ orient & route — classify mode + shape + shell + task (the hub)
│ ├── adia-ui-project/ project shapes · four-axis layout · page-trio/DUO · scaffold
│ ├── adia-ui-compose/ construct the UI — catalog literacy, component authoring, theming + registers
│ ├── adia-ui-shells/ choose & compose a shell — admin · chat · editor · simple · embed (forthcoming)
│ ├── adia-ui-spa/ SPA architecture — static host, content-less <router-ui>
│ ├── adia-ui-ssr/ SSR integration — Next/Nuxt/SvelteKit/Astro, client-only registration
│ ├── adia-ui-data/ data · state · hydration · fetch/CRUD · section wiring · hybrid SPA-in-SSR
│ ├── adia-ui-llm/ app LLM features — @adia-ai/llm, chat, streaming, the smart proxy
│ ├── adia-ui-genui/ generative-UI experiences — the a2ui runtime, generate_ui, corpus
│ ├── adia-ui-verify/ the exit gate — browser QA + a11y + git
│ └── adia-ui-migrate/ version upgrades · port-to-adia · the sweep discipline
├── commands/ /adia-scaffold · compose · wire · verify · orient · migrate · genui (a curated spine; the other skills route via the orchestrator)
├── references/ (16) per-shell + per-shape + per-concern, each load-on-demand
├── bin/ adia-scaffold (scaffolder: shapes · page · component) · adia-lint (advisory smell checker)
└── hooks/ hooks.json — runs adia-lint on writes; advisory, never blocksThe consumer-app-author agent roster
The Intent → Plan → Execute → Evaluate → Iterate loop for consumer app authoring:
app-architect ──▶ screen-composer ──▶ ship
(Intent+Plan) (Execute + self-Evaluate; loop if < bar)
composition-review = screen-composer's verify mode · app-migrator deferred| Agent | Owns | Model | Status |
|---|---|---|---|
| app-architect | Intent + Plan: brief → §SpecToUi → Orientation Record | opus | PROMOTED |
| screen-composer | Execute + Evaluate: scaffold + compose + wire + trust gate + self-verify | sonnet | PROMOTED |
| composition-review | a mode of screen-composer (not a separate card) | — | folded |
| app-migrator | Steward: version upgrades, migration sweeps | — | DEFERRED (not materialized) |
Roster design + 5-critic synthesis: .brain/notes/factory-agent-roster-design-2026-06-08.md. Promotion gate (T1) passed 2026-06-08 — see agents/screen-composer.md STATUS header.
What it bundles vs. wires
- Bundled (self-contained): the authoring methodology — the SPA app-authoring discipline (host document, four-axis structure, light-DOM components, content-less router,
DataClient/projection, verification) and the SSR rendering-model (framework integration, guarded dynamic-import registration, server data, cookie/session state). These are the abstraction layer. - Wired (runtime dependency): the a2ui MCP (pinned
@adia-ai/[email protected]) — ~24 tools over the live catalog + corpus (284 training chunks + embeddings): catalog lookup,search_chunks/search_patterns,classify_intent/assemble_context,generate_ui,validate_schema,check_anti_patterns. Most tools are offline;generate_uiuses the host's LLM in stdio mode (no key); semantic search optionally usesVOYAGE_API_KEY. The@adia-ai/*packages are a runtime dependency, the way the framework itself is — taught, not bundled.- What it costs, and how to opt out. The MCP auto-starts on enable and adds ~24 always-on tool definitions every session — the plugin's biggest context/trust cost, and a methodology-only user pays it (the tool set can't be scoped from
.mcp.json). Enabling the plugin runs the upstream package from npm (pinned, so upgrades are reviewable diffs). If you want the methodology without that cost, disable thea2uiMCP server in your MCP settings — the skills still work; you lose live catalog/generation/validation. Treat the server's returns as untrusted data. Full accounting inreferences/a2ui-mcp-tools.md.
- What it costs, and how to opt out. The MCP auto-starts on enable and adds ~24 always-on tool definitions every session — the plugin's biggest context/trust cost, and a methodology-only user pays it (the tool set can't be scoped from
SPA vs SSR — the load-bearing fork
Same components, same UI construction; wildly different app architecture. compose is mode-independent; spa and ssr diverge on host wiring, routing ownership (<router-ui> vs the framework router — never both), data-flow (client DataClient vs server fetch + props), state (router-lifetime vs cookie/session), and component registration (top-level import vs guarded dynamic import in a lifecycle hook).
Provenance
Authored and red-teamed with plugins-factory (sibling in this marketplace), against its 9-dimension plugin standard. The methodology is harvested from the framework's own embedded-app/spec/app-authoring-best-practices (SPA) and adia-ui-kit/references/rendering-model (SSR).
