novox/hq
6
0
Fork 0
Code Issues Pull Requests 6 Releases Wiki Activity

ADR 0239 and to-be 47: as built — registered at the walk's start, the forge asked through its tools
mesh/merge-gate pass: the change touches no module of the mesh's graph
mesh/delivery delivered
Details

Browse Source 
A build registered before its turn is carried by the next send to its
machines, so a published delivery asks nothing until its walk starts; the
rows the build needed (appeared, adopted, held on no walk, held then go)
and Phase B's verbs-without-probe are now said.
This commit is contained in:
jochen
2026-10-06 23:58:29 +02:00
parent 16b187d4c3
commit e1b95d09cd
2 changed files with 111 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files
03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md
+35 -22
View File
@@ -25,12 +25,13 @@ commit's journey and in what order the steps are allowed.
## The parts
```
forge's holder ──pull.updated / pull.merged──► mesh-delivery ◄──plan-moved / checked── controller
(statuses, the view, ▲ (deliveries, groups, (planner, gate,
the notes) │ the table, its state) registration,
▲ │ │ sending, walk)
└──── transition ────────┴───────────────────────┘── verbs: delivery-plan, -order, -check,
deliver, delivery-stop, delivery-walks
forge's holder ──pull.updated / .merged / .closed──► mesh-delivery ◄──checked / plan-moved── controller
(statuses, the view, (deliveries, groups, (planner, gate,
the notes) the table, its state) registration,
▲ │ │ sending, walk)
└── its tools: note, view, status ◄───────────────┘ └── its verbs: delivery-plan, -order,
-check, deliver, delivery-stop,
delivery-walks
```
- **The controller** stays the only writer of what it owns: machine declarations, bus objects, grants,
@@ -68,13 +69,17 @@ allows.
| checked | a verdict arrived | 1 minute | nothing: it is decided at once |
| ready | it passed; it waits to be merged | none | — |
| rejected | it failed its check | none | — |
| published | merged on the trunk, its first tier registered; it waits for its turn or its word | 30 minutes | `superseded` when a newer delivery to the same trunk took over its walk |
| published | merged on the trunk its modules follow, its walk opened and asking nothing; it waits for its turn or its word | 30 minutes | `superseded` when a newer delivery took over its walk; `go` when its walk started |
| held | it waits for a person | 1 day | nothing: it is the operator's |
| delivering | its walk runs | 2 hours | `delivered` when the walk's record says done; `superseded` when a newer walk closed it |
| delivering | its walk runs; its builds are asked and registered tier by tier | 2 hours | `delivered`, `failed` or `superseded`, as the walk's record says |
| delivered, failed, superseded, stopped | final | — | — |
The transitions are those of ADR 0239 decision 2. A delivery that is merged while not `ready` goes to
`held`. Its check did not pass, and only a person decides that it goes on.
`held`. Its check did not pass, and only a person decides that it goes on. A delivery merged with no walk
opened for it within ten minutes is held too, saying so: nothing it moves follows that branch, or the merge
was not heard. Nothing waits silently. **Nothing of a published delivery is registered before its walk
starts**, because a send carries every registered build that waits on its machine (ADR 0236 §4a), and a
build registered before its turn would be carried by somebody else's send.
**The machine steps.** While a delivery is `delivering`, each machine its walk reaches has a row with the
module and the build: `sent` (the first machine's send, or the rest's), `judging` (the gate's healthy
@@ -103,15 +108,18 @@ them.
In this order, each by its owner:
1. **kept**: mesh-delivery puts the delivery in its state (`deliveries`, one key per delivery; `groups`, one
key per group). Nothing is said before it is kept;
2. **said**: the event `mesh-delivery.transition`, with the delivery's id, from, to, event, why and plan
summary, and no secret or address;
3. **noted**: the forge's holder, hearing it, appends a line to the commit's note: the head while the
delivery is off the trunk, and the commit it landed as once it is on it. It appends as the mesh's own forge
account, and a line already there is not appended again;
4. **reflected**: the forge's holder edits the delivery's view, one comment on the pull request with the
state, the plan, the machine steps and the group, and sets every status of the commit with the view as its
`target_url`.
key per group). Nothing is said before it is kept. What it owes outside is kept with it and retried until
done;
2. **said**: the event `mesh-delivery.transition` (and `mesh-delivery.group` when a group's derived state
changes), with the delivery's id, from, to, event, why and plan summary, and no secret or address;
3. **noted**: mesh-delivery asks the forge's holder (`gitea_note_append`) to append a line to the commit's
note: the head while the delivery is off the trunk, the commit it landed as once it is on it, and at its
end a line of what was executed there. The forge's holder writes it in its own repository as the forge's
own account, and a line already there is not appended again;
4. **reflected**: the delivery's view, one comment on the pull request with the state, the plan, the machine
steps and the group, kept current (`gitea_delivery_view`); the status `mesh/delivery` on the head, and
`mesh/delivery-group` on every member's head (`gitea_commit_status`). Every status links to the pull
request, `mesh/merge-gate` among them.
## The verbs
@@ -131,8 +139,13 @@ In this order, each by its owner:
| `close` | H2's only verb: the transition the table names for a stalled delivery, refused otherwise |
**The controller's verbs for it** (on the mesh-controller seat): `delivery-plan`, `delivery-order`,
`delivery-check`, `deliver`, `delivery-stop`, `delivery-walks`. A person has `plans go <plan> --why`, which
does what `deliver` does under their name.
`delivery-check` (a group's heads composed, or one head checked again), `deliver`, `delivery-stop`,
`delivery-walks`. A person has `plans go <plan> --why`, which does what `deliver` does under their name and
is recorded as a hand act. The controller says every walk it keeps as `plan-moved`, from a verb's command
too.
**The forge's holder's tools for it**: `gitea_note_append`, `gitea_delivery_view`, `gitea_commit_status`. It
also announces `pull.closed`, and a merge's head and the statuses the forge holds on it.
## The store
@@ -165,8 +178,8 @@ up.
| Phase | Delivers | Done when |
|---|---|---|
| A — the owner | mesh-delivery with its table, state, verbs, events and adoption; the controller's seat, verbs, `plan-moved` and the wait; the forge holder's view and notes; the group's order and composed check | the tests of ADR 0239's *How it is checked* pass; a merge on the live mesh with mesh-delivery held is delivered by it and shown by `deliveries` |
| B — the conditions | the self-check reads `stalled`; `delivery.<id>.stalled`; H2 closing by the table | a delivery stalled on purpose is raised and closed by H2 through `close` |
| A — the owner | mesh-delivery with its table, state, verbs, events and adoption; the controller's seat, verbs, `plan-moved` and the wait; the forge holder's view, notes and statuses; the group's order and composed check | the tests of ADR 0239's *How it is checked* pass; a merge on the live mesh with mesh-delivery held is delivered by it and shown by `deliveries` |
| B — the conditions | the self-check reads `stalled`; `delivery.<id>.stalled`; H2 calling `close` (the verbs are built in A) | a delivery stalled on purpose is raised and closed by H2 through `close` |
| C — the walk itself | the per-tier walk moved into mesh-delivery behind single-send verbs, the controller's planner kept only for the built-in path | decided by its own record once Phase A has delivered for a while |
## What is not decided here