novox/hq
9
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge pull request 'Design 47 G: the lead's answers A-298 to A-303' (#589) from design/47-G-lead-answers-17 into main

Browse Source
This commit was merged in pull request #589.
This commit is contained in:
mesh-tools
2026-11-12 19:07:45 +00:00
parent 023a355cdb 9a14624b69
commit ea3b790f1d
1 changed files with 25 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md
+25
View File
@@ -459,3 +459,28 @@ the principle that settles it, cited as "design 47 G A-n".
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.
- **A-298** (§717, §614, §616, A-295; principle 7, one shared mechanism) The claimant of a seat is read from the
catalog half in one place, the catalog seat's client (`Branches.Claimant(seat)`), and one follower there follows
the claimant's seat-holders view, drops and follows again on each catalog change, and answers the SDK's holder
function; every part calls it once and FollowSeat builds on it. The assigner answers its own holder function from
its own seat-holders picture. The seat-holders first-view tool names its callers in A-131's module form for now
(the teller holds no seat to be named by); naming them by seat waits for every follower to hold one.
- **A-299** (§717, corrects its count; principles 3 and 7) The seat mesh-delivery-view's state `answers` takes one key
form per kind of mesh-wants' `asks` forms with `.view` after it (`hold.<module>.<fingerprint>.view`,
`restore.<node>.<module>.<fingerprint>.view`, and so for each), so its generated reader reads every real key; the
kinds are the seven the asks package writes (hold, restore, backup, record, outside, revert, assignments), not eight.
- **A-300** (§717, A-131, A-210; principles 4 and 7) The status view's process follows the wants by its seat-form
first view; its tools program keeps the invoke `assigner_read_wants`, because the view's tools read a want by its
key and its history (`view_tiers`' since of a want, `assigner_want`), which a first-view tool (pages after a
position) does not answer; `assigner_read_asks` and `assigner_read_assignments` go as §717 says.
- **A-301** (§717, A-131; principle 7, one form per seat view) The status view's first-view tool `answers` is mesh-sdk's
first-view tool (the one with a callers list, as the assigner's `asks` and `wants` are), its callers the teller in
A-131's form; §717's "views.ReadTool" reads as this.
- **A-302** (§717, A-298; principles 1 and 7) The indexer follows the assignments through FollowSeat as well, the
claimant of mesh-module-assigner read from its own catalog (it holds the catalog seat), so buildrun's 5-second
holder loop goes for every part.
- **A-303** (§717, A-302; principles 2 and 7) The status view names its followed pictures in the seat form
(`<seat>_<state>`); where a name must be the holder's real bucket (the watchdogs' stuck key, which matches what the
watchman writes, and the reach history's bucket names, whose kept entries stay readable), the view takes it at run
time from the holder FollowSeat follows, through one accessor of the SDK's process reader; no code names the
assigner's module.