2026-11-12 19:07:45 +00:00
1 changed files with 25 additions and 0 deletions
@@ -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.