From 5c766b7c8ce2dde4d895be3595488f3eb31c7596 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 22:54:24 +0100 Subject: [PATCH] Answer A-317: the assigner's main process alone writes a proposal's candidates Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- 03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md b/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md index d2e448a4..05362ad0 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md +++ b/03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md @@ -543,3 +543,8 @@ the principle that settles it, cited as "design 47 G A-n". 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.