bootstrap: iniciar bitácora operativa

2026-08-13 00:43:15 -06:00
commit 1ecfb022b1
85 changed files with 7967 additions and 0 deletions
@@ -0,0 +1,41 @@
+# ADR-0001: Git como fuente y Zola como proyección
+
+- **Estado:** aceptada
+- **Fecha:** 2026-08-12
+
+## Contexto
+
+El sitio debe mostrar estado compartido —revisiones, tiempo de tareas y estados— aunque Zola genere archivos estáticos. Guardar ese estado en el navegador no sería compartido ni auditable. Introducir una base de datos en el MVP aumentaría operación, permisos, respaldo y superficie de ataque.
+
+## Decisión
+
+La fuente de verdad será:
+
+- Markdown para entidades legibles;
+- un archivo JSON inmutable por evento;
+- Git para historia y concurrencia;
+- `clusterlog sync` para producir `data/generated/site_state.json`;
+- Zola para consumir la proyección en modo sólo lectura.
+
+La proyección es desechable y nunca se edita a mano.
+
+## Consecuencias positivas
+
+- El repositorio funciona sin un servicio permanente.
+- Toda la historia es inspeccionable con herramientas estándar.
+- Los conflictos se reducen al separar eventos.
+- La publicación puede ser atómica y cacheable.
+- Es posible reconstruir el sitio desde cero.
+
+## Consecuencias negativas
+
+- No hay edición web en tiempo real.
+- Cada escritura necesita sincronización Git.
+- Con volúmenes muy altos de eventos habrá que medir rendimiento y quizá archivar.
+- La coherencia depende de CI, validación y disciplina de ramas.
+
+## Alternativas descartadas
+
+- `localStorage`: no compartido, fácil de perder y no auditable.
+- Archivo JSON central mutable: conflictos frecuentes entre administradores.
+- Base de datos desde el MVP: complejidad desproporcionada para el flujo y volumen iniciales.
@@ -0,0 +1,35 @@
+# ADR-0002: Identidad por llave SSH y prueba mediante commit firmado
+
+- **Estado:** aceptada
+- **Fecha:** 2026-08-12
+
+## Contexto
+
+Los administradores ya usan llaves SSH y los agentes operan en su sesión local. Se busca evitar un sistema adicional de usuarios y contraseñas, pero una llave pública almacenada no basta para probar que una operación la realizó quien posee la privada.
+
+## Decisión
+
+- El registro `data/admins.json` asocia una o más huellas públicas con cada administrador.
+- La CLI resuelve la identidad a partir de una llave local.
+- El contenido conserva `admin_id` y huella para trazabilidad.
+- Las escrituras de producción usan `--commit` para crear un commit Git firmado por SSH.
+- `config/allowed_signers` se genera desde administradores activos.
+- CI y protección de rama verifican firmas y autorización.
+
+## Consecuencias positivas
+
+- Reutiliza la práctica operativa existente.
+- Evita secretos de aplicación dentro del repositorio.
+- La evidencia se integra con el historial Git.
+- Los agentes pueden usar el mismo contrato sin conocer la llave privada.
+
+## Consecuencias negativas
+
+- La configuración inicial de Git/OpenSSH requiere cuidado.
+- Rotación y revocación deben gobernarse explícitamente.
+- Una operación sin `--commit` queda atribuida sólo de manera declarativa.
+- El proveedor Git debe aplicar políticas de firma y rama.
+
+## Regla de interpretación
+
+La huella es identidad declarada; una firma válida y autorizada es evidencia criptográfica. Nunca deben tratarse como equivalentes.
@@ -0,0 +1,31 @@
+# ADR-0003: Revisiones por hash y conjunto capturado
+
+- **Estado:** aceptada
+- **Fecha:** 2026-08-12
+
+## Contexto
+
+Un booleano `revisada` no indica quién revisó ni qué versión vio. Además, añadir un administrador meses después podría reabrir todo el histórico si la política se recalculara siempre contra el equipo actual.
+
+## Decisión
+
+Al crear una memoria:
+
+- se captura el conjunto de revisores requerido;
+- se calcula un hash SHA-256 sobre la versión de contenido;
+- cada revisión registra administrador, huella, fecha y hash;
+- sólo cuentan revisiones cuyo hash coincide con el actual;
+- la cola se completa cuando todos los IDs capturados tienen un evento válido.
+
+## Consecuencias positivas
+
+- Editar una memoria invalida automáticamente el consenso anterior.
+- La cola histórica no cambia al incorporar administradores futuros.
+- Es posible explicar exactamente por qué una entrada está pendiente.
+- Los eventos permanecen inmutables y auditables.
+
+## Consecuencias negativas
+
+- Corregir incluso un detalle menor puede reabrir la revisión.
+- El equipo debe decidir cuándo una corrección editorial merece conservar o repetir consenso; el MVP prioriza seguridad y vuelve a abrir siempre.
+- Bajas de personal requieren una política de excepción explícita, todavía no automatizada.