Answer develop's third batch of questions on milestone G, and let the design writer answer internal forms
The operator answered D-12, D-13 and D-19 at the terminal, and ruled on 2026-11-11 that a question touching nothing the operator sees, no permission and no data kept is answered as a design line by the design writer and read by the reviewers by architectural domain. The new part file G-10 carries those answers and the internal-form ones (§456 to §479), the earlier lines point to them, and playbooks 02, 07 and 08 and the glossary say who answers a design question now. The questions that touch who may call or what the operator sees are left for the operator. Claude-Session: https://claude.ai/code/session_01JG73KEq4zoDfM9WtYpcQgZ
This commit is contained in:
+4
-1
@@ -1337,7 +1337,10 @@ Not a domain of the mesh but of the way it is built, listed because its words me
|
||||
*Not:* ~~context file~~ (hq)
|
||||
- **design question** — what a milestone's builder would have to choose because its milestone part does not say it:
|
||||
a field, a key, a bound, an owner, a caller, an event, a fate for what exists. It is asked of the operator, and its
|
||||
answer is written into the design before any code builds it (playbook 02); nobody else answers it. A milestone's
|
||||
answer is written into the design before any code builds it (playbook 02); nobody else answers it, save one of
|
||||
internal form only (changing nothing the operator sees, no permission and no data kept or removed: a wire form, a
|
||||
function's input, a contract field's shape, a package's place), which the design writer answers as a design line
|
||||
read by the reviewers by architectural domain (playbook 07, step 0). A milestone's
|
||||
design is **complete** when no design question of it is open (playbook 07, *Design complete*).
|
||||
*Not:* ~~open point~~ (hq)
|
||||
- **issue** — a question about the mesh that someone must answer, numbered and tracked by the issue tracker, which
|
||||
|
||||
@@ -192,7 +192,11 @@ be built (the cycle test reads only a design's main file today).
|
||||
## Answering a design question
|
||||
|
||||
A design question (playbook [07](07-feature-branches.md), step 0) is answered by the operator and by nobody else:
|
||||
not by the lead, the preparer, a developer or a reviewer, however technical it is. The lead asks it as the
|
||||
not by the lead, the preparer, a developer or a reviewer, however technical it is. The one exception is a question
|
||||
of internal form only (playbook 07, step 0, *Who answers a design question*; the operator, 2026-11-11): changing
|
||||
nothing the operator sees, nobody's permissions and no data kept or removed, it is answered by `hq-design-writer` as
|
||||
a design line of the milestone part with its reason, under the record it follows from, read in item 3's round, and
|
||||
told to the operator in one line. The lead asks it as the
|
||||
instruction on asking says, one question per ask, with what the milestone part says, what it leaves open, where it
|
||||
was met (file:line) and a recommendation. Then:
|
||||
|
||||
@@ -210,8 +214,9 @@ was met (file:line) and a recommendation. Then:
|
||||
part at that branch's head.
|
||||
|
||||
How it is checked: every design question in the milestone file names the hq commit that answers it; a design line
|
||||
added during a milestone with no operator's answer or record behind it is a finding of the review by
|
||||
architectural domain.
|
||||
added during a milestone with no operator's answer or record behind it, other than an answer of internal form only
|
||||
that touches nothing the operator sees, no permission and no data, is a finding of the review by architectural
|
||||
domain.
|
||||
|
||||
## Amending an existing design
|
||||
|
||||
|
||||
@@ -54,8 +54,8 @@ A small fix (one repository, one issue, about an hour of work) follows
|
||||
and the code; a developer refused an event the design names; and an audit found seven rulings against the records
|
||||
or the design (among them a store kept twice and a copy of another part's data) and 29 questions the design never
|
||||
answered, all found in develop. The design is now the only input to the prepare and to develop, the prepare's only
|
||||
output is where each design line lands and what the design does not answer, nobody but the operator answers that,
|
||||
and develop starts only when it is all answered (step 0b, *Design complete*).
|
||||
output is where each design line lands and what the design does not answer, the operator answers that (or, for a
|
||||
question of internal form only, the design writer, step 0), and develop starts only when it is all answered (step 0b, *Design complete*).
|
||||
- **A module proven only after it reached the machines.** The mail modules were delivered with unit tests
|
||||
only, then failed live three times (issues 859, 865, 868) and took five more hours of fixes.
|
||||
|
||||
@@ -68,7 +68,7 @@ opened **once**, after the review, and **one check** (ADR 0548). It runs in five
|
||||
| Step | What happens | Bound |
|
||||
|---|---|---|
|
||||
| 0. Prepare | from the milestone part alone: where each design line lands in code, what exists there today and what relies on it, as one build map per repository; and every design question, the design's silences, listed | 15 minutes, longer when what exists is large: code never starts on an incomplete answer |
|
||||
| 0b. Design complete | the operator answers every design question; each answer is written into the milestone part (playbook 02) and its build map rows added | until the list is empty: develop never starts before |
|
||||
| 0b. Design complete | every design question is answered, by the operator or, for one of internal form only, by `hq-design-writer` (step 0); each answer is written into the milestone part (playbook 02) and its build map rows added | until the list is empty: develop never starts before |
|
||||
| 1. Develop | one fixing agent per repository builds every design line of its build map locally, each commit citing the lines it builds, the whole unit suite before every commit, the integration tests compiled, and once per head it reports those of the packages it touched and their importers run against an embedded bus (below); nothing is pushed | the milestone's issues, 30 minutes each |
|
||||
| 2. Review | one reviewer reads all of it, the local commits, judging the integration tests by reading them against the code; reports go both ways; at most 3 rounds | 15 minutes |
|
||||
| 3. Check | push the reviewed heads once and open the pull requests together; the checker's one check runs the integration tests; no further review unless the check fails | one check run |
|
||||
@@ -137,16 +137,23 @@ are held where they are decided: the reviewers by architectural domain judge the
|
||||
- **The prepare's only output** is one build map per repository (item 4) and the list of design questions
|
||||
(item 10). It writes no findings of its own, no recommendations into the build map and no rulings, and no file of
|
||||
the milestone holds a statement of how something should be.
|
||||
- **Nobody but the operator answers a design question**, however technical: not the lead, not the preparer, not a
|
||||
developer or a reviewer, and not a lead of another session. The lead's part is the process: who works on what, on
|
||||
which model, the waits and the reports, and asking the operator.
|
||||
- **Who answers a design question** (the operator, 2026-11-11). A question that changes nothing the operator sees,
|
||||
nobody's permissions (who may call, publish or read what) and no data kept or removed (an internal wire form, a
|
||||
function's input, a helper's API, a contract field's name or shape, a package's place) is a question of internal
|
||||
form only: `hq-design-writer` answers it as a design line from the design and its records, with its reason, the four
|
||||
reviewers by architectural domain read it in one round, and the lead tells the operator each such answer in one
|
||||
line. Every other design question is the operator's, however technical: not the lead's, the preparer's, a
|
||||
developer's or a reviewer's, nor a lead's of another session; one that seems internal but touches who may call,
|
||||
what the operator sees or data is the operator's. The lead's part is the process: who works on what, on which
|
||||
model, the waits and the reports, and asking the operator.
|
||||
- **One milestone has one lead.** A session that held part of the work hands its branches and heads to the lead and
|
||||
stops; between sessions travel heads, commits, design questions and the hq commits that answer them, never an
|
||||
instruction on how to build.
|
||||
|
||||
How it is checked: every subtask in a build map and every commit of the milestone cites the design lines it builds
|
||||
("design NN M §n"), and the review finds code that cites none (step 2, item 2a); the milestone's files hold no
|
||||
rulings (`grep -n -i 'ruling' .work/<slug>/*.md` finds none); a question answered by anyone but the operator is a
|
||||
rulings (`grep -n -i 'ruling' .work/<slug>/*.md` finds none); a question answered by anyone but the operator, other than one of
|
||||
internal form only answered by `hq-design-writer` in a design line the reviewers by architectural domain read, is a
|
||||
breach the lead names at the next report.
|
||||
|
||||
1. **Name the feature once:** `feat/<slug>`, the same branch name in every repository it touches (but see the
|
||||
@@ -289,10 +296,13 @@ Develop starts only when the milestone's design questions are all answered, each
|
||||
2026-11-10: a question the design does not answer stops that part, goes to the operator, and its answer goes into
|
||||
the design before the code).
|
||||
|
||||
1. **The lead asks the operator each question**, one per ask, as playbook [02](02-graduation.md), *Answering a design
|
||||
question*, says, and adds each ask to its wait list. The lead answers none and passes on no answer of its own.
|
||||
1. **The lead sorts each question and asks the operator's.** A question of internal form only (step 0, *Who answers
|
||||
a design question*) goes to `hq-design-writer` in its handover; every other one the lead asks the operator, one per
|
||||
ask, as playbook [02](02-graduation.md), *Answering a design question*, says, and adds each ask to its wait list.
|
||||
The lead answers none and passes on no answer of its own; a question the writer finds is not of internal form only
|
||||
it hands back for the operator.
|
||||
2. **Each answer is written into the milestone part** by `hq-design-writer` on hq's branch of the milestone, as a
|
||||
design line (or, outside every record's question, after its decision record), and the four reviewers by
|
||||
design line (the operator's citing the operator and the date, the writer's own giving its reason) (or, outside every record's question, after its decision record), and the four reviewers by
|
||||
architectural domain read the amended part in one round.
|
||||
3. **The preparer adds the new lines to the build maps** (item 4) and the question's entry names the hq commit that
|
||||
answers it.
|
||||
@@ -302,7 +312,8 @@ the design before the code).
|
||||
**A question met later stops only its part.** A developer or the reviewer who meets a question the milestone part
|
||||
does not answer stops the subtasks that need the answer, says the question to the lead with the design line and
|
||||
file:line, and goes on with the subtasks that do not; the lead adds it to the list and asks it as above, and the
|
||||
stopped subtasks resume from the hq commit that answers it. Nobody builds around it, guesses it or builds both ways.
|
||||
stopped subtasks resume from the hq commit that answers it; one of internal form only goes to `hq-design-writer` as
|
||||
item 1 says. Nobody builds around it, guesses it or builds both ways.
|
||||
**A decision accepted while the milestone is built** that changes its part stops the subtasks of the lines it changes
|
||||
until the part is amended (playbook [02](02-graduation.md)) and their build map rows are redone; code written before
|
||||
the design was complete joins the milestone only where each of its commits builds a design line of the complete part,
|
||||
|
||||
@@ -47,7 +47,10 @@ processing power"). Everything before the push is local and fast, and no try is
|
||||
makes the code do what its issue and its design already say needs nothing more. Anything no design line gives is
|
||||
a **design question**: the session asks the operator, one question with its recommendation, and the answer is
|
||||
written into the design (playbook [02](02-graduation.md), *Answering a design question*) before any code builds
|
||||
it; neither the session nor the lead answers it. A handover to the developer quotes the design lines and never
|
||||
it; neither the session nor the lead answers it. A question of internal form only (playbook
|
||||
[07](07-feature-branches.md), step 0, *Who answers a design question*) is answered instead by `hq-design-writer`
|
||||
as a design line, read by the four reviewers by architectural domain in one round, and told to the operator in
|
||||
one line. A handover to the developer quotes the design lines and never
|
||||
decides a placement itself (2026-11-04: a class placed in mesh-sdk by a lead's handover, against that section,
|
||||
passed review and its check). A fix that turns out to need a second repository, or more than about an hour,
|
||||
stops here and becomes a feature; one that needs a design question answered stays a small fix. **The session's own model (the larger) then writes the issue's acceptance
|
||||
|
||||
@@ -282,7 +282,7 @@ code{font:12.5px ui-monospace,monospace;background:var(--soft);padding:1px 5px;b
|
||||
<h3>Step 0 · what the lead writes before any agent starts</h3>
|
||||
<ul style="margin:6px 0;padding-left:20px;font-size:14px">
|
||||
<li><span class="tag new">new</span>The milestone part of the design is the only input: the prepare maps each design line onto code (a build map per repository, each row citing its line) and lists every design question, what the design does not answer. It writes no findings or rulings of its own.</li>
|
||||
<li><span class="tag new">new</span>Design complete: the operator answers each question, the answer is written into the milestone part, and only then does develop start. Nobody else answers one.</li>
|
||||
<li><span class="tag new">new</span>Design complete: the operator answers each question, or the design writer one of internal form only (no change to what the operator sees, no permission, no data kept or removed), read by the reviewers by architectural domain; the answer is written into the milestone part, and only then does develop start. Nobody else answers one.</li>
|
||||
<li><span class="tag new">new</span>What exists today, read from the code and the live mesh, never from memory: every effect of a part removed or moved (bus writes, files, credentials, plans, processes, calls answered), every reader relying on each, what happens to each after the change and its test. It opens each build map; no code before it is complete, and the review refuses work without it.</li>
|
||||
<li><span class="tag new">new</span>Subtasks ordered so a user starts from the commit that adds its contract; one writer per file; one placement of the siblings for every agent.</li>
|
||||
<li>Into each issue: every file and test it touches (file:line), how it is checked and delivered, a group's merge order.</li>
|
||||
@@ -475,7 +475,7 @@ const P = [
|
||||
{n:"07",name:"Features",kind:"build",c:"--build",
|
||||
trig:"Work that changes code across issues or repositories, too large for a small fix.",
|
||||
who:"A lead (larger model), one fixing agent per repository (smaller), one reviewer (larger).",
|
||||
steps:["Prepare: name the branch, make the worktrees, read the milestone part and the design's main file whole. (new)","Every agent is one of hq's definitions (mesh-preparer, mesh-developer, mesh-code-reviewer, mesh-watcher); the lead writes only the handover. (new)","The prepare's only output: a build map per repository, each row a design line and where it lands, and the design questions. No rulings. (new)","Design complete: the operator answers every question, each written into the milestone part; then develop. (new)","Read what exists today from the code and the live mesh: every effect of what is removed or moved, every reader of each, what happens to each and its test. No code before it is complete; the review refuses work without it. (new)","The build map opens with what exists today; subtasks ordered contract first, one writer per file.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is tried on one node first, what the one check does not cover. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per subtask, each citing its design lines; a question stops only its subtask. (new)","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk; nothing is pushed, no try runs. (new)","Review all of it against the design lines, code no line asks for a finding, reading the integration tests against the code; at most 3 rounds; the report answers the state-and-seams and mesh-agnostic questions. (new)","A group pins the group's own mesh-sdk head in every member. (new)","Push the reviewed heads once and read each forge head against the reviewed commit; no draft pull request, no fix round on an open one. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by; the one check runs. A failed check is read, fixed, reviewed, pushed once more. (new)","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery in the status view (moving, settled, stuck, delivered) to done; resolve the issues; clean up. (new)","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store; a broken controller is put back by a want the operator writes, a hand build by mesh-hand-compose and a want. (new)"],
|
||||
steps:["Prepare: name the branch, make the worktrees, read the milestone part and the design's main file whole. (new)","Every agent is one of hq's definitions (mesh-preparer, mesh-developer, mesh-code-reviewer, mesh-watcher); the lead writes only the handover. (new)","The prepare's only output: a build map per repository, each row a design line and where it lands, and the design questions. No rulings. (new)","Design complete: the operator answers every question (the design writer one of internal form only), each written into the milestone part; then develop. (new)","Read what exists today from the code and the live mesh: every effect of what is removed or moved, every reader of each, what happens to each and its test. No code before it is complete; the review refuses work without it. (new)","The build map opens with what exists today; subtasks ordered contract first, one writer per file.","Write the findings and acceptance criteria into each issue.","Survey every other reader and writer of each changed value. (new)","Answer three questions in the milestone file: who deletes each new key and stream, how the switch-over is tried on one node first, what the one check does not cover. The review checks them. (new)","List every part the change reaches; copy fixtures from the real writer.","Develop: one agent per repository, one commit per subtask, each citing its design lines; a question stops only its subtask. (new)","A test fails first on behaviour, not on compiling. (new)","Bring each branch up to the trunk; nothing is pushed, no try runs. (new)","Review all of it against the design lines, code no line asks for a finding, reading the integration tests against the code; at most 3 rounds; the report answers the state-and-seams and mesh-agnostic questions. (new)","A group pins the group's own mesh-sdk head in every member. (new)","Push the reviewed heads once and read each forge head against the reviewed commit; no draft pull request, no fix round on an open one. (new)","Open one pull request per repository, together, with Reviewed-by and Pushed-by; the one check runs. A failed check is read, fixed, reviewed, pushed once more. (new)","The operator's Approve on Telegram; the group merges in one pass.","Follow the delivery in the status view (moving, settled, stuck, delivered) to done; resolve the issues; clean up. (new)","When the builder cannot deliver its own fix: revert, a build by a session's call, a registration at the terminal, copies kept outside the store; a broken controller is put back by a want the operator writes, a hand build by mesh-hand-compose and a want. (new)"],
|
||||
prod:"One pull request per repository, one source revision delivered, resolved issues, no branch or worktree left.",
|
||||
next:"02 (when it ships)",bounds:"Prepare 15 min · 30 min per issue · review 15 min, ≤ 3 rounds · one check, pushed once",
|
||||
prev:["Pull requests as scratchpads","Context bought again and again","A change built on what was remembered, not on what runs","Review rounds spent on what a run would show","A node agent's bus reads, proven only by review"],
|
||||
@@ -483,7 +483,7 @@ const P = [
|
||||
{n:"08",name:"Small fixes",kind:"build",c:"--build",
|
||||
trig:"One issue in one repository, about an hour of work.",
|
||||
who:"The session, with one reviewer on the larger model.",
|
||||
steps:["Read the issue, the design lines it builds and the code; a design question goes to the operator and into the design before code. (new)","Read what exists in the fix's area today, briefly: every reader of what the fix changes. (new)","Write the acceptance criteria.","Move the issue to fixing.","Build on fix/<issue>-<slug> in its own worktree.","A test that fails today first, on behaviour. (new)","Nothing is pushed and no try runs before the review. (new)","One review of the local commit.","Push the reviewed head once; only then open the pull request. (new)","The operator's Approve; the merge; the delivery, followed in the status view. (new)","Prove the fix live and resolve the same hour.","During a milestone: ride in its delivery group, unless broken for the operator now. (new)"],
|
||||
steps:["Read the issue, the design lines it builds and the code; a design question goes to the operator (one of internal form only to the design writer) and into the design before code. (new)","Read what exists in the fix's area today, briefly: every reader of what the fix changes. (new)","Write the acceptance criteria.","Move the issue to fixing.","Build on fix/<issue>-<slug> in its own worktree.","A test that fails today first, on behaviour. (new)","Nothing is pushed and no try runs before the review. (new)","One review of the local commit.","Push the reviewed head once; only then open the pull request. (new)","The operator's Approve; the merge; the delivery, followed in the status view. (new)","Prove the fix live and resolve the same hour.","During a milestone: ride in its delivery group, unless broken for the operator now. (new)"],
|
||||
prod:"One pull request, one delivery, a resolved issue.",
|
||||
next:"—",bounds:"About an hour · one review, one push, one check",
|
||||
prev:["A fix reviewed after its pull request opened","A long part run twice","A fix waiting on someone else's delivery","Ten SDK merges and eight controller merges in a day, one per fix"],
|
||||
|
||||
@@ -1491,7 +1491,7 @@ way is written down before the switch (ADR 0526, which ADR 0522 §6 asked of R4g
|
||||
names it and its node composes it (ADR 0547 §2).
|
||||
2. **A build by a session's call.** A session calls the build module's fetch and build tools on one named build node (for Go, a fetch and then
|
||||
a build with publishing on); the build module pushes the artifact to the artifact store and answers its reference, as it does for the
|
||||
builder (ADR 0526 §2, ADR 0525 §8). `mesh-pack`, in mesh-sdk, builds and packs a Go bundle with the Go build module's recipe, so a hand
|
||||
builder (ADR 0526 §2, ADR 0525 §8). `mesh-pack`, in mesh-sdk (from milestone G in `mesh-delivery-sdk`, G §464), builds and packs a Go bundle with the Go build module's recipe, so a hand
|
||||
build has the build module's form; with the same Go version it has the build module's digest (ADR 0526 §5).
|
||||
3. **A registration by reference, at the controller's terminal only.** The operator names the module, its repository, its path and each
|
||||
artifact's reference at the controller's terminal, and the controller registers it with no builder key, recording the act with its why;
|
||||
|
||||
@@ -307,7 +307,7 @@ check and deliver milestone G itself (ADR 0667 §2); each of them says so in a l
|
||||
module and build-input fingerprint, with the commits it was seen at and the run that failed it, until none of those
|
||||
commits is a watched branch's head or the head an open pull request names (*The runner's kept data*); so a head
|
||||
merges while the runner is down, judged on what it already heard (ADR 0666 §11, ADR 0596). A head's fingerprints are
|
||||
those its runs named for its commit; a step that failed at that fingerprint in any run, a group's or another commit's
|
||||
those its runs named for its commit (kept as §475 says); a step that failed at that fingerprint in any run, a group's or another commit's
|
||||
of the same content included, refuses it, unless a later run of that same step at that fingerprint, asked again by
|
||||
the operator or the healers (the runner's `rerun`), passed: that pass clears the failure from `failed-steps` (ADR 0666
|
||||
§11). The runner's `step-ended` says that the step was a rerun and the caller the runtime proved, and the forge module
|
||||
|
||||
@@ -0,0 +1,281 @@
|
||||
---
|
||||
layer: to-be
|
||||
status: in-progress
|
||||
design: 47
|
||||
milestone: G
|
||||
updated: 2026-11-11
|
||||
decisions:
|
||||
- "ADR 0667"
|
||||
- "ADR 0668"
|
||||
- "ADR 0666"
|
||||
- "ADR 0660"
|
||||
- "ADR 0635"
|
||||
- "ADR 0625"
|
||||
- "ADR 0596"
|
||||
- "ADR 0595"
|
||||
- "ADR 0584"
|
||||
- "ADR 0564"
|
||||
- "ADR 0363"
|
||||
- "ADR 0240"
|
||||
---
|
||||
|
||||
# 47, milestone G: the answers to develop's second batch of questions
|
||||
|
||||
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".
|
||||
|
||||
## From develop, the second batch (2026-11-11)
|
||||
|
||||
*The operator, 2026-11-11 about 11:15 CET at lead-47's terminal: a design question that changes nothing the operator
|
||||
sees, nobody's permissions (who may call, publish or read what) and no data kept or removed (an internal wire form, a
|
||||
function's input, a helper's API, a contract field's name or shape, a package's place) is answered as a design line by
|
||||
the design writer, from the design and its records, read by the four reviewers by architectural domain in one round,
|
||||
and told to the operator in one line each; every other question goes to the operator (playbook 07, step 0b). §456 to
|
||||
§458 are the operator's answers of 2026-11-11 at the terminal; §459 to §467 answer questions of that internal form,
|
||||
each the design's choice with its reason, §468 to §479 those of the runner's, the build's, the indexer's, the contracts' and the forge's developers the same way. What §463 and
|
||||
§467 leave about callers waits for the operator and is said there.*
|
||||
|
||||
- §456 **A verb that names no `class` is a `read`, and nothing refuses one.** A verb whose definition names no `class`
|
||||
takes the default of `read` (§391), whether it is on main or G adds it: the seat-definition reader, the seat
|
||||
generator and the manifest validator refuse no verb for naming no `class`, and the validator says the default each
|
||||
verb took, as §391 has it. The verbs whose class this design names (§394, §405, §422, §446, §447) name it in their
|
||||
definitions. This amends §391, its "a verb G adds must name its `class`" and its check's refusing row. Why: the
|
||||
operator, 2026-11-11 at the terminal (develop question D-12): a refusal would be "hard-coded logic for no good
|
||||
reason". How it is checked: unit (definition reader), a row where a verb G adds with no `class` takes `read`'s
|
||||
callers; unit (seat generator), a definition with a verb naming no `class` is generated.
|
||||
- §457 **The put session's wire form.** §345's put session runs on the subject `<bundle call subject>.put.<call id>`.
|
||||
Each chunk is one message whose body is the value's raw bytes, at most half the bus's maximum payload as the
|
||||
connection reads it from the server, with the header `Mesh-Put-Seq` (a decimal from 1, one more each chunk) and, on
|
||||
the last chunk alone, `Mesh-Put-Last: true`. The tool runner answers each chunk with `{seq}`, the sequence it took,
|
||||
or `{error}`, and the bundle sends the next chunk only after a `{seq}`; the tool runner's answer to the last chunk is
|
||||
the call's answer. A chunk whose `Mesh-Put-Seq` is not one more than the last taken is answered `{error}` naming
|
||||
both, and the put is dropped as one not sealed (§345). A get of a value over the limit (§407) runs the same form on
|
||||
`<bundle call subject>.get.<call id>`, the tool runner sending the chunks with the same headers and the bundle
|
||||
answering each. Why: the operator, 2026-11-11 at the terminal (develop question D-13); the out-of-order refusal and
|
||||
the get's mirror are the design's choice, one form both ways. How it is checked: whole (mesh-sdk, tool runner), as
|
||||
§345, and a chunk sent out of order fails the put naming both sequences; unit (tool runner), a chunk over half the
|
||||
maximum payload refused.
|
||||
- §458 **How each artifact carries its version.** An image is tagged with the version `MAJOR.MINOR.PATCH` and labelled
|
||||
`org.opencontainers.image.version` with it; a Go program is linked with `-ldflags -X main.meshVersion=<version>`
|
||||
beside the existing `-X main.builtFor`; a Node program reads its version from its package.json `version`, which is
|
||||
the version (§370). A build that carries no version (§371, §373) stamps none: the Go variable stays empty, and the
|
||||
image and the package.json keep what they carry today. This completes §370's "its tag and label" and "reads it as
|
||||
its own version". Why: the operator, 2026-11-11 at the terminal (develop question D-19); a build without a version
|
||||
is §371's and §373's. How it is checked: whole (Go, TypeScript and image build modules), a built image's tag and
|
||||
label, a Go program's `main.meshVersion` and a Node program's own version are the reserved version.
|
||||
- §459 **`SeatsToPassOn`'s input.** mesh-sdk's `catalogue.SeatsToPassOn` takes the holdings on record, the
|
||||
assignments (each a node, a module and its placement's watched branch), what the caller heard of each node and
|
||||
module from the node-engine seat's `running` (a fingerprint, `stopped`, or nothing heard since its consumer began),
|
||||
and a reader of entries the caller passes over its own view of the catalog half, which answers an entry by its
|
||||
fingerprint (§443) and a module's entry on a watched branch's newest revision. The function resolves each
|
||||
assignment's entry itself: by the heard fingerprint; with nothing heard, the module's entry on its placement's
|
||||
branch, §199's one fallback, which no caller applies; a `stopped` module claims nothing on that node (§404). Where
|
||||
the reader answers no entry for an assignment, no seat that assignment could claim passes and the holder on record
|
||||
stays, as ADR 0660 §1 has it with no single claimant, and the answer says it, naming the node, the module and the
|
||||
fingerprint. It answers the passes and what it says, as ADR 0660 §3. The function reads no bus. This amends §199
|
||||
and §404. Why: ADR 0660 §3 has one rule both parts apply, and §199 the fallback in that one function; with the
|
||||
entry read through a reader each part passes, the node-engine and the grants part feed it from their own views
|
||||
(ADR 0596 §2), and the function stays a pure rule (develop question D-14). How it is checked: unit
|
||||
(`SeatsToPassOn`), a table with a row per case: a heard fingerprint, nothing heard (the branch's entry taken), a
|
||||
`stopped` holder passing no seat, and an entry not answered keeping the holder on record and saying it.
|
||||
- §460 **An asker says whether its key is still open.** mesh-sdk's kept-call form takes, beside the ask's key, a
|
||||
function `open` the asker passes, which reads the asker's own state and answers whether that key is still open, and,
|
||||
where one exists, the event that replaces the ask; it asks again only while `open` answers yes and no replacing
|
||||
event was heard. An error of `open` is written in the asker's journal naming the key, and the form asks again: a
|
||||
kept call is one the callee takes once by a key (ADR 0668 §2), so asking again is safe, and not asking would be
|
||||
silent. This amends §425: the replacing event is optional, `open` always given. Why: an ask with no replacing event
|
||||
must still stop when its asker closed it (§351; develop question D-15). How it is checked: unit (kept-call form), a
|
||||
key `open` answers closed is not asked again, a replaced one is not, and an `open` error is logged and asked again.
|
||||
- §461 **mesh-sdk's finding writer.** The writer is mesh-sdk's `go/views` writer and its TypeScript twin, mesh-sdk's
|
||||
`src/views`, exported from its index as `views`, the same functions in both (§452). An observer makes it with: the
|
||||
binding of its own state `findings`, its bus connection, and the subjects of `finding-written`, `finding-cleared`,
|
||||
`findings-stated` and `findings-asked`, which the generated `mesh-conditions` contract's subject functions make from
|
||||
the observer's module name and node (§452, §383), so the writer names no seat and no module; and the observer's
|
||||
`observe` function. Its acts:
|
||||
- `write`, a finding: writes the key `<scope>.<id>.<kind>` in `findings`, keeping the key's `since` where it
|
||||
exists (§384), and says `finding-written` only when what the finding says changed (§383).
|
||||
- `clear`, a finding's `scope`, `id` and `kind` and `why`: deletes the key and says `finding-cleared`.
|
||||
- Every event is published awaiting the bus's acknowledgement, sent again for one minute when unacknowledged, then
|
||||
written in the observer's journal as an error naming the finding (§383).
|
||||
- `observe` is a function the observer passes, which answers the findings it observes now and its pending keys
|
||||
(each with its `since` and its bound), or an error. The writer calls it at its start and on each ask, writes each
|
||||
stated finding's key, deletes each key neither stated nor pending, and says `findings-stated` (§384), putting a
|
||||
set larger than one bus message in the observer's sent store (§59, §407). An error of `observe` is written in the
|
||||
journal and no set is said, so the keeper's `findings-unstated` follows (§390).
|
||||
- The asks: the writer makes a consumer of its own on `findings-asked` that delivers only the asks published after
|
||||
it is made, the statement at start answering any before (§390), and answers an ask that names no `module` or
|
||||
names its own.
|
||||
- Between the seat's contract and the writer pass only the subjects: an observer calls the generated
|
||||
`mesh-conditions` contract's subject functions and hands their strings to the writer. mesh-contracts' bucket
|
||||
adapter `meshconditionsclient/findings` goes in G, its callers in mesh-delivery making mesh-sdk's writer instead
|
||||
in the same change; a client package of `mesh-conditions` keeps only what two callers would each write beside the
|
||||
contract (ADR 0625 §4). A client package of any seat, `meshwatchdogsclient` among them, is an artifact of its
|
||||
contracts module, as every package that module publishes is, so `go-meshwatchdogsclient` is one of the health and
|
||||
repair contracts module's artifacts.
|
||||
Why: §383, §384 and §390 decide the events and their order; the writer's form is the design's choice (develop
|
||||
questions D-16 and C15), every observer stating through one writer. How it is checked: unit (writer, both languages), the
|
||||
acts above each say their event with §439's fields, an ask naming another module is not answered, an error of `observe`
|
||||
says no set; §383's and §384's checks.
|
||||
- §462 **Where the bus state calls and their capabilities land.** The calls' names and shapes are in mesh-sdk's
|
||||
`go/buscalls`, which holds only those (its package's own rule): §408's ledger calls are `mesh/ledger.fill` (one
|
||||
ledger's fill against its cap, as `buscalls.Fill`) and `mesh/ledger.remove` (one instance removed with its
|
||||
operations and its snapshot, §155), and §407's `mesh/objects.sent-get`. The capability each belongs to is listed
|
||||
where the capabilities are today, in the tool runner in mesh-tools (its families of calls per capability): the two
|
||||
ledger calls under `ledger-calls`, `mesh/objects.sent-get` under `bus-state-calls`. mesh-sdk gains no capability
|
||||
list. This amends §347 ("mesh-sdk lists") and §408. Why: the tool runner states the capabilities of the calls it
|
||||
answers (ADR 0595 §9) and the shapes alone are shared, so a module importing the calls rebuilds nothing of the tool
|
||||
runner's (develop question D-17). How it is checked: unit (tool runner), its table of families names each new call
|
||||
under its capability; unit (`buscalls`), each request and answer read.
|
||||
- §463 **The input of the build seats' `steps`.** `steps` takes `artifact`, the key of `detected-steps` (§414), and
|
||||
`fetch` to detect the artifact's steps, `again` (yes or no) to detect again, or `drop` (yes) with `why` (a non-empty
|
||||
text) to delete the key; `fetch` is required unless `drop` is given, and `why` with `drop`. A drop answers `dropped`,
|
||||
the artifact, or `error`, and is written in the hand-act log of the seat `mesh-hand-acts` with the caller the bus
|
||||
proved for the call (never a field of the input), the artifact and `why`. It is defined once, in
|
||||
`mesh-delivery-contracts`' part `build-step`, for the three build seats. It is not the verb `drop` of §338, which
|
||||
drops asks. This completes §326. Why: the design's choice (develop question D-18). How it is checked: unit
|
||||
(`build-step` contract), a `drop` without `why` and an ask without `fetch` or `drop` refused; whole (Go build
|
||||
module), a drop deletes the key and is in the hand-act log with its caller. Who may call `steps` with `drop` waits
|
||||
for the operator: §326 has a drop on a person's word while §338 names the runner and the indexer as `steps`'
|
||||
callers; the contract and the build modules are built to this line meanwhile.
|
||||
- §464 **The delivery SDK's two step packages, and where the build modules' shared code goes.** In
|
||||
`modules/mesh-delivery-sdk` (after §427's move), `buildstep` holds what every delivery part reads of a step: the step
|
||||
ask of a pipeline and its end, `step-ended` (§24), and the kept-artifact judgement of §271, as develop built them;
|
||||
`steprun` (§420) holds what only the build modules run: the step run and the fetch and release (§327), the
|
||||
regenerate-and-compare step and its out-of-step answer, and the per-node CPU share as `steprun/buildcpu`. The seat
|
||||
generator moves with them, as the package `seatgen` of `mesh-delivery-sdk` with its command `cmd/seatgen`, and the
|
||||
command `mesh-pack` as `cmd/mesh-pack` there. So all of mesh-build-go's `buildstep` Go module leaves mesh-catalog,
|
||||
the TypeScript and image build modules import only the delivery SDK, and the delivery SDK requires nothing of
|
||||
mesh-catalog. This amends §327's "a build-step package" and the main file's "`mesh-pack`, in mesh-sdk". Why: code
|
||||
the build modules share is the delivery SDK's (ADR 0635 §4; §327), a module importing another module's package is a
|
||||
seam no mesh path carries, and mesh-sdk takes only the runtime every module uses (ADR 0625 §9), which a generator is
|
||||
not; `buildstep` stays light for the parts that only read the step's contract (develop questions D-20 and SD1). How
|
||||
it is checked: a search of mesh-catalog finds no `buildstep`, `seatgen`, `buildcpu` or `mesh-pack` under
|
||||
mesh-build-go; the delivery SDK's go.mod requires no mesh-catalog module; §327's search.
|
||||
- §465 **A group run's build ask names each package member's build, and the build module reads it from the store.**
|
||||
The ask's `fetch` (the part `build-step`'s Fetch) gains `builds`: a list of `{package, module, artifact, digest}`,
|
||||
one per package member of §373, `package` the name in its ecosystem (the Go module path, the npm name), `module` and
|
||||
`artifact` the member's catalog names and `digest` its build's `sha256:` digest; a package `builds` names is named in
|
||||
neither `packages` nor `package`. The build module reads each from the artifact store through the provision it
|
||||
already requires, `artifact-store`, at the reference it stores at,
|
||||
`artifact-store://<module>/<artifact>/blobs/<digest>`, checks the bytes against the digest and lays them as §373
|
||||
says. No registry seat gains a verb, and no grant changes: the store is read as every machine reads it. This
|
||||
completes §373. Why: the digest is the builder's own fact (§373) and the store is addressed by digest already
|
||||
(develop question BLD12). How it is checked: test 103; unit (`build-step` contract), `builds` read; whole (Go build
|
||||
module), a fetched build whose bytes do not match its digest fails the step naming the member.
|
||||
- §466 **A build names what it resolved.** Each built artifact of the build answer (BuiltArtifact, in the step's
|
||||
result) gains `resolved`, a list of `{package, version, digest}`, one per mesh package the build resolved (one
|
||||
that the catalog graph entry's packages name, the edges of kind 1), `digest` the `sha256:` digest of the package's
|
||||
bytes as the build fetched them; ToolchainUsed gains `digest`, the building node's digest of its toolchain program
|
||||
(§472), kind 3's entry, never the build module's own program. The builder carries both, per artifact,
|
||||
in `package-published` as `resolved` and `toolchain`, from which the indexer writes §374's entries of kinds 1 and 3.
|
||||
This completes §374. Why: §374 has the build module name each dependency with its version and digest in its step
|
||||
key, and the indexer read no other part's state (ADR 0596 §2; develop question BLD13). How it is checked: unit
|
||||
(`build-step` contract), both fields read; whole (Go build module, builder, indexer), a released version's kind-1
|
||||
and kind-3 entries carry the digests the build named.
|
||||
- §467 **A step key starts with its asker.** The build seats' state `steps` (in `node-build-go`, `node-build-node`
|
||||
and `node-build-image`) keys a step `<asker>.<node>.<id>`: `<asker>` the ask's `asker` (`checker`, `runner`,
|
||||
`indexer`, `assigner`, `builder`), `<node>` the node that runs it, `<id>` the ask's id, so §206's read grant of each
|
||||
asker is its own prefix and each holder writes only its node's keys. Keys of the old form `<node>.<id>`, written before G, are read by no
|
||||
tool of G's and go by the state's own two-day age, as on main; nothing is removed by hand. This amends the three
|
||||
seats' `steps` key form on main. Why: §206 and §125 decide that each asker reads only its own step keys (ADR 0363
|
||||
§2); the key's form is what makes that grant a fixed prefix (develop question BLD14). How it is checked: the seats'
|
||||
fixtures; whole (Go build module), a step of each asker keyed under its name. Whether the `<asker>` must be the account the bus proves published the ask, rather than the ask's
|
||||
field, waits for the operator, since it decides who can have a step key written under another asker's name.
|
||||
- §468 **The runner's health check is its tool `runner_health`.** §76's check, run outside the process, is of kind
|
||||
`tool` (ADR 0240) and names the runner's own tool `runner_health`, named as the runner's other tools are
|
||||
(`runner_release`, `runner_catch_up`); it answers as every `tool` health check answers, healthy when the runner
|
||||
answers `show` and each durable consumer §76 names is less than five minutes behind, and otherwise naming each one
|
||||
behind. It is called as every module's health tool is, with no caller added. Why: the design's choice (develop
|
||||
question Q-RN1); one prefix per module's tools. How it is checked: §79's check; the runner's manifest names it.
|
||||
- §469 **An old `state` section declares its cap.** An old `state` section's entry takes `max-mib`, as its old
|
||||
`objects` section's does, and mesh-sdk's `buscompose` makes the bucket with that many MiB as its maximum size; an
|
||||
entry naming none has no cap, as on main, so no bucket of today changes. The runner's `pipelines` names 256 and its
|
||||
`kept` 128 (§85); a write the bus refuses at the cap is said as the runner's `full` (§181), its read tools answering
|
||||
each fill against the cap (§83). Why: §85's caps are the bus's, so a full store refuses loudly (§181) rather than
|
||||
trusting the owner's own count; the field is the one the `objects` section has (develop question Q-RN2). How it is
|
||||
checked: unit (manifest reader), `max-mib` on a state read and a value out of the objects section's bounds
|
||||
refused; whole (runner), a write past a fixture's small cap says `full`.
|
||||
- §470 **The step log is an old `logs` section, kept 100 days.** The runner's `step-log` is declared in its manifest
|
||||
as an old `logs` section, with `max-age-days` 100 and `max-mib` 128, and is written and read onward by sequence
|
||||
through mesh-sdk's kept log (its `Read` from a sequence), as §330 reads it; the seat `mesh-pipeline-runner`'s
|
||||
definition keeps listing it, keyed by `<pipeline>`. A log already takes an age up to 3650 days and refuses no
|
||||
entry it holds, so the design's 100 days stand, and mesh-sdk's bound on a stream's age (30 days) and the indexer's
|
||||
rule that repeats it stay as on main. This amends §85's "old `streams` section" for `step-log`. Why: §330 reads the
|
||||
log onward by sequence, which is what a kept log is, and the log section declares the age and cap §85 names with no
|
||||
new word (develop questions Q-RN3 and Q-RN6). How it is checked: the catalog's validation at G's heads accepts the
|
||||
runner's manifest; whole (runner), as §330.
|
||||
- §471 **A second reader release carries §469's word.** The reader release of §340 and §409 is merged; a second
|
||||
release of mesh-sdk's manifest reader, reading `max-mib` on an old `state` section, is merged ahead of G's check in
|
||||
the same way, so the running checker's validator reads the runner's manifest (§340). Why: readers first (ADR 0667
|
||||
§4); the running checker makes G's own check (ADR 0667 §2). How it is checked: unit rows in the release for the
|
||||
word; G's check reads the runner's manifest.
|
||||
- §472 **The toolchain part's digest.** Each build module states, in its `toolchains` key of each language beside
|
||||
the version and the recipe, `digest`: the `sha256:` digest of the language's toolchain program as it runs it, the
|
||||
program of the module that provides that language's toolchain (for Go, the module providing `go-toolchain`), never
|
||||
the build module's own program. A build's ToolchainUsed carries its node's (§466). The builder's `toolchain-agreed`
|
||||
carries `digests`, each digest the nodes reporting the agreed version report, with those nodes, in place of §376's
|
||||
one digest; it is said only when the agreed version changes (ADR 0584 §1), and kind 3 is stale (§441) when the
|
||||
agreed version differs from the one the release recorded, so a digest that differs between nodes of one version
|
||||
rebuilds nothing and is only recorded. This amends §376 and §441 for kind 3. Why: ADR 0584 agrees a version, not a
|
||||
digest, and a rebuild of every module of a language on a difference no record judges would spend the build
|
||||
capacity for nothing (develop question BL8). How it is checked: unit (build-step contract), `digest` read; whole
|
||||
(builder), a change of the agreed version says `toolchain-agreed` with the digests and a differing digest at one
|
||||
version says nothing.
|
||||
- §473 **The builder takes a candidate's heads from its revision view.** In place of the gate's `source` history,
|
||||
which it reads today to find the trunk heads a candidate's base revision names, the builder takes each build's
|
||||
commits from the catalog half of the revision view the build is for (§348), by `mesh-catalog`'s `revision`; a G
|
||||
pipeline builds a commit as it is, so the builder asks no merge onto a base and sets no `base` in a fetch. Its watch
|
||||
of the gate's `source` and the `reads` of it in its manifest go in the same change (§431). Why: ADR 0596 §2; one
|
||||
source of a revision's commits (develop questions BL15 and BL9). How it is checked: the builder's account holds no
|
||||
read of the gate's state; whole (builder), a run on request builds the commits its revision view names.
|
||||
- §474 **A `*` entry before an event no contract defines keeps its meaning on main.** §386's form, one durable
|
||||
consumer on each declaring module's stream, is taken only for `*.<event>` where `<event>` is defined by a seat's
|
||||
definition or a contract in mesh-sdk; any other `*` entry the validator accepts on main, such as `model-usage`'s
|
||||
`*.usage.*`, keeps its meaning of ADR 0363 §5, the shared stream EVENTS and never a module's own stream, and is
|
||||
accepted as on main; `*.>` and `*` in part of an emitter's name stay refused. G's change does not rewrite
|
||||
`model-usage`'s `consumes`, so it hears what it hears today. This amends §386's "it refuses `*` before any other
|
||||
event". Why: ADR 0363 §5 stays in force for what §386 does not take over, and a refusal would end what a module
|
||||
hears with no answer of the operator's (develop question IX21). How it is checked: unit (manifest validator),
|
||||
`*.usage.*` accepted as the shared form; the grants part's table test makes no per-module consumer for it.
|
||||
- §475 **The forge module learns a head's fingerprint from every `step-ended`.** The state `failed-steps` of §39 gains
|
||||
a second key form, `seen.<commit>.<module>`, holding the build-input fingerprint the runs named for that commit
|
||||
and module, written from every `step-ended` of any outcome whose commit is then a watched branch's head or the
|
||||
head an open pull request names, and deleted by §135's rule; and each failure entry's commits take every commit a
|
||||
later `step-ended` names at its module and fingerprint. `merge-pull` reads a head's fingerprint from its `seen`
|
||||
key, so a head whose runs all ended before another commit of the same content failed is refused, as §39 says. This
|
||||
completes §39 and §135. Why: §39 decides the refusal and that it is judged from the module's own state, and
|
||||
`step-ended` names one commit and fingerprint at a time (develop questions GIT7 and GIT8). How it is checked:
|
||||
whole (forge module), a head that passed, then another commit at its fingerprint failed a `required` step, is
|
||||
refused; its `seen` key goes when the pull request closes.
|
||||
- §476 **`take-in.taken`'s body and its type.** The indexer's own `take-in.taken` carries, beside what it carries on
|
||||
main, `branch` (the watched branch), `source` (the source revision taken in) and `entries`, one `{module, commit,
|
||||
fingerprint}` per module of that revision. Its body is defined in the seat `mesh-catalog`'s definition, in its
|
||||
section `bodies` (§439, §454), so the generated contract carries the type the indexer writes and the runner reads,
|
||||
and neither imports the other (§333). Why: a body said on a module's own stream and read by others is a `bodies`
|
||||
entry (§439), never a client's hand-written type (develop question Q-RN4). How it is checked: unit (seat generator),
|
||||
the type generated; whole (runner), a pipeline started from a fixture `take-in.taken`.
|
||||
- §477 **A sent store's cap.** The bus module plans each `<module>_sent-objects` with a cap of 256 MiB, and a
|
||||
foundation part's old `objects` section `sent-objects` names `max-mib` 256; a send refused at the cap fails its
|
||||
reply or event loudly, naming the store, as §181 has a full store refuse. This completes §59's "the objects
|
||||
template's", which has no default. Why: an object sent is transport kept 7 days (§59), most modules send none, and
|
||||
the largest value the design moves whole is §345's hundred times the message limit, which 256 MiB holds twice
|
||||
(develop question Q-RN5). How it is checked: unit (bus module's plan), every planned sent store has its cap; whole
|
||||
(mesh-sdk), a send past a fixture's cap fails naming the store.
|
||||
- §478 **`reserved` takes a package's name.** The seat `mesh-builds`' verb `reserved` takes either `module` or `name`
|
||||
(a package's or an image's name in its ecosystem: the Go module path, the npm name, the image name), with
|
||||
`version`; given `name`, the builder finds the module from the catalog half's entries, whose packages carry each
|
||||
name (§348, §412), and answers as for `module`, the artifacts with their digests. A registry holder asks it with the
|
||||
name, version and digest its publish carries, so it reads no catalog and its publish gains no field; a name no entry
|
||||
carries is answered `error`, naming it, and the holder refuses the publish (§381). Its callers stay §381's. This
|
||||
completes §381. Why: the builder already reads each package's name from the catalog half (§348), so the mapping is
|
||||
its own fact (ADR 0596 §2) (develop questions GIT12 and REG1). How it is checked: unit (`mesh-builds` contract),
|
||||
`reserved` with `name` read; whole (builder, registry holder), a Go publish named by its module path is checked
|
||||
against the module's reservation, and an unknown name refused.
|
||||
- §479 **A branch's catalog view is named with its branch.** In mesh-sdk's `go/views` reader and process reader, a
|
||||
first view of a per-branch state is named `<owner>.<state>.<branch>`, the branch escaped as a key's name is (§73),
|
||||
so `mesh-catalog.catalog-revisions.<branch>` names one view per watched branch, a part reads several in one reader,
|
||||
and `<module>_first_views` lists one row per branch (§358, §365). A view of a state that is not per branch keeps
|
||||
its name `<owner>.<state>`. Why: the condition keeper reads every watched branch's newest revision (§365), and the
|
||||
state's keys are `<branch>.<revision>` already (§343) (develop question CT10). How it is checked: unit (`go/views`),
|
||||
two branches' views of one state in one reader, each its own row; whole (keeper), a module watched only on a
|
||||
second branch is a source.
|
||||
@@ -50,7 +50,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
|
||||
- §59 **An object sent is readable by the modules it is for.** A reply's or an event's object is written to the sender's
|
||||
**sent store**, `<module>_sent-objects`: the bus module plans it, with no manifest field, for every module of the new
|
||||
form that serves a verb or emits an event, and a foundation part declares it as an old `objects` section
|
||||
`sent-objects` (ADR 0619 §2). Its cap is the objects template's (ADR 0595 §3), and it keeps an object 7 days, after
|
||||
`sent-objects` (ADR 0619 §2). Its cap is the objects template's (ADR 0595 §3), 256 MiB (§477), and it keeps an object 7 days, after
|
||||
which the bus expires it. That age is transport, not kept data: an object sent exists only to carry one reply or one
|
||||
event, read within its call's bound or its consumer's lag, so its expiry is not a removal of kept data that ADR 0595
|
||||
§4 holds to a person's word (the design's choice; 7 days is a guess at the longest a consumer lags, read from the
|
||||
@@ -161,7 +161,8 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
|
||||
§4). A step waiting on a person is said as waiting on that person (ADR 0283), never as a stall; a group waiting for
|
||||
its members, and a merge behind a pending revision, are governed by their own bounds (ADR 0666 §24). At its start the
|
||||
watchman seeds its open waits from the runner's `stands`, as it seeds `take-in-waits` from `indexer_pending`.
|
||||
- §76 **The runner's own health.** Its manifest declares its health check, run outside its process (ADR 0240): the runner
|
||||
- §76 **The runner's own health.** Its manifest declares its health check, run outside its process (ADR 0240; its tool
|
||||
`runner_health`, §468): the runner
|
||||
answers `show`, and its durable consumers of `step-ended`, `take-in.taken`, `package-published`, `toolchain-agreed`
|
||||
and `decided` are
|
||||
each less than five minutes behind; a failed check names which.
|
||||
@@ -213,7 +214,7 @@ each tool answers its whole-module test's case, every store's read answers its f
|
||||
### The runner's kept data, and the build capacity
|
||||
|
||||
§85 Each kept form names its section or template, its retention and its cap; a state template fixes its own size (ADR 0595
|
||||
§3), up to 64 MiB. The numbers are estimates, to be read from the fill tools once G runs: an estimated 20 merges a day
|
||||
§3), up to 64 MiB, and an old `state` section names its cap in `max-mib` (§469); the step log is an old `logs` section (§470). The numbers are estimates, to be read from the fill tools once G runs: an estimated 20 merges a day
|
||||
(as *The delivery record*), each starting a pipeline for about 3 modules of its repository whose fingerprint it changes,
|
||||
and an estimated 2 mesh-sdk publishes a day, each rebuilding about 120 artifacts and starting about 120 pipelines: about
|
||||
300 pipelines a day, of about 6 steps each.
|
||||
|
||||
@@ -117,7 +117,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
|
||||
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 catalog graph's entry of the module on its placement's branch, 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
|
||||
fallback in the one function (ADR 0660 §3), whose input is §459's. 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.
|
||||
- §200 **A part with no view says it waits.** It names the revision it has no view for, acts on nothing new, and keeps
|
||||
@@ -181,7 +181,7 @@ One file of milestone G's part of [design 47](../47-delivery-from-commit-to-deli
|
||||
build module's step key named by the ask's id (ADR 0525 §6). It is an accepted ask of the seat, not a request verb, because it is a
|
||||
long job pulled where there is capacity, never a call to a named node. Only the checker's account may publish `run`,
|
||||
and from G's delivery the runner's and the indexer's (its validation before take-in), each under its own name.
|
||||
Every step key of a `run` ask starts with the asker's name (`checker.<ask id>`), so the checker's read grant is fixed
|
||||
Every step key of a `run` ask starts with the asker's name (`checker.<ask id>`; its whole form is §467's), so the checker's read grant is fixed
|
||||
in advance to its own prefix and never follows ask ids one by one (ADR 0363 §2); no other part can have a program run
|
||||
or read its verdict. From milestone G the seat definition of `node-build-go` in `mesh-delivery-contracts` names it; B0
|
||||
brings the ask with its types in mesh-sdk's `go/delivery` and the grants check asks have today (*The bootstrap
|
||||
|
||||
@@ -64,7 +64,7 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
- §326 **A build seat keeps its `steps` answer.** The build module keeps each artifact's detected steps in its state
|
||||
`detected-steps` (§414), from the template `state`, one key per artifact holding the answer for that artifact's newest build-input
|
||||
fingerprint, replaced when a newer fingerprint is detected and by `steps` with `again`; a key whose artifact no
|
||||
longer exists is dropped by `steps` with `drop`, on a person's word, written in the hand-act log. With one key per
|
||||
longer exists is dropped by `steps` with `drop`, on a person's word, written in the hand-act log (its input §463's). With one key per
|
||||
artifact (about 120) the state needs no aging and no read time. Why: ADR 0666 §25 asks a tool for "the steps
|
||||
detected for an artifact and detect again", which a reply computed anew each time would not need; a build module is
|
||||
no foundation part, so the template form (ADR 0666 §4). How it is checked: whole (Go build module), `steps` answers
|
||||
@@ -208,15 +208,15 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
- §345 **A large value reaches the tool runner in chunks.** A bundle's put of a value over the bus's per-message limit is
|
||||
sent to the tool runner as a put session on the bundle's call subject, named by the call's id, in chunks under that
|
||||
limit, in order, each answered by the tool runner before the next is sent, and written as one object through the
|
||||
object store's own chunking; a put not sealed within the call's bound is dropped by the tool runner and its call
|
||||
object store's own chunking, its wire form §457's; a put not sealed within the call's bound is dropped by the tool runner and its call
|
||||
fails, naming the object. No value is split over objects. Only modules that import the object store package are
|
||||
rebuilt for it. Why: one object per value (ADR 0666 §16), through the tool runner (ADR 0595 §9). How it is checked:
|
||||
whole (mesh-sdk), a value of a hundred times the limit is read back whole, and a put stopped half way fails naming
|
||||
the object and leaves none.
|
||||
- §346 **One object store package.** The assigner's and the indexer's object store code is mesh-sdk's small object store
|
||||
package, with no copy in either. Why: ADR 0595 §9. How it is checked: a search finds no second copy.
|
||||
- §347 **Reading sent objects is a bus state call.** mesh-sdk lists the call that reads a sent object under its existing
|
||||
bus state capability. Why: ADR 0595 §9 puts the calls in that package. How it is checked: the package's table test.
|
||||
- §347 **Reading sent objects is a bus state call.** mesh-sdk's `buscalls` names the call that reads a sent object, and
|
||||
the tool runner lists it under its existing bus state capability (§462, which amends this line). Why: ADR 0595 §9 puts the calls in that package. How it is checked: the package's table test.
|
||||
- §348 **The builder reads the catalog through its seat.** The builder reads the registrations' watched branches through
|
||||
`mesh-catalog`'s `registrations` and `registration-changed`, the released versions it numbers from through
|
||||
`versions` and `version-released`, keeping no list of versions of its own, and a build seat's holder from the seat list; the
|
||||
@@ -280,7 +280,7 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
resolves to, wherever that requirement carries values the consumer contributes. How it is checked: unit
|
||||
(assignment graph), each step of the order and a hold.
|
||||
- §358 **The catalog's shared view takes a branch.** The client's view of the catalog half is per watched branch, named by
|
||||
its caller. How it is checked: unit (client), two branches give two views.
|
||||
its caller (§479). How it is checked: unit (client), two branches give two views.
|
||||
- §359 **`difference` names its revisions.** `difference` with none of `from`, `to` and `group` is refused, naming the
|
||||
missing argument. How it is checked: a unit row.
|
||||
- §360 **An approved ask binds the placement.** What an approved ask binds to includes the placement's watched branch and
|
||||
@@ -363,7 +363,8 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
builder started before the fill reserves nothing until `versions-filled`.
|
||||
- §370 **The version reaches every artifact's build.** The build seat's ask carries the version, and the build module
|
||||
passes it to the artifact's build as the build argument `MESH_VERSION`: a Go package is tagged `vMAJOR.MINOR.PATCH`,
|
||||
an npm package's version is it, an image carries it as its tag and label, and a program reads it as its own version.
|
||||
an npm package's version is it, an image carries it as its tag and label, and a program reads it as its own version,
|
||||
each in §458's form.
|
||||
A Go package's version is its tag: this departs from ADR 0573 §2, which has a Go package's version be its trunk
|
||||
commit, by the operator's choice of 2026-11-10, and a later research brings that record in line. The git tag
|
||||
(`go/vMAJOR.MINOR.PATCH`, design 51) is written by the builder only on the catalog's `version-released`, through the
|
||||
@@ -395,7 +396,7 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
- §373 **A group's run on request publishes no version.** A run on request of a group builds each member that
|
||||
depends on a package member against that member's build by its digest. The builder's build ask for such a member
|
||||
carries each package member's build digest, which the builder takes from its own `build.ended` of that member's
|
||||
build, its own fact (ADR 0596 §2); the build module fetches that build from the store by the digest, checks the
|
||||
build, its own fact (ADR 0596 §2), in the field of §465; the build module fetches that build from the store by the digest, checks the
|
||||
fetched bytes against it, and lays it in the build's workspace as the module that package names (a Go workspace's
|
||||
replacement, a TypeScript local package), so nothing is fetched by a version, and no version is reserved, numbered
|
||||
or published for the run. A dependent whose package member's build is not done waits, said as the builder's
|
||||
@@ -412,7 +413,8 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
makes the dependent stale or only orders it (§378), the manifest word it came from, the part it points to, and what
|
||||
the edge depended on:
|
||||
- kind 1 (an imported package) and kind 3 (the build toolchain): the dependency's version and the digest of the part,
|
||||
as the build used them. The build module names each dependency it resolved, version and digest, in its step key,
|
||||
as the build used them. The build module names each dependency it resolved, version and digest, in its step key
|
||||
(§466's fields),
|
||||
and the builder carries them in each artifact's `package-published`, so the indexer reads no other part's state
|
||||
(ADR 0596). Kind 3 points at the toolchain part the agreed toolchain names (ADR 0584 §1), never at the build
|
||||
module's own program.
|
||||
@@ -436,7 +438,7 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
- §375 **One query finds every edge behind, by the part's digest.** The seat `mesh-catalog`'s verb `outdated`, with
|
||||
the indexer's tool `indexer_outdated`, answers every entry that is behind: for kind 1, the recorded digest differs
|
||||
from the part's digest in the dependency's newest released version (for a build of another branch, its newest build
|
||||
on that branch); for kind 3, it differs from the toolchain part of the builder's newest `toolchain-agreed`; for kinds
|
||||
on that branch); for kind 3, it differs from the toolchain part of the builder's newest `toolchain-agreed` (its version, §472); for kinds
|
||||
2 and 4, it differs from the dependency's newest `version-delivered`; for kind 5, the newest version of the acting
|
||||
part has not acted for the dependent's current build; for kind 6, the delivered version no longer serves the verb or
|
||||
word. A dependency's newer version that left the part's digest as it was makes nothing behind, so nothing is done
|
||||
@@ -451,8 +453,7 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
part's event (the design's choice, round 2 of the review by architectural domain, 2026-11-10). How it is checked: test 105.
|
||||
- §376 **A stale edge rebuilds on its event; a delivery is waited for mesh-wide.** The rebuilds start on two events
|
||||
the runner consumes: kind 1 on `package-published` (§53), and kind 3 on `toolchain-agreed`, which the builder says
|
||||
on its seat `mesh-builds` when the agreed toolchain of a language changes (ADR 0584 §1), naming the language, the
|
||||
version and the toolchain part's digest; for each, the runner asks `outdated` for that dependency and starts a
|
||||
on its seat `mesh-builds` when the agreed toolchain of a language changes (ADR 0584 §1), naming the language, the version and the toolchain part's digests (§472); for each, the runner asks `outdated` for that dependency and starts a
|
||||
pipeline for each dependent behind. `version-released` starts no rebuild. No other edge rebuilds or delivers anything
|
||||
again. A dependent's new version that a change orders after its dependency's new version by kind 2, 4 or 6 is wanted
|
||||
only once that dependency's version is delivered to every machine that places it and is present. The assigner judges
|
||||
@@ -502,7 +503,7 @@ record it follows from, and replaces the builder's own choice where one was made
|
||||
and 6), and whether it is behind now (§375). Its callers are any person, an agent session and the healers. Why: the operator, 2026-11-10 about 22:30 to 23:00 CET. How it is checked: whole (indexer), a fixture module's
|
||||
edges are answered from both ends with their newest release's record.
|
||||
- §381 **A registry holder checks a publish against the reservation.** From G's delivery the holder of a registry
|
||||
seat asks the seat `mesh-builds`' verb `reserved` (§369), in place of `builder_versions`, whether the module, the
|
||||
seat asks the seat `mesh-builds`' verb `reserved` (§369, by name, §478), in place of `builder_versions`, whether the module, the
|
||||
version and the artifact's digest are reserved, and refuses loudly otherwise (ADR 0605 §4); a version the catalog
|
||||
already holds released for that digest is answered as held and stores nothing. Why: ADR 0605 §4 has the holder
|
||||
refuse a version the builder did not give, and the builder's list goes (§372); the design's choice, round 2 of the review by architectural domain, 2026-11-10.
|
||||
|
||||
@@ -101,7 +101,7 @@ record says so in its Why. Round 3 of the review by architectural domain (2026-1
|
||||
`*.<event>` takes the event `<event>` from every module whose manifest declares it, and is the one generic form for
|
||||
hearing an event that many modules say; the keeper's `*.finding-written`, `*.finding-cleared` and
|
||||
`*.findings-stated` are the first. The manifest validator takes `*` only as the whole emitter, and only before an
|
||||
event that a seat's definition or a contract in mesh-sdk defines, with its fields (for the finding events, the seat `mesh-conditions`' definition, §439); it refuses `*` before any other event, `*.>`, and `*` in part of an emitter's name. The grants part,
|
||||
event that a seat's definition or a contract in mesh-sdk defines, with its fields (for the finding events, the seat `mesh-conditions`' definition, §439); it refuses `*.>` and `*` in part of an emitter's name, and a `*` entry before any other event keeps its meaning on main (§474). The grants part,
|
||||
from the catalog graph as it derives every grant (§59, §442), makes on each declaring module's stream one durable consumer
|
||||
for the consumer, named `<machine>_<module>` as ADR 0363 §5 names one, with its grants to read and acknowledge it and
|
||||
its membership's word to bind it; it drops that consumer when the module no longer declares the event, and makes one
|
||||
|
||||
@@ -43,12 +43,12 @@ line says so.*
|
||||
`invokers`, `persons` and `sessions`; an `act` (a new act that changes what the mesh does: registers, sets a policy,
|
||||
watches or unwatches a branch, recovers, restores) takes `operator` and `sessions`; a `warrant` (a verb that runs on
|
||||
the operator's warrant) takes `operator` and carries the approval mark; `accept` is the operator's alone (§394). A
|
||||
verb on main that names no class is a `read`, so every verb open today stays open; a verb G adds must name its
|
||||
`class`, and the definition reader refuses one that does not. A verb that names `callers` keeps them, so no verb is
|
||||
verb that names no class, on main or added by G, is a `read`, so every verb open today stays open, and nothing
|
||||
refuses a verb for naming no class (§456). A verb that names `callers` keeps them, so no verb is
|
||||
closed by §68 for lack of a list; §68, §127 and §306 point here. Why: ADR 0666 §20 makes the definition the one source
|
||||
of caller limits; the operator asked on 2026-11-11 why caller questions kept coming, and answered them as one rule
|
||||
(Q1, S3, C3, D2's reads, Q18). How it is checked: unit (seat-definition reader), a table test with one row per class,
|
||||
a row for a verb with `callers` of its own, and a row refusing a verb G adds without `class`; unit (manifest
|
||||
a row for a verb with `callers` of its own, and a row where a verb G adds without `class` takes `read`'s (§456); unit (manifest
|
||||
validator), the default each verb took is said.
|
||||
- §392 **A caller entry names its kind of name.** In `callers`, a holder role is written `seat:<seat>` and a module
|
||||
`module:<module>`, beside `operator`, `healers`, `persons`, `sessions`, `invokers` and `holder:<seat>@same-node`
|
||||
@@ -111,7 +111,7 @@ line says so.*
|
||||
- §404 **The node-engine's events' bodies.** `capabilities-changed` carries the node record's stated capabilities whole
|
||||
and `at`; `composed` the module, the fingerprint and the composition's digest; `running` with `stopped` carries
|
||||
`stopped: true` and no fingerprint (§365), and mesh-sdk's `SeatsToPassOn` counts such a module as not running on that
|
||||
node. Why: the design's choice (Q17). How it is checked: the seat's fixtures; unit (`SeatsToPassOn`), a row where a
|
||||
node, its input being §459's. Why: the design's choice (Q17). How it is checked: the seat's fixtures; unit (`SeatsToPassOn`), a row where a
|
||||
`stopped` holder passes no seat.
|
||||
|
||||
### Kept data on the bus, restore points and the reader release
|
||||
@@ -145,9 +145,9 @@ line says so.*
|
||||
is checked: unit (`go/stateobjects`), an old section and a template store each take a large value; whole (tool
|
||||
runner), a large reply read back.
|
||||
- §408 **The ledger's calls.** The ledger's fill and removal calls are in mesh-sdk's `buscalls`, under the existing
|
||||
`ledger` calls (§155, §159, §181); no capability word `ledger-fill` is added. Why: the design's choice (S15, Q-T6).
|
||||
`ledger` calls (§155, §159, §181); no capability word `ledger-fill` is added; their names and capability are §462's. Why: the design's choice (S15, Q-T6).
|
||||
How it is checked: the code review.
|
||||
- §409 **The reader release reads every new form G writes.** The reader release of §340 reads every new definition
|
||||
- §409 **The reader release reads every new form G writes** (and §471's second release, one more word). The reader release of §340 reads every new definition
|
||||
form and manifest word G writes: `callers`, `class`, `keep`, `subject`, `acts`, the step `pipeline`, `on`
|
||||
`kind:image`, `version`, the `*` emitter, an observer's finding stream, and an artifact's `needs`; `check` stays
|
||||
beside `pipeline` until the checker is removed (§97, §203). Why: readers first (ADR 0667 §4; S2, S18). How it is
|
||||
@@ -202,7 +202,7 @@ line says so.*
|
||||
check, made by the running checker (§340), counts by the same rule. Why: the test budget per module (S16, D6). How it
|
||||
is checked: `pipeline-ended`'s counts; unit (runner), a module over budget is named `over-budget`.
|
||||
- §420 **A run on request's key, and the step-run package.** A run on request is keyed by the run's id under its named
|
||||
branch (§54, §64, §85); the step-run code is the delivery SDK's package `sdk/steprun`, and the runner's
|
||||
branch (§54, §64, §85); the step-run code is the delivery SDK's package `sdk/steprun` (§464 says what it holds), and the runner's
|
||||
client sits beside the other seats' clients; the runner's kept data layouts are the seat's `states` (§27, §306). Why:
|
||||
the design's choice (D16, D8, D10). How it is checked: whole (runner), two runs of one commit are two pipelines.
|
||||
|
||||
@@ -227,7 +227,8 @@ line says so.*
|
||||
`<module>_first_views` (§205); each tools bundle's composed environment carries its module's fingerprint. Why: the
|
||||
design's choice (S12, Q-T7). How it is checked: whole (tool runner), a bundle reads its fingerprint.
|
||||
- §425 **A kept call asks again what its asker names.** An asker passes the kept-call form the ask's key and the event
|
||||
that replaces it, and the form asks again only while that key is open and no replacing event was heard (§351). Why:
|
||||
that replaces it, and the form asks again only while that key is open and no replacing event was heard (§351);
|
||||
§460 has the asker pass `open`, the replacing event being optional. Why:
|
||||
the design's choice (S11). How it is checked: unit (kept-call form).
|
||||
- §426 **The tool runner keeps no waits list.** §74's session waits use `mesh_wait` on any event (ADR 0670), and
|
||||
`gitea.forge.status` goes (§133). Why: ADR 0670 (Q-T2). How it is checked: the tool runner's manifest has no waits.
|
||||
|
||||
@@ -76,7 +76,7 @@ file on 2026-11-10, and is cited as "design 47 G §n". A sentence that holds a d
|
||||
stayed in the main file, and G builds what it says from G's delivery. A section named in italics is in this part, or,
|
||||
when it is not here, in the main file.
|
||||
|
||||
The part is nine files, each read whole, its design lines numbered across them:
|
||||
The part is ten files, each read whole, its design lines numbered across them:
|
||||
|
||||
- [G-1-pipelines-registration-and-steps](G-1-pipelines-registration-and-steps.md): pipelines per module: registration, watched branches, steps and policy, what holds a delivery, approval, groups, dependencies, a publish.
|
||||
- [G-2-pipelines-sizes-checks-and-tools](G-2-pipelines-sizes-checks-and-tools.md): pipelines per module: any size, the pipeline makes the check, who may say what, health, recovery, tools, kept data, how G itself is delivered, the choices under ADR 0666 and ADR 0667.
|
||||
@@ -86,4 +86,5 @@ The part is nine files, each read whole, its design lines numbered across them:
|
||||
- [G-6-verbs-and-retires](G-6-verbs-and-retires.md): the verbs G adds and what retires.
|
||||
- [G-7-answers](G-7-answers.md): the answers to the builders', the reviewers' and the operator's questions (§322 to §382).
|
||||
- [G-8-findings-heard-as-events](G-8-findings-heard-as-events.md): the operator's answers of 2026-11-11, findings heard as events (§383 to §390).
|
||||
- [G-9-prepare-answers](G-9-prepare-answers.md): the answers to the questions of G's final prepare (§391 on).
|
||||
- [G-9-prepare-answers](G-9-prepare-answers.md): the answers to the questions of G's final prepare and develop's first questions (§391 to §455).
|
||||
- [G-10-develop-answers](G-10-develop-answers.md): the answers to develop's second batch of questions, the operator's and those of internal form only (§456 on).
|
||||
|
||||
Reference in New Issue
Block a user