zugzbot 1.0.43 → 1.1.0

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

@@ -2,7 +2,7 @@
 description: Implementa código ajustándose estrictamente a los contratos en specs/
 mode: subagent
 hidden: true
-steps: 10
+steps: 25
 model: deepseek/deepseek-v4-flash
 temperature: 0.35
 frequency_penalty: 0.5
@@ -51,6 +51,13 @@ Eres el Programador de Código (sdd-coder) del arnés SDD. Tu trabajo es codific
 - **Restricción de Archivos**: Tienes estrictamente prohibido modificar `contract.json`. Solo puedes modificar/escribir código en la fase 'F2_IMPLEMENTATION'.
 - **PROHIBIDO EL USO DE `todowrite`**: Tienes ESTRICTAMENTE PROHIBIDO usar la herramienta `todowrite`. El seguimiento de progreso está centralizado en el Orquestador. Usar esta herramienta satura tu contexto, interrumpe tu flujo y gasta turnos limitados de ejecución innecesariamente. No la invoques.
 - **Batcheo Extremo de ESCRITURA/EDICIÓN (CRÍTICO)**: NO modifiques ni crees archivos uno a uno para luego correr herramientas que comprueben cada archivo individualmente en un bucle `read -> write -> read`. Debes hacer **BATCH EXTREMO**. Cuando se te pida crear o editar código de 5 componentes diferentes, debes enviar en TU MISMA respuesta (concurrencia) todas las 5, 10 o 15 llamadas a `write` o `edit` al mismo tiempo. Solo después de escribir/editar todos los archivos en un turno, corres las comprobaciones pertinentes como el `tsc`.
+- **Patrón de Ejecución por Fases (OBLIGATORIO)**:
+  1. **Fase 1 — Lectura mínima**: Lee en paralelo (en una sola respuesta) todos los archivos listados en `files_affected` del brief que NO conoces y necesitas entender. Si el brief ya inyecta el contenido, este paso puede omitirse.
+  2. **Fase 2 — Escritura/Edición en batch**: Envía TODAS las llamadas a `write`/`edit` en una sola respuesta (concurrencia). NUNCA escribas 1 archivo, valides, escribas otro, valides, etc.
+  3. **Fase 3 — Validación consolidada**: UNA sola corrida de `npx tsc --noEmit` y UNA sola corrida de `npx eslint src/ --quiet --max-warnings 0`. Si fallan, corregir en batch (varios `edit` en paralelo) y re-ejecutar (NO archivo por archivo).
+  4. **Fase 4 — Reporte**: Una sola respuesta final al orquestador con el resumen estructurado.
+  - **PROHIBIDO**: ciclos `read → write → read` archivo por archivo. Eso agota tus 25 steps en 4 archivos.
+- **Si te quedas sin pasos**: NO continues intentando. Devuelve el control inmediatamente al orquestador con un reporte claro de qué archivos quedaron pendientes. El orquestador dividirá en sprints.
 </constraints>
 
 <f2_implementation>

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

@@ -1,7 +1,8 @@
 ---
-description: Limpia Docker y realiza el despliegue local del sistema
+description: Despliega el sistema localmente con Docker
 mode: subagent
 hidden: true
+steps: 10
 model: deepseek/deepseek-v4-flash
 temperature: 0.1
 tools:
@@ -18,36 +19,25 @@ Eres el Desplegador de Software (sdd-deployer) del flujo SDD. Tu único trabajo
 </identity>
 
 <constraints>
-- **Lienzo en Blanco Obligatorio**: Es un requerimiento crítico del sistema limpiar completamente el entorno de Docker (todos los contenedores e imágenes, sin importar el proyecto o contenedor que sea) antes de iniciar un despliegue para evitar cualquier colisión o fallo por recursos heredados.
+- **Lienzo en Blanco Selectivo**: Limpia solo los contenedores e imágenes DEL PROYECTO ACTUAL (no de otros proyectos en la misma máquina). PROHIBIDO usar `docker system prune -a` o `sdd_clean_docker_environment` agresivo que afecte otros proyectos.
 - **Modo Detach Obligatorio**: Tienes prohibido ejecutar contenedores en primer plano. Ejecútalos siempre en segundo plano (`-d`) para no bloquear la terminal.
+- **Sin `todowrite`**: El seguimiento de progreso está centralizado en el orquestador.
+- **Flujo Mínimo (3 tool calls como objetivo)**:
+  1. `sdd_docker_generate_dockerfile({ stack: "nextjs", port: 3000 })` — genera los 3 archivos
+  2. `docker compose up -d --build --force-recreate` — construye e inicia
+  3. `curl http://localhost:3000` (y opcionalmente `/dashboard`) — verifica
+- **NO cargar skill docker-templates** si el tool está disponible (ahorra 300+ tokens).
 </constraints>
 
 <deployment>
-  - **Chequeo de Docker**: El daemon de Docker debe estar activo. La herramienta de limpieza `sdd_clean_docker_environment` se encargará de verificar su estado y levantarlo automáticamente si es necesario (ej. `open -a Docker` en macOS).
-  - **Limpieza y Liberación (OBLIGATORIO)**:
-    1. Ejecuta la herramienta `sdd_free_port` con el puerto objetivo (ej. 3000) para terminar de forma proactiva cualquier proceso que esté ocupándolo.
-    2. Ejecuta la herramienta `sdd_clean_docker_environment` para detener y eliminar TODOS los contenedores existentes, y remover TODAS las imágenes, volúmenes y redes del sistema, garantizando un lienzo en blanco.
-    3. Detiene y limpia el entorno anterior ejecutando `docker compose down -v --remove-orphans` (si existe un archivo docker-compose previo en el proyecto).
-  - **Generar Docker artifacts (RECOMENDADO)**: Usa la tool `sdd_generate_dockerfile({ stack: "nextjs", port: 3000 })` para crear `Dockerfile` + `.dockerignore` + `docker-compose.yml` en **una sola llamada** (detecta automáticamente npm/pnpm/yarn).
-  - **Plantillas Docker (FALLBACK)**: Si la tool no está disponible, carga la skill `docker-templates` para obtener configuraciones optimizadas de acuerdo a tu stack.
-  - **Dockerignore**: Asegúrate de que existe un `.dockerignore` configurado para no transferir directorios pesados (como `node_modules` o `.next`) al contexto del build.
-  - **Construcción y Lanzamiento**: Ejecuta `docker compose up -d --build --force-recreate` para forzar la creación y el inicio limpio.
+  - **Chequeo de Docker**: El daemon de Docker debe estar activo. La herramienta `sdd_clean_docker_environment` solo se invocará si el tool `sdd_docker_generate_dockerfile` falla por Docker no disponible.
+  - **Liberación de Puerto**: Ejecuta `sdd_free_port(3000)` para terminar proactivamente cualquier proceso previo que esté ocupando el puerto.
+  - **Generar Docker artifacts (PRIMERA LLAMADA)**: Usa la tool `sdd_generate_dockerfile({ stack: "nextjs", port: 3000 })` para crear `Dockerfile` + `.dockerignore` + `docker-compose.yml` en **una sola llamada**. Esta tool ya valida internamente los 7 puntos de calidad del Dockerfile (multi-stage, healthcheck, USER no-root, etc.), por lo que NO necesitas re-validarlos.
+  - **Construcción y Lanzamiento (SEGUNDA LLAMADA)**: Ejecuta `docker compose up -d --build --force-recreate` para forzar la creación y el inicio limpio. Espera ~30s para el primer arranque.
+  - **Verificación (TERCERA LLAMADA)**: `curl -sI http://localhost:3000/dashboard` y `curl -s http://localhost:3000/analytics` — verifica status 200. Si redirige (307), sigue el redirect con `-L`.
+  - **FALLBACK**: Solo si la tool `sdd_generate_dockerfile` no está disponible, carga la skill `docker-templates` para obtener las plantillas y escríbelas manualmente con `write`.
 </deployment>
 
