Herramientas

DailyRapport, la app del registro diario

Una aplicación web para registrar el trabajo de cada día: qué necesitaba, cómo la hice y qué hay dentro.

DailyRapport, la app del registro diario

Llevo años enviando un correo al final del día explicando qué he hecho. El problema no era escribirlo: era que siempre llegaba tarde, a las seis de la tarde, cuando ya no recordabas del todo qué había pasado por la mañana. DailyRapport es mi respuesta: una aplicación web que mantiene el registro al día y prepara el correo ella sola.

Qué hay dentro

Nació como herramienta de envío de rapports, pero hoy es un gestor de trabajo diario entero: registro por fechas, biblioteca de tareas con prioridades y categorías, rutinas semanales, planes mensuales y rebalanceo por capacidad cuando el día no da de sí. La duración de cada tarea se redondea a bloques de treinta minutos, porque pretender minutos de precisión es mentirse. Y el ciclo que me sirve cada día es este: la aplicación genera un borrador del rapport, yo lo reviso y lo apruebo desde el Telegram del móvil, y entonces sale por correo. Con aprobación previa, sin envíos que no hayan pasado por mis manos.

Seguridad, cuando la cosa se pone seria

Como había un bot de Telegram y credenciales SMTP dentro, llegó un momento en que tuve que tratarla como aplicación de verdad: ningún secreto en las respuestas de la API, JWT con iss, aud y jti, sesión por cookie HttpOnly, rate limiting en login y webhook, y PostgreSQL publicado solo en loopback. Ninguna de estas cosas la pidió nadie; todas son consecuencia de haberla puesto en producción.

Qué aprendí con agentes de IA

Este proyecto lo construí con agentes de IA, y descubrí que el problema no es generar código: es mantener el contexto entre sesiones. La solución fue documentarlo todo de forma densa: un CHANGELOG detallado, la descripción del proyecto y los documentos de decisiones en markdown. Los ficheros .pen que arrastramos entre sesiones son literalmente el contexto comprimido del proyecto. Cuando un agente volvía a empezar de cero, el trabajo perdido no era código: era memoria.

Qué haría distinto hoy

Pruebas desde el primer día, sobre todo en el cálculo de capacidad y rebalanceo, que es donde la lógica se vuelve sutil. Y empezaría por el flujo de aprobación en lugar de añadirlo al final, porque el envío automático sin aprobación no lo quería y todo lo demás se debería haber adaptado a eso desde el principio.