Arranque del proyecto hammer (distro AI-nativa: laboratorio funcional en el sótano, terminal mutable clásica arriba, integración de IA programadora). - Workspace Rust (compila, tests verdes): hammer-core, hammer-build, hammer-cli (bin `hammer`), hammerd. - SDDs 00-10 + 6 ADRs en docs/ con toda la arquitectura. - Esqueletos navegables mapeados a las fases del roadmap; Fase 0/1 listas para implementar el sandbox real. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.6 KiB
1.6 KiB
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.
.swmverificable: dos máquinas con el mismo pin+patch producen el mismo binario; eso es lo que permite "verificar, no confiar".
Mecanismo de "vivo"
pins.tomlmapeanombre → commitpor upstream.hammer 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.lockde Nix, pero imperativo y bajo tu control.
Consecuencias
- No hay sorpresas por
HEADcambiando 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.