Design 47 G §717: the status view's and the assigner's views are named by their seats
Developer J27 met, building A-210, a status view that claims no seat and an assigner holding two seats, both followed by the teller by module name. ADR 0540 §1 already names the seat mesh-delivery-view; G defines it with its one view, puts the assigner's asks and wants on mesh-wants, and has a follower find the holder in the background so no start stops for it. Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
This commit is contained in:
@@ -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,64 @@ 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, A-126, A-131, A-175, A-178, A-210) 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).
|
||||
- **A follower starts before the holder is known.** mesh-sdk's `views.ProcessReader` gains `FollowSeat`, given a
|
||||
seat and a state: it returns at once a picture that reads as empty, its follower not ready, and never fails for
|
||||
want of a holder. In its own goroutine it asks `seatlist.HolderOf` for the seat through the process's calls; a
|
||||
failed ask is said in the process's journal, naming the seat and the error, and asked again 5 seconds later,
|
||||
until it answers or the process stops. Meanwhile the follower's status names the seat in place of its owner,
|
||||
waiting since the start, and past five minutes the reader writes §200's `view-waits` naming the seat and the
|
||||
state, cleared when the first view arrives. Once the seat's holder H is known it follows as `Follow` does after
|
||||
`Start` (§532): the first view asked of H's tool named for the state, then H's views family. The holder found is
|
||||
kept for the life of the process, and a new holder is followed from the follower's next start. 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 builder's and the checker's
|
||||
own loop for the assignments, buildrun's `AssignerHolder`, goes: both follow `assignments` through `FollowSeat`.
|
||||
|
||||
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, and
|
||||
the holder is found as A-210 has it, asking again and never stopping a start (principles 1, 3, 7 and 8). How it is
|
||||
checked: unit (mesh-sdk `views`), a `FollowSeat` whose holder ask fails twice returns at once, writes `view-waits`
|
||||
naming the seat past five minutes, then takes its first view from `<holder>.<state>` and hears the holder's family;
|
||||
unit (manifest validator), `seat:mesh-delivery-view.views.answers` and `seat:mesh-wants.views.asks` accepted, a seat
|
||||
view of a state without `view` 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.
|
||||
|
||||
@@ -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).
|
||||
|
||||
Reference in New Issue
Block a user