Sergio
2546f5cdf8
`kubectl-neat` y `kubectl-tree` llevaban meses sellados y **no se podían invocar**: los dos son subcomandos que despacha `kubectl`, y `kubectl` no estaba en el catálogo. Probado, no supuesto — `kubectl plugin list` con los dos artefactos en el PATH los lista a los dos. `kubectl version --client -o json` contesta con todos los campos poblados (gitVersion v1.37.0, gitCommit, gitTreeState clean, goVersion go1.26.4). REPRODUCE bit a bit. Los `-X` del ldflags no son adorno: sin ellos `kubectl version` dice `v0.0.0-master+$Format:%H$`, y un cliente de k8s NEGOCIA por versión — varios comandos avisan de desfase cliente/servidor comparando exactamente esos campos. Los nombres son los de `hack/lib/version.sh` de upstream, para no inventar un esquema paralelo. **Uno de esos campos era una trampa de reproducibilidad**: `buildDate`, que upstream llena con `date -u` ⇒ dos builds del mismo fuente darían binarios distintos (la familia del sello de nftables y del `BUILD_ID` de valkey). Se resuelve como lo resuelve upstream, leyendo `SOURCE_DATE_EPOCH`, que el lab exporta con valor FIJO. Sale `1970-01-01T00:00:01Z` — feo y CONSTANTE, que es lo que importa. `gitCommit` va pineado a mano porque el tarball no trae `.git`. ⚠ El tag `v1.37.0` es ANOTADO: el `git/ref` devuelve el sha del OBJETO TAG, no el del commit, y quedarse con ése habría horneado un sha que no es ningún commit. Hay que resolver tag → commit. ⚠ **Y un hallazgo lateral que dejo anotado en la receta porque no es de esta receta:** el árbol de k8s trae su propio `vendor/` curado, pero el lab corre `go mod vendor` en el FETCH siempre que haya `go.mod`, sin mirar si el proyecto ya traía uno (`vendor_go_deps`, incondicional — se ve en el log: `go: downloading …` ANTES de `configure`). O sea que se compila el vendor REGENERADO, no el de upstream. Acá salió bien y reproduce, pero es la misma figura que el clobber del `vendor/` de Cargo, que sí necesitó un campo de receta para resolverse.
Documentación de diseño de takana
Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.
Software Design Documents (SDD)
| # | Documento | Qué cubre |
|---|---|---|
| 00 | Visión y filosofía | Por qué existe, qué problema resuelve, la actitud de ingeniería |
| 01 | Arquitectura general | El modelo de dos mundos, componentes, flujo de datos |
| 02 | El laboratorio de build | Sandbox, zig cc, recetas, CAS, grafo de dependencias |
| 03 | Hidratación y store | Store content-addressed, hardlinks a FHS, patchelf, rollback |
| 04 | Overlay de experimentación | overlayfs en caliente, try/commit/discard |
| 05 | Diario de mutaciones | fanotify, log append-only, config-sin-ser-declarativa |
| 06 | Formato .swm |
Manifiesto de mutación compartible, esquema, firma |
| 07 | Bus de init y de agente | /run/init.control, /run/agent.sock, protocolo |
| 08 | Integración de la IA | El bucle agéntico, seguridad, intención → .swm |
| 09 | Modelo de confianza | Reproducibilidad, verificar-no-confiar, log de transparencia |
| 10 | Roadmap | Fases, MVP, primer entregable |
| 11 | Bootstrap from-scratch | Track posterior: Stage 0/1/2, auto-alojamiento, semilla pinned |
| 12 | arje como init real del Stage 1 |
Contrato de runtime: seed card, hammerd supervisado, CRASHED real |
| 16 | harkaq: la jaula de takana | Landlock+seccomp sobre el bwrap actual; política = clausura; evidencia negativa de hermeticidad |
| 26 | atuq: el envoltorio Gecko |
Navegador propio como artefacto DERIVADO de firefox (no fork de fuente); la toolchain clang como puerta de PGO/LTO; qué se promete y qué no |
Runbooks (operativos)
| Runbook | Para qué |
|---|---|
| Validar Stage 1 booteando en QEMU | stage0→stage1→initramfs→QEMU; criterios de éxito y troubleshooting |
Architecture Decision Records (ADR)
Decisiones tomadas, con su contexto y consecuencias. Ver adr/.