ostacky 0.5.6 → 0.5.7

package/assets/tests/e2e-scenarios.md

@@ -0,0 +1,502 @@
+# Ostacky E2E Test Scenarios
+
+Tests para verificar que Ostacky clasifica correctamente y rutea al flujo adecuado.
+
+## Setup
+
+```bash
+# Ensure CodeGraph is initialized
+codegraph init -i
+
+# Ensure Engram is running
+engram serve &
+
+# Start OpenCode with Ostacky agent
+opencode
+```
+
+---
+
+## Test 1: Level 0 — Cambio trivial → Superpowers (DIRECT)
+
+### Input del usuario
+```
+Agregá un tooltip al botón de "Submit" en el formulario de contacto
+```
+
+### Comportamiento esperado
+
+**Paso 1 — Recepción:**
+- Ostacky llama `start_request`
+- Ostacky analiza: 1 archivo, sin API pública, sin dependencias nuevas, <15 líneas
+- Clasificación: **Nivel 0**
+
+**Paso 2 — Pregunta al usuario:**
+```
+Esto es Nivel 0. Por defecto lo ejecuto directo con Superpowers. ¿O preferís spec?
+```
+
+**Paso 3 — Si usuario responde "directo" (default):**
+- Ostacky llama `record_discovery({ level: "0" })`
+- Ostacky llama `consume_route_decision({ choice: "DIRECT" })`
+- Ostacky ejecuta el cambio directamente usando:
+  - `Read` para leer el archivo
+  - `validate_edit` antes de editar
+  - `edit` para hacer el cambio
+  - `complete_task` para marcar completado
+
+**Paso 4 — Cierre:**
+- Tests pasan
+- Review rápido
+- `codegraph sync`
+- `implementation_complete` → `sync_complete`
+
+### Validación
+- [ ] No se invocó `thinking` skill
+- [ ] No se invocó `openspec-propose`
+- [ ] Cambio se hizo directamente con Superpowers
+- [ ] Controller termina en estado DONE
+
+---
+
+## Test 2: Level 0+1 — Cambio chico no trivial → Superpowers (DIRECT)
+
+### Input del usuario
+```
+Agregá validación de email en el formulario de registro — que rejecte emails inválidos y muestre un mensaje de error
+```
+
+### Comportamiento esperado
+
+**Paso 1 — Recepción:**
+- Ostacky analiza: 1-2 archivos, sin API pública nueva, <30 líneas
+- Clasificación: **Nivel 0+1**
+
+**Paso 2 — Pregunta al usuario:**
+```
+Esto es Nivel 0+1. Por defecto lo ejecuto directo con Superpowers. ¿O preferís spec?
+```
+
+**Paso 3 — Si usuario responde "directo":**
+- Mismo flujo que Test 1
+
+### Validación
+- [ ] Clasificación correcta como Nivel 0+1
+- [ ] Se sugiere Superpowers por defecto
+- [ ] Cambio se ejecuta directamente
+
+---
+
+## Test 3: Level 1+ — Cambio complejo → OpenSpec (SPEC)
+
+### Input del usuario
+```
+Necesito agregar autenticación con OAuth a la aplicación — que soporte Google y GitHub login, con sesiones persistentes
+```
+
+### Comportamiento esperado
+
+**Paso 1 — Recepción:**
+- Ostacky analiza: modifica API pública, agrega dependencias, impacto cross-module
+- Clasificación: **Nivel 1+**
+
+**Paso 2 — Pregunta al usuario:**
+```
+Esto es Nivel 1+ porque requiere autenticación completa con OAuth, sesiones, y múltiples providers. Recomiendo generar spec con OpenSpec. ¿O preferís ejecutar directo?
+```
+
+**Paso 3 — Si usuario responde "spec":**
+- Ostacky llama `record_discovery({ level: "1+" })`
+- Ostacky llama `consume_route_decision({ choice: "SPEC" })`
+
+**Paso 4 — Specification phase:**
+- Ostacky pregunta si quiere thinking o ir directo a spec
+- Si usuario elige thinking:
+  - Se invoca skill `thinking` (creative-design mode)
+  - thinking explora el codebase via CodeGraph
+  - thinking busca en Engram decisiones previas de auth
+  - thinking propone 2-3 approaches
+  - thinking escribe design doc
+  - thinking transiciona a `openspec-propose` (porque routing=SPEC)
+- Si usuario elige directo a spec:
+  - Se invoca `openspec-propose` directamente
+
+**Paso 5 — openspec-propose:**
+- Crea change directory
+- Genera proposal.md, design.md, tasks.md
+- llama `spec_complete`
+
+**Paso 6 — Execution:**
+- Se invoca `execution-mode-evaluation` para determinar INLINE vs SUBAGENT
+- Se ejecutan las tasks
+- `implementation_complete` → `sync_complete`
+
+### Validación
+- [ ] Clasificación correcta como Nivel 1+
+- [ ] Se sugiere OpenSpec
+- [ ] Se invocó `thinking` (si usuario eligió thinking)
+- [ ] thinking transicionó a `openspec-propose`
+- [ ] Se crearon artifacts en `openspec/changes/<name>/`
+- [ ] Controller termina en estado DONE
+
+---
+
+## Test 4: Level 1+ con requisitos vagos → Thinking first
+
+### Input del usuario
+```
+Quiero mejorar el sistema de notificaciones de la app
+```
+
+### Comportamiento esperado
+
+**Paso 1 — Clasificación:**
+- Requisitos vagos pero área amplia → **Nivel 1+**
+
+**Paso 2 — Pregunta:**
+```
+Esto es Nivel 1+ porque afecta múltiples módulos. Recomiendo generar spec con OpenSpec. ¿O preferís ejecutar directo?
+```
+
+**Paso 3 — Si usuario responde "spec":**
+- Ostacky pregunta: "Los requisitos están un poco vagos. ¿Querés que exploremos y diseñemos juntos (thinking) o preferís ir directo a generar el spec?"
+
+**Paso 4 — Si usuario elige thinking:**
+- Se invoca `thinking` (creative-design mode)
+- thinking pregunta: "¿Qué tipo de notificaciones tenés en mente?"
+- thinking explora el sistema actual de notificaciones
+- thinking propone approach
+- thinking escribe design doc
+- thinking transiciona a `openspec-propose`
+
+### Validación
+- [ ] Se detectaron requisitos vagos
+- [ ] Se ofreció thinking como opción
+- [ ] thinking exploró antes de diseñar
+- [ ] Flujo completo hasta openspec-propose
+
+---
+
+## Test 5: Exploración open-ended → Thinking (open-explore)
+
+### Input del usuario
+```
+¿Cómo funciona actualmente el sistema de permisos? Quiero entender si es escalable
+```
+
+### Comportamiento esperado
+
+**Paso 1 — Detección de modo:**
+- Señales: "cómo funciona", "entender", "querés entender"
+- Modo detectado: **open-explore**
+
+**Paso 2 — thinking ejecuta:**
+- `codegraph_explore` sobre el sistema de permisos
+- Mapea arquitectura actual
+- Identifica patrones
+- Presenta diagrama ASCII del flujo de permisos
+- Analiza escalabilidad
+
+**Paso 3 — Cierre:**
+- Usuario tiene lo que necesita
+- No se crea design doc (no es necesario)
+- No se invoca siguiente skill
+
+### Validación
+- [ ] Se detectó modo open-explore
+- [ ] No se forzó output de design doc
+- [ ] Se usó CodeGraph para explorar
+- [ ] Se presentó análisis estructurado
+
+---
+
+## Test 6: Cambio que parece simple pero es complejo
+
+### Input del usuario
+```
+Agregá un botón de "Export to CSV" en la tabla de usuarios
+```
+
+### Comportamiento esperado
+
+**Paso 1 — Análisis:**
+- Superficialmente: 1 archivo, botón simple → Nivel 0
+- Pero: exportar CSV puede implicar:
+  - Manejo de datos sensibles (usuarios)
+  - Permisos (¿quién puede exportar?)
+  - Performance (¿tabla grande?)
+  - Formato de datos (¿encoding, separadores?)
+
+**Paso 2 — Ostacky investiga:**
+- Usa CodeGraph para entender la tabla de usuarios
+- Descubre que hay 10,000+ usuarios
+- Descubre que hay datos sensibles (email, teléfono)
+- Clasificación revisada: **Nivel 1+**
+
+**Paso 3 — Pregunta:**
+```
+Esto es Nivel 1+ porque involucra datos sensibles de usuarios, permisos, y potencialmente performance con tablas grandes. Recomiendo generar spec con OpenSpec. ¿O preferís ejecutar directo?
+```
+
+### Validación
+- [ ] Ostacky no asumió que era trivial
+- [ ] Investigó antes de clasificar
+- [ ] Reclasificó si encontró complejidad oculta
+- [ ] Informó al usuario por qué es nivel superior
+
+---
+
+## Test 7: Transición thinking → openspec-propose
+
+### Input del usuario
+```
+Refactorizá el módulo de pagos para usar una abstracción de provider
+```
+
+### Flujo completo
+
+```
+1. Ostacky: start_request
+2. Ostacky: codegraph_explore (área de pagos)
+3. Ostacky: Clasifica como Level 1+
+4. Ostacky: Pregunta SPEC vs DIRECT
+5. Usuario: "SPEC"
+6. Ostacky: record_discovery({ level: "1+" })
+7. Ostacky: consume_route_decision({ choice: "SPEC" })
+8. Ostacky: Pregunta thinking vs directo a spec
+9. Usuario: "thinking"
+10. Ostacky: Invoca skill thinking (creative-design)
+11. thinking: engram_mem_search (pagos, providers)
+12. thinking: codegraph_explore (módulo de pagos)
+13. thinking: Propone 2-3 approaches
+14. thinking: Presenta diseño
+15. thinking: Usuario aprueba
+16. thinking: Escribe design doc
+17. thinking: Transition Rules → routing=SPEC → invoca openspec-propose
+18. openspec-propose: Crea change directory
+19. openspec-propose: Genera proposal.md
+20. openspec-propose: Genera design.md (o lee el de thinking)
+21. openspec-propose: Genera tasks.md
+22. openspec-propose: spec_complete
+23. Ostacky: Execution phase
+24. Ostacky: execution-mode-evaluation
+25. Ostacky: Ejecuta tasks
+26. Ostacky: sync_complete
+```
+
+### Validación
+- [ ] Flujo completo sin interrupciones
+- [ ] thinking transiciona correctamente a openspec-propose
+- [ ] No se perdió contexto entre skills
+- [ ] Controller mantiene estado correcto durante todo el flujo
+
+---
+
+## Test 8: Análisis de archivos compartidos en execution-mode-evaluation
+
+### Input del usuario
+```
+Agregá soporte para multi-idioma en el módulo de configuración — que soporte español, inglés y portugués
+```
+
+### tasks.md esperado
+
+```markdown
+### Task 1: Crear archivo de traducciones
+- [ ] Crear src/i18n/locales/es.json con traducciones en español
+
+### Task 2: Crear archivo de traducciones inglés
+- [ ] Crear src/i18n/locales/en.json con traducciones en inglés
+
+### Task 3: Crear configuración i18n
+- [ ] Crear src/i18n/config.ts que carga los archivos de traducción
+
+### Task 4: Integrar i18n en el componente de configuración
+- [ ] Modificar src/settings/Settings.tsx para usar traducciones
+```
+
+### Análisis esperado
+
+**Paso 1 — Construcción de sharedFiles:**
+```
+sharedFiles: {
+  "src/i18n/locales/es.json": ["task1"],
+  "src/i18n/locales/en.json": ["task2"],
+  "src/i18n/config.ts": ["task3"],
+  "src/settings/Settings.tsx": ["task4"]
+}
+```
+
+**Paso 2 — Construcción de fileClusters:**
+```
+fileClusters: [
+  ["task1"],    // es.json
+  ["task2"],    // en.json
+  ["task3"],    // config.ts
+  ["task4"]     // Settings.tsx
+]
+clusterCount: 4 (== taskCount)
+```
+
+**Paso 3 — Reglas aplicadas:**
+- clusterCount == 4, taskCount == 4 → Rule 3a/3b/3c aplica
+- Si estLines >= 30 y taskCount >= 3 → **Rule 3c: SUBAGENT-DRIVEN**
+
+**Output esperado al usuario:**
+```markdown
+## Análisis de modo de ejecución
+
+**Recomendación:** SUBAGENT_DRIVEN
+
+### Archivos compartidos entre tasks
+| Archivo | Tasks que lo modifican |
+|---------|------------------------|
+| src/i18n/locales/es.json | task1 |
+| src/i18n/locales/en.json | task2 |
+| src/i18n/config.ts | task3 |
+| src/settings/Settings.tsx | task4 |
+
+### Clusters detectados
+| Cluster | Tasks | Archivos |
+|---------|-------|----------|
+| A | task1 | src/i18n/locales/es.json |
+| B | task2 | src/i18n/locales/en.json |
+| C | task3 | src/i18n/config.ts |
+| D | task4 | src/settings/Settings.tsx |
+
+### Dependencias secuenciales
+- Ninguna detectada
+
+### Razón principal
+[Regla 3c]: 4 clusters independientes (== taskCount) → SUBAGENT-DRIVEN. Cada task corre en paralelo.
+
+### Estimación
+~60 líneas en 4 archivos
+```
+
+### Validación
+- [ ] sharedFiles muestra cada archivo y qué tasks lo modifican
+- [ ] fileClusters muestra las tareas agrupadas por archivos compartidos
+- [ ] La razón explica qué regla se aplicó y por qué
+- [ ] El usuario puede ver si hay archivos compartidos antes de confirmar
+
+---
+
+## Test 9: Archivos compartidos forzan INLINE
+
+### Input del usuario
+```
+Refactorizá el sistema de logging — extraer una interfaz común y actualizar todos los módulos que la usan
+```
+
+### tasks.md esperado
+
+```markdown
+### Task 1: Definir interfaz de logger
+- [ ] Crear src/logger/LoggerInterface.ts
+
+### Task 2: Implementar ConsoleLogger
+- [ ] Crear src/logger/ConsoleLogger.ts que implemente la interfaz
+
+### Task 3: Actualizar módulo de auth para usar la nueva interfaz
+- [ ] Modificar src/auth/auth.ts para usar LoggerInterface
+
+### Task 4: Actualizar módulo de pagos para usar la nueva interfaz
+- [ ] Modificar src/payments/payments.ts para usar LoggerInterface
+```
+
+### Análisis esperado
+
+**sharedFiles:**
+```
+sharedFiles: {
+  "src/logger/LoggerInterface.ts": ["task1"],
+  "src/logger/ConsoleLogger.ts": ["task2"],
+  "src/auth/auth.ts": ["task3"],
+  "src/payments/payments.ts": ["task4"]
+}
+```
+
+**fileClusters:**
+```
+fileClusters: [
+  ["task1"],    // interfaz
+  ["task2"],    // implementación
+  ["task3"],    // auth
+  ["task4"]     // pagos
+]
+clusterCount: 4
+```
+
+**Pero hay sequentialDeps:**
+```
+sequentialDeps: [
+  ["task1", "task2"],  // task2 necesita la interfaz de task1
+  ["task1", "task3"],  // task3 necesita la interfaz de task1
+  ["task1", "task4"]   // task4 necesita la interfaz de task1
+]
+```
+
+**Regla aplicada:**
+- clusterCount == 4, taskCount == 4
+- Hay deps entre clusters (task2, task3, task4 dependen de task1)
+- **Rule 2a: INLINE** — deps secuenciales entre clusters sin contrato explícito
+
+**Output esperado al usuario:**
+```markdown
+## Análisis de modo de ejecución
+
+**Recomendación:** INLINE
+
+### Archivos compartidos entre tasks
+| Archivo | Tasks que lo modifican |
+|---------|------------------------|
+| src/logger/LoggerInterface.ts | task1 |
+| src/logger/ConsoleLogger.ts | task2 |
+| src/auth/auth.ts | task3 |
+| src/payments/payments.ts | task4 |
+
+### Clusters detectados
+| Cluster | Tasks | Archivos |
+|---------|-------|----------|
+| A | task1 | src/logger/LoggerInterface.ts |
+| B | task2 | src/logger/ConsoleLogger.ts |
+| C | task3 | src/auth/auth.ts |
+| D | task4 | src/payments/payments.ts |
+
+### Dependencias secuenciales
+- task2 depende de task1 (necesita la interfaz definida)
+- task3 depende de task1 (necesita la interfaz definida)
+- task4 depende de task1 (necesita la interfaz definida)
+
+### Razón principal
+[Regla 2a]: 4 clusters pero hay dependencias secuenciales entre ellos sin contrato explícito → INLINE
+
+### Estimación
+~80 líneas en 4 archivos
+```
+
+### Validación
+- [ ] Las dependencias secuenciales se detectan correctamente
+- [ ] La razón explica por qué no se puede paralelizar
+- [ ] El usuario entiende que debe ejecutarse en orden secuencial
+
+---
+
+## Ejecución de tests
+
+### Test automatizado de configuración
+```bash
+bash assets/tests/validate-config.sh
+```
+
+### Test manual de comportamiento
+1. Iniciar OpenCode con Ostacky
+2. Ejecutar cada escenario
+3. Verificar cada checkbox de validación
+4. Reportar resultados en `assets/tests/results.md`
+
+### Criterio de éxito
+- Todos los tests automatizados pasan
+- Todos los escenarios manuales pasan
+- No hay regressions en flujos existentes