From db726d734e5eff513e391a710ab1321bcc8c915c Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 05:37:40 +0100 Subject: [PATCH] Answer A-172 and A-173: the teller's merge path goes; the view per branch Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- 03-DESIGN/01-to-be/47-milestones/G-20-lead-answers.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/03-DESIGN/01-to-be/47-milestones/G-20-lead-answers.md b/03-DESIGN/01-to-be/47-milestones/G-20-lead-answers.md index cadf1049..a6659cd3 100644 --- a/03-DESIGN/01-to-be/47-milestones/G-20-lead-answers.md +++ b/03-DESIGN/01-to-be/47-milestones/G-20-lead-answers.md @@ -646,3 +646,12 @@ names the principle that settles it, and is cited as "design 47 G A-n". - **A-171** (§579, A-169; principles 2 and 8) The `pinned` event's `catalog` entries name their branch: each is `{branch, revision}`, in the mesh-delivery seat's definition and from the gate that says it, so a holder keys the pin `.` from what the event says. +- **A-172** (§653, §431, A-161; principles 1 and 7) With the Approve per merge gone, the teller's merge-ask path goes + whole (its reads of the gate's `asks`, its handlers and their tests); the teller keeps `answers` and `answered` for + the assigner's asks only. A view's answer reaches it by the view's event, as §431 says, never by reading the + view's state. The gate fills `recovery-merged`'s `branch` from the branch it merged into and its `module` from the + catalog half's registrations; while no path of the gate opens a forge-made record, the teller says none. +- **A-173** (§507, §512, §532, A-103; principle 7) The view derives each watched branch's source on its own: the + source row and `delivered` per branch, a repository's reach from the source of the first branch of its + registration (before the first registrations, the branches `source` answers), and `view_tiers` with no revision + answering per branch; no branch is named in its code.