storagebits

Probando la NUCLEO-F412ZG con Hubris y Humility

2026-10-18T18:05:17-04:00

El tema: una NUCLEO-F412ZG, una placa de desarrollo de ST con un Cortex-M4, y Hubris, el sistema operativo embebido de Oxide Computer, que no la soporta de serie. El kernel no cambió ni una línea. Hubo que añadir la placa, adaptar tres drivers, actualizar el firmware de la sonda y corregir dos veces Humility, el depurador.

La NUCLEO-F412ZG, alimentada por el USB del ST-LINK, la sonda integrada en la parte inferior de la placa. Encima, los tres LED de usuario que controla la tarea pong.

# Hubris, Humility: ¿qué son? ¿Quién está detrás?

Hubris es un pequeño sistema operativo en Rust que Oxide usa en sus servidores para el procesador de servicio. Cada tarea vive en sus propias regiones de memoria, protegidas por la MPU. Las tareas, sus prioridades y sus permisos sobre los periféricos se declaran todos en tiempo de compilación, en un app.toml. Humility lee la memoria de la placa a través de la sonda y la traduce gracias a la información de depuración: estado de las tareas, pilas, registros, volcados.

El autor principal es Cliff Biffle. Su charla en la Open Source Firmware Conference 2021 explica por qué Oxide escribió su propio sistema operativo. Esta charla es realmente increíble, ¡qué gran obra de ingeniería!

«On Hubris and Humility: developing an OS for robustness in Rust», Cliff L. Biffle, Open Source Firmware Conference 2021, 43 min.

También hay que citar a Bryan Cantrill, cofundador y CTO de Oxide, y a Adam Leventhal entre los grandes nombres detrás de Hubris. En su charla sobre la depuración de Docker en producción, en la DockerCon 2015, Cantrill defiende una idea sencilla: un sistema colgado no se reinicia antes de haberlo depurado, en vivo o a partir de una imagen de su memoria, el core dump. Humility hace las dos cosas: humility tasks lee la placa en marcha y humility dump guarda su estado completo en un archivo que se examina después, con la placa desconectada.

«Running Aground: Debugging Docker in Production», Bryan Cantrill, DockerCon 2015. Docker retiró el vídeo original en 2018; esta es la copia que volvió a publicar Cantrill.

# Lo que hubo que parchear

Le paso a Claude un prompt de misión: hacer funcionar Hubris en esta placa, conectada por USB al Mac. Su objetivo más cercano en el repositorio es una placa Discovery con un STM32F407. Esa misma noche, Hubris corre a 100 MHz en la NUCLEO.

Lo que se parcheó, capa por capa:

El kernel: nada, ni una línea.
La placa y la app: solo añadidos. Un archivo de placa de 2 líneas (el nombre del chip para probe-rs), una descripción del chip (1 MiB de flash, 256 KiB de RAM, direcciones de los periféricos) y la app en sí, con la configuración de reloj a 100 MHz. La rama añade 621 líneas, documentación incluida.
Tres drivers compartidos, unas 150 líneas: stm32fx-rcc elige la variante F412 de la biblioteca de registros, user-leds controla los LED de la Nucleo en PB0, PB7 y PB14, y stm32fx-usart pasa a USART3 (PD8/PD9), el puerto serie virtual del ST-LINK, a 50 MHz. El punto delicado: dos variantes de chip del crate stm32f4 no pueden convivir en una misma tarea, y dos de estos drivers forzaban la F407 en su Cargo.toml. Esa elección pasó a una feature. La Discovery compila exactamente igual, comprobado de nuevo en cada paso.
La sonda: el firmware del ST-LINK, demasiado antiguo, tuvo que actualizarse.
Humility, el depurador: dos parches, detallados más abajo. El primero arregla Humility frente al Hubris más reciente, sea cual sea la placa. El segundo corrige una medida errónea que aparece en esta placa.

# La misión, por tramos

