don-cheli-sdd 1.13.0

package/scripts/.claude/don-cheli/plantillas/especdev/isa.yml

@@ -0,0 +1,152 @@
+# ISA — Arquitectura de Conjunto de Instrucciones para BDD
+
+# Mapea tipos de pasos Gherkin a patrones de código de test.
+# Adaptado de Specular (pei9564/Specular) y traducido al español.
+#
+# Este archivo define la "arquitectura de instrucciones" que conecta
+# cada tipo de paso Gherkin con su implementación en tests.
+#
+# CÓMO MEJORA EL FRAMEWORK:
+# Sin ISA, el agente inventa patrones de test diferentes cada vez.
+# Con ISA, la generación de tests es CONSISTENTE y PREDECIBLE.
+# Cada escenario Gherkin mapea a un patrón de test bien definido.
+
+# ============================================================
+# Compartido: Contrato de conftest.py para TODOS los tipos
+# ============================================================
+compartido:
+  contexto_fixture:
+    descripcion: |
+      Diccionario mutable, portador de estado para Dado → Cuando → Entonces.
+      Proporcionado por tests/integracion/conftest.py como fixture de pytest.
+    claves:
+      - "contexto['datos_base_*']  ← Pasos Dado (datos mock de tablas Gherkin)"
+      - "contexto['resultado']     ← Paso Cuando (valor de retorno o excepción capturada)"
+      - "contexto['payload']       ← (tipos API) Pasos Cuando acumulan de tablas de datos"
+      - "contexto['respuesta']     ← (tipos API) asegurar_llamado() cachea la respuesta"
+      - "contexto['config']        ← (tipos Servicio) Pasos Dado configuran objeto de config"
+
+  helpers:
+    - nombre: "tabla_a_dicts"
+      ubicacion: "tests/integracion/conftest.py"
+      firma: "tabla_a_dicts(datatable: list[list[str]]) -> list[dict]"
+      descripcion: "Convierte datatable de pytest-bdd a list[dict]. NUNCA parsear datatables manualmente."
+
+  reglas_limite:
+    conftest_posee:
+      - "fixture contexto (dict[str, Any])"
+      - "helper tabla_a_dicts()"
+      - "fixtures app / client (solo tipos API)"
+      - "Pasos Dado comunes: entidades de fondo, middleware de auth"
+    archivo_feature_posee:
+      - "decoradores @scenario() (1:1 desde Gherkin)"
+      - "Pasos Dado específicos del feature"
+      - "Pasos Cuando específicos del feature"
+      - "Pasos Entonces específicos del feature"
+    prevencion_colision:
+      - "Nombres de función DEBEN incluir contexto de dominio o feature"
+      - "MAL:  cuando_crear_recurso, entonces_fallo"
+      - "BIEN: cuando_ejecutar_creacion_usuario, entonces_creacion_usuario_deberia_fallar"
+
+# ============================================================
+# Tipo API: Flujo HTTP client
+# ============================================================
+api:
+  flujo_contexto:
+    cuando_acumula: "contexto['payload']"
+    disparador_almacena: "contexto['respuesta']"
+    funcion_disparador: "asegurar_llamado(contexto, client, {{ mock_repo }})"
+
+  definiciones:
+    # --- CONFIGURACION_MOCK (Dado) ---
+    - patron: "el sistema tiene los siguientes {tipo_entidad}:"
+      tipo: "CONFIGURACION_MOCK"
+      contexto: "Dado"
+      notas: "Parsear tabla de datos en contexto para configuración de mock."
+
+    # --- LLAMADA_API (Cuando) ---
+    - patron: "el usuario crea {recurso}:"
+      tipo: "LLAMADA_API"
+      contexto: "Cuando"
+      notas: "Parsear tabla field/value en contexto['payload']."
+
+    # --- DISPARADOR_API ---
+    - patron: "(interno — llamado por pasos Entonces)"
+      tipo: "DISPARADOR_API"
+      contexto: "Entonces (interno)"
+      notas: |
+        asegurar_llamado() configura mocks, dispara el request HTTP,
+        y cachea la respuesta. Idempotente: dispara solo una vez por escenario.
+
+    # --- ASERCION_API (Entonces) ---
+    - patron: "el {recurso} debería crearse exitosamente"
+      tipo: "ASERCION_API"
+      contexto: "Entonces"
+      notas: "Verificar status 201 y campos del body."
+
+    - patron: "la creación debería fallar"
+      tipo: "ASERCION_API"
+      contexto: "Entonces"
+      notas: "Verificar status >= 400."
+
+    - patron: "el mensaje de error debería indicar \"{texto}\""
+      tipo: "ASERCION_API"
+      contexto: "Entonces"
+      notas: "Verificar que el mensaje de error contiene el texto."
+
+    # --- ASERCION_BD (Entonces) ---
+    - patron: "la tabla {tabla} debería contener:"
+      tipo: "ASERCION_BD"
+      contexto: "Entonces"
+      notas: "Verificar campos de respuesta contra tabla de datos."
+
+# ============================================================
+# Tipo Servicio: Llamada directa al servicio
+# ============================================================
+servicio:
+  flujo_contexto:
+    dado_acumula: "contexto['config']"
+    cuando_almacena: "contexto['resultado']"
+    descripcion: |
+      Sin HTTP client involucrado. Los pasos Cuando llaman al método del servicio directamente.
+      contexto["resultado"] almacena el valor de retorno o la excepción capturada.
+
+  definiciones:
+    # --- CONFIGURACION (Dado) ---
+    - patron: "el sistema está configurado con:"
+      tipo: "CONFIGURACION"
+      contexto: "Dado"
+      notas: "Parsear tabla de configuración en contexto['config']."
+
+    # --- LLAMADA_SERVICIO (Cuando) ---
+    - patron: "el sistema ejecuta {operacion}"
+      tipo: "LLAMADA_SERVICIO"
+      contexto: "Cuando"
+      notas: "Invocar método del servicio directamente. Capturar excepciones."
+
+    # --- ASERCION_SERVICIO (Entonces) ---
+    - patron: "la operación debería completarse exitosamente"
+      tipo: "ASERCION_SERVICIO"
+      contexto: "Entonces"
+      notas: "Verificar que resultado no es excepción."
+
+    - patron: "el resultado debería contener:"
+      tipo: "ASERCION_SERVICIO"
+      contexto: "Entonces"
+      notas: "Verificar campos del resultado contra tabla de datos."
+
+    # --- ASERCION_EXCEPCION (Entonces) ---
+    - patron: "la operación debería fallar"
+      tipo: "ASERCION_EXCEPCION"
+      contexto: "Entonces"
+      notas: "Verificar que resultado es una excepción."
+
+    - patron: "el tipo de error debería ser \"{tipo_excepcion}\""
+      tipo: "ASERCION_EXCEPCION"
+      contexto: "Entonces"
+      notas: "Verificar nombre de clase de excepción."
+
+    - patron: "el mensaje de error debería contener \"{texto}\""
+      tipo: "ASERCION_EXCEPCION"
+      contexto: "Entonces"
+      notas: "Verificar que el mensaje de excepción contiene el texto."

package/scripts/.claude/don-cheli/plantillas/especdev/plan.md

@@ -0,0 +1,35 @@
+# Plan del Proyecto
+
+## Fase 1: Descubrimiento
+- [ ] Validar el problema
+- [ ] Investigar soluciones existentes
+- [ ] Documentar hallazgos
+
+## Fase 2: Estrategia
+- [ ] Definir hoja de ruta
+- [ ] Establecer hitos
+- [ ] Tomar decisiones clave
+
+## Fase 3: Diseño
+- [ ] Arquitectura del sistema
+- [ ] Diseño de UX/UI
+- [ ] Especificaciones técnicas
+
+## Fase 4: Desarrollo
+- [ ] Implementar con TDD
+- [ ] Iterar sobre feedback
+
+## Fase 5: Calidad
+- [ ] Tests completos
+- [ ] Validación de rendimiento
+- [ ] Revisión de seguridad
+
+## Fase 6: Lanzamiento
+- [ ] Despliegue
+- [ ] Documentación final
+- [ ] Release notes
+
+## Fase 7: Crecimiento
+- [ ] Monitoreo
+- [ ] Feedback de usuarios
+- [ ] Iteración

package/scripts/.claude/don-cheli/plantillas/especdev/progreso.md

@@ -0,0 +1,7 @@
+# Progreso
+
+Log de sesión del proyecto. Se actualiza continuamente.
+
+---
+
+<!-- El progreso se registra automáticamente por el hook post-herramienta -->

package/scripts/.claude/don-cheli/plantillas/especdev/pt/config.yaml

@@ -0,0 +1,27 @@
+# Configuração do Projeto Don Cheli
+projeto:
+  nome: "meu-projeto"
+  tipo: "produto"  # produto|cli|app|biblioteca|servico|refatoracao|correcao|poc
+  descricao: ""
+  versao: "0.1.0"
+
+# Modelos de IA
+modelos:
+  padrao: sonnet
+  agentes:
+    planejador: opus
+    arquiteto: opus
+    executor: sonnet
+    revisor: opus
+    testador: sonnet
+    documentador: haiku
+    estimador: opus
+
+# Histórico de sessões
+historico:
+  habilitado: true
+  maxSessoes: 10
+  autoSalvar: true
+
+# Idioma
+idioma: "pt"

package/scripts/.claude/don-cheli/plantillas/especdev/pt/descobertas.md

@@ -0,0 +1,7 @@
+# Descobertas
+
+Descobertas e insights do projeto. Atualizado continuamente.
+
+---
+
+<!-- Descobertas são adicionadas aqui com /especdev:memorizar -->

package/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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/scripts/.claude/don-cheli/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"