Apagados en gioser (relay, serve y willay-crosscheck), encendidos en la caja: `tejido` en :4102 y
`willay-crosscheck` en :4103, los dos alcanzables desde fuera.
La prueba de que la identidad VIAJÓ no es que el servicio arranque —eso pasaría igual con semillas
nuevas, que es el fallo silencioso que esto existe para evitar— sino que la semilla sea la misma:
`device.seed` y `roster.postcard` con sha256 IDÉNTICO a los dos lados. El PeerId sale de ahí, así
que sigue siendo 12D3KooWBw2u….
⚠ LO QUE SÍ CAMBIA: el multiaddr que los clientes tienen configurado lleva la IP.
antes /ip4/204.168.193.248/tcp/4102/p2p/12D3KooWBw2u…
ahora /ip4/2.29.29.217/tcp/4102/p2p/12D3KooWBw2u… (mismo PeerId, otra IP)
🧱 SIN EL CORTAFUEGOS HABRÍA SIDO UN VERDE FALSO: el reglaset abría 80/443/1137/2345/22022 y nada
más. Con el relay encendido y el 4102 filtrado, `status` diría «corriendo · 0 reinicios» y la flota
no llegaría. Abiertos 4102 y 4103 con su ban por tasa; NO el 33097, que era el puerto efímero de un
`tejido serve` cliente. Y el fichero quedó IDEMPOTENTE (crear+borrar la tabla antes de definirla),
que era deuda del §6.33: 15 reglas dport antes, 21 después — no 36.
⚠ La política que genera ese reglaset NO EXISTE en ningún disco: ni la ruta que su cabecera nombra
ni el binario `cortafuegos`. El generado sobrevivió a su fuente, así que hoy se edita a mano.
🆔 Y takana acepta ULIDs que arje-zero RECHAZA: la card no encarnaba por `invalid character`, y era
la `L` de «RELAY» — carácter excluido del alfabeto Crockford. `service-cards` lo dio por bueno («26
alfanuméricos») y el consumidor lo tiró. El validador del productor más laxo que el del consumidor
siempre termina en un fallo lejos de donde se escribió.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Era la décima de la tanda y es la única que no selló. Dos hallazgos, y el segundo vuelve irrelevante
al primero.
1. NO CONSTRUYE. Su dependencia `atspi-common` muere con `custom attribute panicked — message: File
has no extension.` en el proc-macro `#[validate(signal: …)]`: lee un fichero en tiempo de
compilación y no resuelve la ruta dentro del sandbox (el árbol vive en `/src/...`). De ahí salen
292 errores en cascada (`ObjectRef` sin declarar), que es lo que se ve primero y no es la causa.
2. NO HACE FALTA. Su propio Cargo.toml la describe como «Mini-ventana Llimphi compatible con
SUDO_ASKPASS»: es una VENTANA (llimphi-ui, theme, widget-text-input, clipboard). En un servidor
sin pantalla no tiene dónde dibujarse — y las sesiones de shuma son PTYs, así que el prompt por
TTY no es una degradación, es el camino correcto.
El aviso que el daemon imprime al arrancar («askpass: no encontré shuma-askpass … pedirán la clave
por el TTY») es para el escritorio, no para el servidor. Queda escrito en la cabecera de
`recipes/shuma-daemon.toml`, que es donde alguien va a leerlo cuando vuelva a ver el aviso.
Balance de la tanda: 9 de 10 selladas y declaradas; la décima retirada con motivo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
La tabla del §6.3 era del 10 de septiembre. Hoy, entera:
2 store entero ✅ 1632 artefactos, 0 vacíos (eran 1362) · ⚠ /store al 88%
4 la granja late allá ❌ el latido SIGUE en gioser
6 dominios vivos 200 ✅ los 8 contra 2.29.29.217, `sergio` incluido
7 respaldo desde allá ⬖ el script corre y LISTA el Storage Box desde la caja
1,3,8 ✅ · 5 ⬖ (sirve, no consume: reproducir exige el lab entero)
La puerta 4 es ahora UNA LÍNEA DE CRONTAB. La caja ya tiene git, python3, rsync, ssh, takana, flock,
la llave del worker y el `.fleet`; le faltaban dos costuras y están hechas: `store -> /store` (el
script espera ./store, acá es partición) y `target/release/takana -> /usr/bin/takana` (no hay árbol
de build en una caja instalada). Prueba de sólo lectura: `estado-granja.sh` desde la caja ve al
worker, lee el grafo KDE y dice «CRON DE COSECHA: NO instalado».
NO lo instalé, por el mismo motivo que tejido: con el cron en las dos máquinas, las dos harían
`rsync --delete` al worker y las dos cosecharían y commitearían. El latido se INTERCAMBIA, no se
duplica, y es el último movimiento antes del borrado.
De paso, el repo de /opt/takana estaba 5 días atrasado y quedó en origin/main exacto (0 diferencias),
con tar de respaldo de los 92 ficheros previos. ⚠ Esos 92 no eran trabajo local: era contenido que
YA estaba río arriba metido en el árbol sin commitear — un árbol que parece sucio y está atrasado.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`/etc/arje/cards.d/openrc-openclaw.json` de gioser tiene una credencial en claro adentro del JSON —
2 coincidencias con patrón de api_key/token. Ese directorio está en `fuera_de_git`, así que la
mudanza lo copia y un respaldo lo multiplica.
No lo toco: rotar una credencial es del dueño. Queda anotado con las dos salidas (rotarla y moverla
a un fichero 600 que la Card EXIJA, como hace thasnuna; o que openclaw muera y se revoque igual), y
con la que no es opción: copiarla tal cual.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Nueve de las diez sellaron y están promovidas. Cinco corren en la caja (matilda, tupu, pacha,
pacha-secretos, willay-daemon, más el par de shuma de ayer); cuatro quedan instaladas y FRENADAS a
propósito, cada una con su guarda diciendo qué falta.
⚠ LA PAUTA DE LOS VHOSTS NO SIRVE PARA UNA IDENTIDAD. Con los sitios la regla fue «mudá el DNS y
dejá el origen encendido, así volver cuesta un minuto» (§6.26). Con `tejido` es justo lo contrario:
su README dice que la clave que el roster atesta ES la identidad de transporte libp2p
(`~/.tejido/device.seed`), así que dos máquinas con la misma semilla no son dos réplicas — son el
MISMO PeerId en dos sitios, dos impostores mutuos para la flota. `tejido` se INTERCAMBIA: se apaga
allá, se enciende acá, en ese orden. Todo listo para el intercambio (binario, cuenta 964, identidad
700 instalada) y su Card en `cards.d` pero NO en el `genesis`, para que un reinicio no lo encienda.
Y arrastra a `willay-crosscheck`, que no es independiente: corriendo su línea a mano dice «no hay
roster en /root/.tejido/roster.postcard — emparejá primero». Vive dentro de la red de tejido.
`thasnuna` tampoco puede: su INSTALAR.md —escrito hoy por el frente tawasuyu para esta mudanza—
pide `sandokan-mcp` y `claude` AUTENTICADO, y el CLI de claude es glibc de ~300 M (jaula qorpa).
De ahí sale un hallazgo que vale para el respaldo entero: la Card `openrc-openclaw` de gioser lleva
la API key de su proveedor EN CLARO dentro del JSON de /etc/arje/cards.d/, que se respalda y se
copia. Un secreto dentro de una Card viaja a todas partes.
`--label` de willay-crosscheck NOMBRA A LA MÁQUINA: en gioser decía `momento`. Ahora sale de
`hostname` y la guarda frena si no hay.
Y tres veredictos FALSOS en una tarde, los tres por probar con lo que la caja no tiene: `/dev/tcp`
(busybox ash no lo tiene) dio los 5 puertos de gioser «cerrados»; la expansión de llaves dijo que
los artefactos no habían llegado; y `find -newermt "-2 minutes"` dijo que tupu no escribía. Tupu SÍ
escribe: su fichero tiene tamaño CONSTANTE —es una serie fija— así que ni los bytes ni ese find
prueban nada; lo que decide es el mtime, medido dos veces con 40 s de por medio.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sellaron `matilda`, `pacha`, `pacha-secretos` y `sandokan-watch`; las cuatro promovidas a canónicas
(hash idéntico antes y después de moverlas) y las tres primeras ya supervisadas por arje.
`matilda` archivó 78 ficheros leyendo el access log de caddy; `pacha` corre con SUS reglas y no con
las de fábrica; `pacha-secretos` vuelve a existir como binario — en gioser era un inodo borrado.
TRES CORREN COMO ROOT, declarado en vez de heredado. No es descuido: `matilda` lee
`/var/log/caddy/requests.json`, que caddy crea `-rw------- root root` y recrea igual en cada
rotación; y los tres del trío escriben en el MISMO `/var/lib/tupu`, cuyos 322 ficheros en gioser son
root:root — bajar a uno solo deja mezcla de dueños en un árbol compartido. O los tres, o ninguno. La
salida limpia (caddy con `mode 640` + cuenta propia del árbol) queda anotada en la receta. `pacha` y
`pacha-secretos` sí bajan a cuenta propia: en gioser tampoco corrían como root.
🕳️ LA CAJA NO TENÍA HOSTNAME. `hostname` decía `(none)` y `/etc/hostname` no existía — NINGUNA caja
takana lo fija: ni netup, ni el product-rootfs. Nunca importó porque nada archivaba por nombre,
hasta que llegó matilda: sus primeros 72 ficheros fueron a `/var/lib/tupu/none/`, y dos máquinas
distintas archivarían en la misma carpeta sin que nada falle. Puesto `/etc/hostname` + una Card
OneShot en el genesis para que sobreviva al reinicio. Lo correcto es que lo haga `netup`.
🛡️ Y `sandokan-watch` quedaba VERDE SIN VIGILAR: en takana no hay `auth.log` ni journalctl, así que
arrancaba, decía «sin fuente de accesos: no se guarda nada» y se quedaba «corriendo · 0 reinicios».
Su Card ahora sale 78 nombrando el problema y NO entra al genesis: un vigía que no vigila es peor
que uno caído, porque el caído se ve.
De paso, dos veredictos FALSOS en una tarde por probar con algo que la caja no tiene: `/dev/tcp` no
existe en busybox ash (dio «cerrado» para los cinco puertos de gioser, incluidos :80 y :443, que
sirven) y la expansión de llaves tampoco (dijo que los artefactos no habían llegado; habían
llegado). Misma familia que el §6.23.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El texto de esta mañana afirmaba que «otro agente movió la rama», y daba como prueba que los commits
que trajo el `pull` cuelgan del commit ANTERIOR al mío. Eso no es prueba de nada: es lo normal
cuando el otro lado empujó desde una máquina que había hecho `fetch` antes — en este caso la laptop,
cuyos tres commits llevan su huso (-04:00) y no pasaron por acá.
Lo MEDIDO es el reflog (entre `start` y `finish` no hay un solo `pick`) y que los diez ficheros
desaparecieron también del ÁRBOL, cosa que un `reset --hard`/`checkout` concurrente sí explicaría.
Queda escrito como hipótesis, que es lo que es.
La receta práctica no cambia y es lo que vale: mirar `git log --oneline -1` después de cada
`pull --rebase`, y si el commit propio no está, `git reflog` + `cherry-pick`.
De paso, descartado el sospechoso obvio: `cosecha-cron.sh` NO hace pull ni reset — commitea acotado
por pathspec y si el push falla sólo lo anota.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`work/` está en .gitignore, así que el fichero donde vive lo que el usuario decidió —con el motivo de
cada línea— no sobrevivía a la máquina que la mudanza borra. Ahora es `docs/state/`.
Nueve entradas marcadas `respalda`: terapeuta.ec (279 M, sin DNS hace tiempo), los cuatro «valens»,
`los-grandes-mensajes.pdf`, `kkk` (46 B, credencial en claro) y los tres clones de terceros CON
cambios sin commitear — lo commiteado se vuelve a clonar, lo de encima existe sólo en este disco.
Juntas en `/mnt/cosecha/respaldo-mudanza` (475 M) con LEEME y SHA256SUMS de 5472 ficheros. El
control se hizo ANTES del manifiesto: ficheros contados en origen y en corral, las nueve coinciden
(3805, 1243, 183, 1, 164, 1, 1, 72, 1).
⚠ NO entraron `~/hammer`, `~/takana` ni `~/tawasuyu`: son SYMLINKS a /mnt/vvv. El censo los veía
como entradas de 0 bytes CON remoto git —porque `git -C` sigue el enlace— y la recomendación
automática decía «respalda» por tener cambios sin commitear. Respaldarlos habría guardado tres
enlaces rotos. Un dato que parece del objeto y es del enlace.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Medido hoy en este repo compartido: commit propio con 10 ficheros → push rechazado porque otro
agente empujó → `git pull --rebase` → el commit YA NO ESTÁ, ni en el log ni en el árbol (los diez
ficheros desaparecidos del disco).
El reflog lo explica: entre `pull --rebase (start)` y `(finish)` no hay ni un `pick`. El rebase no
encontró nada que reaplicar porque, para cuando corrió, el commit ya no colgaba de `main` — los tres
commits que trajo el pull tienen de padre al commit ANTERIOR al mío, o sea que otro agente movió la
rama hacia atrás. Con `-q`, el resultado se ve igual que un pull limpio.
La recuperación es `git reflog` + `git cherry-pick <sha>`: vuelve entero. Y la comprobación que
evita el susto es mirar `git log --oneline -1` después de cada `pull --rebase`.
De paso, el corolario del espejo: el push doble puede triunfar en un remoto y fallar en el otro
(gitea rechazó, GitHub aceptó), así que tras recuperar queda un sha huérfano en GitHub con el mismo
contenido. Se repara empujando SÓLO esa URL con `--force-with-lease=main:<huérfano>`, después de
comprobar con `git diff --stat` que no se pierde nada.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Decisión del usuario: «viven todos los tawasuyu». Se construyen, no se copian — y no es preferencia:
tres de ellos (`tejido`, `pacha-secretos` y el `shuma-gateway` de ayer) corren en gioser desde un
INODO BORRADO, o sea que el binario ya no existe en disco y el proceso vive porque nadie lo mató.
Las diez, todas contra el mismo pin `23a292863` que `shuma-*` y `puriy-costura` — el árbol de
fuentes se comparte por `<dep>-<sha>`, así que un pin distinto es otro vendoreo de 2,4 G:
willay-daemon · willay-crosscheck · tejido · tupu · matilda · thasnuna · sandokan-watch ·
pacha · pacha-secretos · shuma-askpass
⚠ CUATRO NO SE LLAMAN COMO SU PAQUETE, y por eso `-p` y `--bin` no son redundantes:
`willay-crosscheck`←`willay-cruce`, `tupu`←`tupu-cli`, `thasnuna`←`thasnuna-daemon`,
`sandokan-watch`←`sandokan-seguridad-core`, `pacha`←`pacha-cli`. Comprobado crate por crate en el
commit pinneado: los diez son miembros del workspace, así que `-p` resuelve.
Cada cabecera lleva lo que MIDIÓ el censo y que la receta sola no dice: `willay-crosscheck` escucha
con `--label momento`, que nombra a la MÁQUINA y no puede viajar tal cual; `tupu`, `matilda` y
`sandokan-watch` escriben los tres en `/var/lib/tupu`, así que necesitan el mismo dueño o dos fallan
en silencio; `matilda` lee el access log de caddy; `tejido` y `thasnuna` tienen identidad y token que
NO son reproducibles —generar otros es ser otra máquina para la flota, o un bot sin sus teléfonos—,
así que su Card tendrá que exigirlos, no crearlos.
`takana hash` da los diez sin construir. Van a `recipes/incoming/`, que es la cola que el worker
muele; se promueven a canónicas cuando sellen, como shuma.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
El SDD 27 §2 dice que el repo mezcla tres capas —piso, escritorio, extras— en una sola
lista por escritorio, y que esa es la causa de que la composición no esté definida. El
firmware es un cuarto caso que el SDD no nombra y que sigue la misma lógica: no es un
escritorio ni un toolbox, es lo que hace falta para que un METAL CONCRETO arranque con todo
su hardware vivo.
Por eso va como perfil propio y se compone, en vez de duplicarse en los cuatro escritorios:
scripts/targets.py cli metal-tigerlake escritorio-kde
Otro metal = otro perfil de estos con su propia receta firmware-<plataforma> derivada del
mismo linux-firmware. Ese es el punto de haber partido el firmware en base + derivada.
La máquina, medida con lspci/cpuinfo sobre el metal real:
CPU i7-11370H · family 6 · model 140 (0x8c) · stepping 1 ⇒ intel-ucode/06-8c-01
GPU TigerLake-LP GT2 [Iris Xe] [8086:9a49] ⇒ i915 / xe
WiFi Intel Wi-Fi 6 AX201 [8086:a0f0] ⇒ iwlwifi
Audio 500 Series HD Audio [8086:a0c8] ⇒ snd_sof_pci_intel_tgl
Y zsh entra en `cli`, no en `base`: base define el shell del SISTEMA (bash) y esto es el
del usuario. Dos hechos distintos, como `paquetes` y `servicios` un piso más abajo.
El runbook deja el encargo para el worker, y su parte útil son los dos muros que aparecieron
al cruzar ficheros que nadie había leído juntos:
1. takana-live-install.sh:275 bifurca «UEFI ⇒ rama EFI-stub soberana», y metal-usb-sdboot.sh
dice que el EFI-stub «en el firmware del usuario se cuelga tras Measured initrd PCR 9».
ES EL MISMO FIRMWARE. El lazo de instalación EFI está validado en OVMF, que no tiene ese
quirk ⇒ el instalador va a pasar la prueba y colgarse en el metal de destino. La salida
es llevar el instalador a systemd-boot, que es el camino ya probado en esta máquina.
2. El instalador reparticiona en MBR el disco entero, y ese disco tiene /home con 893 G
usados. Si la instalación conserva /home o se lleva el disco con respaldo previo es
decisión del usuario, no del runbook — y hasta que se decida, no correrlo sobre el NVMe.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
sergioandClaude Opus 5