The docs are up, and every fact in them came out of the code.

Product documentation goes wrong in a boring way. Somebody writes it from the feature description, which was itself written before the feature shipped, so it describes the product as hoped rather than the product as built. Then the code moves and the page does not, and a year later the docs are a museum.

So the pages were derived from the thing they describe. The permission mode table came out of logic/permission-modes.js. The list of commands the agent refuses outright, whatever mode you are in, came out of lib/hard-deny.js. The risk bands you see on an approval card are approval-risk.js. The diagnostics section is lib/doctor.js. The install page is install.sh and install.ps1 read end to end, so what the page says the script writes is what the script writes.

The page tree itself is one partial copied into all nineteen files at build time. That is the cheap fix for the oldest documentation bug there is, which is two pages disagreeing about what exists.

All six are additive. With JavaScript off, every docs page is still a complete document with a working tree, working links and working code blocks, because nothing in that list is allowed to be the only route to content. The search box is a convenience. The tree is the navigation.

The second half went up on 29 August. Engine guides is four questions asked of all three engines, one page per pair, twelve pages and an index: where a session is written on disk, what each permission mode actually allows, what happens when you resume a conversation, and how models and reasoning effort are chosen.

They exist because answering one of those properly means running all three CLIs and reading what they leave behind. Each vendor documents its own engine, and nobody outside has much reason to line the three up in one vocabulary. Termdeck drives all three, so I had to work it out anyway.

A sample of what falls out. Claude Code writes each session as a JSONL file under its projects directory, and a slug rule decides which directory it lands in. Codex writes rollout files into a dated tree and compresses the cold ones, which is why its paths resolve by id. Grok never resumes in the Claude sense at all: it re-reads session state every turn, which is why an edit you made in the terminal is always visible to it. Codex advertises a context window larger than the one you can actually use. Grok denies rather than asks in read only mode and has no plan mode of its own, which matters if you assumed the word meant the same thing in all three products.

Each row names the file its fact was read from, so the next person can re-verify instead of trusting me. That is also the reason to check: these three CLIs move fast, and a page that cites its source can be audited when they do.

Writing documentation is easy. Keeping it true through hundreds of deploys is the actual job, so both families are checked by the build rather than by my memory.

The docs checker builds its worklist from the directory, so a new page is covered the moment it is written rather than when I remember to register it. It fails on a page missing from the tree, because unreachable and absent are the same thing to a reader. It fails on a tree entry pointing at nothing. It fails on a broken internal link. And it fails on a cross page anchor naming a heading id that has since moved, which is the half of link rot nobody catches by hand: the link still works, it just drops you at the top of the page and leaves you to hunt.

The guides are generated from one dataset, and the generator refuses to write a broken family. It checks title and description lengths, duplicate slugs, duplicate titles, stray dashes and non-ASCII characters before it writes a byte. One test exists purely because of how generated page families die, which is that the three pages of a concept must not share a detail block. Thin content is the failure mode there, not a malformed tag.

Then the ordinary discipline: a documentation change rides in the same commit as the product change. Four pages caught up with already shipped behaviour on 20 August, and that is the pattern I want. Docs land late once, never twice.

Documentation asks you to take my word for what the software does. The agent does not, because it is published on GitHub under MIT: the agent source, the install and uninstall scripts, the service unit templates, an architecture document and a curated changelog. The hosted control plane at termdeck.io stays proprietary, and the licence says so in its first paragraph.

That split is the point. The piece with access to your files, your repositories and your CLIs is the piece you can read. If a docs page and the source ever disagree, the source is right and I have a bug to fix.

Search is a page filter, not full text. Ctrl K matches page names and groups, so if the word you want sits in the middle of the troubleshooting page, your browser find is still the better tool. Full text search is the obvious next thing.

There is one version, the live one. Termdeck deploys most days and the docs describe what is running now. There is no archive of what a page said in July and no version picker.

They assume a machine. Most feature pages are written for someone who has already connected one, because that takes five minutes and everything downstream is easier to describe once it is true. Reading before you sign up, the pages that make sense cold are how it works, security and privacy, and plans.