[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/contexto/IA.md

@@ -238,7 +238,7 @@ Para información completa sobre todas las hebras del ADN, consultar `adn/00_ind
 | `docs/ambito/dtic-DIIAA/` | Ámbito A09: IA y Automatizaciones — `./adn/tools/run dron` |
 | `adn/tools/cli/dron.rb` | Drones: tareas background con auto-bitácora — `./adn/tools/run dron` |
 
-**Última actualización:** 2026-04-10 (A06: Creación de ámbito dtic-XenServer + diagnóstico SSH legacy)
+**Última actualización:** 2026-04-15 (DASUTEN: Pipeline backups validado + migración TZ + validación usuaria)
 **Próxima revisión:** Al inicio de cada sesión
 
 ---
@@ -367,6 +367,117 @@ ruby adn/tools/candados/candados.rb --help # Help completa
 
 ---
 
+## 🛠️ Pipeline de Backups DASUTEN — Validación Completa (2026-04-15)
+
+**Contexto:** Tras la integración de los drones de backup en `bkps.rb`, se realizó una validación completa del pipeline junto con la migración final de la base de datos.
+
+**Hallazgos y soluciones:**
+
+| Problema | Causa | Solución |
+|----------|-------|----------|
+| Restore no usaba backup correcto | Dron buscaba por LastWriteTime en lugar de nombre específico | Modificar `dasuten_download_drive.rb` para pasar `backup_name` en JSON |
+| Zona horaria incorrecta en dasu-sql4 | "Romance Standard Time" (UTC+2) en lugar de Argentina (UTC-3) | `Set-TimeZone -Id "Argentina Standard Time"` |
+| Datos "desactualizados" en desktop | Fechas interpretadas con ~5 horas de desplazamiento por TZ incorrecta | Restore completo + TZ corregida |
+
+**Comandos creados:**
+- `adn/tools/cli/verificar_fechas_timezone_dasu.rb` — Verificar fechas y TZ
+- `adn/tools/cli/configurar_zona_horaria_dasu.rb` — Configurar TZ Argentina
+- `adn/tools/cli/verificar_zona_horaria_dasu.rb` — Verificar configuración TZ
+- `adn/tools/cli/verificacion_final_comparativa.rb` — Comparar FENIX vs DASU-SQL4
+
+**Validación del usuario (2026-04-15 17:00):** Andrea Almirón confirmó que el sistema desktop muestra correctamente los movimientos del día en curso.
+
+**Lección clave:** Un pipeline técnicamente exitoso (backups, transferencias, restore, DBCC CHECKDB) necesita validación del usuario final. La zona horaria incorrecta fue la causa raíz de que los datos se vieran "desactualizados" — los backups se realizaban correctamente, pero las fechas se interpretaban mal.
+
+---
+
+## 🛠️ Arquitectura de Drones Atómicos para Backups (2026-04-15)
+
+**Patrón implementado:** Pipeline de backups con drones atómicos interconectados vía JSON.
+
+**Flujo:**
+```
+srvv-fenix (BACKUP WITH COMPRESSION)
+    ↓ SMB
+srv-ns8 (/var/tmp/)
+    ↓ rclone
+Google Drive (drive_bkps-dasu)
+    ↓ HTTP Download
+dasu-sql4 (F:\BACKUP\)
+    ↓ RESTORE + DBCC CHECKDB
+```
+
+**Drones atómicos:**
+1. `dasuten_exportar_srvv-fenix.rb` → Output: `backup_ruta_unix`, `backup_tipo`
+2. `dasuten_transferir_srvv-fenix-srv-ns8.rb` → Output: `backup_local`, `backup_origen`
+3. `dasuten_upload_srv-ns8-drive.rb` → Output: `drive_ruta`, `drive_url`
+4. `dasuten_download_drive-dasu-sql4.rb` → Output: `backup_local`, `backup_name`, `duracion`
+5. `dasuten_restaurar_dasu-sql4.rb` → Output: `estado_integridad`
+6. `dasuten_verificar-integridad_dasu-sql4.rb` → Output: `estado_integridad`
+
+**Módulo común:** `adn/tools/cli/drones/lib/dasu_executor.rb`
+- `execute_ps_on_dasu(ps_script, output_path:)` — Ejecuta PowerShell en dasu-sql4 vía SSH
+- `read_json_from_dasu(output_path)` — Lee JSON desde dasu-sql4
+- `execute_ps_on_fenix(client, ps_script)` — Ejecuta PowerShell en fenix vía xp_cmdshell
+
+**Lección:** El patrón SSH/PowerShell se define en un solo lugar. Si cambia, se actualiza solo el módulo.
+
+---
+
+## 📚 Caso de Estudio: Enfoque con Domain Controller (Descartado 2026-03-27)
+
+**Documento completo:** [`docs/ambito/dtic-DASUTEN/_hist/P2601.legacy_lecciones_aprendidas.md`](../ambito/dtic-DASUTEN/_hist/P2601.legacy_lecciones_aprendidas.md)
+
+### Contexto Histórico
+
+**Período:** 23/02/2026 — 27/03/2026  
+**Arquitectura original:** 3 VMs con Domain Controller (AD DS + DNS + GPO)
+
+```
+srv-dasu (Proxmox VE 9.1)
+   └── vmbr1 (NAT 10.0.100.x)
+        ├── VM 100: dc-dasuten (10.0.100.10) — Domain Controller
+        ├── VM 101: sql-dasuten (10.0.100.11) — SQL Server 2019 Core
+        └── VM 102: pcv-dasu0 (10.0.100.12) — Windows 10 LTSC
+```
+
+### Causas del Fracaso (Recursos Insuficientes)
+
+| Recurso | Disponible | Requerido | Déficit |
+|:---|:---|:---|:---|
+| RAM | 15 GB | ~20 GB | -5 GB |
+| vCPU | 6 núcleos | 8+ | -2 vCPU |
+| Disco | 94 GB thin | ~180 GB | -86 GB |
+
+### Señales de Alerta Temprana
+
+| 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 |
+
+### Decisión de Pivot (27/03/2026)
+
+Se adoptó el enfoque **Workgroup sin DC** (P2601.09):
+- **2 VMs** en vez de 3
+- **Red plana DHCP** en vez de NAT 10.0.100.x
+- **SQL Auth** en vez de Windows Integrated (Kerberos)
+
+### Lecciones para Futuros Proyectos
+
+1. **Validar recursos ANTES de comprometerse:** Calcular RAM/vCPU/disco + 20% margen
+2. **Complejidad progresiva:** Empezar simple, añadir complejidad solo si se justifica
+3. **Verificar dependencias de software:** No asumir AD/GPO sin ingeniería inversa
+4. **Señales de alerta:** Backups fallando, VMs lentas, caídas intermitentes = investigar recursos
+
+### Principio Aplicado
+
+> *"La arquitectura más simple que funciona es mejor que la arquitectura 'correcta' que apenas se sostiene."*
+
+---
+
 ## 🛠️ Lecciones Aprendidas - DASUTEN VMs (2026-04-08)
 
 **Problema:** VMs dasu-sql2 y dasu-pcv2 mostraban "running" pero sin conectividad IP ni respuesta a ping.