From fdac1264acd066079a3e97cff77ed26f15f5b85a Mon Sep 17 00:00:00 2001 From: jochen Date: Thu, 12 Nov 2026 22:29:02 +0100 Subject: [PATCH] Answer A-315: test 36 takes the builds of before G from the mesh and starts them as every module starts Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h --- 03-DESIGN/01-to-be/47-milestones/G-22-lead-answers-2.md | 7 +++++++ 1 file changed, 7 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 2ffb7fa7..4d4b555d 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 @@ -529,3 +529,10 @@ the principle that settles it, cited as "design 47 G A-n". `requires` as a state with `ttl-seconds: 172800` and `objects-max-mib: 256`; its bucket stays `_steps`, so the seat's `steps` state is served from it as before. The step runner names the store through `catalogue.StateObjectsName("steps")`, and the manifest validator accepts `objects-max-mib` on the state template. +- **A-315** (test 36, §637, §555, §405; principles 2, 3, 5 and 7) Test 36 takes the fingerprints of before G from the + mesh, not from a file: during G's check the trunk is before G, so it asks `seat:mesh-catalog.module` for the + indexer, the assigner, the gate, the backup holder and the bus module, and fetches each build by its fingerprint + through `seat:oci-artifact-registry` under the checker's account, as §637 says; the address of both is the bus the + check gives the test. Each fetched build is started the way every module is, by the node-engine's own apply of a + want on the test's bus, under the module's own account; the test starts no bare process. Where the seat does not + answer, the test fails, saying which build it could not fetch and why; it never skips.