G-129 + G-101: downstream back-pointers to G-131

Both pairs read as one-directional in goals_xref (G-131 -> G-129 scoring 3.55, G-131 ->
G-101 scoring 2.03) because the dependency convention has the consumer point at its
predecessor. Adding the reverse edge so a reader who opens G-129 or G-101 - the two goals
likely to be activated first - sees what is waiting downstream. Non-contract Notes only;
neither goal's Goal or Acceptance changes, and both still stand alone.

G-129: G-131 generalises its derivation from "where is the zipfs image mounted" to "which
container is attached at all". That does not change what G-129 delivers, but it does say
something about HOW - keep the derivation factored as a step that answers a question about
the running kit rather than inlining a zipfs assumption into the surrounding path assembly,
so the metakit arm can be added beside it rather than around it.

G-101: this is the more consequential one. G-131 wants a runtime that boots from EITHER
container, which bears on how G-101's decision should be FRAMED - if G-131 is wanted, the
useful outcome is not "pick one container for 8.6 and close the question" but "establish
that metakit is carryable AND that the zipfs backport is carryable, and record which is the
default". The file already surveys both candidates and both look additive; the two sections
were written independently as competing options, and G-131 is the reason to read them as a
possible pair. Recorded explicitly that this does not block G-101's decision - it can still
be decided without committing to G-131.

goals_xref now reports both pairs as linked.

Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com

goals/G-101-tcl86-kit-container-strategy.md

@@ -45,6 +45,18 @@ unblocked; activation is the user's call.
 
 ## Notes
 
+- DOWNSTREAM: G-131 (back-pointer added 2026-07-27) wants a runtime that boots from EITHER
+  container - metakit or zipfs - detected at boot, so that the container becomes a bake-time
+  choice and the deliverable count stops being multiplied by container. That has a direct
+  bearing on how this goal's decision should be framed: if G-131 is wanted, the useful
+  outcome here is not "pick one container for 8.6 and close the question" but "establish
+  that metakit is carryable AND that the zipfs backport is carryable, and record which is
+  the default". Both candidates are surveyed in this file and both look additive - the
+  zipfs backport is a new source file plus a Makefile object (see the zipfs section), and
+  the mk4tcl port to 9 is bounded (see the metakit section). The two sections were written
+  independently as competing candidates; G-131 is the reason to read them as a possible
+  pair. G-131 depends on the port work this goal would do; it does not block this goal's
+  decision, and this goal can be decided without committing to G-131.
 - Related: G-125 (achieved 2026-07-27 - see goals/archive/G-125-unbootable-kit-deploy-gate.md) -
   a new container type is exactly where an extraction path can silently produce nothing,
   and the bake now refuses such a kit instead of deploying it. Concretely for this goal:

goals/G-129-kitboot-mountpoint-derivation.md

@@ -93,6 +93,13 @@ the source tree, not from a kit payload - which is what made the gap easy to mis
   So the failure is not "mounted at an unexpected place and therefore mis-resolved" - it is
   "concluded there is no zipfs at all, and skipped every internal-path branch".
 
+- DOWNSTREAM: G-131 (back-pointer added 2026-07-27) generalises this goal's derivation from
+  "where is the zipfs image mounted" to "which container is attached at all - metakit or
+  zipfs". That does not change what this goal must deliver, but it does say something about
+  HOW: keep the derivation factored as a step that answers a question about the running
+  kit, rather than inlining a zipfs assumption into the surrounding path-assembly code, so
+  the metakit arm can be added beside it rather than around it. G-131 depends on this goal
+  and on G-101's port work; this goal depends on neither and ships on its own.
 - Related: G-031 - the closest structural overlap. That goal restructures this same file
   into a thin project-owned main plus a shared boot core; this changes logic that would
   live inside that core. Whichever lands second adopts the other's shape - the derivation