Files

T

Sergio 97ceb72411 takana etapa 5b: los 59 docs de diseño, runbooks y ADR

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.

2026-09-09 19:25:51 +00:00

1.6 KiB

Raw Permalink Blame History

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

1.6 KiB Raw Permalink Blame History

ADR 0006 — Commits fijados, no HEAD vivo