don-cheli-sdd 1.13.0

package/plantillas/especdev/pt/estado.md

@@ -0,0 +1,16 @@
+# Estado do Don Cheli
+
+## Atual
+- **Fase:** 1/7 (Descoberta)
+- **Tarefa:** Definir o problema
+- **Bloqueio:** Nenhum
+
+## Estatísticas Rápidas
+- **Progresso:** 0%
+- **Última Atualização:** [data]
+
+## Velocidade
+- Sessões concluídas: 0
+- Duração média: -
+- Fases concluídas: 0/7
+- Tempo restante estimado: -

package/plantillas/especdev/pt/plano.md

@@ -0,0 +1,35 @@
+# Plano do Projeto
+
+## Fase 1: Descoberta
+- [ ] Validar o problema
+- [ ] Pesquisar soluções existentes
+- [ ] Documentar descobertas
+
+## Fase 2: Estratégia
+- [ ] Definir roteiro
+- [ ] Estabelecer marcos
+- [ ] Tomar decisões chave
+
+## Fase 3: Design
+- [ ] Arquitetura do sistema
+- [ ] Design de UX/UI
+- [ ] Especificações técnicas
+
+## Fase 4: Desenvolvimento
+- [ ] Implementar com TDD
+- [ ] Iterar sobre feedback
+
+## Fase 5: Qualidade
+- [ ] Testes completos
+- [ ] Validação de desempenho
+- [ ] Revisão de segurança
+
+## Fase 6: Lançamento
+- [ ] Implantação
+- [ ] Documentação final
+- [ ] Notas de versão
+
+## Fase 7: Crescimento
+- [ ] Monitoramento
+- [ ] Feedback dos usuários
+- [ ] Iteração

package/plantillas/especdev/pt/progresso.md

@@ -0,0 +1,7 @@
+# Progresso
+
+Log de sessão do projeto. Atualizado continuamente.
+
+---
+
+<!-- O progresso é registrado automaticamente pelo hook pós-ferramenta -->

package/plantillas/especdev/pt/pseudocodigo.md

@@ -0,0 +1,35 @@
+# Pseudocódigo
+
+Lógica de alto nível agnóstica de linguagem/framework. Gerado DEPOIS de especificar e ANTES de planejar. Força o agente a raciocinar sobre a lógica sem comprometer tecnologia.
+
+## [Feature/Módulo]
+
+### Fluxo Principal
+```
+QUANDO usuário faz X
+  VALIDAR que Y
+  SE condição A
+    EXECUTAR ação B
+    PERSISTIR resultado em C
+    NOTIFICAR D
+  SENÃO
+    RETORNAR erro E
+```
+
+### Invariantes
+<!-- Condições que SEMPRE devem ser verdadeiras -->
+- [Invariante 1]
+- [Invariante 2]
+
+### Casos Limite
+<!-- O que acontece nas bordas -->
+- [Edge case 1]: [comportamento esperado]
+- [Edge case 2]: [comportamento esperado]
+
+### Dependências de Dados
+<!-- Quais dados são necessários e de onde vêm -->
+- [Dado 1] ← [Fonte]
+- [Dado 2] ← [Fonte]
+
+---
+*Gerado com `/especdev:pseudocodigo` entre especificar e planejar.*

package/plantillas/especdev/pt/runtime.md

@@ -0,0 +1,26 @@
+# Runtime
+
+Informações de execução do projeto: endpoints, variáveis de ambiente, serviços, portas.
+
+## Endpoints Locais
+| Serviço | URL | Porta |
+|---------|-----|-------|
+<!-- Auto-gerado durante /especdev:implementar -->
+
+## Variáveis de Ambiente Requeridas
+| Variável | Descrição | Origem |
+|----------|-----------|--------|
+<!-- Extraído do .env.example -->
+
+## Serviços Externos
+| Serviço | URL/Host | Plano | Rate Limit |
+|---------|----------|-------|------------|
+<!-- Documentado durante PoC e planejamento -->
+
+## Comandos de Desenvolvimento
+```bash
+# Iniciar
+# Testes
+# Build
+# Deploy
+```

package/plantillas/especdev/pt/trabalho-diferido.md

@@ -0,0 +1,17 @@
+# Trabalho Diferido
+
+Trabalho descoberto durante fixes, PoCs ou implementação que está FORA do escopo atual. Registrado aqui para não expandir o escopo e priorizado posteriormente.
+
+## Formato
+
+### TD-NNN: [Descrição curta]
+- **Descoberto em:** [Tarefa/PoC/Fix onde foi encontrado]
+- **Data:** YYYY-MM-DD
+- **Prioridade estimada:** alta | média | baixa
+- **Esforço estimado:** < 1h | 1-4h | 1d | 1w+
+- **Contexto:** [Por que surgiu e por que não foi resolvido agora]
+- **Status:** pendente | planejado | descartado
+
+---
+
+<!-- O trabalho diferido é registrado automaticamente durante /especdev:poc, /especdev:rapido e /especdev:implementar -->

package/plantillas/estimado-desarrollo.md

@@ -0,0 +1,43 @@
+# Estimado de Desarrollo: [Nombre del Proyecto]
+
+**Fecha:** [fecha]
+**Generado por:** `/especdev:estimar`
+
+## Resumen Ejecutivo
+
+| Métrica | Valor |
+|---------|-------|
+| **Esfuerzo total** | X-Y días/persona |
+| **Complejidad** | Baja/Media/Alta |
+| **Confianza** | X% |
+| **Modelo dominante** | [modelo] |
+
+## Desglose por Feature
+
+| Feature | Optimista | Esperado | Pesimista | Riesgo |
+|---------|-----------|----------|-----------|--------|
+| Feature 1 | Xd | Yd | Zd | Bajo/Medio/Alto |
+| Feature 2 | Xd | Yd | Zd | Bajo/Medio/Alto |
+
+## Detalle por Modelo
+
+### Puntos de Función: X días
+### Planning Poker IA: X días
+### COCOMO: X días
+### Histórico: X días / N/A
+
+## Riesgos que Afectan la Estimación
+
+| Riesgo | Probabilidad | Impacto | Mitigación |
+|--------|-------------|---------|------------|
+| Riesgo 1 | X% | +X días | [acción] |
+
+## Supuestos Clave
+
+- [supuesto 1]
+- [supuesto 2]
+
+## Recomendación
+
+Usar estimado **esperado** (X días) con buffer de 20% para imprevistos.
+→ **Total recomendado: X días/persona**

package/prompt.md

@@ -0,0 +1,16 @@
+# Don Cheli — Instrucciones para Amp
+
+## Identidad
+
+Asistente de desarrollo bajo el framework Don Cheli.
+
+## Contexto
+
+Lee `.especdev/` para entender el estado del proyecto.
+
+## Reglas
+
+1. TDD obligatorio
+2. Causa raíz primero
+3. Evidencia siempre
+4. Todo en español

package/reglas/constitucion.md

