Browse Source

G-129 activated (user-directed): kit-boot mount-point derivation begins

Index entry + detail mirror flipped proposed->active. Activation-freshness
overlap survey (goals_xref score G-129) found one relationship drafted since
the goal was written: G-130 points here with no back-pointer - recorded as a
Related: note in the detail file.

Claude-Session: https://claude.ai/code/session_01UEgomWq6kA6c4A8GswqqGW
Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com
master
Julian Noble 4 days ago
parent
commit
59f14d8e46
  1. 2
      GOALS.md
  2. 6
      goals/G-129-kitboot-mountpoint-derivation.md

2
GOALS.md

@ -403,7 +403,7 @@ Detail: goals/G-127-crosstarget-vfs-bake.md
Scope: src/tools/punkres/ (vendored zig source - tool name settled in the work - with provenance and licence records); src/make.tcl (mechanism selection at the G-057 seam, sharing G-126's tool build step); bin/tools/zig* (pinned toolchain as consumed); bin/punkres.exe (untracked build output); src/tests/ (characterization - icon replaced, payload intact, idempotent, overlay-unsafe refusal); TEMP_REFERENCE/tcl-sfe (read-only reference for the resource structures)
Detail: goals/G-128-portable-pe-resource-stamping.md
### G-129 [proposed] Kit boot finds its payload wherever the archive mounted, not only at //zipfs:/app
### G-129 [active] Kit boot finds its payload wherever the archive mounted, not only at //zipfs:/app
Scope: src/vfs/_config/punk_main.tcl and src/vfs/_config/project_main.tcl (vfs capability detection plus mount-point derivation for the kit's internal module/lib path assembly - both carry the same code today); src/runtime/mapvfs.config (an active kit entry per verification runtime); bin/runtime/win32-ix86/ (the two third-party 32-bit runtimes that verify it - read-only input); src/tests/shell/testsuites/punkexe/ (characterization of the derivation); src/AGENTS.md + bin/AGENTS.md (what a runtime must provide to be kit-wrappable)
Detail: goals/G-129-kitboot-mountpoint-derivation.md

6
goals/G-129-kitboot-mountpoint-derivation.md

@ -1,6 +1,6 @@
# G-129 Kit boot finds its payload wherever the archive mounted
Status: proposed
Status: active
Scope: src/vfs/_config/punk_main.tcl and src/vfs/_config/project_main.tcl (vfs capability detection plus mount-point derivation for the kit's internal module/lib path assembly - both carry the same code today); src/runtime/mapvfs.config (an active kit entry per verification runtime); bin/runtime/win32-ix86/ (the two third-party 32-bit runtimes that verify it - read-only input); src/tests/shell/testsuites/punkexe/ (characterization of the derivation); src/AGENTS.md + bin/AGENTS.md (what a runtime must provide to be kit-wrappable)
Goal: a punk kit boots from wherever its attached archive actually mounted, so a runtime whose zipfs mounts at the executable's own path rather than at //zipfs:/app - as the androwish/undroidwish 8.6 backport does - yields a kit that finds its own modules and libs. The boot derives the mount point from the runtime's own mount list and detects zipfs by a command every generation provides, instead of keying on tcl::zipfs::root (a 9-era command absent from the 8.6 backport) and a compiled-in //zipfs:/app.
Acceptance: a kit baked from a runtime that mounts its attached archive at the executable's own path boots and resolves its own payload with no external package paths in play - the kit's internal modules/ and lib/ trees appear in tcl::tm::list and auto_path and a package that exists only inside the kit resolves - with bin/runtime/win32-ix86/tclsh8.6.10-luck-zip.exe recorded here as that verification runtime; a kit baked from bin/runtime/win32-ix86/tclsh9.1b0-tclsfe.exe (32-bit, modern //zipfs:/app convention) boots the same way, proving the 32-bit target itself needs nothing special and that the derivation did not regress the ordinary case; punkshell's existing 64-bit kits are unaffected, verified by comparing each kit's internal tcl::tm::list and auto_path entries before and after the change across at least one zipfs kit and one starkit-family kit (identical); a runtime that has an attached archive the boot cannot locate says so on stderr rather than continuing silently with no internal paths, which is today's failure shape; and the runtime requirements for kit-wrapping - which zipfs commands and mount conventions are supported - are documented in bin/AGENTS.md.
@ -129,6 +129,10 @@ the source tree, not from a kit payload - which is what made the gap easy to mis
from the service: `bin/runtime/win32-ix86/tclsh8.6.10-luck-zip.cfg` is the base64 build
request (output name, the 38 selected packages, apptext, cmdline) and `LUCK.url` names
the generator.
- Related: G-130 (back-pointer recorded at activation 2026-07-27, from the activation
overlap survey) - builds punkshell's own 32-bit runtimes from the buildsuites; the two
third-party win32-ix86 runtimes this goal verifies against are its comparison specimens,
and the "32-bit dimension" note below describes the interest that goal carries.
- The 32-bit dimension is wider than these two runtimes: the developer's standing interest
(recorded 2026-07-27) is 32-bit zig builds for punk, because old firewalled or sandboxed
systems - industrial ones especially - may carry tcl8-only or tcl9-only binary modules

Loading…
Cancel
Save