zugzbot-sdd 1.5.23 → 1.5.24
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.
- package/agents/sdd-builder.md +1 -0
- package/agents/sdd-tester.md +14 -4
- package/package.json +1 -1
package/agents/sdd-builder.md
CHANGED
|
@@ -27,6 +27,7 @@ permission:
|
|
|
27
27
|
## DO
|
|
28
28
|
- 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.
|
|
29
29
|
- Usa `edit` para parches quirúrgicos (prohibido reescribir archivos completos).
|
|
30
|
+
- **Pre-chequeo Local de Sintaxis**: Realiza un chequeo local rápido de sintaxis de tus archivos modificados antes de finalizar (ej: `node --check` para JS/GS, `python -m py_compile` para Python, o `npx tsc --noEmit` para TypeScript) para erradicar proactivamente errores básicos como paréntesis o llaves abiertas.
|
|
30
31
|
- **Escaneo SAST Quirúrgico**: Ejecuta `sdd_security_vulnerability_scanner` sobre tus archivos modificados antes de cerrar tu implementación.
|
|
31
32
|
- **Validación de Secretos**: Corre `sdd_secret_scanner` para asegurarte de no dejar tokens/passwords temporales de desarrollo.
|
|
32
33
|
- **Linter de Especificación**: Ejecuta `sdd_spec_compliance_linter` para certificar que todos los criterios de aceptación del Spec estén cubiertos.
|
package/agents/sdd-tester.md
CHANGED
|
@@ -34,15 +34,25 @@ permission:
|
|
|
34
34
|
## DO
|
|
35
35
|
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**.
|
|
36
36
|
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.
|
|
37
|
-
3. **
|
|
37
|
+
3. **Configuración Proactiva de Linter/Calidad**:
|
|
38
|
+
- Si el proyecto no cuenta con una configuración mínima de linter o validador de sintaxis estática (como `.eslintrc`, `tsconfig.json` o similar) o carece de dependencias básicas de validación, **DEBES configurar proactivamente** los archivos iniciales mínimos o instalar localmente los paquetes de desarrollo requeridos (`npm install --save-dev eslint` o configuraciones nativas ligeras) para asegurar que el entorno sea capaz de diagnosticar la calidad del código.
|
|
39
|
+
4. **Chequeo Obligatorio de Sintaxis y Compilación (Por Archivo Modificado)**:
|
|
40
|
+
- Identifica todos los archivos modificados en la sesión. Para cada archivo modificado, **ejecuta OBLIGATORIAMENTE un comando de chequeo de sintaxis o compilación en seco en base a su extensión** antes de intentar correr pruebas dinámicas complejas:
|
|
41
|
+
- **JavaScript (`.js`, `.jsx`, `.gs`)**: Ejecuta `node --check <ruta-del-archivo>` para validar la sintaxis general y detectar paréntesis, llaves o corchetes rotos, variables sin declarar, etc.
|
|
42
|
+
- **TypeScript (`.ts`, `.tsx`)**: Ejecutar `npx tsc --noEmit` o el compilador local aplicable para auditar tipos e integridad sintáctica.
|
|
43
|
+
- **Python (`.py`)**: Ejecuta `python -m py_compile <ruta-del-archivo>`.
|
|
44
|
+
- **JSON (`.json`)**: Ejecuta una verificación estructural sintáctica (ej: `node -e "JSON.parse(fs.readFileSync('<ruta-del-archivo>'))"`).
|
|
45
|
+
- **HTML (`.html`)**: Realiza análisis estructural o de balanceo de tags (ej. usando las herramientas de test locales).
|
|
46
|
+
- Si algún archivo modificado reporta un error de sintaxis o compilación, **BLOQUEA de inmediato la transición** (marcando success/blocked a `blocked`), a menos que sea un error simple corregible usando `sdd_sandbox_patcher`.
|
|
47
|
+
5. **Validación y Auditorías del Swarm**:
|
|
38
48
|
- Ejecuta `sdd_spec_compliance_linter` para cruzar requerimientos.
|
|
39
49
|
- Ejecuta `sdd_security_vulnerability_scanner` para detectar vulnerabilidades en el código.
|
|
40
50
|
- Corre `sdd_visual_regression_diff` para auditar la interfaz y estilos.
|
|
41
51
|
- Ejecuta `sdd_performance_regress_profiler` para medir latencias y rendimiento.
|
|
42
52
|
- Usa `sdd_diff_impact_analyzer` para calcular el radio de impacto final.
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
53
|
+
6. **Ejecutar Suite de Pruebas**: Corre la suite de tests nativos del proyecto (ej: `npm run test` / `npx vitest run`).
|
|
54
|
+
7. **Autocorrección con Patcher**: Si detectas fallos unitarios simples o de sintaxis menores, invoca `sdd_sandbox_patcher` para aplicar correcciones automáticas inmediatas sin retroceder de fase.
|
|
55
|
+
8. **Validación UI**: Ejecuta `sdd_ui_auditor` si el proyecto es una app web/frontend con visualización o HTML.
|
|
46
56
|
|
|
47
57
|
## WRITE
|
|
48
58
|
- `.openspec/changes/<change-name>/validation_report.md`
|