@@ -0,0 +1,122 @@
+# Constitución de Don Cheli
+
+> **Versión:** 2.0.0 | **Ratificada:** 2026-03-21
+>
+> La constitución gobierna TODO el código generado bajo Don Cheli.
+> Enriquecida con principios de Specular (pei9564/Specular).
+
+---
+
+## I. Gherkin es Rey (Fuente Única de Verdad)
+
+Los archivos `.feature` en `specs/features/` son los **ÚNICOS** artefactos de especificación. No se generan ni mantienen archivos spec.md separados.
+
+- Todas las decisiones de planificación, implementación y testing DEBEN rastrearse hasta Escenarios y Reglas definidos en el `.feature` correspondiente.
+- El orden del flujo DEBE ser: Leer Gherkin → Generar Step Definitions (Rojo) → Implementar Feature (Verde) → Refactorizar.
+- Cuando un archivo Gherkin es ambiguo o incompleto, el vacío DEBE resolverse actualizando el `.feature` — nunca inventando requisitos en artefactos posteriores.
+
+---
+
+## I-B. Schema como Verdad Viva (Ciclo de Vida DBML)
+
+Las definiciones de schema en `specs/db_schema/<dominio>.dbml` siguen un ciclo de dos fases:
+
+1. **Provisional** (tag `@provisional` presente): Auto-generado durante la fase Spec. Nombres de campos, tipos y restricciones son borradores.
+   - Los Escenarios en `.feature` DEBEN usar los nombres de campos provisionales tal como están.
+   - Los schemas provisionales DEBEN revisarse y ratificarse antes de la fase Plan.
+
+2. **Ratificado** (sin tag `@provisional`): Revisado durante Clarify o Plan. Una vez ratificado, el DBML se convierte en **Verdad Absoluta**.
+   - Cualquier feature posterior en el mismo dominio DEBE extender (no reemplazar) el schema ratificado.
+   - Renombrar campos después de la ratificación requiere una nota de migración en el plan.
+
+---
+
+## II. Precisión Quirúrgica (Colaboración en Equipo)
+
+Cada cambio DEBE ser el **cambio mínimo viable** requerido por la tarea actual.
+
+- Refactoring "de paso" de código no relacionado, helpers globales o componentes compartidos está **PROHIBIDO** salvo que se solicite explícitamente.
+- Cambios de formato, adición de comentarios y reordenamiento de imports fuera del alcance de la tarea NO DEBEN aparecer en diffs.
+
+---
+
+## III. Arquitectura Plug-and-Play (Modularidad)
+
+El código DEBE seguir el Principio Abierto/Cerrado: abierto para extensión, cerrado para modificación.
+
+- Nuevas features DEBEN entregarse como módulos, Objetos de Servicio o clases nuevas, no inflando funciones existentes.
+- La lógica de negocio DEBE encapsularse en Objetos de Servicio o clases especializadas. Controllers, Handlers y Routers DEBEN ser thin (solo delegación).
+- Concerns transversales (logging, auth, validación) DEBEN usar patrones de middleware o decoradores, no código inline.
+
+---
+
+## IV. La Regla "Las Vegas" (Aislamiento de Servicios y Mocking)
+
+> Lo que pasa dentro de un servicio SE QUEDA dentro de ese servicio.
+
+- Los tests DEBEN ejecutarse herméticamente — sin llamadas de red reales, sin estado de BD compartido, sin efectos secundarios en el filesystem.
+- Toda interacción con un servicio externo (HTTP APIs, gRPC, bases de datos, colas de mensajes) DEBE estar mockeada por defecto.
+- Las clases de servicio DEBEN aceptar dependencias via Inyección de Dependencias para que intercambiar mocks por clientes reales sea transparente.
+- Los tests end-to-end son la ÚNICA excepción y DEBEN marcarse explícitamente como tales.
+
+---
+
+## IV-B. Regla del Punto de Entrada (Alineamiento BDD-Arquitectura)
+
+La validación de reglas de negocio DEBE colocarse lo más cerca posible del punto de entrada que el paso `Cuando` del BDD invoca.
+
+**Test de litmus:** Para cada Escenario de fallo en el `.feature`, preguntar: _"¿El paso `Cuando` realmente se ejecuta en mi arquitectura?"_ Si la respuesta es no, la arquitectura viola esta regla.
+
+---
+
+## V. Estándares Modernos de Código
+
+- **Type hints** son obligatorios en toda firma de función.
+- **Modelos de validación** (Pydantic/Zod/equivalente) DEBEN usarse para DTOs y schemas — diccionarios/objetos crudos están PROHIBIDOS para datos estructurados.
+- Se DEBE seguir el style guide del lenguaje (PEP 8, ESLint, etc.). Donde el guide conflicta con legibilidad, gana legibilidad.
+
+---
+
+## VI. Adaptabilidad al Contexto
+
+Antes de generar código, el framework y toolchain DEBEN detectarse escaneando archivos de configuración (`package.json`, `requirements.txt`, `pyproject.toml`, etc.).
+
+El código generado NO DEBE introducir patrones que conflicten con las dependencias instaladas o convenciones establecidas del proyecto.
+
+---
+
+## VII. Codificación Defensiva y Manejo de Errores
+
+- Bloques `try...catch` desnudos que engullen errores están PROHIBIDOS. Toda excepción capturada DEBE logguearse con stack trace completo.
+- El código DEBE usar clases de excepción custom que mapeen a códigos de estado HTTP (ej: `RecursoNoEncontrado` → 404).
+- **Regla Stop-Loss:** Si una tarea falla (luz Roja) más de 3 veces, el trabajo DEBE detenerse y se DEBE solicitar guía humana. Los ciclos infinitos de fix-break están PROHIBIDOS.
+
+---
+
+## VIII. Protocolo de Clarificación (Auto-QA)
+
+Al ejecutar `/especdev:clarificar`, el agente actúa como **Ingeniero QA Estricto** y ejecuta obligatoriamente:
+
+1. **Verificación de Consistencia Schema-Spec:**
+   - Escanear todos los campos en el Gherkin
+   - Comparar contra el schema DBML
+   - Error si nombres no coinciden exactamente
+   - Error si campo `NOT NULL` no tiene escenario de validación
+
+2. **Verificación de Convención de Nombres:**
+   - Feature COMMAND: usar patrón precondición/postcondición
+   - Feature QUERY: usar patrón precondición/éxito
+
+3. **Auditoría Auto-Generado:**
+   - Revisar escenarios auto-generados
+   - Marcar los que sean redundantes o lógicamente imposibles
+
+**Formato de salida:** ✅ PASS / ⚠️ WARNING / ❌ FAIL
+
+---
+
+## Gobernanza
+
+- Esta constitución **supersede** todas las prácticas de desarrollo y guías de estilo dentro del repositorio.
+- Las enmiendas requieren: (1) Justificación documentada, (2) Revisión, (3) Plan de migración para código que ya no cumpla.
+- Todos los PRs y revisiones de código DEBEN verificar cumplimiento con estos principios.

