Templates

C1Planning templates

This section covers the checklist template and the ten nodes of the loop that produce a checklist, each owning one kind of decision and closed by a gate, with the repair edge running between them, as shown in C1·dthe ten nodes. C1·achecklist generator is the grammar's own checklist template record, and C1·brendered checklist is the surface it emits. That surface carries what is true now and what remains, as described in derived state, and C1·cverification report is the verdict that travels with it.

C1.1Produced by nodes, derived by deletion

A checklist written in one sitting records the plan its author imagined. A checklist says most of the units are done, two were undone by a later change, the bar still reads the same, and the next reader re-implements finished work while skipping the undone. A decision made by the wrong node is made without the evidence the owning node would have gathered.

For this reason a checklist is produced by owned, gated nodes, and its state is derived rather than typed. A closed task is deleted rather than ticked, so the remaining set is the work and never a count. In practice, the nodes are walked in order and no node makes a decision another node owns. A task leaves the surface only once it is both done and verified, and the walk stops when the objective sentence reads true against the tree.

To check this, name for each unit of a rendered checklist the node that decided it and the evidence that node read. A unit that cannot be traced to a node was authored, and a status marker on the surface stopped being true the first time the tree changed. A one-task change still walks every node, because a one-line fix can be a fix the project did not need, and orientation is what finds that out. What scales down is the size of each node's output, never the node set.

The nodes are the derivation loop applied to a plan. Verification judges the reasoning, not the implementation, and its result line routes findings to the repair edge rather than forward, and an unknown to blocked. The commit node numbers the tasks only once the order is stable, and every phase it renders carries the genesis stage its node derived rather than a role label written beside it.

A task's contract has five fields, and none of them is inferred. They are the change, the file, the evidence that proves it landed, the verifier that reads the evidence, and the non-goal, which lets the next reader refuse the addition that would have widened the task. A report carries the verdict with its standing, the domain it was measured over, and the reach it covered. The standing is derived in verify the verifier, and the reach is read as coverage, as described in a report, not a checkbox. A pass rate is a count no step derived, and the template has no field for one.

C1·dthe ten nodes
flowchart TB
    orient["Orient · observe before plan"]
    intent["Intent · worth before work"]
    see["See · the lenses, the relational edges"]
    derive["Derive · principles and protocols by fit"]
    project["Project · phases in genesis order, the four axes"]
    act["Act · atomic tasks with evidence contracts and named ripple"]
    constrain["Constrain · admissible, on budget, on branch"]
    verify["Verify · the reasoning, against evidence, with its population"]
    commit["Commit · one terminal, every box unchecked"]
    terminate["Terminate · saturated, complete, verified"]
    orient --> intent --> see --> derive --> project --> act --> constrain --> verify --> commit --> terminate
    verify -. the repair edge · back to the earliest owning node, bounded .-> derive