don-cheli-sdd 1.13.0

package/comandos/especdev/auditar-seguridad.md

@@ -0,0 +1,234 @@
+---
+description: Auditoría de seguridad estática del código (OWASP Top 10, SecDevOps)
+i18n: true
+---
+
+# /especdev:auditar-seguridad
+
+## Objetivo
+
+Realizar una auditoría de seguridad estática del código, identificando vulnerabilidades basadas en OWASP Top 10, exposición de datos sensibles, fallos de autenticación y problemas de configuración.
+
+## Uso
+
+```
+/especdev:auditar-seguridad                                # Auditar proyecto completo
+/especdev:auditar-seguridad @src/services/auth/            # Auditar módulo específico
+/especdev:auditar-seguridad --foco inyeccion               # Enfocarse en un tipo
+/especdev:auditar-seguridad --severidad critica            # Solo hallazgos críticos
+```
+
+## Categorías de Auditoría (OWASP Top 10 + extras)
+
+### A01: Broken Access Control
+
+```
+Buscar:
+  ❌ Endpoints sin middleware de autenticación
+  ❌ Rutas admin accesibles sin verificar rol
+  ❌ IDOR (acceso a recursos de otros usuarios via ID)
+  ❌ Falta de rate limiting en endpoints sensibles
+  ❌ CORS configurado como "*" en producción
+
+Verificar:
+  - Cada ruta tiene middleware de auth
+  - IDs de usuario se validan contra sesión
+  - Rate limiting en login, registro, reset-password
+  - CORS whitelist explícita
+```
+
+### A02: Cryptographic Failures
+
+```
+Buscar:
+  ❌ Passwords en plaintext o con hash débil (MD5, SHA1)
+  ❌ Tokens/secretos hardcoded en código
+  ❌ HTTP en vez de HTTPS para datos sensibles
+  ❌ JWT sin expiración o con secret débil
+  ❌ Datos sensibles en logs (passwords, tokens, PII)
+
+Verificar:
+  - Passwords con bcrypt/argon2id (cost factor ≥ 10)
+  - Secretos en variables de entorno o secret manager
+  - JWT con expiración razonable (≤ 1h access, ≤ 7d refresh)
+  - Logs sanitizados (sin PII)
+```
+
+### A03: Injection
+
+```
+Buscar:
+  ❌ SQL sin parametrizar (string concatenation)
+  ❌ NoSQL injection (operadores en queries)
+  ❌ Command injection (exec, spawn sin sanitizar)
+  ❌ XSS (innerHTML, dangerouslySetInnerHTML sin sanitizar)
+  ❌ Path traversal (../../../etc/passwd)
+  ❌ LDAP injection, XML injection
+
+Verificar:
+  - Queries parametrizadas o ORM
+  - Input sanitizado antes de exec/spawn
+  - Output encodado en templates
+  - Paths validados contra whitelist
+```
+
+### A04: Insecure Design
+
+```
+Buscar:
+  ❌ Falta de validación en puntos de entrada
+  ❌ Business logic bypassable
+  ❌ Sin límites en operaciones costosas
+  ❌ Datos sensibles en URL (query params)
+
+Verificar:
+  - Validación con Pydantic/Zod en cada endpoint
+  - Reglas de negocio en service layer (no en controller)
+  - Paginación y límites en queries
+  - Datos sensibles solo en body/headers
+```
+
+### A05-A10: Otras Categorías
+
+| Categoría | Qué Buscar |
+|-----------|-----------|
+| **A05: Security Misconfiguration** | Debug mode en prod, headers faltantes, default credentials |
+| **A06: Vulnerable Components** | Dependencias con CVEs conocidos |
+| **A07: Auth Failures** | Login sin brute-force protection, session fixation |
+| **A08: Data Integrity** | Deserialización insegura, falta de checksums |
+| **A09: Logging Failures** | Sin audit log para operaciones sensibles |
+| **A10: SSRF** | Requests a URLs proporcionadas por usuario sin validar |
+
+### Extra: Secretos y Configuración
+
+```
+Buscar:
+  ❌ .env commitado en git
+  ❌ API keys en código fuente
+  ❌ Credenciales en docker-compose.yml
+  ❌ Private keys en el repositorio
+  ❌ Tokens en comentarios o TODOs
+
+Verificar:
+  - .env en .gitignore
+  - .env.example sin valores reales
+  - Secrets en variable de entorno o secret manager
+  - git history limpio de secretos (git-secrets, truffleHog)
+```
+
+## Proceso de Auditoría
+
+```
+1. ESCANEAR — Análisis estático del código
+   ├── Patrones de vulnerabilidad por categoría
+   ├── Dependencias con vulnerabilidades conocidas
+   └── Configuración de seguridad
+
+2. CLASIFICAR — Severidad de cada hallazgo
+   ├── 🔴 Crítico: Explotable remotamente, impacto alto
+   ├── 🟠 Alto: Explotable con condiciones, impacto medio-alto
+   ├── 🟡 Medio: Requiere acceso o condiciones específicas
+   └── 🔵 Bajo: Mejora de seguridad, sin riesgo inmediato
+
+3. REPORTAR — Generar reporte estructurado
+
+4. PRIORIZAR — Recomendar orden de remediación
+```
+
+## Output
+
+```markdown
+## Auditoría de Seguridad: mi-proyecto
+
+**Fecha:** 2026-03-21
+**Alcance:** src/ (42 archivos, 3,200 LOC)
+**Auditor:** Don Cheli Security Audit v1.0
+
+### Resumen
+
+| Severidad | Cantidad |
+|-----------|----------|
+| 🔴 Crítico | 1 |
+| 🟠 Alto | 3 |
+| 🟡 Medio | 2 |
+| 🔵 Bajo | 4 |
+
+### Hallazgos
+
+#### 🔴 SEC-001: SQL Injection en búsqueda de productos
+**Archivo:** src/services/product_service.py:45
+**Categoría:** A03 (Injection)
+**Descripción:** Query construida con f-string sin parametrizar.
+```python
+# Vulnerable
+query = f"SELECT * FROM products WHERE name LIKE '%{search_term}%'"
+
+# Fix recomendado
+query = "SELECT * FROM products WHERE name LIKE %s"
+cursor.execute(query, (f"%{search_term}%",))
+```
+**Impacto:** Acceso total a la base de datos.
+**Remediación:** Usar query parametrizada o ORM.
+**Esfuerzo:** 15 min
+
+#### 🟠 SEC-002: JWT sin expiración
+**Archivo:** src/utils/jwt.py:12
+**Categoría:** A02 (Cryptographic Failures)
+**Descripción:** Token se genera sin campo `exp`.
+**Impacto:** Token válido indefinidamente si se filtra.
+**Remediación:** Agregar `exp: now() + 1h` para access token.
+**Esfuerzo:** 10 min
+
+#### ... (más hallazgos)
+
+### Verificaciones Pasadas ✅
+- Passwords hasheados con bcrypt (cost 12) ✅
+- CORS configurado con whitelist ✅
+- .env en .gitignore ✅
+- HTTPS enforced en producción ✅
+- Rate limiting en /login ✅
+
+### Recomendaciones de Remediación (por prioridad)
+1. SEC-001: SQL Injection → INMEDIATO
+2. SEC-002: JWT sin expiración → ANTES DE RELEASE
+3. SEC-003: ... → PRÓXIMO SPRINT
+```
+
+## Almacenamiento
+
+```
+.especdev/seguridad/
+├── auditoria-2026-03-21.md    # Reporte de auditoría
+└── _remediaciones.md           # Tracking de fixes
+```
+
+## Integración con Pipeline
+
+```
+/especdev:auditar-seguridad → reporte
+  → /especdev:desglosar → tareas de remediación
+  → /especdev:implementar → fixes con TDD
+  → /especdev:auditar-seguridad → verificar fixes
+```
+
+Se recomienda ejecutar **antes de cada PR** que toque:
+- Autenticación/autorización
+- Manejo de datos de usuario
+- Endpoints públicos
+- Configuración de infraestructura
+
+## Modelo Recomendado
+
+| Paso | Modelo | Razón |
+|------|--------|-------|
+| Escaneo de patrones | Sonnet | Comprensión de código |
+| Clasificación de severidad | Sonnet | Juicio técnico |
+| Recomendaciones de fix | Sonnet | Código seguro |
+
+## Guardrails
+
+- **Nunca** exponer hallazgos de seguridad en documentación pública
+- **Nunca** incluir exploits funcionales en el reporte (solo describir)
+- **Siempre** priorizar hallazgos críticos para remediación inmediata
+- **Siempre** verificar fixes con tests específicos de seguridad
+- **Siempre** re-auditar después de remediar

