zugzbot-sdd 1.5.19 → 1.5.20

package/.opencode/skills/sdd-auto-rollback-recovery/SKILL.md

@@ -0,0 +1,23 @@
+# Skill: SDD Auto Rollback Recovery
+
+Enseña a los agentes (principalmente `@sdd-deployer`) cómo actuar quirúrgicamente ante un fallo en la fase de despliegue para restaurar la estabilidad de forma atómica.
+
+## Trigger
+
+- Falla del comando de despliegue en Fase 4.
+- Respuestas HTTP 5xx o fallos graves en pruebas de salud inmediatamente después del despliegue.
+
+## Procedimiento de Recuperación
+
+1. **Rollback en Control de Versiones**:
+   - Identificar el último commit estable.
+   - Ejecutar: `git revert HEAD --no-edit` o `git checkout [stable-hash]` de forma controlada.
+2. **Restauración en Producción**:
+   - Re-desplegar la versión estable recuperada.
+3. **Aislamiento del Error**:
+   - Escribir un archivo temporal de error en `.openspec/crash_report.md`.
+   - Transicionar de regreso a Fase 2 (`sdd-builder`) para corrección del bug.
+
+## Tags
+
+#rollback #deploy #git #recovery #stability

package/.opencode/skills/sdd-brain-curator/SKILL.md

@@ -0,0 +1,22 @@
+# Skill: SDD Brain Curator
+
+Instruye al `@sdd-archiver` sobre cómo sintetizar y empaquetar aprendizajes en el archivo de memoria `brain.md`, evitando duplicación de contexto y optimizando la comprensión de la IA en futuras iteraciones.
+
+## Trigger
+
+- Fase de cierre (Fase 5) antes de archivar de forma atómica.
+
+## Directrices de Curación
+
+1. **Evitar Duplicidad**:
+   - Agrupar lecciones similares en un único bullet.
+2. **Categorización Estricta**:
+   - `[Sintaxis/Tipado]`: Errores relacionados con TypeScript, JavaScript o Apps Script.
+   - `[Arquitectura]`: Desacoplamiento de componentes.
+   - `[Lógica de Negocio]`: Flujos de negocio e interfaces.
+3. **Formato ultra compacto**:
+   - Escribir oraciones de máximo 20 palabras por aprendizaje.
+
+## Tags
+
+#brain #lessons #synthesis #memory

package/.opencode/skills/sdd-clean-architecture/SKILL.md

@@ -0,0 +1,20 @@
+# Skill: SDD Clean Architecture
+
+Instruye al `@sdd-builder` en principios de desacoplamiento modular para evitar la creación de archivos gigantescos que saturen el contexto de edición.
+
+## Trigger
+
+- Fase de codificación (Fase 2).
+
+## Directrices de Diseño
+
+1. **Separación de Capas**:
+   - UI / Vista desacoplada de la lógica de servicios y APIs.
+2. **Componentes Puros**:
+   - Funciones pequeñas con una única responsabilidad.
+3. **Tamaño Límite**:
+   - Evitar archivos de código fuente de más de 300 líneas. Si exceden, modularizar de inmediato.
+
+## Tags
+
+#architecture #modular #clean-code #builder

package/.opencode/skills/sdd-token-economy/SKILL.md

@@ -0,0 +1,20 @@
+# Skill: SDD Token Economy
+
+Enseña a todos los agentes a operar bajo estrictas directrices de ahorro de tokens y optimización contextual para reducir costos y acelerar la velocidad del swarm.
+
+## Trigger
+
+- Cualquier operación del ciclo SDD (constante).
+
+## Directrices Operativas
+
+1. **Lecturas Selectivas**:
+   - Usar herramientas de visualización de rangos específicos de líneas en vez de leer archivos enteros.
+2. **Poda de Logs**:
+   - Resumir o eliminar logs repetitivos y trazas gigantescas de la consola.
+3. **Peticiones LSP de Alto Impacto**:
+   - Apuntar la navegación a los símbolos/métodos relevantes de la clase específica en vez de recorrer múltiples módulos.
+
+## Tags
+
+#tokens #economy #cost #efficiency

package/agents/sdd-builder.md

@@ -11,6 +11,11 @@ permission:
   tools:
     "sdd_transition": allow
     "sdd_ui_auditor": allow