package/reglas/hooks-parar.md

@@ -0,0 +1,102 @@
+# Stop Hooks — Verificaciones de Parada
+
+## Qué Son
+
+Los Stop Hooks son verificaciones automáticas que DEBEN pasar antes de que el agente pueda declarar una tarea como "completa". Son el equivalente a puertas de calidad de CI/CD pero ejecutadas por el agente en tiempo real.
+
+> Concepto de MELI: los agentes NO pueden terminar sin pasar validaciones.
+
+## Configuración
+
+```yaml
+# .especdev/hooks/parar.yml
+version: 1
+
+hooks:
+  # Obligatorios — si fallan, la tarea se BLOQUEA
+  obligatorios:
+    - nombre: "Lint"
+      comando: "npm run lint"
+      timeout: 60
+      
+    - nombre: "Type Check"
+      comando: "npx tsc --noEmit"
+      timeout: 120
+      
+    - nombre: "Tests Unitarios"
+      comando: "npm test -- --testPathPattern=unit"
+      timeout: 180
+      
+    - nombre: "Build"
+      comando: "npm run build"
+      timeout: 300
+
+  # Opcionales — si fallan, se advierte pero no se bloquea
+  opcionales:
+    - nombre: "Coverage"
+      comando: "npm run coverage -- --threshold 85"
+      timeout: 180
+      
+    - nombre: "Tests E2E"
+      comando: "npm run test:e2e"
+      timeout: 600
+
+  # Pre-commit — se ejecutan antes de cada commit
+  pre_commit:
+    - nombre: "Guardian"
+      comando: "/especdev:guardian"
+```
+
+## Flujo de Ejecución
+
+```
+/especdev:implementar
+    │
+    ├── ... (implementar tareas) ...
+    │
+    └── Ejecutar Stop Hooks
+        │
+        ├── 1. Lint ───── ✅ PASS (0.8s)
+        ├── 2. TypeCheck ── ✅ PASS (2.1s)
+        ├── 3. Tests ───── ❌ FAIL (1 fallo)
+        │   └── BLOQUEADO: 1 test falla
+        │       → Corregir y re-ejecutar
+        │
+        └── Re-ejecutar después de fix
+            ├── 3. Tests ───── ✅ PASS
+            ├── 4. Build ───── ✅ PASS
+            └── === TODOS LOS HOOKS PASAN ===
+                → Tarea marcada como ✅ COMPLETA
+```
+
+## Templates por Stack
+
+### Node.js / TypeScript
+```yaml
+hooks:
+  obligatorios:
+    - {nombre: "ESLint", comando: "npx eslint . --ext .ts,.tsx"}
+    - {nombre: "TypeScript", comando: "npx tsc --noEmit"}
+    - {nombre: "Vitest", comando: "npx vitest run"}
+    - {nombre: "Build", comando: "npm run build"}
+```
+
+### Python
+```yaml
+hooks:
+  obligatorios:
+    - {nombre: "Ruff", comando: "ruff check ."}
+    - {nombre: "MyPy", comando: "mypy app/ --strict"}
+    - {nombre: "Pytest", comando: "pytest -v"}
+    - {nombre: "Build", comando: "python -m build"}
+```
+
+### Go
+```yaml
+hooks:
+  obligatorios:
+    - {nombre: "Go Vet", comando: "go vet ./..."}
+    - {nombre: "Staticcheck", comando: "staticcheck ./..."}
+    - {nombre: "Go Test", comando: "go test ./..."}
+    - {nombre: "Go Build", comando: "go build ./..."}
+```

