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/18-wawafs-store-vivo.md

@@ -1,16 +1,16 @@
 # SDD 18 — wawafs: el store como filesystem del sistema vivo (CAS + erofs + fs-verity)
 
-> Origen: la pregunta "¿se podría hostear hammer en un FS de grafos sobre discos en vivo,
+> Origen: la pregunta "¿se podría hostear takana en un FS de grafos sobre discos en vivo,
 > sacándole ventaja a ext4?" (2026-07-17). La respuesta corta: sí, y no hay que escribir un
 > filesystem — la pila composefs (CAS + erofs + overlayfs + fs-verity, mainline) es exactamente
-> esa idea, y el modelo de hammer ya es casi isomorfo a ella. "wawafs" queda como apodo del
+> esa idea, y el modelo de takana ya es casi isomorfo a ella. "wawafs" queda como apodo del
 > frente; no es código de wawa (tawasuyu), es la misma filosofía content-addressed bajada al VFS.
 
 **Estado:** diseño aceptado en conversación; sin implementar. **Fecha:** 2026-07-17.
 
 ## 1. Problema
 
-Hoy la materialización del store al sistema vivo es **por copia u hardlink** (`hammer hydrate
+Hoy la materialización del store al sistema vivo es **por copia u hardlink** (`takana hydrate
 <hash> --into`, ADR 0005). Funciona y escala rebuild-free (el escritorio KDE son 137 artefactos
 hidratados), pero en el **sistema desplegado** (live-disk, metal, generaciones de boot) paga
 tres costos:
@@ -27,7 +27,7 @@ tres costos:
 **Bajar el checkout de userspace al kernel**: hoy `hydrate` es un checkout con copia (git-style:
 store = DAG, hidratar = materializar el árbol); wawafs es el mismo checkout hecho *lazy* por el
 VFS al montar, sin copiar un byte. ext4 queda abajo como capa de bloques tonta; la "evolución
-sobre ext4" es la capa content-addressed encima — la arquitectura que hammer ya tiene en
+sobre ext4" es la capa content-addressed encima — la arquitectura que takana ya tiene en
 userspace, un nivel más abajo.
 
 ## 3. Las capas
@@ -61,7 +61,7 @@ Propiedades que caen solas:
   No se toca.
 - **Grano archivo** (nuevo, derivado): el CAS de objetos se indexa por el **digest fs-verity**
   (sha256, es lo que el kernel sabe verificar). Es una capa *derivada* del store: un comando
-  (`hammer fs manifest <ArtifactHash…>`) explota los árboles de N artefactos en objetos por
+  (`takana fs manifest <ArtifactHash…>`) explota los árboles de N artefactos en objetos por
   archivo + genera el manifest erofs de la clausura. blake3 sigue siendo la identidad; el
   digest verity es el enforcement.
 
@@ -103,19 +103,19 @@ un mapa entre ellos).
    (mismo patrón que el re-sellado LANDLOCK/IO_URING de frente-kikin).
 2. **Recetas nuevas**: `erofs-utils` (mkfs.erofs) y `composefs` (mkcomposefs) — C, no existen
    en el catálogo → **worker** (el laptop no construye recetas C).
-3. **Conversor**: `hammer fs manifest` — explotar artefactos en objetos por archivo. El store
+3. **Conversor**: `takana fs manifest` — explotar artefactos en objetos por archivo. El store
    actual (1608 artefactos, directorios por hash) no se toca; el CAS de objetos es derivado y
    regenerable.
 
 ## 8. Fases
 
-- **F0 — spike en QEMU** (sin tocar nada de hammer): rootfs Alpine con composefs-tools de
+- **F0 — spike en QEMU** (sin tocar nada de takana): rootfs Alpine con composefs-tools de
   paquete, `mkcomposefs` sobre UNA clausura hidratada (p.ej. la de KDE), montar, comparar
   `find | sort | b3sum` contra la hidratación por copia. Gate: árboles idénticos + medir
   open-frío y RAM compartida. Decide si el frente existe.
 - **F1 — kernel + recetas**: configs EROFS/FS_VERITY en `linux-generic.toml` (re-sellar en
   worker) + recetas `erofs-utils`/`composefs`. Gate: el kernel propio montando el spike de F0.
-- **F2 — `hammer fs manifest` + generaciones**: manifest erofs por clausura, generación de boot
+- **F2 — `takana fs manifest` + generaciones**: manifest erofs por clausura, generación de boot
   = manifest por hash, arje monta `/usr` de la generación elegida (contrato ADR 0010). Gate:
   bootear en QEMU una generación montada, rollback = elegir otro nodo en el menú.
 - **F3 — sellado verity + live media**: fs-verity en el CAS de objetos; evaluar erofs como