ck upgrade aborts at ck-subc-mcp restart-initiation on Windows: supervised restart refused (unknown_module) blocks all later component replacements

[Qiiks]

Environment

• Windows 11 IoT Enterprise LTSC 2024, x64
• Installed via ck installer: components at %LOCALAPPDATA%\cortexkit\bin (ck, ck-subc, ck-subc-mcp, ck-aft)
• Daemon registered as scheduled task CortexKit\subc-daemon (conhost --headless ck-subc.exe)
• subc.jsonc (%APPDATA%\cortexkit\subc.jsonc) supervises exactly one module: aft → ck-aft.exe

Observed

ck upgrade (0.14.1 → 0.17.5, resolved via the signed release index) plans 27 operations across ck-subc-mcp, ck-aft, ck-subc, ck. It aborts at operation 6:

evidence: ck-subc-mcp warm-execution: destination inode=bfe6eb01... executed successfully (0.1.0)
refusal: ck-subc-mcp restart-initiation failed: ck module restart ck-subc-mcp --drain-ms 30000 exited exit code: 1: unknown_module — module_id 'ck-subc-mcp' is not supervised

ck-subc-mcp is the standalone stdio MCP shim, not a supervised module, so ck module restart ck-subc-mcp can never succeed — the restart-initiation step refuses, and no later operation runs. Re-running ck upgrade reproduces identically (same inode re-warm-executed, binaries on disk unchanged, --version still 0.14.1). The upgrade plan has no path to completion on a Windows install where subc.jsonc does not supervise ck-subc-mcp.

Expected

Either (a) skip the supervised-restart step for components that are not supervised modules and rely on post-verify, or (b) continue the plan past a refused restart for a non-module component, reporting it as a warning. As shipped, the first upgrade a Windows alpha user attempts is a hard stop.

[subc-alfonso]

Confirmed from source, and it is not Windows-specific — every fresh ck setup install hits it, on any OS, the first time ck upgrade has something to do.

Two defects, one mechanism:

1. ck setup never writes a subc-mcp module entry (Component::Core has no module id; setup/model.rs:45), yet the upgrade planner unconditionally emits InitiateModuleRestart + PollModuleRestartCompletion for SubcMcp (setup/planner.rs:456). On a host that does not supervise the shim, that step can never succeed.
2. The restart passes target.label() — the binary name (ck-subc-mcp, ck-aft) — as the module id (setup/upgrade.rs:583), while the supervisor knows modules as aft / subc-mcp. Your run stopped at operation 6, so you never reached operation 12: ck module restart ck-aft refuses with the same unknown_module. Your (a) alone would have moved the hard stop one target later.

Why it shipped: the alpha matrix drives were zero-state installs, never a live upgrade, and the executor's tests run against a recording backend that cannot refuse on a module id. That is on us.

Fix (in progress): the planner consults the supervised roster at plan time and emits the restart pair only for targets whose module id is supervised on this host, using the module id rather than the binary name; an unsupervised target is verified by binary version after replacement and says so in the evidence line. Post-verification takes the same branch (it also asks the supervisor about the module today, so it would refuse next). Ships as subc-core 0.17.21 with a test that drives the planner against a roster that lacks subc-mcp and a roster that has it, and a live re-run of your exact sequence (0.14.1 → current) on a Windows VM before the tag.

[subc-alfonso]

Status: the fix is merged on master (56e9a66, merge 9c718c6) and the issue auto-closed on that merge; it is not released yet. subc-core-v0.17.21 tags once tip CI is green (the ubuntu leg is currently red on an unrelated pre-existing test, #93, fix in hand).

One thing to know when it lands: ck upgrade runs from the ck you already have, and ck replaces itself last in the ladder — so a 0.17.5 (or 0.14.1) ck will keep aborting at the shim step even after 0.17.21 is published. The remedy is to re-run the bootstrap installer once (irm https://cortexkit.io/install/win | iex; it is idempotent and replaces only ck), then ck upgrade. I will add that line to the release notes and confirm here after driving the sequence on a Windows VM.

[subc-alfonso]

Released. The fix is in subc-core-v0.17.28, published and served by the release index on all five targets (darwin-arm64, linux-x64, linux-arm64, windows-x64, windows-arm64). 0.17.21 through 0.17.27 never published: each stalled as a draft on a red Windows verify leg, so the index kept serving 0.17.5 until today.

Because ck upgrade runs from the ck you already have and replaces itself last, a ck older than this fix will still hit the refusal before it gets to itself. The path that works from any prior version is the one the release note states: re-run the bootstrap installer to get the new ck, then ck upgrade. Verified today from released bytes on macOS (0.17.26 → 0.17.28, daemon restarted under launchd) and Ubuntu ARM64 (0.17.5 → 0.17.28, daemon restarted under systemd --user); the Windows drive follows. The bootstrap re-run keeps setup's inventory rows now (0.17.25), so it no longer leaves ck upgrade believing the daemon is not installed.