zugzbot 1.3.0 → 1.5.0

package/.opencode/agents/sdd-coder.md

@@ -62,7 +62,7 @@ Eres el Programador de Código (sdd-coder) del arnés SDD. Tu trabajo es codific
 
 <f2_implementation>
   <bootstrap_obligatorio>
-    **Acción Inicial (Bloqueante)**: Antes de codificar, debes leer `.openspec/active-brief.md` (o `.opencode/active-brief.md` si existiera) y el archivo de diseño `.openspec/DESIGN.md` (o el `.openspec/design-assets/<brandId>/DESIGN.md` activo) para asimilar todos los requerimientos, contratos de la iteración y las guías estéticas de diseño en tu contexto.
+    **Acción Inicial (Bloqueante)**: Antes de codificar, debes leer `.openspec/active-brief.md` (o `.opencode/active-brief.md` si existiera) y el archivo `.openspec/DESIGN.md` activo para asimilar todos los requerimientos y contratos de la iteración. El arnés ya no inyecta marcas externas: el tema base es `shadcn-zinc` nativo del template `nextjs-shadcn/src/app/globals.css`.
     1. **Verifica Estado**: Si indica `Bootstrap Status: OK`, salta directamente al paso 4.
     2. **Detecta Stack**: Next.js/React (`sdd_bootstrap_nextjs_shadcn`), FastAPI/Python (`sdd_bootstrap_fastapi`) o Agnostico/Scripting (`sdd_bootstrap_agnostic`).
     3. **Ejecuta Bootstrap**: Llama a la herramienta del stack instalando dependencias (con `install: true` y `force: false`). Para `sdd_bootstrap_agnostic`, indica el `language` adecuado (ej: `google-apps-script`, `python`, `javascript`, `bash` o `plano`).
@@ -91,11 +91,11 @@ Eres el Programador de Código (sdd-coder) del arnés SDD. Tu trabajo es codific
 </f2_implementation>
 
 <coding_cheatsheet>
-- **Linear/Brand tokens**: Los tokens se inyectan en `globals.css` vía CSS vars. PROHIBIDO reescribir `globals.css` desde cero o usar colores Hex manuales en componentes. Usa variables como `var(--color-brand-primary)`.
+- **Tokens de tema**: Los tokens viven en `globals.css` vía CSS vars (`--background`, `--foreground`, `--primary`, etc.). PROHIBIDO reescribir `globals.css` desde cero o usar colores Hex hardcodeados (`bg-white`, `text-black`) en componentes. Usa siempre variables semánticas (`bg-background`, `text-foreground`, `border-border`).
 - **Estado**: Declara estados centralizados con `useState` en el componente padre (`owner` o `AppLayout`) y pásalos como props. Evita declarar estados compartidos en hijos.
 - **Instalación de Shadcn Segura**: La herramienta de shadcn a utilizar en F2 es `npx shadcn@latest add <componentes>` (o simplemente `npx shadcn add`). Utiliza siempre la última versión final estable de Shadcn para garantizar la compatibilidad con Tailwind v4 y permitir la descarga de bloques complejos de la comunidad y del registro oficial (como dashboards, sidebars y formularios modernos) sin errores 404.
 - **Next.js & Tailwind v4 Style Resolution**: En Tailwind v4, si `globals.css` importa `@import "shadcn/tailwind.css";`, debes asegurarte de instalar el paquete ejecutable `shadcn` ejecutando `npm install shadcn` o el compilador fallará.
-- **PROHIBIDO SOBREESCRIBIR GLOBALS.CSS (Preservación del Tema Shadcn)**: Tienes ESTRICTAMENTE PROHIBIDO sobreescribir el archivo `globals.css` a mano borrando sus variables. Si necesitas alterar colores o aplicar el estilo de una marca, usa OBLIGATORIAMENTE la herramienta `sdd_design_apply_brand_tokens`. Si el contrato dice diseño "default" o "Shadcn", NO TOQUES el CSS original. Borrar las variables semánticas rompe los componentes de Shadcn.
+- **PROHIBIDO SOBREESCRIBIR GLOBALS.CSS (Preservación del Tema Shadcn)**: Tienes ESTRICTAMENTE PROHIBIDO sobreescribir `globals.css` borrando sus variables semánticas. El tema `shadcn-zinc` del template ya provee todas las vars necesarias para claro/oscuro. Si necesitas custom tokens, agregarlos en un bloque nuevo al FINAL del archivo (después del `@theme inline` original) sin tocar las vars existentes. Borrar las vars originales rompe los componentes de Shadcn.
 - **Next.js Auth Redirects robustas (Evitar bucles/parpadeo)**:
   - Usa siempre `router.replace("/")` en lugar de `push` para redirecciones de login.
   - Para evitar efectos concurrentes o solapados en Strict Mode, usa un `useRef(false)` en redirecciones asíncronas para dispararlas solo una vez.
@@ -105,7 +105,8 @@ Eres el Programador de Código (sdd-coder) del arnés SDD. Tu trabajo es codific
 </coding_cheatsheet>
 
 <design_standards>
