2026-11-12 21:55:26 +00:00
1 changed files with 12 additions and 0 deletions
@@ -536,3 +536,15 @@ the principle that settles it, cited as "design 47 G A-n".
  check gives the test. Each fetched build is started the way every module is, by the node-engine's own apply of a
  want on the test's bus, under the module's own account; the test starts no bare process. Where the seat does not
  answer, the test fails, saying which build it could not fetch and why; it never skips.
+- **A-316** (§379, §421, §628, A-312; principles 2 and 7) A node-engine composes a candidate only from what its asker
+  gives it, as it composes a want. The assigner's candidate `<proposal>.<node>` gains `added`: by module, for each
+  module the candidate adds to that node without a want there, the `version` and `parts` the want it would write
+  carries, in the same wire forms (the seat format reuses nothing across repositories, so the assigner's seat
+  defines the two properties itself and a fixture holds them to the want's), made by the same code that writes wants. The node-engine's shadow builds such a module from that
+  entry and its `added` parts; a module with artifacts the candidate gives no parts is held, saying so. Nothing reads
+  the builder's states or asks the registry for it.
+- **A-317** (A-316; principles 1 and 7) A proposal's candidates have one writer, the assigner's main process (the
+  passer), which holds the heard builds and released versions: on hearing a proposal it writes each node's candidate
+  with `added` filled, as `layAgain` does. The verbs' tool process writes the proposal alone and no candidate, so no
+  node-engine sees a candidate before its parts. If a verb's answer needs the candidates, it waits on the passer's write
+  (an event or the state's watch), never a timer.