La north star del prompt cabe en una frase: «humility tasks montre toutes les tâches Healthy sur la NUCLEO-F412ZG, les LEDs utilisateur clignotent sous le contrôle de pong, et ping écrit sur le port COM virtuel du ST-LINK.» [humility tasks muestra todas las tareas Healthy en la NUCLEO-F412ZG, los LED de usuario parpadean bajo el control de pong, y ping escribe en el puerto COM virtual del ST-LINK.] Cinco tramos, cada uno debe terminar en hardware que funciona: preflight, build de referencia, primer arranque con el oscilador interno a 16 MHz, UART y luego 100 MHz.

Primera parada ya en el tramo 0. El firmware del ST-LINK de la placa está en V2J25; probe-rs, en el que se apoya Humility, exige J26. El prompt decía que había que pararse y preguntar. Claude propone parchearlo automáticamente, le doy el zip descargado de la web de ST y listo.

Todas las tareas están Healthy. Claude no ve los LED: lee el registro de salida de GPIOB varias veces seguidas y lo ve alternar entre PB14, PB0 y nada, al ritmo de pong. La placa corre a 100 MHz. En 10 segundos, el reloj de Hubris cuenta 10 235 ms frente a 10,32 s de reloj de pared; la diferencia es la latencia de conexión de Humility.

El tramo 4: de 16 MHz con el HSI a 100 MHz. Cada constante está justificada en el código por una sección del RM0402, y releída en los registros una vez flasheada.

# Cuando se rompió: SavedState

Justo antes del primer arranque, humility tasks falla: «expected structure SavedState not found».

Para entenderlo, hay que saber cómo lee Humility una tarea. Cuando el kernel interrumpe una tarea, guarda sus registros (r4 a r11, el puntero de pila, etc.) en una estructura, el campo save de la entrada Task de esa tarea. Humility lee la tabla de tareas directamente en la RAM de la placa. Para saber en qué byte está cada registro, necesita el plano de esa estructura, que encuentra en la información de depuración (DWARF) del binario del kernel. Y la buscaba por su nombre: SavedState.

El 9 de octubre, cuatro días antes, la PR #2704 de Hubris introdujo un trait Arch para que el kernel pueda apuntar a varias arquitecturas. La estructura del ARMv7-M pasó a llamarse ArmMSavedState. Humility ya no la encuentra, y ni humility tasks ni la lectura de los registros de una tarea funcionan, sea cual sea la placa.

Dos maneras de salir del paso. Claude primero fija la rama justo antes de ese commit y sigue adelante, lo que basta para esta placa. Está en DECISIONS.md, y desbloquea. Después, el parche, en la rama savedstate-by-member de mi fork de Humility: en lugar de buscar el tipo por su nombre, Humility toma el tipo del campo save de Task, que DWARF da directamente. El nombre puede cambiar; el campo se queda. Once líneas añadidas, cuatro eliminadas, en los dos sitios que leían esa estructura: humility tasks y la lectura de los registros. El parche funciona con el kernel antiguo y con el nuevo, probado en la placa en ambos casos.

# El segundo parche: stackmargin mostraba ceros

humility stackmargin indica, para cada tarea, cuánta pila no ha usado nunca. El principio: al arrancar una tarea, el kernel llena toda su pila con un patrón, 0xbaddcafe. Humility lee la pila desde abajo y cuenta las palabras que siguen intactas: ese es el margen.

En la placa, muestra un margen de 0 para jefe, el supervisor, con una pila de 152 bytes, cuando su app.toml declara 2200.

