Merge pull request 'Design 47 G: §717 (the views are named by their seats) and the lead's answers A-294 to A-297' (#588) from design/47-G-lead-answers-16 into main

2026-11-12 17:59:25 +00:00
parent 7247b92fd6 b03f5193b8
commit 023a355cdb
4 changed files with 110 additions and 4 deletions
@@ -609,6 +609,11 @@ controller (the planner, the rollout) until release 6 of ADR 0429; from each rel
  registrations, asks each pipeline step of the seat that serves it, says each step's start and end and each pipeline's
  end as its events, keeps each pipeline's state and step log on the bus, and serves the run on request (ADR 0666 §7,
  §11). An acting part of the step `pipeline` (design 47). Of this domain: its contract is in `mesh-delivery-contracts`.
+- **mesh-delivery-view** — the seat, held once for the mesh, of the status view's role (ADR 0540 §1): it serves no
+  verb and declares one state, `answers`, the person's answers in the web view to the asks of `mesh-wants` that need
+  no proof of who answered, offered as a view, so the teller follows it by the seat (design 47 G §717). The four
+  events of ADR 0540 §1 are its holder's own. Of this domain: its contract is in `mesh-delivery-contracts`.
+  *Not:* ~~status seat~~ (hq)
 - **mesh-builds** — the seat, held once for the mesh, whose holder numbers a package's version when it is published and
  says the publication as its event `package-published`, on which every artifact built against the package is rebuilt
  and its pipeline started (ADR 0666 §15; design 51). Of this domain: its contract is in `mesh-delivery-contracts`.
@@ -7,19 +7,24 @@ updated: 2026-11-12
 decisions:
  - "ADR 0666"
  - "ADR 0656"
+  - "ADR 0596"
+  - "ADR 0567"
+  - "ADR 0565"
+  - "ADR 0540"
  - "ADR 0633"
  - "ADR 0579"
  - "ADR 0571"
  - "ADR 0564"
  - "ADR 0539"
  - "ADR 0330"
+  - "ADR 0429"
  - "ADR 0259"
  - "ADR 0126"
  - "ADR 0112"
  - "ADR 0084"
 ---

-# 47, milestone G: the provider a requirement points to, the ask of a held revert, the edge an acting rule gives, and the take-in of every watched branch
+# 47, milestone G: the provider a requirement points to, the ask of a held revert, the edge an acting rule gives, the take-in of every watched branch, and the seats of the status view's and the assigner's views

 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".
@@ -33,7 +38,9 @@ give an edge of kind 5 (§47), between which entries, and what a catalog entry's
 the indexer's develop questions on rows IX5 to IX7 (2026-11-12), which A-213 sent to design lines: the validation's
 run before take-in, what holds a pending revision while it runs, and how a watched branch other than the trunk gets
 its merges, its pending revision and its groups. §716 answers the lead's question of 2026-11-12 (A-279) that no
-principle settles: where the gate keeps a group's members and each member's base before the take-in. Each is the
+principle settles: where the gate keeps a group's members and each member's base before the take-in. §717 answers
+developer J27's question of 2026-11-12 on A-210: which seat the status view's answers and the assigner's asks are
+views of, and how a follower starts before their holder is known. Each is the
 design's choice within the record it cites, tested against [the principles](../../../00-META/principles.md).*

 ## The provider a requirement points to
@@ -294,3 +301,79 @@ design's choice within the record it cites, tested against [the principles](../.
  `main` member opens a record with `base` `main`, and the `beta` member stays in `groups`. A `pull-merged` missed
  while the gate was down is set from `pull` at its start. Whole (forge bridge): the group's end is published once
  both the member's merged message and its `pull-merged` have come, in either order.
