|
|
|
@@ -32,14 +32,69 @@ decisions:
|
|
|
|
|
One file of milestone G's part of [design 47](../47-delivery-from-commit-to-delivered.md); the part opens at
|
|
|
|
|
[G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n".
|
|
|
|
|
|
|
|
|
|
*§610 to §673 will answer lead-47's seventh batch of 2026-11-11: the operator's answers of 2026-11-11 between 15:14 and
|
|
|
|
|
*§610 to §676 answer lead-47's seventh batch of 2026-11-11: the operator's answers of 2026-11-11 between 15:14 and
|
|
|
|
|
15:42 CET at lead-47's terminal (§610 to §613, and §588 in G-16), the design questions of the six refreshed build
|
|
|
|
|
maps, and develop's D-1 to D-12. Each other line is of internal form only, within what the records and the lines it
|
|
|
|
|
cites decide. A line of another file that one of these corrects is corrected in that line (§15, §423, §515, §528,
|
|
|
|
|
§570, §584, §585, §588, and design 34 every-event §11, §19, §35); here only what is new. A question one line answers
|
|
|
|
|
maps, and develop's D-1 to D-15. Each other line is of internal form only, within what the records and the lines it
|
|
|
|
|
cites decide. A line of another file that one of these corrects is corrected in that line (§15, §30, §391, §394,
|
|
|
|
|
§423, §462, §515, §528, §570, §584, §585, §588, design 34 every-event §11, §19, §35, and design 46 7-approval-mark §22); here only what is new. A question one line answers
|
|
|
|
|
for several build maps is answered once, and the maps' names for it are given in brackets.*
|
|
|
|
|
|
|
|
|
|
*This commit carries §614 alone, ahead of the rest of the batch, so that develop can build from it.*
|
|
|
|
|
## The operator's answers
|
|
|
|
|
|
|
|
|
|
- §610 **Every class's default admits the modules that invoke it, and sessions call `warrant` and `accept`.** (§391,
|
|
|
|
|
§394, §405, §555; ADR 0666 §20, ADR 0286) The operator, 2026-11-11 about 15:40 CET at lead-47's terminal: "the
|
|
|
|
|
operator and agents may do everything, we might make it more strict and start asking for additional checks for
|
|
|
|
|
agent stuff, modules can get as many permissions as they want". §391's defaults become:
|
|
|
|
|
- `read`: `invokers`, `persons` and `sessions`, as before;
|
|
|
|
|
- `act`: `operator`, `sessions` and `invokers`;
|
|
|
|
|
- `warrant`: `operator`, `sessions` and `invokers`, and it still carries the approval mark, so each call runs only on
|
|
|
|
|
the operator's Approve of that one call, whoever made it (ADR 0286, which this line does not change);
|
|
|
|
|
- `accept`: `operator`, `sessions` and `invokers`. The runner's `accept` (§30, §394) is no longer the operator's
|
|
|
|
|
alone.
|
|
|
|
|
|
|
|
|
|
`invokers` is every module whose manifest names the verb in `invokes` (§391). A verb whose definition names its own
|
|
|
|
|
`callers` keeps them (§391); §394's verbs, which take their class's default, take the new one. So `node-backup`'s
|
|
|
|
|
`now` and `restore` (§405, §555), which take `act`'s default, are called by the operator, sessions and every
|
|
|
|
|
module that invokes them: the assigner, the node agent, the bus step's grant and the recovery module, today's
|
|
|
|
|
callers among them [mesh-contracts DQ-6]. This amends §391 and §394. Why: the operator's answer; no accepted record
|
|
|
|
|
makes a `warrant` or `accept` verb the operator's alone (ADR 0286 has the operator approve each marked call and
|
|
|
|
|
alone answer its ask). How it is checked: unit (seat-definition reader), the table's rows for `act`, `warrant`
|
|
|
|
|
and `accept` give their new callers, and a verb with `callers` of its own keeps them; whole (backup holder), a
|
|
|
|
|
`now` from the assigner's account and a `restore` from the recovery module's are taken.
|
|
|
|
|
- §611 **Five parts move only their findings to templates in G.** (§529, §577) The operator, 2026-11-11 between 15:14
|
|
|
|
|
and 15:42 CET at lead-47's terminal: in G only the state `findings` and the finding stream of the teller, the
|
|
|
|
|
status view, the watchman, enrolment and the forge bridge move to `requires` templates (§529). Their other old
|
|
|
|
|
sections stay as they are, keys and names untouched: the watchman's `presence` and `stuck`, the teller's `answers`,
|
|
|
|
|
`asked` and `ends`, the view's `answers` and `reach`, enrolment's `enrolments`, and the forge bridge's `heads`,
|
|
|
|
|
`inputs` and stream `forge`. The manifest validator accepts these parts' other old sections until a later line
|
|
|
|
|
moves them; §577's rule for the finding words stands. [mesh-delivery DQ-4.] Why: the operator's answer. How it is
|
|
|
|
|
checked: unit (manifest validator), each of the five manifests of G's heads accepted with its old sections and its
|
|
|
|
|
finding templates.
|
|
|
|
|
- §612 **The forge module's and the image registry's other template entries become old sections, empty.** (§584) The
|
|
|
|
|
operator, 2026-11-11 between 15:14 and 15:42 CET at lead-47's terminal: the forge module's `incoming` (objects,
|
|
|
|
|
2048 MiB), `transfers` and `idle`, and the image registry module's `incoming` (objects, 8192 MiB), `transfers`,
|
|
|
|
|
`idle`, `findings` and stream `events`, move to old sections under the same names, each with the cap it declares
|
|
|
|
|
today, and start empty: nothing is copied. They hold uploads in flight, which their callers ask again, and
|
|
|
|
|
findings, which are stated again at the start (§384). The template entries, no longer declared, become orphans that
|
|
|
|
|
`orphans` lists, removed only by the operator's `drop` (ADR 0595 §4, §5), as §584 has it for `holds`, `windows`
|
|
|
|
|
and `mirrors`, which alone are copied. [mesh-catalog Q-F2.] Why: the operator's answer. How it is checked: unit
|
|
|
|
|
(manifest validator), both manifests of G's heads hold no template entry; whole (image registry), a first start
|
|
|
|
|
copies only `holds`, `windows` and `mirrors`.
|
|
|
|
|
- §613 **The gate's kept data, state by state.** (§15, §156, §172, §431, §542, §584) The operator, 2026-11-11
|
|
|
|
|
between 15:14 and 15:42 CET at lead-47's terminal:
|
|
|
|
|
- `pulls` and `asks` go with nothing copied (§172, §431): G's gate declares neither, and they are orphans that
|
|
|
|
|
`orphans` lists, removed only by the operator's `drop` (ADR 0595 §4).
|
|
|
|
|
- `merges` and `source` stay in the old `state` section (§542, §15).
|
|
|
|
|
- `deliveries`, `groups`, `owed` and `conditions` move to `requires` entries of the template `state`, under the same
|
|
|
|
|
names. At its first start, before it serves anything, the gate of G copies every key of the old section of each
|
|
|
|
|
into its template entry, from its own data alone, says in its journal and in `gate_records` how many keys it
|
|
|
|
|
copied of each, and leaves a key already in the template as it is (as §584 copies the image registry's). The old
|
|
|
|
|
sections' keys stay, read no more, so a revert's gate of before G finds them, until the operator's `drop`.
|
|
|
|
|
|
|
|
|
|
[mesh-catalog Q-G1.] This corrects §15's "the gate's other kept data stay in ADR 0595's templates". Why: the
|
|
|
|
|
operator's answer. How it is checked: unit (manifest validator), the gate's manifest of G's heads declares `merges`
|
|
|
|
|
and `source` old and the four templates; whole (gate), a first start with keys in the four old sections copies
|
|
|
|
|
them, says how many, and serves them.
|
|
|
|
|
|
|
|
|
|
## Reading the catalog half, every part alike
|
|
|
|
|
|
|
|
|
@@ -83,3 +138,352 @@ for several build maps is answered once, and the maps' names for it are given in
|
|
|
|
|
the first registrations are followed, an entry asked once on a `running` of an unlisted fingerprint and dropped
|
|
|
|
|
when nothing names it, a `none-yet` branch read as empty; whole (grants part, tool runner), a part started with one
|
|
|
|
|
branch at `none-yet` acts once every first view is in; a dropped branch's findings are cleared.
|
|
|
|
|
- §615 **The tool runner's and the Go build module's manifests come from the entry too.** (§594, §614, §443, §445,
|
|
|
|
|
test 61) The mesh MCP server of the tool runner takes each module's manifest from its catalog graph entry, through §614's
|
|
|
|
|
reader; its first view of the indexer's `manifests` and its `consumes` of `mesh-delivery-indexer.views.manifests`
|
|
|
|
|
go [mesh-tools Q-R2]. The Go build module's compose ask takes each manifest whole from the entry its fingerprint
|
|
|
|
|
names, by `seat:mesh-catalog.entry` (§506's `manifest-digest` naming the entry's), and its `invokes` of
|
|
|
|
|
`mesh-delivery-indexer.indexer_read_manifests` goes [mesh-catalog Q-B1]. Both join §594's readers. Why: test 61, and
|
|
|
|
|
`manifests` is kept only for node-engines of before G (§445). How it is checked: test 61, a row each.
|
|
|
|
|
- §616 **The owner of the assigner's views is read from the catalog half.** (§428, §7) The tool runner's code reads the
|
|
|
|
|
module that holds `mesh-module-assigner` from the catalog half's claims of that seat (§614), and names the views
|
|
|
|
|
`<that module>.assignments` and `<that module>.seat-holders` from it, never by a name fixed in code. Its manifest's
|
|
|
|
|
`consumes` keeps `mesh-delivery-assigner.views.assignments` and `views.seat-holders`, the module's own declaration of
|
|
|
|
|
what it hears, as a manifest may name a module. Design 46 7-approval-mark §19's holder of `operator-channel` is read
|
|
|
|
|
from that view so found. [mesh-tools Q-R3, Q-R17.] Why: §428 removes the name from code, and the catalog half
|
|
|
|
|
says who claims a seat. How it is checked: unit (tool runner), a fixture catalog half naming another holder of the
|
|
|
|
|
seat gives views of that name; the code review finds no assigner name in the tool runner's code.
|
|
|
|
|
- §617 **The long form of an `invokes` entry stands beside `*`.** (§558, §545) A manifest's `invokes` may hold `*`
|
|
|
|
|
and long-form entries together: the tool runner's is `*`, then `{verb: "seat:mesh-catalog.revision", fields:
|
|
|
|
|
["none-yet"]}` and `seat:mesh-catalog.entry` with no fields named [mesh-tools Q-R4, Q-R18]. The manifest validator
|
|
|
|
|
accepts a long-form entry beside `*`, and each named verb gives its edge of kind 6 (§558). In mesh-sdk's Go form,
|
|
|
|
|
`Invokes` stays the list of verbs, each long-form entry's verb among them, and `InvokeFields`, beside it, maps a verb
|
|
|
|
|
to the fields it names, so none of `Invokes`' readers changes [mesh-sdk 4]. Why: `*` lets a part call any verb, and a
|
|
|
|
|
long-form entry is how it says it relies on a verb or a field, which `*` cannot say. How it is checked: unit
|
|
|
|
|
(manifest reader), `*` with two long-form entries read into `Invokes` and `InvokeFields`; unit (manifest
|
|
|
|
|
validator), the tool runner's manifest accepted and its two edges derived.
|
|
|
|
|
|
|
|
|
|
## The tool runner
|
|
|
|
|
|
|
|
|
|
- §618 **The tool runner's own fingerprint reaches no bundle.** (§205, §519; design 46 7-approval-mark §5, §19)
|
|
|
|
|
`MESH_FINGERPRINT` is one of the tool runner's own words, which `BundleEnv` hands no bundle: a bundle reads only the
|
|
|
|
|
fingerprint the node-engine composed into its environment (§519). A bundle whose environment carries none has no
|
|
|
|
|
served entry the tool runner can read, so every marked call on that runtime is refused, as design 46 7-approval-mark
|
|
|
|
|
§5 and §19 have it. [mesh-tools Q-R5, extended.] Why: a bundle given the tool runner's own value is judged against
|
|
|
|
|
the tool runner's entry. How it is checked: unit (tool runner), a bundle composed with none sees none and its marked
|
|
|
|
|
call is refused; one composed with a fingerprint sees its own.
|
|
|
|
|
- §619 **A foundation part's bundle reaches its old `objects` sections through its membership.** (§407, §518) The grants
|
|
|
|
|
part issues each old `objects` section of a foundation part in the membership, as it issues its old `state`
|
|
|
|
|
sections: mesh-sdk's membership gains `Objects`, beside `State`, mapping each section's name to its object store.
|
|
|
|
|
The tool runner resolves a put or get session's `name` (§518) of a foundation part's bundle in that field, and of any
|
|
|
|
|
other part in its state's objects store and its sent store, as §518 has them. [mesh-tools Q-R6.] Why: §407 binds
|
|
|
|
|
that bundle to its old `objects` section and no membership field carried it. How it is checked: unit (membership),
|
|
|
|
|
the field read; whole (tool runner), a foundation part's bundle puts and gets a value over the limit in its old
|
|
|
|
|
section.
|
|
|
|
|
- §620 **A sent object over the limit is read by a get session.** (§59, §518) The tool runner's `mesh/objects.sent-get`,
|
|
|
|
|
asked for another module's sent object larger than the bus's per-message limit, answers `{chunked: true, size}` and
|
|
|
|
|
sends the object through §518's get session on the bundle's channel, read from the sender's sent store under the
|
|
|
|
|
standing grant §59 gives the caller. [mesh-tools Q-R7.] Why: a bundle calling a verb whose reply is larger had no
|
|
|
|
|
way to read it. How it is checked: whole (tool runner), a reply's object of 20 MiB read whole by a bundle.
|
|
|
|
|
- §621 **What the second reader release reads, and how it is released.** (§494, §545, §605, §508, §554) §494's release
|
|
|
|
|
reads, beside `calls` (§605) and the long form (§617), the tool runner's artifact word `states` [mesh-tools Q-R8,
|
|
|
|
|
mesh-sdk 3] and `by-caller` on a verb, which the seat definition's format gains for `snapshot-kept` and
|
|
|
|
|
`restore-kept` (§554) [mesh-contracts DQ-1]. Since it also carries §508's validator rule, which is the indexer's,
|
|
|
|
|
the release is a delivery group of mesh-sdk (the reader's words) and mesh-delivery (the rule), checked and delivered
|
|
|
|
|
together [mesh-sdk 5]. Why: the running reader refuses an unknown word, and the rule is mesh-delivery's code. How
|
|
|
|
|
it is checked: unit (the release's reader), `states` and a verb's `by-caller` read; the group's one check.
|
|
|
|
|
- §622 **Where the capability words and `mesh/capabilities` are named.** (§462, §488, §576) mesh-sdk names each
|
|
|
|
|
capability word as a constant beside the calls of its family: the bus-state words (`bus-state-calls`,
|
|
|
|
|
`ledger-calls`, `ledger-upkeep-calls`, `sent-objects-calls`) in `go/buscalls`, and `put-sessions`,
|
|
|
|
|
`finding-calls` and `seat-settle-delay` with `mesh/publish` in `go/stdio.go` and `src/stdio`; the call
|
|
|
|
|
`mesh/capabilities` and its answer `{words}` are named there too, since `go/buscalls` holds only bus-state calls.
|
|
|
|
|
Which calls each word covers stays the tool runner's (§462). mesh-sdk's Go package names all four words its calls
|
|
|
|
|
need in `calls` (§605), the npm package `finding-calls` alone, since its code makes no session, ledger or sent-object
|
|
|
|
|
call. [mesh-tools Q-R9; mesh-sdk 1, 2, 11.] This amends §462's "mesh-sdk gains no capability list": it gains the
|
|
|
|
|
words, not the families. Why: the bundle fails naming a word (§488), so it must know it. How it is checked: unit
|
|
|
|
|
(mesh-sdk), each call's word; unit (tool runner), its families use mesh-sdk's constants.
|
|
|
|
|
- §623 **The forge module's fill is read through `mesh/state.info`.** (§585) A bundle's state call `mesh/state.info`
|
|
|
|
|
answers a state's bucket against its caps, so the forge module's read tool shows `failed-steps`' fill from it, not
|
|
|
|
|
counted from the keys. §585's fill bullet is corrected so. [mesh-tools Q-R11.] Why: the call exists. How it is
|
|
|
|
|
checked: unit (forge module), the fill read from the call.
|
|
|
|
|
- §624 **The tool runner's manifest `version` is §368's.** (§368, §583) The tool runner's manifest names `0.1`, the
|
|
|
|
|
`MAJOR.MINOR` of §368, as every manifest; design 34 every-event §11's "Its `version` stays `2`" is corrected.
|
|
|
|
|
[mesh-tools Q-R13.] Why: §368 is the later line and holds for every manifest. How it is checked: as §368.
|
|
|
|
|
- §625 **The act's build of a marked wait is the tool runner's own `MESH_FINGERPRINT`.** (§205; design 34 every-event
|
|
|
|
|
§35) The build an act of a marked wait names is the tool runner's own fingerprint, read from its `MESH_FINGERPRINT` at
|
|
|
|
|
its start (§205), the fingerprint the node-engine's `running` says of it; the tool runner consumes nothing more for
|
|
|
|
|
it. Design 34 every-event §35 is corrected so. [mesh-tools Q-R14.] Why: the node-engine hands each process its own
|
|
|
|
|
build (§205). How it is checked: unit (tool runner), the act carries the fingerprint of its environment.
|
|
|
|
|
- §626 **A module ends G with no more tests than it starts with.** (§419, test budget) §419 holds for the tool runner's
|
|
|
|
|
work of design 34 every-event and design 46 7-approval-mark: the new tables and the whole test of design 46
|
|
|
|
|
7-approval-mark §22 and design 34 every-event §19 replace existing tests, and every test they delete counts.
|
|
|
|
|
Their "New test functions are allowed within each module's budget" is corrected to say so. [mesh-tools Q-R16.] Why:
|
|
|
|
|
§419 is milestone G's rule and both parts ship in G's release. How it is checked: the check counts the tool runner's
|
|
|
|
|
tests against its count at G's start.
|
|
|
|
|
|
|
|
|
|
## The node-engine and the node agent
|
|
|
|
|
|
|
|
|
|
- §627 **The node-engine is a foundation part.** (§6, §529, §577; ADR 0619 §1 to §3) The node-engine composes every
|
|
|
|
|
part, the bus module included, before the bus module can answer, so it is a foundation part as ADR 0619 §1 defines
|
|
|
|
|
one, as §584 has it for the forge module and the image registry. The manifest validator's list gains the holder of
|
|
|
|
|
the seat `node-engine` in G's change; its kept data stays in its old sections, its old stream `mesh-host-findings`
|
|
|
|
|
among them, and it opens them by their declared names (§577's old-name path), not by `Binding`. [the node-engine's map, RQ-1.]
|
|
|
|
|
Why: ADR 0619 §1. How it is checked: unit (manifest validator), the node-engine's manifest of G's heads accepted with
|
|
|
|
|
its old stream.
|
|
|
|
|
- §628 **G removes the node-engine's reads of the indexer and the builder alone.** (§421, §195, §435) In G the
|
|
|
|
|
node-engine's reads of the indexer's and the builder's states go, as §421 names them. Its reads of the assigner's
|
|
|
|
|
`assignment` and `candidates`, the provisioner's `provisions` and the vault's `signers` and `node-logins` stay in G
|
|
|
|
|
(§459's input among them), and `compose-candidate` keeps its reads of `candidates`, `manifests` and `verdicts` until
|
|
|
|
|
it goes with the checker (§435). §421's "holds no read of another module's state" is checked for the indexer's and
|
|
|
|
|
the builder's states. [the node-engine's map, RQ-2, RQ-3.] Why: G moves the reads §421 names; the others need verbs no line of G
|
|
|
|
|
gives, and they are reads of another module's state that ADR 0596 §2 ends when their owners move. How it is checked:
|
|
|
|
|
the node-engine's account holds no read of the indexer's or the builder's states.
|
|
|
|
|
- §629 **The have's wait and the node-engine's `wait-held`.** (§423, §498, §499, §541, §560) A node-engine's
|
|
|
|
|
`wait-held` and `wait-ended` carry the fields of the seat `mesh-wants`' wait (§498, §512: `owner`, `step`, `node`,
|
|
|
|
|
`on`, `bound`, `since`, `words`) and `reason`; `node` is the node waited on (the build node for a kept build), and
|
|
|
|
|
the subject's `<node>` the node that says it [mesh-contracts DQ-3]. The have's value gains `wait`, one such wait with
|
|
|
|
|
`ask-at` and `act` (§560), present while the have waits; `waits`, the composition digest of the phase
|
|
|
|
|
`waiting-yes`, stays as it is [the node-engine's map, RQ-4, mesh-contracts DQ-4]. This corrects §423's "with no new field". Why:
|
|
|
|
|
§499 and §560 need the wait in the have. How it is checked: unit (node-engine seat's contract), `wait` read with
|
|
|
|
|
both fields; whole (node-engine), a kept-build wait says it.
|
|
|
|
|
- §630 **At a revert the node agent reads the point from `kept-points`.** (§516, §560) At a revert the node agent asks
|
|
|
|
|
`seat:mesh-recovery.kept-points` for the module and kept data, takes the point of the form and fingerprint it reverts
|
|
|
|
|
from, and passes its `snapshot` and its catch-up to `restore-kept`; its manifest names the verb in `invokes`.
|
|
|
|
|
[the node-engine's map, RQ-5.] Why: `ended` is kept last per subject, so a later point replaces it. How it is checked: unit (node
|
|
|
|
|
agent), a revert after two points restores the one of its form.
|
|
|
|
|
- §631 **A manifest's `catch-up` is a tool and its arguments.** (§451, §516) A manifest declares `catch-up` as `{tool,
|
|
|
|
|
arguments}`, mesh-sdk's reader takes it whole (a string of before G read as `{tool, arguments: {}}`), and the node
|
|
|
|
|
agent passes it to `snapshot-kept` unchanged. [the node-engine's map, RQ-6.] Why: `snapshot-kept` takes both. How it is checked:
|
|
|
|
|
unit (reader), both forms read.
|
|
|
|
|
- §632 **The node agent's `why`.** (§516) It gives `snapshot-kept` the `why` "form change of `<module>`'s `<kept>` to
|
|
|
|
|
`<fingerprint>`" and `restore-kept` "revert of `<module>`'s `<kept>` from `<fingerprint>`", which the hand-act log
|
|
|
|
|
keeps. [the node-engine's map, RQ-7.] How it is checked: unit (node agent), both words.
|
|
|
|
|
- §633 **§557's bounds are `config` keys.** (§557) Each bound §557 makes a setting is a key of the part's manifest
|
|
|
|
|
`config`, read at its start through mesh-sdk's `stdio.Config`, its default the design's value; the node-engine's are
|
|
|
|
|
`recovery-wait-minutes` (90) and `view-waits-minutes` (5) [the node-engine's map, RQ-8], the condition keeper's two hours of §540
|
|
|
|
|
`owner-handover-minutes` (120) [D-7], and every other part's is named `<what>-<unit>` alike. The gate's own settings
|
|
|
|
|
stay where they are. Why: one form for every part's bound. How it is checked: each whole test sets its bounds in
|
|
|
|
|
its fixture's `config`.
|
|
|
|
|
- §634 **The node-engine's own name, everywhere it is used, is §527's.** (§428, §527) Its discovery, its finding
|
|
|
|
|
stream's subject and observer, and the vault's login names read the node-engine's own module from §527, as its
|
|
|
|
|
guard, compose and bootstrap do. [the node-engine's map, RQ-9.] How it is checked: the code review finds no fixed name.
|
|
|
|
|
- §635 **The node-engine invokes `withheld`; it gains no `uses`.** (§555, §558; design 46 7-approval-mark §6) Its
|
|
|
|
|
manifest names `seat:mesh-grants.withheld` in `invokes`, which gives the served-verb edge, and gains no `uses`.
|
|
|
|
|
[the node-engine's map, RQ-10.] How it is checked: unit (manifest validator), the edge derived.
|
|
|
|
|
- §636 **The private network module's name is its own manifest's.** (§428) `overlay.Name` stays the `module` the private network package's (`overlay`)
|
|
|
|
|
computed manifest names itself; mesh-networking removes the fixed `mesh-provisioner` alone, read from the seat
|
|
|
|
|
list's holder of `mesh-provisioner`. [the node-engine's map, RQ-11.] How it is checked: the code review.
|
|
|
|
|
- §637 **Test 36 reads the builds of before G through the registry seat.** (§405, §555, §610) Test 36's run, in the
|
|
|
|
|
check the running checker makes of G (ADR 0667 §2), fetches the builds of before G and the recovery module by their
|
|
|
|
|
fingerprints through the seat `oci-artifact-registry`, read-only, under the checker's account, its manifest naming
|
|
|
|
|
the fetch in `invokes`, granted by §610's default. [the node-engine's map, RQ-12.] How it is checked: test 36 runs in that check.
|
|
|
|
|
|
|
|
|
|
## mesh-sdk's shared parts
|
|
|
|
|
|
|
|
|
|
- §638 **The asker client is mesh-contracts' `operatorchannelclient`.** (§570, §586; ADR 0573 §1) The client §570
|
|
|
|
|
names is `operatorchannelclient`, of the seat `operator-channel`'s contracts in mesh-contracts, which already
|
|
|
|
|
bounds the expiry; `Take` answers `Refused` with the router's words. mesh-sdk builds nothing for it. The fields
|
|
|
|
|
§570 names are the contract's: on `decided`, the warrant's `ask` (the ask's id) and `words` (the why); on the record,
|
|
|
|
|
`state` `refused` and `answer`, and the record gains `at`. §570 is corrected so. [mesh-sdk 6, mesh-contracts DQ-9,
|
|
|
|
|
DQ-8.] Why: a seat's client lives in its contracts package (ADR 0573 §1). How it is checked: unit
|
|
|
|
|
(`operatorchannelclient`), a refusal answered and an expiry past its level's bound refused.
|
|
|
|
|
- §639 **A views reader writes its findings through the part's writer.** (§461, §485, §580) `go/views`' findings
|
|
|
|
|
(`view-waits`, `first-view-unanswered`, `view-unsaid`, `view-too-large`) are written through the part's mesh-sdk
|
|
|
|
|
writer as kinds of their own (§580), and the writer's statement covers them beside `observe`'s. [mesh-sdk 7.] How it
|
|
|
|
|
is checked: unit (writer), a statement keeps the reader's open findings.
|
|
|
|
|
- §640 **The writer keeps its copy of the finding layout, held equal to the generated types.** (§439, §452) mesh-sdk's
|
|
|
|
|
writer keeps its own `FindingBody`, `FindingCleared`, `FindingsStated` and `FindingsAsked`, in Go and TypeScript, and
|
|
|
|
|
a test in mesh-contracts holds them field for field equal to the types the seat generator emits. [mesh-sdk 8.] Why:
|
|
|
|
|
one layout, checked, without changing which package imports which. How it is checked: that test.
|
|
|
|
|
- §641 **A stream kept last per subject: where it is read and how it is told.** (§396, §556) mesh-sdk's
|
|
|
|
|
`HearSeatEvents` makes §556's read at the start with an ordered consumer, then follows the durable, and names the
|
|
|
|
|
stream `waiting` in `<module>_first_views` until the read ends [mesh-sdk 9]. The grants part tells such a stream by
|
|
|
|
|
the seat definition's `keep` of that event, and grants its ordered consumer from the reader's `consumes`
|
|
|
|
|
[mesh-delivery DQ-7]. `wait-held` and `wait-ended` of the node-engine each have their own stream (§396), with
|
|
|
|
|
`running`'s keep (no age limit, last per subject) [mesh-contracts DQ-2]; §556's "on the stream `running` is kept
|
|
|
|
|
on" reads so. How it is checked: unit (mesh-sdk), the start read then the durable; unit (grants part), the ordered
|
|
|
|
|
consumer granted from `keep`.
|
|
|
|
|
- §642 **A binding's `objects` is a state's field, and the sent store an entry.** (§399, §513) In mesh-sdk's
|
|
|
|
|
membership, `objects` is a field of a state's binding, and the sent store an entry of its own, local name
|
|
|
|
|
`sent-objects`, as §399 has it; §513's "fields of `membership.BusBinding`" reads so. [mesh-sdk 10.] How it is
|
|
|
|
|
checked: unit (membership).
|
|
|
|
|
- §643 **Put and get sessions are Go only in G.** (§518, §57) A TypeScript bundle's value over the per-message limit
|
|
|
|
|
fails at once, naming the limit, in G. [mesh-sdk 12.] How it is checked: unit (mesh-sdk TypeScript), the refusal.
|
|
|
|
|
- §644 **`Hearing` is told which events are defined.** (§474) `catalogue.Hearing` takes, beside the manifests, a
|
|
|
|
|
function the grants part passes, answering whether an event is defined by a seat definition of the seat list or is
|
|
|
|
|
one of mesh-sdk's finding events. [mesh-sdk 13.] How it is checked: unit (`Hearing`).
|
|
|
|
|
|
|
|
|
|
## mesh-delivery's parts
|
|
|
|
|
|
|
|
|
|
- §645 **The checker's seat definition is in mesh-delivery's contracts.** (§528) §528's "the checker's seat
|
|
|
|
|
definition in mesh-contracts" is corrected to mesh-delivery's contracts module, where `tag-wanted` is removed.
|
|
|
|
|
[mesh-delivery DQ-1, mesh-contracts DQ-13.]
|
|
|
|
|
- §646 **The runner's bodies name `fingerprint`.** (§585) The runner's `step-ended`, pipeline and wait bodies name the
|
|
|
|
|
build-input fingerprint `fingerprint`, not `fp`, as §585 reads it. [mesh-delivery DQ-2.] How it is checked: unit
|
|
|
|
|
(runner's contract).
|
|
|
|
|
- §647 **The runner times an ask from `ask-taken`.** (§535, §602) §535's five minutes run from the ask until the build
|
|
|
|
|
seat holder's `ask-taken` (§602), which the runner consumes; `step-started` is the runner's own. [mesh-delivery
|
|
|
|
|
DQ-3.] How it is checked: whole (runner), an ask no holder takes ends its pipeline after the setting.
|
|
|
|
|
- §648 **A `take-in.taken` entry carries the pull request.** (§476, §542) An entry is `{module, commit, fingerprint,
|
|
|
|
|
repository, pull}`, the last two from a `merged` message and absent for a `pushed` one. [mesh-delivery DQ-5.] How it
|
|
|
|
|
is checked: unit (indexer's contract).
|
|
|
|
|
- §649 **`ParseStepKey` answers the asker.** (§484) `buildstep.ParseStepKey(key)` answers `(asker, node, id, err)`,
|
|
|
|
|
`asker` empty for main's form. [mesh-delivery DQ-8.] How it is checked: unit, both forms.
|
|
|
|
|
- §650 **The `mesh-builds` client's name.** (§586) It is `contracts/go/clients/meshbuildsclient`, with `Reserved`.
|
|
|
|
|
[mesh-delivery DQ-9.]
|
|
|
|
|
- §651 **The checker's first tier of the change's own acting parts is not built.** (§528, §66, §279 to §290) The
|
|
|
|
|
checker of G's heads never makes G's own check (ADR 0667 §2), so the first tier of §279 to §290 (CK6 to CK8) is not
|
|
|
|
|
built in the checker; the runner's steps check a change's acting parts from G's delivery. [mesh-delivery DQ-10.]
|
|
|
|
|
- §652 **`pins-stated` is kept as `pinned` is.** (§579) The seat `mesh-delivery`'s definition gives `pins-stated` the
|
|
|
|
|
`keep` of `pinned`, so the indexer's consumer from the stream's first message hears it. [mesh-delivery DQ-11.]
|
|
|
|
|
- §653 **The teller's reads of the gate's `asks` go.** (§431, §512, §593) The teller's manifest drops its `reads` of
|
|
|
|
|
`mesh-delivery-gate.asks`, since the Approve per merge goes. [mesh-delivery DQ-12.]
|
|
|
|
|
|
|
|
|
|
## mesh-catalog's parts
|
|
|
|
|
|
|
|
|
|
- §654 **The readers of the forge module's old events and tools move to the seat `git`.** (§310, §311, §313, §431)
|
|
|
|
|
mesh-config consumes `git`'s `pull-merged` and `pull-closed` in place of `gitea.pull.merged`, `gitea.pull.closed`
|
|
|
|
|
and `gitea.forge.pull-request.closed`, and invokes `seat:git.pull` in place of `gitea.gitea_get_pull_request`; the
|
|
|
|
|
records module consumes `git.pull-merged`; mesh-issues invokes `seat:git.pull` and `seat:git.contains`, and reads a
|
|
|
|
|
pull request's checks and reviews from the delivery record's `show` (its steps' results, the review step's among
|
|
|
|
|
them), in place of `seat:mesh-delivery.checks` and `gitea_pull_reviews`. [mesh-catalog Q-F1.] How it is checked:
|
|
|
|
|
unit (manifest validator), each manifest of G's heads names none of the old events or tools.
|
|
|
|
|
- §655 **The take and restore of one stream is shared code in mesh-sdk.** (§554, §464; ADR 0672 §1) The code that
|
|
|
|
|
takes and restores one stream's snapshot moves whole from the bus module's `bussnap` into mesh-sdk's `go/bussnap`,
|
|
|
|
|
imported by the bus module (its snapshot before `recreate` and `drop`) and by the recovery module (its points and
|
|
|
|
|
restores); no module imports another module's package. [mesh-catalog Q-R1.] Why: code two modules share lives in
|
|
|
|
|
mesh-sdk (§464's reason). How it is checked: the code review finds one copy.
|
|
|
|
|
- §656 **The hand tools are the recovery module's own tools, answered by its process.** (§554, §566; ADR 0672 §3, §7)
|
|
|
|
|
Each hand tool is a module tool on the process's own `by-caller` subject, the bundle passing the call through, so
|
|
|
|
|
the bus proves the tool runner's account; the seat `mesh-recovery` gains no verb. [mesh-catalog Q-R2.] How it is
|
|
|
|
|
checked: whole (recovery module), a hand tool from another account is refused by the bus.
|
|
|
|
|
- §657 **The recovery module's health check is a tool.** (§554, §468) The recovery module serves the read tool
|
|
|
|
|
`recovery_kept_points`, answering what `kept-points` answers, and its declared health check names it.
|
|
|
|
|
[mesh-catalog Q-R3.] How it is checked: unit (manifest validator), the check names a served tool.
|
|
|
|
|
- §658 **A module new in G starts with the tests its lines name.** (§419) A module new in G counts from none: its
|
|
|
|
|
tests are the checks its design lines name (for the recovery module, its one whole test and the unit rows of its
|
|
|
|
|
lines), within the per-module budget. [mesh-catalog Q-R4.]
|
|
|
|
|
|
|
|
|
|
## mesh-contracts' seat contracts
|
|
|
|
|
|
|
|
|
|
- §659 **`snapshot-kept` and `restore-kept` are of class `act`.** (§554; ADR 0672 §3) Class `act`, their callers
|
|
|
|
|
`seat:node-engine` alone, as §554 names them. [mesh-contracts DQ-5.]
|
|
|
|
|
- §660 **A finding's key and value.** (§461, §437, §439) The state `findings` keeps the key `<scope>.<id>.<kind>` and the
|
|
|
|
|
value `#/bodies/Finding`. [mesh-contracts DQ-7.]
|
|
|
|
|
- §661 **`list` shows the caps.** (§547) The seat `mesh-broker`'s `list` answer gains `caps {sum-mib,
|
|
|
|
|
account-limit-mib, server-limit-mib}`, an absent limit meaning unlimited. [mesh-contracts DQ-10.]
|
|
|
|
|
- §662 **A subject function with parts can fail.** (§523) A generated subject function with `<part>` tokens answers
|
|
|
|
|
`(string, error)` in Go and throws in TypeScript for an empty part, `.` or `..`. [mesh-contracts DQ-11.]
|
|
|
|
|
- §663 **The condition keeper's sources are the bus module's `created` events.** (§515, §529) The keeper takes a
|
|
|
|
|
source when it hears the seat `mesh-broker`'s `created` of a part's `finding-events` entry, and a foundation part's
|
|
|
|
|
old finding stream from the catalog half (§614); at its start it reads both by `list` and the catalog half. §515 is
|
|
|
|
|
corrected so. [mesh-contracts DQ-12; D-7's COND9.] Why: the grants part makes the consumers (§386), and no binding
|
|
|
|
|
names one. How it is checked: whole (keeper, bus module), a part declaring finding events is asked once its entry
|
|
|
|
|
is `created`.
|
|
|
|
|
- §664 **`backed-up` needs no contract change.** (§563) The backup holder's answer carries a put-off item's `act` and
|
|
|
|
|
since when in its own fields. [mesh-contracts DQ-14.]
|
|
|
|
|
- §665 **`attempt-changed` is keyed by condition and attempt.** (§541) The subject is
|
|
|
|
|
`mesh.seat.mesh-healers.event.attempt-changed.<condition>.<attempt>`, kept last per subject, so two attempts on one
|
|
|
|
|
condition both stay. [mesh-contracts DQ-15.] How it is checked: unit (healers' contract).
|
|
|
|
|
|
|
|
|
|
## Met in develop
|
|
|
|
|
|
|
|
|
|
- §666 **`nats_snapshot_get`'s arguments and answer.** (§554, §567; ADR 0672 §1, §8; ADR 0666 §16) It takes `request`,
|
|
|
|
|
the id of the bus module's `drop` or `recreate` request whose snapshot is asked, as the keeper's requests record it.
|
|
|
|
|
It answers `{request, module, local, stream, size, digest, at, object}`: `digest` the `sha256:` digest of the
|
|
|
|
|
snapshot's bytes, and `object` the name of the snapshot in the bus module's sent store (§59), which the recovery
|
|
|
|
|
module reads by the standing grant of that answer; a snapshot larger than the sent store's cap (§591) answers
|
|
|
|
|
`error`, naming its size and the cap. `recovery_restore` names it by `request`, and the recovery module checks the
|
|
|
|
|
bytes against `digest` before it takes any aside, as §567. [D-1.] Why: the snapshot crosses the bus as every large
|
|
|
|
|
answer does, never as a shared file. How it is checked: whole (bus module, recovery module), a `drop`'s snapshot
|
|
|
|
|
restored by `recovery_restore` with its `request`, and one with altered bytes refused.
|
|
|
|
|
- §667 **Where a trusted change and the seed wait for their warrant.** (§3, §8; ADR 0666 §2, §12; ADR 0259) [D-2, D-3.]
|
|
|
|
|
- **Kept.** The indexer keeps each change of `register`, `policy`, `watch` and `unwatch` awaiting its warrant in its
|
|
|
|
|
old `state` section `proposals`, one key `<verb>.<module>` (`<verb>.<module>.<branch>` for `watch` and
|
|
|
|
|
`unwatch`, each token escaped as a key's name is, §73), holding the change whole, the ask's id, its caller and
|
|
|
|
|
when it was asked; the seed's key is `seed`. Capped at 4 MiB.
|
|
|
|
|
- **Asked.** Through `operatorchannelclient`, kind `ask`, level `approve`, its `about` the key, so a newer change of
|
|
|
|
|
the same key replaces the open ask (ADR 0666 §12).
|
|
|
|
|
- **Heard.** By the indexer's durable consumer of `mesh.seat.operator-channel.event.decided.<the indexer's module>`.
|
|
|
|
|
A warrant writes the version by compare-and-set and deletes the key; a Decline, an expiry or a refusal deletes it
|
|
|
|
|
and writes nothing, said in its journal and its answer to the caller; the seed's keeps `seed-waits` (§8).
|
|
|
|
|
- **A restart.** At its start the indexer reads each key and the seat `operator-channel`'s `asks` for its ask:
|
|
|
|
|
a decided one is applied as above, an open one waited on, and one the router no longer holds deleted, said.
|
|
|
|
|
- **Its tools.** `indexer_proposals` (class `read`) lists the keys with their asks; `indexer_seed_again` raises
|
|
|
|
|
the seed's ask again from its key (§8).
|
|
|
|
|
|
|
|
|
|
How it is checked: whole (indexer), a `policy` applied on its warrant after a restart while open, a decline
|
|
|
|
|
writes nothing, and two `policy` changes of one module leave one ask.
|
|
|
|
|
- §668 **`manifest-accepted`'s `problems`.** (§500; ADR 0579 §1) The event gains `problems`, a list of `{rule,
|
|
|
|
|
words}`: each problem the indexer's re-judgement finds in a manifest it keeps accepted because its digest is
|
|
|
|
|
unchanged (ADR 0579 §1), the same items its verdict writes as warnings; an empty list when none. It is defined in
|
|
|
|
|
the seat `mesh-catalog`'s definition in mesh-delivery's contracts, a row of its contracts change. [D-4.] How it is
|
|
|
|
|
checked: unit (indexer), a manifest a stricter validator faults is accepted with its problems, and a mended one
|
|
|
|
|
says none.
|
|
|
|
|
- §669 **A have whose parts differ says the phase `held`.** (§524) §524 holds as written: the phase `held`, its detail
|
|
|
|
|
opening `parts-differ:` and naming each digest that differs, and `wait-held` with the reason `parts-differ`; the
|
|
|
|
|
build as made (H-8) stands. [D-6.]
|
|
|
|
|
|
|
|
|
|
## The builder's forms
|
|
|
|
|
|
|
|
|
|
- §670 **The key codec of the catalog half is a package of its own, which reaches no bus.** (§614) The codec of a
|
|
|
|
|
catalog key's parts (`KeyPart`, `ParseKeyPart`) is mesh-delivery's contracts package
|
|
|
|
|
`contracts/go/clients/meshcatalogkey`, which imports neither mesh-sdk's `views` nor the bus client;
|
|
|
|
|
`meshcatalogclient` keeps the wiring of §614 and imports it. The builder's `builds` package imports
|
|
|
|
|
`meshcatalogkey` alone, so it reaches no bus. [D-8.] Why: a package that only reads and writes keys needs no bus,
|
|
|
|
|
and the builder's `builds` package is held to that (its test `TestThePackageReachesNoBus`, red on main too). How it
|
|
|
|
|
is checked: that test, and one in `meshcatalogkey` that it imports no bus.
|
|
|
|
|
- §671 **`build.ended` names the node that keeps a kept build in `kept-on`.** (§271, §379, §526) For a kept build the
|
|
|
|
|
builder's `build.ended` carries `kept-on`, the build node that keeps it, once for the build, beside `made`, the name
|
|
|
|
|
§526 gives the want's field; every artifact of the build is kept on that node, and each artifact in `made` keeps its
|
|
|
|
|
digest as now. A build not kept carries no `kept-on`. [D-9.] How it is checked: unit (builder), a kept build's
|
|
|
|
|
`build.ended` names its node, and the assigner writes it into the want (§526).
|
|
|
|
|
- §672 **The builder's toolchain wait.** (§267, §276, §472, §629) The builder holds an entry while its fingerprint
|
|
|
|
|
names a toolchain version of its language other than the one the builder's newest `toolchain-agreed` of that
|
|
|
|
|
language names (§267). It keeps each wait in its old `state` section `waits`, one key `<module>.<fingerprint>`
|
|
|
|
|
(escaped as a key's name is, §73), capped at 4 MiB, deleted when the wait ends. It says `wait-held` and
|
|
|
|
|
`wait-ended` on its own stream, on `mesh.stream.mesh-delivery-builder.event.wait-held` and `.wait-ended` (G-4's
|
|
|
|
|
table), the body the fields of §629's wait with `step` `building`, `on` `toolchain:<language>@<version>`, `module`
|
|
|
|
|
and `fingerprint`, and `wait-ended` its `how` (`ran` when a `toolchain-agreed` names that version, `released` by
|
|
|
|
|
`builder_release`). `builder_waits` reads the state, and `builder_release` builds the entry with the running build
|
|
|
|
|
module, written in the hand-act log (§276). [D-10.] How it is checked: whole (builder), an entry held until
|
|
|
|
|
`toolchain-agreed` names its version, then built, the wait ended `ran`; one released by hand ended `released`.
|
|
|
|
|
- §673 **`package-published`'s one `dependencies` list holds both kinds.** (§374, §466) The contract's `dependencies`
|
|
|
|
|
in each artifact of `package-published` is §466's `resolved` and `toolchain` in one list: each item `{kind,
|
|
|
|
|
part, version, digest}`, kind 1 for each `resolved` package (its part the package's artifact reference, §504) and
|
|
|
|
|
one item of kind 3 for the toolchain (its part the agreed toolchain's part, its digest the building node's, §466).
|
|
|
|
|
The indexer writes §374's entries of kinds 1 and 3 from the items of those kinds. [D-11.] How it is checked: unit
|
|
|
|
|
(`mesh-builds`' contract), a list of both kinds read; whole (indexer), the release's kind-1 and kind-3 entries.
|
|
|
|
|
- §674 **`<module>_first_views` says the part's own build.** (§205, §424, §519, §618) Both answers of a part's first
|
|
|
|
|
views, the bundle reader's and the process's status tool's, gain `own-build` beside their list: the fingerprint the
|
|
|
|
|
node-engine composed into the part's environment (§519), or `unknown` when it carries none (§618). A process writes
|
|
|
|
|
it at its start at the key `own-build` of its state `first-views`, which its tools bundle's status tool reads.
|
|
|
|
|
[D-13.] How it is checked: unit (`go/views`), both answers with a fingerprint and with none.
|
|
|
|
|
|
|
|
|
|
## The indexer's entries
|
|
|
|
|
|
|
|
|
|
- §675 **`entry` finds an entry by its fingerprint, and keeps one while a want or a running build names it.** (§443,
|
|
|
|
|
§199, §556, §614) [D-14.]
|
|
|
|
|
- **By fingerprint.** The indexer keeps, in its old `state` section `entry-index`, one key per build-input
|
|
|
|
|
fingerprint, holding the digest of its entry's object (§179, §443); it writes the key when it first stores the
|
|
|
|
|
entry and deletes it when it removes the object. `entry` reads the key and then the object. Capped at 8 MiB (an
|
|
|
|
|
estimate: about 0.1 KiB a key for some tens of thousands of builds).
|
|
|
|
|
- **Its callers.** `entry` is of class `read`, so it takes `read`'s default (§391, §610), its invokers among them
|
|
|
|
|
(§614).
|
|
|
|
|
- **Kept while named.** The indexer consumes the node-engine seat's `running` and `mesh-wants`' `wanted`, read whole
|
|
|
|
|
at its start as §556 has a stream kept last per subject and then followed by a durable consumer, both in its
|
|
|
|
|
`consumes`. It keeps in its old `state` section `named` one key per fingerprint with the set of
|
|
|
|
|
`<node>.<module>` whose want or running build names it, written by compare-and-set, capped at 4 MiB. An entry
|
|
|
|
|
object is removed only at the first revision after no kept revision lists it and its `named` set is empty; a
|
|
|
|
|
`wanted` or `running` that moves on removes its `<node>.<module>` from the old fingerprint's set.
|
|
|
|
|
- **Its tool.** `indexer_entries` (class `read`) reads a fingerprint's key, its object's digest and its `named` set.
|
|
|
|
|
|
|
|
|
|
How it is checked: unit (indexer), an entry no revision lists is answered by `entry` while a want names it and
|
|
|
|
|
removed after the want moves on; a restart reads `named` whole before it removes anything.
|
|
|
|
|
- §676 **Each entry carries its artifacts' package names.** (§491, §478, §504, §412) At take-in the indexer reads each
|
|
|
|
|
artifact's package name from the revision's own files at the artifact's path (the `module` of its `go.mod` for a Go
|
|
|
|
|
package, the `name` of its `package.json` for an npm package, the manifest's image name for an image) and writes it
|
|
|
|
|
into the entry's artifact as `package`, `{ecosystem, name}`. The manifest validator judges §491 from the entries'
|
|
|
|
|
`package` fields, and the builder's mapping (§478, §504) reads them there. [D-15.] How it is checked: unit
|
|
|
|
|
(indexer), a Go and an npm artifact's names read into their entries; unit (manifest validator), two entries
|
|
|
|
|
carrying one name refused, naming both.
|
|
|
|
|