+    "sdd_secret_scanner": allow
+    "sdd_security_vulnerability_scanner": allow
+    "sdd_visual_regression_diff": allow
+    "sdd_auto_api_mocker": allow
+    "sdd_spec_compliance_linter": allow
 ---
 
 # @sdd-builder
@@ -22,6 +27,9 @@ permission:
 ## DO
 - 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).
+- **Escaneo SAST Quirúrgico**: Ejecuta `sdd_security_vulnerability_scanner` sobre tus archivos modificados antes de cerrar tu implementación.
+- **Validación de Secretos**: Corre `sdd_secret_scanner` para asegurarte de no dejar tokens/passwords temporales de desarrollo.
+- **Linter de Especificación**: Ejecuta `sdd_spec_compliance_linter` para certificar que todos los criterios de aceptación del Spec estén cubiertos.
 - Valida con LSP (`documentSymbol`, `goToDefinition`).
 
 ## RETURN
@@ -42,9 +50,9 @@ permission:
 - ❌ Escribir o autogenerar suites de tests unitarios o de integración
 - ❌ Ejecutar validación de linter o auditorías UI por cuenta propia (delegar a `@sdd-tester`)
 - ❌ Realizar deploys, pushes, o publicaciones de ningún tipo
-- ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor` únicamente)
+- ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor`, `sdd_secret_scanner`, `sdd_security_vulnerability_scanner`, `sdd_visual_regression_diff`, `sdd_auto_api_mocker`, `sdd_spec_compliance_linter`)
 - ❌ Modificar `package.json`, `tsconfig.json`, o archivos de configuración de proyecto
 - ❌ Ignorar el spec.md — toda implementación debe trackear contra los criterios de aceptación del spec
 
 > [!IMPORTANT]
-> SÓLO DEBE hacer: implementar cambios quirúrgicos según spec.md, usar `sdd_ui_auditor` cuando edite HTML/JSX/TSX, invocar `sdd_transition` al completar
+> SÓLO DEBE hacer: implementar cambios quirúrgicos según spec.md, usar `sdd_ui_auditor` cuando edite HTML/JSX/TSX, validar con SAST y Linter de Spec, e invocar `sdd_transition` al completar.

package/agents/sdd-planner.md

@@ -11,6 +11,12 @@ permission:
   tools:
     "sdd_transition": allow
     "sdd_brain_sync": allow
+    "sdd_requirement_tracker": allow
+    "check_dependency_cooldown": allow
+    "sdd_diff_impact_analyzer": allow
+    "sdd_auto_api_mocker": allow
+    "sdd_test_scaffold_generator": allow
+    "sdd_context_pruner": allow
 ---
 
 # @sdd-planner
@@ -23,6 +29,10 @@ permission:
 ## DO
 - **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**.
+- **Analizar el Impacto del Cambio**: Ejecuta `sdd_diff_impact_analyzer` para determinar el radio de impacto estructural del requerimiento.
+- **Scaffolding de Pruebas TDD**: Usa `sdd_test_scaffold_generator` para autogenerar la suite de pruebas unitarias en base a las especificaciones del `spec.md` diseñado.
+- **Mock de Servicios de Terceros**: Usa `sdd_auto_api_mocker` para extraer endpoints y generar mocks rápidos si el cambio interactúa con APIs externas.
+- **Optimizar Contexto**: Usa `sdd_context_pruner` para limpiar logs o historial redundante de context activo.
 - 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.
 
@@ -70,11 +80,11 @@ Feature: [Breve descripción]
 - ❌ Escribir, modificar o eliminar ningún archivo de código fuente (.ts, .js, .tsx, .jsx, .css, .html)
 - ❌ Ejecutar comandos bash de ejecución (npm install, git push, npx, etc.) — solo `bash: ask` para lecturas
 - ❌ Realizar deploys, pushes o publicaciones
-- ❌ Crear tests, suites de validación, o archivos de reporte fuera del spec.md
+- ❌ Crear tests, suites de validación, o archivos de reporte fuera del spec.md y el scaffold de pruebas
 - ❌ Modificar archivos fuera de `.openspec/changes/<change-name>/specs/spec.md`
 - ❌ Hacer preguntas por goteo (una por turno) — todas las preguntas van consolidadas en UNA sola llamada a `question` (máx 3-5)
