feat(inference): add Linux Muse and Lightning profiles

Add explicit-only Linux amd64 catalog presets and recipes for Muse Glimmer 30B.

Add a matching Nemotron 3.5 Lightning profile.

Cover direct selection, architecture and memory rejection, runtime floors, and Spark precedence.

Refs #9673

Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>

Author: prekshivyas

.agents/skills/_shared/code-change-considerations.md

@@ -17,22 +17,13 @@ recording them here.
 
 - What accepted outcome and current consumer require the change?
 - What current code owns the behavior, and can that owner be extended directly?
-- What current code, branch, parameter, owner, fixture, or file becomes unnecessary and can be
-  deleted or merged in this change?
 - Would the change duplicate an existing structure or create another source of truth?
-- Can the completed source-and-test change be neutral or negative in total lines? If not, what
-  current correctness, security, or accepted-scope contract requires the growth?
-- If the change adds a helper, abstraction, configuration, registry, fallback, or compatibility
-  path, which current consumers adopt it now, what old structure does it remove, and is the whole
-  result smaller or simpler?
 - What state, success, failure, and partial-failure behavior must remain coherent?
 - What ordering or concurrency can change the result or bypass a guarantee?
 - How do absent values, defaults, retries, recovery, and cleanup behave?
 - Which alternate entry, error, cached, resumed, or compatibility paths can bypass the change?
 - Can code or configuration be removed, or can an existing or native mechanism replace new code?
 - What shortest stable test proves the changed behavior, including the relevant negative path?
-- Can that evidence extend or consolidate current fixtures, matrices, and assertions instead of
-  creating another test owner or a one-use test helper?
 - Does a real process, network, filesystem, container, hardware, or service boundary require deeper
   runtime or end-to-end evidence?
 - Which active issues, pull requests, or recent changes overlap, conflict, or affect delivery order?

.agents/skills/nemoclaw-contributor-implement-issue/SKILL.md

@@ -80,25 +80,13 @@ checked for that operation or failure class and the sensitive-workflow state out
 hold. Then make the direct change in the current behavior owner. Do not add speculative abstractions,
 configuration, compatibility, migration, or fallback behavior.
 
-Optimize the complete source-and-test change for deletion and consolidation. Compare a direct edit,
-reuse of an existing owner, and a refactor of current related code. Prefer a neutral or negative
-total line delta. Add a helper, abstraction, configuration surface, registry, fallback, or
-compatibility path only when current consumers adopt it in this change and the complete result
-removes more owners, concepts, branches, or lines than it adds. Possible future reuse is not enough.
-When a current correctness, security, or accepted-scope contract requires growth, keep the design
-direct and record why deletion or reuse cannot satisfy it.
-
 Add focused evidence as applicable:
 
 - positive behavior that must succeed;
 - negative or denied behavior that must fail;
 - error, interruption, recovery, or cleanup behavior;
 - boundary values, ambiguous state, and alternate entry paths.
 
-Preserve semantic regression coverage, not every existing fixture or assertion block. Extend or
-table-drive current coverage when that keeps one setup and one behavior owner. Do not create a
-one-use test helper, parallel matrix, or second test file merely to shorten an individual test.
-
 State why an evidence category does not apply when omission could hide risk. Use runtime or end-to-end
 evidence only when the real process, filesystem, network, container, hardware, workflow, or service
 boundary owns the behavior. Run focused tests after the final behavior-affecting edit and record the
@@ -115,11 +103,6 @@ Consideration and all nine Security Rubric categories to the completed behavior.
 security control and focused negative evidence that proves forbidden behavior remains denied. If no
 security control changed, state why and cite the reviewed trust boundaries.
 
-Record the reduction case for the completed design: the current code, owners, branches, parameters,
-fixtures, or files deleted or consolidated and the total source-and-test line direction. If the
-change grew, identify the current contract that requires that growth. Remove review-driven machinery
-when a direct solution is smaller; do not add another layer to compensate for an avoidable layer.
-
 Confirm that allowed, denied, error, and boundary behavior remains coherent across failure, retry,
 cleanup, cached, resumed, and compatibility paths that apply.
 Re-check the recorded operation and failure class, sibling paths, and sensitive-workflow state
@@ -138,7 +121,6 @@ Use this structure:
 - Accepted scope authority:
 - Delivered capability:
 - Changed behavior:
