sergio/takana

Mientras se escribían el /etc/shells y el `chsh -s /bin/zsh sergio` había un overlay del FHS
abierto —de un `takana install` sin --prefix sin commitear— y las DOS escrituras cayeron dentro,
aunque no tenían nada que ver con ese paquete ni pasaron por takana (un `cat >` y el chsh de
shadow). Medido con `mount --bind /` no recursivo: en el /etc REAL no había shells y sergio seguía
en /bin/bash, mientras la pantalla mostraba las dos cosas hechas. Un discard o un reinicio lo
borraba y nadie se habría enterado hasta el siguiente login.

Resuelto con commit (5 ficheros promocionados: passwd, passwd-, shells, zsh, zsh-5.9). El
desmontaje perezoso del §5.10 se ganó el sueldo ahí mismo: saltó en /bin y en /usr/bin.

La lección, que es más grande que el caso: `install` sin --prefix NO es un experimento acotado a
ese paquete — cambia la semántica de escritura de la máquina entera hasta que alguien commitea o
descarta, y el overlay no avisa por ningún lado. Como mínimo `takana status` debería salir al
entrar, y el `overlay listo` del install no debería leerse como «terminé». Anotado en SDD 28 §5.11.

diff --git a/docs/28-servidor-de-produccion.md b/docs/28-servidor-de-produccion.md
index 74c4eb9d..6c7fb6ba 100644
--- a/docs/28-servidor-de-produccion.md
+++ b/docs/28-servidor-de-produccion.md
@@ -793,6 +793,29 @@ si aparece.
 setuid root en una distro de artefactos sellados necesita contestar quién lo pone, quién lo
 verifica y qué significa que el hash no lo cubra. Anotado, sin decidir.
 
+⚠⚠ **Y lo que de verdad hay que llevarse de esto: un overlay abierto se traga TODA la máquina.**
+Mientras el `/etc/shells` y el `chsh` se escribían, había un overlay abierto sobre el FHS —de un
+`takana install` sin `--prefix` que alguien había dejado sin commitear— y **las dos escrituras
+cayeron dentro de él**, aunque no tenían nada que ver con ese paquete ni pasaron por takana (fueron
+un `cat >` y el `chsh` de shadow). Medido con un `mount --bind /` no recursivo, que enseña el
+directorio real sin el overlay encima:
+
+| | `/etc` real | lo que se veía |
+|---|---|---|
+| `/etc/shells` | **no existe** | existe |
+| shell de `sergio` | **`/bin/bash`** | `/bin/zsh` |
+
+O sea: el trabajo estaba hecho «según la pantalla» y **un `discard` o un reinicio lo borraba**. Se
+resolvió con `commit` (5 ficheros promocionados: `passwd`, `passwd-`, `shells`, `zsh`, `zsh-5.9`) y
+ahí el desmontaje perezoso del §5.10 se ganó el sueldo: saltó en `/bin` **y** en `/usr/bin`.
+
+⇒ **`install` sin `--prefix` no es «un experimento para ese paquete»: cambia la semántica de
+escritura de la máquina entera hasta que alguien commitea o descarta.** Cualquiera que toque `/etc`
+mientras tanto —otro agente, un servicio, un humano por ssh— escribe en el upper sin enterarse. El
+overlay no avisa: no hay nada en el prompt, ni en `mount` a simple vista, ni un aviso al entrar.
+Como mínimo `takana status` tendría que salir en el arranque de sesión, y `install` debería decir
+**qué queda pendiente** en vez de un `overlay listo` que se lee como «terminé». Anotado.
+
 Consecuencia práctica mientras tanto: **los cambios de shell y de contraseña en esta caja los hace
 root**. Y una observación que sale de mirar esto: no hay `/etc/shadow`; las contraseñas viven en
 `/etc/passwd`, que es legible por todos, con hash DES clásico. No lo toqué — es su propia unidad de