G-101 increment 2: sdx circularity broken (option (a) verified)

sdx.kit runs under the suite-built tclsh86t with NO tclkit in the chain:
starkit 1.3.3 + vfs::mk4 1.10.1 resolve from the suite-installed
lib/vfs1.4.2 (tclvfs trunk ships both scripts - the fact the 2026-07-26
survey missed), Mk4tcl 2.4.9.8 is the increment-1 fork-built battery, and
the wrap surface is proven not just the launch: qwrap WROTE an mk4 kit,
lsk/unwrap read it back, and the wrapped kit itself runs under tclsh86t
mounted at its own path. Goal detail: sdx-section RESOLVED marker +
Progress increment 2 with follow-on items (make.tcl suite-shell rung;
-runtime path waits on the kit-capable head).

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

goals/G-101-tcl86-kit-container-strategy.md

@@ -230,6 +230,30 @@ suite_tcl86 now builds the mk4 candidate's loadable shape from the pinned fork.
   Mk4tcl:2.4.9.8 in BOTH shells (tclsh86t dynamic AND tclsh86ts static)
   alongside Thread/vfs/registry/dde/Tk.
 
+Increment 2 landed 2026-08-02: the sdx BOOTSTRAP CIRCULARITY is broken -
+option (a) from the sdx section verified end-to-end under the suite stack,
+hermetic env (TCLLIBPATH/TCL_LIBRARY/TM_PATH vars unset):
+
+- `tclsh86t.exe bin/sdx.kit` prints the full command list: the kit's header
+  (`package require starkit; starkit::header mk4 -readonly`) resolved starkit
+  1.3.3 and vfs::mk4 1.10.1 from the suite's OWN lib/vfs1.4.2 (tclvfs trunk
+  ships both scripts - the survey fact this goal was missing), loaded the
+  increment-1 Mk4tcl 2.4.9.8, mounted the kit and ran app-sdx from inside it.
+- Wrap surface proven, not just launch: `sdx qwrap hello.tcl` WROTE hello.kit
+  (mk4 commit path through the fork-built dll), `sdx lsk` listed it,
+  `sdx unwrap` extracted the tree, and hello.kit itself RUNS under tclsh86t -
+  its script reports `info script` inside hello.kit/lib/app-hello/ and
+  `vfs::filesystem info` shows the kit path mounted.
+- Chain provenance: every piece suite-built or fork-built (shell, tclvfs dll +
+  scripts, Mk4tcl) except sdx.kit itself (the tracked 2011-era tool, its
+  provenance already captured in patches/). No third-party tclkit anywhere.
+
+Follow-on items this creates (not yet landed): make.tcl's sdx resolution
+ladder (:5048-5097) can gain a suite-shell rung ending the tclkit dependency
+for 'kit' bakes on this machine class; the sdx -runtime path (executable-head
+wrapping) still needs the kit-capable HEAD this goal's demonstration arm will
+build, and stays unexercised until then.
+
 Remaining for acceptance: the candidate-container assessments recorded against
 the kit expectations (mk4 / cookfs / zipvfs-over-tclvfs, with the
 zipfs-backport arm's bearing); one strategy demonstrated end-to-end (kit
@@ -355,6 +379,17 @@ concrete enough to shape acceptance.
   (b) replace sdx's wrap step with a suite-owned writer (setupvfs.tcl above is
   the reference for what writing a kit actually requires). Option (a) is the
   cheaper first probe and also tests whether a suite-built Mk4tcl works at all.
+  RESOLVED 2026-08-02 (Progress increment 2): option (a) VERIFIED - sdx runs
+  under the suite-built tclsh86t with no tclkit anywhere in the chain, and the
+  wrap surface works (qwrap wrote an mk4 kit, lsk/unwrap read it back, and the
+  wrapped kit RUNS under tclsh86t, mounted at its own path). The enabling fact
+  the 2026-07-26 survey missed: tclvfs TRUNK ships the script half itself -
+  the suite's installed lib/vfs1.4.2 carries starkit.tcl (starkit 1.3.3) and
+  mk4vfs.tcl (vfs::mk4 1.10.1) beside the dll, so the suite prefix plus the
+  increment-1 Mk4tcl battery is the COMPLETE sdx host stack. The Context
+  chicken-and-egg (bootstrapping vfs from INSIDE a container) now applies
+  only to the kit-boot arm, not to the wrapping tool. Follow-on recorded in
+  Progress: teach make.tcl's resolution ladder the suite-shell rung.
 - STALE WRAPPER: `bin/sdx1.bat` (and its `TEMP_REFERENCE/sdx/sdx.bat` twin)
   invokes `%~dp0..\src\runtime\tclkit86bi.exe`, a path that no longer exists -
   runtimes moved to `bin/runtime/<os-arch>/`. bin/ has no `sdx` wrapper under