# 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:

```bash
# 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:**

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

**Ejemplos:**
```bash
# 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

```bash
# 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:**
```bash
# 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:**
```bash
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:**
```bash
# 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`](../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