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)

---

📊 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

Cuándo aplicar: Después de cualquier cambio significativo (nueva herramienta, refactorización, cambio de estructura, plan completado, etc.).

Checklist obligatorio (en orden):

#	Documento	Qué actualizar	Cuándo
1	Bitácora	Evento con resultados y próximos pasos	Siempre (antes de salir)
2	docs/contexto/IA.md	Estado de drones, lecciones aprendidas, quick changes	Si hay cambios operativos o de flujo
3	docs/ambito/<ámbito>/<Axx>_manifiesto.md	Tabla de planes, herramientas, nodos, estado	Si el cambio afecta al ámbito
4	docs/ambito/<ámbito>/<Axx.Pxxx>_plan.md	Estado del plan, fases, hitos	Si el plan fue modificado/completado

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: Digitalización y Gestión Documental
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-DNS/	Ámbito A07: Administración DNS — ./adn/tools/run dns
adn/tools/cli/dron.rb	Vigía tareas largas — ./adn/tools/run dron

Última actualización: 2026-04-07 22:10 (A07.P002: Triada SPF+DKIM+DMARC completa - monitoreo reputación) Próxima revisión: Al inicio de cada sesión

---

🤖 Estado de Drones (Verificación 2026-04-06 13:17)

Flota: 2 drones detectados → ambos completados y limpiados

• dron_125106_654316 — Evento #1395: "Test diario de vuelo" (sleep 3) → ✔ Completado (0min)
• dron_125505_657901 — Evento #1398: "Test diario v2" (echo Hola...) → ✔ Completado

Diagnóstico: Drones operaron correctamente pero quedaron como "zombies" (PID muerto, estado=vigilando). El health check (dron salud) los auto-reparó y dron limpiar los removió.

Lección: El sistema de auto-reparación funciona. Verificar flota al inicio de sesión con ./adn/tools/run dron salud.

---

🔐 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.