theus-cli-linux-x64 0.2.84

package/vendor/theus-arsenal/rules/common/code-review.md

@@ -0,0 +1,123 @@
+# Estándares de revisión de código
+
+## Propósito
+
+La revisión de código garantiza calidad, seguridad y mantenibilidad antes de que el código se fusione. Esta regla define cuándo y cómo realizar revisiones de código.
+
+## Cuándo revisar
+
+**Disparadores de revisión OBLIGATORIOS:**
+
+- Después de escribir o modificar código
+- Antes de cualquier commit a ramas compartidas
+- Cuando se modifica código sensible en seguridad (autenticación, pagos, datos de usuario)
+- Cuando se realizan cambios arquitectónicos
+- Antes de fusionar pull requests
+
+**Requisitos previos a la revisión:**
+
+Antes de solicitar una revisión, asegúrate de que:
+
+- Todas las verificaciones automáticas (CI/CD) están pasando
+- Los conflictos de merge están resueltos
+- La rama está actualizada respecto a la rama de destino
+
+## Checklist de revisión
+
+Antes de marcar el código como completo:
+
+- [ ] El código es legible y tiene buenos nombres
+- [ ] Las funciones están enfocadas (<50 líneas)
+- [ ] Los archivos son cohesivos (<800 líneas)
+- [ ] Sin anidamiento profundo (>4 niveles)
+- [ ] Los errores se manejan explícitamente
+- [ ] Sin secretos ni credenciales hardcodeados
+- [ ] Sin console.log ni sentencias de depuración
+- [ ] Existen tests para la nueva funcionalidad
+- [ ] La cobertura de tests alcanza el mínimo del 80%
+
+## Disparadores de revisión de seguridad
+
+**DETENTE y usa el agente revisor-seguridad cuando haya:**
+
+- Código de autenticación o autorización
+- Manejo de entrada de usuario
+- Consultas a base de datos
+- Operaciones sobre el sistema de archivos
+- Llamadas a APIs externas
+- Operaciones criptográficas
+- Código de pagos o financiero
+
+## Niveles de severidad de la revisión
+
+| Nivel | Significado | Acción |
+|-------|-------------|--------|
+| CRÍTICO | Vulnerabilidad de seguridad o riesgo de pérdida de datos | **BLOQUEAR** — debe corregirse antes del merge |
+| ALTO | Bug o problema de calidad significativo | **ADVERTIR** — debería corregirse antes del merge |
+| MEDIO | Preocupación de mantenibilidad | **INFO** — considerar corregirlo |
+| BAJO | Estilo o sugerencia menor | **NOTA** — opcional |
+
+## Uso de agentes
+
+Usa estos agentes para revisar código:
+
+| Agente | Propósito |
+|--------|-----------|
+| **revisor-codigo** | Calidad general del código, patrones, buenas prácticas |
+| **revisor-seguridad** | Vulnerabilidades de seguridad, OWASP Top 10 |
+| **revisor-typescript** | Problemas específicos de TypeScript/JavaScript |
+| **revisor-python** | Problemas específicos de Python |
+| **revisor-go** | Problemas específicos de Go |
+
+## Flujo de trabajo de revisión
+
+```
+1. Ejecuta git diff para entender los cambios
+2. Revisa primero el checklist de seguridad
+3. Revisa el checklist de calidad de código
+4. Ejecuta los tests relevantes
+5. Verifica cobertura >= 80%
+6. Usa el agente apropiado para una revisión detallada
+```
+
+## Problemas comunes a detectar
+
+### Seguridad
+
+- Credenciales hardcodeadas (API keys, contraseñas, tokens)
+- Inyección SQL (concatenación de strings en consultas)
+- Vulnerabilidades XSS (entrada de usuario sin escapar)
+- Path traversal (rutas de archivo sin sanear)
+- Falta de protección CSRF
+- Bypasses de autenticación
+
+### Calidad de código
+
+- Funciones grandes (>50 líneas) — dividir en más pequeñas
+- Archivos grandes (>800 líneas) — extraer módulos
+- Anidamiento profundo (>4 niveles) — usar retornos tempranos
+- Manejo de errores ausente — manejar explícitamente
+- Patrones de mutación — preferir operaciones inmutables
+- Falta de tests — añadir cobertura de tests
+
+### Rendimiento
+
+- Consultas N+1 — usar JOINs o batching
+- Falta de paginación — añadir LIMIT a las consultas
+- Consultas sin límite — añadir restricciones
+- Falta de caché — cachear operaciones costosas
+
+## Criterios de aprobación
+
+- **Aprobar**: sin problemas CRÍTICOS ni ALTOS
+- **Advertencia**: solo problemas ALTOS (fusionar con precaución)
+- **Bloquear**: se encontraron problemas CRÍTICOS
+
+## Integración con otras reglas
+
+Esta regla funciona junto con:
+
+- [testing.md](testing.md) — requisitos de cobertura de tests
+- [security.md](security.md) — checklist de seguridad
+- [git-workflow.md](git-workflow.md) — estándares de commits
+- [agents.md](agents.md) — delegación a agentes