package/comandos/especdev/auditar.md

@@ -0,0 +1,15 @@
+---
+description: Auditar componentes del framework
+i18n: true
+---
+
+# /especdev:auditar
+
+## Uso
+
+```
+/especdev:auditar [componente]
+/especdev:auditar todo
+```
+
+Audita la integridad de comandos, habilidades y configuración del framework.

package/comandos/especdev/avance-rapido.md

@@ -0,0 +1,64 @@
+---
+description: Crear todos los artefactos de planificación de un golpe (fast-forward)
+i18n: true
+---
+
+# /especdev:avance-rapido
+
+## Objetivo
+
+Crear TODOS los artefactos de planificación de una vez cuando el alcance es claro. En vez de ir paso a paso (proponer → especificar → diseñar → desglosar), este comando genera todo de un golpe.
+
+> Adaptado de `/opsx:ff` (fast-forward) de OpenSpec.
+
+## Uso
+
+```
+/especdev:avance-rapido <nombre-del-cambio>
+/especdev:avance-rapido agregar-dark-mode
+```
+
+## Cuándo Usar
+
+| Situación | Comando |
+|-----------|---------|
+| Sabes exactamente qué quieres | `/especdev:avance-rapido` ← ESTE |
+| Requisitos poco claros, necesitas investigar | `/especdev:explorar` primero |
+| Quieres ir paso a paso revisando | `/especdev:proponer` + `/especdev:continuar` |
+
+## Comportamiento
+
+1. **Crear** carpeta de cambio en `.especdev/cambios/<nombre>/`
+2. **Generar** propuesta.md (intención, alcance, enfoque)
+3. **Generar** specs/ (delta specs con requisitos y escenarios)
+4. **Generar** diseño.md (decisiones de arquitectura)
+5. **Generar** tareas.md (desglose TDD)
+6. **Reportar** resumen
+
+## Output
+
+```
+=== Avance Rápido: agregar-dark-mode ===
+
+📁 Carpeta: .especdev/cambios/agregar-dark-mode/
+
+✅ propuesta.md — Intención y alcance definidos
+✅ specs/ui-tema.delta.md — 3 requisitos, 7 escenarios
+✅ diseño.md — 2 decisiones de arquitectura
+✅ tareas.md — 4 fases, 8 tareas
+
+¡Listo para implementar!
+→ /especdev:aplicar agregar-dark-mode
+```
+
+## Pipeline Rápido vs Completo
+
+```
+RÁPIDO (scope claro):
+/especdev:avance-rapido → /especdev:aplicar → /especdev:archivar
+
+COMPLETO (scope incierto):
+/especdev:explorar → /especdev:proponer → /especdev:especificar
+→ /especdev:clarificar → /especdev:diseñar → /especdev:desglosar
+→ /especdev:implementar → /especdev:revisar → /especdev:archivar
+```

