A decision card is ROOK's bounded unit for operator attention. The coding CLI writes one clear fork, gives concrete options with consequences and recommends a path. The operator answers that card, and the answer returns to the work that asked.
This shape keeps the decision portable without turning it into an unstructured conversation. It also gives the on-device record one object to follow from question to action.
[Visual 2 — One decision card moving left to right through its complete lifecycle. It begins inside a coding session as "authored", enters the on-device record, appears on desktop and phone surfaces as "open", returns with one selected option as "answered", and reaches a fresh coding session as "act on this answer". A single thread line runs beneath every stage and the answer arrow points back to the original card.]
The card's journey
The journey begins when the coding CLI finds a choice that needs the operator's intent. It writes the card and ROOK records it. Desktop and phone surfaces render that same recorded unit rather than creating their own copies of the decision.
Once the operator chooses, the answer is recorded against the originating card. A fresh coding session can then read the situation, the chosen option and any note before acting. The card and answer remain part of the record after that handoff.
What makes a card bounded
One card presents one decision. Its explanation says why the choice exists; its options say what can be chosen; each consequence says what follows; and its recommendation makes the coding CLI's best path visible without silently taking it.
The result is smaller than a chat thread. The operator should not have to reconstruct the project from a transcript just to make one choice. The card carries the context needed for that choice and a link back to the fuller work when more detail is needed.
Limits
A card can make a fork legible, but it cannot guarantee that the options are complete or the recommendation is good. ROOK does not add another model to rewrite or rank the coding CLI's judgment. It records, renders and returns what the CLI authored. Blocking behavior also applies to one work thread; it does not promise that the rest of the queue always has runnable work.
Next
Open the unit and see its parts in Card anatomy.