Imagine the archive session finishes its work and the terminal process dies a second before anything is written down. The code may be on disk, but as far as ROOK is concerned the archive thread never moved. The write is what makes the step real, and this page explains why that rule is worth the inconvenience.
Every work machine owns its own history. Cards, answers, events, tasks and file references are appended there, so a later session reads what was recorded rather than trusting that some earlier process reached the end.
Scroll sideways for the rest of the diagram
The write is the handoff
The coding session does the thinking and authors the result. The record preserves the transition that result represents. The mechanical driver then starts the next session from what was recorded.
This is ROOK's proof-of-record rule, and it is deliberately narrow: the system is designed so state advances after the write. It buys one specific thing, which is a durable handoff between sessions that never overlap. The archive card and your answer survive in it, which is the only reason a parked thread can be picked up later at all.
A fair manual comparison
You already do a version of this. You finish a piece of work, then write the outcome somewhere: a commit message, a checklist tick, a line in a notes file. If you skip it, you usually still remember what happened, because you were there.
That last part is what stops working here. No one is watching these sessions, and each one starts without the previous one's context. An unwritten outcome is not a small gap to fill in from memory, because there is no memory to fill it from. Making the write the state change is how a chain of sessions that never met can still agree on where the work stands.
Writes go to the machine that owns the work
The archive thread's history belongs to the machine running the archive work. Writes go there while that machine is online. If it is offline, the phone shows you the thread read-only rather than letting you queue up an answer locally that might conflict with something later.
That is a deliberate limitation and worth stating plainly: ROOK is not an offline-write system. Disconnected means honest read-only.
What the rule does and does not promise
| Recording a transition proves | It does not prove |
|---|---|
| That the transition was written and is readable later | That the work behind it was correct or complete |
| That a fresh session can pick the thread up | That the next session will succeed |
| That the state did not advance on an exit code alone | That crashes cannot cause trouble |
| That every reader sees the same entry | That every reader gives it the right meaning |
Local authority is also not the same as isolation. The coding agent calls a model provider over the internet, and device identity and connectivity depend on Tailscale's coordination service. The record is local; the system around it is not sealed.
One history now exists, but you have seen it through two very different screens. The next page asks how a phone and a laptop can both display the archive thread without one of them quietly becoming a second version of the truth.
Next
See how that single history becomes useful views: projections.