docs: Plan P2603.01 Automatización Zoom y actualizaciones P2601.09
This commit is contained in:
Ricardo Monla
+1
-1
@@ -3,7 +3,7 @@
|
||||
**Fecha:** 17 de marzo de 2026
|
||||
**Autor:** Sistema ADN
|
||||
**Versión:** 1.0
|
||||
**Ubicación:** `docs/proy/P2604_Mejoras-ADN/plan/P2604.01.01_Estandarizacion-Ayudas-ADN.md`
|
||||
**Ubicación:** `docs/ambito/dtic-ADN/plan/P2604.01.01_Estandarizacion-Ayudas-ADN.md`
|
||||
**Estado:** ⏳ En Ejecución
|
||||
|
||||
## 📋 Resumen Ejecutivo
|
||||
+1
-1
@@ -3,7 +3,7 @@
|
||||
**Fecha:** 17 de marzo de 2026
|
||||
**Autor:** Antigravity (IA ADN)
|
||||
**Estado:** ✅ Completado
|
||||
**Proyecto Padre:** [P2604 - Mejoras ADN](../P2604_Mejoras-ADN.md)
|
||||
**Proyecto Padre:** [P2604 - Mejoras ADN](P2604_Mejoras-ADN.md)
|
||||
|
||||
## 📋 Objetivo
|
||||
Automatizar la creación de estructuras de proyectos (planes, hitos, tareas) en el ecosistema ADN para garantizar consistencia en la nomenclatura y ubicación de los archivos en `docs/proy/`.
|
||||
+1
-1
@@ -3,7 +3,7 @@
|
||||
> Proyecto: P2604 - Mejoras ADN | Estado: ⏳ Planificación
|
||||
|
||||
## Contexto
|
||||
Se requiere reemplazar la herramienta legacy `adn/tools/sonda_w-zombi` por la nueva versión modular v2.0 (ubicada en `docs/proy/P2604_Mejoras-ADN/w-zombi/w-zombi_v2.0`). Para mantener un ecosistema higiénico y evitar monolitos indeseados, se optó por un enfoque de **"borrón y cuenta nueva"**.
|
||||
Se requiere reemplazar la herramienta legacy `adn/tools/sonda_w-zombi` por la nueva versión modular v2.0 (ubicada en `docs/ambito/dtic-ADN/w-zombi/w-zombi_v2.0`). Para mantener un ecosistema higiénico y evitar monolitos indeseados, se optó por un enfoque de **"borrón y cuenta nueva"**.
|
||||
|
||||
## Objetivos
|
||||
1. **Archivado Histórico**: Mover la antigua sonda a `adn/tools/_hist/sonda_w-zombi` preservando su estado.
|
||||
+1
-1
@@ -60,7 +60,7 @@ TOTAL: ██████████ 100% PLAN COMPLETO ✅
|
||||
|
||||
## Registro de Implementación (19/03 - 22:50)
|
||||
- Plan creado: P2604.07
|
||||
- Proyecto: P2604_Mejoras-ADN
|
||||
- Ámbito: dtic-ADN
|
||||
|
||||
## Registro de Corrección (19/03 - 21:30)
|
||||
- [x] Bugfix: Formato de hora en `db evento:listar` ahora muestra `HH:MM:SS`
|
||||
+17
@@ -210,6 +210,21 @@ Mejoras atómicas, incrementales y reutilizables al ecosistema ADN. Una herramie
|
||||
| A4 | Frontend: AmbitoDashboard con selector de ámbito | ✅ |
|
||||
| A5 | Documentación: hebras ADN actualizadas | ✅ |
|
||||
|
||||
### Fase 17: Optimización Hardware srv-ns8
|
||||
|
||||
| ID | Mejora | Estado |
|
||||
| :--- | :--- | :--- |
|
||||
| H1 | Aumentar RAM de srv-ns8 (mínimo 32 GB para Ollama) | ⏳ |
|
||||
| H2 | Evaluar SSD para mejorar rendimiento | ⏳ |
|
||||
|
||||
### Fase 18: Integración Ollama (LLM Local)
|
||||
|
||||
| ID | Mejora | Estado |
|
||||
| :--- | :--- | :--- |
|
||||
| O1 | Instalar modelo LLM liviano (1-3B params) | ⏳ |
|
||||
| O2 | Integrar Ollama como backend de IA en herramientas ADN | ⏳ |
|
||||
| O3 | Capacidad de análisis de código/documentos via LLM local | ⏳ |
|
||||
|
||||
---
|
||||
|
||||
## Progreso
|
||||
@@ -231,6 +246,8 @@ Fase 13: ██████████ 100% W-ZOMBI v2.0
|
||||
Fase 14: ██████████ 100% Visibilidad
|
||||
Fase 15: ██████████ 100% Optimización IA
|
||||
Fase 16: ██████████ 100% Ámbito/Nodo
|
||||
Fase 17: ░░░░░░░░░░ 0% Hardware srv-ns8
|
||||
Fase 18: ░░░░░░░░░░ 0% Ollama (LLM Local)
|
||||
```
|
||||
|
||||
## Métricas Totales
|
||||
+2
-2
@@ -1,4 +1,4 @@
|
||||
# P2605 - Migración a Bitácoras Web
|
||||
# Plan: Migración a Bitácoras Web (DB-First)
|
||||
|
||||
> Manifiesto de Proyecto | Referencia: [`adn/07_proyectos.md`](../../../adn/07_proyectos.md)
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
| Campo | Valor |
|
||||
| :--- | :--- |
|
||||
| **Código** | P2605 |
|
||||
| **Código** | P2603.00 |
|
||||
| **Nombre** | Migración a Bitácoras Web (DB-First) |
|
||||
| **Estado** | ✅ Completado |
|
||||
| **Inicio** | 05/03/2026 |
|
||||
@@ -0,0 +1,82 @@
|
||||
# Plan: Refactorización UI Bitácoras - Armonía Integral
|
||||
|
||||
> **Grupo de Trabajo:** dtic-BITACORAS
|
||||
|
||||
**Código:** P2603.01
|
||||
**Fecha:** 30 de marzo de 2026
|
||||
**Autor:** Sistema ADN
|
||||
**Versión:** 1.0
|
||||
**Estado:** ✅ COMPLETADO
|
||||
|
||||
## 📋 Resumen Ejecutivo
|
||||
|
||||
Alinear el comportamiento del Frontend de Bitácoras Web con el principio de **Armonía Integral** del ecosistema ADN. El objetivo consiste en garantizar que la interfaz gráfica represente con absoluta fidelidad la topología relacional de la base de datos, desvinculando la agrupación visual de eventos de la pertenencia física de su nodo, orientándola en su lugar a nivel de **cada entrada y su respectivo ámbito operativo (`ambito_id`)**.
|
||||
|
||||
### Motivación
|
||||
|
||||
Previo a esta actualización, la interfaz de usuario en la vista de "Día Completo" (`/bitacoras/:fecha/completa`) agrupaba inherentemente las entradas bajo el `ambito_nombre` asociado al *Nodo* que las emitía (ej: `dtic-DIIAA` para el nodo 37 `srv-ns8`). Esto causaba distorsiones visuales severas: eventos declarados explícitamente para `dtic-DASUTEN` o `dtic-ADN` aparecían bajo la pestaña lila de `dtic-DIIAA` simplemente porque fueron ejecutados desde un servidor de infraestructura.
|
||||
El principio de Armonía Integral requiere que la representación sea fiel al dominio lógico de la tarea y no a la contingencia física del hardware subyacente.
|
||||
|
||||
### Decisiones Clave
|
||||
|
||||
- **Desacoplamiento Topológico**: Modificar `App.tsx` para que itere sobre `nodoGroup.entradas` y extraiga el ámbito propio de cada evento, anulando la agrupación genérica por nodo.
|
||||
- **Sincronización Transversal**: Actualizar masivamente las entradas huérfanas o desactualizadas en PostgreSQL para vincularlas a sus ámbitos verdaderos en la tabla `bitacoras.ambitos`.
|
||||
- **Registro del Ámbito Autónomo `dtic-ADN`**: Incorporar oficialmente el ecosistema interno ADN como un ámbito de primer nivel en la base de datos para cobijar sus propios eventos de scripting (P2604).
|
||||
|
||||
## 🌐 Arquitectura de Sincronización
|
||||
|
||||
```
|
||||
Base de Datos (PostgreSQL)
|
||||
│
|
||||
├── bitacoras.ambitos (1:DIIAA, 2:DASUTEN, 7:ADN)
|
||||
│
|
||||
└── bitacoras.entradas (FK ambito_id -> ambitos.id)
|
||||
│
|
||||
API (Node.js/Express)
|
||||
│
|
||||
Frontend (React/Vite)
|
||||
└── App.tsx (Itera e.ambito_nombre -> Agrupa -> Renderiza Card)
|
||||
```
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Implementar, desplegar y validar la reestructuración del backend y frontend para que los Eventos se muestren categorizados bajo el Scope exacto (Ámbito) para el que fueron planificados, independientemente del nodo físico desde el cual se registró la actividad.
|
||||
|
||||
## 📅 Fases de Implementación
|
||||
|
||||
### ✅ **FASE 1: Sincronización Estructural (Base de Datos)**
|
||||
|
||||
- [x] **1.1:** Auditar inconsistencias entre `doc_path` (ej. `ambito/dtic-DASUTEN/P...`) y el campo relacional `ambito_id`.
|
||||
- [x] **1.2:** Crear oficialmente el registro para el ámbito matricial `dtic-ADN` en la tabla `bitacoras.ambitos` (Obtuvo ID: 7).
|
||||
- [x] **1.3:** Ejecutar parche SQL de actualización masiva:
|
||||
- 17 entradas actualizadas a `ambito_id = 2` (dtic-DASUTEN).
|
||||
- 2 entradas actualizadas a `ambito_id = 7` (dtic-ADN).
|
||||
- [x] **1.4:** Verificar consistencia de la respuesta JSON en el endpoint de la API (`/api/entradas/1341` confirmando `"ambito_id":2`).
|
||||
|
||||
### ✅ **FASE 2: Refactorización Lógica (Frontend)**
|
||||
|
||||
- [x] **2.1:** Analizar el método de agrupación en `frontend/src/App.tsx`.
|
||||
- [x] **2.2:** Detectar el fallo de diseño (se utilizaba `nodoGroup.ambito_nombre` ignorando `e.ambito_nombre`).
|
||||
- [x] **2.3:** Reescribir el algoritmo de `porAmbito` para que genere subgrupos (Cards/Badges) iterando a nivel de entrada individualmente.
|
||||
- [x] **2.4:** Resolver conflictos de tipado de TypeScript definiendo propiedades opcionales (`ambito_nombre`, `nodo_nombre`) en la interfaz `Entrada`. *(A ser completado en refactor de tipos global si persiste)*.
|
||||
- [x] **2.5:** Aprovechar HMR (Hot Module Replacement) de Vite para aplicar el cambio en vivo.
|
||||
|
||||
### ✅ **FASE 3: Validación End-to-End**
|
||||
|
||||
- [x] **3.1:** Consultar la URL local (`http://localhost:5174/bitacoras/`) para verificar que el evento 1341 (Instalación DASU-PCV2) aparece correctamente bajo la pestaña de `dtic-DASUTEN`.
|
||||
- [x] **3.2:** Confirmar que otros eventos del core de scripts aparecen bajo `dtic-ADN`.
|
||||
- [x] **3.3:** Documentar la culminación de la reforma en el Master Plan [P2603_bitacoras.md](P2603_bitacoras.md) bajo el Hito **UI02**.
|
||||
|
||||
## 📊 Impacto Operativo
|
||||
|
||||
| Aspecto | Antes (Agrupación por Nodo) | Después (Armonía Integral) |
|
||||
|---------|-------------------------|--------------------------|
|
||||
| **Fidelidad Estructural** | ❌ Engañosa | ✅ Exacta |
|
||||
| **Monitoreo de Nodos** | La cabecera era el nodo dominante | El nodo es un metadato tabular por cada fila |
|
||||
| **Identificación Visual** | Los proyectos de DASUTEN se ocultaban en DIIAA | Cada ámbito destaca independientemente |
|
||||
|
||||
## 🔗 Referencias
|
||||
|
||||
- **Proyecto padre**: [P2603_bitacoras.md](P2603_bitacoras.md)
|
||||
- **Principio Rector**: [IA.md](../../contexto/IA.md) (Sección 3: Armonía Integral)
|
||||
- **Ontología**: [01_ontologia.md](../../../adn/01_ontologia.md)
|
||||
+2
-2
@@ -1,4 +1,4 @@
|
||||
# P2604.06.06 - Plan: Acceso Remoto a Bitácora Web
|
||||
# P2603.02 - Plan: Acceso Remoto a Bitácora Web
|
||||
|
||||
## Objetivo
|
||||
Acceder a la bitácora web (`dtic-BITACORAs`) desde equipos remotos sin configuraciones complicadas.
|
||||
@@ -101,7 +101,7 @@ Vite: ██████████ 100% allowedHosts configurado
|
||||
- [x] Verificados puertos y servicios activos
|
||||
- [x] Confirmado acceso via nginx proxy funciona
|
||||
- [x] Documentadas URLs de acceso remoto
|
||||
- [x] Creado plan P2604.06.06
|
||||
- [x] Creado plan P2603.02
|
||||
- [x] IP Tailscale actualizada: 100.88.252.26 → 100.111.195.4
|
||||
- [x] Agregado `srv-ns8` a nginx server_names
|
||||
- [x] Configurado Vite allowedHosts con todos los hosts Tailscale
|
||||
+2
-2
@@ -1,6 +1,6 @@
|
||||
# Plan P2604.09: Referencia Dinámica a Planes desde Bitácora Web
|
||||
# Plan P2603.03: Referencia Dinámica a Planes desde Bitácora Web
|
||||
|
||||
**Proyecto**: P2604 — Mejoras ADN
|
||||
**Proyecto**: P2603 — Sistema de Bitácoras Web
|
||||
**Estado**: ✅ Completado
|
||||
**Fecha**: 2026-03-27
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
# P2604.06.05 - Plan: Herencia Automática de Modo de Jornada
|
||||
# P2603.04 - Plan: Herencia Automática de Modo de Jornada
|
||||
|
||||
## Objetivo
|
||||
Eliminar la fricción de especificar manualmente el modo (`[P]`, `[R]`, `[S]`) en cada evento. El modo se define una sola vez al iniciar la jornada y se hereda automáticamente.
|
||||
+11
-6
@@ -63,12 +63,17 @@ Fase 5: ░░░░░░░░░░ 0% Integración CLI ADN
|
||||
|
||||
| Fecha | ID | Estado | Hito |
|
||||
| :--- | :--- | :---: | :--- |
|
||||
| 03/03 | INIT | ⏳ | Inicialización del proyecto. Creación de `dtic-BITACORAs/` con esquema DB y APIs. |
|
||||
| — | UI01 | 📍 | Frontend: Vista de bitácora diaria con entradas I-F-D-E agrupadas por nodo. |
|
||||
| — | API01 | 📍 | Backend: CRUD completo de entradas, nodos y bitácoras. |
|
||||
| — | EXP01 | 📍 | Exportador a Markdown compatible con el ADN. |
|
||||
| — | PROD | 📍 | Despliegue en producción (srv-ns8, Nginx reverse proxy). |
|
||||
| 07/03 | ADN01 | 📍 | Automatización Ruby del ADN: Implementación de herramientas CLI unificadas para validación, generación y contexto (Plan 260307-1400). |
|
||||
| 03/03 | INIT | ✅ | Inicialización del proyecto. Creación de `dtic-BITACORAs/` con esquema DB y APIs. |
|
||||
| 12/03 | MIG | ✅ | Transición operativa a DB-First ([Ver P2603.00](P2603.00_Migracion-DB-First.md)). |
|
||||
| — | UI01 | ✅ | Frontend: Vista de bitácora diaria con entradas I-F-D-E agrupadas por nodo. |
|
||||
| — | API01 | ✅ | Backend: CRUD completo de entradas, nodos y bitácoras. |
|
||||
| — | EXP01 | ✅ | Exportador a Markdown compatible con el ADN. |
|
||||
| — | PROD | ⏳ | Despliegue en producción (srv-ns8, Nginx reverse proxy). |
|
||||
| 07/03 | ADN01 | ✅ | Automatización Ruby del ADN: Implementación de CLI unificadas. |
|
||||
| 19/03 | REM1 | ✅ | Acceso proxy remoto NGINX, Vite y Tailscale ([P2603.02](P2603.02_Acceso-Remoto-Bitacora-Web.md)). |
|
||||
| 19/03 | JRND | ✅ | Autonomización: Herencia automática de Modo de Jornada ([P2603.04](P2603.04_Herencia-Modo-Jornada.md)). |
|
||||
| 27/03 | DOC1 | ✅ | Visor de planes integrados y referenciación dinámica Markdown (`doc_path`) ([P2603.03](P2603.03_Referencia-Planes-Bitacora.md)). |
|
||||
| 30/03 | UI02 | ✅ | Refactor Ámbitos ([Armonía Integral](P2603.01_Armonia-Integral-Bitacoras.md)): Agrupación granular y renderizado fiel de base de datos. |
|
||||
|
||||
## Arquitectura
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@
|
||||
**Fecha:** 11 de marzo de 2026
|
||||
**Autor:** Sistema ADN
|
||||
**Versión:** 1.0
|
||||
**Ubicación:** `docs/proy/P2601_Dasuten/plan/P2601.06.01_Red-SrvDasu.md`
|
||||
**Ubicación:** `docs/ambito/dtic-DASUTEN/plan/P2601.06.01_Red-SrvDasu.md`
|
||||
**Estado:** ✅ COMPLETADO
|
||||
|
||||
## 📋 Resumen Ejecutivo
|
||||
+2
-2
@@ -1,4 +1,4 @@
|
||||
# Plan: Unión de pc-dasu0 al Dominio DASUTeN (P2601 Fase 6.1.B)
|
||||
# Plan: Unión de pc-dasu0 al Dominio DASUTEN (P2601 Fase 6.1.B)
|
||||
|
||||
**Fecha:** 11 de marzo de 2026 (Actualizado: 16/03/2026)
|
||||
**Autor:** Sistema ADN
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
## 📋 Resumen Ejecutivo
|
||||
|
||||
Unir la PC física `pc-dasu0` (oficina DASUTeN) al dominio `dasuten.utnlr`. La infraestructura de soporte (DC, SQL, red) ya está operativa y validada con la VM de pruebas.
|
||||
Unir la PC física `pc-dasu0` (oficina DASUTEN) al dominio `dasuten.utnlr`. La infraestructura de soporte (DC, SQL, red) ya está operativa y validada con la VM de pruebas.
|
||||
|
||||
> **Fase 0 en curso:** Normalización de nombres de nodos para convención unificada.
|
||||
|
||||
+25
-15
@@ -1,10 +1,12 @@
|
||||
# Plan: DASUTEN sin Domain Controller (Modo Workgroup)
|
||||
|
||||
> **Grupo de Trabajo:** DASUTEN
|
||||
|
||||
**Código:** P2601.09
|
||||
**Fecha:** 27 de marzo de 2026
|
||||
**Autor:** Sistema ADN
|
||||
**Versión:** 2.2
|
||||
**Estado:** 🚧 EN EJECUCIÓN (Fase 2 en progreso — VM 103 creada, pendiente instalación OS)
|
||||
**Estado:** 🚧 EN EJECUCIÓN (Fase 2 completada, Fase 3 pendiente — Creación VM PC Cliente)
|
||||
|
||||
## 📋 Resumen Ejecutivo
|
||||
|
||||
@@ -12,7 +14,7 @@ Evaluar si el sistema DASUTEN puede operar **sin la dependencia de un Domain Con
|
||||
|
||||
### Motivación
|
||||
|
||||
Los intentos previos (P2601.06 a P2601.08) demostraron que la topología con DC introduce complejidad de red que entra en conflicto con el router del ISP de la oficina DASUTeN. Al eliminar la dependencia del DC, se reducen los puntos de falla y se simplifica la conectividad.
|
||||
Los intentos previos (P2601.06 a P2601.08) demostraron que la topología con DC introduce complejidad de red que entra en conflicto con el router del ISP de la oficina DASUTEN. Al eliminar la dependencia del DC, se reducen los puntos de falla y se simplifica la conectividad.
|
||||
|
||||
### Decisiones clave
|
||||
|
||||
@@ -28,8 +30,8 @@ Internet
|
||||
Router ISP (192.168.1.1 — gateway confirmado)
|
||||
│
|
||||
├── srv-dasu → DHCP del ISP: 192.168.1.13 (vmbr0 bridge sobre enp33s0)
|
||||
│ ├── dasu-sql2 (VM 103) → DHCP del ISP (bridge vmbr0) ✅ VM creada
|
||||
│ └── dasu-pcv2 (VM 104) → DHCP del ISP (bridge vmbr0)
|
||||
│ ├── dasu-sql2 (VM 103) → DHCP del ISP: 192.168.1.14 ✅ VM creada
|
||||
│ └── dasu-pcv2 (VM 104) → DHCP del ISP: 192.168.1.15 ✅ VM creada
|
||||
│
|
||||
└── dasu-pc → DHCP del ISP (PC física cliente)
|
||||
```
|
||||
@@ -59,29 +61,30 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
|
||||
- [x] **2.1:** Crear VM 103 en Proxmox ✅ (4 GB RAM, 2 vCPU, 60 GB disco SATA, vmbr0, SeaBIOS, i440fx). MAC: `BC:24:11:8D:EC:46`.
|
||||
- [x] **2.2:** Instalar Windows Server 2022 Core ✅. Instalado vía consola noVNC. Drivers VirtIO instalados vía `pnputil /add-driver D:\*.inf /subdirs /install`. Red operativa (DHCP ISP). Credencial Admin guardada en candados (`dasu-sql2:Administrator`). Backup vzdump realizado (modo stop, zstd, 3.28 GB).
|
||||
- [x] **2.3:** Configurar red: DHCP del ISP ✅. IP asignada: `192.168.1.19/24`, gateway `192.168.1.1`.
|
||||
- [x] **2.3:** Configurar red: DHCP del ISP ✅. IP actual asignada: `192.168.1.14/24`, gateway `192.168.1.1`.
|
||||
- [x] **2.4:** Configurar hostname (`dasu-sql2`) ✅ y modo Workgroup (WORKGROUP).
|
||||
- [x] **2.5:** Instalar y habilitar OpenSSH Server (puerto 7022) ✅. Shell por defecto: PowerShell.
|
||||
- [x] **2.6:** Instalar Tailscale VPN ✅. Cuenta `pcdasu0@frlr.utn.edu.ar`. IP Tailscale: `100.126.182.123`. ⚠️ Inestable: se desconecta al renombrar hostname, requiere `tailscale up --force-reauth`.
|
||||
- [x] **2.7:** Instalar SQL Server 2019 ✅. Servicio MSSQLSERVER Running/Automatic. Instalado vía w-zombi relay LAN (socat srv-dasu:8001 → SSH tunnel → local:8000). Locale cambiado a es-ES para compatibilidad con ISO española.
|
||||
- [x] **2.6:** Instalar Tailscale VPN ✅. Cuenta `pcdasu0@frlr.utn.edu.ar`. IP Tailscale: (Pendiente login). ⚠️ Server Core interfiere con el popup GUI en la instalación normal, requiere comando CLI manual para URL interactiva.
|
||||
- [x] **2.7:** Instalar SQL Server 2019 ✅. Instalado vía bypass del relay w-zombi (limitación por encoding base64 de W-ZOMBI y escapes booleanos de PowerShell estricto en Server Core). Locale cambiado a es-ES.
|
||||
- [x] **2.8:** Configurar autenticación mixta SQL ✅. LoginMode=2 (registro), SA habilitado con password, firewall TCP 1433 abierto. Login SA verificado con `sqlcmd`.
|
||||
- [x] **2.9:** Verificar conectividad SQL ✅. TCP 1433 accesible desde srv-dasu (192.168.1.13) a dasu-sql2 (192.168.1.19). Login SA verificado localmente.
|
||||
|
||||
### ⏳ **FASE 3: Creación de VM PC Cliente (sin dominio)**
|
||||
|
||||
- [ ] **3.1:** Crear VM 104 en Proxmox (4 GB RAM, 2 vCPU, 50 GB disco SATA, vmbr0, SeaBIOS, i440fx).
|
||||
- [ ] **3.2:** Instalar Windows 10 LTSC.
|
||||
- [ ] **3.3:** Configurar red: **DHCP del ISP** (gateway del ISP). Anotar IP asignada.
|
||||
- [ ] **3.4:** Configurar hostname (`dasu-pcv2`) y modo Workgroup.
|
||||
- [ ] **3.5:** Instalar OpenSSH Server (puerto 7022).
|
||||
- [ ] **3.6:** Instalar Tailscale VPN (cuenta `pcdasu0@frlr.utn.edu.ar`). Anotar IP Tailscale asignada.
|
||||
- [x] **3.1:** Crear VM 104 en Proxmox (4 GB RAM, 2 vCPU, 50 GB disco SATA, vmbr0, SeaBIOS, i440fx) ✅. Instalador de Win 10 LTS montado en IDE2, VirtIO en IDE0. Red: e1000.
|
||||
- [x] **3.2:** Instalar Windows 10 LTSC ✅.
|
||||
- [x] **3.3:** Configurar red: **DHCP del ISP** (gateway del ISP). Anotar IP asignada. ✅ IP: `192.168.1.15`.
|
||||
- [x] **3.4:** Configurar hostname (`dasu-pcv2`) y modo Workgroup ✅.
|
||||
- [x] **3.5:** Instalar OpenSSH Server (puerto 7022) ✅ Instalado silente vía QEMU Guest Agent.
|
||||
- [x] **3.6:** Instalar Tailscale VPN (cuenta `pcdasu0@frlr.utn.edu.ar`). Anotar IP Tailscale asignada. ✅ **IP: 100.98.225.100**
|
||||
- [ ] **3.7:** Instalar herramientas cliente SQL (SSMS o sqlcmd) si es necesario.
|
||||
- [ ] **3.8:** Verificar conectividad hacia dasu-sql2 (ping + test TCP 1433).
|
||||
- [x] **3.9:** Instalar qemu-guest-agent en VM dasu-pcv2 para backups desatendidos (ACPI shutdown) ✅.
|
||||
|
||||
### ⏳ **FASE 4: Instalación del Sistema DASUTEN**
|
||||
|
||||
- [ ] **4.1:** Obtener backup/script de la base de datos DASUTEN del sistema actual.
|
||||
- [ ] **4.2:** Restaurar/crear la base de datos DASUTEN en dasu-sql2.
|
||||
- [x] **4.1:** Obtener backup/script de la base de datos DASUTEN del sistema actual. ✅ (Descargado localmente archivo de 604MB y confirmado acceso vía SMB al crudo `.bak`)
|
||||
- [x] **4.2:** Restaurar/crear la base de datos DASUTEN en dasu-sql2. ✅ **Automatización implementada**: Creada la extensión nativa ADN `adn/tools/run dasuten db:migrar` (Ruby) que realiza la descarga SMB, extracción y restauración vía SQLCMD de manera eficiente, segura y reutilizable, eliminando el uso de scripts temporales de shell.
|
||||
- [ ] **4.3:** Instalar la aplicación cliente DASUTEN en dasu-pcv2.
|
||||
- [ ] **4.4:** Configurar la conexión de la aplicación al SQL Server usando autenticación SQL (no Windows Integrated).
|
||||
- [ ] **4.5:** Verificar que la aplicación conecta y opera correctamente.
|
||||
@@ -129,6 +132,13 @@ Crear dos VMs nuevas (SQL Server + PC cliente) en `srv-dasu`, instalar el sistem
|
||||
| **Bridge vmbr0** | ✅ DHCP ISP sobre `enp33s0` — IP: `192.168.1.13/24` |
|
||||
| **Gateway** | `192.168.1.1` (router ISP confirmado) |
|
||||
|
||||
## 8. Lecciones Aprendidas y Troubleshooting
|
||||
- **`New-NetFirewallRule -Enabled` en entornos PS puros:** Al inyectar comandos de PowerShell a Server Core de forma automatizada (WS2022), debe pasarse el string `'True'` y no la variable booleana `$True`, ya que la Cmdletization falla la conversión estricta al vuelo.
|
||||
- **Escape JSON en W-ZOMBI de PowerShell:** Grandes scripts en línea que se parsean a través de `cmd.json` destrozan la interpretación si hay fallas en la conexión. Para Server Core sin GUI, fue más seguro bypassear W-ZOMBI subiendo el PowerShell directo sobre un HTTP en Python temporal (`/tmp/s.ps1`).
|
||||
- **QEMU-GA y Nombres de Unidad Aleatorios:** En entornos con múltiples CDs montados (OS + Drivers VirtIO + CD Extra), Windows Server asigna letras impredecibles (no siempre `D:`). El path del Agent MSI debe resolverse programáticamente usando `Get-WmiObject Win32_CDROMDrive`.
|
||||
- **Usuario Administrador localizado:** Al instalar Server Core desde la ISO `es-es`, el administrador por defecto se renombra literalmente a `Administrador` en español. Esto es crítico porque intentos de conexión desatendida vía SSH con `sshpass` o secuencias usando `Administrator` devolverán "Permission denied", ocultando que el servidor SSH en realidad sí estaba escuchando en el puerto.
|
||||
- **Compresión Nativa de BACKUP SQL vs RAR:** Actualmente el sistema de origen encapsula los `.bak` dentro de un `.rar` gigante (ej. `bksysdasuten.rar`). SQL Server **no sabe** leer `.rar` ni ZIP nativamente para operaciones RESTORE DATABASE. Ya que Linux tiene herramientas como `unar` que facilitan la extracción en RAM, es factible este paso intermedio. Sin embargo, **la solución definitiva y óptima ("menos es más")** para el origen de datos es generar el archivo `.bak` instruyendo a SQL Server que lo comprima nativamente con la opción `WITH COMPRESSION`. Un `.bak` comprimido es un 80% más pequeño, y SQL Server destino lo levanta sin pasos intermedios de extracción, evitando problemas de almacenamiento temporal e I/O innecesarios en el nodo de linux (`srv-dasu`) al copiar el archivo directo al Windows (`dasu-sql2`).
|
||||
|
||||
## 🔗 Referencias
|
||||
|
||||
- **Proyecto padre**: [P2601_dasuten.md](P2601_dasuten.md)
|
||||
+4
-4
@@ -14,12 +14,12 @@
|
||||
|
||||
## Objetivo
|
||||
|
||||
**DASUTeN** (Departamento de Acción Social Universitaria Tecnológica Nacional) es la obra social de empleados, docentes y alumnos de la Universidad Tecnológica Nacional. Si bien cuenta con una oficina en la Facultad Regional La Rioja, depende directamente de su **sede central en el Rectorado (Buenos Aires)**.
|
||||
**DASUTEN** (Departamento de Acción Social Universitaria Tecnológica Nacional) es la obra social de empleados, docentes y alumnos de la Universidad Tecnológica Nacional. Si bien cuenta con una oficina en la Facultad Regional La Rioja, depende directamente de su **sede central en el Rectorado (Buenos Aires)**.
|
||||
|
||||
Actualmente, el sistema de gestión administrativa de DASUTeN funciona dentro de los servidores de la Facultad. El objetivo de este proyecto es **migrar el sistema a un servidor independiente** (`srv-dasu`) aislado de la red académica, de modo que:
|
||||
Actualmente, el sistema de gestión administrativa de DASUTEN funciona dentro de los servidores de la Facultad. El objetivo de este proyecto es **migrar el sistema a un servidor independiente** (`srv-dasu`) isolated de la red académica, de modo que:
|
||||
|
||||
1. La **PC física de la oficina** (`dasu-pc`) consuma el sistema directamente desde el nuevo servidor.
|
||||
2. La infraestructura quede **autocontenida** dentro de la oficina DASUTeN: una PC cliente + un servidor con sus VMs (DC, SQL, y a futuro posibles servicios adicionales).
|
||||
2. La infraestructura quede **autocontenida** dentro de la oficina DASUTEN: una PC cliente + un servidor con sus VMs (DC, SQL, y a futuro posibles servicios adicionales).
|
||||
3. Se logre **independencia operativa** respecto a los servidores de la Facultad, facilitando la gestión desde Rectorado si fuera necesario.
|
||||
|
||||
## Stakeholders
|
||||
@@ -43,7 +43,7 @@ Actualmente, el sistema de gestión administrativa de DASUTeN funciona dentro de
|
||||
| [**dasu-srvv-dc**](../../../nodos/dasu-srvv-dc.md) (VM 100) | `10.0.100.10` | Controlador de Dominio AD DS + DNS |
|
||||
| [**dasu-srvv-sql**](../../../nodos/dasu-srvv-sql.md) (VM 101) | `10.0.100.11` | Motor SQL Server 2019 (Core) |
|
||||
| **dasu-pcv** (VM 102) | `10.0.100.12` | VM de pruebas (Win 10 LTSC) |
|
||||
| [**dasu-pc**](../../../nodos/dasu-pc.md) | Oficina DASUTeN | PC física cliente (Plan A: SSH, Plan B: W-ZOMBI) |
|
||||
| [**dasu-pc**](../../../nodos/dasu-pc.md) | Oficina DASUTEN | PC física cliente (Plan A: SSH, Plan B: W-ZOMBI) |
|
||||
|
||||
### Nodos de Soporte e Infraestructura
|
||||
| Nodo | IP | Rol en el Proyecto |
|
||||
+2
-2
@@ -9,7 +9,7 @@ Esto implica el traslado físico del equipamiento, la adhesión de las estacione
|
||||
## Tareas a Realizar
|
||||
|
||||
### 1. Instalación Física (Hardware)
|
||||
* **Servidor Proxmox (`srv-dasu`)**: Trasladar el host físico a la oficina de DASUTeN e instalarlo en su locación definitiva (gabinete/rack), asegurando energía ininterrumpida (UPS) y conectividad de red adecuada.
|
||||
* **Servidor Proxmox (`srv-dasu`)**: Trasladar el host físico a la oficina de DASUTEN e instalarlo en su locación definitiva (gabinete/rack), asegurando energía ininterrumpida (UPS) y conectividad de red adecuada.
|
||||
* **Estaciones de Trabajo (`pc-dasu0` y otras si las hay)**: Reconectar y asegurar la conectividad L2 (física/switch) hacia el puerto de red que ofrece acceso al servidor `srv-dasu`.
|
||||
|
||||
### 2. Integración de Red y Dominio
|
||||
@@ -18,7 +18,7 @@ Esto implica el traslado físico del equipamiento, la adhesión de las estacione
|
||||
* **Reasignación de Usuarios**: Mapear/Migrar los perfiles y datos del usuario local que usaba Andrea Almirón hacia su nueva cuenta de dominio.
|
||||
|
||||
### 3. Seguridad y GPOs (Group Policy Objects)
|
||||
* **Restricción de Acceso**: Configurar GPOs para prohibir la instalación de software no autorizado por los usuarios estándar de DASUTeN.
|
||||
* **Restricción de Acceso**: Configurar GPOs para prohibir la instalación de software no autorizado por los usuarios estándar de DASUTEN.
|
||||
* **Unidades de Red**: Despliegue automático de mapeos de red necesarios (si la aplicación requiere una letra de unidad específica o para almacenamiento compartido) mediante GPO.
|
||||
* **Restricciones de Explorador**: Ocultar u restringir acceso a la unidad C:\ y recursos sensibles.
|
||||
* **Políticas de Contraseñas**: Asegurar rotación o longitud mínima para los usuarios del dominio.
|
||||
+3
-3
@@ -3,7 +3,7 @@
|
||||
## 1. Identificación y Objetivo
|
||||
- **ID**: `PROC-2601-6.1.B`
|
||||
- **Responsable**: Administrador de Infraestructura / Usuario Autorizado
|
||||
- **Objetivo**: Establecer comunicación de red directa local entre `srv-dasu` (hypervisor Proxmox) y `pc-dasu0` (PC física) cuando ambos dispositivos comparten el mismo router ISP en la oficina DASUTeN, optimizando el rendimiento y reduciendo la dependencia de Tailscale para operaciones locales.
|
||||
- **Objetivo**: Establecer comunicación de red directa local entre `srv-dasu` (hypervisor Proxmox) y `pc-dasu0` (PC física) cuando ambos dispositivos comparten el mismo router ISP en la oficina DASUTEN, optimizando el rendimiento y reduciendo la dependencia de Tailscale para operaciones locales.
|
||||
- **Frecuencia**: Manual / Bajo Demanda (cuando ambos dispositivos están en la misma red física)
|
||||
|
||||
## 2. Alcance y Prerrequisitos
|
||||
@@ -15,7 +15,7 @@
|
||||
- **Prerrequisitos**:
|
||||
- [ ] Acceso SSH a `srv-dasu` con privilegios sudo
|
||||
- [ ] Acceso administrativo a `pc-dasu0` (local o remoto)
|
||||
- [ ] Ambos dispositivos conectados al mismo router ISP en oficina DASUTeN
|
||||
- [ ] Ambos dispositivos conectados al mismo router ISP en oficina DASUTEN
|
||||
- [ ] Tailscale operativo en ambos dispositivos (para failover)
|
||||
- [ ] Backup previo de configuraciones de red
|
||||
|
||||
@@ -498,7 +498,7 @@ foreach ($Port in $Ports) {
|
||||
|
||||
**Topología Final Objetivo**:
|
||||
```
|
||||
Router ISP (Oficina DASUTeN)
|
||||
Router ISP (Oficina DASUTEN)
|
||||
├── Subred Local: 192.168.1.0/24
|
||||
│ ├── srv-dasu: 192.168.1.205/24 (IP local) + 10.0.100.1/24 (gateway VMs)
|
||||
│ └── pc-dasu0: 192.168.1.100/24
|
||||
@@ -0,0 +1,46 @@
|
||||
# Plan: Automatización Flujo Zoom a YouTube
|
||||
|
||||
> **Grupo de Trabajo:** DIGIs (Digitalización y Contenidos)
|
||||
|
||||
**Código:** P2603.01
|
||||
**Fecha:** 31 de marzo de 2026
|
||||
**Autor:** Sistema ADN
|
||||
**Versión:** 1.0
|
||||
**Estado:** 📝 PLANIFICADO
|
||||
|
||||
## 📋 Resumen Ejecutivo
|
||||
|
||||
El objetivo es automatizar un proceso repetitivo que actualmente requiere un alto esfuerzo manual y tiempo de espera ("toil"): descargar grabaciones de aulas y posgrados de Zoom a partir de enlaces en una Google Sheet, procesarlas localmente, subirlas en modo oculto al canal interno de YouTube, y finalmente notificar o retornar los enlaces a la planilla para los destinatarios.
|
||||
|
||||
Al automatizar este flujo utilizando el ecosistema ADN (CLI de herramientas Ruby), la intervención manual se reducirá idealmente a la ejecución de un solo comando (`zoom:sync` o similar).
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Desarrollar una herramienta nativa ADN que englobe estas etapas clave:
|
||||
1. Conectarse a Google Sheets para leer nuevas filas pendientes (sin `ID-YTB`).
|
||||
2. Gestionar la descarga robusta (`wget`/`curl` con sanitización estricta de espacios y nombres) al entorno delimitado `temp/`.
|
||||
3. Interconectar con la **YouTube Data API v3** para subir los videos directamente, dejándolos No Listados ("Unlisted").
|
||||
4. Devolver las URLs post-subida a la planilla y despachar las notificaciones necesarias.
|
||||
|
||||
## 📅 Fases de Implementación Orientativas
|
||||
|
||||
### ⏳ FASE 1: Integración Source (Google Sheets & Descarga)
|
||||
- **1.1:** Habilitar Google Sheets API. Guardar la credencial de Service Account cifrada usando `candados`.
|
||||
- **1.2:** Crear módulo Ruby (`adn/tools/cli/digis.rb`) para extraer columnas *IDReu*, *urlDOWN*, y *TIT*.
|
||||
- **1.3:** Descargar archivos de manera concurrente al directorio de trabajo optimizando transferencia y sanitizando las salidas de los nombres de archivos.
|
||||
|
||||
### ⏳ FASE 2: Extracción local (si aplica según webhook)
|
||||
- **2.1:** Detectar dinámicamente si Zoom retorna un `mp4` o requiere un unpack/descompresión (en el caso de recursos vinculados a chat txt y grabaciones juntas).
|
||||
|
||||
### ⏳ FASE 3: Upload a YouTube
|
||||
- **3.1:** Habilitar y configurar YouTube Data API v3 usando OAuth2 en la cuenta destino.
|
||||
- **3.2:** Mecanismo de subida asíncrona mediante Ruby, empujando chunks grandes de video con protección contra cortes, nombrando el archivo según `TIT` y ajustando la privacidad.
|
||||
|
||||
### ⏳ FASE 4: Notificación final y actualización
|
||||
- **4.1:** Almacenar de retorno el enlace definitivo en la columna `ID-YTB` de la planilla.
|
||||
- **4.2:** Desarrollar rutina para generar correos preformateados o alertas para los organizadores, confirmándoles los enlaces limpios.
|
||||
|
||||
## 🛠 Requisitos para Ecosistema ADN
|
||||
- Integración en `./adn/tools/run digis zoom:sync`
|
||||
- Todo el manejo temporal de GBs debe apuntar a la carpeta limpia `temp/` pero preferiblemente limpiar al concluir (`cleanup ensure`).
|
||||
- Los tokens API irán guardados de forma imperativa dentro de la bóveda de **Candados**.
|
||||
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,193 @@
|
||||
# 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 `adn/06_gobernanza.md`).
|
||||
|
||||
---
|
||||
|
||||
## 🌎 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)
|
||||
|
||||
---
|
||||
|
||||
## 📊 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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📌 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 |
|
||||
|
||||
**Última actualización:** 2026-03-30
|
||||
**Próxima revisión:** Al inicio de cada sesión
|
||||
@@ -1,340 +0,0 @@
|
||||
# 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
|
||||
|
||||
---
|
||||
|
||||
## 🌎 Zona Horaria
|
||||
|
||||
**IMPORTANTE**: Este proyecto opera en la zona horaria de **Argentina (Buenos Aires)**.
|
||||
|
||||
- **UTC**: UTC-3 (hora estándar argentina, sin DST)
|
||||
- **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
|
||||
|
||||
---
|
||||
|
||||
## 🌎 Zona Horaria
|
||||
|
||||
**IMPORTANTE**: Este proyecto opera en la zona horaria de **Argentina (Buenos Aires)**.
|
||||
|
||||
- **UTC**: Argentina no tiene horario de verano permanente (UTC-3)
|
||||
- **Comando local**: Usar `date` para obtener la hora correcta
|
||||
- **Formato registro**: HH:MM (24 horas)
|
||||
|
||||
---
|
||||
|
||||
## 🎯 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
|
||||
|
||||
### Subcomandos principales:
|
||||
|
||||
| Categoría | Comandos |
|
||||
|-----------|----------|
|
||||
| **Bitácoras** | `db evento:crear`, `db evento:actualizar`, `db evento:listar`, `jornada iniciar/cerrar` |
|
||||
| **Nodos** | `nodos listar`, `nodos info <nombre>`, `ssh <nodo> [comando]` |
|
||||
| **Ámbitos** | `ambitos listar`, `ambitos nodos <nombre>`, `ambitos crear` |
|
||||
| **Seguridad** | `candados authorize`, `candados run <clave> <cmd>` |
|
||||
| **Operaciones** | `backup <nodo>`, `salud`, `network show` |
|
||||
| **Generación** | `generar bitacora`, `generar nodo`, `generar evento <tipo>` |
|
||||
| **W-Zombi** | `wzombi start`, `wzombi cmd "<comando>"`, `wzombi log` |
|
||||
|
||||
### ⚠️ 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.
|
||||
|
||||
### Plantillas de Eventos
|
||||
|
||||
**OBLIGATORIO**: Usar plantillas para todos los eventos con detalles ricos.
|
||||
|
||||
```bash
|
||||
./adn/tools/run generar evento <tipo>
|
||||
```
|
||||
|
||||
**Tipos disponibles** (11):
|
||||
| Icono | Tipo | Uso |
|
||||
|-------|------|-----|
|
||||
| 🔧 | `implementacion` | Implementación técnica |
|
||||
| 🔍 | `investigacion` | Investigación/exploración |
|
||||
| 🛠️ | `resolucion` | Resolución de incidentes |
|
||||
| 📝 | `documentacion` | Documentación/corrección |
|
||||
| 👥 | `reunion` | Reuniones/comunicaciones |
|
||||
| ✅ | `test` | Pruebas/validación |
|
||||
| 🐛 | `debug` | Depuración |
|
||||
| 📋 | `planificacion` | Planificación |
|
||||
| 🔄 | `migracion` | Migraciones de red/sistemas |
|
||||
| ✏️ | `renombramiento` | Cambios de nombre de nodos |
|
||||
| 🛡️ | `backup` | Resguardos/VZDumps |
|
||||
|
||||
### Base de datos:
|
||||
|
||||
- **Host:** localhost:5433
|
||||
- **DB:** dtic_bitacoras
|
||||
- **Schema:** bitacoras
|
||||
- **Tablas:** nodos, bitacoras, entradas, temas, gestion, proyectos, fases, hitos
|
||||
|
||||
---
|
||||
|
||||
## 📋 Convenciones de Registro
|
||||
|
||||
### Formato de descripciones:
|
||||
|
||||
```
|
||||
[CÓDIGO_PROYECTO] Descripción breve
|
||||
|
||||
**Detalle 1**: Valor
|
||||
**Detalle 2**: Valor
|
||||
**Próximo**: Qué sigue
|
||||
```
|
||||
|
||||
### Ejemplo real:
|
||||
|
||||
```
|
||||
[P2604.06] Mejora herramienta candados: migración de temporales
|
||||
|
||||
**Archivos modificados**: candados.rb, README.md
|
||||
**Principio**: 05_ia.md #11 (Workspace Bounds)
|
||||
**Próximo**: Actualizar documentación
|
||||
```
|
||||
|
||||
### Referencia a planes en eventos:
|
||||
|
||||
Cuando un evento está asociado a un plan `.md`, usar el flag `--doc` para vincular:
|
||||
|
||||
**Formato CLI:**
|
||||
```bash
|
||||
./adn/tools/run db evento:crear --doc P2601_Dasuten/P2601.09_DASUTEN-sin-DC.md ...
|
||||
./adn/tools/run db evento:actualizar 1308 --doc P2604_Mejoras-ADN/P2604_Mejoras-ADN.md
|
||||
```
|
||||
|
||||
**Campo BD:** `doc_path` en tabla `bitacoras.entradas` (formato: `CARPETA/ARCHIVO.md`).
|
||||
|
||||
**En la web:** Se renderiza como botón clickeable que abre el `.md` en un modal. El contenido se lee del disco dinámicamente — no necesita reiniciar Docker.
|
||||
|
||||
**⚠️ IMPORTANTE:** Si se renombra el archivo `.md`, solo hay que actualizar el campo `doc_path` en los eventos afectados (un solo UPDATE).
|
||||
|
||||
### Tiempos:
|
||||
|
||||
- **Siempre** registrar `--inicio` y `--fin`
|
||||
- **USAR TIEMPO REAL**: hora actual del sistema, no secuencias teóricas
|
||||
- Los eventos son **secuenciales**, no simultáneos
|
||||
- Si trabajás en paralelo, usá diferentes `--nodo`
|
||||
|
||||
**⚠️ IMPORTANTE:**
|
||||
```bash
|
||||
# ✅ CORRECTO: Tiempo real
|
||||
./adn/tools/run db evento:crear --inicio $(date +%H:%M)
|
||||
|
||||
# ❌ INCORRECTO: Forzar secuencias artificiales
|
||||
# No inventes tiempos "lógicos" si la tarea real empezó ahora
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔐 Seguridad
|
||||
|
||||
**⚠️ LEER ANTES DE OPERAR:** [`adn/03_seguridad.md`](../adn/03_seguridad.md)
|
||||
|
||||
- Contiene protocolos de seguridad, gestión de candados y matriz de acceso SSH
|
||||
- **Nunca** escribir secretos en texto plano o commitearlos
|
||||
- Usar `tmp/` del repo, nunca `/tmp/` del sistema
|
||||
|
||||
---
|
||||
|
||||
## 🌐 Topología de Red
|
||||
|
||||
### Comandos útiles:
|
||||
|
||||
```bash
|
||||
# ⚠️ SIEMPRE ejecutar esto ANTES de conectar por SSH
|
||||
./adn/tools/run nodos info <nombre-nodo>
|
||||
|
||||
# Ver topología completa
|
||||
./adn/tools/run network show --formato texto
|
||||
|
||||
# Listar todos los nodos
|
||||
./adn/tools/run nodos listar
|
||||
```
|
||||
|
||||
**El comando `nodos info` muestra: IP, Puerto SSH, Usuario, Auth, Bóveda, SO, VMID**
|
||||
|
||||
### Nodos comunes:
|
||||
- `dtic-DIIAA` - Nodo principal (donde trabajás)
|
||||
- `srv-ns8` - Servidor principal
|
||||
- `dasu-srvv-sql` - SQL Server
|
||||
- `dasu-srvv-dc` - Domain Controller
|
||||
- `dtic-EVENTOS` - Gestión de eventos y videoconferencias
|
||||
- `dtic-DIGI` - Grabaciones y contenidos digitales (YouTube)
|
||||
|
||||
### ⚠️ Puertos SSH por Nodo
|
||||
- **Linux VMs**: Puerto 22 (estándar)
|
||||
- **Windows VMs (dasu-srvv-dc, dasu-srvv-sql, dasu-pcv)**: Puerto **7022** (OpenSSH hardeado)
|
||||
- **PCs físicas Windows**: Puerto **7022** (si tiene OpenSSH)
|
||||
|
||||
---
|
||||
|
||||
## 📁 Estructura del Repositorio
|
||||
|
||||
```
|
||||
dtic-DIIAA/
|
||||
├── adn/ # Núcleo del ecosistema
|
||||
│ ├── 00_indice.md # Mapa general
|
||||
│ ├── 01_ontologia.md # Nodos y topología
|
||||
│ ├── 02_bitacora.md # Formato de registro
|
||||
│ ├── 05_ia.md # Directivas para IA ⚠️
|
||||
│ └── tools/ # Herramientas CLI
|
||||
├── docs/
|
||||
│ ├── bitacoras/ # Bitácoras diarias (exportadas)
|
||||
│ ├── proy/ # Proyectos (P2604_*)
|
||||
│ └── prompt/ # Contexto para IA
|
||||
├── nodos/ # Fichas de nodos
|
||||
├── tmp/ # Temporales (único tmp válido)
|
||||
└── servicios/ # Docker Compose
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🤖 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
|
||||
|
||||
---
|
||||
|
||||
## 🏢 Ámbitos del Sistema
|
||||
|
||||
**Ver listado actual:** `./adn/tools/run ambitos listar`
|
||||
|
||||
Los ámbitos agrupan nodos por área funcional. La lista completa y actualizada está en [`adn/01_ontologia.md`](../adn/01_ontologia.md).
|
||||
|
||||
---
|
||||
|
||||
## 📊 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/
|
||||
|
||||
---
|
||||
|
||||
## 📚 Documentación de Referencia
|
||||
|
||||
| Archivo | Propósito |
|
||||
|---------|-----------|
|
||||
| `adn/README.md` | Punto de entrada al ecosistema |
|
||||
| `adn/05_ia.md` | Directivas específicas para IA ⚠️ |
|
||||
| `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/prompt/260325-0809_Contexto.md` | Contexto inicial del proyecto |
|
||||
| `docs/prompt/260325-0900_Contexto-IA.md` | Este archivo - Contexto (minimalista) |
|
||||
|
||||
---
|
||||
|
||||
## 🚀 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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Última actualización:** 2026-03-26 09:00
|
||||
**Próxima revisión:** Al inicio de cada sesión
|
||||
|
||||
---
|
||||
|
||||
## 📌 Principio "Menos es Más"
|
||||
|
||||
Este archivo contiene solo lo esencial para operar. Para detalles completos, consultar las hebras canónicas:
|
||||
|
||||
- Seguridad → `adn/03_seguridad.md`
|
||||
- Ontología/Ámbitos → `adn/01_ontologia.md`
|
||||
- Bitácoras → `adn/02_bitacora.md`
|
||||
- IA Directivas → `adn/05_ia.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,6 @@
|
||||
Lee docs/contexto/IA.md y docs/ambito/dtic-DASUTEN/P2601.09_DASUTEN-sin-DC.md.
|
||||
Actualiza la bitácora, el plan y el contexto, si corresponde.
|
||||
Luego, podés continuar con lo último que dejamos pendiente.
|
||||
|
||||
Recuerda que los elementos temporales están prácticamente prohibidos, ya que lo que se busca es verificar si las herramientas ADN pueden resolver el problema; de lo contrario, se deberá crear o mejorar la existente para lograr una solución eficiente, reutilizable y no temporal.
|
||||
|
||||
@@ -275,4 +275,4 @@ Directorio: /mnt/ns8Disco3/dtic-BACKUPS/bkps-SERVIDORes/<nombre_vm>/
|
||||
|
||||
- **Bitácoras**: Consultar en DB vía `./adn/tools/run db evento:listar`
|
||||
- **ADN**: [Ontología](../../../adn/01_ontologia.md) | [Proyectos](../../../adn/07_proyectos.md)
|
||||
- **Proyecto Relacionado**: [P2601 DASUTEN](../P2601_Dasuten/P2601_dasuten.md) (srv-dasu backups)
|
||||
- **Proyecto Relacionado**: [P2601 DASUTEN](../../ambito/dtic-DASUTEN/P2601_dasuten.md) (srv-dasu backups)
|
||||
|
||||
Reference in New Issue
Block a user