-<dockerfile_pre_build_lint>
-**BLOQUEANTE — ejecutar antes de `docker build`**: Valida el Dockerfile asegurando los siguientes 7 puntos de calidad:
-
-1. **`FROM` con versión pinned**: Nunca uses `latest` o tags dinámicos. Usa tags fijos (ej. `node:20-alpine` o `node:22-alpine`).
-2. **Multi-stage build**: Al menos 2 stages (`builder` + `runner`). El stage final de ejecución debe usar la imagen alpine mínima.
-3. **`--frozen-lockfile` / `npm ci`**: Asegura que el paso de instalación use flags de congelamiento para que el build no diverja del lockfile.
-4. **Healthcheck definido y alcanzable**: `HEALTHCHECK` presente en el Dockerfile, con una herramienta disponible (ej. curl o wget) apuntando a un endpoint válido (ej. `/`).
-5. **`USER` no-root**: El stage final debe configurar un usuario no-root (ej. `USER node`).
-6. **Sin caché de paquetes**: Cada `RUN apt-get install` o `apk add` debe limpiar su caché en la misma capa (ej. `&& rm -rf /var/cache/apk/*` o `/var/lib/apt/lists/*`).
-7. **Sin errores de sintaxis en `CMD` o `ENTRYPOINT`**: Asegúrate de que los comandos CMD y ENTRYPOINT estén bien formados y cerrados.
-
-Si algún punto falla, corrige el Dockerfile antes de construir. NO continúes con `docker build` hasta que pase este check.
-</dockerfile_pre_build_lint>
-
 <report>
-Al finalizar, no te comuniques directamente con el usuario. Genera un reporte técnico estructurado para `@sdd-orchestrator` que incluya: las URLs de acceso, estado de los contenedores (`docker compose ps`), y logs iniciales de arranque (`docker compose logs` o `docker logs`).
+Al finalizar, no te comuniques directamente con el usuario. Genera un reporte técnico estructurado para `@sdd-orchestrator` que incluya: las URLs de acceso (con sus status codes), estado de los contenedores (`docker compose ps` — solo del proyecto, filtrado por nombre), y logs iniciales de arranque (últimas 10 líneas de `docker compose logs --tail=10`).
 </report>

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

@@ -48,24 +48,36 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
 <workflow>
   <f0_detect>
     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. **Autopiloto (/loop)**:
+    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.
+    3. **Autopiloto (/loop)**:
        - Si el usuario especificó `/loop N` o `iteraciones=N`, autoselecciona Next.js 16, Console mode, y el primer diseño recomendado.
        - Transiciona atómicamente a F1 con `sdd_set_phase({ phase: "F1_CONTRACT", spec_name: "<nombre-kebab>", loopMode: true, loopTargetIterations: N, loopCurrentIteration: 1 })`.
-    3. **Normal (HIL)**: Llama una vez a `question` para decidir Stack (Next.js vs Vite), Verificación (Console vs Visual), Persistencia y Diseño. Luego, transiciona con `sdd_set_phase` a `F1_CONTRACT`.
+    4. **Normal (HIL) — Pregunta Mínima**: Llama **UNA sola vez** a `question` con **una sola decisión clave**:
+       - Modo de verificación: `Console` (rápido, sin Playwright) o `Visual` (con Playwright, +30% tiempo).
+       - **Defaults razonables automáticos** (NO preguntes): Stack = Next.js 16 + Shadcn UI, Persistencia = localStorage/mock, Diseño = primer recomendado.
+       - Si el usuario pide un dashboard/panel/landing explícitamente, **recomienda Console** y usa `dashboard-01` como bloque base sin preguntar nada más.
+       - Luego, transiciona con `sdd_set_phase` a `F1_CONTRACT`.
+    5. **Fast-Track Dashboard (Auto-detect)**: Si la petición del usuario contiene keywords (`dashboard`, `admin panel`, `panel de control`, `panel admin`, `crm`, `erp`), y NO existe un proyecto en `src/`, **recomienda automáticamente** usar `@shadcn/dashboard-01` como bloque base y crea el spec con `sdd_hints.block_strategy = "npx shadcn@latest add @shadcn/dashboard-01"` pre-rellenado. En este modo, F1 se reduce a validación de tokens de diseño únicamente.
   </f0_detect>
 
   <f1_contract>
-    1. Delega a `@sdd-spec-writer` indicando solo el `activeContract` y el modo de verificación.
-    2. Presenta el contrato resumido al usuario (máximo 40 líneas).
+    1. Delega a `@sdd-spec-writer` indicando solo el `activeContract`, el modo de verificación, y el bloque shadcn pre-seleccionado si es Fast-Track Dashboard.
+    2. Presenta el contrato resumido al usuario (máximo 20 líneas, en formato tabla markdown).
     3. Asegura que el spec-writer llene `sdd_hints` con components, icons y bootstrap_template.
     4. **Aprobación**: En autopiloto, transiciona directo. En modo normal, usa `question` para aprobación humana, luego llama a `sdd_set_phase({ phase: "F2_IMPLEMENTATION" })`.
-    5. **Preparar Brief**: Lee `contract.json`, extrae la lista de componentes/endpoints, estado de bootstrap previo, y lecciones clave del Brain. Genera un brief estructurado e inyéctalo en `.openspec/active-brief.md` usando `sdd_save_active_brief`.
+    5. **Preparar Brief**: Lee `contract.json`, extrae la lista de componentes/endpoints, estado de bootstrap previo, y las lecciones de Brain pre-cargadas en F0. Genera un brief estructurado e inyéctalo en `.openspec/active-brief.md` usando `sdd_save_active_brief`.
+       - **Sección obligatoria para el Coder**: `brain_learnings` (resultado de `brain_read_memory({ category: "design" })`) — inyecta lecciones de diseño previas.
+       - **Sección obligatoria para el Tester**: `regressions` (resultado de `brain_read_memory({ category: "errors" })`) — inyecta regresiones históricas.
        - *Asignación Dinámica de Skills (OBLIGATORIO):* Indica en el brief qué habilidades específicas tiene permitido cargar el subagente para ahorrar tokens de carga (ej: si el stack es Next.js, instruye explícitamente habilitar las skills `shadcn` y `shadcn-templates` y prohíbe estrictamente `docker-templates`; si el stack es FastAPI, prohíbe `shadcn` y `shadcn-templates` y autoriza `docker-templates`). Esto previene el desperdicio de tokens de carga de habilidades innecesarias.
   </f1_contract>
 
   <f2_implementation>