package/comandos/especdev/cambios.md

@@ -0,0 +1,14 @@
+---
+description: Mostrar cambios desde la última sesión
+i18n: true
+---
+
+# /especdev:cambios
+
+## Uso
+
+```
+/especdev:cambios
+```
+
+Muestra un diff de los cambios realizados desde la última sesión registrada.

package/comandos/especdev/capturar.md

@@ -0,0 +1,61 @@
+---
+description: Capturar ideas y notas sin interrumpir el flujo de trabajo
+i18n: true
+---
+
+# /especdev:capturar
+
+## Objetivo
+
+Fire-and-forget de ideas durante cualquier fase de trabajo. Permite anotar pensamientos, bugs, mejoras o dudas sin pausar la tarea actual. El sistema clasifica automáticamente cada captura.
+
+## Uso
+
+```
+/especdev:capturar "Deberíamos agregar rate limiting en el login"
+/especdev:capturar --tipo bug "El endpoint /users devuelve 500 con deviceId vacío"
+/especdev:capturar --listar
+/especdev:capturar --procesar
+```
+
+## Clasificación Automática
+
+Cada captura se clasifica en una de 5 categorías:
+
+| Categoría | Emoji | Criterio | Acción |
+|-----------|-------|----------|--------|
+| `quick-task` | ⚡ | Resoluble en < 5 min, sin impacto en tarea actual | Ejecutar al terminar tarea actual |
+| `inject` | 💉 | Relevante para la tarea en curso | Incorporar al slice actual |
+| `defer` | 📋 | Importante pero no urgente | Agregar al backlog |
+| `replan` | 🔄 | Cambia el alcance o la estrategia | Pausar y replantear |
+| `note` | 📝 | Observación o aprendizaje | Guardar en conocimiento.md |
+
+## Comportamiento
+
+1. **Capturar** — Agregar entrada a `.especdev/capturas.md` con timestamp y clasificación
+2. **No interrumpir** — La tarea actual continúa sin pausa
+3. **Procesar** — Al completar la tarea actual (o con `--procesar`), revisar capturas pendientes
+4. **Clasificar** — El LLM clasifica automáticamente basándose en el contexto actual
+5. **Ejecutar** — Las `quick-task` se ejecutan inmediatamente; las `inject` se incorporan al plan
+
+## Archivo de Capturas
+
+```markdown
+# Capturas
+
+## Pendientes
+
+- [2026-03-22 14:30] ⚡ `quick-task` — Agregar rate limiting en login
+- [2026-03-22 14:45] 📋 `defer` — Evaluar Sportmonks como segundo provider
+- [2026-03-22 15:10] 💉 `inject` — El test de notifications.worker necesita mock de Expo SDK
+
+## Procesadas
+
+- [2026-03-22 13:00] 📝 `note` — Redis KEYS bloquea en producción → usar SCAN ✅
+```
+
+## Integración con Pipeline
+
+- Durante `/especdev:implementar`: las capturas se revisan al final de cada tarea
+- Durante `/especdev:revisar`: las capturas tipo `defer` se incluyen como observaciones
+- Con `/especdev:cerrar-sesion`: las capturas pendientes se transfieren al traspaso

