dtic-DIIAA/docs/contexto/IA.md

Contexto para IA - Mecánica de Trabajo dtic-DIIAA

Fecha: 2026-03-25 Versión: 1.3 - Minimalista (Principio "menos es más") Bitácora de referencia: Eventos 1261-1300 (2026-03-25 y 2026-03-26) Actualización: Zona horaria Argentina agregada, renombramiento dasu-pc/dasu-pcv

🎯 Principios Fundamentales (3)

1. Menos es Más: Este archivo contiene solo lo esencial para operar. Para detalles, consultar fuentes canónicas o usar --help en las herramientas ADN.
2. Mejora Continua: Al inicio de cada sesión, ejecutar ./adn/tools/run salud --mejoras --json para identificar oportunidades de optimización.
3. Armonía Integral: Toda acción debe alinearse con las normas vivas del ADN. Ver procedimiento abajo.

---

🌎 Zona Horaria

IMPORTANTE: Este proyecto opera en la zona horaria de Argentina (Buenos Aires).

• UTC: UTC-3 (Argentina no tiene horario de verano permanente)
• Comando local: Usar date para obtener la hora correcta
• Formato registro: HH:MM (24 horas)
• ⚠️ CRÍTICO: Los eventos deben usar la hora real del sistema, NO la hora del agente IA

---

🎯 Principio Fundamental: Bitácora First

TODO lo que hagas DEBE registrarse en bitácora ANTES de ejecutar.

Flujo obligatorio:

1. Registrar contexto en bitácora (db evento:crear)
2. Ejecutar la tarea
3. Actualizar bitácora con resultados (db evento:actualizar --fin)

Ejemplo práctico:

# 1. ANTES de empezar, registrás
./adn/tools/run db evento:crear --nodo dtic-DIIAA \
  --descripcion "[P2604.06] Descripción de lo que voy a hacer" \
  --inicio 08:00

# 2. Ejecutás la tarea
./adn/tools/run <comando>

# 3. Al terminar, actualizás con la hora de fin
./adn/tools/run db evento:actualizar <ID> --fin 08:15

---

🧬 Arquitectura del Ecosistema ADN

Estructura de comandos:

./adn/tools/run <subcomando> [opciones]

⚠️ REGLA CRÍTICA: Antes de SSH

SIEMPRE ejecutar: ./adn/tools/run nodos info <nombre>

Esto muestra: IP, Puerto SSH, Usuario, Auth, Bóveda, SO, VMID

Acceso rápido a información esencial:

• Subcomandos: ./adn/tools/run --help (lista completa)
• Plantillas de eventos: ./adn/tools/run generar evento <tipo>

🔐 Ejecución Remota con Privilegios (Bóveda)

Para ejecutar comandos en nodos remotos como root:

# Usar candados run con clave del nodo
ruby adn/tools/candados/candados.rb run <nodo:usuario> "<comando>"

Ejemplos:

# Conectar como root a srv-dasu
ruby adn/tools/candados/candados.rb run srv-dasu:root "dmidecode -t memory"

# Ejecutar backup en Proxmox
ruby adn/tools/candados/candados.rb run srv-dasu:root "qm stop 104 && vzdump 104 --mode stop"

# Ver VMs
ruby adn/tools/candados/candados.rb run srv-dasu:root "qm list"

Reglas:

• Usar siempre clave de bóveda (nunca password en texto plano)
• Las claves siguen formato: <nodo>:<usuario> (ej: srv-dasu:root, srv-dasu:rmonla)
• Ver claves disponibles: ruby adn/tools/candados/candados.rb list

⚠️ REGLA PARA IA: Antes de leer código fuente

SIEMPRE ejecutar ./adn/tools/run <subcomando> --help o ./adn/tools/run ayuda <subcomando> ANTES de leer archivos .rb para entender cómo funciona una herramienta. La ayuda integrada es suficiente en la mayoría de los casos.

---

🤖 Flujo de Trabajo con IA

Cuando el usuario pide algo:

1. Verificar si está registrado en bitácora

   • Si no → db evento:crear primero
   • Si sí → continuar

2. Ejecutar la tarea

   • Usar comandos ./adn/tools/run
   • Seguir principios de adn/05_ia.md

