diff --git a/goals/G-101-tcl86-kit-container-strategy.md b/goals/G-101-tcl86-kit-container-strategy.md
index be6027e7..1eb8203b 100644
--- a/goals/G-101-tcl86-kit-container-strategy.md
+++ b/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:
diff --git a/goals/G-129-kitboot-mountpoint-derivation.md b/goals/G-129-kitboot-mountpoint-derivation.md
index 1b9538cd..59967472 100644
--- a/goals/G-129-kitboot-mountpoint-derivation.md
+++ b/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