[tang-vu]

ods chat can report success even though the server returned an error or no answer. On Windows, native llama-server also requires a credential that the endpoint resolver returns but the chat command did not send. This change returns a nonzero exit code for HTTP/API failures and missing, empty, whitespace-only or non-string assistant text, and sends the configured native credential as an HTTP header. Successful answer text retains its surrounding whitespace.

The Windows command exits 1 through its existing command dispatcher. The macOS command returns 1 to the script. Neither path logs the credential or changes model/runtime configuration.

Validation at 9603f2655945954186567a5f56360b5ffeda2b74, based on current main c99f52822f2c37813fd880004f964ca83dfc5a35:

• The tests execute the complete shipped CLI and its actual endpoint resolver with a separate ODS_HOME and a loopback HTTP server. They no longer extract functions or stub the route resolver.
• Windows PowerShell 5.1: eight response cases plus one native-mode bearer-header case pass. The prior PR head failed ASCII whitespace, Unicode whitespace and native authentication. The ordinary response cases verify that no credential is attached to the Docker route.
• Native Mac Mini: all eight response cases pass. The prior PR head failed both whitespace cases. The same repaired Bash suite also passes under WSL.
• Real installed models: the complete repaired Windows CLI, pointed at the laptop's existing WSL-backed installation, and the complete repaired macOS CLI, pointed at the Mac Mini installation, each returned exactly ODS CLI LIVE 7877 with exit 0. These used candidate CLI files in isolated source locations; they did not replace installed files.
• Ruff E/F/W and git diff --check pass. Updated-head CI is required before merge.

Scope: the native Windows credential behavior is verified through the real resolver and an authenticated HTTP fixture. Strixy is unreachable, so this is not a physical Strixy/native-AMD model qualification. These CLI results do not establish fleet green or browser/Portal acceptance.

AI assistance: the original change and this fleet-driven repair used AI assistance. Codex ran and reviewed the tests under the owner's authorization, with bounded Tower2 review. Local review findings were checked against source and runtime evidence; no independent human review is implied.

[Lightheartdevs]

Thanks for making chat failures visible to scripts and adding real HTTP response coverage for both native CLIs.

Advisory status: not ready yet

Quickest path to merge:

• In ods/installers/windows/ods.ps1 (Invoke-Chat, around line 2538) and ods/installers/macos/ods-macos.sh (cmd_chat, around line 1363), reject whitespace-only content as well as zero-length strings. Both checks currently accept a nonempty string containing only whitespace, so automation still sees success with no visible answer. Using the PR's Windows HTTP harness, I reproduced exit 0 for both " " and "\n\t". Use [string]::IsNullOrWhiteSpace on Windows and a non-whitespace predicate in the jq filter on macOS, while printing the original successful content unchanged.
• Extend ods/tests/test-cli-chat-error-exit.py with those whitespace-only responses on both platforms; assert nonzero exit and the existing no-assistant-text diagnostic. Keep the successful-answer control.

What I checked:

• Diff, surrounding CLI response handling, repository conventions, and native Windows/macOS CI wiring at 2b66b2d72.
• Supplied HTTP test: Windows passed all five scenarios; macOS was skipped locally on Windows. Additional Windows HTTP probes reproduced the whitespace gap and confirmed null/numeric content is rejected.
• All 79 hosted checks were successful at inspection. The remaining finding is a behavior gap outside the current fixtures.