-  - **Alineación con DESIGN.md e Instanciación de Bloques**: Lee obligatoriamente `.openspec/design-assets/<brandId>/DESIGN.md` y asimila los layouts para recrear diseños premium con grids, sidebars y headers. Quedan prohibidos los MVPs de página flotante. Es **obligatorio** que si la vista requiere un dashboard, panel lateral, login o registro, utilices primero las herramientas MCP de Shadcn (`shadcn_search_items_in_registries` filtrando por `types: ["block"]`) para buscar bloques oficiales. Observa los ejemplos con `shadcn_get_item_examples_from_registries` y compón la vista. Distribuye y compón estos bloques prehechos enlazándolos con el backend en lugar de inventar la UI desde cero.
+  - **Diseño = `shadcn-zinc` por defecto**: El tema base viene del template `nextjs-shadcn/src/app/globals.css`. NO leas `.openspec/design-assets/<brandId>/DESIGN.md` (ese flujo está deprecado desde v1.4.0). Si el usuario pidió custom tokens en el contrato, agregarlos al final de `globals.css` sin tocar las vars originales.
+  - **Alineación con DESIGN.md e Instanciación de Bloques**: Para recrear diseños premium con grids, sidebars y headers, es **obligatorio** que si la vista requiere un dashboard, panel lateral, login o registro, utilices primero las herramientas MCP de Shadcn (`shadcn_search_items_in_registries` filtrando por `types: ["block"]`) para buscar bloques oficiales. Observa los ejemplos con `shadcn_get_item_examples_from_registries` y compón la vista. Distribuye y compón estos bloques prehechos enlazándolos con el backend en lugar de inventar la UI desde cero.
   - **Uso Obligatorio del MCP de Shadcn (Cero Alucinaciones)**: Tienes PROHIBIDO alucinar o inventar la API, las props o los subcomponentes requeridos de los componentes de Shadcn (especialmente en componentes compuestos como Select, Tooltip, Dialog, DropdownMenu). Antes de escribir el código que use estos componentes, DEBES usar la herramienta `shadcn_get_item_examples_from_registries` para ver la implementación real, los imports exactos y su composición obligatoria.
   - **Self-audit pre-transición (BLOQUEANTE)**: Antes de entregar, ejecuta este bloque en una sola corrida de terminal. Si el linter o el tipado TypeScript fallan, debes corregirlos antes de transicionar (el test suite completo queda delegado al Tester en F3 para ahorrar tus turnos):
     ```bash

package/.opencode/agents/sdd-orchestrator.md

@@ -38,7 +38,7 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
 - **Stack UI Exclusivo**: Toda interfaz de usuario debe usar únicamente **Shadcn UI**.
 - **Límite de `todowrite`**: Llama a `todowrite` MÁXIMO 2 veces por sesión: al inicio para crear la lista de fases y al final para marcar todo completado en bloque. No lo actualices en cada transición.
 - **Modo de Verificación ("Console" vs "Visual")**: Si es `console`, queda PROHIBIDO para ti y todos los subagentes usar Playwright o navegadores.
-- **Herramientas Específicas**: Usa siempre `sdd_list_design_recommendations` en vez de list-references directas, e inicia specs con `sdd_set_phase` (transacción atómica).
+- **Herramientas Específicas**: Inicia specs con `sdd_set_phase` (transacción atómica). El arnés ya no inyecta marcas externas: el default de diseño es `shadcn-zinc` nativo del template `nextjs-shadcn`.
 - **Ruta de Capturas**: Guarda cualquier screenshot de Playwright en `.openspec/ts-<nombre>.png`.
 - **Sistema de Memoria (Brain)**: Consulta el cerebro con `sdd_get_initial_session_data` al inicio (F0/F1) para entender el historial del proyecto. Guarda los aprendizajes clave al final en `<completion>` con `brain_save_memory`.
 - **Modo Autopiloto (`/loop`)**: Si se detecta `loopMode: true` o comando `/loop`, autotomará el 100% de las decisiones recomendadas por defecto. Tienes PROHIBIDO usar la tool `question` en autopiloto.
@@ -50,12 +50,13 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
     1. **Inicialización Atómica**: Llama obligatoriamente a `sdd_get_initial_session_data` para obtener estado, memorias e Oh-My-Design en un solo turno.
     2. **Brain Pre-carga (OBLIGATORIO)**: Inmediatamente después, invoca `brain_read_memory({ category: "learnings" })` y `brain_read_memory({ category: "errors" })` para extraer errores y lecciones históricas que prevengan repetir problemas conocidos. Guarda el resultado en una variable interna para inyectarlo en cada brief de subagente.
     2.5 **Detección de intención de catálogo externo (CRÍTICO — bugfix sesión 1176)**: Analiza la petición. Si contiene ALGUNA keyword de marketing/landing/auth/composite, animaciones/shaders/WebGL, AI components, o un nombre propio de cualquier catálogo:
-       - Keywords marketing/landing (shadcn): `hero`, `landing`, `pricing`, `features`, `faq`, `testimonials`, `footer`, `cta`, `navbar`, `stats`, `logo cloud`, `login page`, `signup page`, `forgot password`, `chart`, `sidebar`, `dashboard section`, `comparison`, `use cases`, `how it works`, `changelog`, `cookie banner`, `newsletter`, `bento`, `marquee`, `gallery`, `integration`
+       - Keywords marketing/landing (shadcn): `hero`, `landing`, `pricing`, `features`, `faq`, `testimonials`, `footer`, `cta`, `navbar`, `logo cloud`, `comparison`, `use cases`, `how it works`, `changelog`, `cookie banner`, `newsletter`, `bento`, `marquee`, `gallery`, `integration`
+       - Keywords forms/stats/tables (blocks-so): `form`, `formulario`, `stats`, `métricas`, `KPIs`, `tabla`, `data table`, `data grid`, `file upload`, `subir archivo`, `drag and drop`, `dialog`, `modal`, `command menu`, `command palette`, `onboarding`, `ai component`, `ai chat`, `grid list`, `login page`, `signup page`, `forgot password`
        - Keywords animaciones (reactbits): `shader`, `webgl`, `gsap`, `framer-motion`, `three.js`, `drei`, `animated background`, `animated text`, `gradient mesh`, `magnet`, `floating dock`, `cursor`, `particles`, `noise`, `orbit`, `aurora`, `dither`, `iridescence`, `blob`, `glare`, `staggered`, `magic bento`, `electric border`, `metallic paint`
-       - Nombres propios: `akash`, `akash3444`, `shadcnui-blocks`, `shadcn-ui-blocks`, `basecn`, `shadcn blocks`, `reactbits`, `react-bits`, `david haz`
-       - **Acción obligatoria**: cargar la skill `shadcn-templates` (que ahora referencia las tools MCP `sdd_catalog_list_blocks`, `sdd_catalog_get_block` y `sdd_catalog_warm_index` — NUNCA uses `webfetch` directo a GitHub/reactbits.dev; esta cacheado).
-       - En modo HIL: llama `sdd_catalog_list_blocks({category, limit: 5, registry: 'all'})` y presenta las 2-3 mejores opciones con `preview_url` para que el usuario elija. **Incluir siempre `preview_url` en la respuesta** — para reactbits el demo es animado y el usuario puede ver cómo se ve antes de instalar.
-       - En modo autopiloto (`/loop`): llama `sdd_catalog_get_block({name})` sobre 2-3 candidatos (uno de cada registry) y elige el que mejor encaje.
+       - Nombres propios: `akash`, `akash3444`, `shadcnui-blocks`, `shadcn-ui-blocks`, `basecn`, `shadcn blocks`, `reactbits`, `react-bits`, `david haz`, `ephraim`, `ephraimduncan`, `blocks.so`, `blocks-so`, `blocks so`
+       - **Acción obligatoria**: cargar la skill `shadcn-templates` (que ahora referencia las tools MCP `sdd_catalog_list_blocks`, `sdd_catalog_get_block` y `sdd_catalog_warm_index` — NUNCA uses `webfetch` directo a GitHub/reactbits.dev/blocks.so; esta cacheado).
+       - En modo HIL: llama `sdd_catalog_list_blocks({category, limit: 5, registry: 'all'})` y presenta las 2-3 mejores opciones con `preview_url` para que el usuario elija. **Incluir siempre `preview_url` en la respuesta** — para reactbits el demo es animado, para blocks.so es live en `https://blocks.so/<category>/<name>`, y el usuario puede ver cómo se ve antes de instalar.
+       - En modo autopiloto (`/loop`): llama `sdd_catalog_get_block({name})` sobre 2-3 candidatos (uno de cada registry) y elige el que mejor encaje. Prioriza `blocks-so` si la keyword cae en sus 11 categorías (stats, login, form-layout, file-upload, tables, dialogs, sidebar, command-menu, ai, onboarding, grid-list).
        - Esto evita el ciclo "ping-pong" de 3+ turnos que vimos en sesión 1176 donde el usuario tuvo que guiar al orquestador hacia el catálogo correcto.
     3. **Detección Fast-Track Dashboard (CRÍTICO — bugfix sesión 1186 y 1180)**: Analiza la petición del usuario. Si contiene ALGUNA de estas keywords: `dashboard`, `admin panel`, `panel de control`, `panel admin`, `crm`, `erp`, `panel`:
        - **NO preguntes NADA**. Asume todos los defaults: Stack = Next.js 16 + Shadcn UI + Tailwind v4, Persistencia = localStorage/mock, Diseño = `default` (zinc nativo de Shadcn, NO inyectar marcas de Oh-My-Design), Verificación = `console`.
