punkshell

1248 Commits

1 Branch

1 Tag

216 MiB

Commit Graph

Author	SHA1	Message	Date
Julian Noble	b7c632b670	G-125 achieved: a kit that cannot boot is not deployed (punkshell 0.27.0) The kit machinery already knew when it had failed to extract anything from a source runtime, and under G-122 that notice became a recapped BUILD-WARNING - but the build still assembled an artifact, DELETED the deployed kit and copied the new one over it, closing running instances of the kit first. Field-observed 2026-07-26: an msys2-hosted bake of punk91 produced a 49,501,792-byte bin/punk91.exe that failed at startup with "application-specific initialization failed: Cannot find a usable init.tcl", by which point the previously working kit was already gone. G-124 removed the particular cause; this removes the class. A build tool should not make a working executable worse. A bake now refuses any kit whose merged .vfs supplies no tcl library: the kit is listed under FAILED KITS with a reason naming the cause and NOTHING is written - no src/_build/<kit>, no deploy, and the previously deployed bin/<kit> is left byte-identical. The gate sits immediately after the _vfscommon.vfs + <kit>.vfs merges and before the kit-type assembly switch, the last point at which no build product exists; a refusal appends to failed_kits, ends the punkcheck event FAILED and continues, so the punkcheck records stay consistent with what is on disk. The merged src/_build/<kit>.vfs tree is deliberately left behind - it is the evidence for the refusal. It gates on the BOOT PRECONDITION, not on the extraction step having run. Some .vfs folders legitimately supply their own tcl library (src/vfs/punk8_statictwapi.vfs, punk9test.vfs and mkzipfix.vfs do today), and those must keep building - so the check reads the merged tree. It is structural and executes nothing, which also makes it valid for cross-target kits this host could never run, and costs 0.63ms per kit (measured over 200 iterations against the real src/_build/punk905.exe.vfs), so it runs unconditionally. The predicate is punkboot::utils::vfs_boot_library_report (0.2.0 -> 0.3.0), called through a guarded require modelled on the existing get_src_provenance_warnings: a stale or missing bootsupport snapshot degrades the gate to a NOTE rather than failing every kit. Both branches were observed live - before the bootsupport propagation 'make.tcl check' reported UNAVAILABLE, after it ACTIVE. Scope was extended at activation (user-approved) to put the predicate in that module rather than private to the build script, because a gate that cannot be exercised cannot be characterized, and punkboot::utils is already where make.tcl's provenance gate helper lives. What qualifies as a tcl library: tcl_library/init.tcl (zipfs-attached kits) or lib/tcl<major>.<minor>/init.tcl (starkit-style), AND at least one companion file beside it (tm.tcl, package.tcl, auto.tcl, clock.tcl, history.tcl, word.tcl) or an encoding/ directory. The companion test is load-bearing: every punkshell kit carries lib/BWidget1.10.1/init.tcl, so a check that looked for any init.tcl anywhere would pass a kit with no tcl library at all. lib/tcllib2.0 is correctly not matched by the lib/tcl[0-9]* glob. Verified against all 10 assembled trees in src/_build - both conventions are represented (tcl_library for punk902z/punk905/punk91/punk9_beta/punk9bi_beta/punkmagic, lib/tcl8.6 for punk86/punkbi/punksys, lib/tcl9.0 for punkshell902). The no-extraction BUILD-WARNING was reworded from "will not initialise unless src/vfs/<x> supplies one" - a consequence the build then ignored - to "will FAIL the boot-precondition gate unless src/vfs/<x> supplies one". It stays a warning rather than becoming the failure, because a .vfs that supplies its own library needs no extraction. Verified 2026-07-27 end-to-end against a temporary fixture kit (a mapvfs entry pointing a zip kit at a payload-free runtime, plus a vfs with no tcl library), with sentinel files standing in for a previously deployed kit and a previous build product. Across the failing run bin/punkgatefixture.exe (sha1 2a0700eb...) and src/_build/punkgatefixture.exe (sha1 12c50567...) were byte-identical with unchanged mtimes, and the kit was reported under FAILED KITS with the cause named. Adding tcl_library/{init.tcl,tm.tcl} to that same fixture vfs - extraction still yielding nothing - made it build and deploy normally, which is the other half of the criterion. The fixture was removed afterwards and mapvfs.config restored byte-identical to its backup. Real-kit bake through the gate: punk905 builds, deploys and boots. Characterization: 12 tests in modules/punkboot/utils/testsuites/utils/bootlibrary.test (both conventions, the companion-file requirement and its BWidget decoy, near-miss reporting, missing/empty trees, and a sweep asserting every assembled src/_build/*.vfs tree still passes so the gate cannot fail kits that boot today) and 2 in shell/testsuites/punkexe/maketclbootgate.test (the ACTIVE/UNAVAILABLE report, ESC-free per the G-113 piped policy). Existing punkexe suites pass unchanged. Documented in src/AGENTS.md with the remedy when a kit is refused, in ARCHITECTURE.md beside the provenance gates, and in the embedded 'make.tcl workflow' data flow as key note K10 (verified under the default and PUNKBOOT_PLAIN=1 paths, within the 100-column budget). The achieved flip archives the entry and the detail file, and sweeps the live tier: G-127 (its output location inherits the never-written guarantee as long as the gate stays upstream of the artifact write, and its payload/target mismatch reporting should share this vocabulary), G-028 (the sibling "why bin/<kit> was not updated" surface in the same deploy step) and G-101 (a new container type must land its library where the gate looks, or extend the location list). Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com	2 weeks ago

Author

SHA1

Message

Date

Julian Noble

b7c632b670

G-125 achieved: a kit that cannot boot is not deployed (punkshell 0.27.0)

