Docket records per-commit evidence for code written by AI coding agents

Docket, an open-source tool that surfaced on Hacker News, generates a signed evidence record for every commit produced with the help of an AI coding agent. Instead of handing a reviewer a bare diff, it reconstructs what the agent was asked to do, what it tried along the way, which checks verified the outcome, and which lines no human ever opened.

The verification gap it targets

The project's README on GitHub states the problem plainly: agents produce code faster than anyone can check it, and a finished diff carries no trace of the work behind it — the first approach that failed, the test that caught it, the regions nobody examined. Harnesses already emit much of that story as a session transcript, then throw it away at commit time. Docket captures the transcript, aligns it with the committed diff, and produces a per-hunk evidence record meant to steer reviewer attention toward changes that have nothing backing them.

What a record contains

Running docket show HEAD prints the record for the latest commit, ordered by risk. For each hunk it records the origin — which harness and tool made the edit, with the model and operation named; the task the edit descends from; the intent, meaning what the agent said immediately before making the edit; and any attempt, code written into the same region and later removed together with the check that failed in between. Machine-checkable evidence such as line coverage and test executions is attached too, along with a note on whether any human touched those lines. The sample output shows metrics such as the share of added lines attributed to a recorded edit and a per-hunk "evidence density" score.

A companion command, docket explain file:line, resolves the owning commit through git blame, so a reader can start from a suspicious line of code rather than a commit hash. Docket stores only short, redacted excerpts rather than full conversations, on the grounds that whole transcripts contain secrets and grow without bound.

Storage and integrity

There is no account and no network dependency: records live inside the repository on an orphan ref, and each audited commit gains a single trailer line, next to conventions like Reviewed-by, naming the record's digest. According to the README, one-line log output stays untouched, and the digest names a locally stored, signed record rather than a URL, so history never depends on a hosted service surviving.

Records are signed with a local ed25519 key and carry a trust label of local_claimed; docket verify checks the digest, the signature and the binding to a particular commit. Every record embeds the schema version it was written against, keeping older records readable across upgrades, and docket push sends records to the remote alongside the branch.

Hooks, edge cases and opting out

Setup is docket init, which installs a prepare-commit-msg hook that writes the trailer — the audited agent never records its own audit — a post-commit hook that stores it, and hooks for Claude Code so Docket can observe edits made through the shell. Amending a commit rebuilds the record and replaces the trailer. Merge commits, and commits with nothing attributable in them, get no trailer at all.

Rebases and cherry-picks are the acknowledged weak point: git runs no prepare-commit-msg for them, so a trailer can travel onto a diff it was not built from. Docket's answer is that docket verify reports the mismatch instead of trusting the trailer. Opting out means deleting two hook files in .git/hooks; existing trailers remain as inert text in the history.

Pull requests and distribution

A GitHub Action reads whatever records a pull request's commits carry with them and posts a single comment that reorders the diff: unverified hunks are surfaced first, while boilerplate with solid coverage is collapsed beneath them. The action downloads the same static binary the developer uses, so runners need nothing pre-installed, and the version can be pinned to a tag. Docket itself ships as a single static binary for macOS, Linux and Windows on arm64 and x86-64, installed by a script that verifies SHA256 checksums; building from source is a standard go install. A demo mode builds a throwaway repository in a temp directory — an agent botches a session-fixation fix once, sees a test fail, then corrects it — and cleans up on exit.

Why it matters

As coding agents take a growing share of day-to-day commits, the bottleneck is shifting from writing code to trusting it. Docket's bet is that review becomes triage against evidence: lines with coverage and passing tests sink down the queue, unverified lines float to the top, and the reasoning behind a change — including the approaches the agent abandoned — survives rather than evaporating with the session. Keeping the evidence in-repo, on an orphan ref, makes the scheme vendor-independent.

The caveats deserve weight: the record is signed by a local key, and its account of events comes from the harness itself, so it is evidence of process rather than proof of correctness, and trailers lose meaning under rebases and cherry-picks. Even so, as a lightweight answer to the question of who checked a given piece of agent-written code, Docket sketches a direction that review tooling will likely have to follow.