goals: characterize modpod binary-.tm load location + record multi-name/punkbin intent

Characterized (windows tcl 9.0.5) how a binary inside a zip-based .tm (modpod)
loads, per user request. All three loading locations - dll direct in a kit's
zipfs, a standalone .tm on disk, and a .tm nested inside a kit's zipfs
(zip-in-zip, mounts in place, no .tm pre-extraction) - converge on the same
copy-to-temp path: the binary extracts to %TEMP%\TCL<hex>\ with the same
TIP-741 non-cleanup/accumulation flaw (verified with a #modpod-mybintest
wrapping a real tcl9thread307.dll built via modpod::lib::make_zip_modpod).

- G-066 (substantive): the characterization + the multi-package-name design -
  manifest-at-well-known-location read by libunknown (not yet implemented);
  multi-name .tm are punkshell/libunknown-only, not plain-tclsh loadable, which
  is acceptable if clearly documented; TIP 590 lowercase single-name is the
  plain-tclsh-loadable happy path; complex mechanisms OK with extensive tests.
- G-103: TIP-741 thread extended - windows flaw now confirmed for BOTH
  direct-kit and modpod-.tm binary loads.
- G-105: linux leg BLOCKED - local WSL is tcl 8.6.14 (no zipfs); needs a linux
  tcl9 runtime. Windows done; linux expectation (no accumulation) unverified.
- G-067: binary modpod .tm as a publish payload; cross-refs.

Temp reclaim also done this session: 15,596 orphaned %TEMP%\TCL* dirs removed.
Notes only; no contract changes. goals_lint clean.

Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com

goals/G-066-pkgindex-tm-repackaging.md

@@ -38,3 +38,29 @@ current goal touches this.
   characterization - what happens when both shapes of the same package are present),
   G-063 (license fields in the datafile), G-065 (manifest schema sharing), G-067
   (repackaged artifacts as the publish payload).
+- 2026-07-21 (user direction: support binary-bearing zip-based .tm as single-file
+  downloadable libs, and generate them for punkbin). CHARACTERIZED the binary-load
+  path of a zip-based .tm (modpod) on windows tcl 9.0.5 - specimen: a
+  #modpod-mybintest-0.1 wrapping a real tcl9thread307.dll, built via
+  modpod::lib::make_zip_modpod. Findings: the .tm self-mounts (its prepended stub
+  runs tcl::zipfs::mount <tmfile> //zipfs:/#modpod/...#mounted-modpod-<pkg>-<ver>),
+  then the inner binary 'load's from that zipfs mount and EXTRACTS to
+  %TEMP%\TCL<hex>\<dll> - the SAME copy-to-temp machinery as a direct-from-kit dll
+  load, so the TIP-741 non-cleanup/accumulation flaw applies equally (one temp dir
+  per binary, persists on exit; see G-103 Notes). Three loading locations all
+  converge on this one mechanism: (1) dll direct in a kit's zipfs, (2) standalone
+  .tm on disk, (3) .tm nested INSIDE a kit's zipfs - the nested (zip-in-zip) mount
+  works IN PLACE with NO pre-extraction of the .tm itself; only the dll load hits
+  temp. Note: LOADING a modpod .tm needs only zipfs (the stub is self-contained -
+  no punk/modpod package), so a single-name modpod .tm is plain-tclsh loadable.
+- 2026-07-21 (user): MULTI-package-require-name modpod .tm (case variants like
+  Thread/thread, or sub-packages from one file) needs a manifest at a well-known
+  internal location discovered by libunknown during module scanning - NOT YET
+  IMPLEMENTED. Accepted consequence: a multi-name .tm is punkshell/libunknown-only,
+  NOT loadable in plain tclsh - fine PROVIDED the repo system/docs indicate this
+  clearly. TIP 590 ('recommend lowercase package names') makes the SINGLE-lowercase-
+  name path the happy case (plain-tclsh loadable, no libunknown, no Thread/thread
+  duplication) - the recommended shape for a downloadable single-file binary lib
+  when one require name suffices. New/complex mechanisms are acceptable in punkshell
+  IFF backed by extensive tests. Ties to G-035 (mixed .tm/pkgIndex discovery),
+  G-034 (modpod mount path), G-067 (punkbin publish of these artifacts).

goals/G-067-module-artifact-channel.md

@@ -35,3 +35,10 @@ and pull (G-065) instead of re-vendoring by hand.
 - Related: G-006 (pattern source and candidate shared implementation), G-027 (remote
   infrastructure-pull transport candidate), G-065 (manifest integration), G-066
   (artifact payloads and distribution-unit metadata).
+- 2026-07-21 (user): binary-bearing zip-based .tm (modpod) are an intended publish
+  payload here - single-file downloadable libraries carrying manifest + binary +
+  script. Consuming-side load extracts the binary to %TEMP%\TCL* with the TIP-741
+  non-cleanup flaw on windows (characterized - G-066/G-103 Notes). Single-lowercase-
+  name .tm (TIP 590) are plain-tclsh loadable; multi-require-name .tm need libunknown
+  (punkshell-only, must be documented). Generation + multi-name discovery detail:
+  G-066 Notes.

goals/G-103-runtime-kit-family.md

@@ -227,3 +227,8 @@ contract the sequencing note promises G-101.
   mapped, so the expectation there is NO accumulation; verify rather than assume.
   (Method: mount a zip containing a built dll, load from it, diff %TEMP%/tmpdir
   before+after and after exit; scratch scripts under the session scratchpad.)
+- 2026-07-21: the modpod path was ALSO characterized on windows 9.0.5 - a binary
+  inside a zip-based .tm (self-mounting modpod, including one nested in a kit's
+  zipfs) extracts to %TEMP%\TCL* with the SAME non-cleanup flaw (details in G-066
+  Notes). So windows = flaw confirmed for BOTH direct-kit and modpod-.tm binary
+  loads. Linux/WSL leg is blocked on a linux tcl9 runtime - see G-105 Notes.

goals/G-105-buildsuite-cross-target.md

@@ -54,3 +54,10 @@ dimension), G-102 (achieved 2026-07-21 - driver shape settled; target becomes a
   known wart (Tcl core TIP 741, windows-framed). Test on linux/WSL (and the
   G-060 guests) that it does not accumulate, or characterize it. TIP 741 detail
   + the cross-platform requirement: G-103 Notes.
+- 2026-07-21: linux leg of the temp-cleanup characterization is BLOCKED on a linux
+  tcl9 runtime - the local WSL has only tcl 8.6.14 (no zipfs), so the zipfs
+  copy-to-temp path cannot be exercised there. Needs a linux tcl 9.0+ with zipfs +
+  a loadable .so (this goal's own cross-build, or an apt/self-built tcl9). Windows
+  is fully characterized (confirmed flaw, both direct-kit and modpod-.tm binary
+  loads - G-103/G-066 Notes); the linux expectation stays no-accumulation
+  (unlink-while-mapped) but is UNVERIFIED until a runtime exists.