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
2026-11-12 22:29:02 +01:00
parent 3acb50433a
commit fdac1264ac
1 changed files with 7 additions and 0 deletions
@@ -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 `<module>_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.