Answer A-268 (corrects A-263) and A-269: the Go module is read where it is built; a push's head is its merge

Claude-Session: https://claude.ai/code/session_01NcbgfGKaxw984XyAPfLm4h
2026-11-12 09:55:02 +01:00
parent e58be12323
commit 220d2fbe69
1 changed files with 6 additions and 0 deletions
@@ -334,3 +334,9 @@ the principle that settles it, cited as "design 47 G A-n".
 - **A-267** (§496, §481, §22, A-170; principle 7) The composition step's `step-progress` carries `asker` `runner`, the
  one asker that sends the accepted kind `step` on `mesh-wants`; the asker rename after join 11 (A-163, A-170) reads
  it from the accept subject's asker token instead.
+- **A-268** (corrects A-263; §712, §676, §491; principle 7) §676's `package` stays for package artifacts only, since a
+  bundle's Go module named as a package collides under §491's package names when two modules share one `go.mod`.
+  §712's job names the indexer entry's repository, `path` and the revision's head, and the program's directory;
+  `mesh-build-go` reads the Go module from the `go.mod` it builds there, as it does for every build.
+- **A-269** (§509, §714; principles 7 and 8) A `pushed` message's `head` stands where a `merged` message's `merge`
+  stands: pending refs, the newest load and the revision's head key on it alike.