From 41b2345ba46c117c6e00cf8ebc0d368639e7027f Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 09:18:31 +0100 Subject: [PATCH] Answer A-247: a validation says it was accepted; its answer comes in step-ended Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- 03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md | 4 ++++ 1 file changed, 4 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 a786be9c..6b506019 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 @@ -260,3 +260,7 @@ the principle that settles it, cited as "design 47 G A-n". - **A-246** (§376, §498, A-211; principles 2 and 4) A dependent's delivery wait is kept in a state of its own, `delivery-waits` (key the module, value the `wait-held` said), read by `assigner_waits` beside the others; `assigner_release` {module, step: delivery} writes the hand-act log first and ends the wait `released`. +- **A-247** (§713, A-232; principles 1, 2 and 7) The pending value's `validation` gains `accepted` (the seq it was + accepted at), so a revision held for another indexer is never asked again; `validation` sits on the newest pending + value of the revision alone. The answer is read from the `step-ended` event's own output and output object, never + through the build seat's `steps`; the ask is put through the delivery SDK's `buildrun.Asker`.