From 2dd63fa700b12c02f682371c091605a6a0bef8c3 Mon Sep 17 00:00:00 2001 From: Julian Noble Date: Mon, 27 Jul 2026 05:10:00 +1000 Subject: [PATCH] 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 | 12 ++++++++++++ goals/G-129-kitboot-mountpoint-derivation.md | 7 +++++++ 2 files changed, 19 insertions(+) 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