theus-cli-linux-x64 1.2.2 → 1.3.0

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

@@ -1,82 +0,0 @@
----
-paths:
-  - "**/*.kt"
-  - "**/*.kts"
----
-# Seguridad en Kotlin
-
-> Este archivo extiende [common/security.md](../common/security.md) con contenido específico de Kotlin y Android/KMP.
-
-## Gestión de secretos
-
-- Nunca escribas claves de API, tokens ni credenciales directamente en el código fuente
-- Usa `local.properties` (ignorado por git) para los secretos de desarrollo local
-- Usa campos de `BuildConfig` generados a partir de secretos de CI para las builds de release
-- Usa `EncryptedSharedPreferences` (Android) o Keychain (iOS) para almacenar secretos en tiempo de ejecución
-
-```kotlin
-// MAL
-val apiKey = "sk-abc123..."
-
-// BIEN — desde BuildConfig (generado en tiempo de build)
-val apiKey = BuildConfig.API_KEY
-
-// BIEN — desde almacenamiento seguro en tiempo de ejecución
-val token = secureStorage.get("auth_token")
-```
-
-## Seguridad de red
-
-- Usa HTTPS exclusivamente — configura `network_security_config.xml` para bloquear el tráfico en claro
-- Ancla certificados (certificate pinning) en los endpoints sensibles con `CertificatePinner` de OkHttp o el equivalente de Ktor
-- Define timeouts en todos los clientes HTTP — nunca dejes los valores por defecto (pueden ser infinitos)
-- Valida y sanitiza todas las respuestas del servidor antes de usarlas
-
-```xml
-<!-- res/xml/network_security_config.xml -->
-<network-security-config>
-    <base-config cleartextTrafficPermitted="false" />
-</network-security-config>
-```
-
-## Validación de entrada
-
-- Valida toda entrada del usuario antes de procesarla o enviarla a la API
-- Usa consultas parametrizadas con Room/SQLDelight — nunca concatenes entrada del usuario en SQL
-- Sanitiza las rutas de archivos provenientes del usuario para prevenir path traversal
-
-```kotlin
-// MAL — inyección SQL
-@Query("SELECT * FROM items WHERE name = '$input'")
-
-// BIEN — parametrizada
-@Query("SELECT * FROM items WHERE name = :input")
-fun findByName(input: String): List<ItemEntity>
-```
-
-## Protección de datos
-
-- Usa `EncryptedSharedPreferences` para datos clave-valor sensibles en Android
-- Usa `@Serializable` con nombres de campo explícitos — no filtres los nombres internos de las propiedades
-- Elimina los datos sensibles de la memoria cuando ya no se necesiten
-- Usa `@Keep` o reglas de ProGuard en las clases serializadas para evitar la ofuscación de nombres
-
-## Autenticación
-
-- Almacena los tokens en almacenamiento seguro, no en SharedPreferences plano
-- Implementa la renovación de tokens con un manejo correcto de 401/403
-- Limpia todo el estado de autenticación al cerrar sesión (tokens, datos de usuario en caché, cookies)
-- Usa autenticación biométrica (`BiometricPrompt`) para operaciones sensibles
-
-## ProGuard / R8
-
-- Reglas keep para todos los modelos serializados (`@Serializable`, Gson, Moshi)
-- Reglas keep para bibliotecas basadas en reflexión (Koin, Retrofit)
-- Prueba las builds de release — la ofuscación puede romper la serialización silenciosamente
-
-## Seguridad en WebView
-
-- Desactiva JavaScript salvo que sea explícitamente necesario: `settings.javaScriptEnabled = false`
-- Valida las URLs antes de cargarlas en un WebView
-- Nunca expongas métodos `@JavascriptInterface` que accedan a datos sensibles
-- Usa `WebViewClient.shouldOverrideUrlLoading()` para controlar la navegación

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