-    1. **Delega a `@sdd-coder`**: Envía un prompt conciso. NO re-envíes el contrato entero ni el package.json.
-       - *Instrucción clave:* Indica si requiere bootstrap. Prohíbe formalmente el uso de `brain_read_memory`. Si el subagente se había quedado sin pasos y debes re-invocarlo con su `task_id`, el prompt DEBE SER EXTREMADAMENTE BREVE (ej. "Te quedaste sin pasos. Tu contexto y tareas ya están en tu historial. Revisa lo que falta y continúa."). NO incluyas código ni listas largas para no contaminar el contexto.
+    1. **Delega a `@sdd-coder`**: Envía un prompt conciso. NO re-envíes el contrato entero ni el package.json. Pasa solo:
+       - Spec name + ruta del contract.json
+       - Lista resumida de `files_affected`
+       - Lista de sprints pre-divididos si `files_affected.length > 5`
+       - Sección `brain_learnings` del brief
+       - *Instrucción clave:* Indica si requiere bootstrap. Prohíbe formalmente el uso de `brain_read_memory` (ya está inyectado). Si el subagente se había quedado sin pasos y debes re-invocarlo con su `task_id`, el prompt DEBE SER EXTREMADAMENTE BREVE (ej. "Te quedaste sin pasos. Tu contexto y tareas ya están en tu historial. Revisa lo que falta y continúa."). NO incluyas código ni listas largas para no contaminar el contexto.
     2. **Verificación de Servidor**:
        - **Si la categoría es 'script' o 'tooling' (Track Agnóstico):** No hay un dev server web que correr. Salta directamente este paso y transiciona de forma inmediata a F3.
        - **De lo contrario (Web Next/FastAPI):**
@@ -77,9 +89,10 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
 
   <f3_verification>
     1. **Shift-Left**: Llama obligatoriamente a `sdd_shift_left_verify`. Si reporta errores de ESLint o TypeScript, haz rollback de estructura al Coder. No continúes si hay errores de compilación críticos.
-    2. Delega a `@sdd-tester` para ejecutar las pruebas unitarias o de integración de la suite. (Si es un App Script o Bash, el Tester verificará la estructura del archivo y sintaxis básica).
-       - *Instrucción clave:* Al igual que en F2, si el subagente se quedó sin pasos y usas su `task_id`, el prompt DEBE SER EXTREMADAMENTE BREVE. NO incluyas las listas de test scenarios.
-    3. **Transición**:
+    2. **Pre-inyecta el brief al Tester (BLOQUEANTE)**: Antes de delegar al tester, invoca `brain_read_memory({ category: "errors" })` (idempotente, ya lo hiciste en F0) e inyecta el resultado como sección `regressions` en `.openspec/active-brief.md`. Esto previene que el tester repita errores históricos.
+    3. Delega a `@sdd-tester` para ejecutar las pruebas unitarias o de integración de la suite. (Si es un App Script o Bash, el Tester verificará la estructura del archivo y sintaxis básica).
+       - *Instrucción clave al delegar:* Pasa solo la ruta del spec, la lista de test files a ejecutar, los mockPatterns pre-armados y la sección `regressions`. NO incluyas las listas de test_scenarios completas. PROHIBIDO usar `glob` o `read` masivos: el brief ya tiene todo pre-inyectado. Al igual que en F2, si el subagente se quedó sin pasos y usas su `task_id`, el prompt DEBE SER EXTREMADAMENTE BREVE.
+    4. **Transición**:
        - **Si la categoría es 'script' o 'tooling' (Track Agnóstico):** Omitir la fase F4_DEPLOYMENT por completo (los scripts no requieren Docker en su ciclo estándar). Transiciona directamente a `<completion>`.
        - **De lo contrario (Web):**
          - Autopiloto e iteración intermedia (current < target): Omite la fase F4 para ahorrar tiempo y transiciona directo a `<completion>`.
@@ -95,17 +108,27 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
 
   <rollbacks>
     1. Si se reportan fallos, regresa a la fase correspondiente usando `sdd_set_phase` y delega la corrección al subagente experto.
+    2. Si una misma fase falla más de 2 veces consecutivas, presenta el error al usuario con el contexto completo en vez de seguir intentando.
   </rollbacks>
 
   <completion>
     1. **Flujo de Iteraciones Autónomas (/loop)**:
        - Si `loopCurrentIteration < loopTargetIterations`:
-         - Analiza la app y define **una (1) mejora autónoma de alto impacto de UX/UI o usabilidad** (ej. keyboard shortcuts, toast notifications, empty states).
-         - Anuncia la mejora e inicia la siguiente iteración incrementando el contador.
-         - **Delegación Limpia**: Llama a `sdd_set_phase` a `F0_DETECT`. Invoca obligatoriamente la herramienta `task` para delegar la siguiente iteración completa a un nuevo hilo `sdd-orchestrator` independiente con contexto de 0 tokens.
-       - Si `loopCurrentIteration >= loopTargetIterations` o modo normal: Concluye, limpia con `sdd_set_phase({ phase: "F0_DETECT", loopMode: false })` y presenta el resumen final.
-    2. Guarda los aprendizajes de alto valor obtenidos en la sesión usando `brain_save_memory`.
-    3. Actualiza todos los TODOs de la sesión como completados llamando a `todowrite` en bloque.
+         - Define **una (1) mejora autónoma de alto impacto** (ej. keyboard shortcuts, toast notifications, empty states).
+         - 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.
+    3. **Mensaje Final MÁXIMO 10 LÍNEAS**:
+       ```
+       ✅ Sesión SDD completada
+       - Spec: <nombre>
+       - Stack: <tecnologías>
+       - Tests: <X>/<X> passing
+       - Deploy: <URL>
+       - Lecciones guardadas en Brain: <categoría>
+       ```
+       NO uses tablas largas ni recapitules cada fase. El usuario ya vio el progreso en tiempo real.
+    4. Actualiza todos los TODOs de la sesión como completados llamando a `todowrite` en bloque (1 sola vez).
   </completion>
 </workflow>
 
