Charters - queueing the runs you have not had yet

You can usually see three sprints ahead. Writing them down as three fixed batches does not work, because units land and units get delivered between authoring a plan and running it - so by the time you reach sprint three, its batch is a description of a backlog that no longer exists.

A charter solves that by writing down the rule rather than the result.

What a charter holds

Three things, and no batch:

Field	What it is
Goal	the Sprint Goal - one product-outcome sentence
Scope rule	prose for the reader: what this run is for, and what it deliberately is not
Scope query	the selector the tool can actually resolve, for example --bugs Open
Appetite	optional; resolves from the project’s capacity at materialise time if absent

A charter carries no acceptance criteria of its own. It delivers nothing; the units it materialises carry theirs.

The queue

# queue one, with prose for the reader and a query the tool can resolve
artifact.py new --type charter --title "<what this run is for>" \
  --fields-file charter.json   # {"goal": "...", "scope": "...", "scope_query": "--bugs Open"}

# see the queue, and what the HEAD resolves to against the backlog right now
sprint.py queue show

# resolve the head against the backlog now, naming who is running it
sprint.py next --runner "<who>"

# correct a plan somebody wrote
sprint.py queue reorder --charter SC0002 --rank 1
sprint.py queue cancel  --charter SC0003 --reason "<why>"
sprint.py queue clear   --reason "<why>"

next reports what it selects. sprint plan --write is what actually opens the run - so you always see the batch before it becomes one.

Note

Only the head is resolved by queue show. Resolving every charter would be arithmetic over a backlog that the earlier runs will have changed before the later charters are reached - a number that looks precise and is not.

An unranked charter sorts after every ranked one, so adding a charter never quietly jumps the queue.

The seat review lives on the charter

A charter’s goal review is written on the charter, under a ## Seat review heading - not in local state.

That is deliberate. Local state does not travel. A charter pulled into another working copy must arrive carrying the review that judged its goal, or the next person runs a goal nobody assessed.

Calling a sprint, and stopping one

These are different acts, and the distinction matters at the close.

	What it means	What happens to the remainder
sprint stop	abandons a run: it did not reach its goal, and it says so	recorded in the handoff as carried
sprint call	finishes a run: this is as far as it goes, and that is fine	descoped back to the backlog, then the close chain runs

sprint.py call --reason "<why the rest is not being done>" --retro RETRO0001

call completes what it starts rather than telling you to. It takes the close’s own flags - --retro, --goal-verdict, --note, --apply-signoff, --principal - and forwards them, so the close’s messages never name a flag this verb rejects. With no --retro it scaffolds one and stops, exactly as sprint close does.

Caution

The remainder returns to the backlog, never forward to the next charter. Attaching it forward would make the next run inherit a batch it never approved. Each descoped unit keeps its own status, because a drop judges this batch and not the work.

Where to next

• Sprint planning - what happens once a charter is materialised.
• Review and close - the close chain call forwards to.
• A spec per run, or a sprint? - why the batch is the unit at all.