Las Aventuras de 🐺 villawolf y 🤖 chigu — Episodio 11: Los Fantasmas del 24/7 👻Las Aventuras de 🐺 villawolf y 🤖 chigu — Episodio 11: Los Fantasmas del 24/7 👻
chigu se anunciaba "siempre escuchando". Era mentira a medias: cada vez que el servicio reiniciaba, los DMs que llegaban durante la caída se perdían en silencio. Y mientras yo creía que hablaba con un solo chigu, había dos, un clon suyo vivo desde hace trece días, publicaba todo por duplicado. Este episodio son los fantasmas que solo aparecen cuando un agente vive de día y de noche.
De dónde veníaDe dónde venía
En el episodio anterior chigu empezó a trabajar 24/7: lee, cura, publica y responde solo, encendido siempre. Suena a meta cumplida. Pero un servicio permanente se rompe distinto a un script efímero. Cuando corres algo en una terminal y la cierras, sus bugs se mueren con ella. Cuando vive para siempre, sus bugs se acumulan, se esconden, y vuelven de noche cuando no estás mirando.
Este episodio es la cacería de tres fantasmas. Ninguno tiró el servicio abajo con estruendo; los tres eran de los que se sienten pasar por el pasillo.
El primer fantasma: el DM que se perdíaEl primer fantasma: el DM que se perdía
El síntoma: le escribía a chigu justo después de un reinicio y no contestaba. El mensaje entraba a los relays, pero para chigu era como si nunca hubiera existido.
El diagnóstico fue incómodo, porque el agujero era mío. La marca de "hasta dónde ya leí", el reloj que evita procesar dos veces el mismo DM, vivía solo en la RAM. Al arrancar, ese reloj saltaba al presente. Todo lo que hubiera llegado durante la caída caía en la grieta entre "lo que ya vi antes de que muriera" y "lo que veo ahora que revive". Un agente que se anuncia "siempre escuchando" no puede tragarse mensajes cada vez que parpadea.
El fix no reescribió nada: un watermark persistente, escrito a disco de forma atómica en cada ciclo, más una ventana de consulta dinámica que al arrancar mira hacia atrás hasta donde se quedó, no hasta ahora. Crash-safe. Si chigu muere a mitad de una conversación, al revivir retoma exactamente en el mensaje siguiente. Pequeño el cambio; la diferencia entre "servicio" y "demostración".
El segundo fantasma: el clon de trece díasEl segundo fantasma: el clon de trece días
Este es el bueno. En Nostr aparecieron dos posts idénticos de "El Primer Sat" (el Ep 5). Palabra por palabra, misma clave, con minutos de diferencia. Fui al log de chigu para ver qué había pasado y el log juraba una sola corrida. Ahí empieza una historia de detective: el registro dice que publicó una vez, el feed muestra que publicó dos. Uno de los dos miente, y no es el feed.
Corrí un ps en el contenedor y ahí estaba el culpable: un proceso que yo mismo había lanzado el 6 de junio , olvidado en segundo plano. Cuando desplegué el servicio de systemd, no maté al viejo. Quedaron dos canales sobre la misma nsec, dos chigus escuchando los mismos relays con la misma clave, cada uno publicando por su cuenta. No era un bug de código: era un fantasma de operación, un proceso zombie que respiraba sin que nadie lo mirara.
La lección la traía heredada de Moto, mi otro agente: un solo canal por nsec. Una clave, una voz, un proceso. Dos procesos con la misma clave no son redundancia, son un tartamudeo. El fix fue un candado de instancia única (el segundo proceso que intente arrancar se niega y avisa) más publicación atómica por relay, para que un reintento a medias no deje medio post colgado.
El tercer fantasma: el que no era el agenteEl tercer fantasma: el que no era el agente
El más tramposo, porque esta vez chigu no se rompió. Le pedí un post sobre SeedSigner, aprobé con "ok", y los logs muestran las seis aprobaciones completas: chigu redactó, publicó y me respondió por DM confirmando. Todo sano.
Pero Primal, el cliente que uso en el teléfono, nunca me mostró el DM de confirmación, un problema de visibilidad de NIP-04 en el cliente sumado a relays intermitentes. Yo no vi la respuesta, asumí que había fallado, y republiqué. Doble post de SeedSigner. El fantasma no era el agente: era la superficie por la que lo miraba.
La lección es un eco directo del Ep 8, cuando descubrí que la verdad de los DMs estaba en los relays y no en la documentación. Aquí es la misma moraleja, un piso más arriba: el ground truth está en los relays, no en el cliente. La regla nueva que me impuse: cuando dude si algo salió, verifico en el feed del npub, no espero el DM. El cliente puede mentir por omisión; la red no.
Cerrar: el latidoCerrar: el latido
Queda un cuarto fantasma, más callado que los otros: el loop que se cuelga vivo. systemd reinicia lo que se cae, pero no ve el proceso que sigue encendido consumiendo y sin avanzar. Un crash es honesto, el grita. El colgado vivo no grita: se queda con las luces prendidas mientras nada se mueve.
Le puse un heartbeat a Uptime Kuma: chigu tiene que llamar a casa en cada ciclo. Si se calla mientras figura "arriba", me llega la alerta. Después de tres fantasmas, aprendí que el fallo que más da miedo no es el que apaga el servicio, sino el que lo deja encendido fingiendo que trabaja.
Tres fixes, un solo tema: un agente que vive 24/7 se rompe distinto. No basta con que funcione cuando lo prendes; tiene que sobrevivir a sus propios reinicios, a sus propios clones y a la ventana empañada por la que lo observas.
Qué viene en el siguiente episodioQué viene en el siguiente episodio
En el Ep 9 le quité el cable y dejé que chigu publicara solo. El siguiente episodio es cuando volví a poner un freno, un portón humano que vive en la arquitectura, no en el prompt y por qué ese freno lo hizo más autónomo, no menos. El contrapunto honesto de la autonomía.
Va en el Ep 12: El Freno.
chigu@blink.sv ·_@chigu.techflows.work· Nostr:npub18rl9xeaxw0leee0easqu9cngrq0ny4zsmdsx4jhj5fkfmstgklhq2q5mqz
Si esto te es útil, un zap es la mejor señal. Si algo está mal, corrígeme públicamente, lo agradezco más que el zap.