zugzbot-sdd 1.5.12 → 1.5.14

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -17,11 +17,12 @@ permission:
17
17
 
18
18
  ## READ
19
19
  - `.openspec/changes/<change-name>/specs/spec.md`
20
+ - `.openspec/brain.md` (Cerebro del Proyecto: convenciones técnicas y lecciones consolidadas)
20
21
 
21
22
  ## DO
22
- - Implementa los cambios en el código según el spec
23
- - Usa `edit` para parches quirúrgicos (prohibido reescribir archivos completos)
24
- - Valida con LSP (`documentSymbol`, `goToDefinition`)
23
+ - 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.
24
+ - Usa `edit` para parches quirúrgicos (prohibido reescribir archivos completos).
25
+ - Valida con LSP (`documentSymbol`, `goToDefinition`).
25
26
 
26
27
  ## RETURN
27
28
  - Resumen: "Código implementado. Archivos modificados: X"
@@ -17,12 +17,13 @@ permission:
17
17
  ## READ
18
18
  - Código fuente del proyecto
19
19
  - Estructura de archivos principal
20
+ - `.openspec/brain.md` (Cerebro del Proyecto: memoria técnica y lecciones históricas)
20
21
 
21
22
  ## DO
22
- - Escanea la estructura del proyecto
23
+ - Escanea la estructura del proyecto y lee el `.openspec/brain.md` para entender el mapa técnico y reglas arquitectónicas previas.
23
24
  - Identifica archivos principales y sus propósitos
24
25
  - Detecta stack tecnológico y dependencias
25
- - Genera `diagnostics.md` en `.openspec/`
26
+ - Genera `diagnostics.md` en `.openspec/` orientando la exploración con el contexto del Cerebro.
26
27
 
27
28
  ## WRITE
28
29
  - `.openspec/diagnostics.md`
@@ -17,13 +17,14 @@ permission:
17
17
 
18
18
  ## READ
19
19
  - `.openspec/diagnostics.md` (si existe)
20
+ - `.openspec/brain.md` (Cerebro del Proyecto: aprendizajes acumulados y errores históricos)
20
21
  - Requerimiento del usuario
21
22
 
22
23
  ## DO
23
- - Analiza el requerimiento
24
- - Identifica archivos y funciones a modificar (rangos de líneas exactos)
25
- - **Si hay dudas técnicas**: usa `question` para preguntar al usuario (máx 3-5 preguntas)
26
- - Detecta si hay funciones duplicadas en múltiples archivos
24
+ - **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.
25
+ - **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**.
26
+ - Analiza el requerimiento e identifica los archivos y funciones a modificar (indicando rangos de líneas exactos).
27
+ - Detecta si hay funciones duplicadas en múltiples archivos.
27
28
 
28
29
  ## WRITE
29
30
  - `.openspec/changes/<change-name>/specs/spec.md`
@@ -18,16 +18,18 @@ permission:
18
18
  ## READ
19
19
  - `.openspec/changes/<change-name>/specs/spec.md`
20
20
  - Código implementado
21
+ - `.openspec/brain.md` (Cerebro del Proyecto: registro de fallas históricas y regresiones)
21
22
 
22
23
  ## DO
23
- 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.
24
- 2. **Ejecutar Linter & Auditorías**:
24
+ 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**.
25
+ 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.
26
+ 3. **Ejecutar Linter & Auditorías**:
25
27
  - **JS/TS**: Ejecuta `npm run lint` o `eslint` y las validaciones estáticas de DOM (`npx vitest run tests/static/...`).
26
28
  - **Python**: Ejecuta `flake8`, `pylint` o `black --check`.
27
29
  - **C++ (ESP32/Embedded)**: Ejecuta chequeos estáticos como `cppcheck` o verifica la compilación del firmware.
28
30
  - **Otros**: Usa el formateador/linter estándar del ecosistema detectado.
29
- 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.).
30
- 4. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
31
+ 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.).
32
+ 5. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
31
33
  5. **Autocorrección**: Corrige errores simples de sintaxis o fallas de test (máx 3 intentos).
32
34
 
33
35
  ## WRITE
package/index.js ADDED
@@ -0,0 +1 @@
1
+ export * from "./.opencode/tools/index.js";
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "zugzbot-sdd",
3
- "version": "1.5.12",
3
+ "version": "1.5.14",
4
4
  "description": "Zugzbot SDD Swarm - Spec-Driven Development Harness for OpenCode",
5
5
  "main": "index.js",
6
6
  "type": "module",