3. Actualizar bitácora

   • db evento:actualizar <ID> --fin HH:MM
   • Incluir resultados y próximos pasos

Errores comunes a evitar:

❌ Ejecutar sin registrar en bitácora ❌ Todos los eventos con misma hora de inicio ❌ Olvidar el --fin al terminar ❌ Usar /tmp/ en lugar de tmp/ del repo ❌ No verificar candados antes de SSH ❌ Mostrar contraseñas o secretos en texto plano (usar siempre bóveda) ❌ Olvidar especificar --modo R para eventos ejecutados remotamente (IA operando a distancia) ❌ Hacer commits intermedios durante la jornada — el commit y push va al final de la sesión, salvo pedido explícito del usuario

---

📊 Bitácora Web - Fichas por Ámbito

Implementado: 2026-03-25

La vista principal de la Bitácora Web ahora agrupa las entradas por Ámbito en lugar de por Nodo:

• Cada ficha muestra todos los eventos de los nodos del ámbito
• Columna "Nodo" identifica el origen de cada evento
• Badge muestra cantidad de nodos y entradas del ámbito

URL: http://localhost:5174/bitacoras/

---

🚀 Quick Start para Nueva Sesión

# 1. Iniciar jornada
./adn/tools/run jornada iniciar presencial 08:00

# 2. Registrar primera actividad
./adn/tools/run db evento:crear --nodo dtic-DIIAA \
  --descripcion "[P2604.XX] Lo que voy a hacer" \
  --inicio 08:05

# 3. Trabajar
# ... ejecutás tus comandos ...

# 4. Cerrar actividad
./adn/tools/run db evento:actualizar <ID> --fin 08:30

# 5. Verificar en web
# http://localhost:5174

---

🔄 Armonía Integral — Procedimiento de Actualización Documental

¿Qué significa "Aplicar Armonía Integral"?

Armonía Integral es el principio rector que establece que todo está conectado en el ecosistema ADN. Cuando se dice "Aplicar Armonía", se refiere a:

Actualizar u optimizar bitácora, plan, ámbito, contexto y repositorio según corresponda para mantener la consistencia del ecosistema.

Si un dato cambia en un sitio, debe propagarse a todos los demás elementos relevantes.

📋 Qué elementos actualizar cuando se pide "Aplicar Armonía"

Orden	Elemento	Qué actualizar	Cuándo corresponde
1	Bitácora	Evento con resultados y próximos pasos cerrando la tarea actual	Siempre (antes de finalizar sesión o ante cambios de contexto)
2	Plan (ej: A01.P...md)	Estado de tareas, fases completadas, hitos logrados	Si un plan fue modificado, avanzado o completado
3	Ámbito (ej: A01...md)	Tablas de planes, resumen de herramientas, nodos vinculados	Si se crean nuevos planes, Nodos, o finalizan hitos de bloque
4	Contexto (IA.md)	Lecciones aprendidas, cambios en flujos obligatorios, nuevas macros	Si hubo cambios en el modus operandi o nuevas "leyes" asimiladas
5	Repositorio (Git)	Hacer un commit atómico y descriptivo, y enviarlo (push) a remoto	Siempre luego de completar los pasos 1 a 4 para resguardar

Ejemplo de aplicación (2026-04-06):

Cambio: Reestructuración de dtic-DASUTEN a estándar A03

→ 1. Bitácora: Evento #XXXX registrado
→ 2. Contexto/IA.md: No requería (sin cambios operativos)
→ 3. A04_dtic-DASUTEN.md: Manifiesto creado + tabla de planes actualizada
→ 4. A04.P005_DASUTEN-sin-DC.md: Referencias actualizadas
→ 5. Legacy: P2601_dasuten.md → _hist/

Reglas:

• Menos es Más: Actualizar solo lo necesario, sin duplicar información.
• Trazabilidad: Todo cambio debe poder rastrearse desde la bitácora a los documentos.
• Consistencia: Usar siempre el mismo formato (ver docs/ambito/dtic-BKPs/A03_dtic-BKPs.md como referencia).

---

📌 Principio "Menos es Más"

Este archivo contiene solo lo esencial para operar. Para detalles completos, consultar las hebras canónicas:

Para información completa sobre todas las hebras del ADN, consultar adn/00_indice.md. Las más frecuentemente usadas son:

