G-103: add tcltls to the bi-kit battery list (user-approved)

bi (batteries-included) kits should carry tcltls (core.tcl-lang.org/tcltls) as
a suite-built battery with a zig-built OpenSSL/LibreSSL backend. TLS is already
a consumer dependency (punk::imap4, punk::netbox) shipped today only as vendored
prebuilt binaries (tcltls1.7.23/tls2.0b2) - building it retires those and
advances G-004.

Recorded as a battery line, not a separate goal, and explicitly non-gating:
the crypto-backend build (the real work - no OpenSSL/LibreSSL in the tree yet)
lands when convenient; tcltls stays a vendored binary in the interim. Aim is
to validate the general build/test/kit processes, not rush a releasable product.
Notes capture the feasibility crux (thin extension over a crypto lib built under
zig-only) and the G-107 test-step follow-on.

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

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

@@ -2,7 +2,7 @@
 
 Status: proposed
 Scope: src/buildsuites/suite_tcl90/ (kit assembly steps in recipe/driver; pattern for later suites), src/vfs/_config + src/runtime/mapvfs.config (as consumers of the new runtime names), punkbin repo layout + metadata (c:/repo/jn/punkbin; compatible repos), src/scriptapps runtime scriptset (punk-runtime list/use - renamed under G-097, achieved 2026-07-21)
-Goal: buildsuites produce a defined FAMILY of runnable, self-contained runtime kits - executables whose info library and core batteries live in the initially attached zip, depending on no external filesystem tree: (1) a PLAIN tclsh kit carrying loadable Thread, tclvfs with as many vfs::* packages as we have, and tcllib+tcllibc; (2) a PUNK kit = the plain kit with the TCLSH_PIPEREPL patch applied and ENABLED BY DEFAULT (env opt-out, not opt-in - users wanting stock behaviour take the plain kit); (3) BI (batteries-included) punk kits additionally carrying libraries WE BUILD - Tk first; sqlite3/tdom/twapi as future build targets - all in the attached zip. These are the project's 'runtime' executables: punkbin candidates carrying metadata (variant, component versions, target platform, provenance) that runtime list/use subcommands can surface.
+Goal: buildsuites produce a defined FAMILY of runnable, self-contained runtime kits - executables whose info library and core batteries live in the initially attached zip, depending on no external filesystem tree: (1) a PLAIN tclsh kit carrying loadable Thread, tclvfs with as many vfs::* packages as we have, and tcllib+tcllibc; (2) a PUNK kit = the plain kit with the TCLSH_PIPEREPL patch applied and ENABLED BY DEFAULT (env opt-out, not opt-in - users wanting stock behaviour take the plain kit); (3) BI (batteries-included) punk kits additionally carrying libraries WE BUILD - Tk first; tcltls (with a zig-built OpenSSL/LibreSSL backend), sqlite3/tdom/twapi as future build targets - all in the attached zip. These are the project's 'runtime' executables: punkbin candidates carrying metadata (variant, component versions, target platform, provenance) that runtime list/use subcommands can surface.
 Acceptance: suite_tcl90 produces named artifacts for at least plain, punk, and one bi (+Tk) kit; each verified self-contained from a path with no external Tcl visible (info library resolves into the attached zip; package require checks for Thread, vfs + representative vfs::* packages, tcllib module + tcllibc acceleration engaged; bi adds Tk create/destroy) with the checks recorded here; the punk kit demonstrates piperepl active by default and disabled via the documented env opt-out, the plain kit demonstrates stock behaviour (no patch); artifact metadata (variant, versions, target, source provenance) is emitted alongside the binaries in the punkbin layout and surfaced by the runtime scriptset's list/use; the naming scheme for family members is documented, with piperepl-patched runtime executables carrying 'punk' in the name to distinguish them from unpatched (e.g tclsh905punk.exe - the tcl-patchlevel / punk-version / separator questions resolved and the decision recorded here) and mapvfs.config consuming the punk/bi runtimes under the decided names; the 8.6 family variant is explicitly deferred to the G-101 container investigation (static vfs / metakit patching questions).
 
 ## Context
@@ -163,3 +163,35 @@ contract the sequencing note promises G-101.
   goal's artifact metadata consumes: out/testreports/<lib>.summary line-records
   (result/totals/failednames/baseline/... ), shape documented in
   goals/archive/G-107-buildsuite-library-tests.md ("Evidence summary shape").
+- 2026-07-21 (user): bi kits should include tcltls
+  (https://core.tcl-lang.org/tcltls - fossil, same fetch pattern as
+  thread/tclvfs/tk) as a suite-BUILT battery. Current state: TLS is shipped
+  today ONLY as VENDORED PREBUILT binaries in kit .vfs payloads (tcltls1.7.22/
+  1.7.23 + tls2.0b2 dlls; punk9linux tcltls.so) - committed binaries G-004
+  wants gone - and it is a real consumer dependency already (punk::imap4,
+  punk::netbox both 'package require tls'). Building it as a family battery
+  replaces those prebuilts AND advances G-004.
+  FEASIBILITY (the crux - parallel to the twapi buildability question in
+  Context): tcltls itself is a thin C extension (tls.c/tlsIO.c compile under
+  zig cc like thread/tclvfs/tk), but it LINKS a crypto backend - upstream is
+  OpenSSL, with LibreSSL also supported. No OpenSSL/LibreSSL is in the tree
+  today, so the real work is building the crypto lib under the zig-only policy:
+  pragmatic paths are LibreSSL-portable (autoconf/cmake, no perl Configure) or
+  a no-asm OpenSSL, compiled with zig cc, then tcltls linked static against it
+  (mirrors the tcllibc/tk build shape). This is the LARGEST new build
+  dependency the family would take on - large enough it may warrant its own
+  sub-goal once scoped.
+  TEST (G-107): a suite-built tcltls gets a record-mode step (tcltls carries
+  its own tests/ suite) - the highest-value case here being zig-built
+  OpenSSL/LibreSSL + tcltls against a static tclsh, a combination nobody
+  upstream tests.
+  DECISION (user 2026-07-21): tcltls added to the Goal:'s bi-battery
+  enumeration (approved). Kept as a G-103 battery line - NOT a separate goal
+  and NOT gating any progress; a dedicated goal remains an option if the crypto
+  build proves large, but not now. The crypto-backend build lands when
+  convenient. In the interim tcltls STAYS a vendored binary (the existing
+  tcltls1.7.23 / tls2.0b2 kit payloads remain - consistent with G-004's
+  tolerance of existing vendored binaries pending their build story). Rationale:
+  the aim across this arc is to validate the general build/test/kit PROCESSES as
+  far as practical, not to rush a publicly releasable product - so a battery
+  whose backend build is heavy must not block the family scaffolding.