La aplicación de tareas pendientes es la prueba canónica de cualquier framework web. Ejercita formularios, gestión de estado, persistencia de datos y renderizado de interfaz en un paquete compacto y bien entendido. Cuando construimos la aplicación de tareas de FLIN, la interfaz se renderizaba hermosamente. Los botones hacían clic. Los formularios se enviaban. Y cada dato desaparecía en el momento en que la página se actualizaba.
Tomó tres sesiones -- 201, 202, 203 -- distribuidas a lo largo del 16 de enero de 2026, para rastrear y corregir la cadena de errores que impedían que los datos llegaran al disco. Cada sesión descubrió una causa raíz diferente, y cada corrección reveló el siguiente problema.
Sesión 201: Conectando navegador y servidor
La primera sesión comenzó con una brecha fundamental: los demos integrados de FLIN no funcionaban en el navegador en absoluto. Se resolvieron cuatro problemas distintos: enlace de datos bidireccional, envío de formularios, manejadores de eventos con argumentos y el endpoint /_action.
Sesión 202: La arquitectura de persistencia
La Sesión 202 abordó el problema central de persistencia: cada solicitud HTTP creaba un VM::new() con una base de datos vacía en memoria. Los datos guardados durante una solicitud se perdían antes de que comenzara la siguiente.
La corrección fue usar VM::with_storage(), que conecta la VM a una base de datos respaldada en disco. Después de este cambio, el archivo WAL fue creado. Progreso. Pero el archivo estaba vacío.
Sesión 203: Tres causas raíz para un archivo vacío
Causa raíz 1: El bytecode sobrescribe el estado inyectado. El manejador de acciones inyectaba el estado del navegador en la VM, pero el código de inicialización de la página lo sobrescribía. La corrección introdujo un mecanismo de protected_globals.
Causa raíz 2: Value::Text no manejado por Trim. El opcode Trim de la VM solo manejaba Value::Object (cadenas asignadas en el heap). Para Value::Text (cadenas en línea), devolvía una cadena vacía.
Causa raíz 3: Validadores causando fallos silenciosos. Los validadores de entidad rechazaban el guardado, pero el error era absorbido por el manejo de errores del manejador de acciones.
El momento de la verdad
Después de las tres correcciones, los datos llegaron al disco por primera vez. La Sesión 204 verificó el flujo completo: agregar tareas, matar el servidor, reiniciar, verificar que todas las tareas seguían presentes.
Cada capa independientemente impedía que los datos llegaran a la base de datos. Corregir solo una o dos no habría sido suficiente -- las tres tenían que resolverse para que los datos fluyeran por la tubería completa.
La corrección de persistencia no fue una solución elegante única. Fueron tres correcciones separadas para tres errores separados, descubiertos a lo largo de tres sesiones que abarcaron un día entero. Fue desordenado, iterativo y poco glamoroso. También fue absolutamente esencial. Una aplicación de tareas que no guarda tareas no es una aplicación de tareas. Es un ejercicio de mecanografía.
Esta es la Parte 162 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.
Navegación de la serie: - [161] El error de seguimiento de versiones temporales - [162] La corrección de persistencia de base de datos que tomó 3 sesiones (estás aquí) - [163] El error de envolvimiento de hijos en layouts