package/vendor/theus-arsenal/rules/common/coding-style.md

@@ -0,0 +1,90 @@
+# Estilo de código
+
+## Inmutabilidad (CRÍTICO)
+
+Crea SIEMPRE objetos nuevos; NUNCA mutes los existentes:
+
+```
+// Pseudocódigo
+MAL:      modify(original, field, value) → modifica el original en el sitio
+CORRECTO: update(original, field, value) → devuelve una copia nueva con el cambio
+```
+
+Justificación: los datos inmutables evitan efectos secundarios ocultos, facilitan la depuración y permiten concurrencia segura.
+
+## Principios fundamentales
+
+### KISS (Keep It Simple)
+
+- Prefiere la solución más simple que realmente funcione
+- Evita la optimización prematura
+- Optimiza para la claridad, no para la astucia
+
+### DRY (Don't Repeat Yourself)
+
+- Extrae la lógica repetida en funciones o utilidades compartidas
+- Evita la deriva de implementaciones por copiar y pegar
+- Introduce abstracciones cuando la repetición es real, no especulativa
+
+### YAGNI (You Aren't Gonna Need It)
+
+- No construyas funcionalidades ni abstracciones antes de que se necesiten
+- Evita la generalidad especulativa
+- Empieza simple y refactoriza cuando la presión sea real
+
+## Organización de archivos
+
+MUCHOS ARCHIVOS PEQUEÑOS > POCOS ARCHIVOS GRANDES:
+- Alta cohesión, bajo acoplamiento
+- 200-400 líneas es lo típico, 800 como máximo
+- Extrae utilidades de los módulos grandes
+- Organiza por funcionalidad/dominio, no por tipo
+
+## Manejo de errores
+
+Maneja SIEMPRE los errores de forma exhaustiva:
+- Maneja los errores explícitamente en cada nivel
+- Ofrece mensajes de error amigables en el código de cara a la interfaz
+- Registra el contexto detallado del error en el lado del servidor
+- Nunca silencies errores sin más
+
+## Validación de entrada
+
+Valida SIEMPRE en las fronteras del sistema:
+- Valida toda entrada de usuario antes de procesarla
+- Usa validación basada en esquemas cuando esté disponible
+- Falla rápido con mensajes de error claros
+- Nunca confíes en datos externos (respuestas de API, entrada de usuario, contenido de archivos)
+
+## Convenciones de nombres
+
+- Variables y funciones: `camelCase` con nombres descriptivos
+- Booleanos: prefiere prefijos `is`, `has`, `should` o `can`
+- Interfaces, tipos y componentes: `PascalCase`
+- Constantes: `UPPER_SNAKE_CASE`
+- Hooks personalizados: `camelCase` con prefijo `use`
+
+## Malos olores de código a evitar
+
+### Anidamiento profundo
+
+Prefiere retornos tempranos sobre condicionales anidados en cuanto la lógica empiece a apilarse.
+
+### Números mágicos
+
+Usa constantes con nombre para umbrales, retardos y límites con significado.
+
+### Funciones largas
+
+Divide las funciones grandes en piezas enfocadas con responsabilidades claras.
+
+## Checklist de calidad de código
+
+Antes de marcar el trabajo como completo:
+- [ ] El código es legible y tiene buenos nombres
+- [ ] Las funciones son pequeñas (<50 líneas)
+- [ ] Los archivos están enfocados (<800 líneas)
+- [ ] Sin anidamiento profundo (>4 niveles)
+- [ ] Manejo de errores adecuado
+- [ ] Sin valores hardcodeados (usa constantes o configuración)
+- [ ] Sin mutación (se usan patrones inmutables)

package/vendor/theus-arsenal/rules/common/development-workflow.md

@@ -0,0 +1,44 @@
+# Flujo de trabajo de desarrollo
+
+> Este archivo extiende [common/git-workflow.md](./git-workflow.md) con el proceso completo de desarrollo de funcionalidades que ocurre antes de las operaciones de git.
+
+El flujo de implementación de funcionalidades describe la línea de trabajo: investigación, planificación, TDD, revisión de código y, después, el commit a git.
+
+## Flujo de implementación de funcionalidades
+
+0. **Investigar y reutilizar** _(obligatorio antes de cualquier implementación nueva)_
+   - **Primero, búsqueda de código en GitHub:** ejecuta `gh search repos` y `gh search code` para encontrar implementaciones existentes, plantillas y patrones antes de escribir nada nuevo.
+   - **Segundo, documentación de librerías:** consulta la documentación oficial del proveedor para confirmar el comportamiento de las APIs, el uso de los paquetes y los detalles específicos de cada versión antes de implementar. Para el código del propio proyecto, apóyate en Ñaupa (`search_graph`, `trace_path`, `get_architecture`).
+   - **Búsqueda web nativa solo cuando lo anterior no baste:** usa la búsqueda web nativa de Theus para investigación o descubrimiento más amplios, después de agotar GitHub y la documentación primaria.
+   - **Revisa los registros de paquetes:** busca en npm, PyPI, crates.io y otros registros antes de escribir código de utilidad. Prefiere librerías probadas en batalla sobre soluciones artesanales.
+   - **Busca implementaciones adaptables:** localiza proyectos open source que resuelvan el 80% o más del problema y puedan bifurcarse, portarse o envolverse.
+   - Prefiere adoptar o portar un enfoque probado en lugar de escribir código totalmente nuevo cuando cumpla el requisito.
+
+1. **Planificar primero**
+   - Usa el agente **planificador** para crear el plan de implementación
+   - Genera documentos de planificación antes de programar: PRD, arquitectura, diseño de sistema, documento técnico, lista de tareas
+   - Identifica dependencias y riesgos
+   - Divide el trabajo en fases
+
+2. **Enfoque TDD**
+   - Usa el agente **guia-tdd**
+   - Escribe los tests primero (ROJO)
+   - Implementa para que los tests pasen (VERDE)
+   - Refactoriza (MEJORA)
+   - Verifica una cobertura del 80% o más
+
+3. **Revisión de código**
+   - Usa el agente **revisor-codigo** inmediatamente después de escribir código
+   - Atiende los problemas CRÍTICOS y ALTOS
+   - Corrige los problemas MEDIOS cuando sea posible
+
+4. **Commit y push**
+   - Mensajes de commit detallados
+   - Sigue el formato de conventional commits
+   - Consulta [git-workflow.md](./git-workflow.md) para el formato de mensajes de commit y el proceso de PR
+
+5. **Verificaciones previas a la revisión**
+   - Verifica que todas las comprobaciones automáticas (CI/CD) pasan
+   - Resuelve cualquier conflicto de merge
+   - Asegúrate de que la rama está actualizada respecto a la rama de destino
+   - Solicita la revisión solo después de que estas verificaciones pasen

package/vendor/theus-arsenal/rules/common/git-workflow.md

@@ -0,0 +1,24 @@
+# Flujo de trabajo de git
+
+## Formato de mensajes de commit
+```
+<type>: <description>
+
+<cuerpo opcional>
+```
+
+Tipos: feat, fix, refactor, docs, test, chore, perf, ci
+
+Nota: para desactivar la atribución de coautoría en los commits, establece `"includeCoAuthoredBy": false` en `~/.theus/settings.json` (Theus añade `Co-Authored-By` por defecto; este paquete de reglas no incluye esa configuración de fábrica).
+
+## Flujo de trabajo de pull requests
+
+Al crear PRs:
+1. Analiza el historial completo de commits (no solo el último commit)
+2. Usa `git diff [rama-base]...HEAD` para ver todos los cambios
+3. Redacta un resumen completo del PR
+4. Incluye un plan de pruebas con TODOs
+5. Haz push con el flag `-u` si la rama es nueva
+
+> Para el proceso completo de desarrollo (planificación, TDD, revisión de código) previo a las operaciones de git,
+> consulta [development-workflow.md](./development-workflow.md).

package/vendor/theus-arsenal/rules/common/hooks.md

@@ -0,0 +1,32 @@
+# Sistema de hooks
+
+## Tipos de hooks
+
+- **PreToolUse**: antes de ejecutar una herramienta (validación, modificación de parámetros)
+- **PostToolUse**: después de ejecutar una herramienta (autoformato, comprobaciones)
+- **Stop**: al finalizar la respuesta de la sesión (verificación final)
+
+Theus también soporta los eventos **PostToolUseFailure**, **PreCompact**, **SessionStart** y **SessionEnd**.
+
+## Permisos de auto-aceptación
+
+Úsalos con precaución:
+- Actívalos para planes confiables y bien definidos
+- Desactívalos para trabajo exploratorio
+- Nunca uses el flag que omite peligrosamente todos los permisos
+- Configura `allowedTools` en `~/.theus.json` en su lugar
+
+## Buenas prácticas de TodoWrite
+
+Usa la herramienta TodoWrite para:
+- Seguir el progreso en tareas de varios pasos
+- Verificar la comprensión de las instrucciones
+- Permitir corrección de rumbo en tiempo real
+- Mostrar pasos de implementación granulares
+
+La lista de tareas revela:
+- Pasos fuera de orden
+- Elementos faltantes
+- Elementos extra innecesarios
+- Granularidad equivocada
+- Requisitos malinterpretados

package/vendor/theus-arsenal/rules/common/patterns.md

@@ -0,0 +1,31 @@
+# Patrones comunes
+
+## Proyectos esqueleto
+
+Al implementar funcionalidad nueva:
+1. Busca proyectos esqueleto probados en batalla
+2. Usa agentes en paralelo para evaluar las opciones:
+   - Evaluación de seguridad
+   - Análisis de extensibilidad
+   - Puntuación de relevancia
+   - Planificación de la implementación
+3. Clona la mejor opción como base
+4. Itera dentro de una estructura probada
+
+## Patrones de diseño
+
+### Patrón Repository
+
+Encapsula el acceso a datos detrás de una interfaz consistente:
+- Define operaciones estándar: findAll, findById, create, update, delete
+- Las implementaciones concretas manejan los detalles de almacenamiento (base de datos, API, archivo, etc.)
+- La lógica de negocio depende de la interfaz abstracta, no del mecanismo de almacenamiento
+- Permite intercambiar fuentes de datos con facilidad y simplifica el testing con mocks
+
+### Formato de respuesta de API
+
+Usa un envoltorio consistente para todas las respuestas de la API:
+- Incluye un indicador de éxito/estado
+- Incluye la carga de datos (nula en caso de error)
+- Incluye un campo de mensaje de error (nulo en caso de éxito)
+- Incluye metadatos para respuestas paginadas (total, page, limit)

package/vendor/theus-arsenal/rules/common/performance.md

@@ -0,0 +1,53 @@
+# Optimización de rendimiento
+
+## Estrategia de selección de modelo
+
+**Modelo económico del catálogo Theus** (gran parte de la capacidad del modelo estándar, a una fracción del costo):
+- Agentes ligeros con invocaciones frecuentes
+- Pair programming y generación de código
+- Agentes worker en sistemas multiagente
+
+**Modelo estándar del catálogo Theus** (el caballo de batalla para programar):
+- Trabajo de desarrollo principal
+- Orquestación de flujos multiagente
+- Tareas de programación complejas
+
+**Modelo premium del catálogo Theus** (razonamiento más profundo):
+- Decisiones arquitectónicas complejas
+- Requisitos de razonamiento máximos
+- Tareas de investigación y análisis
+
+## Gestión de la ventana de contexto
+
+Evita el último 20% de la ventana de contexto para:
+- Refactorizaciones a gran escala
+- Implementación de funcionalidades que abarcan varios archivos
+- Depuración de interacciones complejas
+
+Tareas menos sensibles al contexto:
+- Ediciones de un solo archivo
+- Creación de utilidades independientes
+- Actualizaciones de documentación
+- Corrección de bugs simples
+
+## Pensamiento extendido + modo plan
+
+El pensamiento extendido reserva presupuesto adicional de tokens para el razonamiento interno del modelo.
+
+Controla el pensamiento extendido mediante:
+- **Configuración**: la opción de pensamiento en la configuración de `~/.theus/`
+- **Tope de presupuesto**: `export MAX_THINKING_TOKENS=10000` (bash) o `$env:MAX_THINKING_TOKENS = "10000"` (PowerShell)
+
+Para tareas complejas que requieren razonamiento profundo:
+1. Asegúrate de que el pensamiento extendido esté habilitado
+2. Activa el **modo plan** para un enfoque estructurado
+3. Usa varias rondas de crítica para un análisis exhaustivo
+4. Usa subagentes con roles divididos para obtener perspectivas diversas
+
+## Solución de problemas de build
+
+Si el build falla:
+1. Usa el agente **resolutor-builds**
+2. Analiza los mensajes de error
+3. Corrige de forma incremental
+4. Verifica después de cada corrección

package/vendor/theus-arsenal/rules/common/security.md

@@ -0,0 +1,29 @@
+# Directrices de seguridad
+
+## Verificaciones de seguridad obligatorias
+
+Antes de CUALQUIER commit:
+- [ ] Sin secretos hardcodeados (API keys, contraseñas, tokens)
+- [ ] Todas las entradas de usuario validadas
+- [ ] Prevención de inyección SQL (consultas parametrizadas)
+- [ ] Prevención de XSS (HTML saneado)
+- [ ] Protección CSRF habilitada
+- [ ] Autenticación/autorización verificadas
+- [ ] Rate limiting en todos los endpoints
+- [ ] Los mensajes de error no filtran datos sensibles
+
+## Gestión de secretos
+
+- NUNCA hardcodees secretos en el código fuente
+- Usa SIEMPRE variables de entorno o un gestor de secretos
+- Valida que los secretos requeridos estén presentes al arrancar
+- Rota cualquier secreto que pudiera haberse expuesto
+
+## Protocolo de respuesta ante incidentes de seguridad
+
+Si se encuentra un problema de seguridad:
+1. DETENTE de inmediato
+2. Usa el agente **revisor-seguridad**
+3. Corrige los problemas CRÍTICOS antes de continuar
+4. Rota cualquier secreto expuesto
+5. Revisa todo el código en busca de problemas similares

package/vendor/theus-arsenal/rules/common/testing.md

@@ -0,0 +1,57 @@
+# Requisitos de testing
+
+## Cobertura mínima de tests: 80%
+
+Tipos de tests (TODOS requeridos):
+1. **Tests unitarios** — funciones individuales, utilidades, componentes
+2. **Tests de integración** — endpoints de API, operaciones de base de datos
+3. **Tests E2E** — flujos de usuario críticos (el framework se elige según el lenguaje)
+
+## Desarrollo guiado por tests (TDD)
+
+Flujo de trabajo OBLIGATORIO:
+1. Escribe el test primero (ROJO)
+2. Ejecuta el test — debe FALLAR
+3. Escribe la implementación mínima (VERDE)
+4. Ejecuta el test — debe PASAR
+5. Refactoriza (MEJORA)
+6. Verifica la cobertura (80% o más)
+
+## Solución de fallos en los tests
+
+1. Usa el agente **guia-tdd**
+2. Revisa el aislamiento de los tests
+3. Verifica que los mocks sean correctos
+4. Corrige la implementación, no los tests (salvo que los tests estén mal)
+
+## Soporte de agentes
+
+- **guia-tdd** — úsalo PROACTIVAMENTE en funcionalidades nuevas; hace cumplir escribir-tests-primero
+
+## Estructura de tests (patrón AAA)
+
+Prefiere la estructura Arrange-Act-Assert (preparar-actuar-afirmar) en los tests:
+
+```typescript
+test('calcula la similitud correctamente', () => {
+  // Preparar
+  const vector1 = [1, 0, 0]
+  const vector2 = [0, 1, 0]
+
+  // Actuar
+  const similarity = calculateCosineSimilarity(vector1, vector2)
+
+  // Afirmar
+  expect(similarity).toBe(0)
+})
+```
+
+### Nombres de tests
+
+Usa nombres descriptivos que expliquen el comportamiento bajo prueba:
+
+```typescript
+test('devuelve un arreglo vacío cuando ningún mercado coincide con la consulta', () => {})
+test('lanza un error cuando falta la API key', () => {})
+test('recurre a la búsqueda por subcadenas cuando Redis no está disponible', () => {})
+```

package/vendor/theus-arsenal/rules/cpp/coding-style.md

@@ -0,0 +1,44 @@
+---
+paths:
+  - "**/*.cpp"
+  - "**/*.hpp"
+  - "**/*.cc"
+  - "**/*.hh"
+  - "**/*.cxx"
+  - "**/*.h"
+  - "**/CMakeLists.txt"
+---
+# Estilo de código C++
+
+> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de C++.
+
+## C++ moderno (C++17/20/23)
+
+- Prefiere las **funcionalidades de C++ moderno** sobre las construcciones estilo C
+- Usa `auto` cuando el tipo es obvio por el contexto
+- Usa `constexpr` para constantes en tiempo de compilación
+- Usa structured bindings: `auto [key, value] = map_entry;`
+
+## Gestión de recursos
+
+- **RAII en todas partes** — nada de `new`/`delete` manuales
+- Usa `std::unique_ptr` para propiedad exclusiva
+- Usa `std::shared_ptr` solo cuando la propiedad compartida sea realmente necesaria
+- Usa `std::make_unique` / `std::make_shared` en lugar de `new` en crudo
+
+## Convenciones de nomenclatura
+
+- Tipos/Clases: `PascalCase`
+- Funciones/Métodos: `snake_case` o `camelCase` (sigue la convención del proyecto)
+- Constantes: `kPascalCase` o `UPPER_SNAKE_CASE`
+- Namespaces: `lowercase`
+- Variables miembro: `snake_case_` (guion bajo al final) o prefijo `m_`
+
+## Formato
+
+- Usa **clang-format** — nada de debates de estilo
+- Ejecuta `clang-format -i <archivo>` antes de commitear
+
+## Referencia
+
+Consulta la skill `estandares-cpp` para estándares y directrices completos de codificación en C++.

package/vendor/theus-arsenal/rules/cpp/hooks.md

@@ -0,0 +1,39 @@
+---
+paths:
+  - "**/*.cpp"
+  - "**/*.hpp"
+  - "**/*.cc"
+  - "**/*.hh"
+  - "**/*.cxx"
+  - "**/*.h"
+  - "**/CMakeLists.txt"
+---
+# Hooks para C++
+
+> Este archivo extiende [common/hooks.md](../common/hooks.md) con contenido específico de C++.
+
+## Hooks de build
+
+Ejecuta estas comprobaciones antes de commitear cambios en C++:
+
+```bash
+# Chequeo de formato
+clang-format --dry-run --Werror src/*.cpp src/*.hpp
+
+# Análisis estático
+clang-tidy src/*.cpp -- -std=c++17
+
+# Build
+cmake --build build
+
+# Tests
+ctest --test-dir build --output-on-failure
+```
+
+## Pipeline de CI recomendado
+
+1. **clang-format** — chequeo de formato
+2. **clang-tidy** — análisis estático
+3. **cppcheck** — análisis adicional
+4. **cmake build** — compilación
+5. **ctest** — ejecución de tests con sanitizers

package/vendor/theus-arsenal/rules/cpp/patterns.md

@@ -0,0 +1,51 @@
+---
+paths:
+  - "**/*.cpp"
+  - "**/*.hpp"
+  - "**/*.cc"
+  - "**/*.hh"
+  - "**/*.cxx"
+  - "**/*.h"
+  - "**/CMakeLists.txt"
+---
+# Patrones de C++
+
+> Este archivo extiende [common/patterns.md](../common/patterns.md) con contenido específico de C++.
+
+## RAII (Resource Acquisition Is Initialization)
+
+Ata la vida del recurso a la vida del objeto:
+
+```cpp
+class FileHandle {
+public:
+    explicit FileHandle(const std::string& path) : file_(std::fopen(path.c_str(), "r")) {}
+    ~FileHandle() { if (file_) std::fclose(file_); }
+    FileHandle(const FileHandle&) = delete;
+    FileHandle& operator=(const FileHandle&) = delete;
+private:
+    std::FILE* file_;
+};
+```
+
+## Regla de cinco/cero
+
+- **Regla de cero**: prefiere clases que no necesiten destructor, constructores de copia/movimiento ni asignaciones personalizados
+- **Regla de cinco**: si defines cualquiera de destructor / constructor de copia / asignación de copia / constructor de movimiento / asignación de movimiento, define los cinco
+
+## Semántica de valores
+
+- Pasa los tipos pequeños/triviales por valor
+- Pasa los tipos grandes por `const&`
+- Retorna por valor (apóyate en RVO/NRVO)
+- Usa semántica de movimiento para parámetros sink
+
+## Manejo de errores
+
+- Usa excepciones para condiciones excepcionales
+- Usa `std::optional` para valores que pueden no existir
+- Usa `std::expected` (C++23) o tipos result para fallos esperables
+
+## Referencia
+
+Consulta la skill `estandares-cpp` para patrones y antipatrones completos de C++.

package/vendor/theus-arsenal/rules/cpp/security.md

@@ -0,0 +1,51 @@
+---
+paths:
+  - "**/*.cpp"
+  - "**/*.hpp"
+  - "**/*.cc"
+  - "**/*.hh"
+  - "**/*.cxx"
+  - "**/*.h"
+  - "**/CMakeLists.txt"
+---
+# Seguridad en C++
+
+> Este archivo extiende [common/security.md](../common/security.md) con contenido específico de C++.
+
+## Seguridad de memoria
+
+- Nunca uses `new`/`delete` en crudo — usa punteros inteligentes
+- Nunca uses arreglos estilo C — usa `std::array` o `std::vector`
+- Nunca uses `malloc`/`free` — usa la asignación de C++
+- Evita `reinterpret_cast` salvo que sea absolutamente necesario
+
+## Desbordamientos de búfer
+
+- Usa `std::string` en lugar de `char*`
+- Usa `.at()` para acceso con verificación de límites cuando la seguridad importe
+- Nunca uses `strcpy`, `strcat`, `sprintf` — usa `std::string` o `fmt::format`
+
+## Comportamiento indefinido
+
+- Inicializa siempre las variables
+- Evita el desbordamiento de enteros con signo
+- Nunca desreferencies punteros nulos ni colgantes
+- Usa sanitizers en CI:
+  ```bash
+  cmake -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined" ..
+  ```
+
+## Análisis estático
+
+- Usa **clang-tidy** para comprobaciones automatizadas:
+  ```bash
+  clang-tidy --checks='*' src/*.cpp
+  ```
+- Usa **cppcheck** para análisis adicional:
+  ```bash
+  cppcheck --enable=all src/
+  ```
+
+## Referencia
+
+Consulta la skill `estandares-cpp` para directrices de seguridad detalladas.