package/comandos/especdev/cerrar-sesion.md

@@ -0,0 +1,88 @@
+---
+description: Ritual de cierre de sesión con auditoría, calidad, aprendizajes y contexto para la próxima sesión
+i18n: true
+---
+
+# /especdev:cerrar-sesion
+
+## Objetivo
+
+Ritual de fin de sesión que audita cambios, ejecuta checks de calidad, captura aprendizajes y produce un resumen para la próxima sesión. Evita el anti-patrón de cerrar el editor sin guardar contexto.
+
+> Adaptado de `wrap-up` de Pro-Workflow (rohitg00/pro-workflow).
+
+## Uso
+
+```
+/especdev:cerrar-sesion
+```
+
+## Checklist (obligatorio — no saltar pasos)
+
+### 1. 📋 Auditoría de Cambios
+- ¿Qué archivos se modificaron?
+- ¿Hay cambios sin commit?
+- ¿Quedaron TODOs en el código?
+- ¿Hay archivos temporales que limpiar?
+
+### 2. ✅ Check de Calidad
+- Ejecutar lint
+- Ejecutar typecheck
+- Ejecutar tests
+- ¿Todo pasa? ¿Hay warnings?
+
+### 3. 🧠 Captura de Aprendizajes
+- ¿Qué errores se cometieron?
+- ¿Qué patrones funcionaron bien?
+- Formatear como: `[APRENDER] Categoría: Regla`
+
+### 4. 🔮 Contexto para Próxima Sesión
+- ¿Cuál es la siguiente tarea lógica?
+- ¿Hay bloqueantes?
+- ¿Qué contexto preservar?
+
+### 5. 📝 Resumen
+- Un párrafo: qué se logró, estado actual, qué sigue
+
+## Output
+
+```markdown
+# Cierre de Sesión — 2026-03-21 16:45
+
+## Auditoría
+- Archivos modificados: 8
+- Commits: 3
+- Sin commit: 2 archivos (src/auth.ts, tests/auth.test.ts)
+- TODOs encontrados: 1 (src/auth.ts:45 — "TODO: handle refresh token")
+
+## Calidad
+- Lint: ✅ sin errors | ⚠️ 2 warnings
+- TypeCheck: ✅ pasa
+- Tests: ✅ 47/47
+- Coverage: 87%
+
+## Aprendizajes
+- [APRENDER] Testing: Siempre mockear el servicio de email en tests de auth
+- [APRENDER] Git: Hacer commits más pequeños — 3 archivos max
+
+## Próxima Sesión
+- Tarea: Implementar refresh token (TODO en auth.ts:45)
+- Bloqueante: Ninguno
+- Contexto: Branch feature/oauth, PR #23 abierto
+
+## Resumen
+Se completó el login con Google OAuth: 3 endpoints nuevos, 12 tests,
+integración con NextAuth v5. Falta el refresh token (TODO en auth.ts:45).
+PR #23 listo para review excepto por el refresh token.
+
+---
+🛑 ¿Cambios sin commit? Stash o commit antes de cerrar.
+✅ ¿Listo para cerrar sesión?
+```
+
+## Si Tests Fallan
+
+⚠️ **NO cerrar sesión con tests fallando.** Opciones:
+1. Corregir antes de cerrar
+2. Documentar el fallo en el handoff
+3. Crear issue para el próximo que lo agarre

