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] - [ID] - **[Nombre Tarea]** (ej. ✅ - A09 - **dtic-BKPs C4**).
• Nomenclatura de Hitos: La celda inicia con un [Icono Semántico] indicando la categoría (ej. 💾 Ejecución del ciclo masivo...), seguido de la descripción general, y concluye con ⏱️ **Cronología:** y viñetas - [Icono] **[Hora] hs**: [Detalle].
• Estilo (Hitos): Narrativa Generosa y Técnica. Explicando los "qué" y "por qué".
• Estados (Tema): Estrictamente delimitados para trazabilidad (✅ Cerrado, ⏳ En Proceso, ⚠️ Fallo).
• Semántica (Hitos): Uso de una taxonomía visual rica tanto en el prefijo narrativo (categoría de la tarea principal) como en cada viñeta cronológica para otorgar un escaneo visual de lectura ultrarrápida (ej. 🔧, 🧹, 📝, 🧪, 💾).

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, 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).

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.