@@ -142,7 +143,7 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
          - Anúnciala en 1 línea y delega la siguiente iteración completa a un NUEVO hilo `sdd-orchestrator` con contexto de 0 tokens.
        - Si `loopCurrentIteration >= loopTargetIterations` o modo normal: Concluye con `sdd_set_phase({ phase: "F0_DETECT", loopMode: false })`.
     2. **Brain save OBLIGATORIO**: Sintetiza 1-3 lecciones y regístralas con `brain_save_memory` (categoría: `learnings`, `errors`, `design` o `routing`). BLOQUEANTE — no omitir.
-    2.5 **Memory Post-Sesión para Catálogos (CRÍTICO — bugfix sesión 1176)**: Si la sesión tocó cualquier catálogo externo de UI (Akash shadcn-ui-blocks, basecn, reactbits.dev), registra OBLIGATORIAMENTE en `brain.routing`:
+    2.5 **Memory Post-Sesión para Catálogos (CRÍTICO — bugfix sesión 1176)**: Si la sesión tocó cualquier catálogo externo de UI (Akash shadcn-ui-blocks, basecn, reactbits.dev, blocks.so), registra OBLIGATORIAMENTE en `brain.routing`:
        - URL canónica del catálogo
        - Comando `npx shadcn@latest add <URL>` listo para usar
        - Nombre del autor/repo (para evitar redescubrimiento en próximas sesiones)
@@ -164,7 +165,7 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
 <mcp_guidelines>
 - **MCPs**: `shadcn` (UI), `context7` (APIs Next.js/FastAPI), `playwright` (Visual tests), `lucide-icons` (Iconos).
 - `next-devtools` deshabilitado por defecto. MCPs invocados exclusivamente por subagentes.
-- **Catálogos externos (Tools internas)**: `sdd_catalog_list_blocks`, `sdd_catalog_get_block`, `sdd_catalog_warm_index` — cachean el catálogo unificado (Akash shadcn-ui-blocks + basecn + reactbits.dev) en `.openspec/cache/` con TTL 7d (Akash/Basecn) y 1d (reactbits). NUNCA uses `webfetch` directo a GitHub o reactbits.dev para descubrir bloques; usa siempre estas tools. Solo se soportan registries con catálogo JSON oficialmente discoverable.
+- **Catálogos externos (Tools internas)**: `sdd_catalog_list_blocks`, `sdd_catalog_get_block`, `sdd_catalog_warm_index` — cachean el catálogo unificado (Akash shadcn-ui-blocks + basecn + reactbits.dev + blocks.so) en `.openspec/cache/` con TTL 7d (Akash/Basecn/blocks-so) y 1d (reactbits). NUNCA uses `webfetch` directo a GitHub o reactbits.dev para descubrir bloques; usa siempre estas tools. Solo se soportan registries con catálogo JSON oficialmente discoverable.
 </mcp_guidelines>
 
 <communication_rules>

package/.opencode/agents/sdd-spec-writer.md

@@ -25,7 +25,7 @@ Eres el Diseñador de Contratos (sdd-spec-writer) del flujo SDD. Tu único traba
 - **Solo Contratos y Diseño**: Tienes prohibido escribir código de aplicación (`.py`, `.ts`, `.tsx`, etc.). Solo generas el contrato en `contract.json` bajo la carpeta spec asignada y mantienes `.openspec/DESIGN.md`.
 - **Sin Carpetas Duplicadas**: Escribe siempre en la carpeta activa especificada en la tarea o en `activeContract`. No llames a `sdd_create_spec_folder` si ya existe.
 - **Sin Acciones de Orquestación**: Tienes prohibido pedir aprobación directa al usuario o usar `sdd_set_phase`.
-- **Restricción de Archivos**: El enforcer del arnés bloquea mecánicamente cualquier intento de escribir o modificar archivos fuera de la carpeta del spec actual, `.openspec/DESIGN.md` o `.openspec/design-assets/`.
+- **Restricción de Archivos**: El enforcer del arnés bloquea mecánicamente cualquier intento de escribir o modificar archivos fuera de la carpeta del spec actual y `.openspec/DESIGN.md`. El directorio `.openspec/design-assets/` ya no se usa (flujo deprecado desde v1.4.0).
 </constraints>
 
 <contract_structure>
@@ -49,12 +49,11 @@ Antes de declarar firmas de componentes o APIs externas en el contrato, **debes*
 </mcp_validation>
 
 <omd_reference_loading>
-**Diseño de Oh My Design (OBLIGATORIO)**: Si existe un `reference_id` activo en la tarea o en `.omd/init-context.json`, debes cargar la especificación utilizando la herramienta `get_design_md` del MCP `oh-my-design`.
-Extrae los tokens canónicos (paleta de colores, escala de bordes, tipografía, sombras) y embeberlos en el campo `tokens` dentro del `contract.json`. Esto garantiza el acoplamiento directo entre el contrato y `.openspec/DESIGN.md`.
+**Diseño por defecto = `shadcn-zinc`**: El arnés ya no carga marcas externas. El tema base es el del template `nextjs-shadcn/src/app/globals.css` (zinc nativo, modo claro/oscuro via variables CSS semánticas). NO declares `brandId` ni `designTokens` en el contrato a menos que el usuario haya pedido custom tokens explícitamente. En ese caso, agregalos al campo `design.tokens` como JSON inline (paleta, radios, fuentes) y el Coder los inyectará al final de `globals.css` sin tocar las vars originales.
 </omd_reference_loading>
 
 <design_standards>
-- **Alineación con DESIGN.md**: Debes leer obligatoriamente `.openspec/design-assets/<brandId>/DESIGN.md` para extraer los tokens de diseño. Basándote además en los ejemplos HTML interactivos (`preview.html`, `preview-dark.html`) correspondientes de la marca, define en el contrato los layouts exactos (sidebars, grids, headers) a implementar.
+- **Alineación con DESIGN.md**: El archivo `.openspec/DESIGN.md` activo contiene el estado del contrato actual. Si el usuario pidió custom tokens, declara el bloque `design.tokens` en el contrato. Si no, omítelo y deja que el Coder use el default `shadcn-zinc` del template.
 - **Diseño Premium y Bloques Shadcn**: El contrato debe instruir el uso de bloques prehechos oficiales de Shadcn (`dashboard-01`, `sidebar-01` al `16`, `login-01` al `05`, `signup-01` al `05`, etc.) mediante el skill `shadcn-templates` (Sección 3.1) alineado a la guía del `DESIGN.md`. Quedan prohibidos los MVPs de pantalla única flotante. El spec-writer debe usar proactivamente las herramientas MCP (`shadcn_search_items_in_registries`, `shadcn_list_items_in_registries`) para identificar qué bloques de tipo `registry:block` o `registry:ui` se adecuan a la necesidad y declararlos en `frontend.components` y `files_affected`.
 - **Escenarios de Test**:
   - Si `verificationMode === "console"`, genera únicamente escenarios de tipo `unit` o `integration` (entre 3 y 5 escenarios en total). No generes escenarios de tipo `visual` ni tests basados en browser.

package/.opencode/commands/loop.md

