Never cut a milestone by an order between its parts; the delivery plan keeps that order #465

2026-10-21T23:30:31Z

mesh-tools commented

2026-10-21 23:30:31 +00:00

What

Playbooks 07 and 04, and the drawn overview, no longer cut a milestone by a release order. The order in which a milestone's modules reach the machines (a reader of a new manifest word before its users, an SDK change before its users) is the delivery plan's, drawn from the module graph. The prepare step still lists every part a change reaches (strict manifest readers, the SDK's seat verbs, the node-engine's decoder, a first module's registration), each as an issue of the same milestone. An order the plan cannot keep is an issue of the build and delivery system, never a cut and never a step a session takes by hand.

Why

The operator, 2026-10-22, on the prepare step of design 47's R4e (which proposed cutting it in two): "a milestone is a milestone, we shouldn't cut it"; "we have our module graph to define the order"; "that's what the delivery plan describes and is used for". The rule added by hq #456 and playbook 04's "cut by release order" said the opposite.

How it is checked

words.py, records.py, index.py and cycle.py pass locally; playbooks.html is updated with the steps.

Reviewed-by: reviewer-1803@shanks at 2b857df4b5

## What Playbooks 07 and 04, and the drawn overview, no longer cut a milestone by a release order. The order in which a milestone's modules reach the machines (a reader of a new manifest word before its users, an SDK change before its users) is the delivery plan's, drawn from the module graph. The prepare step still lists every part a change reaches (strict manifest readers, the SDK's seat verbs, the node-engine's decoder, a first module's registration), each as an issue of the same milestone. An order the plan cannot keep is an issue of the build and delivery system, never a cut and never a step a session takes by hand. ## Why The operator, 2026-10-22, on the prepare step of design 47's R4e (which proposed cutting it in two): "a milestone is a milestone, we shouldn't cut it"; "we have our module graph to define the order"; "that's what the delivery plan describes and is used for". The rule added by hq #456 and playbook 04's "cut by release order" said the opposite. ## How it is checked words.py, records.py, index.py and cycle.py pass locally; playbooks.html is updated with the steps. Reviewed-by: reviewer-1803@shanks at 2b857df4b51ea54d7d4dac6b27e9a69c22be1f57

mesh-tools added 1 commit 2026-10-21 23:30:31 +00:00

Never cut a milestone by an order between its parts: the delivery plan keeps that order from the module graph

mesh/merge-gate head 2b857df4b51e merged into trunk 73a06324dc0d — pass: the change touches no module of the mesh's graph

Details

mesh/repo-check head 2b857df4b51e merged into trunk 73a06324dc0d — pass: its merge-check.sh passed

Details

mesh/delivery delivered

Details

2b857df4b5

The operator, 2026-10-22: a milestone is a milestone; which module reaches the machines first is what the delivery plan is for. The prepare step still lists every part a change reaches, as issues of the same milestone; an order the plan cannot keep is an issue of the build and delivery system.

mesh-tools commented

2026-10-21 23:30:41 +00:00

Delivery novox/hq@2b857df4b51e — delivered since 2026-10-21T23:44:18Z

Delivery plan — builds nothing: the change touches no module of the mesh's graph

Transitions

2026-10-21 23:30 (new) → proposed (announced): novox/hq#465's head announced
2026-10-21 23:35 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit
2026-10-21 23:35 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail
2026-10-21 23:44 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move
2026-10-21 23:44 published → delivered (done): nothing for a walk to move

The commit's note under refs/notes/mesh-plan keeps every transition: git log --notes=mesh-plan.

**Delivery** `novox/hq@2b857df4b51e` — **delivered** since 2026-10-21T23:44:18Z **Delivery plan** — builds nothing: the change touches no module of the mesh's graph **Transitions** - 2026-10-21 23:30 (new) → proposed (announced): novox/hq#465's head announced - 2026-10-21 23:35 proposed → checked (checked): a verdict names this commit and the trunk's head as its trunk commit - 2026-10-21 23:35 checked → ready (accepted): the gate passed or warned, and the repository's own check did not fail - 2026-10-21 23:44 ready → published (merged): on the trunk its modules follow: merged there, and its walk opened — or nothing for a walk to move - 2026-10-21 23:44 published → delivered (done): nothing for a walk to move The commit's note under `refs/notes/mesh-plan` keeps every transition: `git log --notes=mesh-plan`.

mesh-tools merged commit 77d4a8a39e into main

2026-10-21 23:44:17 +00:00

mesh-tools deleted branch process/07-order-is-the-plans

2026-10-21 23:44:17 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/hq#465