@@ -114,6 +137,20 @@ Eres el coordinador principal del arnés de desarrollo SDD (Spec-Driven Developm
 - `next-devtools` deshabilitado por defecto. MCPs invocados exclusivamente por subagentes.
 </mcp_guidelines>
 
+<communication_rules>
+- **Mensajes Concisos (OBLIGATORIO)**: Cada mensaje tuyo debe ser ≤ 10 líneas de prosa. Tablas con hasta 5 columnas OK. PROHIBIDO:
+  - Resúmenes largos con múltiples tablas decorativas
+  - Listas de emojis innecesarios
+  - Repetir lo que el subagente ya reportó
+  - "Mensaje final" con 30+ líneas recapitulando todo
+- **Patrón de Reporte por Fase**:
+  ```
+  ✅ <Fase> completada — <1 línea con el outcome>
+  Siguiente: <Fase siguiente> → <acción concreta>
+  ```
+- **Errores**: Reportar 1 línea con qué falló + el siguiente paso concreto. NO pegar stack traces crudos (los subagentes ya los tienen).
+</communication_rules>
+
 <knowledge_base_design_html>
 Marcas con layouts exactos interactivos de Oh My Design (SaaS/DevTools: supabase, linear.app, vercel, raycast, posthog; Fintech: stripe, revolut, wise, toss; Consumer/Productivity: airbnb, apple, nike, shopify, spotify, figma, notion).
 </knowledge_base_design_html>

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

@@ -2,7 +2,7 @@
 description: Diseña y corre pruebas unitarias, integración y visuales (Playwright)
 mode: subagent
 hidden: true
-steps: 15
+steps: 20
 model: deepseek/deepseek-v4-flash
 temperature: 0.35
 frequency_penalty: 0.5
@@ -39,12 +39,18 @@ Eres el Validador de Contratos (sdd-tester) del flujo SDD. Tu trabajo es ejecuta
 </identity>
 
 <constraints>
-- **Lectura Inicial Obligatoria (BLOQUEANTE)**: Al comenzar tu trabajo, debes leer obligatoriamente `.openspec/active-brief.md` (o `.opencode/active-brief.md` si existiera) y el diseño activo en `.openspec/DESIGN.md` (o el `.openspec/design-assets/<brandId>/DESIGN.md` activo) para conocer detalladamente el brief, los escenarios de prueba a certificar y las directrices estéticas correspondientes.
+- **Brief Pre-inyectado (BLOQUEANTE)**: Al comenzar, NO explores el código a ciegas. El orquestador inyecta directamente en `.openspec/active-brief.md` (o `.opencode/active-brief.md`) la siguiente información que debes consumir de inmediato sin búsquedas adicionales:
+  - Lista de archivos de test a ejecutar (con su ruta absoluta)
+  - Lista de archivos de producción a testear (para entender qué mockear, ya leídos por el spec-writer)
+  - `mockPatterns` pre-armados (Proxy lucide-react, mock dinámico next-themes, mock next/navigation, polyfills crypto.randomUUID)
+  - `regressions` (lecciones del Brain sobre fallos históricos)
+  - Resumen de los `test_scenarios` del contrato activo
+  - Lee solo el `.openspec/active-brief.md` UNA vez. Si necesitas más contexto de un archivo específico, léelo UNA vez por archivo, NUNCA de forma masiva.
 - **Prohibición de Duplicar Lógica**: Tienes estrictamente prohibido simular o recrear la lógica de negocio dentro de las pruebas para forzar que pasen. Debes importar y verificar los componentes y funciones reales desde `src/`. Moca dependencias externas o corrige configuraciones en `setup.ts` si es necesario.
 - **Ruta de Capturas de Pantalla**: Cualquier screenshot con `playwright_browser_take_screenshot` debe guardarse obligatoriamente con el prefijo `.openspec/ts-` (ej. `.openspec/ts-home-page.png`). Nunca los guardes en la raíz.
 - **Prohibición de Playwright**: Si `verificationMode === "console"` en contract.json, tienes STRICTAMENTE PROHIBIDO usar cualquier tool o navegador de Playwright.
-- **Minimizar Lecturas/Búsquedas**: No realices búsquedas ciegas (`glob` repetidos) ni lecturas innecesarias. Guíate estrictamente por la lista `files_affected` provista en tu sección del brief activo para conocer qué archivos de producción se han modificado y dónde están ubicados los tests correspondientes.
-- **Memoria de Errores**: Tienes PROHIBIDO llamar a `brain_read_memory`. Toda la información histórica sobre fallos técnicos ha sido inyectada directamente en `.opencode/active-brief.md`. Consúltala allí.
+- **Prohibición de Exploración Ciega**: Tienes ESTRICTAMENTE PROHIBIDO usar `glob` o `grep` repetidos para descubrir archivos. Todo lo que necesitas ya está en el brief. Solo `read` los archivos exactos listados en el brief.
+- **Memoria de Errores**: Tienes PROHIBIDO llamar a `brain_read_memory`. El orquestador inyecta las regresiones históricas relevantes directamente en tu sección del brief.
 - **Restricción de Archivos**: Solo se te permite modificar/escribir archivos en la fase 'F3_VERIFICATION', y únicamente archivos que contengan 'test', 'spec', 'tests/' o '.openspec/' en su ruta. Tienes estrictamente prohibido modificar el código fuente de producción.
 - **Extensión JSX en Tests**: Todo archivo de pruebas que contenga JSX, monte componentes o simule iconos (mocks de Lucide con `<svg>`) **DEBE** tener la extensión `.tsx` obligatoriamente (nunca `.ts` ya que esbuild/Vitest fallarán en la compilación).
 - **Selectores de Formularios Robustos**: Evita usar `getByLabelText(/password/i)` si hay botones con aria-label que coincidan de forma ambigua. Prefiere placeholders como `getByPlaceholderText()` o expresiones regulares con anclajes estrictos como `/^Password$/` para aislar el input deseado.
@@ -56,9 +62,10 @@ Eres el Validador de Contratos (sdd-tester) del flujo SDD. Tu trabajo es ejecuta
 
 <pre_deploy>
 - **Ámbito**: Validar pruebas unitarias y de integración antes del despliegue.
-- **Auto-generación de Plantillas (OBLIGATORIO)**: Al comenzar, ejecuta obligatoriamente `sdd_generate_tests` para autogenerar las plantillas a partir de los `test_scenarios` del contrato.
+- **Auto-generación de Plantillas (OBLIGATORIO)**: Al comenzar, ejecuta obligatoriamente `sdd_generate_tests` para autogenerar las plantillas a partir de los `test_scenarios` del contrato. Las plantillas ya incluyen imports reales, mocks estándar (Proxy lucide-react, mock reactivo next-themes), y assertions significativas basadas en el `then` de cada escenario. NO las reescribas desde cero.
+- **NO explorar el código**: Tu brief ya contiene los archivos de producción a testear y los patrones de mock pre-armados. NO hagas `read` masivos de componentes, NO hagas `glob` ciegos. Solo lee el archivo de test específico que estés arreglando.
 - **Preparación de Puerto**: Llama proactivamente a `sdd_free_port` para liberar el puerto de pruebas.
-- **Ejecución Incremental/Dirigida**: Completa la lógica de aserción en los archivos de test y ejecuta la suite de pruebas de forma focalizada apuntando únicamente a los archivos de test específicos relacionados con la funcionalidad modificada (ej. `npx vitest run src/__tests__/<test_name>.test.tsx` o `pytest tests/unit/<test_name>.py` en lugar de correr toda la base de pruebas), acelerando exponencialmente los tiempos de espera.
+- **Ejecución Incremental/Dirigida**: Ejecuta la suite de pruebas de forma focalizada apuntando únicamente a los archivos de test específicos relacionados con la funcionalidad modificada (ej. `npx vitest run src/__tests__/<test_name>.test.tsx` o `pytest tests/unit/<test_name>.py` en lugar de correr toda la base de pruebas), acelerando exponencialmente los tiempos de espera.
 - **Linter Focalizado**: Ejecuta `npx eslint` apuntando específicamente a los archivos de producción modificados listados en `files_affected` del brief y a tus archivos de test (ej. `npx eslint src/components/blocks/MyBlock.tsx src/__tests__/MyBlock.test.tsx`), optimizando el análisis estático.
 - **Resolución Proactiva de Fallas**: Si los tests fallan debido a problemas menores de mocking, importaciones incorrectas, llaves duplicadas en React o configuraciones de test, **tienes autorización total para editarlos y repararlos tú mismo** dentro de `tests/` o `src/__tests__/`. Solo si el error es un fallo lógico en el código de producción de la aplicación (el cual tienes prohibido modificar), debes reportar un rollback a `F2_IMPLEMENTATION`.
 - **Transición**:

package/.opencode/contract-schema.json

@@ -180,7 +180,7 @@
     },
     "external_api_verification": {
       "type": "object",
-      "description": "Resultados de la verificación de APIs externas (HeroUI, Next.js, etc.) realizada por el spec-writer con MCPs. Hace explícito qué se validó en F1.",
+      "description": "OPCIONAL. Solo incluir cuando se valida una API no trivial con un MCP externo (ej: API de HeroUI con props compuestos). NO duplicar props de lucide-react, recharts o shadcn — esas ya están documentadas en sus skills. Para un dashboard típico, omitir este campo completo.",
       "properties": {
         "verified_at": {
           "type": "string",
@@ -224,6 +224,15 @@
           "type": "string",
           "enum": ["nextjs-shadcn", "fastapi-sdd", "agnostic-fast"],
           "description": "Plantilla preferida para bootstrap. nextjs-shadcn para web Next, fastapi-sdd para Python, next-fast o agnostic-fast si es un script ligero de un solo archivo."
+        },
+        "blocks_to_install": {
+          "type": "array",
+          "items": { "type": "string" },
+          "description": "Bloques shadcn pre-hechos para instalar (ej: ['@shadcn/dashboard-01']). El coder los instala con npx shadcn@latest add."
+        },
+        "fast_track": {
+          "type": "boolean",
+          "description": "Si true, indica que el spec es fast-track y debe usar bloques pre-hechos en lugar de diseñar desde cero."
         }
       }
     }

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

