|
|
|
@@ -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.
|
|
|
|
|