|
|
|
@@ -37,55 +37,67 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
|
|
|
|
|
*§677 to §690 come from the fix rounds of the review by architectural domain of §587 to §676 (lead-47's inputs of
|
|
|
|
|
2026-11-11): the approval mark once no verb names its callers (the operator's answer of about 16:10 CET, §610); the
|
|
|
|
|
keeper's snapshots, with the operator's answer O-7 of 20:22 CET (§681); the recovery module's verbs, the entries the
|
|
|
|
|
node-engine keeps and the grants part's first composition (§682 to §684); and develop's D-16 to D-25, of internal
|
|
|
|
|
form only. The rounds' other fixes are written in the lines they correct.*
|
|
|
|
|
node-engine keeps and the grants part's first composition (§682 to §684); the gate before a marked verb's running
|
|
|
|
|
(§677, the operator's O-8); and develop's D-16 to D-31, of internal form only. The rounds' other fixes are written in the lines they correct.*
|
|
|
|
|
|
|
|
|
|
## The approval mark, with no named callers
|
|
|
|
|
|
|
|
|
|
- §677 **A marked verb a module's process serves is asked, checked and claimed by its holder alone.** (§610; ADR
|
|
|
|
|
0286 §10 to §13, §26 to §31, §36, §37, §43; ADR 0259 §3, §6) Once no verb names its callers (§610), a module's
|
|
|
|
|
process may call a marked verb (ADR 0286 §1, §2) directly. Design 46 7-approval-mark's gate wraps only the handlers
|
|
|
|
|
the tool runner serves (its §20); a marked verb a module's process serves is judged by that process, as ADR 0286
|
|
|
|
|
§43 has the controller judge its own verbs, whoever calls it, a session through the tool runner included:
|
|
|
|
|
- **The holder asks, under its own module's name.** On a call of a marked verb it serves with no warrant for its
|
|
|
|
|
act, mesh-sdk's seat server makes the act as ADR 0286 §10 and §11 make one (the address as called, the holder's
|
|
|
|
|
own node and build, the seat and verb, every argument, digested with `operatorchannelclient.ActDigest`), asks it
|
|
|
|
|
through `operatorchannelclient` under the holder's module's name at level `approve` (ADR 0286 §13, §15 to §23),
|
|
|
|
|
unless an open ask of that act exists, and answers the call with ADR 0286 §37's refusal naming the ask. Its
|
|
|
|
|
grants to ask, hear its warrants and read its own asks are those ADR 0286 §6 and ADR 0259 §3 compose for a module
|
|
|
|
|
with a mark.
|
|
|
|
|
- **The caller calls again.** When the holder hears its own `operator-channel.decided` of that ask, it says the
|
|
|
|
|
choice on its seat's event `approval-decided`, `mesh.seat.<seat>.event.approval-decided.<ask>` (`{ask, choice}`,
|
|
|
|
|
kept last per subject, one day), which every seat definition with a marked verb gains through the seat
|
|
|
|
|
generator. A module's process that calls a marked verb names that event in its manifest's `consumes`; mesh-sdk's
|
|
|
|
|
seat client, beside the seat server in `go/seats`, keeps the refused call as a kept call (ADR 0668 §1), waits on
|
|
|
|
|
that event and makes the same call again, with the same arguments, on Approve, and ends it with the decline
|
|
|
|
|
otherwise. A person through the tool runner calls again as ADR 0286 §37 says.
|
|
|
|
|
- **The holder checks.** On a call whose act has an ask that was chosen, the seat server reads the router's own
|
|
|
|
|
record of the ask under its module's name, never the decided event's body nor the caller's word (ADR 0286 §26,
|
|
|
|
|
§36), and holds the warrant to it with `Warrant.For` and `Option.Performs` (ADR 0286 §27, §28), within 30 minutes
|
|
|
|
|
of the choice (§29), the act being the one it composes from the call it received.
|
|
|
|
|
- **The holder claims, once, in its own state.** The claim store is the holder's template state `approvals` (a
|
|
|
|
|
`requires` entry, 48 hours to live, 64 MiB): keys `ask.<id>` (the asked call), `act.<digest>` (the newest ask of
|
|
|
|
|
that act) and `claimed.<id>`, the claim, written with the bus's create, which refuses a key that exists, so two
|
|
|
|
|
calls at once, on one instance or two, cannot both claim it (ADR 0286 §30, §31). The manifest validator refuses
|
|
|
|
|
a module that serves a marked verb from a process and declares no such entry. A state that cannot be read or
|
|
|
|
|
written refuses every marked call of that holder, said as ADR 0286 §40 has it.
|
|
|
|
|
- §677 **A marked verb a module's process serves is one call with a gate before its running, asked, checked and
|
|
|
|
|
claimed by its holder alone.** (§610; ADR 0286 §10 to §13, §24, §26 to §31, §36, §37, §43; ADR 0259 §3, §6) Once
|
|
|
|
|
no verb names its callers (§610), a module's process may call a marked verb (ADR 0286 §1, §2) directly. Design 46
|
|
|
|
|
7-approval-mark's gate wraps only the handlers the tool runner serves (its §20); a marked verb a module's process
|
|
|
|
|
serves is judged by that process, as ADR 0286 §43 has the controller judge its own verbs, whoever calls it. The
|
|
|
|
|
operator, 2026-11-11 about 20:40 CET at lead-47's terminal (O-8): "the tool call should be the same, just with a
|
|
|
|
|
'gate' between the call and the execution"; so a module's call of a marked verb is one call, and the caller never
|
|
|
|
|
calls again:
|
|
|
|
|
- **The holder keeps the call and asks, under its own module's name.** On a call of a marked verb it serves,
|
|
|
|
|
mesh-sdk's seat server makes the act as ADR 0286 §10 and §11 make one (the address as called, the holder's own
|
|
|
|
|
node and build, the seat and verb, every argument, digested with `operatorchannelclient.ActDigest`), keeps the
|
|
|
|
|
waiting call whole with the caller the bus proved (ADR 0286 §24), asks it through `operatorchannelclient` under
|
|
|
|
|
the holder's module's name at level `approve` (ADR 0286 §13, §15 to §23), unless an open ask of that act exists,
|
|
|
|
|
and answers the call at once `{asked: <ask id>, act: <act id>}`. Its grants to ask, hear its warrants and read its
|
|
|
|
|
own asks are those ADR 0286 §6 and ADR 0259 §3 compose for a module with a mark.
|
|
|
|
|
- **On the Approve it runs that same call.** When the holder hears its own `operator-channel.decided` of the ask,
|
|
|
|
|
it reads the router's own record of the ask under its module's name, never the decided event's body nor the
|
|
|
|
|
caller's word (ADR 0286 §26, §36), holds the warrant to it with `Warrant.For` and `Option.Performs` against the
|
|
|
|
|
kept call (ADR 0286 §27, §28), claims it once (below), and runs the kept call, once.
|
|
|
|
|
- **The caller hears the outcome on its own subject.** The holder says the act's end on its seat's event
|
|
|
|
|
`gated-ended`, subject `mesh.seat.<seat>.event.gated-ended.<caller>.<act>`, `<caller>` the account the bus
|
|
|
|
|
proved, escaped as a key's name is (§73): `{act, ask, verb, outcome, answer, error}`, `outcome` one of `ran` (with
|
|
|
|
|
the verb's `answer`), `declined`, `expired` and `refused` (with the router's or the check's words); a decline or
|
|
|
|
|
an expiry runs nothing and says so. Kept last per subject, one day; no argument is in it. Every seat definition
|
|
|
|
|
with a marked verb gains the event through the seat generator; the grants part grants hearing
|
|
|
|
|
`gated-ended.<caller>.>` to that caller alone, from its `invokes` of the marked verb, as it composes a `by-caller`
|
|
|
|
|
verb. mesh-sdk's seat client, in `go/seats` beside the seat server, waits on that subject as a kept wait (ADR
|
|
|
|
|
0668 §1) and reads it whole at its start, so a restart of either side loses no outcome; it makes no second call.
|
|
|
|
|
- **A person through the tool runner keeps ADR 0286 §37's path for now.** An MCP call cannot be held for an ask's
|
|
|
|
|
60 minutes (O-8), so a call whose proved account is a tool runner's is answered with ADR 0286 §37's refusal
|
|
|
|
|
naming the ask, and keeps nothing; the same call made again after the Approve is checked as above and runs.
|
|
|
|
|
- **The holder claims, once, in its own state.** The holder's template state `approvals` (a `requires` entry, 48
|
|
|
|
|
hours to live, 64 MiB) keeps `ask.<id>` (the waiting call whole), `act.<digest>` (the newest ask of that act) and
|
|
|
|
|
`claimed.<id>`, the claim, written with the bus's create, which refuses a key that exists, so a warrant runs one
|
|
|
|
|
call, on one instance or two (ADR 0286 §30, §31). At its start the holder reads every kept call and acts on each
|
|
|
|
|
ask already decided as above. The manifest validator refuses a module that serves a marked verb from a process and
|
|
|
|
|
declares no such entry. A state that cannot be read or written refuses every marked call of that holder, said as
|
|
|
|
|
ADR 0286 §40 has it.
|
|
|
|
|
- **A holder that does not check is never reached.** The grants part composes, for a module's process that serves
|
|
|
|
|
a marked verb, the subscription of that verb's subjects only when the catalog graph entry of the build the
|
|
|
|
|
node-engine says `running` declares that `approvals` entry, which only a build of G's seat server passes the
|
|
|
|
|
validator with; otherwise it composes the subscribe deny design 46 7-approval-mark §6 composes for a runner that
|
|
|
|
|
does not state `approval-mark/1`, named in `withheld` with "its holder checks no warrant". So a holder of before
|
|
|
|
|
G serves none of its marked verbs, and a call finds no responder, until its G version runs: no ordering edge is
|
|
|
|
|
needed, and nothing runs unchecked.
|
|
|
|
|
G serves none of its marked verbs until its G version runs: no ordering edge is needed, and nothing runs
|
|
|
|
|
unchecked.
|
|
|
|
|
- **Before develop.** These lines rest on the record of the approval gate (number to come; its draft is with
|
|
|
|
|
lead-47), which changes ADR 0286 §13, §24, §33 and §37 for a module's call and decides §47's question of how a
|
|
|
|
|
module's call passes a verb's mark. It is accepted before G's seat server is built from them.
|
|
|
|
|
|
|
|
|
|
Why: the mark stays while no caller list does (O-6); the holder alone can read the router's record of an ask made
|
|
|
|
|
under its own name, and one ask and one claim per call keep ADR 0286 §31 (review round 2: security and upgrade 1
|
|
|
|
|
to 3, seams and tools' note). How it is checked: whole (a fixture marked verb, its holder and a module's process),
|
|
|
|
|
a call with no warrant answered with the ask and called again by the seat client on `approval-decided`, run once;
|
|
|
|
|
a warrant for other arguments refused; the same warrant used twice refused; two calls at once with one warrant,
|
|
|
|
|
one run; the same through the tool runner, asked once; unit (grants part), a holder whose running entry declares
|
|
|
|
|
no `approvals` composed with the deny of its marked subjects and named in `withheld`.
|
|
|
|
|
Why: the operator's answers O-6 and O-8; the holder alone can read the router's record of an ask made under its
|
|
|
|
|
own name (review round 2: security and upgrade 1 to 3). How it is checked: whole (a fixture marked verb, its holder
|
|
|
|
|
and a module's process), one call answered `asked` and run once on the Approve, its outcome heard on
|
|
|
|
|
`gated-ended` by that caller and no other; a decline and an expiry run nothing and say so; a restart of the holder
|
|
|
|
|
between the ask and the Approve runs the kept call once; a warrant replayed runs nothing; a call through the tool
|
|
|
|
|
runner refused with the ask and run on the same call made again; unit (grants part), a holder whose running entry
|
|
|
|
|
declares no `approvals` composed with the deny of its marked subjects and named in `withheld`.
|
|
|
|
|
## Develop's D-16 to D-18
|
|
|
|
|
|
|
|
|
|
- §678 **The forms of a finding's `owner` and `waiting-on`.** (§451, §540, §580) Each is one of three forms, written as
|
|
|
|
@@ -174,8 +186,8 @@ form only. The rounds' other fixes are written in the lines they correct.*
|
|
|
|
|
or `operator`), which the tools bundle's `recovery_*` tool passes and which a module's process leaves out. The
|
|
|
|
|
hand-act log's entry names both the account the bus proved and `asker`: the bus's is the boundary, `asker` names
|
|
|
|
|
who asked, for the record (as ADR 0626 §4 has the stamp). Each answers at once, as `snapshot-kept` does (§554):
|
|
|
|
|
`{outcome: accepted, act}`, `{outcome: busy, act}` naming the act that runs, or `{outcome: error, error}`; the
|
|
|
|
|
result comes on the act's ending event (§554, §560), under its `act` id.
|
|
|
|
|
one of `accepted` (the act's id), `busy` (the id of the act that runs) or `error` set alone (§691); the result
|
|
|
|
|
comes on the act's ending event (§554, §560), under its `act` id.
|
|
|
|
|
- `take` (`module`, `kept`, `fingerprint`): takes a point of that kept data at that fingerprint's form, as
|
|
|
|
|
`snapshot-kept` does with no `catch-up`; ends with `ended`.
|
|
|
|
|
- `restore` (`module`, `kept`, and exactly one of `snapshot`, a point's name, or `request`, a keeper's snapshot
|
|
|
|
@@ -187,8 +199,8 @@ form only. The rounds' other fixes are written in the lines they correct.*
|
|
|
|
|
- `discard-aside` (`module`, `kept`, `id`): removes that aside's directory; ends with `aside-discarded`.
|
|
|
|
|
- `expire-points` (no field of its own): runs §551's removal of points past their 90 days now; ends with
|
|
|
|
|
`expiry-ended`.
|
|
|
|
|
- `restore-aside` (`module`, `kept`, `id`) and `cancel` (`act`) as §566 has them; `cancel` answers `{outcome:
|
|
|
|
|
cancelled, act}` or `error` naming the step the act has begun.
|
|
|
|
|
- `restore-aside` (`module`, `kept`, `id`) and `cancel` (`act`) as §566 has them; `cancel` answers `cancelled`
|
|
|
|
|
(the cancelled act's id) or `error` naming the step the act has begun, set alone.
|
|
|
|
|
|
|
|
|
|
Why: the developer's D-19; the bundle calls on the tool runner's account, so the log would name the runner, not the
|
|
|
|
|
asker (review round 2). How it is checked: unit (mesh-recovery's contract), each verb's fields and answers read
|
|
|
|
@@ -297,3 +309,48 @@ form only. The rounds' other fixes are written in the lines they correct.*
|
|
|
|
|
the new one's making; whole (keeper, grants part, bus module), a part whose findings move to a template is bound on
|
|
|
|
|
the new stream after its consumer is made, its condition raised once; unit (`mesh-delivery`'s contract), both
|
|
|
|
|
answers of `source` read from their fixtures.
|
|
|
|
|
|
|
|
|
|
## The operator's O-8, and develop's D-26 to D-31
|
|
|
|
|
|
|
|
|
|
- §691 **The recovery module's contract, as the developer wrote it where no line spoke.** (§516, §554, §560, §567,
|
|
|
|
|
§682, §396) [D-30, mesh-contracts K7 to K9.] Kept as lines: every verb of the seat `mesh-recovery` answers an
|
|
|
|
|
object with one of `accepted` (the act's id), `busy` (the id of the act that runs) or `error` (why) set alone;
|
|
|
|
|
the seat's family is `mesh-recovery.events`, 7 days, for any event naming no `keep`; a point's `digests` is a list
|
|
|
|
|
of `{name, digest}`, each a bus object of the point and the `sha256:` digest of its bytes (§567); `kept-points`'
|
|
|
|
|
`running` is `{act, step, since, waits-on}`, `waits-on` present only while the act waits, and absent when no act
|
|
|
|
|
runs. Corrected: `expiry-ended` has no parts, so it is kept 90 days and not last per subject (the definition
|
|
|
|
|
validator refuses `last-per-subject` on an event without parts); §554 and §560 read so. How it is checked: unit
|
|
|
|
|
(mesh-recovery's contract), each shape read from its fixtures and `expiry-ended`'s `keep` accepted.
|
|
|
|
|
- §692 **`problems` are the manifest validator's strings.** (§668; ADR 0579 §1) [D-26, indexer IX28.] The manifest validator's problems are
|
|
|
|
|
plain strings and gain no rule names: `manifest-accepted`'s `problems` is the list of those strings, the same the
|
|
|
|
|
verdict writes as warnings, in the same order, and `{rule, words}` is not written. How it is checked: unit
|
|
|
|
|
(indexer), a faulted manifest accepted with the validator's strings.
|
|
|
|
|
- §693 **`wanted` says a want removed.** (§675) [D-27, indexer IX29.] The seat `mesh-wants`' event `wanted` gains
|
|
|
|
|
`removed`, a boolean, true when the assigner removes the want of that node and module (the node left, or the module
|
|
|
|
|
was unplaced); `fp` is then the fingerprint last wanted there, and the subject is the one that want was said on, so
|
|
|
|
|
the stream kept last per subject keeps the removal as that want's last word. The assigner says it in the same
|
|
|
|
|
write that removes the want. How it is checked: unit (assigner), an unplaced module's want said `removed`; unit
|
|
|
|
|
(indexer), a `removed` empties that member from `named`.
|
|
|
|
|
- §694 **An image's package name is its module's and its artifact's.** (§676, §491) [D-28.] An image artifact's
|
|
|
|
|
`package` is `{ecosystem: image, name: <module>/<artifact>}`, its module's name and its artifact's name from the
|
|
|
|
|
manifest joined by `/`, unique as module names are; the indexer writes it at take-in, reading no file for it, and
|
|
|
|
|
§676's "the manifest's image name" reads so. How it is checked: unit (indexer), two modules with an image artifact
|
|
|
|
|
of one name carry two package names.
|
|
|
|
|
- §695 **An old state section's cap is its `max-mib`.** (§469, §494, §588, §667, §672, §675) [D-29.] A cap the design
|
|
|
|
|
gives an old `state` section is declared in that section's entry of the part's manifest as `max-mib`, the word §469
|
|
|
|
|
added to the old section and §494's reader release reads: the indexer's `entry-index` 8, `named` 4 and `proposals`
|
|
|
|
|
4, the builder's `publish-queue` 4, `acted` 1 and `waits` 16, each in G's change of that manifest; the grants part
|
|
|
|
|
makes the bucket with it (§494). How it is checked: unit (manifest validator), each of those manifests at G's heads
|
|
|
|
|
declares its caps; whole (grants part), a bucket made with its cap.
|
|
|
|
|
- §696 **A pipeline wait's `on`.** (§534, §498, §266) [D-31, mesh-contracts CT14.] A wait with `step` `pipeline`
|
|
|
|
|
has `on` the module of the runner's new version whose healthy run ends it (the holder of
|
|
|
|
|
`mesh-pipeline-runner` the new revision names, read from the catalog half), and `words` names that version's
|
|
|
|
|
fingerprint. How it is checked: unit (runner's contract), a `pipeline` wait read with its `on`.
|
|
|
|
|
- §697 **`by-caller` reaches the mesh only after the reader release.** (§621, §494, §554) A seat definition that
|
|
|
|
|
marks a verb `by-caller` (§554's `mesh-recovery`, §681's `mesh-broker` verbs, every verb §677 gates) is read only by
|
|
|
|
|
§494's second reader release, merged and delivered before G's merge, whose publish (kind 1) rebuilds every reader
|
|
|
|
|
of seat definitions; those definitions reach the mesh only in G's merge, so the order is the release's before G
|
|
|
|
|
and needs no edge of the module graph. A reader of before the release that met one would refuse that definition,
|
|
|
|
|
which blocks only new claims of the seat (ADR 0636 §3). How it is checked: G's check reads every definition with
|
|
|
|
|
`by-caller` through the release's reader.
|
|
|
|
|
|
|
|
|
|