Answer A-172 and A-173: the teller's merge path goes; the view per branch

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-12 09:41:28 +01:00
parent d8dade2563
commit db726d734e
1 changed files with 9 additions and 0 deletions
@@ -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 `<branch>.<revision>` 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.