@@ -1,128 +0,0 @@
----
-paths:
-  - "**/*.kt"
-  - "**/*.kts"
----
-# Testing en Kotlin
-
-> Este archivo extiende [common/testing.md](../common/testing.md) con contenido específico de Kotlin y Android/KMP.
-
-## Framework de tests
-
-- **kotlin.test** para multiplataforma (KMP) — `@Test`, `assertEquals`, `assertTrue`
-- **JUnit 4/5** para tests específicos de Android
-- **Turbine** para probar Flows y StateFlow
-- **kotlinx-coroutines-test** para probar corrutinas (`runTest`, `TestDispatcher`)
-
-## Tests de ViewModel con Turbine
-
-```kotlin
-@Test
-fun `emite estado de carga y luego los datos`() = runTest {
-    val repo = FakeItemRepository()
-    repo.addItem(testItem)
-    val viewModel = ItemListViewModel(GetItemsUseCase(repo))
-
-    viewModel.state.test {
-        assertEquals(ItemListState(), awaitItem())     // estado inicial
-        viewModel.onEvent(ItemListEvent.Load)
-        assertTrue(awaitItem().isLoading)               // cargando
-        assertEquals(listOf(testItem), awaitItem().items) // cargado
-    }
-}
-```
-
-## Fakes en lugar de mocks
-
-Prefiere fakes escritos a mano en lugar de frameworks de mocking:
-
-```kotlin
-class FakeItemRepository : ItemRepository {
-    private val items = mutableListOf<Item>()
-    var fetchError: Throwable? = null
-
-    override suspend fun getAll(): Result<List<Item>> {
-        fetchError?.let { return Result.failure(it) }
-        return Result.success(items.toList())
-    }
-
-    override fun observeAll(): Flow<List<Item>> = flowOf(items.toList())
-
-    fun addItem(item: Item) { items.add(item) }
-}
-```
-
-## Testing de corrutinas
-
-```kotlin
-@Test
-fun `las operaciones paralelas se completan`() = runTest {
-    val repo = FakeRepository()
-    val result = loadDashboard(repo)
-    advanceUntilIdle()
-    assertNotNull(result.items)
-    assertNotNull(result.stats)
-}
-```
-
-Usa `runTest` — avanza automáticamente el tiempo virtual y provee `TestScope`.
-
-## MockEngine de Ktor
-
-```kotlin
-val mockEngine = MockEngine { request ->
-    when (request.url.encodedPath) {
-        "/api/items" -> respond(
-            content = Json.encodeToString(testItems),
-            headers = headersOf(HttpHeaders.ContentType, ContentType.Application.Json.toString())
-        )
-        else -> respondError(HttpStatusCode.NotFound)
-    }
-}
-
-val client = HttpClient(mockEngine) {
-    install(ContentNegotiation) { json() }
-}
-```
-
-## Testing de Room/SQLDelight
-
-- Room: usa `Room.inMemoryDatabaseBuilder()` para pruebas en memoria
-- SQLDelight: usa `JdbcSqliteDriver(JdbcSqliteDriver.IN_MEMORY)` para tests en la JVM
-
-```kotlin
-@Test
-fun `inserta y consulta items`() = runTest {
-    val driver = JdbcSqliteDriver(JdbcSqliteDriver.IN_MEMORY)
-    Database.Schema.create(driver)
-    val db = Database(driver)
-
-    db.itemQueries.insert("1", "Item de ejemplo", "descripción")
-    val items = db.itemQueries.getAll().executeAsList()
-    assertEquals(1, items.size)
-}
-```
-
-## Nombres de los tests
-
-Usa nombres descriptivos entre backticks:
-
-```kotlin
-@Test
-fun `buscar con consulta vacía devuelve todos los items`() = runTest { }
-
-@Test
-fun `eliminar un item emite la lista actualizada sin el item eliminado`() = runTest { }
-```
-
-## Organización de los tests
-
-```
-src/
-├── commonTest/kotlin/     # Tests compartidos (ViewModel, UseCase, Repository)
-├── androidUnitTest/kotlin/ # Tests unitarios de Android (JUnit)
-├── androidInstrumentedTest/kotlin/  # Tests instrumentados (Room, UI)
-└── iosTest/kotlin/        # Tests específicos de iOS
-```
-
-Cobertura mínima de tests: ViewModel + UseCase para cada funcionalidad.

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

