The archive work has now produced four separate things: a queued task, a decision card, your answer and a session's result. This page is about where those four live. ROOK keeps them in one append-only history on the machine doing the work, and every screen reads from that one history rather than keeping its own.
The record is that history. Append-only means new entries are added at the end and earlier entries are not rewritten, so what happened stays readable in the order it happened.
Four moments, one history
Each of those four moments was created by a different actor at a different time. The coding agent queued the task and raised the card. You answered, possibly from a phone, possibly days later. A fresh coding session implemented the choice and recorded what it did.
Nothing joined them except that they were appended to the same history in order. That is enough for a later session to read the archive thread and see the question, the answer and the work, without any earlier terminal still being open.
You will also see this history called the warehouse. Same thing: the warehouse is the on-device store that holds the record.
A fair manual comparison
Without ROOK, you already have places to put these four moments. The task goes in an issue tracker, the question goes in a note, the answer goes in a reply to that note, and the result is visible in the commit history. For one thread over one afternoon, this is completely adequate, and reaching for anything more would be ceremony.
The cost appears when the moments spread out. The issue, the note, the reply and the commit each live in a different system with its own ordering, and only you know they belong together. Rebuilding the archive thread means opening four tools and remembering which entries matched. ROOK's version of this is one list, in one order, on one machine.
Presentation is not authority
The desktop dashboard and the phone app both show the archive thread. They arrange it differently, because a laptop can show a wide board and a phone shows the one card that needs an answer. Neither of them stores a competing version of what happened.
That is the distinction the rest of this section rests on. A screen presents recorded state. The record owns it. If a screen is closed, replaced or rewritten, the archive thread is unaffected.
State also advances on the write rather than on a successful exit. ROOK is designed around proof-of-record: the archive work counts as advanced when the result is recorded, not because a command finished without an error.
What one record gives you
| It gives | It does not give |
|---|---|
| The archive task, card, answer and result in the order they happened | Proof that any of them was correct |
| A readable thread for a session that starts fresh next week | Proof that the recorded content was complete |
| One place a screen can be rebuilt from | Proof that every screen shows it well |
| A history no surface can quietly overwrite | Immunity from crashes or automatic retry convergence |
Append-only protects the order and the survival of entries. It does not make an entry true. A card can ask a poorly framed question and still be recorded faithfully.
The record is also on your machine, not isolated from the world. The coding agent calls a model provider over the internet, and device identity and connectivity depend on Tailscale's coordination service. Those two dependencies belong beside any claim about local authority.
The next page takes the same four entries and asks the harder question: why does ROOK wait for the write before treating any of them as real?
Next
Start with where the history lives: the on-device record.