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.
Delta semántico
Ninguna definición cambió: el cambio es de texto, documentación o datos.
1 archivos · +33 −16
- docs/adr/0016-renombre-takana.md +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.