zugzbot-sdd 1.5.11 → 1.5.13

package/agents/sdd-archiver.md

@@ -29,7 +29,13 @@ permission:
   - `bumpType`: patch / minor / major
 
 ## RETURN
-- Resumen: "Ciclo cerrado. Versión: X.Y.Z, Commit: abc123"
+- Resumen: Un mensaje claro y rotundo con un banner visual que anuncie que el ciclo ha concluido con éxito absoluto, por ejemplo:
+  ```
+  ╔══════════════════════════════════════════════════════════╗
+  ║   🎉 CICLO SDD FINALIZADO Y CERRADO CON ÉXITO ABSOLUTO   ║
+  ╚══════════════════════════════════════════════════════════╝
+  ```
+  Y detalla de forma ordenada la nueva versión (SemVer), el commit hash, los documentos históricos archivados exitosamente en `.openspec/archive/` y confirma que el espacio de trabajo ha quedado limpio y listo para el siguiente cambio.
 - Estado: success / error
 - Si error: "Error en cierre: ..."
 

package/agents/sdd-builder.md

@@ -17,11 +17,12 @@ permission:
 
 ## READ
 - `.openspec/changes/<change-name>/specs/spec.md`
+- `.openspec/brain.md` (Cerebro del Proyecto: convenciones técnicas y lecciones consolidadas)
 
 ## DO
-- Implementa los cambios en el código según el spec
-- Usa `edit` para parches quirúrgicos (prohibido reescribir archivos completos)
-- Valida con LSP (`documentSymbol`, `goToDefinition`)
+- Implementa los cambios en el código según el spec, asegurándote de revisar `.openspec/brain.md` para cumplir estrictamente con los patrones técnicos exitosos y evitar reintroducir malas prácticas.
+- Usa `edit` para parches quirúrgicos (prohibido reescribir archivos completos).
+- Valida con LSP (`documentSymbol`, `goToDefinition`).
 
 ## RETURN
 - Resumen: "Código implementado. Archivos modificados: X"

package/agents/sdd-deployer.md

@@ -17,9 +17,13 @@ permission:
 - Código implementado
 
 ## DO
-- Ejecuta `npx clasp push` (NO `clasp push` directo)
-- Verifica que el output contenga "Pushed X files"
-- Si falla: reintenta hasta 2 veces
+1. **Identificar Método de Despliegue**: Inspecciona el codebase para identificar el mecanismo de deploy del proyecto:
+   - **Apps Script (Google Apps Script)**: Si existe `.clasp.json`, ejecuta de manera obligatoria `npx clasp push`.
+   - **C++ (PlatformIO / ESP32)**: Si existe `platformio.ini`, ejecuta `pio run -t upload` o similar para subir el firmware al dispositivo.
+   - **Ecosistemas Web/Backend (Node, Python)**: Si existe un comando de deploy en `package.json` (como `npm run deploy` o `npm run build`), ejecútalo.
+   - **Otros**: Ejecuta el pipeline o comando de despliegue nativo configurado en el proyecto.
+2. **Ejecutar Despliegue Físico**: Usa tu permiso de terminal (`bash`) para ejecutar activamente el comando de despliegue real en el entorno del host.
+3. **Verificación de Éxito**: Captura el output y confirma que el despliegue fue exitoso (ej: "Pushed X files", "SUCCESS", "Upload successful", etc.). Si falla, reintenta hasta 2 veces.
 
 ## WRITE
 - `.openspec/changes/<change-name>/deployment_report.md`
@@ -29,13 +33,13 @@ permission:
 # Deployment Report
 
 ## Deploy
-- Comando: npx clasp push
+- Comando: [Comando ejecutado, ej: npx clasp push, pio run -t upload]
 - Estado: ÉXITO / FALLO
-- Archivos subidos: X
-- Errores: [si hay]
+- Detalle / Archivos subidos: [Detalle del output]
+- Errores: [si los hay]
 
 ## Verificación
