Answer A-82: build modules found through their seats

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-11 23:13:31 +01:00
parent acdef3a98d
commit 2f8e07d923
1 changed files with 7 additions and 0 deletions
@@ -316,3 +316,10 @@ names the principle that settles it, and is cited as "design 47 G A-n".
  start, §556, so a restart rebuilds them); `running` means not stopped, with a fingerprint; a not-stored artifact is
  remembered on the reservation (`Unstored`); the tool's request rides a reasks mode `republish`; a message the state
  cannot take is not acknowledged, as the other parts do.
+- **A-82** (§7, §428, §704's seed; principle 1, no module names another) The builder finds a build module the way the
+  indexer's seed does (mesh-delivery d73aeb02): the build seat whose acting rule `build` has an `on` matching the
+  artifact's language or `kind:image`, and that seat's holder on the seat list. `Task.Module` and every lane key are
+  that holder's name as the seat list gives it; a plan's artifact, the toolchain sources, `UnpublishedModules` and
+  `builder_stuck` all derive from it, and `builder_stuck` reads each build seat's steps through the seat (`<seat>.steps`)
+  rather than a named module's state. The floor's sources are the holders of the seats `git` (tags) and `mesh-catalog`
+  (requirements) on the seat list.