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

Take in round 1 of design 47's G review: hear what nodes run, say what the forge is owed, reach the forge by its seat

Browse Source 
The reviewers found a seat's pass waiting on a call to a node that may be away, acts owed to the forge
that could be lost or done twice, a seat git that missed the gate's and half the parts' forge calls and
events, a merge that still judged a check the operator removed, and waits with no bound or condition.
The design now keeps what each node runs from its running events, makes every owed act safe to repeat
with its outcome said and recorded, gives the seat git every call and event with its act verbs granted
by the holder's callers, orders forge, bridge and gate with a way back, adds module-held and
check-could-not-run, numbers tests 56 to 60, and says how the store seat's holder takes its own build.

Claude-Session: https://claude.ai/code/session_01NcbgfFfQ4Z9UE5jK32PmE5
This commit is contained in:
jschoubben
2026-11-09 19:21:49 +01:00
parent 7f2f37d9e6
commit 2fd96e1e4e
3 changed files with 264 additions and 107 deletions
Download Patch File Download Diff File Expand all files Collapse all files
00-META/glossary.md
+4 -3
View File
@@ -813,9 +813,10 @@ controller (the planner, the rollout) until release 6 of ADR 0429; from each rel
- **git seat** — the seat `git`, held once for the mesh, delivering the provision `git`: the
repositories a build comes from ([26 — The seats](../03-DESIGN/01-to-be/26-the-seats.md) *The git seat*). A seat of
this domain, defined in `mesh-delivery-contracts`. From research 085's milestone its verbs are the one way a
delivery part reaches the forge: reads (`pull`, `open-pulls`, `tags`, `trees`, `file`, `commits`, `branches`,
`contains`) for the parts that declare them, and acts (`status`, `comment`, `view`, `note`, `merge-pull`) for the
forge bridge alone (design 47, *The verbs*). Not the **forge** itself, the server, nor the forge module's own tools.
delivery part and the gate reach the forge: reads (`pull`, `open-pulls`, `tags`, `trees`, `file`, `contains`,
`statuses`) for the parts that declare them, acts (`status`, `comment`, `view`, `note`, `merge-pull`) for the forge
bridge alone, as the holder's trusted value `callers` names, and the forge's events (`pull.*`, `forge.*`,
`repo.writable`) as the seat's (design 47, *The verbs*). Not the **forge** itself, the server, nor the forge module's own tools.
## Health and repair — what is wrong, and putting it right
03-DESIGN/01-to-be/26-the-seats.md
+5 -3
View File
@@ -256,7 +256,7 @@ defined whole or at the seat list's grain (ADR 0635 §2). In the milestone of AD
| contracts module | domain | seats | held by |
|---|---|---|---|
| `mesh-delivery-contracts` | Delivery | `mesh-catalog`, `mesh-delivery-checker`, `mesh-delivery`, `mesh-wants`, `node-build-go`, `node-build-image`, `node-build-node`, `npm-package-registry`, `go-package-registry`, `container-image-registry`, `oci-artifact-registry` | the indexer, the checker, the gate part, the assigner, the three build modules, the forge (two), `distribution` (two) |
| `mesh-delivery-contracts` | Delivery | `mesh-catalog`, `mesh-delivery-checker`, `mesh-delivery`, `mesh-wants`, `git`, `node-build-go`, `node-build-image`, `node-build-node`, `npm-package-registry`, `go-package-registry`, `container-image-registry`, `oci-artifact-registry` | the indexer, the checker, the gate part, the assigner, the three build modules, the forge (three), `distribution` (two) |
| `mesh-health-and-repair-contracts` | Health and repair | `mesh-conditions`, `mesh-self-check`, `mesh-healers`, `mesh-watchdogs`, `mesh-hand-acts` | the condition keeper, mesh-self-check, mesh-healers, the watchman, mesh-hand-acts |
| `mesh-provisioning-contracts` | Provisioning | `mesh-provisioner` | mesh-provisioner |
| `mesh-identity-and-access-contracts` | Identity and access | `mesh-vault`, `mesh-node-enroller` | the vault, the module `mesh-enrolment` |
@@ -691,8 +691,10 @@ With the seat unheld, a build from the seat is refused and says why. External bu
**The seat's verbs, from research 085's milestone.** The delivery parts reach the forge through the seat `git`'s
verbs alone, never by the forge module's own tools: reads for the parts that declare them in their `invokes`, and
acts (a status, a comment, the delivery's view, a line on the commit's note, a merge) for the forge bridge alone.
Design 47, *The verbs*, lists them with their callers and how they are checked.
acts (a status, a comment, the delivery's view, a line on the commit's note, a merge) for the forge bridge alone, as
the holder's trusted value `callers` names; the forge's events (a pull request updated, merged or closed, the forge's
own webhooks, a repository writable again) are the seat's events. Design 47, *The verbs*, lists them with their
callers and how they are checked.
**Not yet designed:** a credential for cloning a private repository. The mesh's own repositories are
public. The natural place for a clone credential is a `secret` from the vault, and that is a decision
03-DESIGN/01-to-be/47-delivery-from-commit-to-delivered.md
+255 -101
View File
@@ -184,8 +184,8 @@ source revision is derived from the keys: every **want** equals its module's **f
- **The forge bridge** turns the forge's events into stream messages and is the only part that acts on the
forge. From research 085's milestone every delivery part reaches the forge through the seat `git`'s verbs alone,
never by the forge module's own tools: the forge bridge for every act and read it makes, the checker and the
indexer for the reads they make (*The seat `git`*, under *The verbs*).
never by the forge module's own tools or events: the forge bridge for every act and read it makes, the checker,
the indexer and the gate for the reads they make and the events they hear (*The seat `git`*, under *The verbs*).
- **The indexer** computes each module's fingerprint at the merge preview and writes the candidates of each
group and the modules of the trunk. It reads no placement: placement is not in any repository, and the forge
bridge carries nothing of placement (ADR 0567). From research 085's milestone it keeps the catalog graph per
@@ -487,34 +487,14 @@ ADR 0656.
- **The forge bridge asks the seat for a group.** It reads a group's members from the seat `mesh-delivery`'s verb
`groups`, never the gate's `merges` state, both to set the group on each merged message and to publish a group's
end again (ADR 0656, which changes ADR 0633 §4 and §5; ADR 0596). Its account holds no grant to read `merges`.
- **What the gate owes the forge is said, not watched.** The forge bridge today performs what the gate's states
`merges` and `owed` ask (a merge, a status, the delivery's view, a comment, a line on the commit's note) by watching
those keys (ADR 0437 §8), a read of another module's bus state ADR 0596 §2 ends when the gate moves. From research
085's milestone the gate says each act it owes as the event `owed` of the seat `mesh-delivery`, carrying the act,
its pull request and head, and an id; only the gate's account publishes it (ADR 0363 §2). The forge bridge hears it
through a durable consumer declared in its `consumes`, performs each id once, keeping which ids it performed in its
own state, and does it through the seat `git`'s verbs. The verb `groups` also answers, per group, the acts the gate
said with their ids, and the bridge's tool `bridge_owed` the ids it performed and when, so a person reads both sides
through their owners and nothing reads the other's state. This
is the design's choice under ADR 0596 §1, §2 and ADR 0656 §7: an event consumed durably loses no act while the
bridge is down and performs none twice, and one verb answers a group and what it owes (lead-47, 2026-11-09: no
second verb). How it is checked: in the forge bridge's whole-module test an `owed` said while it is stopped is
performed once after its restart, an act said twice is performed once, its account cannot read `owed`, and
`bridge_owed` lists what it performed; in the gate's, `groups` answers each act it said for a group, with its id.
- **A merge made at the forge has a record too.** A merge the forge reports that the gate did not make (a person's
merge in the forge's own page, as on 2026-11-07 and 11-09) is taken in like any other merge (*Taken in by the
indexer it names*), and the gate opens a delivery record for it on the forge bridge's merged message, marked
`forge-made`, with no Approve, so its trace and its outcomes on the nodes are kept like every delivery's and no
later merge waits behind a merge the gate never heard. The design's choice under ADR 0656 §7 and ADR 0633 §1 (the
operator, 1921's note of 2026-11-07: "a merge made in the forge is taken in like any other"). How it is checked: in
the gate's whole-module test a merged message with no record of the gate's opens a `forge-made` record, and a later
merge in the same repository is taken in behind it.
- **What the gate owes the forge is said, not watched, and a merge made at the forge has a record too** (*What the
gate owes the forge*, below).
- **Its tools**, against the four lines a module's tools answer:
| Line | The gate |
|---|---|
| read everything it holds | `gate_record` (one record whole: the group's state, the trace, each entry's outcome per node, the nodes away), `gate_records` (every record with its fill against the value limit, and the ledger's fill against its cap), `gate_consumer` (its durable consumer: the last event applied per family, the events waiting, the age of the oldest) |
| do by hand what it does itself | `gate_record_repair` (for one record, asks each owner for the outcome of each entry missing one through that owner's read verb: the indexer's `take-in` read, the builder's build read, the checker seat's check read, the seat `mesh-wants`'s `entry`, and the node-engine seat's verb `haves` of that node; applies the answers as the consumer would) |
| do by hand what it does itself | `gate_record_repair` (for one record, asks each owner for the outcome of each entry missing one through that owner's read verb: the indexer's `take-in` read, the builder's build read, the checker seat's check read, the seat `mesh-wants`'s `entry`, and the node-engine seat's verb `composition` of that node; applies the answers as the consumer would) |
| recover without help | `gate_record_end` (end a record left open, a node gone for good or an entry that never runs, with the reason, recorded in the hand-act log of the seat `mesh-hand-acts`) |
| one seat, many tools | the seat `mesh-delivery`'s verbs, with `groups` answering a group's members and the acts said for it |
@@ -533,6 +513,71 @@ ADR 0656.
outcome taken on waking; a record of 30 modules on four nodes stays under 256 KiB; a group checked again at old
heads after a main move is not asked of the operator again (issue 1972).
### What the gate owes the forge
*ADR 0596 §1, §2, ADR 0656 §7, ADR 0437 §8, ADR 0441 §5, ADR 0633 §1, §4, ADR 0363 §2, ADR 0564 §2; from research 085's
milestone, this design's choices under ADR 0596 and ADR 0656 §7.*
The forge bridge today performs what the gate's states `merges` and `owed` ask (a merge, a status, the delivery's
view, a comment, a line on the commit's note) by watching those keys (ADR 0437 §8), and the forge module writes the
checker's `mesh/check` from a watch of the checker's state `owed`: reads of another module's bus state that ADR 0596
§2 ends when their owner moves. From research 085's milestone:
- **Every act is an event, under one id.** The gate says each act it owes as the event `owed` of the seat
`mesh-delivery`, on `mesh.seat.mesh-delivery.event.owed.<repository>.<number>`, carrying the act, the pull request,
the head and an id; the checker says its status the same way, as the event `owed` of the seat
`mesh-delivery-checker` on `mesh.seat.mesh-delivery-checker.event.owed.<repository>.<number>`. Only the owner's
account publishes each (ADR 0363 §2). The subject per repository and pull request lets the bridge, a person and a
test read one pull request's acts alone. The seat events are kept on each owner's stream `owed`, 7 days and at most
64 MiB (an estimated 20 deliveries a day, with about 15 acts of about 1 KiB each, is about 2 MiB over 7 days).
- **Every act is safe to repeat at the forge.** A status and the delivery's view replace what stands; a merge of a
pull request already merged at that head is answered performed; a comment and a line of the note carry the act's
id, and the seat `git`'s verb skips an id the pull request or note already holds. This is chosen over recording the
id before the act: an id recorded and then not performed (the bridge stopped between the two) would be lost, while
an act repeated changes nothing. The bridge's own state `performed`, a key-value state in the new form (ADR 0595),
form 1, one key per id with the outcome and when, kept 7 days as the stream is and capped at 16 MiB, is therefore a
saving and a read, never what keeps an act from happening twice.
- **Every outcome is said, and the gate records it.** The bridge says each act's outcome on its own stream `forge` as
the event `owed.ended`, with the id and one of `performed`, `refused` (the forge's own words), `could not be
performed` (the forge did not answer within the call's bound, with the error) or `undecodable` (an act it cannot
read, with why): an act it cannot decode is said, never only logged. The gate hears the stream `forge` through its
durable consumer, writes the outcome into the delivery record, and says an act's id is answered only once an
outcome is recorded.
- **What is unanswered is said again, and stalls by a bound.** At its start the gate says again, under the same id,
every act its records hold unanswered. An act unanswered 15 minutes after it was said is listed by `stalled`, which
the condition keeper raises as the stalled line (ADR 0421 §7, ADR 0564 §2): fifteen minutes is many times a
forge call's time, and short beside the check's hour.
- **A group's merges follow one another.** The gate says a group's next `merge-pull` only once the previous member's
merged message is heard (ADR 0441 §5), so a member the forge refuses holds the rest, and none is merged ahead.
- **The bridge catches up from the seat.** At its start the bridge resumes its durable consumer and also reads
`groups`, which answers, per group, the acts the gate said with their ids and their recorded outcomes; an id said
and not answered is performed. Its tools: `bridge_owed` (the ids it performed with their outcomes, and its
consumer's backlog: the last event applied, the events waiting, the age of the oldest), `bridge_owed_again`
(perform one id again now) and `bridge_owed_drop` (drop one id with its reason, written in the hand-act log of the
seat `mesh-hand-acts`, and said as `owed.ended` with the outcome `dropped`).
- **The switch carries what is owed.** At the new gate's start (*The switch carries today's state in, once*) every key
of `owed` and `merges` the old bridge has not performed becomes an act of its record, with an id made of the key and
its revision; the new bridge counts as performed every id whose key and revision the old bridge's own bookkeeping
names, so nothing is done twice and nothing dropped. A merge handed to the forge during the switch is such an act:
its merged message finds the record holding it, so it opens no `forge-made` record.
- **A merge made at the forge has a record too.** A merge the forge reports for which no record holds a `merge-pull`
of that pull request at that head (a person merged it in the forge's own page, as on 2026-11-07 and 11-09) is taken
in like any other merge (*Taken in by the indexer it names*), and the gate opens a delivery record for it, marked
`forge-made`, with no Approve, so its trace and its outcomes on the nodes are kept like every delivery's and no
later merge waits behind a merge the gate never heard. The gate says it as the delivery's `transition` with the why
`forge-made`, which the teller passes on to the operator (the operator, 1921's note of 2026-11-07: "a merge made in
the forge is taken in like any other").
- **How it is checked.** In the forge bridge's whole-module test: an `owed` said while the bridge is stopped is
performed once after its restart; the bridge stopped between an act and its `owed.ended` performs it again on its
restart and the forge holds it once (the comment and the note by their id); an act said twice is performed once; an
undecodable act is said `undecodable`; `bridge_owed`, `bridge_owed_again` and `bridge_owed_drop` answer, the drop
writing the hand-act log; its account cannot read the gate's or the checker's state. In the gate's: an act left
unanswered is said again at the gate's start under its id and listed by `stalled` after 15 minutes; a group's second
`merge-pull` is said only after the first member's merged message; the switch with a merge handed and not yet
merged makes no `forge-made` record; a merged message with no record's merge opens a `forge-made` record, said as
`transition` with why `forge-made`, and a later merge in the same repository is taken in behind it. Acceptance
tests 53 and 51.
## The state table
*ADR 0539 §17.*
@@ -732,11 +777,16 @@ Findings 11). How each is kept, read and retained is this design's choice under
manifest claiming that seat is judged with it.
- **Who holds a seat is applied by one rule, from what each node runs.** The node-engine and the grants part decide a
seat's pass by mesh-sdk's `SeatsToPassOn` (ADR 0660 §3), reading the manifest of the build each assignment runs
(ADR 0660 §2). The build another node runs is read through the node-engine seat's verb `haves` of that node, never
its have key, its want or the assignment half (ADR 0596 §2; *Each part acts on its own entries*). The verb is the
design's choice under ADR 0660 §2: the node that runs a build is the one owner of what it runs. How it is checked:
in the node-engine's and the grants part's whole-module tests a pass is decided from a stand-in seat answering
`haves`, and neither part's account can read another node's have key.
(ADR 0660 §2). What each node runs is heard, never asked: each part keeps it from the node-engine seat's events
`running.<node>` (*What each step says*), through a durable consumer of its own declared in its `consumes`, so a
pass is decided with no call to a node that may be away. The event carries the module, the fingerprint and the
digest of the build's manifest, which is the indexer's manifest of that build (ADR 0660 §2's "the indexer's
manifest of it"), read by digest from the catalog half; the builder's done key is not needed, since the event names
the digest it would give. A node that has said no `running` for a module since the part's consumer began counts by
the trunk's manifest, as ADR 0660 §2 has it where the running build cannot be read, and both parts apply that same
fallback in the one function (ADR 0660 §3). Never another node's have key, its want or the assignment half (ADR 0596
§2; *Each part acts on its own entries*). The design's choice under ADR 0660 §2: the node that runs a build says what
it runs, and an event kept by a durable consumer answers when that node is away. How it is checked: test 56.
- **A part with no view says it waits.** It names the revision it has no view for, acts on nothing new, and keeps
running what it runs, as ADR 0636 §1 has a reader of the seat list do; the checker, the builder and the grants part
wait too, and wait for the view, not only the seat list (ADR 0656, which changes ADR 0636 §1); the node-engine waits
@@ -860,11 +910,15 @@ ADR 0656 decides the direction and leaves every choice made in working it out to
| The seat list's reader and its two tools wired once by mesh-sdk's runtime | ADR 0636 §7 puts them in the runtime bundle; four hand-wired copies would each learn `acts` apart |
| The trunk's heads from the catalog half, and nothing read of the gate by the checker | ADR 0596 §2; with the hold and turns removed nothing of the gate is left for the checker to read |
| The indexer reads every contracts trunk's definitions at its start, before it judges | a definition merged while it was down is never judged against a list that lacks it (ADR 0636 §1) |
| Another node's running build read through the node-engine seat's verb `haves` | ADR 0660 §2 reads the manifest of the build each node runs, and that node is its one owner (ADR 0596 §2) |
| What the gate owes the forge said as the event `owed`, consumed durably by the forge bridge, and answered by `groups` | ADR 0596 §1, §2 end the bridge's watch of the gate's keys; a durable consumer loses no act and performs none twice; one verb answers a group and what it owes |
| Another node's running build kept from the node-engine seat's `running` events by a durable consumer, the event carrying the fingerprint and the manifest's digest, the trunk's manifest for a node that said nothing | ADR 0660 §2 reads the manifest of the build each node runs; an event kept by a durable consumer answers while a node is away, where a call would wait on it; one fallback in the one function keeps the two parts agreed (ADR 0660 §3) |
| What the gate and the checker owe the forge said as the event `owed` per repository and pull request, each act safe to repeat at the forge, each outcome said as `owed.ended` and recorded, an unanswered act said again at the gate's start and stalled after 15 minutes | ADR 0596 §1, §2 end the watches of the gate's and the checker's keys; an act safe to repeat cannot be lost between the act and its record, where an id recorded first could; an outcome said and recorded leaves no act unseen |
| A merge made at the forge opens a `forge-made` delivery record | its trace and outcomes are kept like every delivery's, and no later merge waits behind a merge the gate never heard |
| Every delivery part reaches the forge only through the seat `git`'s verbs | the delivery parts name no other module (ADR 0656 §1, acceptance test 27), and the forge's answers are typed in the seat's contract instead of guessed in each caller |
| A check that failed because a part of the mesh was not heard says `could not run`, naming the part, and is asked again on that part's `running` event | the operator sees a mesh fault apart from a failing change, and the check is asked again on the one event that can change its outcome, never on a timer (issue 1373) |
| Every delivery part and the gate reach the forge only through the seat `git`'s verbs and events, the act verbs granted by the holder's trusted `callers` to the forge bridge alone, a failed read answered as an error | the delivery parts name no other module (ADR 0656 §1, acceptance test 27); the forge's answers are typed in the seat's contract instead of guessed in each caller; the bridge stays the one part that acts on the forge; an error read as an empty answer would hide a forge down |
| A check that failed because a part of the mesh was not heard says `could not run`, naming the part, releases its claim, and is asked again once per heads and part on that part's `running` event, raising `check-could-not-run` after 60 minutes | the operator sees a mesh fault apart from a failing change, and the check is asked again on the one event that can change its outcome, never on a timer (issue 1373) |
| A module held for its claim raises `module-held` until it is composed | a module left out in silence would look delivered (the mesh's rule that failure is loud) |
| The indexer waits for the seat `git` at most 2 minutes at its start, then judges from its kept definitions and raises `view-waits` after five | longer than a forge's restart, and no start held behind a forge down for good |
| The forge before the forge bridge before the gate, reverted the other way | the verbs are served before they are called, and `owed` is said only to a bridge that hears it |
| The store seat's holder's own new build kept on its build node and fetched by `kept-artifact` when its seat is broken | its own build needs the store it replaces; a step of the delivery replaces the hand bootstrap |
| Every drop and release tool writes the hand-act log | a hand act that changes what the mesh runs or keeps is recorded with who did it and why, as every hand act is (seat `mesh-hand-acts`) |
Each choice is checked by the tests its section names; the review by architectural domain judges them.
@@ -950,10 +1004,12 @@ the node-engine reads its want and the catalog half and never the assignment hal
while its node's want differs from what runs reports the build it was started with. Live: a search of the readers'
code finds none of the reads the revision view replaces, each by name: the indexer's read of the checker's previews,
the checker's watch of the indexer's `candidates.<try id>`, the forge bridge's read of the gate's `merges` and `owed`,
the checker's read of the gate's `source` and `turns`, the grants part's read of the assigner's state `wants`, the
the checker's read of the gate's `source` and `turns`, the forge module's watch of the checker's `owed` (its `mesh/check`
status, now the checker's `owed` event performed by the forge bridge) and its read of the gate's `source`, the grants
part's read of the assigner's state `wants`, the
checker's validator request with no seat definitions, a seat list compiled into the node-engine, the checker, the
builder or the grants part, a seat list's reader wired by a part itself, and a call of the forge module's own tools by
a delivery part; an old node-engine that wakes takes its new build in a form it reads.
a delivery part or the gate; an old node-engine that wakes takes its new build in a form it reads.
## Order without a person
@@ -1030,6 +1086,19 @@ names go, since every new acting part needed code changes elsewhere (research 08
what its new version is built from or needs (a base, a package, a provider) is acted on by its running version,
never waited for: the running build module builds the shared contracts and the registry holder, then the new build
module builds the rest, so ADR 0614 §6's cycle through them stays allowed, now for that reason.
- **The artifact store's holder takes its own new build even when its seat is the one broken.** A build module
stores what it builds through the seat `oci-artifact-registry` (or `container-image-registry` for an image), so the
holder of that seat is in its own build's path: its new build needs the store it replaces. As every holder's own
inputs are (above), that store is acted on by the running holder: the running holder stores its new build, and only
then is the new one wanted. When the running holder is what is broken (the seat refuses or does not answer a store,
as in the hand bootstrap of 2026-11-07 to 11-09), the build module keeps that one build on its own node among its
kept builds (*The bootstrap delivery*: `build_go_kept`), says in its step key that it is kept on that node, and the
builder's done key names it so; the node-engine composing the holder fetches it by its digest through the build
seat's verb `kept-artifact` of that node, and the new holder, once it runs, takes the store of every build after
it. This is the one artifact the mesh delivers from a build node instead of the store, and only for a holder of a
store seat; the design's choice under ADR 0656 §3 (a wait skips what the holder's own new version needs) and ADR
0526 §2, whose build by a session's call it makes a step of the delivery instead of a hand act. How it is checked:
test 60.
- **The check refuses a cycle among the waits within one step** (ADR 0656, which changes ADR 0603 §2's refusal of a
cycle), counted beside the edges ADR 0614 §3 and §6 list; a cycle through an acting part's edges across two steps, or
through a holder's own inputs, is none.
@@ -1120,12 +1189,15 @@ commit on the SDK's trunk or the head of an SDK pull request the forge holds, op
delivers no verdict, so none of its builds is reused. A trunk move never ends a check: its verdict goes out of
date when it ends, and is carried. A check that failed because a part of the mesh was not heard is still asked
again when the nodes change, which judges heads no check judged. From research 085's milestone its verdict says
`could not run`, naming the part not heard, and it is asked again on that part's `running` event of the
node-engine seat (*What each step says*), never on a timer; a second check of the same heads asked while one runs,
or one erred, claims nothing and writes no status, by the claim above (issue 1373; ADR 0548 §1, ADR 0656 §5). How
it is checked: in the checker's whole-module test a check whose composer's node does not answer says `could not
run` naming it, and is asked again once a fixture `running` event of that node is said; a second ask of the same
heads writes no status.
`could not run`, naming the part not heard, and the check releases its claim on the verdict key, so the heads can
be judged again. The part's return is the one event that can change the outcome: the node-engine seat's
`running.<node>` naming that part (a node waking, the forge module or a build module starting again alike), on which
the check is asked again, once per set of heads and per part returning, never on a timer; a `running` of the same
part at the same fingerprint after that asks nothing. A `could not run` verdict not asked again within 60 minutes
becomes the checker's finding `check-could-not-run`, naming the heads and the part, which the condition keeper
raises (ADR 0564 §2): an hour is the check's own bound. A second check of the same heads asked while one runs, or
one erred, claims nothing and writes no status, by the claim above (issue 1373; ADR 0548 §1, ADR 0656 §5). How it
is checked: test 58.
- **A failed build node loses nothing.** An ask a build module took and never acknowledged goes to another node by the
stream's own acknowledgement wait, with no timer of a part; a step's end is written on the build module's step key named
by the ask's id (ADR 0525 §6).
@@ -1191,14 +1263,15 @@ the check gates merges.*
its record still to be written (below).*
**Removed at research 085's milestone.** The hold, the merge turns, their stalled line, the gate's tools for them and
the setting `check-gates-merge` go in milestone G (the operator, on Telegram, 2026-11-09 01:11 UTC, choosing "Remove them
in G"). The setting has been false since 2026-10-25, so the gate wrote no turn and held no merge in that time, and the
the setting `check-gates-merge` go in milestone G, the gate's and the forge module's alike (the operator, on Telegram,
2026-11-09 01:11 UTC, choosing "Remove them in G"; the forge's merge then judges no check, *The seat `git`*). The setting has been false since 2026-10-25, so the gate wrote no turn and held no merge in that time, and the
operator's word for G is that no check gates delivery (1921's note of 2026-11-07). From G's delivery an approved merge
is handed to the forge bridge at once; a check running on a repository the merge goes into ends on the commit it read,
and its verdict is carried (*A move of the trunk carries every verdict*); the checker reads nothing of the gate, and
the gate no longer watches the checker's verdicts for a hold. **No record carries this yet:** ADR 0548 §2 to §4, §9
and §10 and ADR 0551 are in force, and a record that ends them is written before this design is merged; until it is
accepted, the rule below holds as those records have it. How it is checked: in the gate's whole-module test an approved merge into a
the gate no longer watches the checker's verdicts for a hold. **Its record is to be accepted before the push:** ADR
0548 §2 to §4, §9 and §10, ADR 0551 and ADR 0534 §4's judgement of `mesh/check` by the merge are in force, and the
record that ends the first two and changes the third (needs the operator's Approve) is to be accepted before milestone
G's pull requests are pushed; until it is accepted, the rule below holds as those records have it. How it is checked: in the gate's whole-module test an approved merge into a
repository under a running check is handed at once, and the gate's manifest declares no `turns` and no setting
`check-gates-merge`; in the checker's, a check claims at once with no gate state granted to read.
@@ -1503,7 +1576,7 @@ pull request, and it owes the forge nothing.
they are still the heads, their check passed against the trunk's head, and, while the check gates merges, no
check of other heads runs on a repository the merge goes into (*Nothing merges into a repository under check*,
above, which milestone G removes). From milestone G the forge bridge merges through the seat `git`'s verb
`merge-pull`, which keeps the merge tool's judgement of ADR 0534 §4. When the trunk moved, the merge waits for the carried verdict, and the event of its line asks the merge
`merge-pull`, which judges the Approve's heads and no check (*The seat `git`*, under *The verbs*). When the trunk moved, the merge waits for the carried verdict, and the event of its line asks the merge
again; no timer asks it, no person rechecks, and the Approve is not asked again (ADR 0421 §3, §12, as ADR 0548
§8 changes them). The merge tool still refuses a verdict naming a trunk commit other than the trunk's head and
asks nothing (ADR 0534 §4); the carry makes the verdict current.
@@ -1888,8 +1961,9 @@ later change of a kept data's form, not as a case of this milestone.
composes that module as left out, keeping its openings, says why in its have, and composes and applies every other
module of the node; it never refuses the whole pass for one module's claim (ADR 0636 §3: a refused definition blocks
new claims of that seat only). Met on 2026-11-08, when one claim problem refused a node's every module (issue 1966).
How it is checked: in the node-engine's composition table a node with one module whose claim is refused applies the
others, and that module's have names why.
A module held so is no silent leave-out: the node-engine writes the finding `module-held` naming the node, the
module and why, and the condition keeper keeps the condition (ADR 0564 §2) until the module is composed again, when
the node-engine clears the finding. How it is checked: test 55.
- **The order a node takes to composing its own.** One delivery group carries every part: the seat `mesh-module-assigner`
on the assigner, the controller's verb `placement-export` (as it is) and the controller's pin only, the node-engine
(its record and its own composer), the vault's `own`, the grants part's reads, and mesh-config's reading of
@@ -2112,8 +2186,8 @@ From research 085's milestone the seat gains:
| Verb or event | Answers or does |
|---|---|
| `groups` with a group | that group's members, which the forge bridge reads in place of the gate's `merges` state (ADR 0656), and the acts the gate said it owes the forge for it, each with its id (*The delivery record*) |
| `owed` | an act the gate owes the forge (a merge, a status, the delivery's view, a comment, a line on the commit's note), with its pull request, head and id, said only from the gate's account and heard by the forge bridge through a durable consumer (*The delivery record*) |
| `groups` with a group | that group's members, which the forge bridge reads in place of the gate's `merges` state (ADR 0656), and the acts the gate said it owes the forge for it, each with its id and its recorded outcome (*What the gate owes the forge*) |
| `owed` | an act the gate owes the forge (a merge, a status, the delivery's view, a comment, a line on the commit's note), with its pull request, head and id, on `mesh.seat.mesh-delivery.event.owed.<repository>.<number>`, said only from the gate's account and heard by the forge bridge through a durable consumer (*What the gate owes the forge*) |
| `milestone.asked`, `milestone.withdrawn`, `milestone.answered` | the one Approve ask per milestone (ADR 0493 §9 as ADR 0659 §1 changes it, issue 1783), held until it is answered, or withdrawn by a new head and asked again (ADR 0441 §1); said on `mesh.seat.mesh-delivery.event.milestone.<milestone>.<event>`, apart from each delivery's `transition`, which stays as it is, so a waiter on one member's pull request wakes only on that member's `transition` |
| `pinned`, `freed`, `heads-replaced` | the events by which the indexer and the assigner keep or drop graph revisions, said only from the gate's account (*The delivery record*) |
| `record-ended`, `filling`, `full`, `room` | a delivery record ended; the ledger past 80 % of its cap; the ledger full; the ledger back below its cap (*The delivery record*) |
@@ -2122,39 +2196,80 @@ From research 085's milestone the seat gains:
of the revision view, ADR 0656), and `entry` and `difference` on `mesh-wants` (ADR 0656), with the events of *What
each step says*.
**The seat `node-engine`** gains, from research 085's milestone, the verb `haves`: what its node runs of each module,
the fingerprint and its phase, which the node-engine of another node and the grants part ask to decide a seat's pass
(ADR 0660 §2; *Who holds a seat is applied by one rule*), and the gate's `gate_record_repair` asks for a missing
outcome. It answers from the node's own haves, and every node's account may call it.
**The seat `node-engine`**'s event `running.<node>` carries, from research 085's milestone, the module, its
fingerprint and the digest of its build's manifest, so the node-engine of another node and the grants part decide a
seat's pass from it (ADR 0660 §2; *Who holds a seat is applied by one rule*). No verb is added.
**The seat `git`.** The seat `git` (design 26, *The git seat*), of the Delivery domain, defined in
`mesh-delivery-contracts`, holds no verb today, and the delivery parts reach the forge by naming the forge module's own
tools and guessing the shape of their answers (on 2026-11-09 one guess, an answer wrapped in a `result` field, made
316 conditions stand, issue 1966). From research 085's milestone the seat's definition carries the verbs below, their
inputs and answers typed in its contract, served by the module that claims the seat; every delivery part calls the
seat, never the forge module by name (acceptance test 27). The verbs are this design's choice under ADR 0596 §2 (a
module's data is asked through its seat verbs) and ADR 0625 §1 (a seat's contract is generated from its definition),
each for a call a delivery part makes of the forge today:
`mesh-delivery-contracts`, holds no verb today, and the delivery parts and the gate reach the forge by naming the forge
module's own tools and events and guessing the shape of their answers (on 2026-11-09 one guess, an answer wrapped in a
`result` field, made 316 conditions stand, issue 1966). From research 085's milestone the seat's definition carries the
verbs and events below, their inputs and answers typed in its contract, served and said by the module that claims the
seat; every delivery part and the gate call and hear the seat, never the forge module by name (acceptance test 27).
They are this design's choice under ADR 0596 §1, §2 (a module's events are subscribed to and its data asked through
its seat verbs) and ADR 0625 §1 (a seat's contract is generated from its definition). The table is built from what the
parts' manifests declare in `invokes` and `consumes` and what their code calls, read on main on 2026-11-09 (mesh-delivery
042b8d1f, mesh-catalog's gate); a declaration nothing calls (the checker's `gitea_commits`, `gitea_compare`,
`gitea_list_branches`) gets no verb and is dropped from its manifest:
| Verb | Answers or does | Called by |
| Verb | Answers or does | Called by (today's call) |
|---|---|---|
| `pull` | one pull request, by its repository and number or by its merge commit: number, base, head branch, head, merge commit, author, state | the forge bridge (a merge the gate did not make), the gate's author of a stalled line (*The Approve and the merge*) |
| `open-pulls` | every open pull request of every repository, its head and base, the statuses its base requires and those its head has | the forge bridge, at its start and each reconnect (ADR 0443 §5) |
| `tags` | a repository's tags, paged, with the page's bound said when more exist | the forge bridge, for the builder's floor |
| `trees` | the trees of one commit | the forge bridge (a merged message's trees), the checker, the indexer (the definitions at its start) |
| `file` | one file at one commit | the checker, the indexer |
| `commits` | the commits between two commits of a repository | the checker |
| `branches` | a repository's branches with their heads | the checker |
| `contains` | whether one commit contains another | the indexer |
| `status`, `comment`, `view`, `note` | a commit status, a comment, the delivery's one view comment, a line on the commit's note under `refs/notes/mesh-plan` | the forge bridge alone, performing the gate's `owed` |
| `merge-pull` | merges a pull request at a head, judging what the forge module's merge tool judges today (ADR 0534 §4) | the forge bridge alone |
| `pull` | one pull request, by its repository and number or by its merge commit: number, base, head branch, head, merge commit, author, state | the forge bridge (a merge the gate did not make; `gitea_api`), the gate (a stalled line's author) |
| `open-pulls` | every open pull request of every repository, its head and base, the statuses its base requires and those its head has | the forge bridge at its start and each reconnect (ADR 0443 §5), the indexer, the gate (`gitea_open_pulls`) |
| `tags` | a repository's tags, paged, the page's bound said when more exist | the forge bridge, for the builder's floor (`gitea_api`) |
| `trees` | the trees of one commit | the forge bridge, the checker, the indexer (`gitea_commit_trees`) |
| `file` | one file at one commit | the forge bridge, the checker, the indexer (`gitea_get_file`) |
| `contains` | whether one commit contains another | the indexer, the gate (`gitea_contains`) |
| `statuses` | the statuses a commit carries | the gate (`gitea_commit_statuses`) |
| `status`, `comment`, `view`, `note` | a commit status, a comment, the delivery's one view comment, a line on the commit's note under `refs/notes/mesh-plan`; a comment and a note line carry the act's id and an id already held is skipped | the forge bridge alone, performing the gate's and the checker's `owed` (`gitea_commit_status`, `gitea_add_comment`, `gitea_delivery_view`, `gitea_note_append`) |
| `merge-pull` | merges a pull request at the head the operator's Approve names; refuses a head that moved, a branch no rule guards, a head the Approve does not name and a merge git refuses; judges no check (below); a pull request already merged at that head is answered performed | the forge bridge alone (`gitea_merge_pull_request`) |
The verbs that act are granted to the forge bridge's account alone, so the bridge stays the one part that acts on
the forge; the reads are granted to each part that declares them in its `invokes`. A verb's answer is the contract's
type, never a wrapper a caller unwraps. How it is checked: the seat definition's conformance fixtures hold one answer
of each verb, and the forge module's tool tests answer each fixture; the forge bridge's, the checker's and the
indexer's unit fakes answer from the same fixtures; a call of a verb that acts from an account other than the forge
bridge's is refused by the bus; live, a search of the delivery parts' code finds no name of the forge module's tools.
| Event of the seat | Says | Heard by (today's event) |
|---|---|---|
| `pull.updated`, `pull.merged`, `pull.closed` | a pull request's new head, its merge with the merge commit, its close | the forge bridge, the gate (`gitea.pull.*`) |
| `forge.pull`, `forge.status`, `forge.delete` | the forge's own webhook of a pull request, of a commit status, of a deleted branch | the gate (`forge.pull`, `forge.status`), the forge bridge (`forge.delete`) (`gitea.forge.*`) |
| `repo.writable` | a repository the forge can write again | the gate (`gitea.repo.writable`) |
Each is said on `mesh.seat.git.event.<event>`, declared in the seat's definition, and heard through the hearer's
`consumes` of the seat.
- **A failed read answers an error, never an empty answer.** When the forge does not answer, refuses or answers what
the contract cannot type, the verb answers an error naming why; an empty list or an absent file is answered only
when the forge said so. A caller never reads an error as "none". How it is checked: the seat's fixtures hold an
error answer for each verb, and each caller's unit table has a row for it (the forge bridge, the checker, the
indexer, the gate).
- **Who may call an act.** The holder's trusted config value `callers`, which today names per verb who may call the
two package seats' verbs (design 51), gains a line per verb of the seat `git`: the act verbs name the forge bridge
alone, the reads name each part that declares them in `invokes`; the grants part grants by it, and the holder
refuses a caller it does not name. The forge module's own acting tools (`gitea_merge_pull_request`,
`gitea_commit_status`, `gitea_delivery_view`, `gitea_note_append`, `gitea_add_comment`) retire with the milestone,
and so do its watch of the checker's state `owed` and its read of the gate's `source`, so the bridge stays the one
part that acts on the forge. How it is checked: test 51 reads the grants, not the code.
- **`merge-pull` judges no check.** The operator's answer that no check gates delivery (Telegram, 2026-11-09 01:11 UTC,
"Remove them in G") covers the forge module's own setting `check-gates-merge` as well as the gate's: both are
removed, and `merge-pull` merges an approved head whatever its `mesh/check` says. The record that ends ADR 0551 and
ADR 0548 §2 to §4, §9 and §10 also changes ADR 0534 §4's judgement of `mesh/check` by the merge; it is to be accepted
before the push (*Nothing merges into a repository under check*).
- **The order is the module graph's, and each step has its way back.** The verbs are a served-verb edge (ADR 0614):
the forge module's new build runs before the forge bridge's, and the forge bridge's before the gate's, since the
bridge calls the verbs and performs the gate's `owed`, and the gate says `owed` only to a bridge that hears it; all
three are ahead of the acting parts' steps, which read through the seat. While the new forge runs and the old bridge
still calls the retired acting tools, the old bridge's acts fail loudly and stay unperformed in the old gate's keys,
and the switch carries them (*What the gate owes the forge*). A revert goes back in the other order: the gate, then
the bridge, then the forge, each wanted only once the one after it in the forward order runs its reverted build, so
no part calls a verb nobody serves.
- **A part that cannot read the forge keeps what it has, and says so.** The indexer, at its start, waits for the
seat `git` at most 2 minutes; with no answer it judges from the last definitions it kept, says in its
`<module>_first_views` that it waits for `git` and since when, writes `view-waits` after five minutes, and reads the
definitions once the seat answers. Two minutes is longer than a forge's restart, and short enough that a start is
not held behind a forge down for good. How it is checked: in the indexer's whole-module test with a fixture forge on
its old build, which serves no verb of the seat, the indexer starts, judges from its kept definitions, and raises
`view-waits` after five minutes.
- **How it is checked.** The seat definition's conformance fixtures hold one answer and one error of each verb and one
of each event, and the forge module's tool tests answer each fixture; the forge bridge's, the checker's, the
indexer's and the gate's unit fakes answer from the same fixtures; a call of an act verb from an account other than
the forge bridge's is refused (test 51); live, a search of the delivery parts' and the gate's code finds no name of
the forge module's tools or events.
**Links of the trace.** No part reads a review line (ADR 0659 §1 to §3); who may review and the review verb's grant
stay issue 1782's, outside milestone G, and that verb gates nothing (ADR 0659 §2). The trace's links are this
@@ -2447,24 +2562,53 @@ Each change ADR 0656 makes in an earlier record, and its test:
What milestone G's prepare found, and its test:
50. **No description is read** (ADR 0659 §4). The Approve ask names the issues read from the milestone's links and a
stalled line the author read through the seat `git`, no notice of an `after:` line is said, and a test over the
gate's code finds no read of a description field (whole, gate).
stalled line the author read through the seat `git`'s `pull`, no notice of an `after:` line is said, and a test over
the gate's code finds no read of a description field (whole, gate).
51. **The forge is reached through its seat.** Every act the forge bridge performs and every read the forge bridge,
the checker and the indexer make of the forge goes through a verb of the seat `git`, each answer decoded as its
contract's type; an act called from an account other than the forge bridge's is refused; a search of the
delivery parts' code finds no name of the forge module's tools (whole, forge bridge; live).
52. **Nothing holds an approved merge for another check.** An approved merge into a repository under a running check
is handed at once; the gate declares no `turns` and no setting `check-gates-merge`, and the checker is granted no
read of the gate's state (whole, gate and checker; its record first, *Nothing merges into a repository under
check*).
53. **What the gate owes is said, and a forge-made merge is kept.** An `owed` said while the forge bridge is stopped
is performed once after its restart; a merge made at the forge opens a `forge-made` record and is taken in, and a
later merge in its repository follows it (whole, gate and forge bridge).
the checker, the indexer and the gate make of the forge goes through a verb of the seat `git`, and every forge
event they hear is the seat's; each answer is decoded as its contract's type and a failed read as an error; the
grants composed from the holder's `callers` give the act verbs to the forge bridge's account alone, a call of one
from another account is refused, and the forge module serves none of its retired acting tools (whole, forge bridge,
grants part; live, the grants read with `grants_bindings`).
52. **Nothing holds an approved merge for another check.** Once the record that ends ADR 0551 and ADR 0548 §2 to §4,
§9, §10 and changes ADR 0534 §4 is accepted (to be accepted before the push): an approved merge into a repository
under a running check is handed at once and merged whatever that check says; neither the gate nor the forge module
declares `check-gates-merge`, the gate declares no `turns`, and the checker is granted no read of the gate's state
(whole, gate, checker and forge module).
53. **What is owed is said, answered and kept.** An `owed` said while the forge bridge is stopped is performed once after
its restart; the bridge stopped between an act and its `owed.ended` repeats it and the forge holds it once; an
undecodable act is said `undecodable`; an act unanswered 15 minutes is listed by `stalled`; the switch with a merge
handed and not yet merged opens no `forge-made` record; a merge made at the forge opens one, said as `transition`
with why `forge-made`, and a later merge in its repository follows it; the checker's `mesh/check` is performed by
the bridge from the checker's `owed` (whole, gate and forge bridge).
54. **One reader of the seat list per part, and one view machinery.** Every part that reads the seat list has the two
tools of ADR 0636 §7 from the runtime and no wiring of its own; every part that takes a first view answers its
held and awaited revision in `<module>_first_views` (unit, mesh-sdk; live search).
55. **A claim problem holds one module.** A node with one module whose claim is refused applies the others, and that
module's have names why (unit, node-engine).
held and awaited revision in `<module>_first_views`; the indexer with the forge on its old build, serving no verb of
the seat `git`, starts within 2 minutes on its kept definitions and raises `view-waits` after five (unit, mesh-sdk;
whole, indexer; live search).
55. **A claim problem holds one module, and says so.** A node with one module whose claim is refused applies the
others; that module's have names why, and `mesh-conditions.conditions` reads its `module-held` condition until the
module is composed again, when it clears (whole, node-engine and condition keeper).
56. **One rule picks a seat's holder, also with a node away** (ADR 0660 §1 to §3). With one node away whose last
`running` named a build that no longer claims the seat, and one node that has said nothing since the parts'
consumers began, the node-engine and the grants part each pick the same holder, the silent node counted by the
trunk's manifest; neither reads another node's have key, and neither calls a node (whole, node-engine and grants
part).
57. **The indexer reads every definition at its start.** Started with a definition on a contracts trunk that no event
announced, the indexer judges the first manifest claiming that seat with it, and answers it in
`seat-definitions` (whole, indexer).
58. **A check that could not run says so and is asked once more.** A check whose composer's node does not answer
reads `could not run` and names that node in `mesh-delivery.show`; the claim is released; the node's `running` asks
the check again once, and a second `running` of the same part at the same fingerprint asks no second check; a
`could not run` not asked again within 60 minutes raises `check-could-not-run` (whole, checker; live, read through
`mesh-delivery.show`).
59. **A session hears an accepted record** (issue 595). An Approve that accepts a record makes the knowledge base say
`reviewed` with what was accepted, by the operator and with the warrant, and the tool runner's account hears it, so
a session waiting with `mesh_wait` wakes on it (whole, knowledge base; live).
60. **The store's holder takes its own build when its seat is broken.** With a fixture holder of `oci-artifact-registry`
that refuses every store, its new build is kept on the build node, named in the builder's done key, fetched by the
node-engine through `kept-artifact`, and once it runs the next build is stored through the seat, with no hand act
(whole, builder, build module and node-engine).
## What retires
@@ -2570,7 +2714,7 @@ release reports the controller's code lines against research 063's baseline (acc
| L6 | Provisioning leaves the controller (ADR 0570): every provision is one key of the seat `mesh-provisioner`, held by mesh-provisioner, holding a reference and never a value, and each placed module's provisioning plan a key of its state `plans`, both composed from placement, the wants and the manifests on change events; each provider acts once all a provision depends on is provided; the assigner moves a want only once its build's provisions are provided; a provision no want needs is retiring, and its account or credential is removed only on the operator's Approve, its data never; the vault mints each provision's secret sealed to the consumer's and the provider's node, and the consumer's node-engine writes it; a wait for a person is a provision's state, which the watchman reads; bus permissions stay with the grants part (ADR 0349, ADR 0230, ADR 0547 §11) | — | mesh-sdk, the node-engine (`mesh-host`), mesh-tools (the tool runner's provisioner client), mesh-catalog (mesh-provisioner, the vault, the provisioner client, postgres, keycloak, gitea, route-adapter), mesh-delivery (assigner, watchman) | 1954 |
| L7 | History and records leave the controller (ADR 0571): the builder keeps its build log, one entry at a build's start and one at its end, from which build history and durations are read and the module mesh-catalog asks the builds it missed; the artifact sweep is the seat `mesh-artifact-sweep`, held by artifact-store-tools beside the artifact store, its keep set from the store's own listing, the wants and the build log, sweeping at each build's end from the lease write and recording each deletion in the hand-act log; disk readings are disk-load's own state on every node; who holds which seat is the state `seat-holders` of the seat `mesh-placement` (now `mesh-module-assigner`), and tools are found by the tool runners' announcements; what a node runs is its want and its have; the grants part writes `grants.<module>.<fingerprint>` and keeps memberships in its own state; root-free is a probe of the self-check; no manifest but the controller's reads, invokes or consumes `mesh-controller`, but a named list kept to the lease write, so the lease write's check passes (ADR 0189, ADR 0547 §11, ADR 0549 §6) | — | mesh-sdk, mesh-controller (its pin only), mesh-delivery (builder, indexer, assigner, grants part, view), mesh-catalog (artifact-store-tools, disk-load, the backup seat's holder, mounts, nfs-server, minio, mesh-watcher, the messenger, the self-check, the module mesh-catalog, docker), mesh-tools (the tool runner) | 1955 |
| B0 | The bootstrap delivery: every check, a lone pull request's as a group of one and a verdict carried after a trunk move included, is judged by a checking program built from the change's own heads in the build seat's sandbox, which also makes the heads' one seat list that the check hands the manifest validator and the composer; it brings no seat definition and no manifest field, so the running checker checks it (ADR 0644; *The bootstrap delivery, and the one milestone after it*) | 26 needs it | mesh-sdk (`go/delivery`: the seat `node-build-go`'s ask `run` and the checker's record of which checking program judged; `go/composer`: the request's seat list), mesh-catalog (mesh-build-go: the run step, the refused answer, the kept programs' tools and sweep), mesh-delivery (checker: the checking program and its command), hq (this design, the glossary) | 1921 |
| G | Two graphs and one revision view: the catalog graph and the assignment graph kept per revision, a change delivered as its graph difference, the acting parts' rules on their seats as bounded waits that hold their modules when the new version fails, the check on the change's own acting parts, the revision view and each process's own build, the gate's delivery record, and the trace's links (ADR 0656); no part reads a pull request's description (ADR 0659); every delivery part reaches the forge through the seat `git` and names no other module; nothing holds an approved merge for another check | 26 to 55 | mesh-sdk (the runtime: the fingerprint, the view, the definition reader, the seat list's one wiring), mesh-contracts and the domains' contracts modules (`acts`, the new verbs and events, the seat `mesh-grants`, the seat `git`'s verbs), mesh-delivery (indexer, assigner, checker, builder, grants part, gate's view, forge bridge, watchman), mesh-catalog (the gate, the build modules, the forge module, mesh-issues, mesh-knowledge, the `node-backup` holder, nats: a module's kept data on the bus as a backed-up item), the node-engine (`mesh-host`), hq | 1966, 1961 (retargeted to this row's shape), 1660, 1972, 1721, 1783, 1785, 1794, 1791, 1373, 595; 1962 goes back with 1958, whose assignment entry it needs (ADR 0641 §3) |
| G | Two graphs and one revision view: the catalog graph and the assignment graph kept per revision, a change delivered as its graph difference, the acting parts' rules on their seats as bounded waits that hold their modules when the new version fails, the check on the change's own acting parts, the revision view and each process's own build, the gate's delivery record, and the trace's links (ADR 0656); no part reads a pull request's description (ADR 0659); every delivery part reaches the forge through the seat `git` and names no other module; nothing holds an approved merge for another check | 26 to 60 | mesh-sdk (the runtime: the fingerprint, the view, the definition reader, the seat list's one wiring), mesh-contracts and the domains' contracts modules (`acts`, the new verbs and events, the seat `mesh-grants`, the seat `git`'s verbs), mesh-delivery (indexer, assigner, checker, builder, grants part, gate's view, forge bridge, watchman), mesh-catalog (the gate, the build modules, the forge module, mesh-issues, mesh-knowledge, the `node-backup` holder, nats: a module's kept data on the bus as a backed-up item), the node-engine (`mesh-host`), hq | 1966, 1961 (retargeted to this row's shape), 1660, 1972, 1721, 1783, 1785, 1794, 1791, 1373, 595; 1962 goes back with 1958, whose assignment entry it needs (ADR 0641 §3) |
An issue is in one row only (ADR 0493 §2): where a row named an issue another row names too, the last row keeps it and the
earlier row says so in words (the operator, 2026-10-26). Milestone M1 makes each row a record of the issue tracker
@@ -2720,10 +2864,12 @@ B0's own choices, each checked by the rows of *How it is checked* below:
it). No record decides a merge without the operator's Approve: ADR 0421 §1 and ADR 0398 §3 ask it for every merge,
and the forge's merge tool merges only a head the operator approved (ADR 0534 §4). The shape this design would give
it, once a record decides it: the verb `merge` of the seat `mesh-delivery`, taking the pull requests at their heads
and the reason, refused unless their check passed, opening a delivery record marked `recovery` with the caller as
the runtime proves it, and saying the event `recovery-merged`, which the teller tells the operator on every channel,
so a recovery merge cannot go untold. Until that record is accepted it is not built, and a recovery fix is asked the
operator's Approve like any change.
and the reason; callable only by the callers the gate's trusted config value `recovery-callers` names; refusing a
change that adds or widens an acting rule, a grant or a credential, which ADR 0656 §8 has named to the operator in
the Approve ask and which a recovery merge has none of; opening a delivery record marked `recovery` with the caller
as the runtime proves it; and saying the event `recovery-merged`, which the teller tells the operator on every
channel, so a recovery merge cannot go untold. It waits for its own record; until that record is accepted it is not
built, and a recovery fix is asked the operator's Approve like any change.
- What a process started by a node-engine that hands no fingerprint does beyond saying `own build unknown`, for a part
other than the indexer.
- The caps' and the growth's numbers are estimates (*Two graphs, one source of truth*); the fill tools read the real
@@ -2776,7 +2922,15 @@ in and recorded; the indexer reading every definition at its start; the seat `me
contracts module; the seat `git`'s verbs for every call the delivery parts make of the forge; the seat list's reader
wired once by the runtime; `go/views` as the view's machinery, with the seats' client packages typed over it; a check
that could not run asked again on the missing part's `running`; and a claim problem holding one module. Its review by
architectural domain is still to come, and this section is rewritten with its findings.
architectural domain then ran, four domains side by side, and lead-47 ruled on round 1 (2026-11-09): a seat's pass is
decided from the node-engine seat's `running` events kept by durable consumers, with the trunk's manifest for a node
that said nothing, instead of a call to a node that may be away; every act owed to the forge is safe to repeat, its
outcome said and recorded, unanswered acts said again and stalled after 15 minutes, a group's merges said one after
another, and the switch carrying what is owed; the seat `git` covers every forge call and event of the delivery parts
and the gate, its act verbs granted by the holder's trusted `callers`, the forge's acting tools and its watch of the
checker retired, and `merge-pull` judging no check, its record to be accepted before the push; the order forge, bridge,
gate with its way back, and the indexer's start without the forge; `module-held`, an error for a failed forge read and
the re-ask of a check that could not run; numbered tests 56 to 60; and the store seat's holder's own build.
Left as notes on issue 1921, not in this amendment: a conformance check that a changed layout raises its `form`; the
size and retention of restore points and set-aside data; who may call `restore` for bus data and which manifest grants