+
+## The seats of the status view's and the assigner's views
+
+- §717 **The status view's answers are a view of the seat `mesh-delivery-view`, the assigner's asks and wants are
+  views of the seat `mesh-wants`, and a follower finds each by its seat and starts without it.** (ADR 0540 §1, §6;
+  ADR 0429 §3; ADR 0567 §5, §6; ADR 0571 §6; ADR 0565; ADR 0539 §16; ADR 0596; §7, §200, §428, §532, §616, §699,
+  §710, §614, A-126, A-131, A-175, A-178, A-210, A-295) This answers developer J27's question of 2026-11-12, met building A-210
+  and A-296 (G-22): A-210 has a part find another module as the holder of the seat it holds, but the status view
+  claims no seat while the teller follows its `answers` by its module name, and the assigner holds two seats while
+  the teller follows its `asks` by its module name. It completes A-175 and A-178 for both views.
+  - **The seat `mesh-delivery-view`.** ADR 0540 §1 names the seat the status view holds, `mesh-delivery-view`; G
+    defines it. Its definition is in the Delivery domain's contracts module, `seats/mesh-delivery-view/` beside the
+    domain's other seats, with a states fixture as theirs have: `scope` mesh, `grain` whole, `domain` Delivery,
+    `decision` ADR 0540. It serves no verb and declares no seat event and no `family`: the status view's tools stay
+    its own (one seat, many tools), each caller reaching them at the holder A-210 finds, and its events `delivered`,
+    `moving`, `settled` and `stuck` stay the holder's own on the subjects ADR 0540 §1 names, so every `consumes` of
+    them keeps its entry and a part that builds their subject in code builds it from the holder A-210 finds. It
+    declares one state, `answers` (template state, history 5, `view: true` by §699), whose one key form is
+    `<ask key>.view`, `<ask key>` a key of the seat `mesh-wants`' state `asks` of a kind that needs no proof of who
+    answered, and whose value is the status view's answer: `v`, `asking` (the asking it answers), `option`, `words`.
+    Only the holder writes it, the person's answer in the web view, and only the holder deletes a key: once the ask's
+    key has left `asks`, heard on the `asks` view it follows, so no answer outlives its ask. The status view's manifest `claims` the seat with scope mesh and an empty `serves`. Its
+    first-view tool of `answers` is named for the state, `answers` (mesh-sdk's `views.ReadTool`, the teller among
+    its callers, A-131's form), in place of A-178's `view_read_answers`, which goes.
+  - **The seat `mesh-wants` owns `asks` and `wants`.** Every kind the assigner keeps in its state `asks` (hold,
+    restore, backup, record, outside, revert and a placement proposal's `assignments`) is an ask whether what a node
+    runs moves, and ADR 0567 §6 names the states of `mesh-module-assigner` without `asks`, so `asks` is a state of
+    `mesh-wants`: its definition gains `asks` (template state, history 5, `view: true`), its key forms the eight kinds'
+    keys as the assigner's `asks` package writes them, its value the ask as the assigner composes it. Its `wants`,
+    which the definition already declares, gains `view: true`. The holder's first-view tools are named for the
+    states: `wants`, as it exists, and `asks`, new, in place of `assigner_read_asks`, which goes.
+  - **The followers name the seat.** The teller's manifest `consumes` `seat:mesh-wants.views.asks` and
+    `seat:mesh-delivery-view.views.answers` in place of `mesh-delivery-assigner.views.asks` and
+    `mesh-delivery-view.views.answers`, and its `invokes` loses `mesh-delivery-assigner.assigner_read_asks` and
+    `mesh-delivery-view.view_read_answers`, the seat-form `consumes` covering each first view (A-131). The status
+    view's manifest `consumes` `seat:mesh-wants.views.asks`, `seat:mesh-wants.views.wants` and
+    `seat:mesh-module-assigner.views.assignments` in place of the three `mesh-delivery-assigner.views` entries, and
+    its `invokes` loses `assigner_read_asks`, `assigner_read_wants` and `assigner_read_assignments`. Neither part's
+    code names the assigner or the status view (§7, §428).
+  - **What the seat form puts on the bus.** A seat's view is said where its holder says it, on the holder's own
+    subject `mesh.mod.<holder>.event.views.<state>`, and the grants part resolves a `consumes` entry
+    `seat:<seat>.views.<state>` to that subject for the seat's holder on record, granting nothing while the seat has
+    none (§616). The subject is module-scoped, so a follower must know the holder, and follows it as it moves.
+  - **A follower finds and re-finds the holder from the seat-holders view.** mesh-sdk's `views.ProcessReader` gains
+    `FollowSeat`, given a seat and a state, and the holder function A-295 gives a part, which answers from what the
+    part last heard of the seat `mesh-module-assigner`'s view `seat-holders`. The part follows that view as the tool
+    runner does (§616): the module that claims `mesh-module-assigner` is read from the catalog half the part follows
+    (§614, the trunk's entry whose manifest `claims` the seat), so no code names the assigner's module; the view is
+    named `seat:mesh-module-assigner.views.seat-holders` in the part's `consumes`, its first view asked of the
+    claimant's tool `seat-holders`, and a catalog revision naming another claimant drops it and follows the new one
+    (§532). `FollowSeat` returns at once a picture that reads as empty, its follower not ready, and never fails for
+    want of a holder. At each change of the seat-holders view it reads the seat's holder: on a first holder it follows
+    as `Follow` does after `Start` (§532), the first view asked of the holder's tool named for the state, then its
+    views family; on another holder it drops the view of the old one and follows the new one, the picture handing on
+    the new holder's state whole; with no holder it keeps the picture it has and follows nothing. Nothing is asked
+    again on a timer. While no holder is followed the follower's status names the seat in place of its owner, waiting
+    since its start or since its holder left, and past five minutes the reader writes §200's `view-waits` naming the
+    seat and the state, cleared when a holder's first view arrives. The teller's two follows and the status view's
+    three go through `FollowSeat`, each apart, so the teller raises the assigner's asks whether or not the status
+    view's answers are read (issue 1906, as today); the teller gains the catalog half's reader of §614 for this. The
+    builder's and the checker's own loop for the assignments, buildrun's `AssignerHolder`, which asks every 5 seconds,
+    goes: both follow `assignments` through `FollowSeat`. `seatlist.HolderOf`'s call stays for a caller that asks
+    once, as A-210 has it.
+
+  Why: ADR 0540 §1 already names the seat the status view holds, and §616 and §699 give a view named by its seat;
+  `asks` goes where the kinds it holds belong, its proposal kind kept with them so the teller follows one view. The
+  holder is heard from the seat-holders view as A-295 has it, never asked on a timer, and a moved holder is followed
+  as it moves (principles 1, 3, 7 and 8). How it is checked: unit (mesh-sdk `views`), a `FollowSeat` with no holder
+  returns at once and writes `view-waits` naming the seat past five minutes; a seat-holders change naming a holder
+  takes its first view from `<holder>.<state>` and hears its family; a second change naming another holder drops the
+  first and follows the second; no ask is made between changes. Unit (manifest validator):
+  `seat:mesh-delivery-view.views.answers` and `seat:mesh-wants.views.asks` are accepted, and a seat view of a state
+  without `view` is refused. Whole (teller): started before any module holds `mesh-wants`, it raises an assigner's
+  ask once the holder is placed, and takes an answer the status view writes. The code review: no module name of the
+  assigner or the status view in the teller's, the status view's, the builder's or the checker's code, and no
+  timer that asks for a holder again.
@@ -443,3 +443,19 @@ the principle that settles it, cited as "design 47 G A-n".
  writes the refused key `<node>.<module>.<fp>` with the event's words, a later done end of the module (at any
  fingerprint) deletes the refused key such an end wrote, so the state never says refused for a done build, and an
  end naming a branch moves nothing.
+- **A-294** (corrects A-267; §600, A-170; principle 7, the seat definition is the one source) The seats mesh-wants and
+  mesh-builds are not build seats: their accepted kind `step` stays without a token (not `by-caller`), and the
+  composition step's step-progress names its asker as the one caller its seat's definition lists, read from the seat
+  list; only the three build seats carry the asking seat's name as a token.
+- **A-295** (A-210; principles 1 and 7, one shared mechanism in the SDK) A tool's callers list names a seat as the entry
+  `seat:<seat>`, resolved in mesh-sdk's verb callers by a holder function the part is given; that function follows
+  the assigner's seat-holders view (as the watcher does) and answers from what it last heard, never one call per
+  checked call; each part's list becomes the operator, `seat:node-tool-runner` and `seat:mesh-healers`.
+- **A-296** (A-210, A-131; principles 1 and 2) Where A-210 makes a part find another by the seat it holds, the part's
+  manifest takes the seat forms in the same change (`seat:<seat>.views.<state>` for a consume, the seat's verb for an
+  invoke), and a part names its own buckets from its credential's module, never from a constant. Which seat a module
+  that holds none (the delivery view) or several (the assigner) is found by is a design line (§717).
+- **A-297** (A-232, A-111; principle 7, one form per fact) The pipeline runner's step ask id takes the usual ask id
+  form: base 36 of the pipeline's start time in milliseconds, then six hex digits of the sha256 of the pipeline, the
+  artifact and the step, so the same placement makes the same id at every start (and the bus dedupes on it); a rerun
+  uses its own start time.
@@ -45,10 +45,12 @@ decisions:
  - "ADR 0573"
  - "ADR 0571"
  - "ADR 0567"
+  - "ADR 0565"
  - "ADR 0564"
  - "ADR 0563"
  - "ADR 0551"
  - "ADR 0548"
+  - "ADR 0540"
  - "ADR 0539"
  - "ADR 0534"
  - "ADR 0525"
@@ -86,7 +88,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 twenty-one files, each read whole, its design lines numbered across them:
+The part is twenty-two 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.
@@ -108,7 +110,7 @@ The part is twenty-one files, each read whole, its design lines numbered across
 - [G-18-fix-round-six-seven](G-18-fix-round-six-seven.md): the fix round of §587 to §676: the approval mark once no verb names its callers, the keeper's snapshots, the recovery module's verbs, the node-engine's kept entries, the gate before a marked verb's running, develop's D-16 to D-49, and a delivery's wait on another machine's network (§677 to §705).
 - [G-19-outside-wait-and-refusals](G-19-outside-wait-and-refusals.md): a delivery's wait on an outside cause, written whole once (§706, in place of §705), and the finding writer's own refusals in every bundle (§707, amending §580).
 - [G-20-lead-answers](G-20-lead-answers.md): the lead's one-line answers to develop's questions, each tested against the principles (A-1 on).
- [G-21-provider-and-revert-ask](G-21-provider-and-revert-ask.md): the provider a requirement points to, the named seat and the contribution edge (§708, §709, completing §357), and the assigner's ask of a held revert (§710, completing §300), the edge an acting rule gives (§711, completing §47's kind 5), the validation before take-in (§712, §713, completing §16) and the take-in and groups of every watched branch (§714, §715).
+- [G-21-provider-and-revert-ask](G-21-provider-and-revert-ask.md): the provider a requirement points to, the named seat and the contribution edge (§708, §709, completing §357), and the assigner's ask of a held revert (§710, completing §300), the edge an acting rule gives (§711, completing §47's kind 5), the validation before take-in (§712, §713, completing §16), the take-in and groups of every watched branch (§714, §715), where the gate keeps a group's members (§716) and the seats of the status view's and the assigner's views, followed before their holder is known (§717).
 - [G-22-lead-answers-2](G-22-lead-answers-2.md): the lead's answers continued, from A-182.

 Design 34's milestone [every-event](../34-milestones/every-event.md) and design 46's milestone [7-approval-mark](../46-milestones/7-approval-mark.md) ship in milestone G's release, built in its repositories beside G's lines (lead-47, 2026-11-11 15:30 CET); where one of their lines and a line of G differ, G's later line holds and the other is corrected in place (§624 to §626).