dtic-DIIAA/adn/02_protocolo.md

# 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**: Tabla detallada (Tema | Hitos).
- **Nomenclatura del Tema**: `[Estado] [Categoría] - [ID] - **[Nombre Tarea]**` (ej. `✅ 💾 - A09 - **dtic-BKPs C4**`).
- **Nomenclatura de Hitos**: `⏱️ **Cronología:**` seguido de viñetas con formato `- [Icono Semántico] **[Hora] hs**: [Descripción]` (ej. `- 🚀 **09:13 hs**: Reanudación del ciclo...`).
- **Estilo (Hitos)**: **Narrativa Generosa y Técnica**. Explicando los "qué" y "por qué".
- **Estados (Tema)**: Estrictamente delimitados para trazabilidad (✅ Cerrado, ⏳ En Proceso, ⚠️ Fallo).
- **Categoría (Tema)**: Uso de taxonomía semántica (🔧, 🧹, 📝, 🧪, etc) acoplada al Estado para dar catalogación de lectura rápida.
- **Semántica (Hitos)**: Uso libre de iconos descriptivos (🐛, 💾, 👁️, 🚀) integrados al nivel de la viñeta de tiempo para dar contexto visual detallado a cada evento.

### 4.3 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, la columna de Tema implementa un Sistema Visual Dual (`[Estado] [Categoría]`):

### 1. Icono de Estado (Obligatorio)
| 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). |

### 2. Iconos Semánticos (Categoría del Tema & Hitos Internos)
| 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.