package/reglas/i18n.md

@@ -0,0 +1,47 @@
+# i18n — Internationalization Rules
+
+## Language Detection
+
+On every interaction, detect the user's configured language:
+
+1. Read the framework locale file at `${FRAMEWORK_HOME}/locale` (contains `es`, `en`, or `pt`)
+2. If not found, check `.especdev/config.yaml` → `framework.idioma`
+3. If neither exists, default to `es`
+
+## Language Behavior
+
+Once the locale is determined:
+
+| Locale | Communication | Code | Commits/PRs | Docs |
+|--------|--------------|------|-------------|------|
+| `es` | Español | English | Español | Español |
+| `en` | English | English | English | English |
+| `pt` | Português | English | Português | Português |
+
+**Code (variables, functions, comments) is ALWAYS in English regardless of locale.**
+
+## Locale Files
+
+Framework locale strings are in `locales/{es,en,pt}.json`. Use them for:
+- Phase names, status labels, verdicts
+- Installer messages
+- Command output templates
+- Review dimensions, severity labels
+- TDD cycle names, iron laws
+
+## How to Apply
+
+When generating output (estado.md, plan.md, hallazgos.md, propuesta.md, etc.):
+- Use the locale's terminology for headers, labels, and status text
+- Keep technical terms (e.g., TDD, OWASP, API, WebSocket) untranslated
+- Gherkin keywords follow the Gherkin i18n spec:
+  - `es`: Dado/Cuando/Entonces/Y
+  - `en`: Given/When/Then/And
+  - `pt`: Dado/Quando/Então/E
+
+## Changing Language
+
+The user can change the language at any time by:
+1. Editing `${FRAMEWORK_HOME}/locale` directly
+2. Re-running `scripts/instalar.sh` (re-prompts language selection)
+3. Setting `framework.idioma` in `.especdev/config.yaml`

package/reglas/leyes-hierro.md

@@ -0,0 +1,18 @@
+# Leyes de Hierro
+
+## No Negociable. Siempre se aplican.
+
+### 1. Ley TDD
+Todo código de producción REQUIERE tests.
+- `RED` → Escribir test que falla
+- `GREEN` → Código mínimo que pasa
+- `REFACTOR` → Mejorar sin cambiar comportamiento
+
+### 2. Ley de Debugging
+Primero la causa raíz, luego la corrección.
+1. REPRODUCIR → AISLAR → ENTENDER → CORREGIR → VERIFICAR
+
+### 3. Ley de Verificación
+Evidencia antes de afirmaciones.
+- ✅ "Tests pasan (evidencia adjunta)"
+- ❌ "Creo que funciona"

package/reglas/puertas-calidad.md

@@ -0,0 +1,87 @@
+# Puertas de Calidad (Quality Gates)
+
+## Cómo Mejoran el Framework
+
+Las puertas de calidad son **puntos de verificación obligatorios** entre fases del pipeline.
+Sin ellas, el pipeline avanza aunque haya problemas. Con ellas, cada fase DEBE cumplir
+criterios formales antes de pasar a la siguiente. Esto es clave para la **trazabilidad**.
+
+> Adaptado de Specular (pei9564/Specular → constitution.md §Quality Gates)
+> Alineado con spec-kit (github/spec-kit) — criterios de completitud y constitution check
+
+---
+
+## Las 6 Puertas
+
+| # | Puerta | Fase | Criterios |
+|---|--------|------|-----------|
+| 1 | **Completitud de Spec** | Después de `/especdev:especificar` | P1 tiene happy + sad path. Criterios de éxito definidos (≥2 medibles). Marcadores `[NECESITA CLARIFICACIÓN]` identificados |
+| 2 | **Estado de Spec** | Antes de `/especdev:planificar-tecnico` | Tag `@lista` presente. Specs `@borrador` NO pueden entrar a fase Plan |
+| 3 | **Verificación Clarify** | Después de `/especdev:clarificar` | Reporte Auto-QA sin ❌ FALLA. Todos los `[NECESITA CLARIFICACIÓN]` resueltos. Auditoría completada |
+| 4 | **Aprobación de Plan** | Después de `/especdev:planificar-tecnico` | Chequeo de constitución pasa (todos ✅). Contexto técnico completo. DBML ratificado. Tracking de complejidad documentado |
+| 5 | **Preparación de Tareas** | Después de `/especdev:desglosar` | Todas las tareas con IDs (`T###`). Rutas de archivos en tareas de implementación. Marcadores `[P]` de paralelismo asignados. 5 fases presentes |
+| 6 | **Merge de Código** | Después de `/especdev:implementar` | Tests verdes, lint limpio, type-check pasa, coverage ≥85%, sin diff no relacionado, regresión cross-fase pasa |
+
+## Verificación Automática
+
+Cada puerta se verifica automáticamente. Si falla, el framework **bloquea** el avance:
+
+```
+/especdev:especificar → [Puerta 1: ¿Completitud?]
+    ├── ✅ PASA → Continuar
+    └── ❌ FALLA → "Faltan escenarios sad path en P1" o "Criterios de éxito no definidos"
+
+/especdev:clarificar → [Puerta 2+3: ¿Estado? ¿Auto-QA?]
+    ├── ✅ PASA → Marcar @lista
+    └── ❌ FALLA → "Quedan 2 [NECESITA CLARIFICACIÓN] sin resolver"
+
+/especdev:planificar-tecnico → [Puerta 4: ¿Aprobación?]
+    ├── ✅ PASA → Continuar a tareas
+    └── ❌ FALLA → "Artículo III de constitución no cumplido" o "DBML provisional no ratificado"
+
+/especdev:desglosar → [Puerta 5: ¿Preparación?]
+    ├── ✅ PASA → Listo para implementar
+    └── ❌ FALLA → "Tarea T008 sin ruta de archivo" o "Falta Fase 5 (Verificación)"
+
+/especdev:implementar → [Puerta 6: ¿Merge?]
+    ├── ✅ PASA → Feature completa
+    └── ❌ FALLA → "3 tests fallan" o "Coverage 72% < 85%"
+```
+
+## Reporte de Puerta
+
+Cada puerta genera un reporte estructurado:
+
+```markdown
+## Puerta de Calidad: Completitud de Spec
+
+✅ PASS: P1 tiene happy path (Registro exitoso)
+✅ PASS: P1 tiene sad path (Email duplicado)
+✅ PASS: Criterios de éxito definidos (4 medibles)
+⚠️ WARNING: P2 solo tiene 1 escenario (recomendado: ≥2)
+✅ PASS: 3 marcadores [NECESITA CLARIFICACIÓN] identificados
+❌ FAIL: P3+ tiene escenario sin criterio de aceptación
+
+**Resultado: NO-AVANZAR (1 FAIL)**
+→ Acción requerida: Agregar Given/When/Then al escenario P3+ "Registro OAuth"
+```
+
+## Regresión Cross-Fase
+
+Al completar la Puerta 6 de una feature, se ejecuta **regresión automática** sobre features anteriores:
+
+```
+Feature actual: CrearUsuario (Puerta 6)
+  │
+  ├── Tests de CrearUsuario: ✅ 21/21
+  ├── Regresión: ListarProductos (feature anterior): ✅ 15/15
+  ├── Regresión: GestionarCarrito (feature anterior): ✅ 18/18
+  └── Resultado: ✅ SIN REGRESIÓN
+
+  ¿Algún test de feature anterior falla?
+  ├── NO → ✅ Puerta 6 pasa
+  └── SÍ → ❌ REGRESIÓN DETECTADA
+       └── Identificar qué test rompió y en qué feature
+```
+
+**Regla:** No se puede mergear código que rompe features anteriores. La regresión cross-fase es parte obligatoria de la Puerta 6.

package/reglas/reglas-desviacion.md

@@ -0,0 +1,36 @@
+# Reglas de Desviación
+
+## Las 5 Reglas
+
+Cuando encuentras algo inesperado durante la ejecución:
+
+| Regla | Disparador | Acción |
+|:-----:|-----------|--------|
+| **1** | Bug encontrado | 🔧 Auto-corregir inmediatamente |
+| **2** | Falta algo crítico (deps, config) | ➕ Auto-agregar inmediatamente |
+| **3** | Bloqueador (impide progreso) | 🚧 Auto-desbloquear inmediatamente |
+| **4** | Cambio arquitectónico | ⛔ **PARAR Y PREGUNTAR** |
+| **5** | Mejora (nice-to-have) | 📝 Registrar en ISSUES.md |
+
+## Distribución de Autonomía
+
+```
+AUTÓNOMO (solo hacerlo):
+├── Regla 1: Bug → Corregir
+├── Regla 2: Faltante → Agregar
+├── Regla 3: Bloqueador → Desbloquear
+└── Regla 5: Mejora → Registrar
+
+HUMANO REQUERIDO (parar y preguntar):
+└── Regla 4: Cambio arquitectónico
+```
+
+## Guía Rápida de Decisión
+
+```
+¿Puedo corregir esto en < 5 min sin cambiar cómo las cosas trabajan juntas?
+├── SÍ → Reglas 1, 2 o 3 (auto-manejar)
+└── NO → ¿Necesita una decisión de diseño?
+          ├── SÍ → Regla 4 (PARAR y PREGUNTAR)
+          └── NO → Regla 5 (Registrar y continuar)
+```