-- [ ] Push verificado
+- [ ] Despliegue verificado con éxito en el host
 ```
 
 ## RETURN

package/agents/sdd-explorer.md

@@ -17,12 +17,13 @@ permission:
 ## READ
 - Código fuente del proyecto
 - Estructura de archivos principal
+- `.openspec/brain.md` (Cerebro del Proyecto: memoria técnica y lecciones históricas)
 
 ## DO
-- Escanea la estructura del proyecto
+- Escanea la estructura del proyecto y lee el `.openspec/brain.md` para entender el mapa técnico y reglas arquitectónicas previas.
 - Identifica archivos principales y sus propósitos
 - Detecta stack tecnológico y dependencias
-- Genera `diagnostics.md` en `.openspec/`
+- Genera `diagnostics.md` en `.openspec/` orientando la exploración con el contexto del Cerebro.
 
 ## WRITE
 - `.openspec/diagnostics.md`

package/agents/sdd-planner.md

@@ -17,13 +17,14 @@ permission:
 
 ## READ
 - `.openspec/diagnostics.md` (si existe)
+- `.openspec/brain.md` (Cerebro del Proyecto: aprendizajes acumulados y errores históricos)
 - Requerimiento del usuario
 
 ## DO
-- Analiza el requerimiento
-- Identifica archivos y funciones a modificar (rangos de líneas exactos)
-- **Si hay dudas técnicas**: usa `question` para preguntar al usuario (máx 3-5 preguntas)
-- Detecta si hay funciones duplicadas en múltiples archivos
+- **Descubrimiento de Requerimientos (Crucial)**: Realiza una encuesta inicial activa al usuario utilizando la herramienta `question` (consolidada en una llamada de 3-5 preguntas claras) para comprender a fondo la causa raíz, el síntoma real de negocio/UX y sus preferencias antes de redactar el plano técnico.
+- **Consultar el Cerebro**: Analiza `.openspec/brain.md` para asimilar fallas y aprendizajes anteriores. Es obligatorio diseñar una solución técnica que **evite cometer el mismo error o comportamiento incorrecto dos veces**.
+- Analiza el requerimiento e identifica los archivos y funciones a modificar (indicando rangos de líneas exactos).
+- Detecta si hay funciones duplicadas en múltiples archivos.
 
 ## WRITE
 - `.openspec/changes/<change-name>/specs/spec.md`

package/agents/sdd-tester.md

@@ -18,16 +18,18 @@ permission:
 ## READ
 - `.openspec/changes/<change-name>/specs/spec.md`
 - Código implementado
+- `.openspec/brain.md` (Cerebro del Proyecto: registro de fallas históricas y regresiones)
 
 ## DO
-1. **Identificar Ecosistema Tecnológico**: Inspecciona la raíz del codebase (archivos como `package.json`, `requirements.txt`, `pyproject.toml`, `platformio.ini`, `CMakeLists.txt`, `go.mod`, etc.) para detectar el stack técnico del proyecto.
-2. **Ejecutar Linter & Auditorías**:
+1. **Detección de Regresiones Históricas**: Lee `.openspec/brain.md` para identificar qué fallas específicas o comportamientos errados ocurrieron en el pasado. Debes verificar de manera explícita y prioritaria que la nueva implementación **no reintroduzca ninguno de los bugs o comportamientos incorrectos registrados en el Cerebro**.
+2. **Identificar Ecosistema Tecnológico**: Inspecciona la raíz del codebase (archivos como `package.json`, `requirements.txt`, `pyproject.toml`, `platformio.ini`, `CMakeLists.txt`, `go.mod`, etc.) para detectar el stack técnico del proyecto.
+3. **Ejecutar Linter & Auditorías**:
    - **JS/TS**: Ejecuta `npm run lint` o `eslint` y las validaciones estáticas de DOM (`npx vitest run tests/static/...`).
    - **Python**: Ejecuta `flake8`, `pylint` o `black --check`.
    - **C++ (ESP32/Embedded)**: Ejecuta chequeos estáticos como `cppcheck` o verifica la compilación del firmware.
    - **Otros**: Usa el formateador/linter estándar del ecosistema detectado.
-3. **Ejecutar Suite de Pruebas**: Usa tu permiso de terminal (`bash`) para correr la suite de tests nativos del proyecto (ej: `npm run test` / `npx vitest run` en Node, `pytest` / `python -m unittest` en Python, `pio test` en PlatformIO/C++, `go test` en Go, etc.).
-4. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
+4. **Ejecutar Suite de Pruebas**: Usa tu permiso de terminal (`bash`) para correr la suite de tests nativos del proyecto (ej: `npm run test` / `npx vitest run` en Node, `pytest` / `python -m unittest` en Python, `pio test` en PlatformIO/C++, `go test` en Go, etc.).
+5. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
 5. **Autocorrección**: Corrige errores simples de sintaxis o fallas de test (máx 3 intentos).
 
 ## WRITE

package/agents/zugzbot.md

@@ -36,9 +36,11 @@ permission:
 | 4 | `@sdd-deployer` | `deployment_report.md` | **Sí** (validar QA) |
 | 5 | `@sdd-archiver` | commit + archivado | No (cierra) |
 
-### 3. Manejar Auto-Pilot
-- Si `auto_pilot: true`: F0→F1→F2→F3 van sin pausas
-- **HIL post-F1 y post-F4 son OBLIGATORIOS** aunque auto_pilot esté prendido
+### 3. Manejar Flujo Eficiente (Reducción de Pausas)
+- Las transiciones **F0 → F1**, **F2 → F3** y **F3 → F4** son **completamente automáticas, fluidas y directas**. No debes detener el flujo ni interrumpir con preguntas de opción múltiple al usuario en estos pasos técnicos intermedios. Invoca `sdd_transition` y delega de inmediato al siguiente agente.
+- **HIL (Human-In-The-Loop) es obligatorio** únicamente en dos hitos metodológicos clave:
+  1. **Post-F1**: Revisión y aprobación explícita de la especificación (`spec.md`) antes de construir (F2).
+  2. **Post-F4**: QA final y validación manual del despliegue antes del archivado y cierre (F5).
 
 ### 4. Verificar Pendientes antes de F5
 - Antes de delegar a `@sdd-archiver`: verificar que todas las `lockfile.tasks[]` tengan `status: "completed"`

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zugzbot-sdd",
-  "version": "1.5.11",
+  "version": "1.5.13",
   "description": "Zugzbot SDD Swarm - Spec-Driven Development Harness for OpenCode",
   "main": "index.js",
   "type": "module",