-- Simplification result: <deleted or consolidated structure, total line direction, and required-growth justification when applicable>
 - Deferred scope:
 
 ## Changed files

.github/workflows/podman-cpu-proof.yaml

@@ -28,7 +28,6 @@ on:
       - "src/lib/onboard/runtime-provider/container-state-mutation.ts"
       - "src/lib/onboard/runtime-provider/docker-state-mutation.ts"
       - "src/lib/onboard/experimental/portable-host-preparation*.ts"
-      - "src/lib/onboard/experimental/portable-profile.ts"
       - "src/lib/onboard/runtime-provider/podman*.ts"
       - "scripts/install-openshell.sh"
       - "scripts/checks/run-portable-cpu-delegation-proof.mts"
@@ -335,21 +334,6 @@ jobs:
             printf 'XDG_RUNTIME_DIR=%s\n' "$runtime_dir"
           } >>"$GITHUB_ENV"
 
-      - name: Configure exact Portable host gateway alias
-        shell: bash
-        run: |
-          set -euo pipefail
-          portable_host_gateway_ip="$(
-            node --input-type=module --eval '
-              const { PORTABLE_HOST_GATEWAY_IP } =
-                await import("./dist/lib/onboard/docker-driver-platform.js");
-              process.stdout.write(PORTABLE_HOST_GATEWAY_IP);
-            '
-          )"
-          sudo ip address replace "$portable_host_gateway_ip/32" dev lo
-          ip -o -4 address show dev lo | awk '{print $4}' | grep -Fx "$portable_host_gateway_ip/32"
-          printf 'E2E_PORTABLE_HOST_GATEWAY_IP=%s\n' "$portable_host_gateway_ip" >>"$GITHUB_ENV"
-
       - name: Start the exact connected gateway required by portable retirement
         shell: bash
         run: |
@@ -474,17 +458,6 @@ jobs:
             esac
           done < <(podman --url "$endpoint" secret ls --format '{{.Name}}' 2>/dev/null || true)
           podman --url "$endpoint" network rm openshell-docker 2>/dev/null || true
-          portable_host_gateway_ip=""
-          if portable_host_gateway_ip="$(
-            node --input-type=module --eval '
-              const { PORTABLE_HOST_GATEWAY_IP } =
-                await import("./dist/lib/onboard/docker-driver-platform.js");
-              process.stdout.write(PORTABLE_HOST_GATEWAY_IP);
-            '
-          )" && [ -n "$portable_host_gateway_ip" ] \
-            && [ "${E2E_PORTABLE_HOST_GATEWAY_IP:-}" = "$portable_host_gateway_ip" ]; then
-            sudo ip address delete "$portable_host_gateway_ip/32" dev lo 2>/dev/null || true
-          fi
           service_pid="${E2E_PODMAN_SERVICE_PID:-}"
           if [[ "$service_pid" =~ ^[1-9][0-9]*$ ]]; then
             kill "$service_pid" 2>/dev/null || true

bin/nemoclaw.js

@@ -17,9 +17,9 @@ try {
 }
 
 const PORT_ENV_NAME =