The kit machinery already knew when it had failed to extract anything from a source
runtime, and under G-122 that notice became a recapped BUILD-WARNING - but the build
still assembled an artifact, DELETED the deployed kit and copied the new one over it,
closing running instances of the kit first. Field-observed 2026-07-26: an msys2-hosted
bake of punk91 produced a 49,501,792-byte bin/punk91.exe that failed at startup with
"application-specific initialization failed: Cannot find a usable init.tcl", by which
point the previously working kit was already gone. G-124 removed the particular cause;
this removes the class. A build tool should not make a working executable worse.

A bake now refuses any kit whose merged .vfs supplies no tcl library: the kit is listed
under FAILED KITS with a reason naming the cause and NOTHING is written - no
src/_build/<kit>, no deploy, and the previously deployed bin/<kit> is left byte-identical.
The gate sits immediately after the _vfscommon.vfs + <kit>.vfs merges and before the
kit-type assembly switch, the last point at which no build product exists; a refusal
appends to failed_kits, ends the punkcheck event FAILED and continues, so the punkcheck
records stay consistent with what is on disk. The merged src/_build/<kit>.vfs tree is
deliberately left behind - it is the evidence for the refusal.

It gates on the BOOT PRECONDITION, not on the extraction step having run. Some .vfs
folders legitimately supply their own tcl library (src/vfs/punk8_statictwapi.vfs,
punk9test.vfs and mkzipfix.vfs do today), and those must keep building - so the check
reads the merged tree. It is structural and executes nothing, which also makes it valid
for cross-target kits this host could never run, and costs 0.63ms per kit (measured over
200 iterations against the real src/_build/punk905.exe.vfs), so it runs unconditionally.

The predicate is punkboot::utils::vfs_boot_library_report (0.2.0 -> 0.3.0), called through
a guarded require modelled on the existing get_src_provenance_warnings: a stale or missing
bootsupport snapshot degrades the gate to a NOTE rather than failing every kit. Both
branches were observed live - before the bootsupport propagation 'make.tcl check' reported
UNAVAILABLE, after it ACTIVE. Scope was extended at activation (user-approved) to put the
predicate in that module rather than private to the build script, because a gate that
cannot be exercised cannot be characterized, and punkboot::utils is already where
make.tcl's provenance gate helper lives.

What qualifies as a tcl library: tcl_library/init.tcl (zipfs-attached kits) or
lib/tcl<major>.<minor>/init.tcl (starkit-style), AND at least one companion file beside it
(tm.tcl, package.tcl, auto.tcl, clock.tcl, history.tcl, word.tcl) or an encoding/
directory. The companion test is load-bearing: every punkshell kit carries
lib/BWidget1.10.1/init.tcl, so a check that looked for any init.tcl anywhere would pass a
kit with no tcl library at all. lib/tcllib2.0 is correctly not matched by the lib/tcl[0-9]*
glob. Verified against all 10 assembled trees in src/_build - both conventions are
represented (tcl_library for punk902z/punk905/punk91/punk9_beta/punk9bi_beta/punkmagic,
lib/tcl8.6 for punk86/punkbi/punksys, lib/tcl9.0 for punkshell902).

The no-extraction BUILD-WARNING was reworded from "will not initialise unless src/vfs/<x>
supplies one" - a consequence the build then ignored - to "will FAIL the boot-precondition
gate unless src/vfs/<x> supplies one". It stays a warning rather than becoming the failure,
because a .vfs that supplies its own library needs no extraction.

Verified 2026-07-27 end-to-end against a temporary fixture kit (a mapvfs entry pointing a
zip kit at a payload-free runtime, plus a vfs with no tcl library), with sentinel files
standing in for a previously deployed kit and a previous build product. Across the failing
run bin/punkgatefixture.exe (sha1 2a0700eb...) and src/_build/punkgatefixture.exe (sha1
12c50567...) were byte-identical with unchanged mtimes, and the kit was reported under
FAILED KITS with the cause named. Adding tcl_library/{init.tcl,tm.tcl} to that same fixture
vfs - extraction still yielding nothing - made it build and deploy normally, which is the
other half of the criterion. The fixture was removed afterwards and mapvfs.config restored
byte-identical to its backup. Real-kit bake through the gate: punk905 builds, deploys and
boots.

Characterization: 12 tests in modules/punkboot/utils/testsuites/utils/bootlibrary.test
(both conventions, the companion-file requirement and its BWidget decoy, near-miss
reporting, missing/empty trees, and a sweep asserting every assembled src/_build/*.vfs
tree still passes so the gate cannot fail kits that boot today) and 2 in
shell/testsuites/punkexe/maketclbootgate.test (the ACTIVE/UNAVAILABLE report, ESC-free per
the G-113 piped policy). Existing punkexe suites pass unchanged.

Documented in src/AGENTS.md with the remedy when a kit is refused, in ARCHITECTURE.md
beside the provenance gates, and in the embedded 'make.tcl workflow' data flow as key note
K10 (verified under the default and PUNKBOOT_PLAIN=1 paths, within the 100-column budget).

The achieved flip archives the entry and the detail file, and sweeps the live tier: G-127
(its output location inherits the never-written guarantee as long as the gate stays
upstream of the artifact write, and its payload/target mismatch reporting should share this
vocabulary), G-028 (the sibling "why bin/<kit> was not updated" surface in the same deploy
step) and G-101 (a new container type must land its library where the gate looks, or extend
the location list).

Assisted-by: harness=claude; primary-model=claude-opus-5[1m]; api-location=anthropic.com

2 weeks ago

1 Commits (9065232e82657c0f12b304ba4500b47bbb97ffb2)