Answer A-310: a compose request's manifest names its fingerprint beside its digest

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-12 22:19:36 +01:00
parent 383f21ed49
commit 47bb7409be
1 changed files with 6 additions and 0 deletions
@@ -505,3 +505,9 @@ the principle that settles it, cited as "design 47 G A-n".
 - **A-309** (A-290, A-254, research 071; principles 7 and 2) A build module's `outputs` objects live as long as the
  step key that names them: the store's age is the steps state's time to live (two days), its cap 256 MiB, and the
  bus's own age removes an object; nothing else deletes one. The milestone's lifetime list gains this line.
+- **A-310** (§615, §506; principles 7 and 3) A compose request's manifest named by digest also names the fingerprint
+  whose catalog graph entry holds it: `composer.Manifest` gains `fingerprint` beside `digest`, and the checker, the one
+  part that sends digests, fills it (a pull's `Fps`, else the trunk revision's entry of that module). The Go build module
+  reads the entry by `seat:mesh-catalog.entry` with that fingerprint, takes its manifest whole, and refuses the request,
+  saying which module, when the entry's `manifest-digest` differs or a digest comes without a fingerprint. A manifest
+  sent whole (`raw`, the assigner and the indexer) is read as today.