-  "NEMOCLAW_(?:GATEWAY|DASHBOARD|VLLM|LLAMACPP|OLLAMA|OLLAMA_PROXY|BEDROCK_RUNTIME_ADAPTER|OPENROUTER_RUNTIME_ADAPTER|HTTPS_PIN_RUNTIME_ADAPTER)_PORT";
+  "NEMOCLAW_(?:GATEWAY|DASHBOARD|VLLM|OLLAMA|OLLAMA_PROXY|BEDROCK_RUNTIME_ADAPTER|OPENROUTER_RUNTIME_ADAPTER|HTTPS_PIN_RUNTIME_ADAPTER)_PORT";
 const SAFE_PORT_DIAGNOSTIC = new RegExp(
-  `^Invalid port: ${PORT_ENV_NAME}="\\d{1,5}" — (?:must be an integer between 1024 and 65535|must not overlap the 18789-18799 dashboard port range|must not overlap the (?:llama\\.cpp inference|vLLM / NIM inference|Ollama inference|Ollama auth proxy|Bedrock Runtime adapter|OpenRouter Runtime adapter|HTTPS Pin Runtime adapter) default port \\(\\d{1,5}\\)|conflicts with ${PORT_ENV_NAME} \\(\\d{1,5}\\))$`,
+  `^Invalid port: ${PORT_ENV_NAME}="\\d{1,5}" — (?:must be an integer between 1024 and 65535|must not overlap the 18789-18799 dashboard port range|must not overlap the (?:llama\\.cpp inference|vLLM / NIM inference|Ollama inference|Ollama auth proxy|Bedrock Runtime adapter|OpenRouter Runtime adapter|HTTPS Pin Runtime adapter) default port \\(\\d{1,5}\\)|conflicts with ${PORT_ENV_NAME} \\(\\d{1,5}\\)|conflicts with the fixed llama\\.cpp inference port \\(8081\\))$`,
 );
 
 function redactFallbackMessage(message) {

docs/inference/choose-local-inference-server.mdx

@@ -81,7 +81,7 @@ Before you start, confirm these prerequisites:
 
 - Use a DGX Spark host with Linux on Arm64.
 - Confirm that Docker, the NVIDIA Container Toolkit, and the NVIDIA GPU driver are operational.
-- Stop any server that already uses the selected `NEMOCLAW_VLLM_PORT` (`8000` by default).
+- Stop any server that already uses port `8000`.
 - Allow capacity for container images, model artifacts, and same-filesystem download staging.
 - Export `HF_TOKEN` only if the configured artifact source requires Hugging Face authentication.
 
@@ -113,14 +113,13 @@ curl -fsSL https://www.nvidia.com/nemoclaw.sh | \
 The flag enables the dedicated vLLM profile gate, disables Express selection, and selects the matching catalog recipe.
 Selecting Express option 2 enables the same profile gate and selects the vLLM runtime.
 Do not combine this path with `NEMOCLAW_PROVIDER` or `NEMOCLAW_MODEL`.
-The profile rejects `NEMOCLAW_VLLM_MODEL` and `NEMOCLAW_VLLM_EXTRA_ARGS_JSON` before installation.
-Set `NEMOCLAW_VLLM_PORT` to publish its fixed container listener on another unused host port.
+The profile rejects `NEMOCLAW_VLLM_MODEL`, `NEMOCLAW_VLLM_PORT`, and `NEMOCLAW_VLLM_EXTRA_ARGS_JSON` before installation.
 
 The profile performs these actions:
 
 - Uses the pinned runtime image and fixed serving command from the catalog.
 - Stores model files in the host Hugging Face cache.
-- Publishes the authenticated server on loopback and the exact private IPv4 gateway of the `openshell-docker` bridge at the configured `NEMOCLAW_VLLM_PORT` (`8000` by default).
+- Publishes the authenticated server on `127.0.0.1:8000` and the exact private IPv4 gateway of the `openshell-docker` bridge, such as `172.18.0.1:8000`.
 - Never publishes the Docker host port on `0.0.0.0` or `::`.
 - Reuses the owner-only host-global managed-vLLM API key.
 
@@ -149,7 +148,7 @@ docker container inspect \
 ```
 
 The bridge result must contain exactly one private IPv4 `Gateway` value.
-The container result must contain exactly two bindings with `HostPort` set to the selected `NEMOCLAW_VLLM_PORT` (`8000` by default): one `HostIp` value of `127.0.0.1` and one that exactly matches the private bridge gateway. The inspect key remains `8000/tcp` because the container listener is fixed even when the published host port changes.
+The container result must contain exactly two bindings with `HostPort` set to `8000`: one `HostIp` value of `127.0.0.1` and one that exactly matches the private bridge gateway.
 Reject the runtime if a binding uses `0.0.0.0`, `::`, an empty address, another host address, or an additional entry.
 
 If installation stops after a model download, rerun the same installer command.

docs/inference/set-up-llama-cpp.mdx

@@ -17,7 +17,7 @@ Both paths are experimental and use OpenAI Chat Completions through `https://inf
 
 | Path | NemoClaw manages | You manage | Use it when |
 |---|---|---|---|
-| Existing server | Provider registration, route validation, and sandbox traffic through `inference.local`. | The server binary or container, GGUF file, launch configuration, credential, upgrades, and lifecycle. | Your authenticated server already satisfies the llama.cpp fingerprint contract on the configured loopback port (`8081` by default). |
+| Existing server | Provider registration, route validation, and sandbox traffic through `inference.local`. | The server binary or container, GGUF file, launch configuration, credential, upgrades, and lifecycle. | Your authenticated server already satisfies the llama.cpp fingerprint contract on loopback port `8081`. |
 | Managed DGX Spark | The exact YAML-selected image, GGUF acquisition and verification, launch configuration, credential, Docker lifecycle, diagnostics, and cleanup. | The qualified Linux host, Docker Engine, NVIDIA runtime prerequisites, storage, and any required Hugging Face credential. | You want the experimental Muse Glimmer or NVIDIA Nemotron profile without managing `llama-server` directly. |
 
 Compared with other local options, Ollama emphasizes a simple local model workflow, while managed vLLM provides host-specific NVIDIA GPU profiles and broader model selection.
@@ -30,7 +30,7 @@ Refer to [Choose a Local Inference Server](choose-local-inference-server) for th
 Use this path when you operate `llama-server` and want NemoClaw to register its authenticated endpoint without owning its process or model.
 The server must satisfy all of these requirements:
 
-- Listen over HTTP on `127.0.0.1:<configured-port>` and expose its OpenAI-compatible API under `/v1`.
+- Listen over HTTP on `127.0.0.1:8081` and expose its OpenAI-compatible API under `/v1`.
 - Require the same native bearer key supplied through `NEMOCLAW_LLAMACPP_LOCAL_TOKEN`.
 - Expose bounded native llama.cpp evidence through `/v1/models`, `/health`, `/props`, and either `/metrics` or the native metrics-not-supported response.
 - Report a stable, non-path served model alias.
@@ -64,7 +64,6 @@ For non-interactive onboarding, export `NEMOCLAW_LLAMACPP_LOCAL_TOKEN` from your
 : "${NEMOCLAW_LLAMACPP_LOCAL_TOKEN:?Export the native llama.cpp API key first}"
 NEMOCLAW_PROVIDER=llama-cpp \
 NEMOCLAW_MODEL="<served-model-alias>" \
-NEMOCLAW_LLAMACPP_PORT=19081 \
 NEMOCLAW_SANDBOX_NAME=my-assistant \
   $$nemoclaw onboard --non-interactive --yes-i-accept-third-party-software
 ```
@@ -74,10 +73,6 @@ You can omit `NEMOCLAW_MODEL` only when the server exposes exactly one native mo
 It refuses unauthenticated, ambiguous, non-native, conflicting, or differently addressed servers instead of guessing their identity.
 It does not start, stop, upgrade, or remove an attached server.
 
-Set `NEMOCLAW_LLAMACPP_PORT` to the server's non-privileged loopback port.
-The variable defaults to `8081` and also controls the OpenShell gateway route and local-inference policy entry.
-For a managed runtime, NemoClaw persists the chosen bridge port and reuses it during later recovery.
-
 Verify the registered route:
 
 ```bash
@@ -110,7 +105,7 @@ Before you start, confirm these prerequisites:
 - Confirm that the NVIDIA Container Toolkit is operational.
 - Confirm that NVIDIA Container Device Interface support is healthy.
 - Use NVIDIA driver version `580.65.06` or later.
-- Stop any process that uses the configured host port (`8081` when `NEMOCLAW_LLAMACPP_PORT` is unset).
+- Stop any process that uses host port `8081`.
 - Allow capacity for the pinned images, the GGUF file, and same-filesystem download staging.
 - Export `HF_TOKEN` only when the YAML-declared Hugging Face source requires authentication.
 
@@ -121,7 +116,7 @@ Run `unset HF_TOKEN` after onboarding when no other process needs it.
 <Warning>
 When the exact artifacts are not already present, onboarding pulls digest-pinned images from external registries and acquires the YAML-declared GGUF file through the standard Hugging Face cache.
 It reuses locally present pinned images and a cached GGUF only after their exact identities verify.
-It creates an owner-only API key, a host-loopback listener on the configured port, and a Docker internal network.
+It creates an owner-only API key, a host-loopback listener on port `8081`, and a Docker internal network.
 Only one managed llama.cpp runtime can exist per Docker authority, regardless of the owning OpenShell gateway or sandbox.
 </Warning>
 
@@ -143,7 +138,6 @@ For non-interactive onboarding, select the repository-owned recipe explicitly:
 ```bash
 NEMOCLAW_PROVIDER=install-llama-cpp \
 NEMOCLAW_LLAMACPP_RECIPE=llama-cpp.muse-glimmer-30b.spark-single.v1 \
-NEMOCLAW_LLAMACPP_PORT=19081 \
 NEMOCLAW_SANDBOX_NAME=my-assistant \
   $$nemoclaw onboard --non-interactive --yes-i-accept-third-party-software
 ```
@@ -157,8 +151,7 @@ For non-interactive onboarding or an explicit provider request, set `NEMOCLAW_LL
 An unknown recipe, an incompatible host, or more than one compatible profile for the requested recipe stops onboarding before installation effects.
 Do not set `NEMOCLAW_MODEL` for this path.
 The repository YAML recipe is authoritative for the exact model file, revision, digest, image, launch settings, resource limits, readiness probes, and disabled surfaces.
-`NEMOCLAW_LLAMACPP_PORT` controls the host-owned private bridge; the recipe's internal server port remains fixed.
-NemoClaw does not provide hidden model, image, or launch-flag overrides for the managed path.
+NemoClaw does not provide hidden model, port, image, or launch-flag overrides for the managed path.
 
 The shipped NVIDIA Nemotron recipe continues to use the `nemotron-v3-embedded` chat template.
 A repository recipe that uses an image-owned Jinja template must declare this typed contract:
@@ -196,7 +189,7 @@ Onboarding performs these actions:
 - Reuses a verified GGUF from the shared `~/.cache/huggingface/` cache, or acquires the exact file through the existing Hugging Face mechanism when it is absent or invalid.
 - Verifies the GGUF size and SHA-256 digest before it starts the runtime.
 - Runs the authenticated container as the current non-root user with one NVIDIA GPU and no CPU fallback.
-- Starts a host-owned private bridge on `127.0.0.1:<configured-port>` and connects the container to a Docker internal network without a Docker-published port.
+- Starts a host-owned private bridge on `127.0.0.1:8081` and connects the container to a Docker internal network without a Docker-published port.
 - Registers `llama-cpp-local` and routes agent traffic through `https://inference.local/v1`.
 
 The runtime cannot download a model and has no egress on its internal Docker network.
@@ -232,14 +225,14 @@ Refer to [CLI Commands](../../reference/commands) for complete command behavior.
 
 During managed installation, NemoClaw first checks internal runtime readiness and host-loopback health.
 It repeats these checks when onboarding resumes.
-It then runs the authoritative OpenShell Docker bridge probe on the configured host port.
+It then runs the authoritative OpenShell Docker bridge probe on fixed port `8081`.
 If that bridge probe cannot connect or times out after the earlier checks pass, onboarding stops without changing UFW.
 When the bridge reports a valid narrow subnet and a gateway IP address inside that subnet, the error reports these values:
 
 - The detected Docker network.
 - The source subnet.
 - The gateway IP address.
-- The configured port.
+- The fixed port `8081`.
 - The exact narrow UFW command.
 
 If the bridge topology is missing or invalid, onboarding fails closed without printing topology or a UFW command.
@@ -248,22 +241,22 @@ Inspect the OpenShell Docker bridge configuration before you retry onboarding.
 <Warning>
 The printed command changes UFW.
 Confirm that the reported Docker network, source subnet, and gateway IP address belong to the OpenShell Docker bridge before you run it.
-The rule allows TCP traffic only from that subnet to the configured port on that gateway IP address.
+The rule allows TCP traffic only from that subnet to port `8081` on that gateway IP address.
 </Warning>
 
 Run the exact command from the onboarding error.
 It has this form:
 
 ```bash
-sudo ufw allow from <subnet> to <gateway-ip> port <llama-cpp-port> proto tcp
+sudo ufw allow from <subnet> to <gateway-ip> port 8081 proto tcp
 ```
 
 After you apply the rule, rerun the same onboarding selection.
 
 If onboarding still reports the bridge failure, or when the managed runtime no longer needs the rule, remove the exact rule that you added:
 
 ```bash
-sudo ufw --force delete allow from <subnet> to <gateway-ip> port <llama-cpp-port> proto tcp
+sudo ufw --force delete allow from <subnet> to <gateway-ip> port 8081 proto tcp
 ```
 
 Use the same subnet and gateway IP address that appeared in the original command.