@@ -1,47 +0,0 @@
----
-paths:
-  - "**/nuxt.config.*"
-  - "**/app.config.*"
-  - "**/app.vue"
-  - "**/pages/**"
-  - "**/layouts/**"
-  - "**/middleware/**"
----
-
-# Estilo de código Nuxt
-
-> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de Nuxt.
-
-## Estructura de directorios
-
-- El `srcDir` por defecto es `app/`. Los archivos del framework viven en `app/pages/`, `app/layouts/`, `app/middleware/`, `app/plugins/`, `app/app.config.ts`. `nuxt.config.ts` y `server/` se quedan en la raíz del proyecto.
-- Algunos proyectos sobrescriben `srcDir` a `src/` para un layout tipo Feature-Sliced Design, remapeando `dir.pages` (por ejemplo a `src/app/routes`), `dir.layouts` y los alias `@`/`~`. Revisa siempre `nuxt.config.ts` antes de asumir una ruta.
-
-## Disciplina de auto-imports
-
-- Los composables en `app/composables/` y `server/utils/` se auto-importan. NO importes manualmente los composables de Nuxt (`useFetch`, `useState`, `navigateTo`) ni `defineStore` / `storeToRefs`.
-- NO añadas una dependencia independiente de `vue-router` (Nuxt empaqueta la v5) ni montes a mano `createApp` / `createPinia` / `createRouter`. El framework se encarga de cablearlos.
-
-## Macros del compilador
-
-- `definePageMeta` es una macro de tiempo de compilación. Solo valores estáticos: nada de datos reactivos ni llamadas con efectos secundarios dentro.
-- Amplía el tipo `PageMeta` mediante `declare module '#app'` en lugar de hacer casts.
-
-## Separación de archivos de configuración
-
-Tres archivos distintos; no los mezcles.
-
-- `nuxt.config.ts` = solo tiempo de build (`routeRules`, `modules`, `nitro`, flag `ssr`). No es reactivo.
-- `runtimeConfig` (dentro de nuxt.config) = valores de runtime por entorno, sobrescribibles vía variables `NUXT_*`. Las claves raíz son solo de servidor; las claves bajo `public` son visibles en el cliente.
-- `app/app.config.ts` = ajustes públicos reactivos fijados en build (tokens de tema, feature flags). Sin sobrescritura por entorno. NUNCA secretos.
-
-## Head y meta
-
-- `app.head` en `nuxt.config.ts` acepta solo valores estáticos.
-- Los meta reactivos van por `useHead` / `useSeoMeta` en el setup del componente, nunca vía `app.head`.
-
-## Referencia
-
-- Skills: `patrones-nuxt4`, `patrones-vite`, `patrones-frontend`.
-- [Estructura de directorios de Nuxt](https://nuxt.com/docs/guide/directory-structure/app)
-- [Configuración de Nuxt](https://nuxt.com/docs/api/nuxt-config)

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

@@ -1,39 +0,0 @@
----
-paths:
-  - "**/nuxt.config.*"
-  - "**/app.config.*"
-  - "**/server/**/*.ts"
-  - "**/*.vue"
----
-
-# Hooks de Nuxt
-
-> Este archivo extiende [common/hooks.md](../common/hooks.md) con contenido específico de Nuxt.
-
-Estos son hooks del harness de Theus para trabajo con Nuxt. Los ejecuta el harness, no el modelo.
-
-## Verificación de tipos
-
-- `nuxi typecheck` envuelve `vue-tsc`. Requiere `vue-tsc` + `typescript` como dependencias de desarrollo.
-- Ejecútalo al editar `.vue` / `.ts` o en pre-commit. La verificación de tipos abarca todo el proyecto, así que aplícale debounce y envuélvela en un timeout (imita `web/hooks.md`, por ejemplo `timeout 60 nuxi typecheck`) para que una verificación colgada sea eliminada en lugar de acumularse entre ediciones rápidas.
-
-## Lint
-
-- Usa el módulo `@nuxt/eslint` (flat-config, consciente del proyecto, genera `.nuxt/eslint.config.mjs`).
-- Ejecuta `eslint .` o `eslint --fix`. Es la integración oficial de ESLint para Nuxt; prefiérela sobre configuraciones hechas a mano.
-
-## Formato
-
-- `prettier --write`, o habilita las reglas estilísticas de `@nuxt/eslint` para evitar un conflicto Prettier/ESLint.
-- Elige una única autoridad de formateo. No ejecutes Prettier y las reglas estilísticas de ESLint a la vez.
-
-## Cadena PostToolUse sugerida
-
-- Al editar `app/**` y `server/**`: ejecuta `eslint --fix` y después `timeout 60 nuxi typecheck`.
-- El orden importa: primero el lint-fix (muta el archivo), después la verificación de tipos con timeout (verifica el resultado). El debounce sigue aplicando.
-
-## Referencia
-
-- Skills: `patrones-nuxt4`, `patrones-vite`.
-- [Módulo @nuxt/eslint](https://eslint.nuxt.com/)
-- [nuxi typecheck](https://nuxt.com/docs/api/commands/typecheck)

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

@@ -1,54 +0,0 @@
----
-paths:
-  - "**/nuxt.config.*"
-  - "**/app.config.*"
-  - "**/app.vue"
-  - "**/server/**/*.ts"
-  - "**/pages/**"
-  - "**/middleware/**"
----
-
-# Patrones de Nuxt
-
-> Este archivo extiende [common/patterns.md](../common/patterns.md) con contenido específico de Nuxt.
-
-## Selección de la herramienta de fetch de datos
-
-Crítico. Elige según el momento de renderizado, no por costumbre.
-
-- `useFetch(url)` = seguro en SSR, orientado a URL, para datos iniciales / del primer render. Es el valor por defecto. Reenvía el resultado del servidor a través del payload, así que no hay doble fetch en la hidratación.
-- `useAsyncData(key, fn)` = seguro en SSR, para lógica asíncrona personalizada (SDK / GraphQL / llamadas combinadas). La clave explícita comparte el resultado entre componentes.
-- `$fetch` = solo interacciones de cliente (envío de formulario, clic de botón, POST/PUT/DELETE). NO es seguro en SSR: provoca doble fetch si se usa para el primer render.
-- Regla: `useFetch` / `useAsyncData` para todo lo que se renderiza en el primer paint; `$fetch` solo para mutaciones disparadas por eventos.
-
-## Estado compartido
-
-- `useState('key', () => init)` para estado compartido seguro en SSR. Los valores deben ser serializables a JSON.
-- NUNCA `export const x = ref()` a nivel de módulo. Una única instancia compartida se filtra entre peticiones SSR concurrentes y provoca una fuga de memoria.
-- Con `@pinia/nuxt`: Pinia para el estado de dominio, `useState` para primitivos pequeños entre componentes.
-- La inicialización asíncrona del lado del servidor va en `callOnce(async () => {...})`, no como efecto secundario dentro de `useAsyncData`.
-
-## Rutas de servidor Nitro
-
-- `server/api/*.{get,post}.ts` se auto-registran por ruta + método. El handler es `defineEventHandler((event) => ...)`.
-- Errores vía `throw createError({ status, statusText })`. Prefiere `status` / `statusText` (Web API) sobre los obsoletos `statusCode` / `statusMessage`.
-- `server/middleware/` NO debe devolver una respuesta. Solo mutar `event.context` o establecer cabeceras.
-
-## Middleware de rutas
-
-- `app/middleware/*.ts` con `defineNuxtRouteMiddleware((to, from) => ...)`.
-- Usa los argumentos `to` / `from`. NO llames a `useRoute()` dentro del middleware.
-- El sufijo `.global` lo ejecuta en cada ruta. Devuelve `navigateTo()` para redirigir, `abortNavigation()` para detener.
-
-## Renderizado seguro frente a la hidratación
-
-- Enruta según `status` (`idle | pending | success | error`) para fetches perezosos.
-- El payload de `useAsyncData` usa `devalue` (Date/Map/Set/refs sobreviven). Una respuesta de `server/api` es solo `JSON.stringify`, así que define `toJSON()` para los tipos no JSON.
-- Reduce el payload con `pick` / `transform`. Esto reduce el tamaño serializado; no evita el fetch.
-
-## Referencia
-
-- Skills: `patrones-nuxt4`, `patrones-vite`, `patrones-frontend`.
-- [Fetch de datos en Nuxt](https://nuxt.com/docs/getting-started/data-fetching)
-- [Gestión de estado en Nuxt](https://nuxt.com/docs/getting-started/state-management)
-- [Motor de servidor de Nuxt (Nitro)](https://nuxt.com/docs/guide/directory-structure/server)

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

@@ -1,48 +0,0 @@
----
-paths:
-  - "**/nuxt.config.*"
-  - "**/app.config.*"
-  - "**/server/**/*.ts"
----
-
-# Seguridad en Nuxt
-
-> Este archivo extiende [common/security.md](../common/security.md) con contenido específico de Nuxt.
-
-## runtimeConfig público vs privado
-
-- Las claves raíz de `runtimeConfig` son solo de servidor. `runtimeConfig.public` se serializa en el payload de CADA página (visible en el cliente).
-- Los secretos van solo en la raíz. Nunca pongas secretos en `app.config.ts` ni en `runtimeConfig.public`: ambos llegan al bundle del cliente.
-- Advertencia oficial: "Cuida de no exponer claves de la configuración de runtime al lado cliente, ya sea renderizándolas o pasándolas a `useState`."
-
-## Validación de entrada en rutas de servidor
-
-- Usa los lectores validadores de h3. NO confíes en `readBody` / `getQuery` / `getRouterParam` crudos.
-  - `readValidatedBody(event, schema)` valida el body.
-  - `getValidatedQuery(event, schema)` valida la query.
-  - `getValidatedRouterParams(event, schema)` valida los parámetros de ruta.
-- Todos aceptan una función de validación o un esquema Zod y lanzan un error si falla.
-
-## Fuga por el payload de SSR
-
-- Todo lo que esté en `useState`, en resultados de `useFetch` / `useAsyncData` o en `runtimeConfig.public` se serializa en el payload del cliente. Nunca escribas un secreto ahí.
-- Usa `useServerSeoMeta` para meta solo de servidor sin coste en el cliente.
-
-## Cookies y passthrough de autenticación en SSR
-
-- Nuxt NO adjunta automáticamente las cookies del usuario entrante a los `$fetch` salientes del lado del servidor.
-- Reenvíalas explícitamente con `useRequestFetch()` (lo más limpio, ya viene ligado a las cabeceras de la petición) o `useRequestHeaders(['cookie'])`.
-- Retransmite un `Set-Cookie` del backend al navegador vía `$fetch.raw` + `appendResponseHeader(event, 'set-cookie', ...)`.
-- socket.io es solo de cliente (plugin `.client.ts`), nunca en SSR.
-
-## SSRF en `$fetch` de servidor
-
-- Las rutas de servidor corren con salida de red completa. Nunca pases entrada controlada por el usuario directamente a la URL o al host de un `$fetch` del lado del servidor.
-- Valida primero el parámetro (utilidades de h3 de arriba), usa una lista de permitidos para el destino, fíjalo a `runtimeConfig.public.apiBase` y rechaza URLs absolutas suministradas por el usuario.
-- Usa el agente `revisor-seguridad` solo para rutas que hagan peticiones de red externas (`$fetch` de servidor), manejen tokens o credenciales de autenticación, o realicen mutaciones sensibles o verificaciones de autorización. Ejemplos: endpoints proxy propensos a SSRF, intercambio de tokens o restablecimiento de contraseña, acciones de administración. Omite las rutas benignas de solo lectura que solo aceptan parámetros de query validados.
-
-## Referencia
-
-- Skills: `revision-seguridad`, `patrones-nuxt4`.
-- [Configuración de runtime de Nuxt](https://nuxt.com/docs/guide/going-further/runtime-config)
-- [Utilidades de petición de h3](https://v1.h3.dev/utils/request)

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

@@ -1,49 +0,0 @@
----
-paths:
-  - "**/nuxt.config.*"
-  - "**/server/**/*.ts"
-  - "**/pages/**"
-  - "**/layouts/**"
-  - "**/middleware/**"
----
-
-# Testing en Nuxt
-
-> Este archivo extiende [common/testing.md](../common/testing.md) con contenido específico de Nuxt.
-
-Paquete: `@nuxt/test-utils`. Vitest-first para tests unitarios y de componentes, con soporte integrado de E2E en navegador vía Playwright. nuxt-vitest y vitest-environment-nuxt quedaron obsoletos y están absorbidos en él.
-
-## Configuración
-
-- Instala las dependencias de desarrollo: `@nuxt/test-utils vitest @vue/test-utils happy-dom playwright-core`.
-- Configuración: `defineVitestConfig({ test: { environment: 'nuxt' } })` desde `@nuxt/test-utils/config`. Usa `defineVitestProject` para multi-proyecto (entornos separados unit / nuxt / e2e).
-- Añade `@nuxt/test-utils/module` a `nuxt.config`. Opt-in por archivo vía `// @vitest-environment nuxt`.
-
-## Helpers de runtime
-
-Impórtalos desde `@nuxt/test-utils/runtime`.
-
-- `mountSuspended(component, opts)` monta en el entorno de Nuxt con setup asíncrono + inyección de plugins (acepta las opciones de mount de `@vue/test-utils` + `route`).
-- `renderSuspended(component, opts)` es la variante de Testing Library (necesita `@testing-library/vue`).
-- `mockNuxtImport(name, factory)` mockea auto-imports (p. ej. `useState`). Una vez por import por archivo; usa `vi.hoisted()`.
-- `mockComponent(name, factory)` mockea por nombre en PascalCase o por ruta.
-- `registerEndpoint(path, handler|opts)` mockea un endpoint de Nitro para probar rutas de servidor o simular el backend. Soporta método + `once`.
-
-## Helpers de E2E
-
-Impórtalos desde `@nuxt/test-utils/e2e`.
-
-- `await setup({ rootDir, server, browser, ... })` dentro del bloque describe (gestiona beforeAll/afterAll).
-- Después: `$fetch(url)` (HTML renderizado), `fetch(url)` (objeto de respuesta), `url(path)` (URL completa con puerto), `createPage(url)` (Playwright).
-- Integración con Playwright: importa `expect` / `test` desde `@nuxt/test-utils/playwright`.
-
-## Qué probar y cómo
-
-- Composables: mockea los auto-imports con `mockNuxtImport` y monta un componente anfitrión vía `mountSuspended` para ejercitar `useState` / `useFetch` en el runtime de Nuxt.
-- Rutas de servidor: `registerEndpoint` para simularlas, o E2E con `$fetch` / `fetch` contra el servidor Nitro real.
-
-## Referencia
-
-- Skills: `patrones-nuxt4`, `testing-e2e`, `patrones-vite`.
-- [Documentación de testing de Nuxt](https://nuxt.com/docs/getting-started/testing)
-- [@nuxt/test-utils en npm](https://www.npmjs.com/package/@nuxt/test-utils)

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

@@ -1,40 +0,0 @@
----
-paths:
-  - "**/*.php"
-  - "**/composer.json"
----
-# Estilo de código PHP
-
-> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de PHP.
-
-## Estándares
-
-- Sigue las convenciones de formato y nombres de **PSR-12**.
-- Prefiere `declare(strict_types=1);` en código de aplicación.
-- Usa type hints escalares, tipos de retorno y propiedades tipadas en todo lugar donde el código nuevo lo permita.
-
-## Inmutabilidad
-
-- Prefiere DTOs inmutables y value objects para los datos que cruzan fronteras entre servicios.
-- Usa propiedades `readonly` o constructores inmutables para los payloads de request/response siempre que sea posible.
-- Mantén arrays para mapas simples; promueve las estructuras críticas para el negocio a clases explícitas.
-
-## Formato
-
-- Usa **PHP-CS-Fixer** o **Laravel Pint** para el formateo.
-- Usa **PHPStan** o **Psalm** para el análisis estático.
-- Mantén los scripts de Composer versionados en el repo para que los mismos comandos corran en local y en CI.
-
-## Imports
-
-- Añade sentencias `use` para todas las clases, interfaces y traits referenciados.
-- Evita depender del namespace global salvo que el proyecto prefiera explícitamente nombres totalmente cualificados.
-
-## Manejo de errores
-
-- Lanza excepciones para estados excepcionales; evita devolver `false`/`null` como canales de error ocultos en código nuevo.
-- Convierte la entrada del framework/request en DTOs validados antes de que llegue a la lógica de dominio.
-
-## Referencia
-
-Consulta la skill `patrones-backend` para una guía más amplia sobre capas de servicios y repositorios.

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

@@ -1,24 +0,0 @@
----
-paths:
-  - "**/*.php"
-  - "**/composer.json"
-  - "**/phpstan.neon"
-  - "**/phpstan.neon.dist"
-  - "**/psalm.xml"
----
-# Hooks para PHP
-
-> Este archivo extiende [common/hooks.md](../common/hooks.md) con contenido específico de PHP.
-
-## Hooks PostToolUse
-
-Configúralos en `~/.theus/settings.json`:
-
-- **Pint / PHP-CS-Fixer**: auto-formatea los archivos `.php` editados.
-- **PHPStan / Psalm**: ejecuta análisis estático tras ediciones de PHP en bases de código tipadas.
-- **PHPUnit / Pest**: ejecuta tests dirigidos a los archivos o módulos tocados cuando las ediciones afectan el comportamiento.
-
-## Advertencias
-
-- Advierte sobre `var_dump`, `dd`, `dump` o `die()` que queden en archivos editados.
-- Advierte cuando archivos PHP editados añadan SQL crudo o deshabiliten protecciones CSRF/de sesión.

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

@@ -1,33 +0,0 @@
----
-paths:
-  - "**/*.php"
-  - "**/composer.json"
----
-# Patrones de PHP
-
-> Este archivo extiende [common/patterns.md](../common/patterns.md) con contenido específico de PHP.
-
-## Controladores delgados, servicios explícitos
-
-- Mantén los controladores enfocados en el transporte: auth, validación, serialización, códigos de estado.
-- Mueve las reglas de negocio a servicios de aplicación/dominio que sean fáciles de testear sin arrancar toda la capa HTTP.
-
-## DTOs y value objects
-
-- Reemplaza los arrays asociativos con muchas formas implícitas por DTOs para requests, comandos y payloads de APIs externas.
-- Usa value objects para dinero, identificadores, rangos de fechas y otros conceptos con restricciones.
-
-## Inyección de dependencias
-
-- Depende de interfaces o contratos de servicio acotados, no de globals del framework.
-- Pasa los colaboradores por los constructores para que los servicios sean testeables sin búsquedas por service locator.
-
-## Fronteras
-
-- Aísla los modelos del ORM de las decisiones de dominio cuando la capa de modelos hace más que persistencia.
-- Envuelve los SDKs de terceros detrás de adaptadores pequeños para que el resto del código dependa de tu contrato, no del de ellos.
-
-## Referencia
-
-Consulta la skill `diseno-api` para convenciones de endpoints y guía sobre la forma de las respuestas.
-Consulta la skill `patrones-laravel` para guía de arquitectura específica de Laravel.

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

@@ -1,37 +0,0 @@
----
-paths:
-  - "**/*.php"
-  - "**/composer.lock"
-  - "**/composer.json"
----
-# Seguridad en PHP
-
-> Este archivo extiende [common/security.md](../common/security.md) con contenido específico de PHP.
-
-## Entrada y salida
-
-- Valida la entrada de los requests en la frontera del framework (`FormRequest`, Symfony Validator o validación explícita con DTOs).
-- Escapa la salida en las plantillas por defecto; trata el renderizado de HTML crudo como una excepción que debe justificarse.
-- Nunca confíes en query params, cookies, headers ni metadatos de archivos subidos sin validarlos.
-
-## Seguridad de base de datos
-
-- Usa sentencias preparadas (`PDO`, Doctrine, el query builder de Eloquent) para todas las consultas dinámicas.
-- Evita construir SQL concatenando strings en controladores/vistas.
-- Acota con cuidado la asignación masiva del ORM y usa una lista blanca de campos escribibles.
-
-## Secretos y dependencias
-
-- Carga los secretos desde variables de entorno o un gestor de secretos, nunca desde archivos de configuración commiteados.
-- Ejecuta `composer audit` en CI y revisa la confianza en los mantenedores de cada paquete nuevo antes de añadir dependencias.
-- Fija las versiones mayores de forma deliberada y elimina rápido los paquetes abandonados.
-
-## Seguridad de auth y sesiones
-
-- Usa `password_hash()` / `password_verify()` para el almacenamiento de contraseñas.
-- Regenera los identificadores de sesión tras la autenticación y tras cambios de privilegios.
-- Exige protección CSRF en los requests web que cambian estado.
-
-## Referencia
-
-Consulta la skill `seguridad-laravel` para guía de seguridad específica de Laravel.

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

@@ -1,38 +0,0 @@
----
-paths:
-  - "**/*.php"
-  - "**/phpunit.xml"
-  - "**/phpunit.xml.dist"
-  - "**/composer.json"
----
-# Testing en PHP
-
-> Este archivo extiende [common/testing.md](../common/testing.md) con contenido específico de PHP.
-
-## Framework
-
-Usa **PHPUnit** como framework de tests por defecto. Si el proyecto tiene configurado **Pest**, prefiere Pest para los tests nuevos y evita mezclar frameworks.
-
-## Cobertura
-
-```bash
-vendor/bin/phpunit --coverage-text
-# o
-vendor/bin/pest --coverage
-```
-
-Prefiere **pcov** o **Xdebug** en CI, y mantén los umbrales de cobertura en CI en lugar de como conocimiento tribal.
-
-## Organización de tests
-
-- Separa los tests unitarios rápidos de los tests de integración con framework/base de datos.
-- Usa factories/builders para las fixtures en lugar de arrays grandes escritos a mano.
-- Mantén los tests de HTTP/controladores enfocados en transporte y validación; mueve las reglas de negocio a tests a nivel de servicio.
-
-## Inertia
-
-Si el proyecto usa Inertia.js, prefiere `assertInertia` con `AssertableInertia` para verificar nombres de componentes y props en lugar de aserciones sobre JSON crudo.
-
-## Referencia
-
-Consulta la skill `flujo-tdd` para el ciclo RED -> GREEN -> REFACTOR a nivel de repo.

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

@@ -1,42 +0,0 @@
----
-paths:
-  - "**/*.py"
-  - "**/*.pyi"
----
-# Estilo de código Python
-
-> Este archivo extiende [common/coding-style.md](../common/coding-style.md) con contenido específico de Python.
-
-## Estándares
-
-- Sigue las convenciones de **PEP 8**
-- Usa **anotaciones de tipo** en todas las firmas de funciones
-
-## Inmutabilidad
-
-Prefiere estructuras de datos inmutables:
-
-```python
-from dataclasses import dataclass
-
-@dataclass(frozen=True)
-class User:
-    name: str
-    email: str
-
-from typing import NamedTuple
-
-class Point(NamedTuple):
-    x: float
-    y: float
-```
-
-## Formato
-
-- **black** para el formateo del código
-- **isort** para ordenar los imports
-- **ruff** para el linting
-
-## Referencia
-
-Consulta la skill `patrones-python` para idiomas y patrones de Python en profundidad.