npm - theus-cli-linux-x64 - Versions diffs - 1.2.2 → 1.4.0 - Mend

theus-cli-linux-x64 1.2.2 → 1.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (759) hide show

package/vendor/theus-arsenal/skills/harness-evaluacion/SKILL.md DELETED Viewed

@@ -1,296 +0,0 @@
----
-name: harness-evaluacion
-description: Marco formal de evaluación para sesiones de Theus que implementa los principios del desarrollo guiado por evaluaciones (EDD)
-tools: Read, Write, Edit, Bash, Grep, Glob
----
-# Skill de Harness de Evaluación
-Un marco formal de evaluación para sesiones de Theus, que implementa los principios del desarrollo guiado por evaluaciones (EDD, por sus siglas en inglés).
-## Cuándo activarla
-- Al configurar desarrollo guiado por evaluaciones (EDD) para flujos de trabajo asistidos por IA
-- Al definir criterios de aprobado/reprobado para la finalización de tareas de Theus
-- Al medir la fiabilidad del agente con métricas pass@k
-- Al crear suites de tests de regresión para cambios en prompts o agentes
-- Al hacer benchmarking del rendimiento del agente entre versiones de modelos
-## Filosofía
-El desarrollo guiado por evaluaciones trata las evaluaciones como los "tests unitarios del desarrollo con IA":
-- Define el comportamiento esperado ANTES de la implementación
-- Ejecuta las evaluaciones de forma continua durante el desarrollo
-- Rastrea regresiones con cada cambio
-- Usa métricas pass@k para medir la fiabilidad
-## Tipos de evaluación
-### Evaluaciones de capacidad
-Comprueban si Theus puede hacer algo que antes no podía:
-```markdown
-[EVAL DE CAPACIDAD: nombre-funcionalidad]
-Tarea: Descripción de lo que Theus debe lograr
-Criterios de éxito:
-  - [ ] Criterio 1
-  - [ ] Criterio 2
-  - [ ] Criterio 3
-Salida esperada: Descripción del resultado esperado
-```
-### Evaluaciones de regresión
-Aseguran que los cambios no rompan la funcionalidad existente:
-```markdown
-[EVAL DE REGRESIÓN: nombre-funcionalidad]
-Línea base: SHA o nombre del checkpoint
-Tests:
-  - test-existente-1: PASS/FAIL
-  - test-existente-2: PASS/FAIL
-  - test-existente-3: PASS/FAIL
-Resultado: X/Y aprobados (antes Y/Y)
-```
-## Tipos de evaluador (grader)
-### 1. Evaluador basado en código
-Comprobaciones deterministas mediante código:
-```bash
-# Comprobar si el archivo contiene el patrón esperado
-grep -q "export function handleAuth" src/auth.ts && echo "PASS" || echo "FAIL"
-# Comprobar si los tests pasan
-npm test -- --testPathPattern="auth" && echo "PASS" || echo "FAIL"
-# Comprobar si el build tiene éxito
-npm run build && echo "PASS" || echo "FAIL"
-```
-### 2. Evaluador basado en modelo
-Usa un modelo del catálogo Theus para evaluar salidas abiertas:
-```markdown
-[PROMPT DEL EVALUADOR POR MODELO]
-Evalúa el siguiente cambio de código:
-1. ¿Resuelve el problema planteado?
-2. ¿Está bien estructurado?
-3. ¿Se manejan los casos borde?
-4. ¿El manejo de errores es adecuado?
-Puntuación: 1-5 (1=deficiente, 5=excelente)
-Razonamiento: [explicación]
-```
-### 3. Evaluador humano
-Marcar para revisión manual:
-```markdown
-[REVISIÓN HUMANA REQUERIDA]
-Cambio: Descripción de lo que cambió
-Motivo: Por qué se necesita revisión humana
-Nivel de riesgo: BAJO/MEDIO/ALTO
-```
-## Métricas
-### pass@k
-"Al menos un éxito en k intentos"
-- pass@1: tasa de éxito al primer intento
-- pass@3: éxito dentro de 3 intentos
-- Objetivo típico: pass@3 > 90%
-### pass^k
-"Todas las k ejecuciones tienen éxito"
-- Listón más alto de fiabilidad
-- pass^3: 3 éxitos consecutivos
-- Úsalo para rutas críticas
-## Flujo de trabajo de evaluación
-### 1. Definir (antes de programar)
-```markdown
-## DEFINICIÓN DE EVAL: funcionalidad-xyz
-### Evaluaciones de capacidad
-1. Puede crear una nueva cuenta de usuario
-2. Puede validar el formato del email
-3. Puede hashear la contraseña de forma segura
-### Evaluaciones de regresión
-1. El login existente sigue funcionando
-2. La gestión de sesiones no cambió
-3. El flujo de logout está intacto
-### Métricas de éxito
-- pass@3 > 90% para evaluaciones de capacidad
-- pass^3 = 100% para evaluaciones de regresión
-```
-### 2. Implementar
-Escribe el código necesario para superar las evaluaciones definidas.
-### 3. Evaluar
-```bash
-# Ejecutar evaluaciones de capacidad
-[Ejecutar cada evaluación de capacidad, registrar PASS/FAIL]
-# Ejecutar evaluaciones de regresión
-npm test -- --testPathPattern="existing"
-# Generar informe
-```
-### 4. Informar
-```markdown
-INFORME DE EVAL: funcionalidad-xyz
-==================================
-Evaluaciones de capacidad:
-  create-user:     PASS (pass@1)
-  validate-email:  PASS (pass@2)
-  hash-password:   PASS (pass@1)
-  Total:           3/3 aprobadas
-Evaluaciones de regresión:
-  login-flow:      PASS
-  session-mgmt:    PASS
-  logout-flow:     PASS
-  Total:           3/3 aprobadas
-Métricas:
-  pass@1: 67% (2/3)
-  pass@3: 100% (3/3)
-Estado: LISTO PARA REVISIÓN
-```
-## Patrones de integración
-### Antes de la implementación
-```
-/eval define nombre-funcionalidad
-```
-Crea el archivo de definición de la evaluación en `.theus/evals/nombre-funcionalidad.md`
-### Durante la implementación
-```
-/eval check nombre-funcionalidad
-```
-Ejecuta las evaluaciones actuales e informa el estado
-### Después de la implementación
-```
-/eval report nombre-funcionalidad
-```
-Genera el informe completo de evaluación
-## Almacenamiento de evaluaciones
-Guarda las evaluaciones en el proyecto:
-```
-.theus/
-  evals/
-    funcionalidad-xyz.md    # Definición de la evaluación
-    funcionalidad-xyz.log   # Historial de ejecuciones
-    baseline.json           # Líneas base de regresión
-```
-## Buenas prácticas
-1. **Define las evaluaciones ANTES de programar** — obliga a pensar con claridad los criterios de éxito
-2. **Ejecuta las evaluaciones con frecuencia** — detecta regresiones temprano
-3. **Rastrea pass@k a lo largo del tiempo** — monitorea las tendencias de fiabilidad
-4. **Usa evaluadores de código siempre que sea posible** — determinista > probabilístico
-5. **Revisión humana para seguridad** — nunca automatices por completo las comprobaciones de seguridad
-6. **Mantén las evaluaciones rápidas** — las evaluaciones lentas no se ejecutan
-7. **Versiona las evaluaciones junto con el código** — las evaluaciones son artefactos de primera clase
-## Ejemplo: agregar autenticación
-```markdown
-## EVAL: agregar-autenticacion
-### Fase 1: Definir (10 min)
-Evaluaciones de capacidad:
-- [ ] El usuario puede registrarse con email/contraseña
-- [ ] El usuario puede iniciar sesión con credenciales válidas
-- [ ] Las credenciales inválidas se rechazan con el error apropiado
-- [ ] Las sesiones persisten tras recargar la página
-- [ ] El logout limpia la sesión
-Evaluaciones de regresión:
-- [ ] Las rutas públicas siguen accesibles
-- [ ] Las respuestas de la API no cambiaron
-- [ ] El esquema de la base de datos es compatible
-### Fase 2: Implementar (variable)
-[Escribir el código]
-### Fase 3: Evaluar
-Ejecutar: /eval check agregar-autenticacion
-### Fase 4: Informar
-INFORME DE EVAL: agregar-autenticacion
-======================================
-Capacidad: 5/5 aprobadas (pass@3: 100%)
-Regresión: 3/3 aprobadas (pass^3: 100%)
-Estado: LISTO PARA PUBLICAR
-```
-## Evaluaciones de producto (v1.8)
-Usa evaluaciones de producto cuando la calidad del comportamiento no pueda capturarse solo con tests unitarios.
-### Tipos de evaluador
-1. Evaluador de código (aserciones deterministas)
-2. Evaluador de reglas (restricciones por regex/esquema)
-3. Evaluador por modelo (rúbrica con LLM como juez)
-4. Evaluador humano (adjudicación manual para salidas ambiguas)
-### Guía de pass@k
-- `pass@1`: fiabilidad directa
-- `pass@3`: fiabilidad práctica con reintentos controlados
-- `pass^3`: prueba de estabilidad (las 3 ejecuciones deben pasar)
-Umbrales recomendados:
-- Evaluaciones de capacidad: pass@3 >= 0.90
-- Evaluaciones de regresión: pass^3 = 1.00 para rutas críticas del release
-### Antipatrones de evaluación
-- Sobreajustar los prompts a ejemplos de evaluación conocidos
-- Medir únicamente las salidas del camino feliz
-- Ignorar la deriva de costo y latencia mientras se persiguen tasas de aprobación
-- Permitir evaluadores inestables (flaky) en las compuertas de release
-### Estructura mínima de artefactos de evaluación
-- `.theus/evals/<funcionalidad>.md` — definición
-- `.theus/evals/<funcionalidad>.log` — historial de ejecuciones
-- `docs/releases/<version>/eval-summary.md` — instantánea del release

