Coldstart is in final cutover and has not been released. The behavior on this page runs in the development build; there is no release you can install today.
The pointer is a short block of seven fields at the top of the project's progress file. It says which section is active, what kind of session is running, what the next action is, what is blocking, what to read, when it was written, and one optional line of context.
That block is the entire handoff. Everything else a new session knows, it gets by reading the project's files. Naming that boundary plainly is more useful than pretending the gap between two sessions can be closed.
[Visual 2.4 — The work-loop chain with the Pointer block enlarged into a card listing its seven fields as labelled rows: active section, mode, next action, blockers, reading list, updated, resume note. A heavy dashed vertical line is drawn immediately to the left of the card, labelled "the loss boundary — the terminal closes here". Everything left of the line is greyed and tagged "the conversation"; the card and the return arrow leaving it are drawn solid and tagged "what crosses". A small lock icon on the card's corner is labelled "one machine writer; rewritten whole".]
The problem it solves
A conversation with an agent ends when the terminal closes, and the next one starts with nothing. The usual repair is a pasted summary, which works until the summary and the project disagree. That happens quickly and quietly, because a summary is written from a memory of a discussion while the project keeps moving in files.
The pointer replaces recall with a read. It is machine-written at every close, so keeping it accurate is not a discipline anyone has to maintain by hand, and it is deliberately too small to hold a narrative.
What the seven fields carry
The active section names the piece of work in progress, and by naming it also names the plan the next session should walk into.
The mode records what kind of session this is. It is the field a planning session sets before it writes anything, and the field the boundary check reads when deciding whether a write is allowed. It is the one field on the card that other parts of the product act on rather than display.
The next action is one short sentence saying what to do, not what happened.
The blockers list what is unresolved. A refused close writes them itself, naming what is red, so a blocked project says so at the top of the file rather than in someone's memory.
The reading list is the declared set of files for the next session. It is what the start verb commits to out loud before reading, so a read outside it is visible as it happens.
The updated date says when the block was written, which is the only way to tell a current pointer from one that has been sitting through other people's work.
The resume note is one optional line of context that would otherwise have nowhere to go. It carries forward untouched until something replaces it.
Why it is rewritten whole
The pointer is never appended to. Every close replaces the whole block, and a file found carrying more than one pointer block is refused rather than merged.
Appending is exactly the failure this prevents. A pointer that accumulates has to be read carefully to work out which parts are still true, and a resume file that needs careful reading is not doing its job. There is also exactly one writer: the close tool owns the block, and the two other doors that touch it (declaring a session's mode, and creating the pointer for a new project) are the same writer entered differently, not second writers with their own opinions.
The block is size-banded, too. Growing past its band produces a warning that says to trim the reading list or the note. That is the mechanism keeping the hottest file in the project from slowly turning into prose.
When to use it, and when not
Read it at the start of every session; the start verb does this for you and states what it found. Read it yourself when you want to know where a project stands without opening a session at all: it is a plain block at the top of a plain file.
Do not hand-edit it to get past a refusal. The supported path is to fix what the refusal named and re-run the close, because a hand-edited pointer is a pointer nothing verified.
Do not use it as a project log. It holds the current address, and the session records beneath it hold the history. Anything that needs to survive as a decision rather than as a position belongs in the project's durable record.
Limits
A pointer can be stale. It is written at one session's close and reflects what that session believed when it ended. A concurrent session, a manual edit, or a close that recorded an optimistic next action all produce a block that reads confidently and points somewhere the project has left.
It is an address, not memory. It narrows the route back to the evidence; it does not carry the reasoning, the rejected alternatives, or the thing you said out loud and never wrote down. If it was not written to a file, no field here brings it back.
Its accuracy depends on the close that wrote it. A close that skipped the check walk still produces a well-formed pointer, and a well-formed pointer describing unverified work is the most misleading state this method can produce. That is why the previous page is about the checks rather than the record.
Next
That completes one unit of work. The next section is what the pointer leads to — what a fresh session can still find, and how it knows the answer is current: memory.
How current this page is
Checked on 10 August 2026 against the product's current pointer structure and its recorded release state. Seven fields is a count of what exists today; a released version may add one. To ask whether a claim here still holds, or to report one that does not, write to [email protected].