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

Merge pull request 'Design 47: one plan per group, no order lines, the Approve as the only gate (ADR 0418, 0419, 0421)' (#404) from fix/design-47-records-0418-0421 into main

Browse Source
This commit was merged in pull request #404.
This commit is contained in:
mesh-tools
2026-10-17 15:25:14 +00:00
parent aaa0647ec3 b0cfd08f7c
commit cf73f96797
1 changed files with 126 additions and 64 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
+126 -64
View File
@@ -4,6 +4,10 @@ status: in-progress
code: [mesh-controller, mesh-catalog modules/mesh-delivery]
updated: 2026-10-17
decisions:
- "ADR 0421"
- "ADR 0420"
- "ADR 0419"
- "ADR 0418"
- "ADR 0408"
- "ADR 0407"
- "ADR 0406"
@@ -30,7 +34,6 @@ decisions:
- "ADR 0270"
- "ADR 0267"
- "ADR 0250"
- "ADR 0249"
- "ADR 0239"
- "ADR 0238"
- "ADR 0233"
@@ -42,12 +45,13 @@ decisions:
**A change reaches the machines in one of three ways, all owned by mesh-delivery: a hotfix (one pull request,
delivered at its merge), a feature (one branch name across its repositories: in two or more, one delivery
group merged together and delivered member by member in its order; in one, a lone delivery), or an epic (a run of milestones, each delivered as a feature). The trunk is what runs; there
is no "release branch"** (ADR 0401).
group merged in one pass on the operator's one Approve and delivered by one delivery plan; in one, a lone
delivery), or an epic (a run of milestones, each delivered as a feature). The trunk is what runs; there is no
"release branch"** (ADR 0401, ADR 0418 §1, ADR 0421 §2).
**Every step starts on an event, and the state lives on the bus.** The forge's events, the controller's
events and the nodes' reports move a delivery; the bus's own rules keep the queues, the merge window and the
order; and one chain, from module to commit to build to rollout to assignment, is kept in the bus's
order of a plan's tiers, which only the module graph gives (ADR 0419); and one chain, from module to commit to build to rollout to assignment, is kept in the bus's
key-value store as its only source (ADR 0406, ADR 0407, ADR 0408). A running delivery never touches merging:
every merge is recorded at once for the next delivery plan of what it touches.
@@ -68,7 +72,7 @@ controller's delivery tables and the timers that polled them.
(deliveries, groups, a key per │
pull request, the state table) ▼
node-engine on every node
builders (build seat) ◄── work queues: delivery builds, ready checks, other checks ───────────────────────── (reports; backups first)
builders (build seat) ◄── work queues: delivery builds, approve-asked checks, other checks ───────────────── (reports; backups first)
```
- **mesh-delivery** (the seat `mesh-delivery`) owns hotfixes, features and milestones as deliveries and delivery
@@ -82,8 +86,8 @@ controller's delivery tables and the timers that polled them.
the build seat's own account, and take their jobs from the bus's work queues, delivery builds first
(ADR 0405, ADR 0406).
- **The forge module** (`gitea`) publishes every forge event on the bus through the forge's system webhook
(issue 729): pull requests updated, synchronized, labeled, unlabeled, commented, merged and closed, and
commit statuses. It sets statuses, keeps the delivery's view as one comment on the pull request, and appends
(issue 729): pull requests updated, synchronized, merged and closed, and commit statuses; no label or comment
moves a delivery, and mesh-delivery subscribes to none (ADR 0421 §11). It sets statuses, keeps the delivery's view as one comment on the pull request, and appends
to the commit's note under `refs/notes/mesh-plan`.
- **Each node's backup seat** (`node-backup`) backs up the data a delivery plan moves there before the plan
sends anything (ADR 0404).
@@ -95,7 +99,7 @@ controller's delivery tables and the timers that polled them.
| Way | What it is | How it is delivered |
|---|---|---|
| **hotfix** | one pull request in one repository | at its merge, as a lone delivery; a lone merge is cut at once (ADR 0282 §2, as ADR 0304 §1 changed it) |
| **feature** | one branch name across its repositories; in two or more, its pull requests are one delivery group; in one, a single pull request | a group is merged together once its composed check passes and every member is marked, reviewed and approved, then delivered member by member in its order (ADR 0239 §16); in one repository, as a lone delivery like a hotfix |
| **feature** | one branch name across its repositories; in two or more, its pull requests are one delivery group; in one, a single pull request | a group is merged in one pass once its composed check passed at every member's head and the operator gave the group's one Approve (ADR 0418 §4, ADR 0421 §2); its merges are one batch and one delivery plan, each module built once and sent once (ADR 0418 §1); in one repository, as a lone delivery like a hotfix |
| **epic** | a run of milestones in one design (playbook 04) | each milestone is a feature, delivered when its own group is ready; the next starts when the previous one's delivery plan is done |
- **The trunk is what runs.** Every delivery is cut from a repository's trunk. A merge into any other branch
@@ -106,10 +110,12 @@ controller's delivery tables and the timers that polled them.
- **A milestone is functional, its delivery shaped technically.** A milestone is named by what the operator or
the mesh can do once it is delivered; how it ships is shaped by the delivery plan its changes would have, asked of
the controller's planner through mesh-delivery's `what-if` (ADR 0239 §3): the modules it moves and their fan-out.
- **What a merge waits for.** mesh-delivery merges a group's members once the group's composed check passed at
their heads, the independent reviewer marked each member ready (ADR 0364 §1, §2), each member carries the
review ADR 0382 §6 asks, and the operator approved each merge into main (ADR 0398 §3). The operator's Approve is
asked for every merge into main, a hotfix's too (the operator, 2026-10-16 23:40).
- **What a merge waits for.** After its checks, a merge waits for one act of a person: the operator's Approve,
asked as soon as both required checks passed at the head (ADR 0421 §1, §3). For a group the Approve is asked
once, when every member's checks and the group's composed check passed, and covers every member's head
(ADR 0421 §2); it is the review ADR 0382 §6 asks (ADR 0421 §9). No ready mark, label, comment, forge review or
recheck stands before it. The operator's Approve is asked for every merge into main, a hotfix's too
(ADR 0398 §3; the operator, 2026-10-16 23:40).
## A delivery
@@ -121,8 +127,12 @@ Its id is `<owner>/<repository>@<twelve characters of its commit>`. It holds:
its diffset (ADR 0238 §2, as ADR 0323 §1 changed it);
- its **state**, its **transitions** (the last hundred, each with when, the event, from, to and why), and its
**machine steps** while delivering;
- its **Approve**: the ask, the operator's answer with its warrant, and the review record the pull request was
opened with (ADR 0421 §5, §8);
- once merged, **the commit it landed on the trunk as**, and the delivery plan that delivers it: the plan of the
batch that answers its merge, which may carry a later commit of its repository that contains it.
batch that answers its merge, which may carry a later commit of its repository that contains it. Every member
of a delivery group is delivered by the same plan, and its delivery ends with that plan's result
(ADR 0418 §1).
**One key per pull request.** Beside the delivery, mesh-delivery keeps one key per open pull request on the
bus: its head, the trunk commit its current check is asked against, and its verdict, written by
@@ -141,7 +151,7 @@ allows.
|---|---|---|---|
| proposed | a head was announced and is being checked | 1 hour from when its check is asked; none while its verdict is out of date and no check is asked | nothing: the check's own watchdog (S6) speaks |
| checked | a verdict arrived | 1 minute | nothing: it is decided at once |
| ready | it passed; it waits to be merged | none | — |
| ready | it passed; its Approve is asked (a group member's once the group is ready), and it waits for it and the merge | none | — |
| rejected | it failed its check | none | — |
| published | merged on its trunk, recorded in a batch; it waits for its plan to start | 30 minutes | `superseded` when a plan that does not answer its merge took over its plan; `go` when its plan started |
| held | it waits for a person: a failed backup (ADR 0404 §4), a policy of record; it ends by itself when it moves nothing or a later merge covers it (ADR 0270) | 1 day | nothing: it is the operator's |
@@ -152,7 +162,8 @@ allows.
when the builder clones it, and the verdict names both. When another merge moves the trunk, a `ready`
delivery goes back to `proposed` on the event `trunk moved`, and mesh-delivery asks the check of every active,
cleanly merging open pull request into that trunk at once (ADR 0395, *A move of the trunk asks every check
again* below). The row from `proposed` to `checked` takes only a verdict that names the trunk's head.
again* below). An Approve already asked stays; the merge waits for the fresh check, and the Approve is not asked
again for a trunk move (ADR 0421 §1, §3). The row from `proposed` to `checked` takes only a verdict that names the trunk's head.
**What needs no person ends by itself** (ADR 0270): a merge that moves nothing is `delivered` at its merge; a
merge a later delivered merge contains is `covered`, by the forge's word that the later merge commit contains
@@ -170,23 +181,29 @@ nodes' reports, never inferred from time.
## Order without a person
*ADR 0239 §11 and §12, ADR 0249, ADR 0402.*
*ADR 0419, ADR 0418 §2.*
A delivery group's order is a table of pairs, each with the rule that won (ADR 0249 §3). The controller's
`delivery-order` infers it from the manifests and the module graph; a person writes an `after: <repository>`
line only where the rules cannot see the order.
A delivery group has no order among its members, and nobody writes one (ADR 0419 §1). Inside a plan only the
module graph orders: the planner orders the build and deploy tiers by edges between modules, never between
repositories or members (ADR 0418 §2, ADR 0419 §3). Modules with no edge between them share a tier.
| Rank (highest first) | Rule | Read from |
| Edge | A module goes before | Read from |
|---|---|---|
| 1 | *declared*: an `after:` line | the member's description |
| 2 | *built by* and *version skew* | the module graph and the change |
| 2 | *verb before caller*: a member adding a verb to a seat's served verbs before a member adding that verb to an invoked verb | the manifests (ADR 0402) |
| 2 | *SDK before its users*: a member changing `mesh-sdk` before every member whose modules are built on it | the module graph (ADR 0402) |
| 3 | *engine before controller* | module names |
| 4 | the repositories' names | — |
| *built by* and *stands on* | the modules built by it or standing on it | the module graph |
| *SDK before its users* | every module built on the SDK, `mesh-sdk` | the module graph |
| *verb before caller* | a module whose change adds to its invoked verbs a verb this module's change adds to a seat's served verbs | the manifests |
| *version skew* | (the controller, when the plan moves it) every module whose manifest the plan changes | the change |
Rules of one rank in opposite directions reject the group, naming both members, both rules and the line that
would settle it (ADR 0249 §4).
- **Engine before controller is the one default.** When a plan moves both the node-engine and the controller and
no edge orders them, the node-engine's tier comes first; an edge either way wins over it (ADR 0419 §4).
- **Each tier says the edge that placed it.** The plan, `delivery-order`, `show` and the plan's note name, for
each module placed after another, the edge and its rule, and where the default was overruled, the edge that
overruled it (ADR 0419 §5).
- **A cycle is refused before anything merges.** Edges that form a cycle fail the group's composed check, or a
lone pull request's check, naming every module and edge in it. The way out is in the change itself (a verb
promised optional before it is required, ADR 0246), never an order typed by a person (ADR 0419 §6).
- **No `after:` line is read.** mesh-delivery reads no `after:` line, no refusal asks for one, and a description
that holds one is told once on its pull request that the line is not read (ADR 0419 §2).
**The SDK by version.** A Go module names the SDK by its released version and fetches it from the mesh's forge,
checked against its recorded checksum; vendored copies go. Inside a group, a member may name the SDK member's
@@ -201,10 +218,10 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
*ADR 0323, ADR 0350, ADR 0395, ADR 0406.*
- **Three work queues, taken in order.** Delivery builds go on a work-queue stream of their own; checks of pull
requests marked ready on a second; every other check on a third. A builder takes from the first, then the
requests whose Approve is asked or given on a second (ADR 0421 §10); every other check on a third. A builder takes from the first, then the
second, then the third. Each check stream has one subject per pull request and keeps only the newest request:
a newer request replaces one still waiting, by the stream's rule. A ready mark publishes its pull request's
check request on the ready stream; a request left behind on the third for a head and trunk commit already
a newer request replaces one still waiting, by the stream's rule. The fresh check of such a pull request, asked
on the merge path, is published on the second stream; a request left behind on the third for a head and trunk commit already
judged or running is acknowledged and dropped when taken, by reading the pull request's key. Nothing pauses the
worker or deletes and republishes a request (issue 558).
- **A running check stops itself.** It watches its pull request's key and stops when the head or the trunk
@@ -222,15 +239,15 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
- A trunk move asks the check of every active open pull request into that trunk that merges cleanly, against the
new head; a conflict is told once on the pull request, not checked.
- A pull request with no push and no ready mark for 7 days is left out; a push, a ready mark or a recheck asks
its check.
- For a group, a move asks each member's own check, and the composed check runs again through those rechecks; a
move made by a member merging in the group's order asks the other members nothing.
- A pull request with no push for 7 days and no Approve asked or given is left out; its statuses say out of date
and that a push or a recheck asks its check (ADR 0421 §10).
- For a group, a move asks each member's own check, and the composed check runs again through those checks; the
group's own merges, made in one pass on its Approve, ask its members nothing again (ADR 0418 §4).
- Its cost is at most one check per active, cleanly merging pull request per trunk move; issue 944 measures it.
### A delivery group's checks
*ADR 0239 §14, ADR 0323 §6, ADR 0382, ADR 0403.*
*ADR 0239 §14, ADR 0323 §6, ADR 0382, ADR 0403, ADR 0418 §4, ADR 0421 §2, §9.*
- **The composed check is each member's gate.** The group's composed check composes every machine with all
members' heads, each merged into its own trunk's head first, judged by the controller built from the group's
@@ -242,20 +259,39 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
heads exists. A member's new head, close or base move puts the composed verdict out of date, and with it every
member's gate. When mesh-delivery cannot say the groups, the pull request is checked alone and its verdict
says so (ADR 0382 §1).
- **A member merges only with its group passed and reviewed** (ADR 0382 §6), and in the group's order
(ADR 0364 §8).
- **A group merges in one pass, with no order.** Once the composed check passed at every member's head and the
operator's one Approve covers those heads, mesh-delivery merges every member in one pass, no member waiting for
another's merge or delivery (ADR 0418 §4). The Approve is the review ADR 0382 §6 asks: the merge tool reads its
warrant for those heads in place of an approving forge review (ADR 0421 §9). A member the forge refuses is
merged again on its fresh check while the group's batch stays open for it.
## Ready marks and the merge
## The Approve and the merge
*ADR 0364, ADR 0406 §1.*
*ADR 0421, ADR 0398 §3, ADR 0406 §1.*
The independent reviewer marks a pull request ready at the reviewed head with the label `mesh/ready` and a
comment `ready at <full sha>`, through `mesh-delivery.mark-ready`. The forge's `labeled` and `commented` events
reach mesh-delivery in seconds; once both required checks passed against the trunk's head, it asks the operator's
Approve for a merge into main, with the pull request, its issues, the reviewer's verdict and the delivery plan, and
merges the marked head through the forge's merge tool on that Approve (ADR 0398 §3). When the trunk moved, the merge tool asks the fresh check, and the event
of its passing verdict asks the merge again; no timer asks it. A push clears the mark (the `synchronized`
event), and a failed check is said once and listed by `stalled`.
- **Asked as soon as the checks pass.** When a pull request's delivery reaches `ready` (both `mesh/merge-gate` and
`mesh/repo-check` passed at its head against its trunk's head), mesh-delivery asks the operator's Approve of its
merge into main at once, on a channel that proves who answered (ADR 0274; Telegram today). The ask names the
pull request, its issues, the reviewer's verdict, the delivery plan and the trunk commit the checks judged. A
verdict that names a trunk commit the trunk had already left raises no ask: mesh-delivery asks that head's check
against the trunk's head, and its passing verdict raises the ask (ADR 0421 §1).
- **A group is asked once.** One ask names every member and its head, once every member is `ready` and the
composed check passed at those heads; one Approve covers them all (ADR 0421 §2).
- **The reviewer's verdict is attached, not a gate.** The review finishes before the push (playbook 07), and the
session that opens a pull request gives its review record: who reviewed it, the commit the review approved and
the verdict. The ask carries it; with none, or one naming another commit, the ask says so in its first line and
the operator decides (ADR 0421 §5).
- **The merge.** mesh-delivery merges through the forge's merge tool at the heads the Approve names, only while
they are still the heads and both checks passed against the trunk's head. When the trunk moved, the merge tool
asks the fresh check, and the event of its passing verdict asks the merge again; no timer asks it, and no person
rechecks (ADR 0421 §3, §12).
- **A push or a Decline ends the Approve.** A new head ends its ask or its Approve, for a group every member's, and
is said once on the pull request; the new head is asked again once its checks pass. A Decline merges nothing and
is said once (ADR 0421 §6).
- **A failure is said, never merged past.** An approved head whose check failed is said once on the pull request
and listed by `stalled`; so is a merge the merge tool kept refusing for an hour (ADR 0421 §7).
- **Recorded.** The ask, the answer with its warrant and the review record are kept on the delivery, shown by
`show` and said in mesh-delivery's log; the merge's transition names the Approve (ADR 0421 §8).
## The merge window and the batch
@@ -269,12 +305,19 @@ event), and a failed check is said once and listed by `stalled`.
refreshed by each merge into the batch, beside a key set once when the batch opens whose time to live is
`merge-window-at-most` (10 minutes). The first to expire closes the batch, heard by a watcher; no cutter
polls. A stop that records merges again into the open batch closes its window too (ADR 0299 §3).
- **A group's merges are one batch.** A batch holding a merge of a delivery group with a member not yet merged
does not close when either key expires; once the group's last member merged, the window runs again from that
merge. A group whose last member has not merged ten minutes (`merge-window-at-most`) after its first raises a
condition naming the member and why, and nothing of the group is delivered while it waits (ADR 0418 §3).
- **A lone merge is cut at once**: no batch it shares a repository, module, graph edge or delivery group member
with is assembling (ADR 0282 §2, ADR 0304 §1, ADR 0306).
- **The plan.** A closed batch becomes one delivery plan: every commit in it, tiered along the module graph
across repositories, at most one commit per repository, the latest of its trunk. It answers every merge in the
batch, its own commits and the earlier merges a later commit contains (ADR 0276 §2, as ADR 0299 §7 changed it).
- **A plan fixes its commits when it starts.** A plan starts at its first send, after mesh-delivery's word, and
across repositories, at most one commit per repository, the latest of its trunk, each module it moves built once
and sent once to each node that runs it. It answers every merge in the batch, its own commits and the earlier
merges a later commit contains (ADR 0276 §2, as ADR 0299 §7 changed it; ADR 0418 §1). No member of a group has
a turn: only the module graph orders its tiers (ADR 0418 §2).
- **A plan fixes its commits when it starts.** A plan starts at its first send, after mesh-delivery's word, given once for a
group's plan when every member is merged (ADR 0418 §2), and
from then nothing that merges changes it. A plan still waiting for its word is folded into the next batch
(ADR 0276 §4).
- **Plans that share something run one after another.** A batch that shares a repository, a module or a graph
@@ -282,7 +325,9 @@ event), and a failed check is said once and listed by `stalled`.
that shares none runs beside the open ones, so a hotfix is never held by an unrelated feature's delivery.
- **The ends.** A plan done ends every delivery it answers: `delivered` for its own commits, `covered` for an
earlier merge it carried by a later commit. A plan that failed fails its own commits' deliveries; each earlier
merge it answered is then delivered on its own commit, the newest first, until one is delivered (ADR 0276 §3).
merge it answered is then delivered on its own commit, the newest first, until one is delivered (ADR 0276 §3). A
group's plan fails as one: no member is stopped because another failed, what earlier tiers delivered stays, and
the fix is a new change (ADR 0418 §5).
- **Shown.** `plans` lists the open batch first, with its window's time left and its merges, and a batch waiting
behind an open plan names that plan; the controller says the batch as `plan-moved` in the state `assembling`.
@@ -325,9 +370,9 @@ nothing, and the plan says so for that node.
One plan carries every merge of its batch, so a stop ends only the change it is for:
- **A group's stop.** When a member after a failed one is stopped and its plan is open, mesh-delivery asks
`delivery-stop` for that plan with the stopped members' merges to leave out. The controller ends the plan and
records every other merge it answered again in the open batch of its kind, whose window the stop closes.
- **No stop by member.** A group's plan fails as one (ADR 0418 §5), so mesh-delivery asks no stop of a member
after a failed one. The mechanism stands for a person's stop with the way `again`: the controller ends the plan
and records every other merge it answered again in the open batch of its kind, whose window the stop closes.
- **What is left out with it.** A later merge of the stopped merge's repository, and a merge that moves a
module a left-out merge moves, would deliver the stopped change; each is left out too, its delivery `stopped`,
naming why.
@@ -426,27 +471,29 @@ forge module's files of what it announced (ADR 0406 §6).
| Verb | Answers or does |
|---|---|
| `deliveries` | every delivery not final, the final ones of the last day, and every one `stalled` still lists |
| `show` | one delivery or group whole: plan, transitions, machine steps, order, the chain's links |
| `groups` | every group with its members in order and its derived state |
| `show` | one delivery or group whole: plan, the edge that placed each tier, the Approve, transitions, machine steps, the chain's links |
| `groups` | every group with its members and its derived state |
| `what-if` | the delivery plan a diffset would have, asked of the controller's planner |
| `table` | the state table and the machine-step table, with bounds and H2's repairs |
| `stalled` | every delivery held past its bound, with the transition H2 may take |
| `mark-ready` | a reviewer's mark at a head: the label and the `ready at` comment, by the mesh's own forge account |
| `recheck` | a check asked again for a delivery whose verdict is out of date (ADR 0395 §6) |
| `recheck` | an exception verb, no step of the flow: a check asked again for a proposed delivery nothing else asks again, an inactive one or a failed verdict gone out of date (ADR 0395 §6, ADR 0421 §12) |
| `release` | a held delivery goes on, with why; for a failed backup it asks the backups again |
| `stop` | a delivery to stopped, with why; on a shared plan it first answers what it would take down (ADR 0299) |
| `close` | H2's only verb: the transition the table names for a stalled delivery |
| `retire-history` | held history to retired (ADR 0250) |
| `times` | each class's budget, the week's median and worst delivery time, and the deliveries over budget |
**The controller's verbs for it**: `delivery-plan`, `delivery-order`, `delivery-check`, `deliver`,
**The controller's verbs for it**: `delivery-plan`, `delivery-order` (the edges that order a plan's tiers,
ADR 0419 §2), `delivery-check`, `deliver`,
`delivery-stop`, `delivery-walks`, and `plans` (the open batch, the open plans, and a what-if for a repository
and its files). A person has `plans go <plan> --why`.
## The bootstrap
- A plan that moves the controller, the node-engine, the tool runner, the bus or mesh-delivery is the
controller's own, started by the merge; mesh-delivery records it (ADR 0239 §31).
controller's own, started by the merge; mesh-delivery records it (ADR 0239 §31). Such a merge shares one batch
and one plan with the other merges of its delivery group, and that plan is started by the controller when the
group's batch closes, not by its own merge (ADR 0418 §6).
- Any other plan waits for `deliver` while the seat has a holder on record; with none, the controller starts it.
- A replaced controller or mesh-delivery carries on from the bus: the keys, the queues and the durable
consumers hold every step, so nothing is lost or repeated (ADR 0406 §6).
@@ -456,14 +503,17 @@ and its files). A person has `plans go <plan> --why`.
What the build proves before this design is implemented (research 055's direction):
1. A feature across the controller and the catalogue with a new seat verb is delivered as one group, with no
`after:` line, no two steps and one composed check.
`after:` line, one composed check, one Approve and one delivery plan: its merges are one batch, each module is
built once and sent once, its commits are carried by that one plan, and the plan names the edge that placed
each tier.
2. An SDK change and a Go module using it are delivered as one group.
3. A data module is backed up before a delivery moves it, and a failed backup holds the delivery.
4. A build on any builder uses the installed toolchain with no container, and a toolchain update rebuilds only
modules of that language when its version changes.
5. Two merges into one repository within a minute leave each open pull request with one queued check, by the
stream's rule.
6. A ready mark is acted on within seconds of its event.
6. The operator's Approve is asked within seconds of the event of a pull request's checks passing, with no ready
mark, label or comment written by anyone.
7. A controller replaced in the middle of a rollout resumes it with no step lost or repeated.
8. The merge window closes by its key's expiry.
9. A hotfix to a module the running feature's delivery does not touch reaches the machines in minutes, beside it.
@@ -480,6 +530,13 @@ What the build proves before this design is implemented (research 055's directio
- The window cutter, the merge catch-up timer, the rollout ticker, mesh-delivery's tick, reconcile and
ready-mark poll, the forge's poll as a trigger, the queue reordering, the forge-asking cancel, and the forge
module's announcement files (ADR 0406, ADR 0407).
- The ready mark: the label `mesh/ready`, the `ready at` comment, `mark-ready`, the forge module's
`ready-authors` setting, and mesh-delivery's subscriptions to labeled, unlabeled and commented events
(ADR 0421 §4, §11); a recheck by hand as a step of the flow (ADR 0421 §12).
- A group's order: `after:` lines, the ranked rules and the order of the repositories' names (ADR 0419, which
supersedes ADR 0249).
- Delivery member by member, a stop of a member after a failed one, and the own path's separate batch for a
group's merges (ADR 0418 §1, §5, §6).
- The controller's tables of builds, build requests, rollouts and their tiers, batches and merges, and
assignments; the record mirrors, probe D17's audit and healer H6 for those kinds (ADR 0408).
@@ -492,12 +549,17 @@ when the previous one's delivery is done.
|---|---|---|---|---|
| 1 | A merge during a running delivery is never dropped and needs no person's release; the merge window lives on the bus; a rollout that shares nothing with an open one runs beside it | 8, 9, 11 | mesh-controller | 973 (with the rest of 525); delivered 2026-10-17 (mesh-controller #366, #367) |
| 2 | A ready mark is acted on within seconds, and each pull request has at most one waiting check | 5, 6, 7 | mesh-controller, mesh-catalog (mesh-delivery, gitea) | 974, 975, 976; delivered 2026-10-17 in one plan (mesh-controller #368, mesh-catalog #345) |
| 3 | A feature with a new seat verb across the controller and the catalogue is delivered as one group: no `after:` line, one composed check, no "release branches" | 1 | mesh-controller, mesh-catalog (mesh-delivery) | 977, 978 |
| II | phase II: build-agent and route-proxy live whole in mesh-controller, in two releases under ADR 0420 (accepted 2026-10-17): release 1 has the controller accept a reviewed move and mesh-delivery announce each merge with its Approve; release 2 is the move | — | mesh-controller, mesh-catalog (mesh-delivery, build-agent, route-proxy) | release 1: 1025; release 2: 1019 |
| 3 | A feature with a new seat verb across the controller and the catalogue is one group, one batch, one delivery plan and one Approve: no order lines, no ready mark, each module built and sent once | 1, 6 | mesh-controller, mesh-catalog (mesh-delivery, gitea) | 977, 978, 1022; 605 (1021 closed as its duplicate) is resolved by this build (ADR 0419 §7) |
| 4 | A delivery backs up the data it moves first, and a failed backup holds it and is said | 3 | mesh-controller, mesh-catalog (mesh-delivery, the backup seat's holder) | 980 |
| 5 | One read of a module on a node names the commit, build and rollout that put it there | 10, 12 | mesh-controller, mesh-catalog (mesh-config, nats) | 981 |
| 6 | Builds use installed toolchains with no container, builders fetch over SSH with their own key, and an SDK change ships in one group with its users | 2, 4 | mesh-catalog (build modules, build-agent, ssh-client, gitea), mesh-controller, mesh-sdk | 979, 971 |
The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971.
The issues are linked `depends-on` in this order; 976 depends on 975, and 979 also on 971. Phase II is not a
milestone of this design's own: it was put before milestone 3 by the operator on 2026-10-17, and its release 2
is opened only once release 1's delivery plan is done. Milestone 3 builds ADR 0418, ADR 0419 and ADR 0421
(issues 977, 978 and 1022). Acceptance test 6 spoke of a ready mark when milestone 2 was delivered; restated for
the Approve, it is proved again by milestone 3.
## What is not decided here