fix: address the fourth review round

- The LM Studio recreate snippet now shows both Compose assignments instead of
  describing the alternative in a comment.
- `sim-setup logs` on a source checkout prints where the logs are rather than
  following a stream; the table said it follows.
- The GKE BackendConfig annotation targeted `<release>-realtime`, but the chart
  names the Service `<fullname>-realtime` — and the fullname is `<release>-sim`
  unless the release name already contains `sim`. It now selects by the release
  and component labels, which holds for either.
- The Helm `NO_PROXY` example listed only the `.svc` suffixes, which match none
  of the bare Service names the chart wires into `SOCKET_SERVER_URL`,
  `PII_URL`, and `OLLAMA_URL`. Those requests would still have gone to the
  proxy.
- `sim-setup` detects only the production and local Compose files, so an
  Ollama-stack install is invisible to it. The upgrade section now says so and
  gives the direct commands.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015BwsJTEQRzWJaY4BRCkPZt

Author: waleedlatif1

apps/docs/content/docs/platform/self-hosting/docker.mdx

@@ -154,9 +154,9 @@ VLLM_API_KEY=your_lm_studio_api_token
 Both the server root shown above and a URL ending in `/v1` are accepted. After recreating the `simstudio` service, its models appear in the model picker with a `vllm/` prefix; Sim removes that prefix before sending the model identifier to LM Studio.
 
 ```bash
-# Use the file that started your install — docker-compose.ollama.yml if you
-# started from the Ollama stack.
+# Pick the file that started your install.
 COMPOSE_FILE=docker-compose.prod.yml
+# COMPOSE_FILE=docker-compose.ollama.yml
 docker compose -f "$COMPOSE_FILE" up -d --force-recreate simstudio
 ```
 
@@ -168,7 +168,7 @@ docker compose -f "$COMPOSE_FILE" up -d --force-recreate simstudio
 |---|---|
 | `sim-setup` | The setup wizard. `--quick` skips the prompts, `--dir <path>` picks the directory, `--mode compose\|dev\|k8s` picks the target (`dev` and `k8s` need a source checkout) |
 | `sim-setup status` | Show what is installed and healthy |
-| `sim-setup logs` | Follow logs |
+| `sim-setup logs` | Follow logs. On a source checkout it prints where the logs are — the dev server streams in its own terminal — rather than following a stream |
 | `sim-setup start` / `stop` / `restart` | Bring the install up, down, or cycle it |
 | `sim-setup update` | Pull or rebuild images and apply them. Compose installs only — it refuses on source checkouts and Kubernetes, which update through git and `helm upgrade` |
 | `sim-setup down` | Remove containers, keep the data |

apps/docs/content/docs/platform/self-hosting/networking.mdx

@@ -229,7 +229,8 @@ spec:
 Then annotate the realtime Service so the load balancer picks it up. The chart renders no annotations on any Service, and `realtime.service` accepts only `type`, `port`, and `targetPort` — an annotations key there is silently dropped. Annotate the Service directly:
 
 ```bash
-kubectl annotate service <release>-realtime -n <namespace> \
+kubectl annotate service -n <namespace> \
+  -l app.kubernetes.io/instance=<release>,app.kubernetes.io/component=realtime \
   cloud.google.com/backend-config='{"default": "sim-realtime-backendconfig"}'
 ```
 
@@ -329,13 +330,13 @@ The practical consequence: a mandatory-egress-proxy environment can route most L
 <Callout type="info">
   Set `NO_PROXY` for every destination that is not on the public internet, not just model endpoints. The app reaches the realtime server (`SOCKET_SERVER_URL`), the Presidio PII service (`PII_URL`), and itself (`INTERNAL_API_BASE_URL`) over the same default `fetch`, alongside self-hosted Ollama, LiteLLM, and vLLM — so a proxy that cannot reach your internal network breaks live updates and PII redaction, not only inference.
 
-  Set it in the application environment, not your shell — under `app.env` on Helm, or the service's `environment:` on Compose. The cluster suffix covers every Service whatever the release is named:
+  Set it in the application environment, not your shell — under `app.env` on Helm, or the service's `environment:` on Compose. On Helm the suffixes alone are not enough: the chart wires `SOCKET_SERVER_URL`, `PII_URL`, and `OLLAMA_URL` to bare Service names, which no domain suffix matches. Add those names too — `helm template` prints the rendered ones, and the prefix is the release name unless it already contains `sim`, in which case it is the release name alone:
 
   ```yaml
-  # Helm
+  # Helm — for a release named `acme`
   app:
     env:
-      NO_PROXY: "localhost,127.0.0.1,.svc,.svc.cluster.local"
+      NO_PROXY: "localhost,127.0.0.1,.svc,.svc.cluster.local,acme-sim-realtime,acme-sim-pii,acme-sim-ollama"
   ```
 
   ```yaml

apps/docs/content/docs/platform/self-hosting/upgrades.mdx

@@ -193,6 +193,13 @@ install uses:
 
 Inspect the result with `npx sim-setup logs`, which targets whichever Compose file the install uses.
 
+The CLI detects only those two files. An install started from `docker-compose.ollama.yml` is invisible to it — `update`, `logs`, and `status` all report no install — so upgrade that stack directly:
+
+```bash
+docker compose -f docker-compose.ollama.yml pull
+docker compose -f docker-compose.ollama.yml up -d
+```
+
 <Callout type="warn">
   `sim-setup update` refuses two install kinds outright rather than doing something surprising: