theus-cli-linux-x64 1.2.2 → 1.4.0

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

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

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

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

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

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

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

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

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

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

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

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

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

@@ -1,51 +0,0 @@
----
-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.