Batched punkcheck-managed build outputs from make.tcl modules/bootsupport/
vfscommonupdate for the G-133 change-set: bootsupport and _vfscommon.vfs gain
utils-0.5.0.tm (0.4.0 pruned), thin-layout make.tcl copies and the modpod
templates payload re-synced.
Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com
Regenerated by 'make.tcl modules' + 'bootsupport' + 'vfscommonupdate'. The thin-layout
make.tcl copies and the templates modpod carry ::punkboot::replace_possibly_mapped_file and
::punkboot::mapped_file_hint, so generated projects get the same behaviour - a project whose
own bootsupport carries a zip-based .tm meets exactly the same windows constraint.
Note the templates modpod copy in this commit was itself replaced by the new delete-then-
place path: the bootsupport run reported "in-place overwrite refused - replaced by
delete-then-place" and completed, where the previous three runs this session failed and
needed a hand copy. The fix was exercised by the change-set that introduced it.
Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com
Regenerated by 'make.tcl modules' + 'bootsupport' + 'vfscommonupdate'. make.tcl reaches
the predicate through a guarded require against the bootsupport snapshot, so the third
tcl-library convention only takes effect for a bake once this lands; 'make.tcl check'
confirms the gate ACTIVE and now names all three locations.
The thin-layout make.tcl copies and the templates modpod carry the reworded K10 key note,
so generated projects describe the gate the same way.
The bootsupport templates modpod again failed to copy in place with 'invalid argument' and
again succeeded on retry seconds later - the transient lock noted in the previous two
build-output commits, not a make.tcl mount this time. Copied by hand, then 'make.tcl
bootsupport' and 'vfscommonupdate' re-run to reconcile; all three copies share one sha1.
Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com
Regenerated by 'make.tcl modules' + 'bootsupport' + 'vfscommonupdate' for the G-125
change. make.tcl loads punkboot::utils from bootsupport through a guarded require, so the
boot-precondition gate only becomes ACTIVE once the snapshot carries
vfs_boot_library_report - before this propagation 'make.tcl check' correctly reported the
gate UNAVAILABLE.
The thin-layout make.tcl copies and the templates modpod pick up the gate and the K10
workflow key note, so generated projects get the same refusal behaviour.
The bootsupport templates modpod again could not be replaced in place - 'BOOTSUPPORT
module update FAILED: ... templates-0.2.0.tm (invalid argument)'. Unlike the G-124
occurrence a plain tclsh failed on the first attempt too and succeeded on a retry moments
later, which points at a transient lock by one of the running shells rather than at
make.tcl having the file mounted. Copied by hand, then 'make.tcl bootsupport' re-run to
reconcile the punkcheck record.
Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com
Regenerated by 'make.tcl modules' + 'bootsupport' + 'vfscommonupdate' for the G-124
change. make.tcl loads punk::zip from bootsupport, so the reader only reaches the
zipfs-less bake path once the snapshot carries it.
Also carries two version propagations pending from earlier work, not authored here:
punk 0.2.7 -> 0.2.8 and punk::platform 0.1.0 -> 0.2.0 (the latter was added to
include_modules.config in 5c1e6927 but never snapshotted). Their source buildversion
files are unchanged by this change-set.
The templates modpod is rebuilt because the layout make.tcl inside it changed. Note for
next time: 'make.tcl bootsupport' cannot replace a bootsupport modpod that the running
make.tcl has itself mounted - it failed twice with 'BOOTSUPPORT module update FAILED:
... templates-0.2.0.tm (invalid argument)' while a plain tclsh copied the identical file
without complaint. Copied by hand, then re-run to reconcile the punkcheck record.
Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com
make.tcl bootsupport pulled the newly-included punk::platform; the templates
modpod refresh used the established virgin-tclsh direct copy (cd6aec8f
precedent) because the in-process punkcheck copy fails while the running
interp holds the target modpod mounted ("invalid argument") - snapshot now
byte-identical to the built modules/punk/mix/templates-0.2.0.tm (carries the
G-121-era layout make.tcl payload).
Claude-Session: https://claude.ai/code/session_01Jz7wkUsknJzyuJ3tgMaL2t
Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com
The stale copy (2026-07-19 20:55 build) survived three make.tcl bootsupport
runs: two in-session runs failed the copy with 'invalid argument' (destination
held open - a running shell's zipfs mount on the bootsupport modpod, the
G-087-era self-lock class) and the user's post-shell-close rerun left it
untouched (cause unobserved - if that run reported no copy attempt rather
than a failure, the punkcheck staleness records having absorbed the earlier
failed attempts would be worth noting for G-094). Direct file copy from the
current root modules build (22:13, md5 b1226b3d) succeeded once the lock was
gone; bootsupport now matches root modules and _vfscommon.vfs (already fresh
via the earlier vfscommonupdate).
Claude-Session: https://claude.ai/code/session_01BNUVVkYq9vHa6G3S9a3XTZ
Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com
Julian Noble