From df569ad63a4cdb8f2f96e57bc5e221d103738a92 Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 04:57:52 +0100 Subject: [PATCH] Answer A-151: the build modules read the artifact store through its provision Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- 03-DESIGN/01-to-be/47-milestones/G-20-lead-answers.md | 4 ++++ 1 file changed, 4 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 ac261486..57af4354 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 @@ -564,3 +564,7 @@ names the principle that settles it, and is cited as "design 47 G A-n". - **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. +- **A-151** (§465, ADR 0614 §2; principle 7) The three build modules `require` the provision `artifact-store` to read a + group member's build, with a `binds` file as go-package-registry's (`at`, `serves.port`), and read the blob by the + store's own path `:/v2///blobs/`; they never write into it, so ADR 0614 §2 + holds, and their manifest tests assert the read.