G-103 context: vfs-system relationship note (bi family = kit minus main.tcl)

Records the 2026-07-21 discussion: make.tcl's zip-kit extract+merge_over+mkimg
flow already unifies runtime-zip and vfs-folder payloads, so the bi family is
isomorphic to a .vfs kit without its main.tcl fauxlink. Where the equivalence
breaks (tcl_library provenance, stock-boot path setup, dll-from-zip loading) is
the goal's design content; generators stay separate (bootstrap hermeticity,
release axis) and meet at the attached-image contract - the concrete payload
contract promised to G-101.

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

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

@@ -101,6 +101,45 @@ names; projects and fingers consume short stable WORKING names; 'runtime use'
 (The acceptance's 'e.g tclsh905punk.exe' example predates this decision; the
 decided punk-marked shape is tclsh<dotted-patchlevel>-punk....)
 
+VFS-SYSTEM RELATIONSHIP (user observation 2026-07-21, assessment recorded): the
+bi family is structurally what the existing .vfs kit system would generate with
+the main.tcl fauxlink (-> _config/punk_main.tcl) left out - and make.tcl
+half-proves the isomorphism: its zip-kit path extracts the runtime's attached
+image, merge_overs it with the .vfs content and re-images the union onto the raw
+exe via tcl::zipfs::mkimg (mkimg REPLACES the whole attached image - one archive
+out), so runtime-zip and vfs-folder payloads are already treated as the same
+species, and punk9wintk905.vfs's bin/ + lib_tcl9/ batteries are essentially this
+family's payload list. Where the equivalence breaks is this goal's real design
+content:
+
+- tcl_library provenance: the kit flow inherits the core lib by EXTRACTION from
+  the runtime underneath; a family runtime must guarantee it directly (the
+  suite's make-zipfs step already does).
+- path setup: kit batteries are visible only because punk_main.tcl (punk::boot)
+  wires lib_tcl9/bin into auto_path/loading; with no main.tcl the stock zipfs
+  app hook falls through to plain interactive tclsh and nothing wires them -
+  family payload must sit where the STOCK boot searches, i.e. the installed
+  lib-tree layout, which the suite's out/lib already is (post-tclsh steps
+  install thread/tclvfs/tcllib/tcllibc/tklib there; build_tk delivers Tk
+  lib + dll).
+- open at activation: staging-tree convention, payload layout inside the zip
+  (stock lib tree vs lib_tcl9-style + boot hook), and dll-load-from-zipfs for
+  Thread/Tk (core's copy-to-temp fallback; AV/cleanup caveats) - these, not the
+  zip mechanics, are the design work.
+
+SEPARATION vs SHARING: the generators stay separate - bootstrap position
+(family runtimes must be produced hermetically with no punkshell available;
+make.tcl needs a working shell, and the family runtime IS the bootstrap
+product) and release axis (tcl-patchlevel + -rN vs punkshell version) both
+force it; Scope accordingly casts src/vfs/_config + mapvfs.config as name
+CONSUMERS. Sharing happens at the primitive (both generators bottom out in
+zipfs mkimg over a staged tree) and at the CONTRACT: a family runtime's
+attached image is exactly what make.tcl extracts and merges under every future
+kit. Consequence: once family runtimes exist, punk9wintk905-class vfs folders
+shrink toward pure punkshell payload (modules + main.tcl + twapi-class
+vendored bits) - and this attached-image contract is the concrete payload
+contract the sequencing note promises G-101.
+
 ## Notes
 
 - 2026-07-21 (user): SEQUENCING CONFIRMED - G-097 (bin naming sweep, achieved 2026-07-21) first, then