package/vendor/theus-arsenal/skills/harness-generador-evaluador/SKILL.md DELETED Viewed

@@ -1,254 +0,0 @@
----
-name: harness-generador-evaluador
-description: Harness multi-agente de estilo GAN (Generador + Evaluador + Planificador) para construir
-  aplicaciones completas de alta calidad de forma autónoma, con bucle adversarial de feedback,
-  rúbrica ponderada e iteraciones acotadas.
----
-# Harness Generador-Evaluador (estilo GAN)
-Un harness multi-agente que separa la **generación** de la **evaluación**, creando un bucle adversarial de feedback que empuja la calidad mucho más allá de lo que logra un agente solo.
-## Idea central
-> Cuando se les pide evaluar su propio trabajo, los agentes son optimistas patológicos — elogian salidas mediocres y se convencen de ignorar problemas legítimos. Pero diseñar un **evaluador separado** para que sea implacablemente estricto es mucho más tratable que enseñar a un generador a autocriticarse.
-Es la misma dinámica que las GAN (Generative Adversarial Networks): el Generador produce, el Evaluador critica, y ese feedback alimenta la siguiente iteración.
-## Cuándo usarla
-- Construir aplicaciones completas a partir de un prompt de una línea
-- Tareas de diseño frontend que exigen alta calidad visual
-- Proyectos full-stack que necesitan funcionalidades que funcionen, no solo código
-- Cualquier tarea donde la estética genérica "hecha por IA" sea inaceptable
-- Proyectos donde compensa invertir un presupuesto alto por salida con calidad de producción
-## Cuándo NO usarla
-- Arreglos rápidos de un solo archivo (usa el flujo estándar del CLI)
-- Tareas con presupuesto muy ajustado
-- Refactorizaciones simples
-- Tareas ya bien especificadas con tests (usa el flujo TDD, `skills/flujo-tdd/`)
-## Arquitectura
-```
-                    ┌──────────────┐
-                    │ PLANIFICADOR │
-                    └──────┬───────┘
-                           │ Especificación de producto
-                           │ (features, sprints, dirección de diseño)
-                           ▼
-              ┌────────────────────────┐
-              │                        │
-              │   BUCLE DE FEEDBACK    │
-              │   GENERADOR-EVALUADOR  │
-              │                        │
-              │  ┌──────────┐          │
-              │  │GENERADOR │-construye│──┐
-              │  └────▲─────┘          │  │
-              │       │                │  │ app en vivo
-              │    feedback            │  │
-              │       │                │  │
-              │  ┌────┴─────┐          │  │
-              │  │EVALUADOR │<-prueba--│──┘
-              │  │+Playwright│         │
-              │  └──────────┘          │
-              │                        │
-              │   5-15 iteraciones     │
-              └────────────────────────┘
-```
-## Los tres agentes
-### 1. Planificador (`agents/planificador-harness.md`)
-**Rol:** product manager — expande un prompt breve a una especificación completa de producto.
-**Comportamientos clave:**
-- Toma un prompt de una línea y produce una especificación multi-sprint con más de una docena de features
-- Define historias de usuario, requisitos técnicos y dirección de diseño visual
-- Es deliberadamente **ambicioso** — la planificación conservadora produce resultados decepcionantes
-- Produce los criterios de evaluación que el Evaluador usará después
-**Modelo:** el más capaz disponible en el catálogo (necesita razonamiento profundo para expandir la especificación).
-### 2. Generador (`agents/generador-harness.md`)
-**Rol:** desarrollador — implementa las features según la especificación.
-**Comportamientos clave:**
-- Trabaja en sprints estructurados (o en modo continuo con modelos más capaces)
-- Negocia un "contrato de sprint" con el Evaluador antes de escribir código
-- Usa tooling full-stack: React, FastAPI/Express, bases de datos, CSS
-- Gestiona git para versionar entre iteraciones
-- Lee el feedback del Evaluador y lo incorpora en la siguiente iteración
-**Modelo:** el más capaz disponible (necesita capacidad de código fuerte).
-### 3. Evaluador (`agents/evaluador-harness.md`)
-**Rol:** ingeniero de QA — prueba la aplicación viva en ejecución, no solo el código.
-**Comportamientos clave:**
-- Usa **Playwright (MCP)** para interactuar con la aplicación en vivo
-- Recorre las features con clics, rellena formularios, prueba endpoints de API
-- Puntúa contra cuatro criterios (configurables):
-  1. **Calidad de diseño** — ¿se siente como un todo coherente?
-  2. **Originalidad** — ¿decisiones propias o patrones de plantilla/IA?
-  3. **Factura** — ¿tipografía, espaciado, animaciones, micro-interacciones?
-  4. **Funcionalidad** — ¿todas las features realmente funcionan?
-- Devuelve feedback estructurado con puntuaciones y problemas concretos
-- Está diseñado para ser **implacablemente estricto** — jamás elogia trabajo mediocre
-**Modelo:** el más capaz disponible (necesita buen juicio + uso de herramientas).
-## Criterios de evaluación
-Los cuatro criterios por defecto, cada uno puntuado 1-10:
-```markdown
-## Rúbrica de evaluación
-### Calidad de diseño (peso: 0.3)
-- 1-3: genérico, de plantilla, estética "IA genérica"
-- 4-6: competente pero anodino, sigue convenciones
-- 7-8: identidad visual distintiva y cohesiva
-- 9-10: podría pasar por el trabajo de un diseñador profesional
-### Originalidad (peso: 0.2)
-- 1-3: colores por defecto, layouts de stock, sin personalidad
-- 4-6: algunas decisiones propias, mayormente patrones estándar
-- 7-8: visión creativa clara, enfoque único
-- 9-10: sorprendente, deleitable, genuinamente novedoso
-### Factura (peso: 0.3)
-- 1-3: layouts rotos, estados faltantes, sin animaciones
-- 4-6: funciona pero se siente tosco, espaciado inconsistente
-- 7-8: pulido, transiciones suaves, responsivo
-- 9-10: pixel-perfect, micro-interacciones deleitables
-### Funcionalidad (peso: 0.2)
-- 1-3: features centrales rotas o ausentes
-- 4-6: el camino feliz funciona, los casos límite fallan
-- 7-8: todas las features funcionan, buen manejo de errores
-- 9-10: a prueba de balas, maneja todos los casos límite
-```
-### Puntuación
-- **Puntuación ponderada** = suma de (puntuación_criterio * peso)
-- **Umbral de aprobación** = 7.0 (configurable)
-- **Máximo de iteraciones** = 15 (configurable; 5-15 suele bastar)
-## Uso
-### Vía comandos
-```bash
-# Harness completo de tres agentes
-/harness-build "Construye una app de gestión de proyectos con tableros Kanban, colaboración en equipo y modo oscuro"
-# Con configuración propia
-/harness-build "Construye una plataforma para compartir recetas" --max-iterations 10 --pass-threshold 7.5
-# Modo diseño frontend (generador + evaluador, sin planificador)
-/harness-diseno "Crea una landing para un tracker de portafolio cripto"
-```
-### Manual, con el CLI en modo no interactivo
-```bash
-# Paso 1: planificar
-theus -p "Eres un planificador de producto. Lee el prompt del planificador. Expande este brief en una especificación completa: 'Construye una app de tablero Kanban'. Escribe la especificación en spec.md"
-# Paso 2: generar (iteración 1)
-theus -p "Eres un Generador. Lee spec.md. Implementa el Sprint 1. Arranca el servidor de desarrollo en el puerto 3000."
-# Paso 3: evaluar (iteración 1)
-theus -p --allowedTools "Read,Bash,mcp__playwright__*" "Eres un Evaluador. Lee el prompt del evaluador. Prueba la app en vivo en http://localhost:3000. Puntúa contra la rúbrica. Escribe el feedback en feedback-001.md"
-# Paso 4: generar (iteración 2 — lee el feedback)
-theus -p "Eres un Generador. Lee spec.md y feedback-001.md. Corrige todos los problemas. Mejora las puntuaciones."
-# Repetir pasos 3-4 hasta alcanzar el umbral de aprobación
-```
-## Evolución según la capacidad del modelo
-El harness debe simplificarse a medida que los modelos mejoran:
-### Etapa 1 — modelos menos capaces
-- Descomposición completa en sprints obligatoria
-- Reinicios de contexto entre sprints (evita la ansiedad de contexto)
-- Mínimo 2 agentes: inicializador + agente de código
-- El andamiaje pesado compensa las limitaciones del modelo
-### Etapa 2 — modelos capaces
-- Harness completo de 3 agentes: Planificador + Generador + Evaluador
-- Contratos de sprint antes de cada fase de implementación
-- Descomposición en ~10 sprints para apps complejas
-- Los reinicios de contexto siguen siendo útiles pero menos críticos
-### Etapa 3 — modelos frontier
-- Harness simplificado: una sola pasada de planificación, generación continua
-- La evaluación se reduce a una pasada final (el modelo es más listo)
-- Sin estructura de sprints
-- La compactación automática del CLI absorbe el crecimiento de contexto
-> **Principio clave:** cada componente del harness codifica una suposición sobre lo que el modelo no puede hacer solo. Cuando los modelos mejoran, vuelve a poner a prueba esas suposiciones. Elimina lo que ya no haga falta.
-## Configuración
-Parámetros del bucle (se pasan como flags a `/harness-build` y `/harness-diseno`):
-| Parámetro | Por defecto | Descripción |
-|-----------|-------------|-------------|
-| `--max-iterations` | `15` | Máximo de ciclos generador-evaluador |
-| `--pass-threshold` | `7.0` | Puntuación ponderada para aprobar (1-10) |
-| Criterios de la rúbrica | `diseño,originalidad,factura,funcionalidad` | Editables en `harness/eval-rubric.md` |
-| Puerto del servidor dev | `3000` | Puerto de la app en vivo |
-| Comando del servidor dev | `npm run dev` | Comando de arranque |
-### Modos de evaluación
-| Modo | Herramientas | Ideal para |
-|------|-------------|-----------|
-| `playwright` | MCP de navegador + interacción en vivo | Apps full-stack con UI |
-| `screenshot` | Captura + análisis visual | Sitios estáticos, solo diseño |
-| `code-only` | Tests + linting + build | APIs, librerías, herramientas CLI |
-## Antipatrones
-1. **Evaluador demasiado indulgente** — si el evaluador aprueba todo en la iteración 1, la rúbrica es demasiado generosa. Endurece los criterios y añade penalizaciones explícitas para los patrones típicos de IA.
-2. **Generador que ignora el feedback** — asegúrate de que el feedback se pasa como archivo, no inline. El generador debe leer `feedback-NNN.md` al inicio de cada iteración.
-3. **Bucles infinitos** — fija siempre el máximo de iteraciones. Si el generador no logra superar una meseta de puntuación tras 3 iteraciones, detente y marca para revisión humana.
-4. **Evaluador que prueba superficialmente** — el evaluador debe usar Playwright para **interactuar** con la app en vivo, no solo capturarla. Que haga clic en botones, rellene formularios, pruebe estados de error.
-5. **Evaluador que elogia sus propios arreglos** — nunca dejes que el evaluador sugiera arreglos y luego evalúe esos arreglos. El evaluador solo critica; el generador arregla.
-6. **Agotamiento de contexto** — en sesiones largas, apóyate en la compactación automática del CLI o reinicia el contexto entre fases mayores.
-## Resultados: qué esperar
-Según resultados publicados en la literatura del sector sobre harnesses de larga duración:
-| Métrica | Agente solo | Harness generador-evaluador | Diferencia |
-|---------|-------------|------------------------------|------------|
-| Tiempo | 20 min | 4-6 horas | 12-18x más |
-| Coste | bajo | 14-22x más | 14-22x más |
-| Calidad | apenas funcional | lista para producción | cambio de fase |
-| Features centrales | rotas | todas funcionando | N/A |
-| Diseño | IA genérica | distintivo, pulido | N/A |
-**El trade-off es claro:** ~20x más tiempo y coste a cambio de un salto cualitativo en la salida. Es para proyectos donde la calidad importa.
-## Relacionados
-- Agentes: `agents/planificador-harness.md`, `agents/generador-harness.md`, `agents/evaluador-harness.md`
-- Comandos: `/harness-build`, `/harness-diseno`
-- Skills: `skills/harness-evaluacion/`, `skills/construccion-harness-agentes/`
-- Lectura de contexto: [Martin Fowler — Harness Engineering](https://martinfowler.com/articles/exploring-gen-ai/harness-engineering.html)

package/vendor/theus-arsenal/skills/homelab-diseno-red/SKILL.md DELETED Viewed

@@ -1,120 +0,0 @@
----
-name: homelab-diseno-red
-description: Planificación práctica de redes domésticas y de homelab — gateways, switches, puntos de acceso, rangos IP, reservas DHCP, DNS, cableado y los errores más comunes de principiante.
----
-# Diseño de red para homelab
-Usa esta skill para diseñar una red doméstica o de laboratorio pequeño que pueda crecer sin necesitar una reconstrucción completa.
-## Cuándo usarla
-- Al planificar una red doméstica nueva o rediseñar un montaje con solo el router del ISP.
-- Al elegir los roles de gateway, switch y puntos de acceso.
-- Al diseñar rangos IP, ámbitos DHCP, reservas estáticas y DNS.
-- Al prepararse para futuras VLANs, Pi-hole, NAS, servidores de laboratorio o acceso VPN.
-- Al diagnosticar una red recién montada con doble NAT, Wi-Fi inestable o servidores que cambian de dirección.
-## Cómo funciona
-Empieza separando los roles de los dispositivos:
-```text
-Internet
-  |
-Módem u ONT
-  |
-Gateway o router       NAT, firewall, DHCP, DNS, enrutamiento inter-VLAN
-  |
-Switch gestionado      clientes cableados, uplinks de APs, troncales VLAN opcionales
-  |
-Puntos de acceso       solo Wi-Fi; idealmente con backhaul cableado
-Servidores y NAS       direcciones estables, nombres DNS, monitorización
-Clientes e IoT         pools DHCP, aislados más adelante si hay VLANs
-```
-Elige un gateway que encaje con el operador, no solo con la lista de funciones:
-| Opción | Mejor encaje | Notas |
-| --- | --- | --- |
-| Router del ISP | Solo internet básico | Control limitado y soporte de VLAN a menudo pobre |
-| Gateway UniFi | Red doméstica gestionada | Buena UI, dependencia del ecosistema |
-| OPNsense o pfSense | Homelab flexible | Control sólido de VLAN, firewall, VPN y DNS |
-| MikroTik | Usuarios de red avanzados | Potente, pero fácil de configurar mal |
-| Router Linux | Aficionados al cacharreo | Documenta el rollback antes de usarlo como gateway principal |
-## Plan de IPs
-Evita el rango por defecto más común, `192.168.1.0/24`, cuando prevés usar VPNs. Suele chocar con hoteles, oficinas y routers de ISP.
-```text
-Ejemplo de plan para un homelab pequeño:
-192.168.10.0/24  clientes de confianza
-192.168.20.0/24  dispositivos IoT y multimedia
-192.168.30.0/24  servidores y NAS
-192.168.40.0/24  Wi-Fi de invitados
-192.168.99.0/24  gestión de red
-Convención de gateway: .1
-Reservas de infraestructura: .2 a .49
-Pool DHCP dinámico: .50 a .240
-Margen de reserva: .241 a .254
-```
-Usa `home.arpa` para los nombres locales. Está reservado para redes domésticas y evita los problemas de fugas y conflictos de nombres improvisados como `home.lan`.
-```text
-nas.home.arpa
-pihole.home.arpa
-gateway.home.arpa
-switch-01.home.arpa
-```
-## DHCP y DNS
-- Usa reservas DHCP para todo aquello a lo que haces SSH, guardas en marcadores, monitorizas o expones como servicio.
-- Entrega el gateway como DNS hasta que despliegues intencionadamente un resolutor local.
-- Si usas Pi-hole u otro filtro DNS, dale primero una reserva y luego apunta las opciones DNS del DHCP a esa dirección.
-- Mantén un rango pequeño de direcciones estáticas/reservadas por subred para que los reemplazos no colisionen con los leases dinámicos.
-## Cableado y Wi-Fi
-- Prefiere backhaul cableado para los APs en lugar de mesh siempre que puedas tender Ethernet.
-- Usa un switch PoE para APs y cámaras si el presupuesto lo permite.
-- Etiqueta ambos extremos de cada cable y mantén un mapa de puertos sencillo.
-- Pon el gateway, el switch, el servidor DNS y el NAS en un SAI si los cortes de luz son frecuentes.
-## Ejemplos
-### Mejora para principiantes
-Objetivo: conservar el router del ISP pero estabilizar un laboratorio pequeño.
-1. Configura reservas DHCP para el NAS, la Pi y cualquier host con SSH.
-2. Mueve los nombres locales a `home.arpa`.
-3. Desactiva los servidores DHCP duplicados en routers secundarios o APs.
-4. Cablea el AP principal en lugar de depender de backhaul inalámbrico.
-### Plan preparado para VLANs
-Objetivo: prepararse para una futura segmentación sin activarla de inmediato.
-1. Elige rangos /24 no solapados para confianza, IoT, servidores, invitados y gestión.
-2. Reserva la .1 para el gateway y la .2-.49 para infraestructura en cada subred.
-3. Compra un gateway y un switch que soporten VLANs y reglas de firewall inter-VLAN.
-4. Documenta qué SSIDs y puertos del switch se mapearán con el tiempo a cada red.
-## Antipatrones
-- Doble NAT sin motivo ni documentación.
-- Usar `192.168.1.0/24` cuando se planea acceso VPN.
-- Direcciones dinámicas para el NAS, Pi-hole, Home Assistant u otros hosts de servicio.
-- Routers de consumo reciclados como APs con sus servidores DHCP todavía activos.
-- Redes planas con cámaras, enchufes inteligentes, portátiles y servidores compartiendo el mismo límite de confianza.
-## Skills relacionadas
-- `homelab-preparacion-red`
-- `salud-interfaces-red`
-- `validacion-config-red`