package/comandos/especdev/clarificar.md

@@ -0,0 +1,98 @@
+---
+description: Detectar ambigüedades en una especificación, ejecutar Auto-QA y registrar respuestas
+i18n: true
+---
+
+# /especdev:clarificar
+
+## Objetivo
+
+Analizar una especificación Gherkin actuando como **Ingeniero QA Estricto**: detectar ambigüedades, ejecutar verificaciones automáticas de consistencia Schema↔Spec, y registrar las respuestas en el archivo `.feature`.
+
+> Mejorado con el protocolo Auto-QA de Specular (constitution.md §VIII)
+
+## Uso
+
+```
+/especdev:clarificar @specs/features/<dominio>/<Feature>.feature
+```
+
+## Comportamiento
+
+### Fase 1: Análisis de Ambigüedades (Original)
+
+1. **Leer** el archivo `.feature`
+2. **Analizar** cada escenario buscando:
+   - Términos ambiguos o no definidos
+   - Casos límite no cubiertos
+   - Validaciones implícitas
+   - Dependencias no mencionadas
+3. **Formular** hasta 5 preguntas dirigidas
+4. **Registrar** las respuestas en el archivo `.feature` como comentarios
+
+### Fase 2: Verificación Auto-QA (De Specular)
+
+Ejecutar automáticamente **SIN pedir instrucciones adicionales**:
+
+#### 2.1 Verificación de Consistencia Schema-Spec (DBML)
+
+- Escanear todos los campos mencionados en el Gherkin
+- Comparar contra el schema DBML en `specs/db_schema/<dominio>.dbml`
+- ❌ Error si nombres de campos no coinciden exactamente (ej: `user_id` vs `userId`)
+- ❌ Error si un campo `NOT NULL` en DBML no tiene escenario de validación en Gherkin
+
+#### 2.2 Verificación de Convención de Nombres
+
+- **Feature COMMAND:** Usar patrón de precondición + postcondición
+- **Feature QUERY:** Usar patrón de precondición + éxito
+
+#### 2.3 Auditoría de Escenarios Auto-Generados
+
+- Revisar escenarios tagueados `@auto_generado`
+- Marcar los que sean redundantes o lógicamente imposibles
+
+### Fase 3: Generar Checklist de Requisitos
+
+Generar automáticamente `requisitos.md` con evidencia citada para cada item.
+
+## Output
+
+```markdown
+=== Reporte Auto-QA ===
+
+Feature: CrearUsuario.feature
+
+## Ambigüedades Detectadas: 3
+1. ¿Qué longitud mínima/máxima debe tener la contraseña?
+2. ¿Se permite registro con proveedores OAuth (Google, GitHub)?
+3. ¿El email de bienvenida es síncrono o asíncrono?
+
+## Verificación Schema-Spec
+✅ PASS: Campo "email" coincide con usuario.dbml
+✅ PASS: Campo "password_hash" tiene escenario de validación
+❌ FAIL: Campo "nombre" en DBML es NOT NULL pero no tiene escenario de validación
+
+## Verificación de Convenciones
+✅ PASS: Feature COMMAND usa patrón precondición/postcondición
+⚠️ WARNING: Escenario "Contraseña débil" no verifica postcondición
+
+## Auditoría Auto-Generado
+✅ PASS: Sin escenarios redundantes
+
+## Resultado
+NO-AVANZAR (1 FAIL)
+→ Acción requerida: Agregar escenario de validación para campo "nombre"
+```
+
+## Transición de Estado
+
+```
+@borrador → (clarificar pasa Auto-QA) → @lista
+@borrador → (clarificar falla Auto-QA) → @borrador (corregir y re-clarificar)
+```
+
+## Puerta de Calidad Asociada
+
+Esta comando implementa la **Puerta 2+3** del pipeline:
+- Puerta 2: El header contiene `@lista` (solo si pasa)
+- Puerta 3: Reporte Auto-QA sin ❌ FALLA

package/comandos/especdev/comenzar.md

