Cómo construí Alhena: la IA propone y un padre o madre decide

El 6 de abril de 2026 dejé guardada la sincronización con Gmail a las 17:46 y el primer paso de IA a las 18:01. Esa primera versión pasaba lo que devolvía el modelo directo al tablero, como tareas.

A las 20:20 de esa misma noche ya lo había cambiado. El mensaje del commit lo resume: la entrada de correo crea borradores para revisión en lugar de crear tareas automáticamente. Ahora solo un padre o una madre puede convertir un borrador en tarea. El costo es un paso más por aviso. A cambio, nada de lo que lee el modelo llega al tablero sin que una persona lo haya visto.

Si usted está pensando en algo parecido, resuelva esto desde el primer día: ¿quién tiene la última palabra, el software o una persona? Esa noche hacerlo realidad requirió una tabla de borradores, un servicio de revisión, tres rutas y una cola de revisión.

La app le pide a Google un solo permiso de Gmail, de solo lectura, y únicamente cuando el padre o la madre decide conectar el correo, como un paso aparte del inicio de sesión. A ese tipo de permiso se le llama alcance (scope): la lista de cosas que usted deja hacer a una aplicación. Este solo incluye leer, y el código únicamente llama las funciones de lectura de Gmail.

Luego reduje lo que la app conserva. Sigue a un solo remitente, que el padre o la madre puede cambiar en Ajustes, y el correo de cualquier otro se descarta antes de guardarse. Por defecto la primera sincronización mira 15 días atrás, y se puede elegir otro plazo. Las siguientes piden a Gmail solo lo nuevo. Nada corre en segundo plano: alguien pulsa un botón.

La contrapartida es que el correo no llega solo. Las reglas del primer commit ya descartaban la sincronización programada para la primera versión. El 16 de abril reescribí el texto de la página de inicio y ajusté las pantallas de los padres para que Gmail quede claramente como opcional: una familia puede empezar con tareas manuales y agregar el correo después.

Las reglas de mi primer commit ya decían dos cosas: usar salidas estructuradas para extraer datos del correo y nunca dejar que un modelo escriba directo en la base de datos. Por eso usé gpt-4o-mini de OpenAI con un formulario fijo en lugar de texto libre. Ese formulario se llama esquema. La API le pide al modelo que lo siga, y mi código vuelve a revisar la respuesta contra el mismo esquema antes de usarla.

Dos reglas pequeñas importan más de lo que parece. Los enlaces de un borrador deben salir del correo original: cualquier otro enlace que devuelva el modelo se descarta, así no puede inventar una dirección que alguien toque. Y cada resultado se guarda con el nombre del modelo y un número de rastreo, para saber de dónde salió cada borrador.

Las fechas requirieron muchos commits. El 8 de abril, 16 de los 42 commits mencionan fechas, plazos o tareas vencidas. Si su producto lee fechas de texto libre, reserve tiempo para ellas.

Mi primera migración creó diez tablas y ninguna tenía columna de familia. El soporte para muchas familias llegó el 10 de abril y tomó dos pasos: un script que movió los datos existentes a una primera familia y después una migración que volvió obligatorio el ID de familia en 14 tablas. El orden importaba: el propio encabezado de la migración dice que solo puede correr después de mover los datos.

Hoy 17 de las 20 tablas llevan un ID de familia. Importa más de dónde sale ese ID: sale de la sesión iniciada, no de la solicitud.

Si es posible que algún día tenga un segundo cliente, ponga el ID del cliente en cada tabla desde el primer día. Yo lo agregué el quinto día, con un script de relleno y una migración cuidadosa. Con datos de otras personas ya adentro, ese paso conlleva mucho más riesgo.

El primer commit del proyecto ya traía mis reglas: sin notificaciones, sin sincronización programada, un solo buzón de Gmail y solo tema claro. Los límites escritos desde el primer día le dan una respuesta lista a cada «¿y si también…?». Para un dueño de negocio, la lista de lo que no va a construir sirve tanto como la de lo que sí.

Lo que sí trae la primera versión es un conjunto de revisiones automáticas. Cada cambio a la rama principal corre las pruebas unitarias (al escribir esto pasan 1,321 y se omiten 5 que necesitan una base de datos real), un informe de cobertura que marca 67% de las líneas y una compilación de producción. Además, un script hace fallar la compilación si el código que habla con Gmail o con OpenAI termina en código que corre en el navegador. Las reglas del proyecto mantienen ambos en el servidor.

Las pruebas de extremo a extremo manejan un navegador real en tamaño de escritorio y de iPad. Están pensadas para correr en la computadora de quien desarrolla y se omiten en el servidor de integración. Es una brecha conocida.