gioser

sergio/takana

> Una distribución Linux construida con un laboratorio funcional y hermético en el > sótano, y una terminal mutable, clásica y anárquica en el piso de arriba — diseñada > desde el suelo para que una IA programadora entienda, modifique y co…

ADR 0016: cerrada la unidad de variables de entorno

Con lo que la medición cambió respecto del plan, los dos controles negativos
del helper, y la distinción que importa: la caída sirve al lector NUEVO; donde
el script exporta, hay que seguir poniendo la vieja porque el lector puede ser
un binario viejo.

24cb5d1f0f1e9cd0aeead846c5e58dd6a09656da · por Sergio · (hace 1 mes) · padre 1c3e18516 · ver el árbol en este commit

Delta semántico

Ninguna definición cambió: el cambio es de texto, documentación o datos.

1 archivos · +33 −16

diff --git a/docs/adr/0016-renombre-takana.md b/docs/adr/0016-renombre-takana.md
index 057a8a6e..c3427dff 100644
--- a/docs/adr/0016-renombre-takana.md
+++ b/docs/adr/0016-renombre-takana.md
@@ -124,22 +124,39 @@ simplemente deja de cosechar. El directorio es lo **último** que se toca, y con
    así que **el baseline `of_tree` del selfhost hay que rehacerlo**. Es efecto de la etapa 4, no de
    un cambio en `hammerd`.
 
-4 bis. **Las variables de entorno son su propia unidad, no la cola de la 4.** Se midió antes de
-   tocarlas y el problema tiene otra forma que la que suponía el plan: no es «la variable
-   `HAMMER=`», son **14** (`HAMMER`, `HAMMER_DIR`, `HAMMER_BIN`, `HAMMER_STORE`, `HAMMER_MUSL`,
-   `HAMMER_MIRROR`, `HAMMER_TZ`, `HAMMER_KEYMAP`, `HAMMER_KERNEL`, `HAMMER_HOSTNAME`, `HAMMER_ZIG`,
-   `HAMMER_WORK`, `HAMMER_ROOTFS`, `HAMMER_LIVE`, `HAMMER_CACHE`), ~260 apariciones en 58 ficheros,
-   **y el binario las lee**: `HAMMER_LAB`, `HAMMER_ZIG`, `HAMMER_WORK`, `HAMMER_ROOTFS`,
-   `HAMMER_MIRROR_KEY`, `HAMMER_LLM_*`.
-
-   ⇒ **Son contrato de usuario, del mismo tipo que un verbo de CLI**, no churn interno: hay knobs
-   del instalador (`HAMMER_TZ`, `HAMMER_KEYMAP`, `HAMMER_HOSTNAME`), el entorno del worker las trae
-   puestas (`mirror-env.sh`) y quedan fuera del repo, en perfiles de shell y units. Un `sed` las
-   rompe en silencio.
-
-   El patrón correcto es el mismo que el resto del renombre: **leer las dos, preferir la nueva**
-   (`TAKANA_X` con caída a `HAMMER_X`), lo que es un cambio de código en Rust más un barrido de
-   scripts. Va como unidad propia, con su decisión.
+4 bis. **Variables de entorno: leen las dos, gana la nueva.** ← *hecho (2026-09-09)*.
+
+   Se midió antes de tocarlas y el problema tenía otra forma que la del plan: no era «la variable
+   `HAMMER=`», eran **14**, ~260 apariciones en 58 ficheros, **y el binario las lee**. Con knobs del
+   instalador entre ellas, el entorno del worker trayéndolas puestas y `mirror-env.sh` exportándolas
+   — todo eso vive **fuera del repo**, en perfiles de shell y units. Un `sed` no falla ruidosamente:
+   la variable deja de aparecer, se toma el default y el build se comporta distinto en silencio.
+
+   - **Rust:** `takana_core::env::{var, var_os}` recibe el nombre **canónico** (`TAKANA_…`) y deriva
+     el viejo cambiando el prefijo. Se le pasa el nuevo a propósito, para que un `grep` del nombre
+     nuevo encuentre todas las lecturas. 5 tests, **con dos controles negativos**: sin ninguna de las
+     dos no hay valor, y un nombre sin prefijo `TAKANA_` no inventa una caída.
+   - Migrados los 17 sitios directos **y los indirectos que el grep de `env::var("HAMMER_…")` no
+     mostraba**: `bases_de_mirror`, las constantes de `kernel_cmd`, `ROOT_ENV` de qorpa y `env_path`
+     de recover. `takana-recover` lleva la caída **inline**: es un mini-binario que se copia a
+     `/usr/sbin` y no vale arrastrarle una dep entera por dos líneas.
+   - **Scripts:** 30 lecturas pasan a `${TAKANA_X:-${HAMMER_X:-default}}`, conservando el nombre
+     **interno** de la variable para no tocar sus 190 usos.
+   - **Donde el script EXPORTA en vez de leer, se ponen las dos** (`mirror-env.sh` y el fragmento
+     in-VM de `takana-bootstrap`). Ahí el lector puede ser un binario **viejo** —un worker sin
+     recompilar, el `/usr/bin/hammer` pinado del baseline— que sólo conoce `HAMMER_*`. La caída
+     sirve al lector nuevo; al viejo hay que seguirle dejando la suya puesta.
+
+   **Verificado con el binario, no sólo con unit tests:** `HAMMER_LAB` sigue surtiendo efecto,
+   `TAKANA_LAB` hace exactamente lo mismo, y con las dos puestas gana `TAKANA_LAB`. 605 tests en
+   verde y `hash zlib` sigue en `b3:dc363f26…`.
+
+   **Cambio de comportamiento que va dicho aparte:** el hostname por defecto de una instalación
+   nueva pasa de `hammer` a `takana` (sólo si no se fija ninguna de las dos variables).
+
+   **No se tocan:** las rutas `/var/lib/hammer` de sistemas ya instalados, el `-volid HAMMER_LIVE`
+   del ISO (es identidad horneada en el medio) y el namespace `HARKAQ_*`, que es de otro subsistema.
+
 5. **Comentarios de recetas** (692). Gratis en hash, ruidoso en diff: va en un commit propio y solo.
 6. **Retirar el alias.** Y recién entonces, si se quiere, el directorio `/mnt/vvv/hammer` — parando
    el cron y reescribiendo el crontab en el mismo movimiento.