From 9e737e7c4c4673d1b5205ac636c3633aa4d4fd89 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 04:54:30 +0100 Subject: [PATCH] Answer A-150: restic's night process gets its own bus Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- 03-DESIGN/01-to-be/47-milestones/G-20-lead-answers.md | 3 +++ 1 file changed, 3 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 804c0c18..ac261486 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 @@ -561,3 +561,6 @@ names the principle that settles it, and is cited as "design 47 G A-n". - **A-149** (§634, §527, A-120; principles 2 and 7) The node-engine knows its own name at start from its applied store: the record of the module whose fingerprint is its own `MESH_FINGERPRINT`; the finding writer, discovery and the vault login use it. Only on a first start with no such record do they wait for the first composing to name it. +- **A-150** (§563, A-107, A-115; principles 1 and 7) restic's `night` process, which dumps, gets a `bus` of its own + (its own broker account, as the recovery module's process has) and says item-started and item-ended and reads the + recovery module's events itself; no local request to the tools runtime, and the backup does not move into it.