theus-cli-linux-arm64 0.2.84

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

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

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

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