ostacky 0.5.9 → 0.6.0

package/assets/tests/e2e-scenarios.md

@@ -1,502 +0,0 @@
-# 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