9.2 KiB
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)
- Menos es Más: Este archivo contiene solo lo esencial para operar. Para detalles, consultar fuentes canónicas o usar
--helpen las herramientas ADN. - Mejora Continua: Al inicio de cada sesión, ejecutar
./adn/tools/run salud --mejoras --jsonpara identificar oportunidades de optimización. - 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
datepara 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:
-
Verificar si está registrado en bitácora
- Si no →
db evento:crearprimero - Si sí → continuar
- Si no →
-
Ejecutar la tarea
- Usar comandos
./adn/tools/run - Seguir principios de
adn/05_ia.md
- Usar comandos
-
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.mdcomo 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 21:55 (A07.P002: DKIM completado - srvv-DNS identificado correctamente) 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 adns.frlr.utn.edu.aryns1.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.