La MPU de un Cortex-M4 solo admite regiones cuyo tamaño es una potencia de 2. Desde abril (PR #2458), Hubris divide la RAM de una tarea en varias regiones contiguas para desperdiciar menos: los 2560 bytes de jefe son 1 KiB + 1 KiB + 512 bytes en lugar de una única región de 4 KiB. Así que una pila puede extenderse por varias regiones. El kernel se corrigió en mayo (PR #2492) para pintarla entera. Humility, en cambio, solo leía la región que contiene la cima de la pila: aquí la última, donde caben solo 152 bytes de pila, todos usados. De ahí el margen de 0.

Leído en la placa (humility map, readmem). Humility solo miraba la región que contiene la cima de la pila. El kernel, en cambio, pinta toda la pila con 0xbaddcafe en las tres regiones.

            STACKBASE  STACKSIZE  MAXDEPTH  MARGIN
antes   jefe 0x20001c00       152       152       0
después jefe 0x20001400      2200       272    1928

El parche, en la rama stackmargin-multi-region, recorre hacia abajo las regiones contiguas que pertenecen a la misma tarea, como hace el kernel, antes de medir. La prueba de no regresión de Humility también lo validó: en un volcado de un Sidecar, un switch real de Oxide, la instantánea esperada contenía tres falsos «MARGIN 0». Tras la corrección, cada tamaño de pila coincide al byte con el declarado en el app.toml de ese Sidecar.

# Dónde estoy

La rama nucleo-f412zg tiene cinco commits, con un DECISIONS.md y un README. Está fijada antes de la PR #2704; con el primer parche, Humility también sigue al kernel reciente. Los dos parches están en mi fork de Humility. La batería de pruebas del kernel en la F412, el tramo 5 opcional, no está hecha. Y «todo Healthy» solo es verdad a medias: ping provoca a propósito un fallo cada 100 respuestas de pong, como en las demos de Oxide.

Una pista para más adelante, aún sin hacer: un sensor I2C o SPI detrás de una tarea driver. En Hubris, un driver es una tarea como cualquier otra: solo ella tiene acceso a los registros del periférico, declarados en el app.toml, y las demás tareas le hablan mediante mensajes. El driver I2C del repositorio apunta a los STM32H7 y G0 (más un driver aparte para el LPC55), el SPI solo a los STM32H7 y al LPC55: nada para la familia F4, habría que escribirlo para esta placa.

Continuará…

Un reloj de 2020, un firmware completo, tres días

2026-10-16T00:00:00+00:00

Compré un LilyGO T-Watch 2020 hace seis años, porque era barato e ideal para probar y trastear. Desarrollar para él, en cambio, exigía una inversión real: C/C++, un framework que aprender, nociones de sistemas embebidos. Acabó en un rincón, junto a otros side projects sin terminar.

Con la IA, todos esos frenos desaparecen: en pocos minutos, tenía un firmware completo, escrito desde cero. Sin la IA, no lo habría sacado del cajón: crear cualquier cosa en él exigía demasiado esfuerzo.

¿Qué aparatos duermen en tu casa? Imagina lo que podrías hacer con ellos, en un tiempo récord.

La entrada sobre los cuatro días ya contó el primer flasheo. Aquí me quedo con el reloj.

# Lo que quería

Una esfera de cronógrafo de aviación y displays de 7 segmentos al estilo de los «circuitos temporales». Luego el tiempo, los autobuses y las notificaciones del iPhone. La lista completa de aplicaciones está en el README del repositorio.

Mi método se resume en dos gestos. Expongo sencillamente las funciones que quiero. Luego pido enseguida una primera versión de principio a fin, para tener un ciclo de retroalimentación corto. El resultado se vuelve convincente muy rápido.

Dirigí el desarrollo en lenguaje natural, expresando intenciones. Leyendo el código generado, también aprendí mucho, tanto sobre el lenguaje como sobre los frameworks y los conceptos de sistemas embebidos. ¡El alcance pedagógico es inmenso!

# El comienzo

Primer commit a las 3:22. El prompt de misión imponía dos reglas: hacer una copia de seguridad de los 16 MB de flash originales antes de cualquier escritura, y no tocar nunca los eFuses ni la tensión del núcleo.

La copia de seguridad estuvo a punto de fallar. A 921 600 baudios, el puerto USB desapareció en plena lectura. El agente volvió a empezar a 230 400 baudios, en bloques de 1 MB verificados uno a uno, porque por encima el cable introducía errores. A las 3:46, la copia completa estaba verificada y su hash SHA-256 registrado. A las 3:48, primer flasheo verificado en el reloj.

Tuve un poco de miedo de brickear el reloj. No sabía de dónde venía el fallo; probablemente del cable. El agente se encargó de todo, hasta probar un flasheo lento y fraccionado para lidiar con ese cable defectuoso (!). Sus preguntas y sus métodos eran pertinentes y precisos, y eso era lo que me daba confianza.

A las 4:09, la esfera de aviador aparecía en pantalla, con un segundero a 8 Hz.

La esfera de aviador, capturada en el reloj real por el puerto serie. Captura ya publicada en la entrada anterior.

# El momento en que se rompió

Conectado por USB, el reloj aguantaba. Con batería, se colgaba sistemáticamente al cabo de unos segundos. Durante la mañana, temía que estuviera brickeado, y le metía prisa al agente para que fuera rápido antes del siguiente cuelgue. Tuve que apagarlo y encenderlo tres veces.

Había dos causas, encontradas una tras otra. Primero, el watchdog del procesador seguía armado durante el sueño ligero. Ahora se suspende antes de entrar en reposo y se rearma al despertar. Después, una pulsación del botón congelaba el reloj. La línea de interrupción del chip de alimentación se queda en nivel bajo mientras no se lee, y la interrupción se volvía a disparar sin fin. Las interrupciones GPIO ahora se desactivan durante el sueño, y comprobé que el reloj aguantaba muy bien.

# Una decisión: dejar de depender del cable

Los cortes del USB volvían durante los flasheos. Había dos opciones: esperar a que volviera el puerto, o hacer que el cable fuera accesorio. El agente propuso el «modo taller»: cuando el reloj está alimentado por USB y el Wi-Fi está configurado, se queda conectado, acepta actualizaciones por Wi-Fi (OTA) y expone una consola TCP. Un Wi-Fi encendido todo el tiempo es normalmente un antipatrón. Enchufado a la corriente, la batería no está en juego, y la opción se puede desactivar.

Como el cable fallaba, el agente pasó por su cuenta a las actualizaciones por Wi-Fi (OTA). ¡Magia! Más tarde, los cortes aparecieron también mientras el procesador estaba en su cargador de arranque en ROM: así que el problema es de hardware, no de software. Después llegó un modo seguro: tras tres cuelgues seguidos en el primer minuto, el Bluetooth no arranca, para poder reparar siempre el reloj a distancia.

El reloj real en la pantalla de diagnóstico, la primera pantalla flasheada. Foto ya publicada en la entrada anterior.

# Dónde estoy

El problema del cable (B2 en BLOCKERS.md) sigue abierto: la conexión micro-USB sigue siendo frágil. El doble toque que despierta la pantalla sigue siendo algo aleatorio, pero funciona. El gesto de muñeca para despertar el reloj todavía hay que ajustarlo. La autonomía durante un día entero aún no se ha medido.

Lo que más me impresionó fue la rapidez con la que el agente flasheó el reloj por su cuenta y me mostró resultados concretos. Tengo muchas ganas de probarlo en otros aparatos. De hecho, pronto voy a volver a sacar mis micro:bits: ¡tengo una idea de proyecto!

Doce minutos entre la idea y la tele

2026-10-12T00:00:00+00:00

Jueves 8 de octubre, 20:34. Envío un prompt de misión a un agente. A las 20:46, la hora aparece en grande en mi tele, con una tipografía que eligió el agente.

Cuatro días después: seis proyectos, 159 commits, unos 240 mensajes míos, buena parte de menos de cinco palabras. «go T8». «vas-y présente la tranche 3» [venga, enséñame el tramo 3]. «c’est fait, reteste» [hecho, prueba otra vez].

El tiempo entre la intención y lo concreto se ha vuelto ridículo. Doce minutos para la aplicación Almanak. Dieciséis para Lukarne. El cuello de botella ahora soy yo: mi sueño, mis cables, mis cuotas.

Una fila por proyecto, del jueves a las 19 h al lunes a las 19 h. La cifra de la derecha cuenta los commits. Pasa el cursor por los círculos para ver las horas exactas.

Cada fila es un proyecto, cada trazo un commit. El círculo vacío es mi primer mensaje al agente. El lleno, por encima de la fila, es lo primero concreto: la app funcionando en la tele, el firmware en el reloj, la doble autenticación activa en la pasarela del homelab. Las bandas grises son las noches. Hay commits dentro. No siempre porque yo estuviera despierto.

# Jueves por la noche: tres agentes en 45 minutos

La noche del 8, en 45 minutos:

20:34: sale la misión Almanak.
20:36: retomo shot2cart, un proyecto empezado en septiembre con otra herramienta. «inspect project, it comes from an other AI conversation, inspect and we pursue».
21:07: descargo desde claude.ai el CLAUDE.md de mi homelab, que estoy rediseñando con un LLM. Lo acababa de escribir con otra instancia mientras la primera construía Almanak.
21:19: «je viens de créer CLAUDE.md pour toi, c’est parti !» [acabo de crear CLAUDE.md para ti, ¡vamos!]

Nadie espera a nadie. Mientras un agente compila, escribo la misión del siguiente con un tercero.

# Almanak, la chispa

El north star cabía en una frase:

Una pantalla que apetece dejar encendida. Cuando paso por delante de mi tele, sé en 2 segundos la hora, la fecha, el tiempo que hace y que va a hacer, y en cuántos minutos pasa mi próximo autobús. Es bonita como un objeto de diseño, no como un panel de administración.

Y una regla que mantuve en todos los proyectos siguientes: ningún tramo está terminado hasta que el agente lo ha visto funcionar en la Shield. Hace una captura por adb, la lee, la critica. Legibilidad a 3 m, overscan, desbordes. Y para cada tramo visual, dos variantes; nos quedamos con la mejor.

Almanak en la Shield la primera noche: el tema oscuro a las 22:17, el tema papel a las 21:38.

Siete tramos entre las 20:46 y las 22:32. Para el reloj, el agente comparó una serif editorial con una sans-serif suiza y se quedó con Fraunces, porque a 3 m, Inter con grosor 200 «empieza a parecer un alambre». Tiene razón.

El mejor bug: la sincronización de horarios de autobús devolvía HTTP 441 en la Shield y funcionaba desde el Mac. El agente rebuscó en dumpsys connectivity y encontró la VPN que corre en la Shield: la web de la STM (la red de transporte de Montreal) rechaza las IP de salida de las VPN. Pasó a un espejo del mismo flujo, byte a byte, y documentó el split tunneling en el README. El prompt no decía nada de una VPN.

Para ser honesto: mi definición de «terminado» pedía 24 horas de salvapantallas sin fuga de memoria. La medida real cubre más o menos una hora. Terminado, pues. Entre comillas.

# Lukarne, mi favorito

Al día siguiente, 17:58, segunda misión. Una ventana al mundo: girar un globo con el mando, lanzarse sobre una región, ver un mosaico de webcams en directo, saltar de una cámara a otra. La frase que cuenta en el prompt:

Si una interacción no es fluida con el mando, ha fracasado, aunque sea técnicamente correcta.

Y otra, más discreta, que explica por qué todo fue tan rápido: «Ya desarrollé otra app de Google TV contigo en esta misma Shield. Antes de nada, busca en mi entorno […] cómo nos conectamos […]. Reutiliza lo que funciona.» Cada proyecto deja tras de sí una dirección adb, un script de despliegue, un formato de DECISIONS.md. El siguiente arranca desde ahí.

18:14: primer directo a pantalla completa en la tele, HLS y YouTube, izquierda/derecha para pasar de uno a otro. 16 minutos. A las 20:54, la V1 estaba lista: un globo día/noche en OpenGL a 60 imágenes por segundo (3 ms por imagen), 1640 cámaras en 34 regiones (19 más desde el lunes), un mosaico 3×3 cuya casilla seleccionada pasa a directo en dos segundos, y un botón «sorpréndeme» que te manda adonde es de día. Dos pruebas de resistencia de 22 minutos, cero cuelgues.

Lukarne: Europa de noche, Venecia seleccionada, 16 webcams en directo, la cuenca de San Marcos en la esquina.

Lo más fácil es verla funcionar:

78 segundos en la Shield, sin sonido: el globo hasta California, la zambullida en Pollock Pines, el mosaico de cámaras de autopista en directo, la pantalla completa, la cámara siguiente, la subida, y luego «surprise me».

Este vídeo lo grabó el agente, el lunes por la noche, para esta entrada. Manejaba la Shield con un mando virtual (adb shell input keyevent) y grababa la pantalla con screenrecord. La primera toma fue en francés, sobre Europa, donde era la 1 de la madrugada: todo estaba negro. Repitió la toma en inglés, sobre California, de día.

El mosaico de un lugar y luego la pantalla completa. Izquierda/derecha salta a la cámara vecina sin volver al mosaico.

«surprise me» cayó aquí, en pleno rodaje. La cámara de auroras de explore.org en Fairbanks, 15:09 hora local: seguramente una reposición de la noche entre dos planos en directo.

Luego la usé, y me quejé. Sábado, 23:20: «je suis assez surpris du peu de flux video , bcp d’images fixes qui apportent peu» [me sorprende lo poco que hay en vídeo, muchas imágenes fijas que aportan poco]. 23:34, commit: primero el directo, las imágenes fijas como opción. Catorce minutos.

En la noche del domingo al lunes, a las 00:08: «parfait , je vais dormir là» [perfecto, me voy a dormir]. Y dos peticiones: «les vignettes pixelisée : on peut trouver un moyen de charger ne serait ce qu 1 frame propre plutôt que la vignette degeueu ?» [las miniaturas pixeladas: ¿podemos cargar aunque sea 1 fotograma limpio en vez de esa miniatura asquerosa?], y para el último nivel de zoom, un «effet plongeant genre zoom google earth» [efecto de zambullida tipo zoom de Google Earth]. A las 00:26, las miniaturas son fotogramas reales capturados en el aparato durante la reproducción. A las 00:48, te lanzas sobre un lugar con un zoom ×30, se encienden las luces, y vuelves a subir. A las 00:59, prueba de resistencia de 10 minutos después de todo eso. Yo dormía.

El lunes por la tarde pedí un modo demo, para que la tele viaje sola. 41 minutos después:

El modo demo: cámaras al azar donde es de día, nunca dos veces la misma región, con un fundido a un cartel entre una y otra.

Los ajustes, a un botón del mando: idioma (inglés, francés, español), unidades, imágenes fijas o solo directo, reproductor en esquina, tiempo por cámara del modo demo y los créditos de cada fuente.

Lo que aún falta: la cobertura en directo fuera de Norteamérica es escasa. El primer día, el agente gastó toda la cuota de búsqueda de YouTube mientras dos bugs ocultaban los resultados. Ahora un repositorio público republica cada día el catálogo de directos, y la app lo descarga detrás de su logo. Y hay un bug que no siempre consigo reproducir: una webcam de YouTube que se queda congelada al encadenar dos. Lo señalé a las 15:46 y hubo un arreglo a las 16:31. Falta comprobarlo en la tele.

# DropboksTV, un domingo por la tarde

Un cliente de Dropbox para la tele, pensado para el sofá: fotos y vídeos primero, solo lectura, sin backend. Domingo, 15:18: «read prompt-dropbokstv-claude-code.md and go». 16:02: el emparejamiento por teléfono funciona en la tele. 18:28: octavo y último tramo, con búsqueda, modo sin conexión, salvapantallas y 128 textos traducidos por idioma.

Lo más retorcido es el emparejamiento. Conectarse a Dropbox desde una tele, sin teclado, debería ser un código que escribes en el teléfono. Solo que la API de Dropbox no ofrece ese flujo. El agente lo comprobó en el SDK y lo anotó en su registro de decisiones. Así que montó otra cosa:

la tele muestra un código QR que apunta a una página servida por la propia tele, en el wifi de casa;
el teléfono abre esa página, que lo manda a autorizar DropboksTV en Dropbox;
Dropbox muestra un código, lo pegas en el teléfono, y la tele lo cambia por un token (PKCE: el secreto nunca sale de la tele, sin backend);
la sesión caduca a los 10 minutos y la tele renueva el QR sola. Un error al teclear no quema la sesión. Y si el teléfono no ve la tele, un botón cambia al enlace directo de Dropbox.

El pequeño servidor HTTP de la tele (150 líneas) lo sacó de Almanak.

El emparejamiento

Y luego está el visor. En tres tramos, entre las 16:25 y las 18:07, el agente escribió un visor que abre prácticamente todo:

las fotos, con zoom ×2 y ×3 que se desplaza con las flechas, y un pase de diapositivas con fundido o Ken Burns;
los vídeos: H.264, HEVC hasta 4K, reanudación donde lo dejaste, subtítulos .srt;
los PDF, página a página, con zoom;
Word y PowerPoint, que Dropbox convierte a PDF, y las hojas de cálculo, escaladas al 170 % para leerlas desde el sofá;
el Markdown con formato, el código con números de línea y colores;
la música, MP3 y FLAC, con la portada;
y para todo lo demás, un código QR que manda el archivo al teléfono.

El reproductor de vídeo llevó 16 minutos. Los documentos, la música y el envío al teléfono, 27. Una locura.

En orden: foto ampliada, vídeo, PDF, hoja de cálculo, Markdown, código, música, envío al teléfono (QR difuminado). Los archivos de prueba los fabricó el propio agente y los dejó en una carpeta de Dropbox dedicada. Capturas tomadas durante el desarrollo, en francés.

# Kronograf, o la vuelta del hardware

Lunes, 3:19 de la madrugada, un reloj LilyGO T-Watch de 2020 conectado por USB, y una misión: una esfera de cronógrafo de aviación y unos visores de 7 segmentos «circuitos temporales». A las 3:48, primer flasheo verificado en el reloj, después de una copia completa del flash original. Era la regla n.º 2 del prompt: no se escribe nada en el reloj sin red de seguridad. El cable falló durante la primera copia, y el agente se negó a flashear hasta tener una completa.

El reloj real, el lunes a las 18:11: la pantalla de diagnóstico, la primera que se flasheó. En verde, los chips detectados; en gris, lo que la V1 no tiene.

A la izquierda, captura del reloj real por el puerto serie. A la derecha, la esfera «circuitos temporales» en el simulador, que compila exactamente la misma interfaz.

Aquí el tiempo vuelve a subir, y no es culpa del agente. Ya no es código contra un emulador, es un conector micro-USB cansado. Mis mensajes de esa mañana: «elle plante systematiquement au bout de quelque secondes» [se cuelga siempre a los pocos segundos], «va vite sinon elle plante» [date prisa o se cuelga], «j’espère qu’elle n’est pas brikée» [espero que no se haya quedado brickeado]. El problema venía del sueño ligero, con una tormenta de interrupciones al despertar con el botón. A las 11:17: «ce semble tres bien tenir maintenant» [ahora parece aguantar muy bien]. A las 11:18: «go pour la météo» [adelante con el tiempo]. A las 11:31, el reloj muestra el tiempo y el próximo autobús en tiempo real.

Esta noche tiene 33 commits, alarmas, cronómetro, podómetro, actualizaciones por wifi y las notificaciones del iPhone por Bluetooth, que todavía no enganchan bien. El doble toque es «un peu alétoire , comme le mouvement du poignet … mais ca passe» [algo aleatorio, como el gesto de muñeca… pero vale].

# El homelab, y la app shot2cart

La obra más larga no se ve. Sesenta commits y 276 mensajes para rehacer el servidor de casa: inventario, copias de seguridad con pruebas reales de restauración, acceso remoto con passkeys para la familia, alertas, una página de inicio con un esquema animado de la infraestructura y otro de la red local.

Mi mensaje favorito de toda la serie, la primera noche: «ignore cet audit ; je ne compte que sur toi maintenant» [olvida esa auditoría; ahora solo cuento contigo]. El más sincero, el domingo: «Nest dans Home Assistant c’est payant ??!!» [¿¿Nest en Home Assistant es de pago??!!]. Pues sí, 5 $, gracias Google.

shot2cart es el contraejemplo. La idea de la app: una foto de una lista de la compra, y el carrito se abre en la tienda en menos de 15 segundos, sin teclear nada. Primer intento en septiembre, con otra herramienta y un flujo basado en especificaciones: tres días, dos commits. El jueves por la noche lo retomé sobre esa base. Domingo, 20:13, lo archivé todo: «forget about previous session, I archived the previous project and to start a new one with better prompt». 23:01: foto, análisis con un modelo de visión, enlaces de tienda artículo por artículo. 00:04: «I’m going to sleep […] please go as far as you can in full autonomy». Por la mañana había detección en streaming, fichas de revisión y recorridos de prueba automatizados.

Misma idea, mismo desarrollador. La diferencia entre septiembre y este domingo es la calidad de los modelos, y en particular Opus 5.5. ¡¡¡Una bestia!!!

# El tiempo, medido

Tipo	Lo que pedí	Tiempo hasta el commit
FEAT	«ajoute la langue espagnole à l’application» [añade el español a la aplicación] (Lukarne)	5 min
BUG	Los vecinos a 2500 km: «je suis sur Londres mais la Patagonie est listée» [estoy en Londres pero sale la Patagonia]	5 min
BUG	El logo que solo aparece medio segundo al arrancar	2 min
FEAT	Más directo, menos imágenes fijas	14 min
FEAT	El zoom de zambullida «tipo Google Earth», pedido antes de irme a dormir	40 min
FEAT	Un modo demo que encadena webcams al azar	41 min
BUG	El vídeo reciente que siempre abre un vídeo de 2012 (DropboksTV)	2 min
FEAT	«go pour la météo» [adelante con el tiempo] en el reloj	13 min

Lo que no va más rápido: un cable micro-USB que se suelta, una cuota de YouTube que se reinicia a las 3 de la madrugada, una clave de API que el portal del proveedor rechaza, mi suscripción. Domingo, 16:46: «il me reste que 10% pour notre session en cours» [solo me queda un 10 % para nuestra sesión actual]. Y mi sueño, que acabé metiendo en el plan: «je vais dormir la , avance au maximum de ton autonomie» [me voy a dormir, avanza todo lo que puedas por tu cuenta].

Lo que todavía no sé: cuántos de estos seis proyectos seguiré usando dentro de un mes. Ahora toca llegar hasta el final, publicar lo que se pueda publicar, alimentar a otros agentes.

Esta entrada se hizo igual. Un mensaje mío el lunes al final de la tarde, a lo bruto, con mis erratas: «génère moi un article complet […] mettre en avant le délai ridicule que c’est devenu entre l’intention et le concret» [escríbeme un artículo completo […] destaca lo ridículo que se ha vuelto el tiempo entre la intención y lo concreto]. Contarlo todo con transparencia y honestidad. El propio blog estaba en línea 45 minutos después de mi primer mensaje, el lunes a las 4 de la madrugada.

En fin, ¡buen fin de semana!