@@ -5,14 +5,16 @@ Estas reglas son mandatorias para todos los agentes de la sesión (Orchestrator,
 ## 1. Sistema de Memoria Compartida (Brain)
 El proyecto utiliza un sistema de memoria centralizado en `.openspec/brain.md` gestionado por las herramientas `brain_save_memory` y `brain_read_memory`.
 
-- **Orquestador (F0/F1 y Finalización)**:
-  - Al iniciar, debe invocar `brain_read_memory` para extraer aprendizajes de diseño, ruteo o errores históricos.
-  - Al completar una sesión, debe sintetizar las lecciones valiosas aprendidas y registrarlas mediante `brain_save_memory`.
+- **Orquestador (OBLIGATORIO en cada sesión)**:
+  - **F0**: Invocar `brain_read_memory({ category: "learnings" })` y `brain_read_memory({ category: "errors" })` para extraer errores históricos conocidos y prevenir repetirlos.
+  - **F2 inicio (antes de delegar al coder)**: Invocar `brain_read_memory({ category: "design" })` para inyectar lecciones de diseño previas en el brief.
+  - **F3 inicio (antes de delegar al tester)**: Invocar `brain_read_memory({ category: "errors" })` para inyectar regresiones en el brief.
+  - **Finalización (siempre, sin excepción)**: Sintetizar 1-3 lecciones valiosas de la sesión y registrarlas con `brain_save_memory` en la categoría adecuada (`learnings`, `errors`, `design`, `routing`).
 - **Coder (F2)**:
-  - Antes de empezar a codificar, debe consultar la categoría `design` y `learnings` en el Brain.
+  - Antes de empezar a codificar, debe consultar la categoría `design` y `learnings` en el Brain. El orquestador inyecta estos datos en `.openspec/active-brief.md` antes de delegar.
   - Si soluciona un bug complejo, debe reportarlo registrándolo en la categoría `errors` o `learnings`.
 - **Tester (F3)**:
-  - Debe consultar la categoría `errors` para asegurar que los nuevos casos de prueba cubran regresiones históricas.
+  - Debe consultar la categoría `errors` para asegurar que los nuevos casos de prueba cubran regresiones históricas. El orquestador inyecta estos datos en `.openspec/active-brief.md` antes de delegar.
 
 ## 2. Modo Autopiloto (/loop)
 Cuando el estado del sistema tiene `loopMode === true` (activado mediante el comando `/loop` o llamando a `sdd_set_phase`):
@@ -80,3 +82,4 @@ Para evitar que los subagentes se queden sin pasos (step/token exhaustion) o acu
 - **Regla de Micro-Specs:** Si una funcionalidad requiere implementar múltiples vistas complejas o formularios densos, el Spec-Writer **debe** dividirla obligatoriamente en specs incrementales secuenciales de máximo 3 componentes principales por contrato. No intentes implementar todo un panel de administración en una sola iteración de contrato.
 - **Compilación Atómica:** El Coder **debe** implementar y compilar exitosamente cada archivo de forma individual antes de escribir el siguiente. Está estrictamente prohibido escribir todos los componentes de golpe sin ejecutar validaciones intermedias de TypeScript (`tsc --noEmit`).
 - **Verificación Temprana de Dependencias:** El Coder **debe** comprobar en el primer paso de F2 que dependencias de pruebas críticas como `@testing-library/dom` estén correctamente instaladas en proyectos React 19 para evitar fallos intermitentes de tipado en Vitest.
+- **PROHIBICIÓN ESTRICTA DE `todowrite` en Coder/Tester/Deployer/Spec-Writer:** Estas herramientas **no deben invocar** `todowrite` en ningún momento de su sesión. El seguimiento de fases está centralizado en el Orquestador. Inyectar TODOs en subagentes satura su contexto y agota pasos de LLM innecesariamente. El Orquestador solo debe usar `todowrite` **2 veces máximo por sesión**: una al inicio (lista de fases) y otra al final (marcar todas completadas).

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

@@ -0,0 +1,71 @@
+---
+name: sdd-foundation-overview
+description: Resumen ejecutivo del flujo SDD para el orquestador. Cargado SOLO por el orquestador principal (~50 líneas). Para detalles profundos, los subagentes cargan `sdd-methodology` directamente.
+license: MIT
+compatibility: opencode
+---
+
+## Qué hace esta habilidad
+
+Resumen ultra-compacto del ciclo SDD. El orquestador NO debe cargar `sdd-methodology` (600 líneas). Solo esta skill + delegar.
+
+## El ciclo en 60 segundos
+
+```
+F0 → detectar stack + auto-bootstrap (si dashboard/admin/panel) + diseñar 1 pregunta
+F1 → spec-writer redacta contract.json desde plantilla (sdd-quickstart)
+F2 → coder implementa con block-first (@shadcn/dashboard-01 si es dashboard)
+F3 → tester corre vitest/pytest (tests YA tienen assertions reales)
+F4 → deployer genera Dockerfile + build + verify
+```
+
+## Defaults razonables (NO preguntar)
+
+- **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
+
+## 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_generate_dockerfile({ stack: "nextjs", port: 3000 })` en F4 | Genera 3 archivos en 1 call |
+
+## Reglas duras
+
+1. **Coordinación pura**: el orquestador NO escribe/edita código. Solo delega vía `task`.
+2. **Una pregunta por sesión**: solo Console vs Visual en F0. Todo lo demás por default.
+3. **Fast-Track Dashboard**: si el usuario pide dashboard/admin/panel → usar `@shadcn/dashboard-01` directamente sin preguntar más.
+4. **Brain obligatorio**: save 1-3 lecciones al cerrar cada sesión, read learnings+errors en F0.
+5. **Tests con assertions reales**: nunca stubs con `expect(true).toBe(true)`.
+
+## Métricas objetivo de una sesión
+
+- F0: 1 ronda de `question` con 1 sola decisión
+- F1: contract.json 80-120 líneas, 3-5 test_scenarios
+- F2: self-audit limpio en 1 intento
+- F3: lint + tests verdes en 1 intento
+- F4: build OK al 1er intento, healthcheck `healthy` en <60s
+
+## Anti-patrones (PROHIBIDO)
+
+- Cargar `sdd-methodology` (600 líneas) en el orquestador
+- Preguntar stack/diseño/persistencia si el usuario dijo "dashboard"
+- Usar `todowrite` más de 2 veces por sesión
+- Ejecutar `glob`/`grep` ciegos en el orquestador
+- Pedirle al orquestador que compile/testee código
+
+## Inyectar en briefs de subagentes
+
+Cada vez que delegues a un subagente, pasa en el brief:
+- `brain_learnings`: resultado de `brain_read_memory({ category: "design" })` para coder
+- `regressions`: resultado de `brain_read_memory({ category: "errors" })` para tester
+- `mockPatterns`: pre-armados para tester (Proxy lucide-react, mock next-themes)
+- `files_affected`: lista exacta, NO paths inferidos

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

@@ -1,10 +1,16 @@
 ---
 name: sdd-methodology
-description: Guía rápida del flujo SDD (Spec-Driven Development) con atajos y trampas conocidas. Cargar al inicio de CUALQUIER sesión SDD. Esta skill reemplaza la guía genérica anterior y contiene los patrones optimizados descubiertos tras analizar la sesión 137a (Sumadora Nike).
+description: Guía DETALLADA del flujo SDD con trampas conocidas. SOLO para subagentes (spec-writer, coder, tester, deployer). El orquestador debe cargar `sdd-foundation-overview` en su lugar.
 license: MIT
 compatibility: opencode
 ---
 
+## A quién está dirigida esta habilidad
+
+Esta skill es la versión **detallada y profunda** del flujo SDD. Está optimizada para subagentes que necesitan el contexto completo de las 5 fases, las trampas conocidas y los atajos avanzados.
+
+**El orquestador NO debe cargar esta skill.** Carga `sdd-foundation-overview` (~50 líneas) en su lugar.
+
 ## Qué hace esta habilidad
 
 Esta habilidad instruye a los agentes del arnés SDD a través del ciclo de 5 fases (F0-F4) **usando los atajos del harness optimizado**. NO es solo una guía genérica — incluye las **trampas conocidas** que han costado tiempo en sesiones reales y los atajos que las evitan.

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

@@ -150,6 +150,59 @@ Copia y adapta los IDs y descripciones que apliquen. Borra los que no apliquen.
 
 ---
 
+## 2.5. Plantilla MÍNIMA viable (Fast-Track Dashboard)
+
+Para un dashboard o panel estándar, usa esta plantilla **reducida** de **~80 líneas** en lugar de la completa. Omite `external_api_verification`, `database` y detalles innecesarios.
+
+```json
+{
+  "$schema": "../../../.opencode/contract-schema.json",
+  "contractName": "{{NOMBRE_PASCAL}}",
+  "description": "{{UNA_LINEA}}",
+  "category": "frontend",
+  "settings": {
+    "verificationMode": "console",
+    "language": "TypeScript",
+    "testFramework": "Vitest"
+  },
+  "stack": {
+    "core": ["Next.js 16", "Shadcn UI", "Tailwind CSS v4"],
+    "databases": []
+  },
+  "files_affected": [
+    "src/app/page.tsx",
+    "src/app/layout.tsx",
+    "{{ARCHIVOS_RELEVANTES}}"
+  ],
+  "frontend": {
+    "components": [
+      { "name": "{{COMP_1}}", "path": "@/components/blocks/{{COMP_1_KEBAB}}" },
+      { "name": "{{COMP_2}}", "path": "@/components/blocks/{{COMP_2_KEBAB}}" }
+    ]
+  },
+  "test_scenarios": [
+    {
+      "id": "TS-01",
+      "name": "{{NOMBRE_TEST}}",
+      "type": "unit",
+      "feature_ref": "{{COMP_1}}",
+      "given": "{{GIVEN}}",
+      "when": "{{WHEN}}",
+      "then": "{{THEN_OBSERVABLE}}"
+    }
+  ],
+  "sdd_hints": {
+    "bootstrap_template": "nextjs-shadcn",
+    "fast_track": true,
+    "blocks_to_install": ["@shadcn/dashboard-01"]
+  }
+}
+```
+
+**Tiempo objetivo F1 con Fast-Track**: 30-45 segundos.
+
+---
+
 ## 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).

package/.opencode/tools/sdd_bootstrap.ts

@@ -132,11 +132,14 @@ const DEFAULT_PACKAGE_JSON = {
     "postcss": "^8.4.49",
     "eslint": "^9.16.0",
     "eslint-config-next": "^15.1.0",
+    "typescript-eslint": "^8.18.0",
     "vitest": "^2.1.8",
     "@vitejs/plugin-react": "^4.3.4",
-    "jsdom": "^25.0.1",
+    "happy-dom": "^15.11.7",
     "@testing-library/react": "^16.1.0",
-    "@testing-library/dom": "^10.4.0"
+    "@testing-library/dom": "^10.4.0",
+    "@testing-library/jest-dom": "^6.6.3",
+    "@testing-library/user-event": "^14.5.2"
   }
 }
 

package/.opencode/tools/sdd_core.ts

@@ -409,6 +409,28 @@ export const set_phase = tool({
       } catch (e) {
         // ignore
       }
+
+      // Clean up stale screenshots from previous sessions (.openspec/ts-*.png)
+      try {
+        const openspecDir = path.resolve(root, ".openspec")
+        if (fs.existsSync(openspecDir)) {
+          const entries = fs.readdirSync(openspecDir)
+          let cleanedCount = 0
+          for (const entry of entries) {
+            if (/^ts-.*\.(png|jpe?g|webp)$/i.test(entry)) {
+              try {
+                fs.unlinkSync(path.join(openspecDir, entry))
+                cleanedCount++
+              } catch (e) { /* ignore individual file errors */ }
+            }
+          }
+          if (cleanedCount > 0) {
+            ;(currentState as any).cleanedScreenshots = cleanedCount
+          }
+        }
+      } catch (e) {
+        // ignore
+      }
     }
 
     writeState(filePath, currentState)
@@ -448,7 +470,30 @@ export const get_initial_session_data = tool({
     const root = getRoot(context)
     const statePath = getStateFilePath(context)
     const currentState = readState(statePath)
-    
+
+    // Limpieza silenciosa de carpetas/screenshots transitorios al iniciar F0
+    let cleanedCount = 0
+    try {
+      const playwrightTmpDir = path.resolve(root, ".openspec/.playwright")
+      if (fs.existsSync(playwrightTmpDir)) {
+        fs.rmSync(playwrightTmpDir, { recursive: true, force: true })
+        cleanedCount++
+      }
+      const openspecDir = path.resolve(root, ".openspec")
+      if (fs.existsSync(openspecDir)) {
+        for (const entry of fs.readdirSync(openspecDir)) {
+          if (/^ts-.*\.(png|jpe?g|webp)$/i.test(entry)) {
+            try {
+              fs.unlinkSync(path.join(openspecDir, entry))
+              cleanedCount++
+            } catch (e) { /* ignore */ }
+          }
+        }
+      }
+    } catch (e) {
+      // ignore
+    }
+
     // Read brain memory
     let brainMemory: any = { found: false }
     const brainFilePath = path.resolve(root, ".openspec/brain.md")
@@ -467,7 +512,7 @@ export const get_initial_session_data = tool({
             sections[currentHeader].push(line)
           }
         }
-        
+
         let prunedContent = ""
         for (const [header, bodyLines] of Object.entries(sections)) {
           const limit = 10
@@ -486,13 +531,18 @@ export const get_initial_session_data = tool({
     // Get design recommendations
     const recommendations = RECOMMENDED_BRANDS
 
-    return JSON.stringify({
+    const response: any = {
       status: "SUCCESS",
       state: currentState,
       brainMemory,
       designRecommendations: recommendations,
       note: "Inicialización completada. No es necesario que llames a sdd_get_state, brain_read_memory o sdd_list_design_recommendations por separado."
-    }, null, 2)
+    }
+    if (cleanedCount > 0) {
+      response.cleanedArtifacts = cleanedCount
+      response.note += ` Se limpiaron ${cleanedCount} artefactos transitorios (.playwright, screenshots).`
+    }
+    return JSON.stringify(response, null, 2)
   }
 })
 
@@ -511,6 +561,7 @@ export const save_active_brief = tool({
 
     // Attempt to read the active contract path from sdd_state.json and extract files_affected
     let filesAffected: string[] = []
+    let contract: any = null
     try {
       const statePath = path.resolve(openspecDir, "sdd_state.json")
       if (fs.existsSync(statePath)) {
@@ -518,7 +569,7 @@ export const save_active_brief = tool({
         if (state.activeContract) {
           const contractPath = path.resolve(root, state.activeContract)
           if (fs.existsSync(contractPath)) {
-            const contract = JSON.parse(fs.readFileSync(contractPath, "utf8"))
+            contract = JSON.parse(fs.readFileSync(contractPath, "utf8"))
             if (contract && Array.isArray(contract.files_affected)) {
               filesAffected = contract.files_affected
             }
@@ -536,14 +587,90 @@ export const save_active_brief = tool({
       enrichedBrief += `\n\n## [CRITICAL] POLÍTICA DE ZERO-SEARCH Y PRUEBAS INCREMENTALES\n`
       enrichedBrief += `La lista de archivos exactos creados o modificados en este contrato es:\n`
       enrichedBrief += filesAffected.map(f => `- \`${f}\``).join("\n") + "\n\n"
-      
+
       enrichedBrief += `### CODER_CONTEXT (F2)\n`
       enrichedBrief += `- Debes editar, crear y leer EXCLUSIVAMENTE estos archivos de producción: ${filesAffected.map(f => `\`${f}\``).join(", ")}.\n`
-      enrichedBrief += `- PROHIBIDO utilizar glob o grep de manera exploratoria ciega.\n\n`
-      
+      enrichedBrief += `- PROHIBIDO utilizar glob o grep de manera exploratoria ciega.\n`
+      enrichedBrief += `- **Batch extremo**: escribe/edita TODOS los archivos en una sola respuesta antes de validar.\n\n`
+
       enrichedBrief += `### TESTER_CONTEXT (F3)\n`
-      enrichedBrief += `- Debes correr pruebas enfocándote SOLO en tests que verifiquen estos archivos.\n`
+      enrichedBrief += `- Archivos de test asociados: src/__tests__/<feature_ref>.test.tsx\n`
       enrichedBrief += `- Ejecuta el linter de forma dirigida: \`npx eslint ${filesAffected.join(" ")}\`.\n`
+      enrichedBrief += `- **NO explores** el código: todo lo que necesitas ya está inyectado en este brief.\n`
+    }
+
+    // Inyectar automáticamente Brain learnings + errors (regresiones)
+    try {
+      const brainPath = path.resolve(openspecDir, "brain.md")
+      if (fs.existsSync(brainPath)) {
+        const brainContent = fs.readFileSync(brainPath, "utf8") || ""
+        const sections: Record<string, string[]> = {}
+        let currentHeader = "general"
+        for (const line of brainContent.split(/\r?\n/)) {
+          if (line.startsWith("# ")) {
+            currentHeader = line.substring(2).trim().toLowerCase()
+            sections[currentHeader] = []
+          } else if (line.trim().length > 0) {
+            if (!sections[currentHeader]) sections[currentHeader] = []
+            sections[currentHeader].push(line)
+          }
+        }
+        const last = (cat: string, n: number) =>
+          (sections[cat] || []).slice(-n).join("\n")
+
+        const learnings = last("learnings", 5)
+        const errors = last("errors", 5)
+        const design = last("design", 3)
+
+        if (learnings || errors || design) {
+          enrichedBrief += `\n\n## [AUTO-INJECTED] Brain Memory (lecciones de sesiones previas)\n`
+          if (design) {
+            enrichedBrief += `\n### Design (aplicar en estilo):\n${design}\n`
+          }
+          if (learnings) {
+            enrichedBrief += `\n### Learnings (patrones validados):\n${learnings}\n`
+          }
+          if (errors) {
+            enrichedBrief += `\n### Errors / Regresiones (evitar repetir):\n${errors}\n`
+          }
+        }
+      }
+    } catch (e) {
+      // ignore
+    }
+
+    // Inyectar mockPatterns estándar si el stack es Next.js con React
+    try {
+      const isNext = contract?.stack?.core?.some((c: string) => /next\.?js/i.test(c))
+      if (isNext) {
+        enrichedBrief += `\n\n## [AUTO-INJECTED] Mock Patterns (Vitest + Testing Library)\n`
+        enrichedBrief += `\`\`\`typescript\n`
+        enrichedBrief += `// Mock dinámico de lucide-react (cualquier icono)\n`
+        enrichedBrief += `vi.mock("lucide-react", () => new Proxy({}, {\n`
+        enrichedBrief += `  get: (_t, prop) => {\n`
+        enrichedBrief += `    const Icon = (props: any) => null;\n`
+        enrichedBrief += `    Icon.displayName = String(prop);\n`
+        enrichedBrief += `    return Icon;\n`
+        enrichedBrief += `  },\n`
+        enrichedBrief += `}));\n\n`
+        enrichedBrief += `// Mock reactivo de next-themes para ThemeToggle\n`
+        enrichedBrief += `let theme = "light";\n`
+        enrichedBrief += `vi.mock("next-themes", () => ({\n`
+        enrichedBrief += `  useTheme: () => ({\n`
+        enrichedBrief += `    get theme() { return theme; },\n`
+        enrichedBrief += `    setTheme: (t: string) => { theme = t; },\n`
+        enrichedBrief += `    get resolvedTheme() { return theme; },\n`
+        enrichedBrief += `  }),\n`
+        enrichedBrief += `}));\n\n`
+        enrichedBrief += `// Mock de next/navigation\n`
+        enrichedBrief += `vi.mock("next/navigation", () => ({\n`
+        enrichedBrief += `  useRouter: () => ({ push: vi.fn(), replace: vi.fn(), prefetch: vi.fn() }),\n`
+        enrichedBrief += `  usePathname: () => "/",\n`
+        enrichedBrief += `}));\n`
+        enrichedBrief += `\`\`\`\n`
+      }
+    } catch (e) {
+      // ignore
     }
 
     const briefPath = path.resolve(openspecDir, "active-brief.md")
@@ -551,7 +678,12 @@ export const save_active_brief = tool({
     return JSON.stringify({
       status: "SUCCESS",
       message: `Brief de contexto de sistema guardado exitosamente en .openspec/active-brief.md`,
-      filePath: briefPath
+      filePath: briefPath,
+      injectedSections: {
+        brainMemory: enrichedBrief.includes("Brain Memory"),
+        mockPatterns: enrichedBrief.includes("Mock Patterns"),
+        filesAffected: filesAffected.length
+      }
     }, null, 2)
   }
 })

package/.opencode/tools/sdd_testing.ts

@@ -402,26 +402,78 @@ export const generate_tests = tool({
           lines.push("")
         }
       } else {
-        lines.push('import { describe, it, expect } from "vitest";')
+        const componentImport = `@/components/blocks/${feature}`
+        lines.push('import { describe, it, expect, vi, beforeEach } from "vitest";')
+        
         if (hasReact) {
-          lines.push('import { render, screen } from "@testing-library/react";')
+          lines.push('import { render, screen, cleanup } from "@testing-library/react";')
           lines.push('import userEvent from "@testing-library/user-event";')
-          lines.push(`// import { ${feature} } from "@/components/blocks/${feature}";`)
+          lines.push('')
+          lines.push('// Mock lucide-react con Proxy (cualquier icono se mockea automáticamente)')
+          lines.push('vi.mock("lucide-react", () => new Proxy({}, {')
+          lines.push('  get: (_t, prop) => {')
+          lines.push('    const Icon = (props: any) => null;')
+          lines.push('    Icon.displayName = String(prop);')
+          lines.push('    return Icon;')
+          lines.push('  },')
+          lines.push('}));')
+          lines.push('')
+          lines.push(`import { ${feature} } from "${componentImport}";`)
         }
         lines.push("")
         lines.push(`describe("${feature} Tests (Contract Scenarios)", () => {`)
+        if (hasReact) {
+          lines.push('  afterEach(() => cleanup());')
+          lines.push('')
+        }
         
         for (const s of scenarios) {
           const tid = s.id || "TS-XX"
           const name = s.name || "Test case"
+          const isIntegration = s.type === "integration"
+          const thenText = (s.then || "").toLowerCase()
+          
           lines.push(`  // ${tid}: ${name}`)
           lines.push(`  // Given: ${s.given || ""}`)
           lines.push(`  // When: ${s.when || ""}`)
           lines.push(`  // Then: ${s.then || ""}`)
-          lines.push(`  it("${tid}: ${name}", async () => {`)
-          lines.push('    // TODO: Implement actual contract assertions')
-          lines.push('    expect(true).toBe(true);')
-          lines.push('  });')
+          
+          if (isIntegration && thenText.includes("dark")) {
+            lines.push(`  it("${tid}: ${name}", async () => {`)
+            lines.push(`    // Mock reactivo de next-themes para toggle de tema`)
+            lines.push(`    let theme = "light";`)
+            lines.push(`    vi.mock("next-themes", () => ({`)
+            lines.push(`      useTheme: () => ({ get theme() { return theme; }, setTheme: (t: string) => { theme = t; }, get resolvedTheme() { return theme; } }),`)
+            lines.push(`    }));`)
+            lines.push(`    document.documentElement.classList.add("light");`)
+            lines.push(`    render(<${feature} />);`)
+            lines.push(`    const button = screen.getByRole("button");`)
+            lines.push(`    await userEvent.click(button);`)
+            lines.push(`    expect(document.documentElement.classList.contains("dark")).toBe(true);`)
+            lines.push(`  });`)
+          } else if (thenText.includes("kpi") || thenText.includes("tarjeta") || thenText.includes("valor")) {
+            lines.push(`  it("${tid}: ${name}", () => {`)
+            lines.push(`    render(<${feature} />);`)
+            lines.push(`    expect(screen.getByText(/revenue/i)).toBeInTheDocument();`)
+            lines.push(`    expect(screen.getByText(/\\$/)).toBeInTheDocument();`)
+            lines.push(`  });`)
+          } else if (thenText.includes("sidebar") || thenText.includes("navega")) {
+            lines.push(`  it("${tid}: ${name}", () => {`)
+            lines.push(`    render(<${feature} />);`)
+            lines.push(`    expect(screen.getByText(/dashboard/i)).toBeInTheDocument();`)
+            lines.push(`    expect(screen.getByText(/analytics/i)).toBeInTheDocument();`)
+            lines.push(`  });`)
+          } else if (thenText.includes("svg") || thenText.includes("chart") || thenText.includes("recharts") || thenText.includes("gráfico") || thenText.includes("grafico")) {
+            lines.push(`  it("${tid}: ${name}", () => {`)
+            lines.push(`    const { container } = render(<${feature} />);`)
+            lines.push(`    expect(container.querySelector("svg")).toBeTruthy();`)
+            lines.push(`  });`)
+          } else {
+            lines.push(`  it("${tid}: ${name}", () => {`)
+            lines.push(`    render(<${feature} />);`)
+            lines.push(`    expect(screen.getByText(/${name.replace(/[.*+?^${}()|[\]\\]/g, '\\$&').slice(0, 30)}/i)).toBeTruthy();`)
+            lines.push(`  });`)
+          }
           lines.push("")
         }
         lines.push("});")

package/opencode.json

@@ -14,6 +14,7 @@
     "skill": {
       "omd-*": "allow",
       "stack-validator": "allow",
+      "sdd-foundation-overview": "allow",
       "sdd-methodology": "allow",
       "sdd-quickstart": "allow",
       "sdd-tester-quickstart": "allow",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zugzbot",
-  "version": "1.0.43",
+  "version": "1.1.0",
   "description": "Fácil instalador del arnés SDD de Zugzbot para proyectos OpenCode",
   "type": "module",
   "bin": {