@@ -12,7 +12,7 @@ Estás ejecutando el ciclo SDD en modo **Autopiloto Autónomo** para resolver la
 ## Instrucciones de Autopiloto Obligatorias:
 1. Activa inmediatamente el modo piloto en el estado llamando a `sdd_set_phase` pasándole `phase: "F1_CONTRACT"`, un `spec_name` descriptivo en kebab-case, `loopMode: true`, `loopTargetIterations: N` (si el usuario ingresó un número en su comando, ej: `/loop 3` o `iteraciones=3`; por defecto 1), y `loopCurrentIteration: 1`.
 2. Tienes estrictamente prohibido usar la herramienta `question` para pedir confirmaciones de diseño, stack o contratos.
-3. Elige los valores recomendados por defecto de forma autónoma (Next.js 16, Console mode, primer diseño recomendado por la marca en oh-my-design).
+3. Elige los valores recomendados por defecto de forma autónoma (Next.js 16, Console mode, diseño `shadcn-zinc` nativo del template).
 4. No te detengas en las verificaciones humanas (HIL): asume la aprobación si el linter y los tests pasan satisfactoriamente.
 5. Registra de forma proactiva tus hallazgos, decisiones e iteraciones en el Brain (`brain_save_memory`).
 6. Al finalizar cada ciclo en `<completion>`, si `loopCurrentIteration < loopTargetIterations`, autoevalúa el producto, propón exactamente una (1) mejora clave de UX/UI o usabilidad, e inicia automáticamente el siguiente ciclo de mejora regresando a `F0_DETECT` / `F1_CONTRACT` incrementando `loopCurrentIteration`. No desactives `loopMode` hasta llegar a la última iteración.

package/.opencode/plugins/loop-enforcer.ts