-- ❌ Usar herramientas más allá de las asignadas (`sdd_transition`, `sdd_brain_sync`)
+- ❌ Usar herramientas más allá de las asignadas (`sdd_transition`, `sdd_brain_sync`, `sdd_requirement_tracker`, `check_dependency_cooldown`, `sdd_diff_impact_analyzer`, `sdd_auto_api_mocker`, `sdd_test_scaffold_generator`, `sdd_context_pruner`)
 - ❌ Reabrir fases anteriores o retroceder el ciclo
 
 > [!IMPORTANT]
-> SÓLO DEBE hacer: analizar requerimiento, identificar archivos afectados, realizar encuesta consolidada, generar spec.md
+> SÓLO DEBE hacer: analizar requerimiento, identificar archivos afectados, realizar encuesta consolidada, generar spec.md, y andamiar tests TDD.

package/agents/sdd-tester.md

@@ -11,6 +11,17 @@ permission:
     "sdd_transition": allow
     "sdd_ui_auditor": allow
     "sdd_spec_validator": allow
+    "sdd_regression_detector": allow
+    "sdd_bdd_tester": allow
+    "sdd_requirement_tracker": allow
+    "sdd_diff_impact_analyzer": allow
+    "sdd_security_vulnerability_scanner": allow
+    "sdd_visual_regression_diff": allow
+    "sdd_performance_regress_profiler": allow
+    "sdd_auto_api_mocker": allow
+    "sdd_test_scaffold_generator": allow
+    "sdd_spec_compliance_linter": allow
+    "sdd_sandbox_patcher": allow
 ---
 
 # @sdd-tester
@@ -23,14 +34,15 @@ permission:
 ## DO
 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.
-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).
+3. **Validación y Auditorías**:
+   - Ejecuta `sdd_spec_compliance_linter` para cruzar requerimientos.
+   - Ejecuta `sdd_security_vulnerability_scanner` para detectar vulnerabilidades en el código.
+   - Corre `sdd_visual_regression_diff` para auditar la interfaz y estilos.
+   - Ejecuta `sdd_performance_regress_profiler` para medir latencias y rendimiento.
+   - Usa `sdd_diff_impact_analyzer` para calcular el radio de impacto final.
+4. **Ejecutar Suite de Pruebas**: Corre la suite de tests nativos del proyecto (ej: `npm run test` / `npx vitest run`).
+5. **Autocorrección con Patcher**: Si detectas fallos unitarios simples, invoca `sdd_sandbox_patcher` para aplicar correcciones automáticas inmediatas sin retroceder de fase.
+6. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
 
 ## WRITE
 - `.openspec/changes/<change-name>/validation_report.md`
@@ -69,10 +81,10 @@ permission:
 - ❌ Modificar lógica de negocio, funciones, componentes o cualquier código fuente
 - ❌ Crear, modificar o eliminar specs o spec.md
 - ❌ Realizar deploys, pushes, o publicaciones
-- ❌ Reescribir archivos de código — solo autocorregir errores de sintaxis simples (máx 3 intentos)
+- ❌ Reescribir archivos de código — solo autocorregir errores de sintaxis simples usando `sdd_sandbox_patcher`
 - ❌ Escribir tests unitarios o de integración nuevos
 - ❌ Modificar archivos fuera de `.openspec/changes/<change-name>/`
-- ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor`, `sdd_spec_validator`)
+- ❌ Usar herramientas que no le fueron asignadas (`sdd_transition`, `sdd_ui_auditor`, `sdd_spec_validator`, `sdd_regression_detector`, `sdd_bdd_tester`, `sdd_requirement_tracker`, `sdd_diff_impact_analyzer`, `sdd_security_vulnerability_scanner`, `sdd_visual_regression_diff`, `sdd_performance_regress_profiler`, `sdd_auto_api_mocker`, `sdd_test_scaffold_generator`, `sdd_spec_compliance_linter`, `sdd_sandbox_patcher`)
 
 > [!IMPORTANT]
-> SÓLO DEBE hacer: ejecutar linter, auditorías UI, validaciones estáticas, generar `validation_report.md`, invocar `sdd_transition` al completar
+> SÓLO DEBE hacer: ejecutar linter, auditorías UI, validaciones estáticas, generar `validation_report.md`, invocar `sdd_transition` al completar.

package/package.json

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

package/skills/sdd-auto-rollback-recovery/SKILL.md

@@ -0,0 +1,23 @@
+# Skill: SDD Auto Rollback Recovery
+
+Enseña a los agentes (principalmente `@sdd-deployer`) cómo actuar quirúrgicamente ante un fallo en la fase de despliegue para restaurar la estabilidad de forma atómica.
+
+## Trigger
+
+- Falla del comando de despliegue en Fase 4.
+- Respuestas HTTP 5xx o fallos graves en pruebas de salud inmediatamente después del despliegue.
+
+## Procedimiento de Recuperación
+
+1. **Rollback en Control de Versiones**:
+   - Identificar el último commit estable.
+   - Ejecutar: `git revert HEAD --no-edit` o `git checkout [stable-hash]` de forma controlada.
+2. **Restauración en Producción**:
+   - Re-desplegar la versión estable recuperada.
+3. **Aislamiento del Error**:
+   - Escribir un archivo temporal de error en `.openspec/crash_report.md`.
+   - Transicionar de regreso a Fase 2 (`sdd-builder`) para corrección del bug.
+
+## Tags
+
+#rollback #deploy #git #recovery #stability

package/skills/sdd-brain-curator/SKILL.md

@@ -0,0 +1,22 @@
+# Skill: SDD Brain Curator
+
+Instruye al `@sdd-archiver` sobre cómo sintetizar y empaquetar aprendizajes en el archivo de memoria `brain.md`, evitando duplicación de contexto y optimizando la comprensión de la IA en futuras iteraciones.
+
+## Trigger
+
+- Fase de cierre (Fase 5) antes de archivar de forma atómica.
+
+## Directrices de Curación
+
+1. **Evitar Duplicidad**:
+   - Agrupar lecciones similares en un único bullet.
+2. **Categorización Estricta**:
+   - `[Sintaxis/Tipado]`: Errores relacionados con TypeScript, JavaScript o Apps Script.
+   - `[Arquitectura]`: Desacoplamiento de componentes.
+   - `[Lógica de Negocio]`: Flujos de negocio e interfaces.
+3. **Formato ultra compacto**:
+   - Escribir oraciones de máximo 20 palabras por aprendizaje.
+
+## Tags
+
+#brain #lessons #synthesis #memory

package/skills/sdd-clean-architecture/SKILL.md

@@ -0,0 +1,20 @@
+# Skill: SDD Clean Architecture
+
+Instruye al `@sdd-builder` en principios de desacoplamiento modular para evitar la creación de archivos gigantescos que saturen el contexto de edición.
+
+## Trigger
+
+- Fase de codificación (Fase 2).
+
+## Directrices de Diseño
+
+1. **Separación de Capas**:
+   - UI / Vista desacoplada de la lógica de servicios y APIs.
+2. **Componentes Puros**:
+   - Funciones pequeñas con una única responsabilidad.
+3. **Tamaño Límite**:
+   - Evitar archivos de código fuente de más de 300 líneas. Si exceden, modularizar de inmediato.
+
+## Tags
+
+#architecture #modular #clean-code #builder

package/skills/sdd-token-economy/SKILL.md

@@ -0,0 +1,20 @@
+# Skill: SDD Token Economy
+
+Enseña a todos los agentes a operar bajo estrictas directrices de ahorro de tokens y optimización contextual para reducir costos y acelerar la velocidad del swarm.
+
+## Trigger
+
+- Cualquier operación del ciclo SDD (constante).
+
+## Directrices Operativas
+
+1. **Lecturas Selectivas**:
+   - Usar herramientas de visualización de rangos específicos de líneas en vez de leer archivos enteros.
+2. **Poda de Logs**:
+   - Resumir o eliminar logs repetitivos y trazas gigantescas de la consola.
+3. **Peticiones LSP de Alto Impacto**:
+   - Apuntar la navegación a los símbolos/métodos relevantes de la clase específica en vez de recorrer múltiples módulos.
+
+## Tags
+
+#tokens #economy #cost #efficiency