Step 4: The daily log · Lemon Agent

The log is the vault’s memory of events: one file per day at log/YYYY/MM/YYYY-MM-DD.md, append-only, holding what happened, what was decided, and what’s left hanging. Its killer feature arrives months later, when “why did I set it up this way?” has a greppable answer with a date on it.

You’ve met this before. The lab notebook and the engineering daybook: the oldest knowledge tool in science. The agent removes the reason they never stuck: you don’t have to write it. The agent appends a session summary as a byproduct of the work; you write only when you have something to say.

The habits

Append-only, dated headings. New entries go at the bottom under a time or topic heading. Yesterday’s entry never gets rewritten: the log is a record, not a document you polish.
The agent logs its sessions. End of any real working session: what happened, decisions made, open threads (three to six plain sentences, appended to today). This costs you nothing and builds the archive that makes future context cheap.
Decisions get a line. Not everything deserves logging, but choices do, especially the ones that felt obvious at the time. “Chose X over Y because Z” is one sentence now and an hour of digging saved later.
The log feeds the next session. An agent starting fresh reads the last few days of log and arrives oriented. This is the vault’s answer to sessions not sharing memory, the same move as writing git history for the next reader.

Try it

TRY IT "Log it"

you

Good session. Log it before we wrap.

agent

Three hours of migration work, two decisions, one dead end. The log entry I write now is what future-you gets instead of remembering any of it.

Pick the agent's next move, then see where it leads:

A[appends] "### 16:40 · migr sesh: idx rebuild via B-plan (post-bikeshed), perf ✓ after JSONB pivot, punted on the FK cascade q, see thread. TODO: vac-full before cutover."

you

Three weeks later: what was "B-plan"? What bikeshed? Which thread?

agent

No idea. That session's context is gone, and the entry was written in its private shorthand. "See thread" points at a conversation that no longer exists. The log recorded that things happened without recording what they were.

the baseline

Logged in the working register: session jargon, dangling references, compression that only decompressed inside a context that's now gone. The reader is future-you, cold. And future-you just got nothing. AF-16

B[appends] "### 16:40 · Migration session. Rebuilt the search index with the JSONB approach. Chose it over the join-table because query time dropped 40ms in the probe. Deferred the foreign-key cascade question; open because delete semantics aren't decided. Next: run vacuum before cutover."

you

Three weeks later, new session: "where did we leave the migration?"

agent

Reading the log: JSONB approach chosen for the 40ms probe win, cascade question still open pending delete semantics, vacuum still owed before cutover. I'm oriented. Picking up from the cascade decision. Total catch-up cost: one file read.

correct

Plain sentences, decisions with their why, open threads named: the entry paid out exactly when designed to. A cold session (agent or human) orients in seconds from what would otherwise be hours of digging.

CThe log's been getting messy. I'll take this chance to rewrite today's whole file as one polished narrative, folding the morning's rough entries into a clean summary of the day.

you

The morning entry said the JSONB idea came from the perf probe. I wanted to check the number. Where'd it go?

agent

Smoothed away in the rewrite. The polished narrative reads better and remembers less: I edited a record as if it were a draft, and the rough details that made it a record were exactly what got polished out.

plausible but wrong

The log is append-only because it's a record, not a document: rewriting for polish destroyed the raw detail that gave it evidentiary value. Yesterday's entry is evidence, never a draft.

Do it by hand

Create today’s file, write two sentences about what today was actually about. Then end your next agent session with: “append a session summary to today’s log: what happened, decisions, open threads.” From then on it’s automatic.

Or paste this into Claude

Standing log behavior for my vault. At the end of any working
session (or when I say "log it"): append to log/YYYY/MM/YYYY-MM-DD.md
(creating the file with a date heading if it doesn't exist) a short
section: what happened, decisions made (with the why in one line
each), and open threads. Plain sentences, no jargon, three to six of
them. Never rewrite or delete existing entries; the log is
append-only. When starting a session in this vault, read the last
three days of log first and say in one line where things stand. Add
this to CLAUDE.md. Show me the diff first.

Watch out

The performative log: entries written to look productive read terribly in six months. What happened, what was decided, what’s open. Nothing else.
Summaries in the working register: an agent will happily log in its own shorthand: session jargon, internal names, dense fragments. Plain sentences is a rule precisely because the reader is future-you, cold.
Logging instead of filing: the log records that a decision happened; the content lives with its project. If a log entry is growing sections, it’s a note trying to escape. File it.