• Seguridad → adn/03_seguridad.md
• Ontología/Ámbitos → adn/01_ontologia.md
• Bitácoras → adn/02_bitacora.md
• IA Directivas → adn/05_ia.md

---

📚 Documentación de Referencia

Archivo	Propósito
adn/00_indice.md	Índice y comandos CLI del ecosistema
adn/05_ia.md	Directivas específicas para IA ⚠️
adn/06_gobernanza.md	3 principios rectores: Menos es Más, Armonía Integral, Mejora Continua
adn/02_bitacora.md	Formato y triggers de bitácoras
adn/03_seguridad.md	Protocolos de seguridad y candados 🔐
adn/01_ontologia.md	Nodos, ámbitos y topología
docs/ambito/dtic-ADN/A01_dtic-ADN.md	Ámbito A01: Ecosistema core — ./adn/tools/run
docs/ambito/dtic-DIGIs/	Ámbito A02: Zoom, YouTube, canales digitales institucionales
docs/ambito/dtic-BKPs/	Ámbito A03: Backups — ./adn/tools/run bkps
docs/ambito/dtic-DASUTEN/	Ámbito A04: Infraestructura DASUTEN — ./adn/tools/run dasuten
docs/ambito/dtic-XenServer/	Ámbito A06: Hipervisor Citrix XenServer 7.0
docs/ambito/dtic-DNS/	Ámbito A07: Administración DNS — ./adn/tools/run dns
docs/ambito/dtic-NOTAS/	Ámbito A08: Sistema de Notas e Informes — Web de plantillas
docs/ambito/dtic-DIIAA/	Ámbito A09: IA y Automatizaciones — ./adn/tools/run dron
docs/ambito/dtic-IDIS/	Ámbito A10: Identidades Digitales y Servicios — M365, correo, licencias
docs/ambito/dtic-GEMMA/	Ámbito A11: Agente IA de Gestión Diaria — Asistente Operativo
adn/tools/cli/dron.rb	Drones: tareas background con auto-bitácora — ./adn/tools/run dron

Última actualización: 2026-04-24 (A11 dtic-GEMMA creado: agente IA "número 2" para operativa diaria) Próxima revisión: Al inicio de cada sesión

---

🤖 Drones - Sistema Mejorado (2026-04-08)

Mejora implementada: Auto-detección de nodo y ámbito automático en bitácora.

Cambios realizados:

1. Auto-detección de nodo: El dron detecta automáticamente el nodo por hostname
2. Ámbito automático: El ámbito se hereda del nodo mediante JOIN en la consulta
3. Unificación de vistas: evento:listar muestra tanto events (drones) como entradas (tradicional)

Flujo de trabajo:

# Al iniciar sesión: verificar flota
./adn/tools/run dron salud
./adn/tools/run dron limpiar   # Si hay zombies

# Para tareas en background (auto-registra en bitácora)
./adn/tools/run dron lanzar --nota "Descripción de la tarea" -- <comando>

# Opcional: especificar nodo manualmente
./adn/tools/run dron lanzar --nodo srv-ns8 --nota "Tarea" -- <comando>

Importante: Los drones registran automáticamente en bitácora con el ámbito correcto. Para SSH interactivo, usar candados run.

---

🔐 Lecciones Aprendidas - DNS (2026-04-07)

Problema: Confusión inicial entre servidores DNS.

Descubrimiento:

• srvv-dns (190.114.205.18) = nombre interno del nodo donde trabajamos (srv-ns8)
• srvv-DNS (190.114.205.2) = servidor DNS PÚBLICO que responde a dns.frlr.utn.edu.ar y ns1.frlr.utn.edu.ar

Lección: Los registros DKIM deben estar en el servidor DNS que responde a las consultas públicas (190.114.205.2), no necesariamente donde se ejecuta la CLI.

Solución aplicada: Script copiado a srvv-DNS via SCP, ejecutado con sudo via candado srvv-DNS:rmonla:sudo.

Actualización 22:00 - Gmail marca spam aunque DKIM esté OK

Estado: DKIM habilitado en M365, registros responden correctamente, pero Gmail sigue marcando correos como spam.

Causas identificadas:

1. DMARC faltante - No hay registro _dmarc.frlr.utn.edu.ar
2. Reputación de dominio - Gmail requiere período de "calentamiento" (24-72 horas típico)
3. Historial del dominio - Correos anteriores sin autenticación afectan reputación inicial

Próximo paso: Agregar DMARC con p=none (solo monitoreo) para completar triada de autenticación.

---

🛠️ Optimización de candados (2026-04-08)

Contexto: La herramienta candados.rb es crítica para la seguridad del ecosistema. Se requiere que cualquier IA sepa usarla correctamente sin exponer contraseñas.

Cambios realizados:

1. Help resumida (default): Se muestra al ejecutar sin argumentos o con comando desconocido

   • Mensaje conciso con lo esencial
   • Los dos métodos para cargar variables (run y load)
   • Lista de comandos principales
   • Indica usar --help para más detalles

2. Help completa (--help o -h):

   • Explicación detallada de cada método
   • Ejemplos de uso
   • Flujo de trabajo típico
   • Advertencias de seguridad

3. README actualizado: Sincronizado con la ayuda integrada

Lección: La documentación integrada en la CLI es más efectiva que archivos externos. Cualquier IA que ejecute candados sin argumentos verá inmediatamente cómo usarla de forma segura.

Comando para verificar:

ruby adn/tools/candados/candados.rb        # Help resumida
ruby adn/tools/candados/candados.rb --help # Help completa

---

🛠️ Integración de Backups DASUTEN en BKPs (2026-04-14)

Contexto: Los drones de backup DASUTEN estaban implementados como scripts independientes pero no integrados en el ecosistema ADN de backups.

Problema: Existían dos "canales diferentes" que hacían lo mismo:

• ./adn/tools/run dasuten → herramientas específicas
• ./adn/tools/run bkps → sistema unificado de backups

Solución aplicada: Integrar DASUTEN como un tipo de procesador dentro de bkps.rb:

1. Nuevo procesador: adn/tools/bkps/lib/proc_dasuten.rb

   • Mapea tareas a drones atómicos existentes
   • Usa dron lanzar para ejecución con bitácora automática
   • Respeta principio "Menos es Más" (reutiliza, no duplica)

2. Tareas en bkps.yml: T8-T15 agregadas

   • dasuten_export_full / dasuten_export_dif
   • dasuten_transferir, dasuten_upload, dasuten_download
   • dasuten_restaurar_full / dasuten_restaurar_dif
   • dasuten_verificar

3. Comandos compuestos: C7 (full) y C8 (diferencial)

   • Pipeline completo: 6 pasos, ~35-40 min
   • Pipeline diferencial: 6 pasos, ~5-10 min

4. Documentación:

   • A04.P006_Backups-DASUTEN.md creado
   • A04_dtic-DASUTEN.md actualizado (plan agregado)
   • A03_dtic-BKPs.md actualizado (comandos agregados)

Comando resultante:

# Pipeline diferencial diario
./adn/tools/run bkps run dasuten_diferencial

# Pipeline completo semanal
./adn/tools/run bkps run dasuten_full

Lección: Cuando dos herramientas parecen hacer lo mismo, integrar una dentro de la otra siguiendo la arquitectura existente (BKPs como sistema unificado de backups).

---

🛠️ 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

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.

Diagnóstico:

• Tabla ARP mostraba MACs en bridge pero sin respuesta ICMP
• Tailscale reportaba "offline, last seen 1d ago"
• qemu-guest-agent no estaba corriendo dentro de las VMs

Causa probable: Windows Server Core iniciaba pero sin stack de red activo o servicios de red fallando.

Solución aplicada: Crear VM 105 (dasu-sql3) limpia con:

• ISO Windows Server 2022 Español (no Core evaluation)
• Discos SATA (no VirtIO que puede causar problemas)
• 60GB disco para SO + 120GB disco para datos SQL
• virtio drivers integrados

Nota técnica - LVM-thin:

• lvcreate -L crea volúmenes finos pero requiere espacio físico real
• lvcreate -V -T pool/thin crea volúmenes thin que solo usan espacio cuando se escriben
• Verificar con vgs y lvs -a para diagnosticar espacio
• Thin volumes pueden tener metadata más pequeña que el tamaño virtual