Module goal 

A goal: the run itself, written down and survivable.

A spec and a goal look alike on the page and are not the same object. A spec is design authority — you think hard, you write it, you hand it to the model as context. It is a bigger prompt. Nothing about it touches the runtime, so when the process dies there is nothing to come back to: the file is still there and the run is gone.

A goal is bound to the run. It has an id, it holds which phase is in flight, and it is on disk before the first turn, so a crash, a laptop lid, or a deliberate stop leaves something to resume rather than something to re-derive. That is the whole distinction, and it is why this lives beside crate::seal and crate::receipt rather than in a docs folder: goal says what, seal says what may not move while it happens, receipt says what came of it.

Context is referenced, not inlined. Goal::context holds paths. A goal that embeds the material it points at is a prompt again — it goes stale against the files it copied, and it grows until it is the thing you were trying to avoid re-reading.

Phases exist to bound review, not the model. The useful question is not “how long may this run” but “how many commits am I willing to read”. Ten to twenty phases is the range that has worked; nothing here enforces it, because the right number is a property of the work.

Structs

Goal

A durable, resumable objective.

GoalStore

Goals on disk, one JSON file per id.

Phase

One reviewable chunk of the objective.

Enums

PhaseStatus

Where one phase stands.

Constants

SCHEMA

Current Goal::schema.