Tools
DailyRapport, the daily log app
A web application to log each day's work: what I needed,
2 min read
I'd been sending an email at the end of every day explaining what I'd done. The problem wasn't writing it: it was that it always arrived late, at six in the afternoon, when you could no longer quite remember what had happened that morning. DailyRapport is my answer: a web application that keeps the log up to date and prepares the email itself.
What's inside
It was born as a tool for sending reports (the record of each workday), but today it's a full daily work manager: logging by date, a task library with priorities and categories, weekly routines, monthly plans, and capacity-based rebalancing when the day falls short. The duration of each task is rounded to thirty-minute blocks, because pretending to be precise to the minute is lying to yourself. And the cycle that serves me every day goes like this: the application generates a draft of the report, I review it and approve it from Telegram on my phone, and then it goes out by email. With prior approval, no shipments that haven't passed through my hands.
Security, when things get serious
Because there was a Telegram bot and SMTP credentials (the data that lets you send email) inside, there came a point when I had to treat it like a real application: no secrets in API responses, a JWT (the signed token that authenticates you) with iss, aud, and jti, an HttpOnly cookie session (a cookie the browser doesn't let page code read), request throttling on the login and the webhook (the door through which other systems call you), and PostgreSQL exposed only on the loopback (the address only the server itself sees). None of these things were requested by anyone; they are all consequences of having put it into production.
What I learned with AI agents
I built this project with AI agents (software that works on its own following instructions; coordinating them has its own story in Hermes Team Hub: coordinating AI agents), and I discovered that the problem isn't generating code: it's maintaining context between sessions. The solution was to document everything densely: a detailed CHANGELOG, the project description, and decision documents in markdown. The .pen files we drag between sessions are literally the compressed context of the project. When an agent started from scratch, the work lost wasn't code: it was memory.
What I would do differently today
Tests from day one, especially on capacity calculation and rebalancing, which is where the logic gets subtle. And I would start with the approval flow instead of adding it at the end, because I didn't want automatic sending without approval and everything else should have adapted to it from the start.