Description

Walking through nemoclaw onboard on v0.0.44 macOS while reading get-started/quickstart.html side-by-side surfaces four small but real doc-vs-product mismatches. None block onboarding, but together they make the docs untrustworthy as a first-read.

Environment

Device:        MacBook (M4)
OS:            macOS 26.1
Architecture:  arm64
Node.js:       v23.10.0
npm:           11.3.0
Docker:        27.4.0 (Colima)
OpenShell CLI: 0.0.39
NemoClaw:      v0.0.44
OpenClaw:      2026.4.24 (cbcfdf6)

Steps to Reproduce

1. Run nemoclaw onboard end-to-end while reading get-started/quickstart.html.

Mismatches Found

Issue 1 — Wizard prompt-order narrative misleading

The doc says: "After selection, you'll specify a model, sandbox name, and optionally enable web search and messaging channels".

This implies the order is: provider → model → sandbox name → web search → messaging.

Actual order: provider → key (if not exported) → model → sandbox name → REVIEW config + confirm → web search → messaging → network policy.

The Review block shown in the doc DOES say "Web search and messaging channels will be prompted next", but the lead-in sentence above it contradicts that.

Issue 2 — Curated model lists are stale

Option 1 (NVIDIA Endpoints) — doc lists 5 example models (Nemotron 3 Super 120B, GLM-5, MiniMax M2.7, GPT-OSS 120B, DeepSeek V4 Pro). Wizard actually offers 7 + Other. Missing from doc:

• Nemotron 3 Nano Omni 30B (nvidia/nemotron-3-nano-omni-30b-a3b-reasoning)
• Kimi K2.6 (moonshotai/kimi-k2.6)

Option 6 (Gemini) — doc names only gemini-2.5-flash. Wizard offers 6 + Other, including newer 3.x preview tier.

Doc uses "for example" so not strictly wrong, but the list looks months behind v0.0.44.

Issue 3 — Option 7 (Local Ollama) suffix not shown in doc example

Doc literal: 7) Local Ollama (localhost:11434)

Actual when ollama is running: 7) Local Ollama (localhost:11434) — running (suggested)

Doc narrative elsewhere mentions dynamic detection, but the literal example block hides the suffix.

Issue 4 — Privoxy / ollama-auth-proxy layer at :11435 not documented

Wizard banner reads: ✓ Using Ollama on localhost:11434 (proxy on :11435).

Implementation: a node ollama-auth-proxy.js binds 0.0.0.0:11435, validates a Bearer ollama-proxy token, forwards to 127.0.0.1:11434. No doc page explains:

• Why the :11435 proxy exists (sandbox-host reachability)
• That it uses Bearer-token auth and rejects unauthenticated requests
• How it interacts with host http_proxy env vars (NVB#6122435)

First-time users debugging "why ollama works in CLI but not from sandbox" need this in inference/use-local-inference.html or reference/troubleshooting.html.

Expected Result

• Quickstart narrative wording matches the actual prompt order (model → sandbox name → review → web search → messaging → policy).
• Provider-specific model lists either auto-update from the wizard catalog API, or quickstart drops the list and links to a "current catalog" doc.
• Option 7 example block shows the dynamic-detection suffix.
• A dedicated section (likely in inference/use-local-inference.html) explains the ollama-auth-proxy at :11435.

Actual Result

All four mismatches are present on the live docs as of 2026-05-18.

NVB#6187477