Ground infrastructure discovery in configured inventories

helm/mosaic-stack/files/openclaw-seed/skills/bcm/SKILL.md

@@ -12,6 +12,8 @@ SPDX-License-Identifier: Apache-2.0
 
 Use this skill when a user asks about node inventory, node categories, cluster health, or why a node is or was unavailable.
 
+BCM device inventory can include machines outside the current Kubernetes cluster. Correlate device names and addresses with Kubernetes membership and scheduler or service evidence; report physical inventory separately from membership in a particular cluster. A BCM pod or node label alone does not prove that this session has BCM tools or that the service is healthy. Check available tools and returned evidence before claiming access or health.
+
 Use Base Command Manager tools, not shell or Slurm tools. For inventory, category, Kubernetes cluster, schedulability, and node state questions, prefer `bcm_execute_cmsh` because it uses the Base Command Manager read-only CMSH profile. Use `bcm_get_info`, `bcm_search_tools`, `bcm_execute_tool`, or `bcm_search_notes` for non-CMSH evidence. Do not call `bcm_health` just to start a normal `/cluster-management` request; it may be slow on large clusters. Do not invent CMSH modes or subcommands; `cluster` is not a valid CMSH mode for this workflow, and `device health ...` / `device; use <node>; health` are not valid commands.
 
 When Base Command Manager or NVIDIA Mission Control command syntax, modes, concepts, or operational behavior are unclear, search the seeded Base Command Manager manuals and NMC guides before guessing. These documents are normal markdown files, not Base Command Manager MCP tools and not the `SKILL.md` file. Never call `bcm_search_docs`; that tool is not available. Use `exec` with read-only shell commands against `/sandbox/workspace/skills/bcm/docs`, for example `find /sandbox/workspace/skills/bcm/docs -type f`, `grep -R <term> /sandbox/workspace/skills/bcm/docs`, and `sed -n`. If running outside OpenShell, the same documents are also staged at `/home/node/.openclaw/workspace/docs`. Then return to Base Command Manager MCP tools for live cluster evidence.

helm/mosaic-stack/files/openclaw-seed/workspace/AGENTS.md

@@ -52,6 +52,16 @@ Use connected operational systems as the source of truth for infrastructure stat
 
 ## Kubernetes
 
+### Infrastructure scope and discovery
+
+A Kubernetes cluster contains only its registered nodes. The physical fleet can also include other Kubernetes clusters, scheduler-managed nodes, bare-metal services, and management hosts. An empty GPU inventory in one Kubernetes context says nothing about GPUs elsewhere in the fleet.
+
+Establish capabilities from this session's registered tools and configured targets. Pods, labels, or services belonging to another deployment do not establish that this agent has that integration, credentials, or access. For broader inventory, use configured BCM inventory tools, additional registered Kubernetes clusters, Slurm inventory, or monitoring targets as appropriate. Correlate hostnames and addresses across sources and state each source's coverage. If no broader inventory is available, report that boundary without concluding the hosts do not exist. Inventory discovery does not authorize access to newly found hosts.
+
+For service-placement questions, distinguish the agent runtime, proxies, and backend service. Inspect the current deployment's non-secret configuration and follow service references and upstream endpoints before identifying where the backend runs. An agent pod's node or GPU allocation does not establish the inference server's placement or GPU count. Confirm those from the backend's deployment or host evidence. Chart source may not be mounted; rendered workloads and ConfigMaps remain useful read-only evidence. Never retrieve Secrets or dump credential-bearing configuration for this purpose.
+
+Configuration, endpoint addresses, shared address prefixes, and Running pods do not prove network reachability or successful requests. Use relevant logs, metrics, or an available approved diagnostic tool to establish those facts. State the particular tool or target limitation when blocked; do not describe View mode as prohibiting all network diagnostics or require Edit for an available read-only check. Do not use scans, nested SSH, or arbitrary exec to bypass configured access.
+
 If a Kubernetes tool rejects a request, stop using tools and explain the enforced access boundary. Never use general `exec` to run, find, install, inspect, or work around kubectl. Never retry a denied Kubernetes operation through another tool.
 
 For every Kubernetes read, call `run_kubectl` with a registered cluster and read-only kubectl argument array. In View, explain that Edit or Auto is required when the user requests a change. In Edit or Auto, immediately call `run_kubectl_admin` with the exact requested kubectl arguments and optional stdin for operations outside the read-only tool, including create, exec, label, patch, scale, delete, and apply. The tool framework requests approval in Edit and executes immediately in Auto; never print a proposed approval command or ask the user to confirm in chat.