You come back Monday. There is a pile of changes and a cheerful summary.

They record the conversation, not the actions

The transcript of your session holds what you asked and what the agent answered. Both useful, neither a record of what happened to your files, your branches or your services. Intent and response, not effect.

The undo history has documented gaps

Checkpoints look like a record and are not one. The documentation is specific:

"Checkpointing does not track files modified by bash commands. Only direct file edits made through Claude's file editing tools are tracked."

code.claude.com, checkpointing

The same page adds that edits made by a subagent are usually not captured in your session's checkpoints either. So the most consequential actions, the ones run as commands, are exactly the ones the undo history does not hold.

The summary comes from the thing being summarised

The agent reports its own work, in the same voice it did the work with. Where it was confident and wrong, the summary is confident and wrong in the same places. Nothing in the loop disagrees with it.

You already own most of a record. It is just not assembled, and nobody told you to look at it.

1. Read the version history, not the summary

Every change to your files is in git, with a time on it. Ask your agent to show you what changed since Friday, file by file, with the line counts. Read that instead of the paragraph it wrote. If you cannot read code, the file names and the sizes already tell you whether the work matches the story.

2. Ask for the command, every time

When something is reported fixed or tested, ask what was run and what came back. Paste the answer somewhere durable. A claim that cannot produce a command was never checked by anything.

3. Keep the decisions where they will be found

One file, one line per decision, dated. It takes seconds and it is the only thing that survives the chat closing. Without it, next month's argument starts from scratch.

4. Set the boundary in your own tool

Every agent client has permission settings that decide what runs without asking you. Open yours and read them. Most people never have, and the defaults were chosen for convenience rather than for your project.

Mission HQ assembles the record instead of leaving it in four places. Four things, and what makes each one worth reading.

Time, from moments the server actually saw

Working time is derived from timestamps recorded as the work happened, never from a number an agent typed. Activity within thirty minutes counts as one block. Where there is no signal, the answer is unknown rather than zero, because silence is not evidence of nothing.

What closed, from a ledger that does not rewrite

Task completions are counted from an append-only event ledger. Reopening a task later, or deleting it, does not change what last Tuesday says. A past day stops moving once it has passed.

The quality split, which is the part people actually want

Done is not one number. It arrives in three: done with a test a runner actually executed, done with a test somebody typed as passing, and done with no test at all. Same word on the screen, three very different things underneath, and the split is visible without opening anything.

Every refusal and override, queryable

When a completion is blocked, or a check is skipped with a reason, or somebody overrides one, that is an event you can look up afterwards. Real refusals are kept apart from advisory reminders, so the count means something.

The work log carries that warning inside the product, on the page itself: it is a floor, not a timesheet, not for pay and not for ranking people. That is not decoration. It is what makes the number usable.

A figure derived from recorded moments always understates. Thinking does not emit events. Reading does not either. Some of the best hours in a week leave almost no trace, so the honest reading of the number is "at least this much happened", never "this is what they did".

Which is exactly why it is worth having. A floor answers the questions a lead actually has, whether a project moved and where the work went, without pretending to a precision that would invite the wrong use. Anyone can see their own log. Seeing somebody else's requires being an admin.

Two different questions, and both deserve a plain answer.

What is stored. Project metadata: plans, tasks, decisions, memories and session summaries. Your source code never leaves your machine. Every account is isolated from every other. API keys are held as hashes rather than as keys. Free-text fields are scanned server-side and anything shaped like a secret is scrubbed before it is stored, by fourteen shape rules.

What is shown. The activity record, so you can see what happened. The heartbeats that produce the timing record what kind of event it was and when, and never the text of your prompts. Local breadcrumbs carry a fixed list of thirteen fields, all of them about the shape of an action rather than its content.

So the record answers "what happened, when, and was it proven", and it does that without holding your code or your conversations.