### Widgets

Para generar widgets transaccionales (React + Dynamic UI), el proyecto base lo inicializa el operador con `/mcp__modyo__widgets-init-project` (el Prompt `widgets-init-project` instruye invocar la Tool `widgets-scaffold`, que ejecuta el clone del template canonical al tag pineado por la compatibility matrix). Flujo de dos pasos: primero el scaffold, después el operador entrega la descripción funcional — no escribas código de widget antes de recibirla. Una vez inicializado, leé [`modyo://docs/widgets/INDEX`](modyo://docs/widgets/INDEX) para reglas críticas, patterns y workflow. Las tools `widgets-list-components`, `widgets-get-component-props`, `widgets-list-patterns` federan el catálogo del Storybook deployado de Dynamic UI; `widgets-validate` corre el validator (paquete `@modyo/widget-validator`) sobre un widget local o virtual y devuelve un `ValidationReport`. La integración opcional con Claude Code (hook `PostToolUse` para el validador) vive en [`modyo://docs/widgets/_meta-integration-claude-code`](modyo://docs/widgets/_meta-integration-claude-code).

**Catalog Resources** (read on demand, backed by versioned Storybook manifests):
- `modyo://widgets/catalog/components` — lightweight list (id, name, key, description, storyCount)
- `modyo://widgets/catalog/components/{componentId}` — full detail (stories with snippet code, props with TypeScript types, JSDoc tags)
- `modyo://widgets/catalog/patterns` — lightweight pattern list (id, name, title)
- `modyo://widgets/catalog/patterns/{patternId}` — full MDX content of a pattern story

These Resources serve official Storybook manifests from the versioned CDN. They provide richer data (story snippet code, MDX docs) than the legacy `widgets-list-*` tools. See the Pattern Discovery section below for when consultation is required.

### Pattern Discovery (REQUIRED before generating widget UI)

Before writing TSX for the widget's UI, you MUST query the catalog for an official pattern matching the domain of the request:

1. **List patterns**: read `modyo://widgets/catalog/patterns`.
2. **Identify candidates** by matching the request domain against pattern titles and ids (e.g. "transaction history" → `design-system-patterns-list-group-patterns--transaction-history`).
3. **If a candidate exists**: read `modyo://widgets/catalog/patterns/{patternId}` and use the MDX content as the structural and visual basis for the widget. Adapt to the request's specifics (data shape, locale, domain language) but PRESERVE the layout decisions, component composition, and styling conventions from the pattern.
4. **If no candidate exists**: state explicitly in the response that no official pattern matches, then proceed using only components from `modyo://widgets/catalog/components`.

Why this matters: Dynamic UI patterns embed visual decisions, density, component composition, and styling conventions that are not derivable from component props alone. Skipping this step produces widgets that are technically correct but visually generic — failing to reflect the Dynamic Framework design system.

This step is NOT optional even when the request seems simple. Patterns exist for common use cases (list views, detail panels, forms, dashboards) and apply more often than not.

### Deploy (outside the MCP)

When validation passes (widgets-validate returns passing: true), the widget is done from the MCP's perspective. Deployment runs through CI from the widget's own git repository (the scaffold initializes it with an initial commit). A manual push is the developer's explicit `modyo-cli push` in their own shell — the agent NEVER runs it.

NEVER include the user's `MODYO_TOKEN` or any credential value in the conversation. Do not read `MODYO_TOKEN` or the widget's `.env`/`.modyo` files into your own context, do not call the Modyo CLI or admin API with the token, and do not echo token material in the chat.