fix(setup): inject docker-network service URLs into dashboard-api for diagnostics

[SSignall]

Summary

scripts/dream-test-functional.sh is run by POST /api/setup/test from the setup wizard's "Run Diagnostics" step. The script is executed inside the dashboard-api container, but its LLM_URL / TTS_URL / EMBEDDING_URL / WHISPER_URL defaults all point at http://localhost:<port>. Those defaults are correct for someone running the script on the host (where each service is published on 127.0.0.1:<port>), but inside the container localhost is the container's own loopback, so every test connect-refuses regardless of service health.

Symptom: setup wizard reports 0/3 passed, Some tests failed. even when LLM / TTS / Whisper are all healthy → "Complete Setup" stays disabled (disabled={!config.tested} in SetupWizard.jsx) and the user is stuck on the diagnostics screen.

Fix

Set the URLs explicitly on dashboard-api in docker-compose.base.yml, using docker network hostnames:

- LLM_URL=${LLM_URL:-http://llama-server:8080}
- TTS_URL=${TTS_URL:-http://tts:8880}
- EMBEDDING_URL=${EMBEDDING_URL:-http://embeddings:80}
- WHISPER_URL=${WHISPER_URL:-http://whisper:8000}

The script's existing ${VAR:-default} pattern picks these up. Host-side invocations of the script (e.g. for debugging) keep working as before via the unchanged localhost:<port> defaults.

Before / after on a live install (DGX Spark, GB10)

Before:

> Testing LLM Functional Generation
✗ LLM returned no response
> Testing TTS Audio Generation
✗ TTS returned HTTP 000
> Testing Embeddings Vector Generation
✗ Embeddings returned no response
Results: 0 passed, 3 failed
__DREAM_RESULT__:FAIL:1

After:

> Testing LLM Functional Generation
✓ LLM generates text (answer may vary)
> Testing TTS Audio Generation
✓ TTS generates audio file (72248 bytes)
> Testing Embeddings Vector Generation
✗ Embeddings returned no response          ← TEI amd64-only image, OOS
> Testing Whisper Transcription
✗ Whisper returned empty transcription     ← missing model, OOS
Results: 2 passed, 2 failed

LLM and TTS now correctly reflect actual health. The remaining two failures are real, separate bugs out of scope here:

• Embeddings: text-embeddings-inference does not publish an arm64 manifest, so dream-embeddings can't start on aarch64 hosts (already tracked as a follow-up to arm64 / NVIDIA Grace Blackwell support — partial #1129 #1130).
• Whisper: dream-whisper returns {"detail":"Model 'Systran/faster-whisper-large-v3' is not installed locally."} on this install — a model-provisioning issue separate from the diagnostic plumbing.

Test plan

• make lint
• docker compose ... config dashboard-api shows the four URLs on the merged config.
• Recreated dashboard-api on live install; POST /api/setup/test now produces the after-output above (LLM + TTS PASS).
• Reviewer with a healthy embeddings/whisper install confirms all four PASS.

🤖 Generated with Claude Code

[Lightheartdevs]

Thanks for tightening the setup diagnostics container URLs. I found one blocking routing issue in the new LLM_URL env.

docker-compose.base.yml now sets LLM_URL=${LLM_URL:-http://llama-server:8080} for dashboard-api, while the existing dashboard API env already sets OLLAMA_URL=${LLM_API_URL:-http://llama-server:8080}. That distinction matters: the installers intentionally write LLM_API_URL=http://litellm:4000 for AMD/Lemonade local mode and for non-local modes, because requests need to route through LiteLLM instead of directly to llama-server.

I rendered the compose config with GPU_BACKEND=amd and LLM_API_URL=http://litellm:4000; the result is:

OLLAMA_URL: http://litellm:4000
LLM_URL: http://llama-server:8080

So /api/setup/test would still run dream-test-functional.sh against http://llama-server:8080/v1/... in those modes, even though the rest of the dashboard/API stack is configured to use http://litellm:4000. For Lemonade specifically, the direct service path differs (/api/v1 behind the adapter path), so this can make setup diagnostics fail despite the configured LLM route being correct.

Please derive LLM_URL from LLM_API_URL when no explicit LLM_URL override is provided, for example by preserving a manual LLM_URL override but otherwise mirroring the same LLM_API_URL default used by OLLAMA_URL. A compose-render regression test for the AMD/LiteLLM case would be ideal here.

Local checks run:

• git diff --check origin/main...HEAD
• traced /api/setup/test to scripts/dream-test-functional.sh
• rendered docker compose ... config dashboard-api with LLM_API_URL=http://litellm:4000, which exposed the mismatch above