* fix(cookbook): record real Windows pid for local serve so Stop kills the model
The Windows-local serve runner recorded Git Bash's `$$`, which is the
MSYS/Cygwin pid, not the Windows pid. Win32 tooling (taskkill,
Get-CimInstance ParentProcessId, Stop-Process) can't match an MSYS pid, so
the frontend Stop-Tree walk found nothing and the llama-server child survived
after Stop, leaving the model loaded and the GPU pinned.
Record the serving shell's true Win32 pid via `/proc/$$/winpid`, falling back
to the outer proc.pid already written from Python when the map is unavailable.
The existing pid-tracking test asserted the buggy `$$` literal at the source
level, so it passed while the feature was broken; update it to the winpid
behavior and add a focused regression test.
* fix(cookbook): make Windows serve pid handoff deterministic
---------
Co-authored-by: Alexandre Teixeira <111787685+alteixeira20@users.noreply.github.com>
Co-authored-by: Alexandre Teixeira <alexandremagteixeira@gmail.com>
* fix(cookbook): prefer native llama-server on local Windows
* fix(cookbook): harden local llama-server launch commands
* fix(cookbook): build serve commands for selected target
list_packages() probes each optional package with importlib.import_module() but
only caught ImportError / PackageNotFoundError. A package that is installed yet
raises a different exception on import took down the whole panel with a 500,
surfaced in the UI as "Error loading packages: Unexpected token 'I', ...".
Concrete Windows case: a CUDA build of llama-cpp-python runs
os.add_dll_directory(r"...\CUDA\v12.3\bin") at import and raises FileNotFoundError
when that toolkit dir is absent. Catch any exception during the import probe and
report the package as not-installed instead of failing the entire request.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
