Arising from the third-party 32-bit kit investigation. src/vfs/_config/punk_main.tcl
decides whether the running kit has an attached zipfs image with two assumptions that held
for every runtime punkshell had until now: it probes with 'info commands tcl::zipfs::root'
and then looks for the mount at a compiled-in //zipfs:/app. Christian Werner's androwish /
undroidwish backport gives Tcl 8.6 a working zipfs but no 'root', and mounts the
executable's attached archive at the EXECUTABLE'S OWN PATH, so [info library] reads
<exe>/tcl8.6. Against such a runtime punkshell concludes "no zipfs", neither the zipfs nor
the kitpath branch runs, and the kit silently gets no internal module or lib paths at all -
the failure surfaces later as packages that cannot be found. project_main.tcl carries the
identical code, so the same defect ships into every generated project; both files are in
Scope.
Two third-party 32-bit runtimes now in the win32-ix86 tier bracket the problem and are
named as the verification pair: tclsh8.6.10-luck-zip.exe (Lean Undroidwish Construction
Kit - no 'root', no ::zipfs ensemble, mounts at the exe path, library at tcl8.6/, and no
zipfs at all in child or thread interps) and tclsh9.1b0-tclsfe.exe (apnadkarni/tcl-sfe -
the modern //zipfs:/app convention on the same architecture). The Acceptance requires both:
the tclsfe kit proves the 32-bit target itself needs nothing special and that the
derivation did not regress the ordinary case, the LUCK kit is the actual work. Both are
untracked per G-004, so tests naming them self-gate on presence as the G-124 piperepl pin
does; the LUCK build is reproducible from its .cfg build request.
Approach settled in the draft: derive the mount point from tcl::zipfs::mount itself, whose
entries pair mountpoint with mounted file - the entry naming this executable is this kit's
archive wherever it landed. Detect zipfs by a command the backport also provides rather
than by 'root'. Leave the kitpath and cookfs branches alone. Report on stderr when an
archive is attached but no mount entry matches this executable, because silence is today's
failure shape and is what made this expensive to diagnose.
Overlap survey named G-031 (restructures this same file into a thin main plus shared boot
core - whichever lands second adopts the other's shape, and the derivation belongs in the
core), G-101 (its candidate container list already includes zipvfs-over-tclvfs boot, and
the LUCK runtime is a ready-made specimen carrying zipfs, vfs 1.4.2 and starkit together),
G-123 (these are punkbin candidates; kit-wrappability decides whether a runtime publishes
as a usable tier), G-125 (achieved - its gate learned the tcl<M>.<m>/ library convention so
such a kit can now be BUILT; making it BOOT is this goal), plus G-114 and G-127 as
deliberate non-overlaps - same file, different axes.
Also records in G-024 a design direction from the developer (non-contract Notes): the toml
move is where NAMED GROUPINGS of mapvfs entries should be considered, prompted by wanting
verification kits active but obviously not shipped products. Grouping would also give bake
and bakelist a name to select on beyond per-kit names, and the commented-out historical
entries somewhere honest to live.
Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com
