mudanza: movidos los guiones, la memoria, los secretos y el estado — verificando en DESTINO

Con las decisiones puestas, se movió lo que no dependía de nada más. Cada copia se verificó del lado
del destino, que es lo que el rsync con exit 0 y 1367 artefactos vacíos dejó escrito:

  27 guiones (75 KB)          → takana:/work/rescate-guiones      sha256sum -c ⇒ 27 OK
  memoria de Claude (6,3 M)   → takana:/root/.claude              733 ficheros = 733
  transcripts (1,3 G)         → StorageBox claude-gioser          rsync -an ⇒ 1 pendiente (el vivo)
  clave PRIVADA de release    → takana:/root/.config/takana/keys  sha256 igual + pública == trust/
  credenciales y config       → takana:/work/mudanza-secretos     27 ficheros = 27
  estado de sigma/tupu/willay → takana:/work/mudanza-estado       351 ficheros, 68 M

Las credenciales NO se instalaron en su sitio a propósito: la caja ya tiene su /root/.ssh, su
crontab y su Caddyfile, y pisarlos rompe lo que funciona. El .gitconfig es el caso más claro — trae
los `insteadOf` que reescriben remotos. Se instalan cuando se mude el hub. La excepción es la clave
de release, que sí fue a su ruta canónica: sin ella nadie puede volver a firmar el repo, y eso no
falla el día que se borra gioser sino la próxima vez que alguien publica.

Y un «576 M contra 1,3 G» que parecía copia truncada: el Storage Box COMPRIME, y su shell
restringida no tiene find ni acepta tuberías, así que el conteo de ficheros ahí no se puede hacer.
Lo que sí: preguntarle a rsync en seco, que compara contra el destino real. Un número que no cuadra
merece una segunda medición antes de un diagnóstico.

No se movieron ~10 G de árboles personales de /home ni /opt: qué datos valen no se deduce de la
máquina, y ésos son proyectos del usuario, no servicios de un censo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sergio
2026-09-16 16:02:04 +00:00
co-authored by Claude Opus 5
parent 9816fb98fd
commit 628abdbb51
+51
View File
@@ -2102,6 +2102,57 @@ usuario** (SDD 29 §4.0 quinquies), así que declararlos sin más los pone a cor
misma advertencia que ya lleva `recipes/incoming/shuma-daemon.toml` en su cabecera, escrita donde se
va a leer.
### 6.36 🚚 Lo que se movió hoy — y las cuatro verificaciones que se hicieron EN DESTINO *(2026-09-16)*
Con las decisiones del §6.35 puestas, se movió lo que no dependía de nada más. **Cada copia se
verificó del lado del destino**, que es la regla que el `rsync` con exit 0 y 1367 artefactos vacíos
dejó escrita (§6.13, y la regla 2 de `aplicar.py`).
| qué | a dónde | verificación en destino |
|---|---|---|
| **los 27 guiones** (75 KB) | `takana:/work/rescate-guiones/` | `sha256sum -c SHA256SUMS` ⇒ **27 OK** |
| **la memoria de Claude** (733 ficheros, 6,3 M) + `settings.json`, `plugins`, `history.jsonl` | `takana:/root/.claude/` | 733 ficheros en origen y **733 en destino** |
| **los transcripts crudos** (1 966 ficheros, 1,3 G) | Storage Box `claude-gioser/` | `rsync -an` de vuelta: **1 solo fichero pendiente**, y es el transcript de la sesión que estaba escribiéndolo |
| **la clave PRIVADA de release** | `takana:/root/.config/takana/keys/` 0600 | sha256 idéntico en los dos lados **y** su pública == `trust/release.ed25519.pub` |
| credenciales y config (gitconfig, npmrc, gh, ssh, crontabs, Caddyfile) | `takana:/work/mudanza-secretos/` 0700 | 27 ficheros en origen y **27 en destino** |
| estado de los daemons que viven (`sigma`, `tupu`, `willay`, `sandokan-watch.json`) + `/var/www/para-respaldar` | `takana:/work/mudanza-estado/` | 351 ficheros y 68 M en los dos lados |
#### ⚠ Las credenciales NO se instalaron en su sitio, a propósito
La caja **ya tiene** su `/root/.ssh` (con `github5`), su crontab (el latido de la caja, §6.29) y su
`/etc/caddy/Caddyfile` con los siete vhosts que ya sirve. Pisar cualquiera de los tres con el de
gioser rompe lo que hoy funciona. Quedan en `/work/mudanza-secretos/` con su `LEEME.txt`, y se
instalan **cuando se mude el hub**, que es otra unidad de trabajo. El `.gitconfig` es el caso más
claro: trae los `insteadOf` que **reescriben remotos**, así que instalarlo cambia a dónde empuja
`git push` sin que nadie lo pida.
La **única** excepción es la clave de release, que sí fue a su ruta canónica: sin ella nadie puede
volver a firmar el repo, y ese fallo no aparece el día que se borra gioser sino la próxima vez que
alguien publica.
#### 🔍 Un «576 M contra 1,3 G» que parecía una copia a medias
`du -sh` en el Storage Box decía **576 M** de los 1,3 G subidos. Con el antecedente del rsync que
llenó el disco, eso se lee como copia truncada. No lo era: el Storage Box **comprime**, y su shell
restringida no tiene `find` ni acepta tuberías, así que el conteo de ficheros —la verificación
obvia— ahí no se puede hacer. Lo que sí se puede es **preguntarle a rsync**: una corrida `-an`
compara tamaño y fecha contra el destino real y dijo **1 fichero pendiente**, el que estaba
creciendo mientras se copiaba.
⇒ *la verificación tiene que poder correrse en el destino que hay, no en el que uno imagina*. Y un
número que no cuadra merece una segunda medición antes de un diagnóstico: `du` medía otra cosa.
#### Lo que NO se movió, y no es olvido
**~10 G de árboles personales en `/home/sergio`** —`android-sdk` 1 G, `maps`, `imm`, `humanoid`,
`hifas`, `fdroid`, `valens-conversion`, `pyswisseph`, `accordion`…— y `/opt` (1,2 G, que es
`android-sdk` otra vez y `google`). **Qué datos valen no se deduce de la máquina** (§3), y éstos son
proyectos del usuario, no servicios de un censo: van a la lista de decisiones, no a una copia hecha
por criterio ajeno.
De `/var/lib` (8,1 G) se movió sólo el estado de los daemons que viven: **6,1 G son swap** y 1,9 G
el gitea, que ya está mudado desde el §6.14.
## 7. Reusar los scripts que ya existen, y no escribir de nuevo
Pedido explícito del usuario. El inventario de lo que ya hace el trabajo: