[ADN] Refactorización a arquitectura multi-hebra con Armonía Integral
This commit is contained in:
Ricardo Monla
@@ -1,16 +0,0 @@
|
||||
# Índice de Bitácoras del Proyecto srv-ns8
|
||||
|
||||
El registro detallado de eventos se ha segmentado por fecha para mejor organización.
|
||||
|
||||
| Fecha | Eventos Clave | Resumen de Actividad |
|
||||
| :--- | :--- | :--- |
|
||||
| [**19/02/2026**](../bitacoras/2026-02-19.md) | Registro Procedimientos, Backup Proxmox. | Implementación del sistema de procedimientos y lanzamiento del primer ciclo de backup automatizado (Ruby). |
|
||||
| [**18/02/2026**](../bitacoras/2026-02-18.md) | Recuperación Proxmox, DASU, Alta Nodos. | Recuperación Proxmox SSH, implementación VPN Tailscale, alta usuarios DC y carga calendario Posgrado. |
|
||||
| [**16/02/2026**](../bitacoras/2026-02-16.md) | Hardening SSH, Expansión Grid. | Hardening masivo de SSH en el Grid y expansión del relevamiento a nuevos nodos LXC/VM. |
|
||||
| [**15/02/2026**](../bitacoras/2026-02-15.md) | Tailscale Server. | Implementación de Tailscale y RustDesk como solución estratégica de acceso remoto. |
|
||||
| [**11/02/2026**](../bitacoras/2026-02-11.md) | Servicios Base (Nginx, SSL). | Configuración de servicios base, establecimiento de protocolos de seguridad y red híbrida. |
|
||||
| [**08/02/2026**](../bitacoras/2026-02-08.md) | Solución Licencia FENIX. | Resolución del incidente de apagado automático en `srvv-fenix` por causa de licencia. |
|
||||
| [**07/02/2026**](../bitacoras/2026-02-07.md) | Incidentes apagado srvv-fenix. | Investigación forense intensiva ante apagados recurrentes de `srvv-fenix`. |
|
||||
| [**14/01/2026**](../bitacoras/2026-01-14.md) | Gestión Digital CD (Video). | Gestión y publicación de grabaciones de Consejo Directivo en YouTube. |
|
||||
|
||||
> **Nota**: Los archivos fuente se encuentran en el directorio `/bitacoras`.
|
||||
@@ -0,0 +1,46 @@
|
||||
# 🧬 ADN del Proyecto: srv-ns8
|
||||
|
||||
> *Las hebras del ADN no existen aisladas: se entrelazan y codifican información que afecta a todo el organismo.*
|
||||
|
||||
## Principio Rector: Armonía Integral
|
||||
|
||||
En este proyecto **todo tiene que ver con todo**. El ADN (hebras), las Bitácoras (registro diario) y los Nodos (infraestructura) forman un organismo interconectado donde la coherencia es un requisito de supervivencia.
|
||||
|
||||
- **ADN → Bitácoras**: Las hebras definen cómo se escriben, qué iconos usan y qué triggers disparan.
|
||||
- **ADN → Nodos**: La ontología describe los nodos; los nodos alimentan los hitos de las bitácoras.
|
||||
- **Bitácoras → ADN**: Las mejores prácticas emergentes se formalizan como nuevas reglas en las hebras (Evolución Progresiva).
|
||||
- **Bitácoras → Nodos**: Los cambios de estado de un nodo se reflejan tanto en la bitácora como en su ficha de nodo.
|
||||
|
||||
> **Regla de Armonía**: Si un dato cambia en un sitio, **debe propagarse** a todos los demás. Esta responsabilidad recae tanto sobre el operador como sobre la IA. Al detectar una inconsistencia, es prioritario resolverla antes de avanzar.
|
||||
|
||||
---
|
||||
|
||||
## Hebras del ADN
|
||||
|
||||
| # | Hebra | Archivo | Dominio |
|
||||
| :---: | :--- | :--- | :--- |
|
||||
| 01 | [**Ontología**](01_ontologia.md) | `01_ontologia.md` | Identidad del sistema, nodos, servicios y topología de red. |
|
||||
| 02 | [**Bitácora**](02_bitacora.md) | `02_bitacora.md` | Formato del registro diario, triggers de sincronización y métricas híbridas. |
|
||||
| 03 | [**Seguridad**](03_seguridad.md) | `03_seguridad.md` | Protocolos de red (Hombre Muerto), secretos operativos y bóveda cifrada. |
|
||||
| 04 | [**Iconografía**](04_iconografia.md) | `04_iconografia.md` | Taxonomía visual de estados e iconos semánticos. |
|
||||
| 05 | [**Directivas IA**](05_ia.md) | `05_ia.md` | Fuente única de verdad para las premisas de trabajo de la Inteligencia Artificial. |
|
||||
| 06 | [**Gobernanza**](06_gobernanza.md) | `06_gobernanza.md` | Idioma, nomenclatura, armonía integral, resguardo y evolución progresiva. |
|
||||
|
||||
---
|
||||
|
||||
## Índice de Bitácoras
|
||||
|
||||
| Fecha | Eventos Clave | Resumen de Actividad |
|
||||
| :--- | :--- | :--- |
|
||||
| [**27/02/2026**](../bitacoras/2026-02-27.md) | Backup DB01 Manual, Refactorización ADN. | Finalización de backup Proxmox vía GUI y descomposición del ADN en arquitectura multi-hebra. |
|
||||
| [**26/02/2026**](../bitacoras/2026-02-26.md) | SQL Server Instalado, SSH, Backups. | Reconstrucción del motor SQL en Español, habilitación de OpenSSH nativo y resguardo VZDump. |
|
||||
| [**25/02/2026**](../bitacoras/2026-02-25.md) | VM SQL Server, ISO Español. | Creación de VM DB01, troubleshooting de localización y descarga de ISO ES-ES. |
|
||||
| [**20/02/2026**](../bitacoras/2026-02-20.md) | Refinamiento Bitácoras. | Evolución del formato de bitácora con ID alfanuméricos e iconografía semántica. |
|
||||
| [**19/02/2026**](../bitacoras/2026-02-19.md) | Procedimientos, Backup Proxmox. | Sistema de procedimientos y primer ciclo de backup automatizado (Ruby). |
|
||||
| [**18/02/2026**](../bitacoras/2026-02-18.md) | Recuperación Proxmox, DASU. | Recuperación SSH Proxmox, VPN Tailscale y alta usuarios DC. |
|
||||
| [**16/02/2026**](../bitacoras/2026-02-16.md) | Hardening SSH, Expansión Grid. | Hardening masivo de SSH y expansión del relevamiento a nuevos nodos. |
|
||||
| [**15/02/2026**](../bitacoras/2026-02-15.md) | Tailscale Server. | Implementación de Tailscale y RustDesk como solución de acceso remoto. |
|
||||
| [**11/02/2026**](../bitacoras/2026-02-11.md) | Servicios Base (Nginx, SSL). | Configuración de servicios base y protocolos de seguridad. |
|
||||
| [**08/02/2026**](../bitacoras/2026-02-08.md) | Solución Licencia FENIX. | Resolución del incidente de apagado automático en `srvv-fenix`. |
|
||||
| [**07/02/2026**](../bitacoras/2026-02-07.md) | Incidentes srvv-fenix. | Investigación forense ante apagados recurrentes. |
|
||||
| [**14/01/2026**](../bitacoras/2026-01-14.md) | Gestión Digital CD. | Gestión y publicación de grabaciones de Consejo Directivo en YouTube. |
|
||||
@@ -0,0 +1,61 @@
|
||||
# 02 - Hebra: Formato de Bitácora
|
||||
|
||||
> Referencia canónica: [`adn/00_indice.md`](00_indice.md)
|
||||
|
||||
Esta hebra define el formato, estructura y reglas de sincronización de las bitácoras diarias del proyecto.
|
||||
|
||||
## 1. Principios Generales
|
||||
|
||||
- **Orden Inverso Cronológico**: Lo más nuevo SIEMPRE ARRIBA.
|
||||
- **Archivo Diario**: `bitacoras/YYYY-MM-DD.md`.
|
||||
|
||||
## 2. Control de Gestión
|
||||
|
||||
- **Pendientes**: Tabla de tareas por hacer (ID **[Icono] - [Hora Ini] - [Nombre Tarea]** | NODO | DETALLE).
|
||||
- **En Proceso**: Tabla de tareas activas (ID **[Icono] - [Hora Ini] - [Nombre Tarea]** | NODO | DETALLE).
|
||||
- **Resumen de Actividades**:
|
||||
- **Formato**: Tabla (NODO | RESUMEN INTEGRAL).
|
||||
- **Estilo**: **Narrativa Sintética e Integral**. SIN TÍTULOS NI ESTADOS en el texto. Solo la historia consolidada del día para ese nodo.
|
||||
- **Regla**: **Una sola fila por Nodo**.
|
||||
|
||||
## 3. Actividades Detalladas
|
||||
|
||||
- **Subdivisión**: Encabezados por Nodo (`### srv-ns8`).
|
||||
- **Formato Jerárquico**:
|
||||
1. Título H4 del Tema: `#### [Estado] - [ID] - [Nombre Tarea]` (ej. `#### ✅ - A09 - dtic-BKPs C4`).
|
||||
2. Párrafo Narrativo: Descripción rica que incluye referencias de migración (ej. `➡️ **[Viene del 23/02]...**`) y que explica el "qué" y el "por qué" de la tarea.
|
||||
3. Tabla Cronológica: Tabla `| Tiempo | Descripción |`.
|
||||
- **Formato de Tiempo**: La columna Tiempo debe usar la sintaxis `[Icono Semántico] HH:MM` **SIN** el sufijo "hs" (ej. `✅ 23:26`).
|
||||
- **Estados (Tema)**: Estrictamente delimitados para trazabilidad (✅ Cerrado, ⏳ En Proceso, ⚠️ Fallo).
|
||||
- **Semántica (General)**: Uso de una taxonomía visual rica para escaneo visual ultrarrápido (ver hebra [04_iconografia.md](04_iconografia.md)).
|
||||
- **Auto-Registro (IA)**: Cualquier acción técnica autónoma de la IA **DEBE** registrarse explícitamente en las tablas cronológicas indicando "(IA)" y el respectivo emoji semántico.
|
||||
|
||||
## 4. Métricas Híbridas (Telemetría)
|
||||
|
||||
**OBLIGATORIO**. Cada hito o bloque de sincronización (SINC) debe registrar el esfuerzo:
|
||||
|
||||
- **En proceso**: Usar formato `[Físico/Remoto: Iniciado HH:MM]`.
|
||||
- **Finalizado**: Usar formato de duración `[Físico/Remoto: H:MM hs]`.
|
||||
|
||||
La IA escaneará sintácticamente estas métricas para graficarlas en la aplicación web del dashboard.
|
||||
|
||||
## 5. Reglas de Sincronización en Cascada (Triggers)
|
||||
|
||||
El mantenimiento de la bitácora es dinámico y reactivo. La actualización de una sección debe **disparar (trigger)** la actualización de sus dependencias:
|
||||
|
||||
- **Trigger 1 (Detalle → En Proceso)**: Al insertar una nueva viñeta en la cronología de una tarea activa (`⏳`), se DEBE actualizar la columna `DETALLE` de esa misma tarea en la tabla `En Proceso`.
|
||||
- **Trigger 2 (Cierre → Resumen Integral)**: Al cambiar el estado de la última tarea activa de un Nodo de `⏳` a `✅` (o `⚠️`), se DEBE desencadenar la redacción o actualización de su `RESUMEN INTEGRAL`.
|
||||
- **Trigger 3 (Cambio de Día → Rollover)**: Al crear un nuevo archivo de bitácora:
|
||||
1. Migrar las actividades `Pendientes` y `En Proceso` hacia las tablas del nuevo día.
|
||||
2. En la bitácora del día fenecido, cambiar el Estado Tema de las tareas migradas a `➡️` (**Migrado**).
|
||||
3. Inyectar hipervínculos bidireccionales de trazabilidad transdiaria.
|
||||
|
||||
## 6. Footer de Referencia (IA)
|
||||
|
||||
Al final de cada bitácora, incluir una referencia mínima a la fuente de verdad de las Directivas IA:
|
||||
|
||||
```html
|
||||
<!-- 🤖 PREMISAS DE TRABAJO (IA): Fuente de Verdad → adn/05_ia.md -->
|
||||
```
|
||||
|
||||
> **Evolución**: Las premisas de trabajo evolucionan **exclusivamente** en la hebra [`05_ia.md`](05_ia.md). Las bitácoras **nunca** duplican las reglas.
|
||||
@@ -1,134 +0,0 @@
|
||||
# 02 - Protocolo del Proyecto: Normas y Directivas
|
||||
|
||||
Este documento establece las reglas fundamentales para la interacción, documentación y desarrollo en el proyecto `srv-ns8`.
|
||||
|
||||
## 1. Idioma y Nomenclatura
|
||||
- **Directiva**: **Todo el contenido debe estar en español.**
|
||||
- **Nomenclatura de Nodos**: Estrictamente **minúsculas** en nombres de archivo y referencias (ej: `srv-ns8`, `pc-dasu0`, `srvv-maurik`).
|
||||
- **Alcance**:
|
||||
- Interacciones con el asistente (chat).
|
||||
- Documentación (archivos `.md`).
|
||||
- Mensajes de Commit (Git).
|
||||
- Comentarios en el código (scripts, configs).
|
||||
|
||||
## 2. Formato de Documentación
|
||||
- **Estilo**: Markdown estándar.
|
||||
- **Ubicación**: Todo documento clave debe residir en el directorio `adn/`.
|
||||
|
||||
## 3. Armonía y Auto-optimización
|
||||
- **Principio**: La documentación (ADN) debe mantenerse como un todo coherente y libre de contradicciones.
|
||||
- **Alcance Global**: Esta directiva aplica a **TODOS** los directorios del proyecto, incluyendo `adn/`, `bitacoras/`, `nodos/`, y `procedimientos/`.
|
||||
- **Directiva**:
|
||||
- **Consistencia**: No deben existir discrepancias entre diferentes hebras. Si se actualiza una definición en `01_ontologia.md`, debe reflejarse en los protocolos y bitácoras correspondientes.
|
||||
- **Trazabilidad**: Los IDs y estados deben ser consistentes a través del tiempo.
|
||||
- **Auto-corrección**: Al detectar una inconsistencia, es prioritario resolverla para restaurar la armonía del sistema documental.
|
||||
|
||||
## 4. Estructura de Bitácora (Flujo Diario)
|
||||
- **Principio**: **Orden Inverso Cronológico** (Lo más nuevo SIEMPRE ARRIBA).
|
||||
- **Archivo Diario**: `bitacoras/YYYY-MM-DD.md`.
|
||||
- **Secciones Obligatorias**:
|
||||
|
||||
### 4.1 Control de Gestión
|
||||
- **Pendientes**: Tabla de tareas por hacer (ID **[Icono] - [Hora Ini] - [Nombre Tarea]** | NODO | DETALLE).
|
||||
- **En Proceso**: Tabla de tareas activas (ID **[Icono] - [Hora Ini] - [Nombre Tarea]** | NODO | DETALLE).
|
||||
- **Resumen de Actividades**:
|
||||
- **Formato**: Tabla (NODO | RESUMEN INTEGRAL).
|
||||
- **Estilo**: **Narrativa Sintética e Integral**. SIN TÍTULOS NI ESTADOS en el texto. Solo la historia consolidada del día para ese nodo.
|
||||
- **Regla**: **Una sola fila por Nodo**.
|
||||
|
||||
### 4.2 Actividades Detalladas
|
||||
- **Subdivisión**: Encabezados por Nodo (`### srv-ns8`).
|
||||
- **Formato Jerárquico**:
|
||||
1. Título H4 del Tema: `#### [Estado] - [ID] - [Nombre Tarea]` (ej. `#### ✅ - A09 - dtic-BKPs C4`).
|
||||
2. Párrafo Narrativo: Descripción rica que incluye referencias de migración (ej. `➡️ **[Viene del 23/02]...**`) y que explica el "qué" y el "por qué" de la tarea.
|
||||
3. Tabla Cronológica: Tabla `| Tiempo | Descripción |`.
|
||||
- **Formato de Tiempo**: La columna Tiempo debe usar la sintaxis `[Icono Semántico] HH:MM` **SIN** el sufijo "hs" (ej. `✅ 23:26`).
|
||||
- **Métricas Operativas (Dashboard)**: Para soportar la telemetría del dashboard de proyectos, las tareas que consumen tiempo prolongado (especialmente durante hitos de implementacion) deben especificar su esfuerzo en el texto usando las etiquetas `[Físico: X hs]` y/o `[Remoto: Y hs]`. La IA parseará estas etiquetas para alimentar los medidores duales (`physical` vs `remote`) en las líneas de tiempo web.
|
||||
- **Estados (Tema)**: Estrictamente delimitados para trazabilidad (✅ Cerrado, ⏳ En Proceso, ⚠️ Fallo).
|
||||
- **Semántica (General)**: Uso de una taxonomía visual rica tanto en el párrafo de descripción como en cada fila de cronograma para otorgar un escaneo visual ultrarrápido (ej. 🔧, 🧹, 📝, 🧪, 💾).
|
||||
- **Auto-Registro (IA)**: El proyecto es operado de forma conjunta. Cualquier acción técnica, investigación subyacente o inyección de comandos SSH realizada autónomamente por la Inteligencia Artificial **DEBE** registrarse explícitamente en las tablas cronológicas (indicando "(IA)" y el respectivo emoji semántico), asegurando la trazabilidad absoluta de la autoría técnica de cada evento.
|
||||
|
||||
### 4.3 Reglas de Sincronización en Cascada (Triggers)
|
||||
El mantenimiento de la bitácora es dinámico y reactivo. La actualización de una sección debe **disparar (trigger)** la actualización de sus dependencias para garantizar consistencia:
|
||||
- **Trigger 1 (Detalle -> En Proceso)**: Al insertar una nueva viñeta en la cronología de `Hitos` de una tarea activa (`⏳`), se DEBE actualizar la columna `DETALLE` de esa misma tarea en la tabla `En Proceso` para reflejar su último estado de avance.
|
||||
- **Trigger 2 (Cierre -> Resumen Integral)**: Al cambiar el estado de la última tarea activa de un Nodo de `⏳` a `✅` (o `⚠️`), indicando que ya no quedan tareas en proceso para dicho nodo, se DEBE desencadenar la redacción o actualización de su `RESUMEN INTEGRAL` consolidado en la tabla de inicio.
|
||||
- **Trigger 3 (Cambio de Día -> Rollover)**: Al crear un nuevo archivo de bitácora (`YYYY-MM-DD.md`):
|
||||
- 1. Heredar íntegro el bloque HTML final de `Premisas de Trabajo (IA)` de la bitácora de ayer.
|
||||
- 2. Migrar las actividades `Pendientes` y `En Proceso` hacia las tablas de Control de Gestión del nuevo día.
|
||||
- 3. En la bitácora del día fenecido, cambiar el Estado Tema de las tareas migradas de `⏳` (o `📍`) a `➡️` (**Migrado**), y añadir una viñeta final de Hito narrando el traspaso (ej. `- ➡️ **23:59 hs**: Tarea delegada a la bitácora de mañana.`).
|
||||
|
||||
### 4.4 Footer de Mantenimiento (IA)
|
||||
- Al final de cada bitácora, incluir el bloque de comentarios HTML con las **Premisas de Trabajo**.
|
||||
- **Evolución**: El footer debe ser idéntico al del día anterior o una versión evolucionada (con nuevas reglas). NUNCA una versión simplificada o diferente.
|
||||
- **Registro**: Las nuevas reglas se acumulan para mantener la memoria del sistema.
|
||||
|
||||
## 5. Documentación de Nodos (Snapshots)
|
||||
- **Ubicación**: `nodos/<hostname>.md` (Raíz del proyecto).
|
||||
- **Contenido**: Representa el **Estado Actual** (Snapshot) del nodo.
|
||||
- **Actualización**: Solo se modifica cuando cambia la configuración o estado del nodo. No duplicar información dinámica de la bitácora.
|
||||
|
||||
## 6. Protocolo de Seguridad de Red (Hombre Muerto)
|
||||
- **Problemática**: La administración remota del servidor implica el riesgo de desconexión total ante cambios erróneos en la configuración de red.
|
||||
- **Directiva**: **Toda modificación de red debe incluir un mecanismo de reversión automática.**
|
||||
- **Implementación**:
|
||||
- Usar scripts con temporizador ("Dead Man's Switch").
|
||||
- **Flujo**:
|
||||
1. Aplicar cambios temporalmente.
|
||||
2. Esperar confirmación explícita del usuario (ej: presionar una tecla) durante un tiempo prudencial (5 minutos).
|
||||
3. **Si no hay confirmación**: Revertir cambios inmediatamente y restaurar estado anterior.
|
||||
4. **Si hay confirmación**: Hacer cambios persistentes.
|
||||
|
||||
## 7. Referencia de Iconografía
|
||||
Para optimizar el escaneo visual de las bitácoras, se implementa una estricta separación de responsabilidades visuales:
|
||||
|
||||
### 1. Icono de Estado (Columna Tema)
|
||||
| Icono | Significado | Descripción |
|
||||
| :---: | :--- | :--- |
|
||||
| ✅ | **Completado** | Tarea general finalizada exitosamente. |
|
||||
| ⏳ | **En Proceso** | Tarea en ejecución o pendiente de cierre. |
|
||||
| ⚠️ | **Fallo / Alerta** | Tarea fallida, cancelada o riesgo detectado. |
|
||||
| 📍 | **Definido** | Pendiente en la cola de planificación (Control de Gestión). |
|
||||
| ➡️ | **Migrado** | Tarea transferida a la bitácora del día siguiente (Rollover). |
|
||||
|
||||
### 2. Iconos Semánticos (Prefijos y Viñetas de Hitos)
|
||||
| Icono | Orientación | Ejemplos de Uso |
|
||||
| :---: | :--- | :--- |
|
||||
| 🟢 | **Operativo** | Servicio funcionando, confirmación de red, OK. |
|
||||
| 🔧 | **Configuración** | Mantenimiento, ajuste de parámetros, cambios de código. |
|
||||
| 🧪 | **Prueba** | Validación técnica, ensayos, simulaciones, logs. |
|
||||
| 🐛 | **Bug / Fix** | Errores de software, excepciones, correcciones. |
|
||||
| 🧹 | **Limpieza** | Refactorización, purga, reubicación de archivos. |
|
||||
| 💾 | **Datos** | Backups, volcados, sincronización de discos, almacenamiento. |
|
||||
| 🚀 | **Despliegue** | Lanzamiento masivo, ejecución grande, puesta en marcha. |
|
||||
| 👁️ | **Análisis** | Revisión humana, planificación, auditoría, brainstorming. |
|
||||
| 🧠 | **Estructura** | Conceptualización de arquitectura, metodologías, ideas críticas. |
|
||||
| 📝 | **Documentación**| Actualización del ADN, manuales, reportes, logs manuales. |
|
||||
|
||||
## 8. Resguardo del Repositorio (Safeguard)
|
||||
- **Objetivo**: Asegurar la integridad y el historial de cambios del proyecto.
|
||||
- **Directiva**:
|
||||
- **Frecuencia**: Al finalizar una tarea significativa o conjunto de tareas relacionadas (hito).
|
||||
- **Alcance**: Todo cambio en `adn/`, `servicios/config`, `scripts/` y documentación `docs/`.
|
||||
- **Formato Mensaje**: `[Categoría] Descripción breve del cambio`.
|
||||
|
||||
## 9. Evolución Progresiva (Mejora Continua)
|
||||
- **Principio**: El ADN no es estático; evoluciona a partir de los descubrimientos y buenas prácticas (emergentes) surgidas durante la operación diaria.
|
||||
- **Flujo de Vida de una Mejora**:
|
||||
1. **Incubación (Prueba de Concepto)**: Una técnica experimental (ej. notas ocultas HTML para instanciar a la IA, rediseños de interfaces) se prueba bajo fuego en la trinchera (bitácoras diarias, scripts, reportes).
|
||||
2. **Identificación**: Se reconoce el valor sistémico y repetible de la técnica.
|
||||
3. **Formalización**:
|
||||
4. UNIFICACIÓN: Una sola fila por Nodo en Resumen.
|
||||
5. ESTADO ACTIVO: Tareas iniciadas sin finalizar van a 'En Proceso'.
|
||||
6. IDENTIFICADORES: Usar el correlativo exacto del Tema (ej. `[✅ - 09:13 - **dtic-BKPs C4**](#...)`).
|
||||
7. ARMONÍA: Consultar y seguir estrictamente las premisas del ADN (`adn/02_protocolo.md`)., `adn/01_ontologia.md`, etc.).
|
||||
4. **Propagación**: A partir de su formalización, la regla es de cumplimiento obligatorio para el trabajo futuro y, donde sea viable, se refactoriza el material previo para mantener la Consistencia (ver Sección 3).
|
||||
- **Ejemplos Fundacionales**:
|
||||
1. **Estructura Dinámica**: Las *Premisas de Trabajo (IA)* en el footer de las bitácoras nacieron como un experimento y evolucionaron orgánicamente hasta convertirse en un estándar estructural oficial (Sección 4.3).
|
||||
2. **Migración Tecnológica (Bash → Ruby)**: El salto de scripts procedimentales en Bash hacia aplicaciones estructuradas en Ruby (`dtic-BKPs`). La operación real demostró que Bash resultaba frágil e inescalable para secuencias complejas. Ruby fue probado, identificado como superior por su manejo de excepciones y adaptabilidad estructural, formalizado en la reescritura de las herramientas, y propagado como el nuevo estándar de facto para construir utilidades dentro del repositorio.
|
||||
|
||||
### 10. Interacciones Operativas (IA)
|
||||
|
||||
1. **Gestión de Secretos sin Texto Plano:** La Inteligencia Artificial operante tiene expresamente prohibido solicitar contraseñas administrativas, tokens o claves privadas al operador, así como también plasmarlas en logs, comandos literales temporales o en la bitácora.
|
||||
2. **Consumo de Bóveda Ephemeral:** Ante requerimientos de escalada de privilegios (`sudo`, `root`, `sshpass`), la IA accederá de forma autónoma a la bóveda encriptada localizándose en `scripts/.agent_secrets.json` a través de la interfaz de desencriptación (`ruby scripts/secret_box.rb decrypt <payload>`). Este pase se realizará exclusivamente inyectando subshells para enmascarar la variable en los árboles de procesos: `CMD_PASS=$(ruby...); sshpass -p "$CMD_PASS" ...`
|
||||
3. **Restricción Estricta de Directorio de Trabajo (Workspace Bounds):** Toda creación de artefactos transitorios (scripts de Python, Powershell, Bash, dumps temporales) que la IA genere para asistir en la depuración, verificación o ejecución de una tarea **deberá confinarse de forma absoluta al directorio `tmp/` en la raíz del repositorio local**. Está **terminantemente prohibido** utilizar la carpeta temporal global del sistema operativo anfitrión (ej. `/tmp/`), garantizando que la basura residual y el rastro operativo del proyecto no contamine la máquina física del operador y quede abarcada bajo el manto del archivo `.gitignore`.
|
||||
4. **Principio Bitácora-First (Pre-Declaración de Tareas):** La IA debe practicar transparencia proactiva. **Antes** de despachar cadenas de comandos exploratorias, pruebas de concepto de red (como tests SSH), o iniciar transformaciones extensas (scripts ad-hoc), la IA está obligada a **registrar la acción inminente en la Bitácora del Día con el estado `⏳`**. Una vez que la validación o el comando finalice en la terminal, deberá actualizar dicha fila en la misma iteración y virarla al estado de completitud `✅` o fallo `❌`. Este principio garantiza que, si un comando bloquea o crashea a la IA ciegamente, el operador humano encuentre el registro exacto de la interrupción en el documento.
|
||||
@@ -0,0 +1,41 @@
|
||||
# 03 - Hebra: Seguridad y Red
|
||||
|
||||
> Referencia canónica: [`adn/00_indice.md`](00_indice.md)
|
||||
|
||||
Esta hebra gobierna los protocolos de seguridad de red, gestión de secretos y contingencia ante fallos críticos de conectividad.
|
||||
|
||||
## 1. Protocolo de Seguridad de Red (Hombre Muerto)
|
||||
|
||||
- **Problemática**: La administración remota del servidor implica el riesgo de desconexión total ante cambios erróneos en la configuración de red.
|
||||
- **Directiva**: **Toda modificación de red debe incluir un mecanismo de reversión automática.**
|
||||
- **Implementación**:
|
||||
- Usar scripts con temporizador ("Dead Man's Switch").
|
||||
- **Flujo**:
|
||||
1. Aplicar cambios temporalmente.
|
||||
2. Esperar confirmación explícita del usuario durante un tiempo prudencial (5 minutos).
|
||||
3. **Si no hay confirmación**: Revertir cambios inmediatamente y restaurar estado anterior.
|
||||
4. **Si hay confirmación**: Hacer cambios persistentes.
|
||||
|
||||
## 2. Gestión de Secretos (Bóveda Operativa)
|
||||
|
||||
### 2.1 Prohibición de Texto Plano
|
||||
La Inteligencia Artificial operante tiene **expresamente prohibido** solicitar contraseñas administrativas, tokens o claves privadas al operador, así como también plasmarlas en logs, comandos literales temporales o en la bitácora.
|
||||
|
||||
### 2.2 Consumo Efímero de Bóveda
|
||||
Ante requerimientos de escalada de privilegios (`sudo`, `root`, `sshpass`), la IA accederá de forma autónoma a la bóveda encriptada:
|
||||
|
||||
- **Ubicación**: `scripts/.agent_secrets.json`
|
||||
- **Interfaz**: `ruby scripts/secret_box.rb decrypt <payload>`
|
||||
- **Cifrado**: AES-256-GCM con `.master.key` local (ignorada en Git).
|
||||
- **Ejecución**: Exclusivamente inyectando subshells para enmascarar la variable en los árboles de procesos:
|
||||
```bash
|
||||
CMD_PASS=$(ruby scripts/secret_box.rb decrypt "$PAYLOAD")
|
||||
sshpass -p "$CMD_PASS" ssh ...
|
||||
```
|
||||
|
||||
### 2.3 Archivos Protegidos (`.gitignore`)
|
||||
Los siguientes artefactos **nunca** deben ser rastreados por Git:
|
||||
- `.master.key` (clave maestra de la bóveda)
|
||||
- `scripts/.agent_secrets.json` (payloads cifrados)
|
||||
- `*.key` (claves privadas)
|
||||
- `tmp/` (artefactos transitorios de la IA)
|
||||
@@ -0,0 +1,37 @@
|
||||
# 04 - Hebra: Iconografía
|
||||
|
||||
> Referencia canónica: [`adn/00_indice.md`](00_indice.md)
|
||||
|
||||
Esta hebra define la taxonomía visual utilizada en las bitácoras para optimizar el escaneo visual. Se implementa una estricta separación de responsabilidades.
|
||||
|
||||
## 1. Iconos de Estado (Columna Tema)
|
||||
|
||||
Representan el **estado de ciclo de vida** de una tarea o hito principal.
|
||||
|
||||
| Icono | Significado | Descripción |
|
||||
| :---: | :--- | :--- |
|
||||
| ✅ | **Completado** | Tarea general finalizada exitosamente. |
|
||||
| ⏳ | **En Proceso** | Tarea en ejecución o pendiente de cierre. |
|
||||
| ⚠️ | **Fallo / Alerta** | Tarea fallida, cancelada o riesgo detectado. |
|
||||
| ❌ | **Error Crítico** | Fallo irrecuperable o bloqueo definitivo. |
|
||||
| 📍 | **Definido** | Pendiente en la cola de planificación (Control de Gestión). |
|
||||
| ➡️ | **Migrado** | Tarea transferida a la bitácora del día siguiente (Rollover). |
|
||||
|
||||
## 2. Iconos Semánticos (Prefijos y Viñetas de Hitos)
|
||||
|
||||
Representan la **naturaleza técnica** de la acción dentro de las tablas cronológicas.
|
||||
|
||||
| Icono | Orientación | Ejemplos de Uso |
|
||||
| :---: | :--- | :--- |
|
||||
| 🟢 | **Operativo** | Servicio funcionando, confirmación de red, OK. |
|
||||
| 🔧 | **Configuración** | Mantenimiento, ajuste de parámetros, cambios de código. |
|
||||
| 🧪 | **Prueba** | Validación técnica, ensayos, simulaciones, logs. |
|
||||
| 🐛 | **Bug / Fix** | Errores de software, excepciones, correcciones. |
|
||||
| 🧹 | **Limpieza** | Refactorización, purga, reubicación de archivos. |
|
||||
| 💾 | **Datos** | Backups, volcados, sincronización de discos, almacenamiento. |
|
||||
| 🚀 | **Despliegue** | Lanzamiento masivo, ejecución grande, puesta en marcha. |
|
||||
| 👁️ | **Análisis** | Revisión humana, planificación, auditoría, brainstorming. |
|
||||
| 🧠 | **Estructura** | Conceptualización de arquitectura, metodologías, ideas críticas. |
|
||||
| 📝 | **Documentación** | Actualización del ADN, manuales, reportes, logs manuales. |
|
||||
| 🧬 | **ADN** | Refactorización o evolución de las hebras del ADN. |
|
||||
| 🛡️ | **Seguridad** | Hardening, auditoría de accesos, bóveda de secretos. |
|
||||
@@ -0,0 +1,46 @@
|
||||
# 05 - Hebra: Directivas de la Inteligencia Artificial
|
||||
|
||||
> Referencia canónica: [`adn/00_indice.md`](00_indice.md)
|
||||
>
|
||||
> ⚠️ **FUENTE ÚNICA DE VERDAD.** Este archivo es la referencia canónica y exclusiva de las premisas de trabajo de la IA. Las bitácoras diarias **no duplican** estas reglas, solo referencian esta hebra.
|
||||
|
||||
## Premisas de Trabajo
|
||||
|
||||
### 1. Orden Inverso
|
||||
Lo más nuevo SIEMPRE arriba (Tabla Resumen, Secciones de Nodo e Hitos).
|
||||
|
||||
### 2. Narrativa y Estructura Jerárquica
|
||||
- **Resumen (Arriba)**: Narrativa integral y sintética, SIN TÍTULOS NI ESTADOS en el texto.
|
||||
- **Detalle (Abajo)**: Encabezado de Nodo (H3), Título de Hito (H4), párrafo descriptivo, y finalmente una tabla de cronología `| Tiempo | Descripción |`.
|
||||
|
||||
### 3. Formato de Tiempo
|
||||
Usar formato `[Icono] HH:MM` (ej. `✅ 23:26`). ESTRICTAMENTE PROHIBIDO usar el sufijo "hs" o " hs".
|
||||
|
||||
### 4. Estados y Triggers
|
||||
Sincronización en cascada entre secciones de la bitácora. Ver hebra [`02_bitacora.md`](02_bitacora.md), sección "Triggers".
|
||||
|
||||
### 5. Iconografía
|
||||
Título Principal = Estado (ej. ✅, ⏳, ➡️). Eventos cronológicos = Emojis semánticos al inicio de la celda de tiempo. Ver hebra [`04_iconografia.md`](04_iconografia.md).
|
||||
|
||||
### 6. Armonía
|
||||
Consultar y seguir siempre las normativas vivas del ADN. Ver hebra [`06_gobernanza.md`](06_gobernanza.md).
|
||||
|
||||
### 7. Auto-Registro IA
|
||||
Las acciones autónomas de la IA (ej. comandos SSH, inyección de discos, escaneos) **DEBEN** registrarse explícitamente en la cronología como hitos propios (indicando "(IA)" en el título) para garantizar la trazabilidad total de la operación conjunta.
|
||||
|
||||
### 8. Auto-Documentación IA
|
||||
La IA debe mantener esta hebra de forma autónoma, asegurando que refleje las reglas y directrices más actuales para su operación y la del operador humano.
|
||||
|
||||
### 9. Métricas Híbridas (Telemetría)
|
||||
**OBLIGATORIO.** Cada hito o bloque de sincronización (SINC) debe registrar el esfuerzo:
|
||||
- **En proceso**: Usar formato `[Físico/Remoto: Iniciado HH:MM]`.
|
||||
- **Finalizado**: Usar formato de duración `[Físico/Remoto: H:MM hs]`.
|
||||
|
||||
### 10. Secretos Operativos
|
||||
La IA **NUNCA** pedirá ni escribirá contraseñas en texto plano. Se consumirán de forma efímera mediante la bóveda. Ver hebra [`03_seguridad.md`](03_seguridad.md).
|
||||
|
||||
### 11. Gestión de Artefactos y Temporales (Workspace Bounds)
|
||||
Cualquier script efímero (Python, Bash, PowerShell) creado por la IA para asistir en configuraciones, DEBE guardarse exclusivamente en el directorio local `tmp/` del repositorio del proyecto. Está **ESTRICTAMENTE PROHIBIDO** el uso de carpetas globales del OS anfitrión (como `/tmp`).
|
||||
|
||||
### 12. Principio Bitácora-First (Anticipación)
|
||||
Todo hito mayor, prueba de concepto técnica o interacción de red iniciada por la IA debe ser documentado en un borrador `⏳` dentro de la Bitácora **ANTES** de ejecutar los comandos en la Terminal. Una vez que la validación finalice, actualizar dicha fila al estado `✅` o `❌`.
|
||||
@@ -0,0 +1,55 @@
|
||||
# 06 - Hebra: Gobernanza y Armonía
|
||||
|
||||
> Referencia canónica: [`adn/00_indice.md`](00_indice.md)
|
||||
|
||||
Esta hebra establece las reglas fundamentales de idioma, nomenclatura, coherencia documental, resguardo y evolución del proyecto.
|
||||
|
||||
## 1. Idioma y Nomenclatura
|
||||
|
||||
- **Directiva**: **Todo el contenido debe estar en español.**
|
||||
- **Nomenclatura de Nodos**: Estrictamente **minúsculas** en nombres de archivo y referencias (ej: `srv-ns8`, `pc-dasu0`, `srvv-maurik`).
|
||||
- **Alcance**:
|
||||
- Interacciones con el asistente (chat).
|
||||
- Documentación (archivos `.md`).
|
||||
- Mensajes de Commit (Git).
|
||||
- Comentarios en el código (scripts, configs).
|
||||
|
||||
## 2. Formato de Documentación
|
||||
|
||||
- **Estilo**: Markdown estándar.
|
||||
- **Ubicación**: Todo documento clave del ADN debe residir en el directorio `adn/`.
|
||||
|
||||
## 3. Armonía Integral 🧬
|
||||
|
||||
El principio rector del proyecto. Así como las hebras del ADN biológico se entrelazan para codificar un organismo, las piezas de este proyecto están **interconectadas bidireccionalmente**:
|
||||
|
||||
- **ADN ↔ Bitácoras**: Las hebras definen cómo se escriben; las mejores prácticas emergentes en bitácora se formalizan como nuevas reglas.
|
||||
- **ADN ↔ Nodos**: La ontología describe los nodos; los cambios de estado de un nodo se reflejan en su ficha y en la bitácora.
|
||||
- **Bitácoras ↔ Nodos**: Los hitos del día alimentan y actualizan la ficha del nodo afectado.
|
||||
|
||||
### Regla de Propagación
|
||||
> Si un dato cambia en un sitio, **debe propagarse** a todos los demás. Esta responsabilidad recae tanto sobre el operador como sobre la IA. Al detectar una inconsistencia, es **prioritario resolverla antes de avanzar**.
|
||||
|
||||
### Consistencia
|
||||
No deben existir discrepancias entre diferentes hebras. Si se actualiza una definición en `01_ontologia.md`, debe reflejarse en los protocolos y bitácoras correspondientes.
|
||||
|
||||
### Trazabilidad
|
||||
Los IDs y estados deben ser consistentes a través del tiempo. Los hipervínculos bidireccionales entre bitácoras (`➡️ [Viene del...]` / `➡️ [Migrado al...]`) son obligatorios.
|
||||
|
||||
## 4. Resguardo del Repositorio (Safeguard)
|
||||
|
||||
- **Objetivo**: Asegurar la integridad y el historial de cambios del proyecto.
|
||||
- **Directiva**:
|
||||
- **Frecuencia**: Al finalizar una tarea significativa o conjunto de tareas relacionadas (hito).
|
||||
- **Alcance**: Todo cambio en `adn/`, `servicios/config`, `scripts/` y documentación `docs/`.
|
||||
- **Formato Mensaje**: `[Categoría] Descripción breve del cambio`.
|
||||
|
||||
## 5. Evolución Progresiva (Mejora Continua)
|
||||
|
||||
- **Principio**: El ADN no es estático; evoluciona a partir de los descubrimientos y buenas prácticas emergentes de la operación diaria.
|
||||
- **Flujo de Vida de una Mejora**:
|
||||
1. **Incubación**: Una técnica experimental se prueba en la trinchera (bitácoras, scripts, reportes).
|
||||
2. **Identificación**: Se reconoce el valor sistémico y repetible de la técnica.
|
||||
3. **Formalización**: Se integra como regla oficial en la hebra correspondiente del ADN.
|
||||
4. **Propagación**: A partir de su formalización, la regla es de cumplimiento obligatorio para el trabajo futuro.
|
||||
- **Ejemplo Fundacional**: Las *Premisas de Trabajo (IA)* nacieron como un experimento en el footer de las bitácoras y evolucionaron orgánicamente hasta convertirse en una **hebra canónica** (`05_ia.md`).
|
||||
+2
-21
@@ -79,7 +79,7 @@
|
||||
| Tiempo | Descripción |
|
||||
| :--- | :--- |
|
||||
| ✅ 20:25 | Resguardo del Repositorio de Trabajo. Ante la culminación de los hitos críticos del día, la IA procede a realizar el commit y push final al repositorio Git. Se consolidan todos los cambios en bitácoras, protocolos de ADN y scripts de automatización, garantizando la persistencia de la inteligencia operativa y los secretos encriptados. |
|
||||
| ⏳ 18:20 | Recuperación de Resguardo (VZDump DB01). En aplicación estricta del protocolo de anticipación, la IA pre-declara la inyección manual del comando `Stop-Computer` vía SSH sobre `sql-dasuten` para evadir el bloqueo del Guest Agent, seguido de la re-ejecución nativa del comando de backup offline directo `vzdump 101 --mode stop` desde el hipervisor. |
|
||||
| ➡️ 18:20 | Recuperación de Resguardo (VZDump DB01). En aplicación estricta del protocolo de anticipación, la IA pre-declara la inyección manual del comando `Stop-Computer` vía SSH sobre `sql-dasuten` para evadir el bloqueo del Guest Agent, seguido de la re-ejecución nativa del comando de backup offline directo `vzdump 101 --mode stop` desde el hipervisor. **[Migrado al 27/02](2026-02-27.md)** debido a que requirió resolución manual vía GUI tras timeout interactivo. |
|
||||
| ⚠️ 17:15 | Resguardo Integral Offline (Fallo Parcial). El volcado VZDump finalizó exitosamente para el nodo 100 (`dc-dasuten`), tomando 8 minutos para escribir ~4.26GB (ZStd). Sin embargo, la tarea falló (Exit 255) al iterar sobre el nodo 101 (`sql-dasuten`) tras exceder el timeout de 600 segundos; Proxmox no logró forzar el ACPI shutdown debido a la ausencia del QEMU Guest Agent. |
|
||||
| ✅ 17:28 | Creación de Usuario Administrativo en Proxmox (PVE). El operador requiere acceso a la consola del hipervisor (`srv-dasu`). La IA, en cumplimiento de la directiva de seguridad, asume el control consumiendo la llave rsa desde la bóveda y despacha remtamente los comandos de `pveum` para provisionar el usuario nativo `rmonla@pve` con su clave definida y mapearle el rol irrestricto `Administrator`. |
|
||||
| 👁️ 16:50 | Validación Exhaustiva de Conectividad SSH. Culmina el proceso de tunneling. Se comprueba exitosamente el login puro sobre `dc-dasuten` y `sql-dasuten` utilizando usuario de dominio y extracción del output `@@VERSION` de SQL Server vía SSH. |
|
||||
@@ -90,23 +90,4 @@
|
||||
| 👁️ 09:00 | Inicio de Sincronización Presencial (09:00 a 15:30). El operador asume guardia física en el nodo central. Inicia la jornada realizando el traspaso transversal de estado, rollover de bitácora y control de trazabilidad de métricas del Dashboard P2601. Se aguarda verificación de que el setup desatendido de SQL Server finalizó con éxito durante la noche. |
|
||||
|
||||
---
|
||||
<!-- 🤖 PREMISAS DE TRABAJO (IA) -->
|
||||
<!--
|
||||
1. ORDEN INVERSO: Lo más nuevo SIEMPRE arriba (Tabla Resumen, Secciones de Nodo e Hitos).
|
||||
2. NARRATIVA Y ESTRUCTURA JERÁRQUICA:
|
||||
- Resumen (Arriba): Narrativa integral y sintética, SIN TÍTULOS NI ESTADOS en el texto.
|
||||
- Detalle (Abajo): Encabezado de Nodo (H3), Título de Hito (H4), párrafo descriptivo, y finalmente una tabla de cronología `| Tiempo | Descripción |`.
|
||||
3. FORMATO DE TIEMPO: Usar formato `[Icono] HH:MM` (ej. `✅ 23:26`). ESTRICTAMENTE PROHIBIDO usar el sufijo "hs" o " hs".
|
||||
4. ESTADOS Y TRIGGERS (Sincronización en Cascada):
|
||||
- **T1 (Avance)**: Agregar un Hito/Cronología actualiza el DETALLE de la tabla 'En Proceso'.
|
||||
- **T2 (Cierre)**: Cerrar el último `⏳` de un Nodo dispara la creación de su Resumen Integral.
|
||||
- **T3 (Rollover)**: Al cambiar de día (archivo), heredar estas Premisas IA, migrar tareas activas al nuevo día, y marcar las antiguas como `➡️` (Migradas). Inyectar hipervínculos bidireccionales de trazabilidad transdiaria.
|
||||
5. ICONOGRAFÍA: Título Principal = [Estado] (ej. ✅, ⏳, ➡️). Eventos cronológicos = Emojis semánticos al inicio de la celda de tiempo.
|
||||
6. ARMONÍA: Consultar y seguir siempre las normativas vivas del ADN (`adn/02_protocolo.md`).
|
||||
7. AUTO-REGISTRO IA: Las acciones autónomas de la IA (ej. comandos SSH, inyección de discos, escaneos) **DEBEN** registrarse explícitamente en la cronología como hitos propios (indicando "(IA)" en el título) para garantizar la trazabilidad total de la operación conjunta.
|
||||
8. AUTO-DOCUMENTACIÓN IA: La IA debe generar y mantener esta sección de "PREMISAS DE TRABAJO (IA)" de forma autónoma, asegurando que refleje las reglas y directrices más actuales para su operación y la del operador humano.
|
||||
9. MÉTRICAS HÍBRIDAS (TELEMETRÍA): Cuando un hito del proyecto consuma tiempo considerable (especialmente si se refleja en el dashboard web), registrar el esfuerzo usando las etiquetas `[Físico: X hs]` y/o `[Remoto: Y hs]` dentro de las filas del cronograma o en su resumen. La IA escaneará sintácticamente estas métricas para graficarlas en la aplicación web.
|
||||
10. SECRETOS OPERATIVOS: La IA **NUNCA** pedirá ni escribirá contraseñas en texto plano. Se consumirán de forma efímera leyendo `scripts/.agent_secrets.json` mediante `ruby scripts/secret_box.rb decrypt <payload>`, usándolo silenciosamente en un subshell para comandos sudo/ssh.
|
||||
11. GESTION DE ARTEFACTOS Y TEMPORALES (WORKDIR BOUNDS): Cualquier script efímero (Python, Bash, Powershell) creado por la IA para asistir en configuraciones, DEBE de ser guardado exclusivamente en el directorio local del repositorio del proyecto (ej: `tmp/` o `scripts/tmp/`, ya ignorados en Git), ESTANDO ESTRICTAMENTE PROHIBIDO el uso de carpetas globales del OS anfitrión (como `/tmp`).
|
||||
12. PRINCIPIO BITÁCORA-FIRST (ANTICIPACIÓN): Todo hito mayor, prueba de concepto técnica o interacción de red iniciada por la IA debe ser documentado en un borrador `⏳` dentro de la Bitácora **ANTES** de ejecutar los comandos en la Terminal (e.g., inyectar fila indicando el inicio del test, y reescribirla a `✅` cuando finalice), garantizando predictibilidad y control pleno del operador.
|
||||
-->
|
||||
<!-- 🤖 PREMISAS DE TRABAJO (IA): Fuente de Verdad → adn/05_ia.md -->
|
||||
|
||||
@@ -0,0 +1,43 @@
|
||||
# Bitácora de Operaciones - 27/02/2026
|
||||
|
||||
## Control de Gestión
|
||||
|
||||
### 🚩 Pendientes
|
||||
| ID | NODO | DETALLE |
|
||||
| :--- | :--- | :--- |
|
||||
| [📍 - P02 - **Sistema DASUTEN**](#sql-dasuten) | sql-dasuten | ➡️ **[Viene del 26/02](2026-02-26.md)**<br>Despliegue e instalación del software del sistema DASUTEN en la VM con la base de datos operativa. |
|
||||
| [📍 - S02 - **Hardenización SSH**](#sql-dasuten) | sql-dasuten | Hardening de OpenSSH Server (deshabilitación de password, llaves asimétricas con passphrases y auditoría). |
|
||||
|
||||
### ⏳ En Proceso
|
||||
| ID | NODO | DETALLE |
|
||||
| :--- | :--- | :--- |
|
||||
| | | |
|
||||
|
||||
### 📝 Resumen de Actividades
|
||||
| NODO | RESUMEN INTEGRAL |
|
||||
| :--- | :--- |
|
||||
| | |
|
||||
|
||||
---
|
||||
|
||||
## 📂 Actividades Detalladas
|
||||
|
||||
### sql-dasuten
|
||||
|
||||
#### ✅ - DB01.3 - Finalización de Resguardo Integral (Manual)
|
||||
🛡️ Confirmación de cierre del backup de la VM 101 que había quedado interactuando en bloqueos de script.
|
||||
|
||||
| Tiempo | Descripción |
|
||||
| :--- | :--- |
|
||||
| ✅ 16:15 | Finalización de VZDump Manual (GUI). ➡️ **[Viene del 26/02](2026-02-26.md)**. El operador informa el inicio de la sesión remota y notifica que el backup offline (VZDump) programado mediante scripts interactivos no logró concretarse (timeouts de terminal). Se ejecutó la instrucción directamente desde la interfaz gráfica (GUI) de Proxmox concluyendo exitosamente el resguardo del nodo `sql-dasuten`. `[Remoto: 0:13 hs]` |
|
||||
|
||||
### Operaciones Centrales
|
||||
|
||||
#### 👁️ - SINC02 - Sincronización de Inicio de Jornada
|
||||
| Tiempo | Descripción |
|
||||
| :--- | :--- |
|
||||
| ✅ 17:40 | (IA) 🧬 Refactorización del ADN a Arquitectura Multi-Hebra. El operador aprobó el plan de descomposición del protocolo monolítico (`02_protocolo.md`) en 6 hebras temáticas independientes, integrando el principio de Armonía Integral como eje transversal. Se extraen las Premisas IA del footer de las bitácoras hacia una hebra canónica única (`05_ia.md`). Se eliminan archivos obsoletos y se reemplazan los footers duplicados por referencias canónicas. `[Remoto: 0:20 hs]` |
|
||||
| 👁️ 16:13 | Inicio de Sincronización Remota. El operador inicia las tareas en modo remoto, reportando la culminación exitosa del backup de la DB a través de la GUI de Proxmox. Se asume el control del entorno para proceder con las siguientes tareas del backlog (Deploy del sistema DASUTEN y/u optimizaciones de seguridad). `[Remoto: Iniciado 16:13]` |
|
||||
|
||||
---
|
||||
<!-- 🤖 PREMISAS DE TRABAJO (IA): Fuente de Verdad → adn/05_ia.md -->
|
||||
Reference in New Issue
Block a user