Sergio
97ceb72411
645 líneas. Los ADR entran porque en este repo SON documentos vivos, no registros inmutables: el 0013 tiene 5 commits, el 0009 dos. Eso se comprobó antes de decidir, no se asumió por convención general. EXCLUIDOS por ser REGISTRO o generado: docs/evidencia/ (6), el HANDOFF de la noche de KDE (1) y docs/state/ (24, se regenera solo). Reescribir un comando dentro de una evidencia la falsifica. Y el ADR 0016 se excluye de todo barrido, con un aviso adentro para el próximo que barra: habla SOBRE el renombre, así que necesita seguir diciendo 'hammer'. El barrido se lo llevó puesto y lo dejó titulado 'Renombre del sistema: takana → takana'; revertido. Congelados, verificados uno por uno con controles: /opt/hammer, /var/lib/hammer, /usr/bin/hammer, /mnt/vvv/hammer, la URL de gitea, hammer-farm.service, hammer-live-install.sh, BRIEFING-hammer.md, hammerd, hammer-recover y HAMMER_LIVE.
39 lines
1.6 KiB
Markdown
39 lines
1.6 KiB
Markdown
# ADR 0006 — Commits fijados, no `HEAD` vivo
|
|
|
|
- **Estado:** aceptada
|
|
- **Fecha:** 2026-06-06
|
|
|
|
## Contexto
|
|
|
|
La idea original habla de "repositorios vivos" apuntando al `HEAD` de los upstreams. Romántico,
|
|
pero `HEAD` se rompe a diario y destruye el determinismo que justifica todo el laboratorio
|
|
funcional. Sin entrada estable no hay hash estable, no hay caché fiable, y no hay `.swm`
|
|
verificable.
|
|
|
|
## Decisión
|
|
|
|
El lab compila **siempre contra commits fijados** (un lockfile, `pins.toml`). "Repositorio
|
|
vivo" significa **rastreo automatizado del upstream con snapshots fijados**, no `HEAD` ciego.
|
|
|
|
## Razones
|
|
|
|
- **Reproducibilidad:** entrada idéntica ⇒ hash idéntico ⇒ salida idéntica
|
|
([SDD 02](../02-build-lab.md), [SDD 09](../09-trust-model.md)).
|
|
- **Avance ordenado del grafo:** al subir un pin, sólo cambian ese nodo y sus dependientes;
|
|
sabes exactamente qué commit causó qué fallo.
|
|
- **`.swm` verificable:** dos máquinas con el mismo pin+patch producen el mismo binario; eso es
|
|
lo que permite "verificar, no confiar".
|
|
|
|
## Mecanismo de "vivo"
|
|
|
|
- `pins.toml` mapea `nombre → commit` por upstream.
|
|
- `takana update [<pkg>]` consulta el upstream, propone subir el pin al nuevo commit, y
|
|
reconstruye sólo lo afectado. El humano (o la IA) decide cuándo avanzar.
|
|
- Análogo al `flake.lock` de Nix, pero imperativo y bajo tu control.
|
|
|
|
## Consecuencias
|
|
|
|
- No hay sorpresas por `HEAD` cambiando bajo tus pies.
|
|
- Mantener los pins al día es una acción explícita (deseable: lo controlas tú/la IA).
|
|
- El pin (commit) forma parte del `artifact_hash`; cambiarlo invalida la caché de ese nodo.
|