egutierrez
32fc008cae
Infraestructura de documentación operativa y de decisiones: - docs/adr/ — Architecture Decision Records. Incluye plantilla y ADR 0001 documentando el experimento y retirada de GitButler. - docs/diary/ — diario de avances con un archivo por día. Primera entrada 2026-04-24.md retrocubriendo esta sesión (conectar aurgi-pc, dashboard fn_monitoring, funciones systemd locales, ADR GitButler, regla KISS). - CHANGELOG.md — formato Keep a Changelog para cambios cara a usuario/agentes. Sección 2026-04-24 con Added/Changed/Fixed/Removed. - .claude/commands/entrada_diario.md — slash command para añadir entradas al diario con formato consistente. Separación: diary = contexto operativo diario CHANGELOG = qué cambió en el código ADR = por qué se decidió algo rules = reglas operativas del agente Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.2 KiB
1.2 KiB
Diario — fn_registry
Registro diario de avances: qué se trabajó, qué se completó, qué queda pendiente.
Un archivo por día con nombre YYYY-MM-DD.md. Dentro, una sección por bloque de trabajo con timestamp.
Cuándo usar cada tipo de registro
| Archivo | Para qué | Granularidad |
|---|---|---|
docs/diary/YYYY-MM-DD.md |
Qué hicimos hoy. Contexto operativo, decisiones rápidas, cosas pendientes para mañana. | Diario |
CHANGELOG.md (raíz) |
Qué cambió en el código cara al usuario/agentes. Add/Change/Fix/Remove. | Por release o por hito |
docs/adr/NNNN-*.md |
Por qué tomamos una decisión arquitectural. | Ocasional |
Reglas:
- Nunca reescribir entradas antiguas — si algo cambia, añadir una nota nueva.
- Preferir bullet points breves a párrafos largos.
- Enlazar a commits, issues, ADRs o funciones del registry cuando aplique.
Añadir una entrada
Usar el comando /entrada_diario <descripción>. Crea el archivo del día si no existe y añade una sección con hora actual.
Formato de una entrada
# YYYY-MM-DD
## HH:MM — Título corto
Contexto en 1-3 líneas.
- Hecho: viñeta
- Hecho: viñeta
- Pendiente: viñeta
Referencias: commit SHA, ADR #NNNN, issue #N