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.

docs/joyas-reusables.md

@@ -1,7 +1,7 @@
-# Joyas reusables — trucos de otras distros que encajan en piezas hammer existentes
+# Joyas reusables — trucos de otras distros que encajan en piezas takana existentes
 
 **Fecha:** 2026-07-16 · **Criterio de entrada:** o está probado por alguien serio, o el CAS de
-hammer lo vuelve trivial donde a otros les cuesta. Cada joya nombra la pieza hammer que la
+takana lo vuelve trivial donde a otros les cuesta. Cada joya nombra la pieza takana que la
 recibe — sin pieza receptora, no entra. Complementa `plan-freebsd-aprovechables.md`,
 `plan-variantes-cpu.md` y `plan-jaula-juegos.md`.
 
@@ -11,20 +11,20 @@ recibe — sin pieza receptora, no entra. Complementa `plan-freebsd-aprovechable
 
 **Qué es.** overlayfs+EROFS montando un árbol desde un **object store content-addressed**, con
 fs-verity por objeto. Probado en producción: ostree/bootc/Fedora Atomic lo usan hoy. Está
-diseñado *literalmente* para stores como el de hammer.
+diseñado *literalmente* para stores como el de takana.
 
 **Dónde encaja.** Backend alternativo a la hidratación por hardlink (ADR 0005): en vez de
 materializar N hardlinks, un manifiesto (imagen EROFS chiquita, firmable) monta el árbol
-directo del store. Y se lleva puesto medio **cierre §5** (verity + medida): el hash que hammer
+directo del store. Y se lleva puesto medio **cierre §5** (verity + medida): el hash que takana
 ya usa como identidad se convierte en verificación por-lectura del kernel. Coste kernel: EROFS
 + OVERLAY_FS + FS_VERITY, tres líneas más del contrato `scripts/config`.
 
-**Gate barato:** prototipo de `hammer hydrate --backend composefs` sobre un artefacto sellado;
+**Gate barato:** prototipo de `takana hydrate --backend composefs` sobre un artefacto sellado;
 comparar con hardlink en frío/caliente. No reemplaza ADR 0005 — convive como backend.
 
 **Prototipo MEDIDO (2026-07-17, laptop, composefs 1.0.8, sobre el product-rootfs sellado
 `ba351f1b…`, 262MB / 730 entradas):**
-- `hammer hydrate` (hardlink, ADR 0005): **28ms**. `mkcomposefs --digest-store`: **507ms**
+- `takana hydrate` (hardlink, ADR 0005): **28ms**. `mkcomposefs --digest-store`: **507ms**
   (incluye hashear todo al objects/). El manifiesto `.cfs` resultante: **136KB firmables**
   para el rootfs entero.
 - La comparación de velocidad es la métrica equivocada: ambos son sub-segundo. Lo que
@@ -36,7 +36,7 @@ comparar con hardlink en frío/caliente. No reemplaza ADR 0005 — convive como
 - **Hallazgo de diseño**: el objects/ de composefs se indexa por digest **fs-verity
   (sha256)**, no por `b3:` ⇒ el backend mantiene un objects/ paralelo al store (lo
   construye `mkcomposefs --digest-store` solo, y DEDUPLICA contenido entre artefactos)
-  o hammer guarda el mapa b3→verity al sellar. No es bloqueante, es una tabla.
+  o takana guarda el mapa b3→verity al sellar. No es bloqueante, es una tabla.
 - **Pendiente (pide root)**: montar el `.cfs` (overlayfs+EROFS) y medir lectura
   fría/caliente vs hardlink. El kernel linux-metal re-sellado ya trae EROFS+FS_VERITY.
 
@@ -46,7 +46,7 @@ comparar con hardlink en frío/caliente. No reemplaza ADR 0005 — convive como
 pero rompen la bit-repro de las distros: el perfil varía corrida a corrida, así que
 reproducible-builds y PGO viven peleados.
 
-**El truco hammer.** El perfil se **sella como artefacto**: se genera una vez con carga
+**El truco takana.** El perfil se **sella como artefacto**: se genera una vez con carga
 representativa, entra al store por hash, y la receta lo declara como input. El build vuelve a
 ser función pura `(fuente, perfil) → binario` — PGO bit-reproducible, verificable por la
 granja como cualquier receta. Nadie tiene esto porque nadie trata los perfiles como inputs
@@ -58,12 +58,12 @@ más barata — es la única optimización que se cobra en cada build futuro, no
 ## 3. mimalloc en estático — el talón de musl
 
 **El problema.** El allocator de musl (mallocng) es el punto débil de rendimiento conocido de
-toda distro musl, sobre todo multihilo. Y como hammer linkea estático, cada binario *hornea* su
+toda distro musl, sobre todo multihilo. Y como takana linkea estático, cada binario *hornea* su
 allocator — no hay LD_PRELOAD que valga después.
 
 **El truco (probado: Chimera Linux lo envía system-wide).** Linkear mimalloc en las
 herramientas calientes, per-receta como el patrón `.hammer-zig-ar` (NO framework: re-hashearía
-los sellados). Candidatas: las propias herramientas hammer y todo lo alloc-intensivo de la
+los sellados). Candidatas: las propias herramientas takana y todo lo alloc-intensivo de la
 lista caliente de `plan-variantes-cpu.md` — es la otra mitad de esa moneda: v3 acelera el
 cómputo, mimalloc el malloc.
 
@@ -77,7 +77,7 @@ T1.x) — mismo re-sellado, cero código.
 ## 5. uutils coreutils — de-Alpinización que compila en el LAPTOP
 
 **Probado:** Ubuntu 25.10 los envía como default. Son los coreutils en Rust — y ahí está el
-encaje hammer: **Rust compila en el laptop** (la regla "recetas C ⇒ worker" no aplica). Cada
+encaje takana: **Rust compila en el laptop** (la regla "recetas C ⇒ worker" no aplica). Cada
 utilidad de la clase busybox/coreutils que hoy es deuda declarable puede migrar a una receta
 Rust sin tocar la cola del worker. No es rendimiento: es soberanía de cadena con el compilador
 que ya es el nativo de la casa (ADR 0001).
@@ -101,7 +101,7 @@ que las aplica es trivial y no hace falta traer `ananicy-cpp` entero.
 ## Lo que se miró y NO entra
 
 - **DT_RELR / prelink** — ganancias de arranque para *dinámico*; con link=static es ruido.
-- **ccache/sccache** — la memoización de hammer es por contenido y sellada (H2); un cache
+- **ccache/sccache** — la memoización de takana es por contenido y sellada (H2); un cache
   mutable por-builder la contradice.
 - **ksm en la granja** — dedup de páginas entre VMs efímeras que viven minutos: no amortiza.