bootstrap: iniciar bitácora operativa
This commit is contained in:
@@ -0,0 +1,84 @@
|
||||
# Reunión semanal de revisión operativa
|
||||
|
||||
## Objetivo
|
||||
|
||||
Asegurar que el conocimiento de los cambios técnicos se distribuya, que los riesgos pendientes tengan dueño y que manuales, tareas y proyectos reflejen la realidad.
|
||||
|
||||
## Preparación individual
|
||||
|
||||
Antes de la reunión, cada administrador ejecuta:
|
||||
|
||||
```bash
|
||||
clusterlog --root . --json --ssh-key ~/.ssh/id_ed25519.pub review list --mine
|
||||
clusterlog --root . --json --ssh-key ~/.ssh/id_ed25519.pub task list --mine
|
||||
```
|
||||
|
||||
Debe leer las memorias, anotar preguntas y revisar evidencias. Marcar “revisada” significa comprender el cambio y sus implicaciones; no necesariamente aprobar retrospectivamente una decisión.
|
||||
|
||||
## Agenda sugerida
|
||||
|
||||
### 1. Riesgo alto o crítico
|
||||
|
||||
Abrir primero memorias `critical` y `high`:
|
||||
|
||||
- resultado observado;
|
||||
- validaciones;
|
||||
- rollback;
|
||||
- riesgo residual;
|
||||
- seguimiento requerido.
|
||||
|
||||
### 2. Resto de memorias pendientes
|
||||
|
||||
Para cada entrada:
|
||||
|
||||
- confirmar sistemas afectados;
|
||||
- aclarar términos y comandos;
|
||||
- detectar conocimiento reusable;
|
||||
- decidir si debe actualizarse un manual o documento;
|
||||
- crear una tarea cuando exista una acción concreta.
|
||||
|
||||
Cada administrador registra su propia confirmación:
|
||||
|
||||
```bash
|
||||
clusterlog --root . --json --commit --ssh-key ~/.ssh/id_ed25519.pub \
|
||||
review mark MEM-... --note "Revisado en reunión semanal"
|
||||
```
|
||||
|
||||
No debe existir una sola persona marcando por todo el equipo.
|
||||
|
||||
### 3. Tareas abiertas
|
||||
|
||||
Revisar especialmente:
|
||||
|
||||
- bloqueadas;
|
||||
- vencidas o próximas a vencer;
|
||||
- con tiempo real muy superior a la estimación;
|
||||
- con temporizador activo desde una sesión anterior;
|
||||
- sin responsable.
|
||||
|
||||
### 4. Proyectos
|
||||
|
||||
Para proyectos planeados, activos o bloqueados:
|
||||
|
||||
- progreso contra objetivo;
|
||||
- siguiente hito;
|
||||
- dependencia o riesgo;
|
||||
- tareas faltantes;
|
||||
- fecha objetivo.
|
||||
|
||||
### 5. Cierre
|
||||
|
||||
- La cola de memorias debe quedar vacía o con una causa y fecha de seguimiento.
|
||||
- Toda acción debe convertirse en tarea con responsable.
|
||||
- Toda mejora repetible debe actualizar un manual.
|
||||
- Todo cambio de arquitectura debe actualizar Documentación.
|
||||
|
||||
## Evidencia de cierre
|
||||
|
||||
```bash
|
||||
clusterlog --root . sync --check
|
||||
clusterlog --root . validate
|
||||
clusterlog --root . verify commit HEAD
|
||||
```
|
||||
|
||||
El secretario de la reunión puede enlazar los IDs discutidos en la minuta corporativa, sin duplicar contenido sensible.
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user