Merge pull request 'Design 47 G: the lead's answers A-36 to A-43, and corrections of A-27 and A-30' (#556) from design/47-G-lead-answers-4 into main

2026-11-11 21:27:07 +00:00
parent 2b731e1141 d9a0e19b20
commit e1819e0a0d
1 changed files with 40 additions and 6 deletions
@@ -103,19 +103,25 @@ names the principle that settles it, and is cited as "design 47 G A-n".
 - **A-26** (§687, §689, A-22; principle 7) A part raises no follower's finding itself: every follower is adopted through
  its reader (`Adopt`), and the reader raises and clears the follower's four findings through the module's writer, so
  the pipeline runner, the indexer and the assigner build none of their own.
- **A-27** (A-26, A-16; principle 7) The tool runner's first views follow A-26 too: `firstview` builds a
+- **A-27** (A-16, A-28, A-29; principle 7; corrected) The tool runner is no process module, so it keeps its own
-  `views.ProcessReader` over the runner's bus connection and adopts its followers, so the reader raises their findings;
+  consumer and its four followers as they are and builds no `views.ProcessReader`. It writes the findings it wrote
-  the runner's `bus.Conn` gains one accessor for its JetStream, its one place (A-16).
+  before (`first-view-unanswered` and the others of its old code, the same kinds) through one `views.HeldWriter` over
  its own connection: a small state adapter over the connection's state calls, `Publish` and `Listen` from the
  connection, in its one place (A-16); it writes and clears each follower's finding as that follower's status says, as
  A-28 has for a single ask. Its JetStream comes from the connection as `bindings.go` already makes it.
 - **A-28** (A-26, A-22, §687; principle 7) A part's own follower (mesh-config, mesh-vault) is followed through a
  `views.Reader` holding the module's writer and adopted, as A-26. A single ask that is no follower (mesh-build-go's
-  manifest ask, the tool runner's ask) writes and clears its `first-view-unanswered` finding itself through
+  manifest ask) writes and clears its `first-view-unanswered` finding itself through
  `Writer.Write` and `Writer.Clear` with the contract's `Finding`; mesh-sdk exports no helper for it.
 - **A-29** (§686, A-3; principle 7, shared code lives in mesh-sdk) A part whose findings are raised as they happen, not
  judged afresh, uses one mesh-sdk form of the writer that observes from its own state: it seeds what it holds from the
  state's keys before it starts, keeps them under its own lock, and its `Observe` answers them, so no part writes that
  adapter (the watchman's copy moves there; the assigner, builder and indexer use it).
- **A-30** (§383, §686; principle 3) Every module whose writer publishes declares the events it says
+- **A-30** (§383, §529, §686; principle 3; corrected) Every module whose writer publishes declares its finding events
-  (`finding-written`, `finding-cleared`, `findings-stated`) in its manifest; none publishes an event it does not declare.
+  as §529 says: a foundation part (the validator's list) in its old `streams` section as `<module>-findings`; every
  other part in its `requires` by the template `events` as `finding-events`, its entry listing `finding-written.*`,
  `finding-cleared.*` and `findings-stated.*`. None publishes an event it does not declare, and no other part declares
  `<module>-findings`.
 - **A-31** (A-14, A-22; principles 3 and 7) A module whose old finding keys end in no kind it owns (gitea's package
  registry, distribution) deletes those old keys once at its start, in its own code, so no stale finding stays; the
  writer's rule is unchanged.
@@ -131,3 +137,31 @@ names the principle that settles it, and is cited as "design 47 G A-n".
  `acts` with when it was said, and ended there on `owed.ended`, so `stalled` reads the unanswered ones.
  `approval-carried` and `approval-carried-open` are design lines (§542, §592), not left out: they are built, with the
  `pull-merged` and `pull-closed` consumes that clear the finding.
 - **A-36** (§622, §643, A-21, A-22; principle 7) As built in mesh-sdk a59ccad8: the Go package's `calls` are the four
  words its calls need (`ledger-upkeep-calls`, `sent-objects-calls`, `put-sessions`, `finding-calls`), the npm package's
  `finding-calls` alone; the npm package makes no session, so its `state.put` refuses a value over one chunk, naming
  it. A-22 holds for TypeScript too: the TS follower keeps no plain-field `Finding` of its own beside the writer.
 - **A-37** (A-16, A-29, A-32; principles 7 and 3) The held writer has a stdio form, `views.NewStdioHeldWriter`, filling
  `Publish` and `Listen` as A-16's does, so no module writes the adapter; and the held writer holds every finding
  written through it, its `WriteWire` included, so a reader's findings are in its statement too.
 - **A-38** (A-29, A-32; principles 4 and 7) The held writer can be read: `HeldWriter.Held()` answers the findings it holds,
  so a part that diffs or looks up its open findings (artifact-store-tools, mesh-config) reads them there and keeps no
  set of its own.
 - **A-39** (§158, §161 to §167, A-35; principle 7) Which record change makes which act, as the transitions did: every
  change of a record (a step's outcome applied, the record ended) says a line on the head commit's note
  (`<at> record <key>: <what changed> (<why>)`, one line) and replaces each member pull request's delivery view with
  what `show` answers for the record; a comment is said only when the record ends failed or held, naming why. The gate's
  own findings (`approval-carried-open` first) go through one held writer over its own `findings` state (A-29, A-37).
 - **A-40** (A-29, A-37; principle 7) The held writer seeds what it holds from its state at `Start`, not when it is
  made, so every module makes it at once, as it makes the plain writer, and no stdio module waits for `Served` in an
  adapter of its own; a `Write` before `Start` is held and written at `Start`.
 - **A-41** (§492, §604, §546; principle 1) A part reads another module's data only by asking it, so the checker and the
  indexer stop reading the build modules' `toolchains` buckets: they take a toolchain from the builder's own read verb
  or event where one serves it today. Where none does, the restored read stays for G, built as mesh-delivery 7a3c312a
  has it, and the lead notes it for the next milestone; no new verb is added in G for it.
 - **A-42** (§592; principle 8) The gate's `approval-carried-open` has scope `delivery`, a scope the mesh already uses
  for the delivery's findings, and id `<repository>.<pull>`.
 - **A-43** (A-26, A-28, A-16; principle 7) As built in mesh-catalog d03ffa80 and mesh-tools 4bfae38a: an owner's plain
  `<owner>.views.<state>` family is followed by `Reader.Follow`, the follower's `Ask` set after (`Adopt` is for a seat's
  events); and the tool runner's held writer is given its JetStream, the writer's own defaults publishing and
  listening, so `bus.Conn` gains no publish method.