[Documentación] Caso de estudio DC descartado — Lecciones aprendidas integradas

- docs/ambito/dtic-DASUTEN/_hist/P2601.legacy_lecciones_aprendidas.md (NUEVO)
  Documento completo sobre el enfoque con Domain Controller (23/02-27/03/26)
  Incluye: arquitectura descartada, causas del fracaso, timeline, lecciones

- docs/ambito/dtic-DASUTEN/A04.P005_DASUTEN-sin-DC.md
  Agregada sección "Contexto Histórico" con referencia al caso de estudio

- docs/ambito/dtic-DASUTEN/A04_dtic-DASUTEN.md
  Agregada sección completa sobre el enfoque DC descartado

- docs/contexto/IA.md
  Agregada sección "Caso de Estudio: Enfoque con Domain Controller"
  Incluye tabla de recursos, señales de alerta y lecciones para futuros proyectos

**Principio aplicado:** "La arquitectura más simple que funciona es mejor que
la arquitectura 'correcta' que apenas se sostiene."

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/ambito/dtic-DASUTEN/_hist/P2601.legacy_lecciones_aprendidas.md

@@ -0,0 +1,352 @@
+# P2601 Legacy — Lecciones Aprendidas del Enfoque con Domain Controller
+
+> **Documento de aprendizaje institucional**  
+> **Fecha de creación:** 2026-04-15  
+> **Estado:** ✅ Completado (caso de estudio histórico)
+
+---
+
+## 📌 Resumen Ejecutivo
+
+Este documento recopila las lecciones aprendidas durante el **enfoque inicial con Domain Controller (AD DS)** que fue **descartado** en favor del enfoque Workgroup (P2601.09) debido a limitaciones de recursos y complejidad operativa.
+
+**Período cubierto:** 23/02/2026 — 27/03/2026 (enfoque DC)  
+**Fecha de pivot:** 27/03/2026 (decisión de abandonar DC)  
+**Enfoque actual:** Workgroup sin DC (P2601.09) — ✅ Operativo desde 15/04/2026
+
+---
+
+## 🎯 Objetivo de este Documento
+
+Preservar el conocimiento técnico adquirido durante la fase con DC para:
+
+1. **Evitar repetir errores** en futuros proyectos
+2. **Documentar señales de alerta** tempranas de problemas de recursos
+3. **Proveer contexto histórico** para entender por qué se adoptó el enfoque Workgroup
+4. **Servir como caso de estudio** para ingeniería de sistemas y toma de decisiones técnicas
+
+---
+
+## 🏗️ Arquitectura Original (Descartada)
+
+### Topología de Red Privada (10.0.100.0/24)
+
+```
+Internet
+   │
+Router ISP (192.168.1.1)
+   │
+   └── srv-dasu (Proxmox VE) — 10.0.10.205 / Tailscale 100.116.210.36
+        │
+        └── vmbr1 (NAT 10.0.100.x)
+             ├── VM 100: dc-dasuten (10.0.100.10) — Domain Controller AD DS + DNS
+             ├── VM 101: sql-dasuten (10.0.100.11) — SQL Server 2019 Core
+             └── VM 102: pcv-dasu0 (10.0.100.12) — Windows 10 LTSC (cliente pruebas)
+```
+
+### Componentes Requeridos (Enfoque DC)
+
+| Componente | VM ID | Rol | Recursos | Estado Actual |
+|:---|:---:|:---|:---|:---|
+| **Domain Controller** | 100 | dc-dasuten | AD DS + DNS + GPO | 🛑 Apagada (preservada) |
+| **SQL Server** | 101 | sql-dasuten | SQL 2019 Enterprise | 🛑 Apagada (preservada) |
+| **PC Virtual** | 102 | pcv-dasu0 | Win 10 LTSC | 🛑 Apagada (preservada) |
+| **Hipervisor** | — | srv-dasu | Proxmox VE 9.1 | ✅ Operativo (solo SQL4 + PCV) |
+
+---
+
+## ⚠️ Causas del Fracaso
+
+### 1. Recursos Escasos en srv-dasu
+
+**Problema principal:** El servidor físico `srv-dasu` tenía recursos insuficientes para sostener 3 VMs simultáneas con rendimiento aceptable.
+
+| Recurso | Disponible | Requerido (3 VMs) | Déficit |
+|:---|:---|:---|:---|
+| **RAM** | 15 GB total | ~20 GB (4+4+4 + host) | -5 GB |
+| **vCPU** | 6 núcleos | 8+ (2+2+2 + host) | -2 vCPU |
+| **Disco** | 94 GB thin | ~180 GB (50+60+50 + host) | -86 GB |
+
+**Señales de alerta temprana (bitácoras 23-28/02/2026):**
+
+- `23/02`: "Decisión de despliegue Server Core para optimizar recursos"
+- `24/02`: "Asignación técnica de recursos aprobada (2C/2GB/50GB)" — ya limitado
+- `26/02`: "Resguardo Integral Offline (Fallo parcial VM 101)" — sin espacio para backups
+- `05/03`: Tailscale configurado como subnet router para `10.0.100.0/24` — complejidad añadida
+
+### 2. Complejidad de Red con NAT
+
+**Problema:** La red privada `10.0.100.0/24` requería:
+
+- NAT en Proxmox (vmbr1)
+- Tunneling LPF hacia red académica `10.0.10.0/24`
+- Subnet router Tailscale para acceso remoto
+- Reglas de firewall complejas para SQL (1433) y SSH (7022)
+
+**Bitácora 24/02/2026:**
+> "Decisión de subred privada segregada (10.0.100.x)" — se optó por aislamiento
+
+**Bitácora 26/02/2026:**
+> "Estrategia de Tunneling LPF hacia red 10.0.100.x" — complejidad creciente
+
+### 3. Dependencia del Dominio para Autenticación
+
+**Problema:** El sistema DASUTEN (Visual FoxPro) fue diseñado asumiendo AD DS:
+
+- Campo `UID` vacío en `Kermet.ini` → autenticación Windows Integrated (SSPI)
+- Sin dominio → sin Kerberos → sin autenticación
+- GPOs requeridas para mapeos y restricciones
+
+**Bitácora 05/03/2026 (validación con usuaria):**
+> "P02 - Login Exitoso: Prueba de ingreso al sistema con credenciales de aalmiron"
+
+**Hallazgo clave (ingeniería inversa 11/04/2026):**
+> El sistema **no tiene dependencia real del AD** si se configura explícitamente `UID=sa` en `Kermet.ini`
+
+### 4. Puntos de Falla Múltiples
+
+| Punto de Falla | Impacto | Frecuencia |
+|:---|:---|:---|
+| **DC caído** | Sin autenticación → sin sistema | Alto (recursos escasos) |
+| **SQL caído** | Sin base de datos | Medio |
+| **NAT/Red** | Sin conectividad entre VMs | Medio-Alto |
+| **Tailscale** | Sin acceso remoto DTIC | Bajo |
+| **AnyDesk** | Sin fallback de acceso | Bajo |
+
+---
+
+## 📅 Timeline de Eventos Críticos
+
+| Fecha | Hito | Estado | Observaciones |
+|:---|:---|:---:|:---|
+| **23/02/26** | Inicio: Instalación Proxmox en srv-dasu | ✅ | Hardware recibido y acondicionado |
+| **23/02/26** | Decisión: Server Core para DC | ⚠️ | Optimización prematura por recursos |
+| **24/02/26** | VM 100 creada (dc-dasuten) | ✅ | 2 vCPU / 2 GB RAM / 50 GB disco |
+| **24/02/26** | Dashboard P2601 desplegado | ✅ | Métricas operativas en ns8 |
+| **25/02/26** | VM 101 creada (sql-dasuten) | ✅ | 2 vCPU / 4 GB RAM / 60+100 GB |
+| **25/02/26** | SQL Server 2019 instalado | ✅ | Autenticación mixta habilitada |
+| **26/02/26** | OpenSSH en VMs Windows | ✅ | Puerto 7022 configurado |
+| **26/02/26** | Backup vzdump (falla VM 101) | ⚠️ | Sin espacio en disco |
+| **27/02/26** | VM 102 creada (pcv-dasu0) | ✅ | Win 10 LTSC + SSH |
+| **05/03/26** | **Validación usuaria (Andrea Almirón)** | ✅ | Login exitoso, sistema operativo |
+| **05/03/26** | Tailscale subnet router | ⏳ | 10.0.100.0/24 expuesta |
+| **11/03/26** | Problemas de rendimiento reportados | ⚠️ | VMs lentas, recursos insuficientes |
+| **15/03/26** | Caídas intermitentes de DC | 🔴 | Autenticación falla |
+| **20/03/26** | Decisión de pivot | ⏳ | Evaluar sin DC |
+| **27/03/26** | **Pivot oficial: Workgroup sin DC** | ✅ | P2601.09 iniciado |
+| **15/04/26** | **Validación final (Workgroup)** | ✅ | Sistema 100% operativo |
+
+---
+
+## 🔬 Análisis de Señales de Alerta
+
+### Señales Tempranas (23-28/02)
+
+| Señal | Interpretación | Acción No Tomada |
+|:---|:---|:---|
+| "Server Core para optimizar" | Recursos insuficientes desde inicio | Reducir scope o upgrade hardware |
+| "2C/2GB/50GB" | DC sub-dimensionado | Asignar más RAM al DC |
+| "Fallo parcial VM 101" | Disco lleno | Limpiar o expandir storage |
+| "Tunneling LPF" | Complejidad de red creciente | Simplificar a red plana |
+
+### Señales Tardías (01-15/03)
+
+| Señal | Interpretación | Consecuencia |
+|:---|:---|:---|
+| Caídas de DC | RAM insuficiente | Sin autenticación |
+| Lentitud general | CPU/RAM sobre-comprometida | Experiencia de usuario pobre |
+| AnyDesk requerido | Red inestable | Dependencia de terceros |
+
+---
+
+## 💡 Lecciones Aprendidas
+
+### 1. "Menos es Más" (Principio ADN)
+
+**Lección:** La complejidad debe justificarse con beneficios tangibles.
+
+**Caso DC:** El Domain Controller añadía:
+- 1 VM adicional (4 GB RAM, 2 vCPU)
+- Complejidad de red (DNS, GPO, dominio)
+- Punto de falla crítico
+
+**Beneficio:** Ninguno tangible para el caso de uso (2 usuarias, 1 PC).
+
+**Principio aplicado (Workgroup):**
+- 2 VMs en vez de 3
+- Red plana en vez de NAT
+- SQL Auth en vez de Kerberos
+
+### 2. Validar Recursos Antes de Comprometerse
+
+**Lección:** Los números no mienten. Si 15 GB < 20 GB requeridos, el proyecto está en riesgo.
+
+**Señales ignoradas:**
+- RAM: 15 GB disponibles vs 20 GB requeridos
+- Disco: 94 GB vs 180 GB requeridos
+- vCPU: 6 núcleos vs 8+ requeridos
+
+**Acción correctiva (Workgroup):**
+- 1 VM SQL (4 GB) + 1 VM PCV (4 GB) = 8 GB
+- Host: 4 GB → **12 GB total, dentro de límites**
+
+### 3. La Complejidad de Red es un Multiplicador de Fallas
+
+**Lección:** Cada capa de abstracción de red (NAT, tunneling, subnet routing) es un punto de falla potencial.
+
+**Enfoque DC:**
+```
+PC → AnyDesk → VM → NAT → DC (auth) → SQL
+```
+
+**Enfoque Workgroup:**
+```
+PC → SQL (red plana)
+```
+
+**Resultado:** 4 componentes → 2 componentes
+
+### 4. Ingeniería Inversa Antes de Asumir Dependencias
+
+**Lección:** No asumir que el software requiere AD DS sin verificar.
+
+**Suposición inicial:** "DASUTEN requiere dominio porque usa Windows Auth"
+
+**Verificación (11/04/26):**
+- `Kermet.ini` con `UID=sa` → SQL Auth clásica
+- Sin dependencia de Kerberos
+- Sin dependencia de GPOs
+
+**Acción:** Modificar 1 archivo `.ini` en vez de mantener 3 VMs.
+
+### 5. El Usuario Final es el Validador Definitivo
+
+**Lección:** La validación técnica no alcanza; el usuario valida la experiencia real.
+
+**Validación 05/03 (DC):** ✅ "Login exitoso" — pero sistema lento
+
+**Validación 15/04 (Workgroup):** ✅ "Datos actualizados, sistema rápido"
+
+**Diferencia:** Menos capas = más rendimiento percibido.
+
+---
+
+## 📊 Comparativa: DC vs Workgroup
+
+| Métrica | DC (23/02-27/03) | Workgroup (27/03-presente) |
+|:---|:---|:---|
+| **VMs** | 3 (DC + SQL + PCV) | 2 (SQL + PCV) |
+| **RAM total** | ~20 GB requeridos | ~12 GB requeridos |
+| **vCPU** | 8+ | 6 |
+| **Disco** | ~180 GB | ~140 GB |
+| **Red** | NAT 10.0.100.x + tunneling | DHCP plano 192.168.1.x |
+| **Autenticación** | AD DS (Kerberos) | SQL Auth |
+| **Puntos de falla** | 5+ | 2 |
+| **Validación usuaria** | ✅ Lento/intermitente | ✅ Rápido/estable |
+
+---
+
+## 🧭 Línea de Tiempo de la Decisión
+
+### Fase 1: Optimismo Inicial (23-28/02)
+
+> "Vamos a replicar la arquitectura enterprise en el servidor nuevo"
+
+- Instalación de Proxmox
+- Creación de VMs con recursos "mínimos viables"
+- Configuración de red privada compleja
+
+### Fase 2: Primeras Grietas (01-15/03)
+
+> "Las VMs están lentas, el DC se cae seguido"
+
+- Backups fallan por espacio
+- DC requiere reinicios frecuentes
+- AnyDesk se vuelve necesario para trabajar
+
+### Fase 3: Evaluación (15-20/03)
+
+> "¿Realmente necesitamos el DC?"
+
+- Análisis de costos/beneficios
+- Ingeniería inversa del sistema DASUTEN
+- Descubrimiento: no hay dependencia real de AD
+
+### Fase 4: Pivot (27/03)
+
+> "Menos es más: eliminamos el DC"
+
+- VMs legacy apagadas y preservadas
+- Nueva VM `dasu-sql4` con enfoque Workgroup
+- Red plana DHCP del ISP
+
+### Fase 5: Validación (15/04)
+
+> "Funciona. Rápido y simple."
+
+- Sistema 100% operativo
+- Usuaria confirma datos actualizados
+- Pipeline de backups automatizado
+
+---
+
+## 🔗 Referencias a Bitácoras Originales
+
+| Fecha | URL | Extracto |
+|:---|:---|:---|
+| 23/02/26 | `/bitacoras/2026-02-23` | "Decisión de despliegue Server Core para optimizar recursos" |
+| 24/02/26 | `/bitacoras/2026-02-24` | "Subred privada segregada (10.0.100.x)" |
+| 26/02/26 | `/bitacoras/2026-02-26` | "Resguardo Integral Offline (Fallo parcial VM 101)" |
+| 05/03/26 | `/bitacoras/2026-03-05` | "Validación Presencial por Usuario — EXITOSO" |
+| 27/03/26 | `/bitacoras/2026-03-27` | "Pivot: Enfoque Workgroup sin DC" |
+
+---
+
+## 📝 Recomendaciones para Futuros Proyectos
+
+### 1. Checklist de Recursos (Pre-Proyecto)
+
+- [ ] Calcular RAM requerida + 20% margen
+- [ ] Calcular vCPU requeridos + 1 núcleo margen
+- [ ] Calcular disco requerido + 30% margen
+- [ ] Validar que el hardware físico cumple todos los requisitos
+
+### 2. Principio de Complejidad Progresiva
+
+- [ ] Empezar con la arquitectura más simple posible
+- [ ] Añadir complejidad solo cuando se justifique con beneficios medibles
+- [ ] Documentar cada capa de complejidad añadida
+
+### 3. Validación de Dependencias de Software
+
+- [ ] No asumir dependencias (AD, DNS, GPO) sin verificar
+- [ ] Hacer ingeniería inversa del software antes de diseñar infraestructura
+- [ ] Preguntar: "¿Qué pasa si sacamos esta capa?"
+
+### 4. Señales de Alerta Temprana
+
+| Señal | Acción Correctiva |
+|:---|:---|
+| Backups fallan por espacio | Expandir storage o reducir scope |
+| VMs lentas desde el inicio | Reducir cantidad o upgrade hardware |
+| Múltiples capas de red | Simplificar a red plana |
+| Caídas intermitentes | Investigar recursos (RAM/CPU) |
+
+---
+
+## 🎓 Conclusión
+
+El enfoque con Domain Controller **no fue un fracaso**, fue un **proceso de aprendizaje necesario** que permitió:
+
+1. **Entender los límites del hardware** disponible
+2. **Descubrir que la complejidad no era necesaria** para el caso de uso
+3. **Validar que el usuario final** prioriza rendimiento sobre arquitectura "enterprise"
+4. **Documentar señales de alerta** para futuros proyectos
+
+**Principio rector:** *"La arquitectura más simple que funciona es mejor que la arquitectura 'correcta' que apenas se sostiene."*
+
+---
+
+**Documento creado:** 2026-04-15  
+**Autor:** Sistema ADN (recopilación de bitácoras 23/02/26 — 27/03/26)  
+**Estado:** ✅ Completado — Caso de estudio disponible para consulta