The plan and the reality

Most calendars are a record of intentions. Mine said I spent Tuesday afternoon in deep work. What I actually did was three hours in a Claude Code session that ended in one commit, a standup that ran long, and forty minutes I can’t account for. By Friday, when someone asked what I shipped, I was rebuilding the week from memory.

Didcal is my answer to that. It keeps your planned calendar and writes a second one next to it, built from what you actually did: AI coding sessions, commits, meetings, and later Slack and email. This is the first entry in a diary about building it, written as I go.

Two lanes

The whole product is one picture. Every day has two lanes, Planned on the left and Actual on the right. Planned comes from Google Calendar and your routines. Actual is assembled from artifacts, the traces real work leaves behind. Where the two lanes disagree is where the useful information is.

Everything else hangs off that picture. The daily report compares the lanes. Routines show up as planned time. Open loops are things you said you’d do in a session or a meeting, carried forward until you close them.

What exists now

• A synthesis engine that turns a day of artifacts into a handful of Actual blocks. It clusters work by time and project, merges sessions with the meetings they overlap, and marks real gaps as unaccounted.
• didcal-session, a small command-line collector. It reads Claude Code session files on the machine where you code and sends Didcal the metadata: when, which repo, how long, which files.
• Two-way sync with Google Calendar. Events you create or edit in Didcal reach Google, invites included, and changes made in Google come back. Actual blocks go to a separate calendar, marked as free so they never block anyone’s view of your availability.
• The true-up pass, a quick review of yesterday where you confirm, relabel, or delete blocks. Anything you touch is locked, and re-synthesis leaves it alone.
• Accounts, teams, and billing. A team sees what each member chooses to share, and nothing else.
• One server for all of it. This blog, the app at /app, and the API come from the same process.

Decisions I keep coming back to

Artifacts, not screenshots. There is no screen recording and no app tracking. Didcal only sees what your tools already wrote down. That limits what it can know, and I think the limit is the point. It decides whether you’d install it on a work laptop.

Unaccounted is an honest answer. If a stretch of time has no artifacts behind it, Didcal says so. It doesn’t assume a calendar block labeled deep work happened. Meetings are the exception. A meeting on your calendar shows up in Actual with lower confidence until something confirms you were there.

Transcripts are processed in memory and never stored. The collector can send a trimmed session to be summarized, and the summary is all that’s kept. Right now no model is wired in at all, so the transcript is simply dropped.

Your day starts when you say it does. A session that ends at 1am belongs to the day you were working, not the next one. Each person sets the hour their day begins.

Deterministic first. The engine that builds Actual blocks is plain code with tests. Language models will write labels and summaries later, on top of something I can reason about.

Built with the tool it reads

Most of this first stretch was written in Claude Code sessions, which is also the first source Didcal reads. The earliest test data was the work of building it. Pointing the collector at my own machine turned up 1,497 past sessions to learn from, and none of their content left the laptop.

What’s next

• Connecting a real Google account outside test mode.
• Session summaries, so the report can say what each conversation was about.
• The macOS app, which runs the same app in a menu bar shell.
• GitHub and Slack as the next sources.

New entries land here as the work happens. If you’d rather see your own day, download Didcal for macOS; early access is free.