@@ -0,0 +1,105 @@
+---
+description: Iniciar tarea con nivel de complejidad auto-detectado (0-4)
+i18n: true
+---
+
+# /especdev:comenzar
+
+## Objetivo
+
+Iniciar una tarea detectando automáticamente el nivel de complejidad (0-4) y ejecutando el flujo apropiado.
+
+## Uso
+
+```
+/especdev:comenzar <descripción de la tarea>
+```
+
+## Auto-Detección de Nivel
+
+Evaluar cada dimensión de 0 a 4:
+
+```
+Alcance:     0=1 archivo  1=2-3 archivos  2=módulo  3=multi-módulo  4=sistema
+Incógnitas:  0=ninguna    1=menores       2=algunas 3=significativas 4=fundamentales
+Riesgo:      0=trivial    1=bajo          2=medio   3=alto           4=crítico
+Duración:    0=<30min     1=horas         2=días    3=1-2 semanas    4=semanas+
+
+Nivel = max(puntuaciones)  // Conservador: gana la dimensión más alta
+```
+
+## Niveles
+
+| Nivel | Nombre | Proceso |
+|-------|--------|---------|
+| **0** | Atómico | Ejecutar directamente |
+| **P** | PoC | Hipótesis → Construir → Evaluar → Veredicto |
+| **1** | Micro | Planear → Ejecutar → Verificar |
+| **2** | Estándar | 5 fases (sin Descubrimiento/Crecimiento) |
+| **3** | Complejo | 7 fases completas |
+| **4** | Producto | 7 fases + artefactos completos |
+
+**Detección de PoC:** Si la tarea es una pregunta ("¿se puede...?", "¿funciona...?", "¿vale la pena...?") o incluye palabras como "probar", "viabilidad", "validar", "explorar opción" → sugerir `/especdev:poc`.
+
+## Comportamiento
+
+1. **Analizar** la descripción de la tarea
+2. **Evaluar** las 4 dimensiones (alcance, incógnitas, riesgo, duración)
+3. **Determinar** nivel de complejidad
+4. **Mostrar** evaluación al usuario
+5. **Preguntar** si está de acuerdo o desea ajustar
+6. **Iniciar** flujo del nivel correspondiente
+
+## Ejemplo
+
+```bash
+/especdev:comenzar Implementar autenticación JWT con refresh tokens
+
+=== Evaluación de Complejidad ===
+
+Tarea: Implementar autenticación JWT con refresh tokens
+
+Alcance:    3 (multi-módulo: auth, middleware, database)
+Incógnitas: 2 (algunas: estrategia de refresh)
+Riesgo:     3 (alto: seguridad)
+Duración:   2 (días)
+
+→ Nivel detectado: 3 (Complejo)
+→ Proceso: 7 fases completas
+
+¿Proceder con Nivel 3? (s/n/ajustar)
+```
+
+## Escalamiento y Des-escalamiento
+
+- Si durante la ejecución se detecta mayor complejidad → escalar nivel
+- Si la complejidad resulta menor → des-escalar nivel
+- Regla de Desviación 4 → escalar al menos 1 nivel
+
+## Heurística de Scale-Adaptive Planning
+
+Inspirada en el framework BMAD: el nivel de planificación se ajusta automáticamente según la complejidad detectada.
+
+| Nivel detectado | Fases que se ejecutan | Fases que se SALTAN |
+|-----------------|----------------------|---------------------|
+| **0 — Atómico** | implementar → verificar | spec, clarificar, planificar, desglosar |
+| **1 — Micro** | especificar (light) → implementar → revisar | clarificar, planificar, desglosar, pseudocódigo |
+| **P — PoC** | hipótesis → construir → evaluar → veredicto | todo el pipeline formal |
+| **2 — Estándar** | especificar → clarificar → planificar → desglosar → implementar → revisar | pseudocódigo (opcional) |
+| **3 — Complejo** | especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+| **4 — Producto** | constitución → proponer → especificar → clarificar → pseudocódigo → planificar → diseñar → desglosar → implementar → revisar | nada se salta |
+
+**Principio:** No aplicar el mismo proceso a un micro-fix que a una migración de plataforma. La fricción innecesaria es tan dañina como la falta de estructura.
+
+### Señales de detección automática
+
+| Señal | Sube nivel | Baja nivel |
+|-------|-----------|------------|
+| Archivos afectados > 10 | +1 | |
+| Archivos afectados ≤ 2 | | -1 |
+| Cambio cruza módulos | +1 | |
+| Solo 1 módulo | | -1 |
+| Toca auth/pagos/seguridad | +1 | |
+| Solo wording/config | | -1 |
+| Dependencias externas nuevas | +1 | |
+| Sin dependencias nuevas | | 0 |