The owned-CUDA worker's packaging contract: no release asset, DLL-missing exe fails the acceptance probe at PE load, and no worker_bin default

[Qiiks]

The release contract for the owned-CUDA worker is incomplete in three linked ways, all verified on the same box that successfully runs the lane (RTX 4050, CUDA 13.2.1, driver API 13030):

1. verify_acceptance runs <exe> --version, but the exe dies at PE load without its DLL sidecars

The worker is built against CUDA 13 runtime DLLs (cudart64_13.dll, cublas64_13.dll, cublasLt64_13.dll). With the sidecars absent, ck-synapse-worker-cuda.exe --version exits 0xC0000135 (STATUS_DLL_NOT_FOUND) before main — no output, no version string. Reproduced by copying just the exe to an empty directory and running it.

So a release archive that ships the exe without the DLLs would abort ck setup synapse for every Windows user without a CUDA toolkit, at the version-probe step. Two possible fixes:

• Delay-load hardening: mark the CUDA DLLs delay-load so --version resolves before any CUDA symbol is needed (the exe's --version path touches none). This also makes the inert-worker assertion in the manual build gate exact instead of approximate.
• Ship the redist sidecars in the archive (the windows-owned-cuda-manual-gate already flattens the redist archives to build; the same step can package them).

These compose: delay-load makes the acceptance probe honest, sidecars make the lane actually run.

2. No release asset exists for the CUDA worker

v0.1.0-alpha.2 ships worker-llama, worker-ane, worker-decode — no worker-cuda. The release workflow's own comment says this is deliberate until "a CUDA build runner exists", but the manual gate (windows-owned-cuda-manual-gate) now produces exactly that artifact on a hosted runner (it needs nvcc from a redist download, which the gate already does). The remaining gap is packaging + inventory, blocked on decision 1 (sidecar contract) and the naming contract:

3. worker_bin / env is mandatory with no default resolution

Nothing looks beside the module binary for ck-synapse-worker-*, so even a user who unpacks a hypothetical archive must hand-set SYNAPSE_OWNED_CUDA_WORKER_BIN. I opened #12 with sibling resolution for the module side; the worker side (its worker_bin for owned-cuda entries) would follow the same pattern.

Suggested sequence

1. Delay-load hardening + sidecar packaging contract (small, unlocks 2 and the acceptance probe).
2. Ship worker-cuda in the Windows release matrix (the gate already builds it; needs the sidecar manifest from 1).
3. Sibling resolution (PR workers: resolve the worker binary beside the module when no explicit path is set #12 covers the module side; the same table extends if owned-cuda entries need their own resolution path).

Verified artifacts from this box available on request: the exit-code capture, the exact redist file list the gate flattens, and the working sidecar layout that makes the lane run.

[synapse-alfonso]

All three verified as stated, and the sequence you propose is the right one.

1. Delay-load hardening plus the sidecar packaging contract — take it as a PR. The windows-owned-cuda-manual-gate already flattens the exact redist set to build, so derive the packaging manifest from that step rather than hand-listing DLLs; a list maintained separately drifts the first time the pinned toolkit moves. Keep the inert-worker --version probe honest under delay-load: the assertion that --version succeeds off-PATH and the CUDA import fails on-PATH-absent is the thing that proves the sidecars are load-bearing, and delay-load must not turn the second half of it into a silent pass.
2. Shipping worker-cuda in the Windows release matrix — mine. Adding a CUDA lane to release.yml means a pinned toolchain in the release matrix and the siblings.lock reproducibility rules, and I want the manual gate green on dispatch a few more times before a release depends on it. I will do it once (1) lands.
3. Sibling resolution — workers: resolve the worker binary beside the module when no explicit path is set #12 is merged, so the module side is covered. If owned-cuda entries end up needing their own resolution path, extend the same table in worker_engine_names.rs.

Two facts worth carrying into (1): the checkpoint's embedding table is bf16, not f16 (the loader converts), and #15 has now been verified byte-identical on real hardware, so the packaging work lands on a lane whose vectors are pinned.