@@ -231,7 +231,6 @@ export const LoopEnforcerPlugin: Plugin = async ({ project, client, $, directory
           const isAllowedSpecWriterFile =
             targetFilePath.includes(".openspec/specs/") ||
             targetFilePath.includes(".openspec/DESIGN.md") ||
-            targetFilePath.includes(".openspec/design-assets/") ||
             targetFilePath.endsWith("contract-schema.json")
 
           if (!isAllowedSpecWriterFile) {

package/.opencode/plugins/sdd-bridge.ts

@@ -452,7 +452,7 @@ export const SddBridgePlugin: Plugin = async ({ project, client, $, directory, w
         }
         // Live-refresh the canonical _sessions.jsonl so future sessions
         // can read compact history (1 line per contract) instead of full MD exports.
-        if (input?.tool === "sdd_set_phase" || input?.tool === "sdd_select_design" || input?.tool === "sdd_create_spec_folder") {
+        if (input?.tool === "sdd_set_phase" || input?.tool === "sdd_create_spec_folder") {
           try {
             const metrics = readMetrics()
             const state = readState()

package/.opencode/rules/sdd-global.md

@@ -33,14 +33,18 @@ Para optimizar el tiempo de desarrollo, garantizar una experiencia visual premiu
   - **Preservación de Datos Dummy**: El archivo de datos del bloque (por ejemplo, `data.json` o constantes locales) debe mantenerse intacto en su ruta inyectada por la CLI en esta Fase A para garantizar que la vista se muestre de inmediato en el navegador exactamente idéntica al demo real.
 - **Sustitución Atómica de Datos en Fase B**: Una vez que el bloque compila e interactúa en el navegador de manera idéntica al demo con los datos de ejemplo, el Coder procederá de forma exclusiva a sustituir los datos mock por lógica y fetchings de datos dinámicos del backend, manteniendo intactos los contenedores estructurales del bloque (grids de diseño, paddings y contenedores flex) sin alteración alguna para evitar aberraciones visuales.
 - **Resolución Activa de Conflictos de Ruteo por Inyección de Bloques**: Si la CLI de Shadcn inyecta automáticamente una estructura de rutas (ej: `src/app/dashboard/page.tsx`) que compite con las rutas del contrato (como un route group `(dashboard)` o una ruta raíz), el Coder **debe** borrar o refactorizar de inmediato el código inyectado por defecto para evitar bucles de redirección infinitos o colisiones en el router.
-- **Catálogo Unificado `sdd_catalog` (3 registries, todos discoverables)**: Antes de inventar cualquier layout/bloque desde cero, el Spec-Writer (F1) y el Coder (F2) **deben** consultar `sdd_catalog_list_blocks({ registry: "all", category: "<cat>" })`. El catálogo cubre 3 fuentes con catálogo JSON oficial en un solo tool:
-  1. **`shadcn`** (akash3444/shadcn-ui-blocks, GitHub Contents API) — ~540 bloques Radix/Next.js curados. **Default** para marketing, landing, auth, dashboards, footers.
+- **Catálogo Unificado `sdd_catalog` (4 registries, todos discoverables)**: Antes de inventar cualquier layout/bloque desde cero, el Spec-Writer (F1) y el Coder (F2) **deben** consultar `sdd_catalog_list_blocks({ registry: "all", category: "<cat>" })`. El catálogo cubre 4 fuentes con catálogo JSON oficial en un solo tool:
+  1. **`shadcn`** (akash3444/shadcn-ui-blocks, GitHub Contents API) — ~540 bloques Radix/Next.js curados. **Default** para marketing, landing, hero, pricing, features, faq, testimonials, footer, cta, navbar, logo-cloud, bento, marquee, comparison, use-cases, how-it-works, changelog, cookie-banner, newsletter.
   2. **`basecn`** (akash3444/basecn, GitHub Contents API) — ~60 bloques fork Base UI. Usar solo si el proyecto está en Base UI.
   3. **`reactbits`** (reactbits.dev, `/r/registry.json` oficial shadcn-compatible) — 134 primitivas animadas × 4 variantes (JS-CSS/JS-TW/TS-CSS/TS-TW, default `TS-TW`). **Fuente preferente** para backgrounds animados, textos con efecto, cards interactivas, cursors custom, dock flotante. Tratar como third-party trust: revisar siempre el campo `dependencies` (suelen incluir `gsap`, `three`, `@react-three/fiber`, `motion`) y validar compat con el stack target antes de instalar.
+  4. **`blocks-so`** (ephraimduncan/blocks, GitHub Contents API sobre `/content/components/`) — 60+ bloques Radix prod-ready con `categories[]` explícito en cada JSON. **Default** para sus 11 categorías: `stats` (15 vars), `login` (9 vars), `form-layout` (5 vars), `file-upload` (6 vars), `tables` (5 vars), `dialogs` (12 vars), `sidebar` (6 vars), `command-menu` (3 vars), `ai` (5 vars), `onboarding` (7 vars), `grid-list` (3 vars). MIT license, autor Ephraim Duncan (1.7k⭐). Para `sidebar` y `login` hay empates con shadcn — el orquestador prefiere blocks-so y solo consulta shadcn si el usuario lo pide explícito o si la categoría quedó sin resultados.
   - **Criterio de inclusion**: solo se soportan registries con catálogo JSON oficialmente discoverable. 21st.dev fue removido porque su catálogo es JS-rendered y rompe el principio de "siempre saber qué hay disponible antes de elegir".
-  - El comando install siempre viene en el campo `install_command` del resultado de `sdd_catalog_get_block`. **Prohibido** ejecutar `npx shadcn add` con una URL adivinada; usar siempre el `install_command` literal que devuelve la tool.
-  - El catálogo guarda caché local en `.openspec/cache/` con TTL diferenciado (7d shadcn/basecn, 1d reactbits) — **NUNCA** usar `webfetch` directo a GitHub o reactbits.dev, está cacheado.
-  - Todos los items exponen `preview_url`. Para reactbits el demo es animado vivo (`https://reactbits.dev/<BaseName>`) — el orchestrator debe **siempre** presentar el `preview_url` al usuario en modo HIL para que vea cómo se ve antes de elegir.
+  - El comando install siempre viene en el campo `install_command` del resultado de `sdd_catalog_get_block`. **Prohibido** ejecutar `npx shadcn add` con una URL adivinada; usar siempre el `install_command` literal que devuelve la tool. Formatos válidos por registry:
+    - shadcn/basecn: `npx shadcn@latest add https://shadcnui-blocks.com/r/radix/<name>.json --yes` o `https://basecn.dev/r/<name>.json`
+    - reactbits: `npx shadcn@latest add https://reactbits.dev/r/<Name>-TS-TW.json --yes`
+    - blocks-so: `npx shadcn@latest add https://blocks.so/r/<name>.json --yes` (o `@blocks-so/<name>` si `components.json` del proyecto lo tiene declarado).
+  - El catálogo guarda caché local en `.openspec/cache/` con TTL diferenciado (7d shadcn/basecn/blocks-so, 1d reactbits) — **NUNCA** usar `webfetch` directo a GitHub o reactbits.dev, está cacheado.
+  - Todos los items exponen `preview_url`. Para blocks.so el preview es live (`https://blocks.so/<category>/<name>`); para reactbits también (`https://reactbits.dev/<BaseName>`). El orchestrator debe **siempre** presentar el `preview_url` al usuario en modo HIL para que vea cómo se ve antes de elegir.
 
 ## 4. Soporte para Subdirectorios, Monorepos (targetDir) y Estándar Corporativo `src/`
 Si el proyecto o aplicación principal vive en un subdirectorio (ej. `next-app`, `frontend`, `backend`), se deben seguir estas directivas estrictas para mantener la consistencia y el "estándar corporativo con carpeta `src/`":

package/.opencode/scripts/lint-charts.js

@@ -39,8 +39,7 @@ const IGNORE_DIRS = new Set([
   "coverage",
   ".openspec/cache",
   ".openspec/__tests__",
-  ".opencode/templates",
-  ".opencode/oh-my-design"
+  ".opencode/templates"
 ])
 
 // Patrones prohibidos: cualquier chartConfig que envuelva una variable CSS

package/.opencode/skills/sdd-foundation-overview/SKILL.md

@@ -24,18 +24,17 @@ F4 → deployer genera Dockerfile + build + verify
 - **Stack**: Next.js 16 + Shadcn UI + Tailwind v4 (frontend), FastAPI + Pydantic (backend)
 - **Verificación**: `console` (5x más rápido que `visual`)
 - **Persistencia**: localStorage (mock frontend), SQLite (backend simple)
-- **Diseño**: primer recomendado por Oh My Design para la categoría del usuario
+- **Diseño**: `shadcn-zinc` nativo (default; sin marcas externas)
 
 ## Atajos críticos
 
 | Atajo | Ahorro |
 |---|---|
-| `sdd_list_design_recommendations({ use_case: "all" })` en F0 | 4 calls → 1 |
 | `sdd_set_phase({ phase: "F1_CONTRACT", spec_name: "..." })` atómico | Crea carpeta sin race |
-| `sdd_select_design({ brandId: "..." })` | Copia DESIGN.md |
 | `brain_read_memory({ category: ... })` en F0 y F3 inicio | Previene errores históricos |
 | Skill `sdd-quickstart` en F1 | Plantilla pre-rellenada (~1 min vs 3+ min) |
-| `sdd_apply_brand_tokens({ tokens: ... })` en F2 | Inyecta tokens sin romper shadcn |
+| `sdd_catalog_list_blocks({ registry: "all" })` en F1 | Lista shadcn/basecn/reactbits en 1 call |
+| `sdd_lucide_validate_lucide_icons_batch({ icons: [...] })` en F1 | Valida lote de iconos en 1 call |
 | `sdd_generate_dockerfile({ stack: "nextjs", port: 3000 })` en F4 | Genera 3 archivos en 1 call |
 
 ## Reglas duras

package/.opencode/skills/sdd-methodology/SKILL.md

@@ -35,23 +35,24 @@ Cada fase tiene un **gate explícito** (HIL del usuario) antes de transicionar a
 
 | Atajo | Cuándo | Ahorro |
 |---|---|---|
-| `sdd_list_design_recommendations({ use_case: "all" })` | F0 | 4 llamadas a `oh-my-design_list_references` → 1 |
 | `sdd_set_phase({ phase: "F1_CONTRACT", spec_name: "..." })` | F0→F1 | Crea la carpeta del spec atómicamente, sin race de timestamp |
-| `sdd_select_design({ brandId: "nike" })` | F0 | Copia DESIGN.md al path canónico `.openspec/design-assets/<brandId>/` |
 | `brain_read_memory({ category: ... })` | F0-F4 | Consulta el cerebro del proyecto para recuperar aprendizajes y evitar errores históricos |
 | `brain_save_memory({ category: ... })` | F2, F4 | Guarda aprendizajes, errores técnicos resueltos y decisiones de diseño en el cerebro |
 | Skill `sdd-quickstart` | F1 | Plantilla de `contract.json` pre-rellenada + test_scenarios recurrentes |
-| `sdd_apply_brand_tokens({ tokens: ... })` | F2 | Inyecta tokens de marca en `globals.css` sin romper variables shadcn |
+| `sdd_lucide_validate_lucide_icons_batch({ icons: [...] })` | F1 | Valida lote completo de iconos Lucide en 1 call (vs 1 por icono) |
+| `sdd_catalog_list_blocks({ registry: "all" })` | F1 | Lista candidatos de shadcn/basecn/reactbits en 1 call |
 | `sdd_generate_dockerfile({ stack: "nextjs", port: 3000 })` | F4 | Genera Dockerfile + .dockerignore + docker-compose.yml en 1 call |
 | `_sessions.jsonl` | Histórico | 1 línea por contrato (vs 18K+ líneas de MD export) |
 
+> **Diseño**: el arnés ya no inyecta marcas externas. El default es `shadcn-zinc` nativo del template `nextjs-shadcn`. Si el usuario quiere tokens custom, lo hace explícito en F2 con edición manual de `globals.css`.
+
 ---
 
 ## 3. Trampas del Flujo Maestro (EVITAR siempre)
 
-### Trampa 1: Listar marcas de diseño una por una
-**NO HAGAS**: Hacer múltiples llamadas a `oh-my-design_list_references` para mostrar opciones al usuario en F0.
-**HAZ**: Haz una única llamada consolidada a `sdd_list_design_recommendations({ use_case: "all", max_per_category: 3 })`.
+### Trampa 1: Preguntar marca de diseño al usuario en F0
+**NO HAGAS**: Preguntar al usuario "¿qué marca/diseño quieres?" o asumir tokens custom por defecto.
+**HAZ**: Asumir `shadcn-zinc` nativo. El template `nextjs-shadcn/src/app/globals.css` ya viene con todas las variables semánticas para tema claro/oscuro. El usuario puede pedir custom en F2 si quiere.
 
 ### Trampa 2: Crear la carpeta del spec en 2 steps
 **NO HAGAS**: Llamar a `sdd_create_spec_folder("mi-spec")` y luego a `sdd_set_phase("F1_CONTRACT", ...)` por separado (causa race conditions en el timestamp).
@@ -111,10 +112,7 @@ Cada fase tiene un **gate explícito** (HIL del usuario) antes de transicionar a
 │   ├── archive/                  # Contratos completados
 │   │   ├── _sessions.jsonl       # 1 línea por contrato (histórico compacto)
 │   │   └── <archived_specs>/
-│   ├── design-assets/<brandId>/  # ÚNICA ruta canónica de DESIGN.md
-│   │   ├── DESIGN.md
-│   │   ├── preview.html
-│   │   └── preview-dark.html
+│   ├── DESIGN.md                 # Resumen del spec activo (actualizado por sdd_save_active_brief)
 │   ├── .playwright/              # (transient, se borra en F0_DETECT)
 │   ├── sdd_state.json
 │   └── .sdd_session_metrics.json

package/.opencode/skills/sdd-quickstart/SKILL.md

@@ -36,9 +36,8 @@ Copia el siguiente JSON y rellena los huecos. Los campos sin `{{...}}` se mantie
     "persistence": "{{localStorage|sqlite|postgresql}}"
   },
   "design": {
-    "brand": "{{BRAND_ID}}",
-    "reference": ".openspec/design-assets/{{BRAND_ID}}/DESIGN.md",
-    "tokens": "{{PEGA_AQUI_LOS_TOKENS_EXTRAIDOS_CON_oh-my-design_get_design_md}}"
+    "system": "shadcn-zinc-default",
+    "tokens": "inherited from .opencode/templates/nextjs-shadcn/src/app/globals.css (zinc native)"
   },
   "stack": {
     "core": ["Next.js 16", "Shadcn UI", "Tailwind CSS v4", "{{PERSISTENCE}}"],
@@ -265,10 +264,8 @@ Para un dashboard o panel estándar, usa esta plantilla **reducida** de **~80 l
 ## 3. Anti-patrones a evitar en el contrato
 
 - **Inconsistencia de nombres de componentes (CRÍTICO)**: Los nombres declarados en `frontend.components[].name` del contrato son **un compromiso inmutable**. El spec-writer DEBE usar exactamente estos mismos nombres al crear las pruebas unitarias/integración, y el coder DEBE usarlos para crear los componentes de producción. **PROHIBIDO renombrar o cambiar de PascalCase a kebab-case en archivos de test**. Si el contrato dice `CalculatorPanel`, el archivo de test se llamará `CalculatorPanel.test.tsx` y no se debe cambiar a `CalculatorPage.test.tsx` (esto causó fallas de compilación con imports rotos en la sesión 1374).
-- **NO busques iconos uno por uno**: PROHIBIDO usar `lucide-icons_fuzzy_search_icons` de forma repetitiva en un loop para cada icono. Usa la herramienta optimizada por lotes `sdd_validate_lucide_icons_batch` pasándole todo el arreglo de nombres de iconos que desees usar en una sola llamada.
-- **NO uses `read` para DESIGN.md**: Para extraer los tokens de diseño de una marca, usa siempre `oh-my-design_get_design_md(brandId)` o lee selectivamente, no leas el archivo entero que consume miles de tokens de input innecesariamente.
-- **NO embebas código TSX en el contrato.** El contrato es declarativo (qué, no cómo).
-- **NO dupliques los tokens de `.openspec/design-assets/<brandId>/DESIGN.md` línea por línea.** Usa el tool `oh-my-design_get_design_md` y pega el bloque `tokens` completo UNA vez.
+- **NO busques iconos uno por uno**: PROHIBIDO usar `lucide-icons_fuzzy_search_icons` de forma repetitiva en un loop para cada icono. Usa la herramienta optimizada por lotes `sdd_validate_lucide_icons_batch` (tool `sdd_lucide_validate_lucide_icons_batch`) pasándole todo el arreglo de nombres de iconos que desees usar en una sola llamada.
+- **NO embabes código TSX en el contrato.** El contrato es declarativo (qué, no cómo).
 - **NO escribas más de 5-6 `test_scenarios`** para modo `console`. Más de eso no acelera la entrega, solo retrasa F2.
 - **NO incluyas escenarios `visual` o `e2e` si `verificationMode` es `console`.** El tester los rechazará.
 - **NO omitas la disposición espacial y propuesta de Layout**: El spec-writer DEBE proponer un bosquejo textual o diagrama ASCII de la disposición espacial de la UI en F1 (ej. layouts con sidebar lateral para configuración o paneles complejos en lugar de simples pestañas tradicionales planas) y acordar anchos de pantalla generosos (`max-w-6xl` o superior, evitando el limitante `max-w-3xl`) con el usuario antes de transicionar a F2. Esto previene reestructuraciones estéticas costosas y asegura entregas de alta gama a la primera.
@@ -282,8 +279,7 @@ Para un dashboard o panel estándar, usa esta plantilla **reducida** de **~80 l
 [orchestrator] → sdd_set_phase({ phase: "F1_CONTRACT", spec_name: "..." })
 [spec-writer]  → skill sdd-quickstart       ← ESTA SKILL
 [spec-writer]  → read .opencode/contract-schema.json
-[spec-writer]  → oh-my-design_get_design_md(brandId)  (si aplica)
-[spec-writer]  → write .openspec/specs/.../contract.json (rellenando plantilla)
+[spec-writer]  → write .openspec/specs/.../contract.json (rellenando plantilla; design=shadcn-zinc-default)
 [spec-writer]  → sdd_set_phase({ phase: "F2_IMPLEMENTATION" })
 ```
 

package/.opencode/skills/shadcn-templates/SKILL.md

@@ -154,54 +154,58 @@ El `@sdd-coder` utiliza el template base `nextjs-shadcn`. Si el contrato no deta
 
 ## 5. Catálogo Unificado de Bloques Externos (`sdd_catalog`)
 
-Además del catálogo nativo de Shadcn UI, el arnés expone un catálogo unificado de **3 registries** externos (todos con catálogo JSON oficial y discoverable programáticamente). Si el usuario pide cualquier interfaz (hero, footer, dashboard, login, AI chat, animated background, etc.), **TIENES LA OBLIGACIÓN** de explorar este catálogo ANTES de inventar desde cero.
+Además del catálogo nativo de Shadcn UI, el arnés expone un catálogo unificado de **4 registries** externos (todos con catálogo JSON oficial y discoverable programáticamente). Si el usuario pide cualquier interfaz (hero, footer, dashboard, login, AI chat, animated background, stats, form, table, etc.), **TIENES LA OBLIGACIÓN** de explorar este catálogo ANTES de inventar desde cero.
 
 ### 5.0 Registries Soportados (todos discoverables)
 
 | Registry | Fuente de catálogo | Contenido | TTL | Notas |
 |---|---|---|---|---|
-| `shadcn` | akash3444/shadcn-ui-blocks (GitHub Contents API) | ~540 bloques Radix | 7d | **Default** para marketing/landing/auth/dashboards |
+| `shadcn` | akash3444/shadcn-ui-blocks (GitHub Contents API) | ~540 bloques Radix | 7d | **Default** para marketing/landing/hero/pricing/features/faq/testimonials/footer/cta/navbar/logo-cloud/bento/marquee |
 | `basecn` | akash3444/basecn (GitHub Contents API) | ~60 bloques fork Base UI | 7d | Alternativa si el proyecto usa Base UI |
 | `reactbits` | reactbits.dev/r/registry.json (JSON oficial shadcn) | 134 bases × 4 variantes = 536 items | 1d | Primitivas animadas (backgrounds, text, cards, cursors, etc.) |
+| `blocks-so` | ephraimduncan/blocks (GitHub Contents API sobre `/content/components/`) | 60+ bloques Radix con `categories[]` explícito en cada JSON | 7d | **Default** para `stats` (15), `login` (9), `form-layout` (5), `file-upload` (6), `tables` (5), `dialogs` (12), `sidebar` (6), `command-menu` (3), `ai` (5), `onboarding` (7), `grid-list` (3). MIT, Ephraim Duncan. |
 
 > **Criterio de inclusion**: solo se soportan registries con catálogo JSON oficialmente discoverable. 21st.dev fue removido porque su catálogo es JS-rendered y requiere scraping para descubrir items nuevos — eso rompe el principio de "siempre saber qué hay disponible antes de elegir".
 
 ### 5.1 Herramientas MCP Nativas del Arnés (PREFERENTE — `sdd_catalog_*`)
 
-**PROHIBIDO** usar `webfetch` directo a GitHub o reactbits.dev para descubrir bloques. El arnés expone 3 tools MCP dedicadas que cachean en `.openspec/cache/` y evitan redescubrimiento:
+**PROHIBIDO** usar `webfetch` directo a GitHub, reactbits.dev o blocks.so para descubrir bloques. El arnés expone 3 tools MCP dedicadas que cachean en `.openspec/cache/` y evitan redescubrimiento:
 
 - `sdd_catalog_list_blocks({ category?, query?, registry?, limit?, force_refresh? })`
-  - `registry`: `"shadcn"` | `"basecn"` | `"reactbits"` | `"all"` (default).
-  - Filtra por categoria exacta (`hero`, `pricing`, `backgrounds`, `text`, `cards`, `navigation`, ...) o substring libre (sobre `name`, `description`, `tags`).
+  - `registry`: `"shadcn"` | `"basecn"` | `"reactbits"` | `"blocks-so"` | `"all"` (default).
+  - Filtra por categoria exacta (`hero`, `pricing`, `backgrounds`, `text`, `cards`, `navigation`, `stats`, `login`, `form-layout`, ...) o substring libre (sobre `name`, `description`, `tags`).
   - Para `reactbits`: devuelve las **134 bases** (cada una con `variants[]` y `default_variant`), NO las 536 variantes. Esto evita duplicados y permite ver opciones de un vistazo.
+  - Para `blocks-so`: devuelve los **60+ bloques Radix** distribuidos en 11 categorías oficiales. La categoría se infiere del path del directorio GitHub (`content/components/<category>/`), no del nombre del archivo.
 - `sdd_catalog_get_block({ name, registry?, variant?, force_refresh? })`
   - Formatos de `name`:
     - shadcn/basecn: `"hero-06"`, `"sidebar-07"`
+    - blocks-so: `"stats-01"`, `"login-03"`, `"form-layout-02"`, `"ai-01"`, etc.
     - reactbits: `"Dither"` (auto-resuelve a `Dither-TS-TW` por default) **o** `"Dither-JS-CSS"` (variante canónica completa)
-    - URL directa: `"https://reactbits.dev/r/Dither-TS-TW.json"` o `"https://shadcnui-blocks.com/r/radix/hero-06.json"`
-    - Namespace shadcn: `"@acme/button"`
+    - URL directa: `"https://reactbits.dev/r/Dither-TS-TW.json"`, `"https://blocks.so/r/stats-01.json"` o `"https://shadcnui-blocks.com/r/radix/hero-06.json"`
+    - Namespace shadcn: `"@acme/button"` o `"@blocks-so/stats-01"` (auto-routing a blocks-so)
   - Para reactbits, parámetro opcional `variant`: `"JS-CSS" | "JS-TW" | "TS-CSS" | "TS-TW"` (default `"TS-TW"`). Aplicar solo cuando pasas el nombre base sin sufijo de variante.
   - `registry` autodetecta por el formato; pasalo explícito solo si necesitas forzar.
   - Devuelve `source_files[]`, `dependencies[]`, `preview_url`, `install_command` listo y metadatos `base_name` + `variant` (para reactbits).
 - `sdd_catalog_warm_index({ registry? })`
-  - Pre-calienta caches. Llamar al bootstrap (F0) o inicio de F1.
+  - Pre-calienta caches. Llamar al bootstrap (F0) o inicio de F1. Para `blocks-so` consume ~12 GitHub API calls (1 para categorias + 11 para listar archivos) — TTL 7d minimiza esto.
 
 ### 5.2 Flujo de Descubrimiento (Fase F1 - Spec-Writer)
 
 Cuando el usuario pide una UI, sigue este orden de prioridad:
 
-1. **Primero** `sdd_catalog_list_blocks({ registry: "all", category: "<categoria>", limit: 10 })` — devuelve candidatos de los 3 registries simultáneamente.
-2. **Si el usuario pide animaciones/shaders/efectos visuales cinematograficos**, prioriza `registry: "reactbits"` (es donde estan las primitivas animadas reales: `Dither`, `Aurora`, `GlareHover`, `Magnet`, `StaggeredMenu`, `FloatingDock`, etc.).
-3. **Si el usuario pide paginas de marketing completas** (landing, pricing, features), prioriza `registry: "shadcn"` (bloques Radix mas completos con texto, CTAs, imagenes placeholder).
-4. **Si el usuario ya dio una URL** (`https://reactbits.dev/...` o `https://shadcnui-blocks.com/...`), ve directo a `sdd_catalog_get_block` con esa URL.
-5. **Presenta opciones con `preview_url`** para que el usuario vea cada una antes de elegir:
+1. **Primero** `sdd_catalog_list_blocks({ registry: "all", category: "<categoria>", limit: 10 })` — devuelve candidatos de los 4 registries simultáneamente.
+2. **Si la keyword cae en las 11 categorías de blocks-so** (stats, login, signup, form-layout, file-upload, tables, dialogs, sidebar, command-menu, ai, onboarding, grid-list), prioriza `registry: "blocks-so"`. Es la fuente más actualizada y curada para esos casos de uso. Ejemplo: si el usuario pide *"un formulario de registro"*, el Spec-Writer debe ir directo a `sdd_catalog_list_blocks({registry: "blocks-so", category: "form-layout", limit: 5})` y mostrar las 5 variantes (`form-layout-01` a `form-layout-05`).
+3. **Si el usuario pide animaciones/shaders/efectos visuales cinematograficos**, prioriza `registry: "reactbits"` (es donde estan las primitivas animadas reales: `Dither`, `Aurora`, `GlareHover`, `Magnet`, `StaggeredMenu`, `FloatingDock`, etc.).
+4. **Si el usuario pide paginas de marketing completas** (landing, pricing, features, hero), prioriza `registry: "shadcn"` (bloques Radix mas completos con texto, CTAs, imagenes placeholder).
+5. **Si el usuario ya dio una URL** (`https://reactbits.dev/...`, `https://blocks.so/...` o `https://shadcnui-blocks.com/...`), ve directo a `sdd_catalog_get_block` con esa URL.
+6. **Presenta opciones con `preview_url`** para que el usuario vea cada una antes de elegir:
    - **Asistido (HIL):** muestra `preview_url` (que el usuario puede abrir en navegador) + `install_command` para los 2-3 mejores candidatos y deja que elija. Si el usuario dice "ese", ejecuta el `install_command`.
    - **Autopiloto (`/loop`):** inspecciona 2-3 candidatos con `sdd_catalog_get_block`, analiza dependencias y compat con el stack del contrato, elige autonomamente.
 
 ### 5.3 Seleccion de Bloques (Interactiva o Autonoma)
 
 Cuando hay multiples opciones para una categoria (ej. 10 heroes):
-- **Modo Asistido (default):** pregunta al usuario con `question` o en chat: *"Tengo X opciones de [categoria]. ¿Quieres revisar alguna? Puedo darte el `preview_url` (ej. `https://shadcnui-blocks.com/blocks/hero-06` o `https://reactbits.dev/Dither`) para que elijas."*
+- **Modo Asistido (default):** pregunta al usuario con `question` o en chat: *"Tengo X opciones de [categoria]. ¿Quieres revisar alguna? Puedo darte el `preview_url` (ej. `https://shadcnui-blocks.com/blocks/hero-06`, `https://blocks.so/stats/stats-04` o `https://reactbits.dev/Dither`) para que elijas."*
 - **Modo Autopiloto:** lee el codigo de 2-3 opciones con `sdd_catalog_get_block` y elige sin preguntar.
 
 ### 5.4 Inyeccion e Instalacion (Spec-Writer + Coder)
@@ -211,6 +215,7 @@ Cuando hay multiples opciones para una categoria (ej. 10 heroes):
   "frontend": {
     "components": [
       { "name": "hero-06", "registry": "shadcn", "source": "akash3444/shadcn-ui-blocks" },
+      { "name": "stats-01", "registry": "blocks-so", "source": "ephraimduncan/blocks" },
       { "name": "Dither", "registry": "reactbits", "variant": "TS-TW", "source": "reactbits.dev/Dither" }
     ]
   }
@@ -223,6 +228,10 @@ Cuando hay multiples opciones para una categoria (ej. 10 heroes):
   npx shadcn@latest add https://basecn.dev/r/footer-04.json --yes
   # reactbits (variante TS-TW explicita)
   npx shadcn@latest add https://reactbits.dev/r/Dither-TS-TW.json --yes
+  # blocks-so (ephraimduncan/blocks)
+  npx shadcn@latest add https://blocks.so/r/stats-01.json --yes
+  # blocks-so via namespace (requiere declararlo en components.json)
+  npx shadcn@latest add @blocks-so/stats-01 --yes
   ```
   La CLI v3 de Shadcn negocia `Accept: application/json` automaticamente, descarga el codigo y resuelve las `registryDependencies`.
 
@@ -263,8 +272,55 @@ reactbits.dev es el registry mas "vivo" del catalogo unificado. Cada componente
 | shadcn | `https://shadcnui-blocks.com/blocks/<name>` | iframe del demo oficial |
 | basecn | `https://basecn.dev/blocks/<name>` | iframe del demo oficial |
 | reactbits | `https://reactbits.dev/<BaseName>` | demo vivo con animacion real + codigo a la derecha |
+| blocks-so | `https://blocks.so/<category>/<name>` | demo vivo con el bloque real renderizado (sin animaciones) |
 
-Cuando el orchestrator presente opciones al usuario, **siempre incluir el `preview_url`** en el chat. Para reactbits en particular, el demo es animado y se ve inmediatamente cómo se mueve la UI en el navegador del usuario — esto cierra el ciclo "imaginar como se ve → ver real → decidir instalar" sin hacer conjeturas.
+Cuando el orchestrator presente opciones al usuario, **siempre incluir el `preview_url`** en el chat. Para reactbits y blocks-so el demo es interactivo y se ve inmediatamente cómo se ve en el navegador del usuario — esto cierra el ciclo "imaginar como se ve → ver real → decidir instalar" sin hacer conjeturas.
+
+### 5.8 blocks.so (ephraimduncan/blocks) - Detalles
+
+blocks.so es el registry más curado para interfaces funcionales: **60+ bloques Radix prod-ready** con `categories[]` explícito en cada JSON. La diferencia clave frente a akash es que cada bloque de blocks.so **incluye un `categories[]` array** dentro del JSON, lo que elimina la ambigüedad de la heurística por nombre de archivo.
+
+**Estructura del repo**:
+```
+ephraimduncan/blocks/
+  content/
+    components/
+      ai/              ai-01.tsx ... ai-05.tsx          (5 bloques)
+      command-menu/    command-menu-01.tsx ...          (3 bloques)
+      dialogs/         dialog-01.tsx ... dialog-12.tsx  (12 bloques)
+      file-upload/     file-upload-01.tsx ...            (6 bloques)
+      form-layout/     form-layout-01.tsx ...            (5 bloques)
+      grid-list/       grid-list-01.tsx ...              (3 bloques)
+      login/           login-01.tsx ... login-09.tsx    (9 bloques)
+      onboarding/      onboarding-01.tsx ...             (7 bloques)
+      sidebar/         sidebar-01.tsx ... sidebar-06.tsx (6 bloques)
+      stats/           stats-01.tsx ... stats-15.tsx     (15 bloques)
+      tables/          tables-01.tsx ... tables-05.tsx   (5 bloques)
+```
+
+**Campos clave del JSON de cada bloque**:
+- `name`: canonical (ej: `"stats-01"`)
+- `type`: `"registry:block"` (estándar shadcn)
+- `title`: `"Stats with Trending"`
+- `description`: `"A stats with trending block."`
+- `author`: `"ephraim duncan <https://ephraimduncan.com>"`
+- `registryDependencies`: ej: `["card"]` — el coder debe pre-instalar via `sdd_bootstrap` antes del `npx shadcn add`.
+- `dependencies`: ej: `[]` — paquetes npm necesarios (rara vez hay, son 100% Radix).
+- `files[]`: cada item tiene `path` (origen en el repo), `type` (`"registry:component"`) y `target` (ruta destino en el proyecto, ej: `"components/stats-01.tsx"`).
+- `categories[]`: ej: `["stats"]` — usado para filtrado.
+
+**Patrones de uso en el contrato**:
+```json
+{
+  "frontend": {
+    "components": [
+      { "name": "stats-01", "registry": "blocks-so", "source": "ephraimduncan/blocks" }
+    ]
+  }
+}
+```
+
+**Cuidado con `field` y `FieldGroup`**: algunos bloques de `form-layout` y `onboarding` usan el primitivo `field` (Field, FieldLabel, FieldDescription) que no viene por defecto en `npx shadcn add`. Si `sdd_catalog_get_block` lista `field` en `registryDependencies[]`, el coder debe correr `npx shadcn@latest add field` antes de instalar el bloque.
 
 ---
 

package/.opencode/templates/nextjs-shadcn/components.json

@@ -18,6 +18,7 @@
   },
   "iconLibrary": "lucide",
   "registries": {
-    "@react-bits": "https://reactbits.dev/r/{name}.json"
+    "@react-bits": "https://reactbits.dev/r/{name}.json",
+    "@blocks-so": "https://blocks.so/r/{name}.json"
   }
 }