Each work machine owns its ROOK history. Cards, answers, events, tasks and file references are appended to a warehouse on that machine, so a later session or surface can read what was actually recorded instead of depending on a process that happened to finish.
[Visual 3.1 — A work machine contains one append-only timeline. Five entries are stacked in order: task, event, decision card, answer and file reference. A new event enters only at the bottom, while the older entries remain fixed. Beside the timeline, a workflow arrow pauses before a small marker labelled "recorded" and continues only after it. A caption reads: "process exit is not the state change; the recorded event is".]
The write is the handoff
A coding session authors its work and the record preserves the resulting transition. The mechanical driver can then start the next session from recorded state rather than treating an exit code as proof that the project advanced.
This is ROOK's proof-of-record rule. It is deliberately narrow: the system is designed so state advances after the write. The record supplies a durable handoff between fresh sessions, including the card and answer that let a parked thread return later.
Writes go to the origin work machine while it is online. If that machine is disconnected, a surface is honestly read-only rather than collecting a second offline queue that might conflict later.
Limits
On-device authority does not mean that nothing leaves the machine. The coding CLI still calls a model provider over the internet. Device identity and connectivity rely on Tailscale's coordination service. Those dependencies belong beside the local-record claim because they define its real boundary.
The design also does not promise crash immunity or automatic retry convergence. Recording a transition proves that the transition was written; it does not by itself prove that the content was correct, complete or interpreted correctly by every reader.
Next
See how that single history becomes useful views: projections.