[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`).
|
||||
Reference in New Issue
Block a user