fix(status): probe inference.local route for cloud providers in status/doctor

.agents/skills/nemoclaw-contributor-create-pr/SKILL.md

@@ -22,19 +22,25 @@ Follow the shared [Git and GitHub Access Hard Stop](../_shared/git-github-hard-s
 
 Before creating a PR, verify the branch.
 
-1. **Not on main.** Never create PRs from main.
+1. **Refresh the trusted base ref.**
+
+   ```bash
+   git fetch --prune origin main
+   ```
+
+2. **Not on main.** Never create PRs from main.
 
    ```bash
    git branch --show-current
    ```
 
-2. **Branch has commits ahead of main.**
+3. **Branch has commits ahead of `origin/main`.**
 
    ```bash
-   git log main..HEAD --oneline
+   git log origin/main..HEAD --oneline
    ```
 
-3. **Working tree is clean.** Stage or stash any uncommitted changes first.
+4. **Working tree is clean.** Stage or stash any uncommitted changes first.
 
    ```bash
    git status
@@ -49,28 +55,32 @@ Use the checks that match the diff and the verification you already have.
 
 If the commits were created normally and the branch was pushed normally, count the installed hooks as verification:
 
-- `pre-commit` runs file fixers, formatters, linters, skill frontmatter validation, and changed-surface Vitest hooks.
+- `pre-commit` runs cheap structural and file-local checks, including fixers, formatters, linters, and skill frontmatter validation.
 - `commit-msg` runs commitlint.
-- `pre-push` runs TypeScript build and type-check gates.
+- `pre-push` runs path-scoped incremental type checks for affected CLI and plugin surfaces plus checked-JavaScript checks.
 
-If hooks were skipped with `--no-verify`, were not installed, failed, or you cannot tell whether they ran, run a manual diff-scoped fallback before creating the PR:
+If hooks were skipped with `--no-verify`, were not installed, failed, or you cannot tell whether they ran, use the single diff-scoped fallback that reproduces `pre-commit`, `commit-msg`, and `pre-push` checks:
 
 ```bash
-npx prek run --from-ref main --to-ref HEAD
+npm run check:diff
 ```
 
-Use `npx prek run --all-files` only when you need a whole-repository baseline, such as changing hook configuration, formatter configuration, generated-check scripts, or other repo-wide validation behavior.
+The fallback compares with the refreshed `origin/main` ref from Step 1.
+Reserve `npm run check` for the whole-repository pre-commit and full CLI/plugin coverage baseline, such as when changing hook configuration, formatter configuration, generated-check scripts, or other repo-wide validation behavior.
 
 ### Targeted Tests
 
-Run the smallest meaningful tests for changed behavior:
+Run the smallest meaningful tests for changed behavior once per relevant change set, and record the command and result for the PR body:
 
 - CLI or root `src/`, `bin/`, `scripts/`, or `test/` changes: `npx vitest run --project cli` or the directly affected test file.
 - Plugin changes under `nemoclaw/src/`: `npx vitest run --project plugin` or the directly affected plugin test file.
 - E2E support changes under `test/e2e/support/`: `npx vitest run --project e2e-support`.
+- E2E workflow, artifact upload, trace timing, or fixture environment-boundary changes: run the directly affected `test/e2e/support/*workflow*.test.ts`, `test/e2e/support/upload-e2e-artifacts-workflow-boundary.test.ts`, `test/e2e/support/sanitize-trace-timing.test.ts`, and fixture boundary tests instead of relying on unrelated live target runs.
 - Installer behavior changes: run the relevant installer integration project only when the local environment supports it.
 
-Reserve full `npm test` for broad runtime changes, test harness changes, or cases where targeted coverage is hard to justify.
+Do not rerun targeted tests solely because the normal hooks passed; rerun them after later edits or hook autofixes that can affect the tested behavior.
+Reserve `npm test` for broad runtime changes, test harness changes, or cases where targeted coverage is hard to justify.
+Reserve `npm run check` for repo-wide hook, formatter, generated-check, or coverage-baseline changes.
 Do not run the full test suite for doc-only changes unless the docs change code samples or generated behavior in a way that needs runtime validation.
 
 For doc-only changes, run the docs build before opening the PR:
@@ -94,7 +104,7 @@ If the push fails because of SSH, authentication, remote access, authorization,
 
 ## Step 4: Prepare DCO Declaration and Verify GitHub Commits
 
-Before creating the PR, prepare the DCO declaration for the PR body and verify every commit in `main..HEAD`.
+Before creating the PR, prepare the DCO declaration for the PR body and verify every commit in `origin/main..HEAD`.
 This is a hard contributor self-serve gate.
 Do not run `gh pr create` until the PR body will include the DCO declaration and every commit passes GitHub verification.
 
@@ -107,10 +117,10 @@ Do not run `gh pr create` until the PR body will include the DCO declaration and
    ```
 
 2. **GitHub verification.** Each pushed commit must appear as verified in GitHub.
-   Check the commit SHAs from `main..HEAD` with the GitHub API before opening the PR.
+   Check the commit SHAs from `origin/main..HEAD` with the GitHub API before opening the PR.
 
    ```bash
-   for sha in $(git rev-list main..HEAD); do
+   for sha in $(git rev-list origin/main..HEAD); do
      gh api "/repos/NVIDIA/NemoClaw/commits/$sha" --jq '.sha + " verified=" + (.commit.verification.verified | tostring) + " reason=" + .commit.verification.reason'
    done
    ```
@@ -192,8 +202,8 @@ Follow these rules when filling in the template:
 - **Related Issue:** Include `Fixes #NNN` or `Closes #NNN` if an issue exists. Remove the section entirely if there is no related issue.
 - **Changes:** Bullet list of key changes. Be specific — reference file names, commands, or behaviors that changed.
 - **Type of Change:** Check exactly one box. Use `[x]` for checked, `[ ]` for unchecked.
-- **Quality Gates:** Check every line that applies to the diff. If tests/docs are not needed or existing coverage is sufficient, include the justification. If sensitive paths changed or a non-success CI check is accepted, record the authorized reviewer, maintainer-approved waiver, approval link, or follow-up issue.
-- **Verification:** Check only the boxes for steps you actually ran and confirmed passing, or for Git hooks that passed during normal commit and push. Do not check boxes for steps you skipped or did not verify. The DCO declaration and GitHub verification checkbox is mandatory before PR creation because Step 4 must pass first. For doc-only changes, `npm test` is not required; leave it unchecked unless you ran it.
+- **Quality Gates:** Check exactly one tests line and one docs line, then check every other line that applies to the diff. If tests/docs are not needed or existing coverage is sufficient, include the justification. If sensitive paths changed or a non-success CI check is accepted, record the authorized reviewer, maintainer-approved waiver, approval link, or follow-up issue.
+- **Verification:** Check only the boxes backed by the requested command/result, justification, normal hook evidence, or fallback evidence. Do not check boxes for steps you skipped or did not verify. The DCO declaration and GitHub verification checkbox is mandatory before PR creation because Step 4 must pass first. For focused changes, leave the broad-gate line unchecked unless you actually ran the applicable command.
 - **DCO Sign-Off:** Replace `{name}` and `{email}` with values from `git config user.name` and `git config user.email`.
 
 ## Step 7: Create the PR
@@ -244,8 +254,9 @@ Automated review: no actionable findings / addressed findings / waiting on user
 - **Do not invent your own PR body format.** Use `.github/PULL_REQUEST_TEMPLATE.md` exactly.
 - **Do not omit sections.** Even if a section is not applicable, keep it with the "Skip if..." comment.
 - **Do not check boxes for steps you did not run.** If you did not run `npm run docs`, leave that box unchecked.
-- **Do not rerun hook-covered checks by default.** Normal commit and push hooks are valid verification. Use `npx prek run --from-ref main --to-ref HEAD` as the fallback when hooks were skipped, missing, or uncertain.
-- **Do not run the full test suite for doc-only changes by default.** Run the docs build instead, and leave `npm test` unchecked unless you actually ran it.
+- **Do not rerun hook-covered checks by default.** Normal `pre-commit`, `commit-msg`, and `pre-push` hooks are valid verification. Use `npm run check:diff` once as the fallback when hooks were skipped, missing, or uncertain.
+- **Do not run targeted tests more than once per unchanged relevant change set.** Record the passing command and result; rerun when subsequent edits or hook autofixes can affect that behavior.
+- **Do not run broad gates for doc-only changes by default.** Run the docs build instead, and leave the broad-gate verification item unchecked unless you actually ran the applicable command.
 - **Do not forget the DCO sign-off declaration in the PR body.** CI will reject the PR without it.
 - **Do not create PRs with unverified commits.** GitHub must report every PR commit as `Verified` before the PR is opened.
 - **Do not rely on maintainers to repair contributor signature history.** If force-push is not allowed and the branch contains an unverified commit, use a fresh branch and fresh PR.

.agents/skills/nemoclaw-contributor-onboard-messaging-channel/SKILL.md

@@ -88,15 +88,24 @@ Start with the manifest. Add core code only when the manifest vocabulary cannot
 
 ## Verification
 
-Use the narrowest tests that cover the changed behavior:
+Build one targeted Vitest invocation from only the files that cover the changed behavior.
+Omit unaffected paths from this example, then run the resulting command once per relevant change set:
 
 ```bash
-npm run build:cli
-npm run typecheck:cli
-npx vitest run src/lib/messaging/channels/manifests.test.ts src/lib/messaging/channels/metadata.test.ts src/lib/messaging/compiler/manifest-compiler.test.ts
-npx vitest run src/lib/messaging/channels/<channel>/hooks
-npx vitest run test/messaging-build-applier.test.ts
+npx vitest run \
+  src/lib/messaging/channels/<channel> \
+  src/lib/messaging/channels/manifests.test.ts \
+  src/lib/messaging/channels/metadata.test.ts \
+  src/lib/messaging/compiler/manifest-compiler.test.ts \
+  test/messaging-build-applier.test.ts
 ```
 
 Add channel-specific config render, hook, policy, and channel add/remove tests when those surfaces change.
-Run `npm run docs` for documentation changes and `npx prek run --files <changed files>` before handoff. If broad hooks expose unrelated failures, report the failure with the targeted passing evidence.
+Rerun the targeted command after later edits or hook autofixes that can affect the tested behavior.
+Run `npm run docs` for documentation changes.
+Commit and push normally so pre-commit handles cheap structural and file-local checks and pre-push runs the path-scoped type checks.
+Treat successful hooks as verification and do not rerun their checks manually.
+If `pre-commit`, `commit-msg`, or `pre-push` hooks were skipped or unavailable, run `npm run check:diff` once to reproduce those checks.
+Refresh `origin/main` first.
+Reserve `npm test` for broad runtime or test-harness changes.
+Reserve `npm run check` for repo-wide validation or coverage-baseline changes.

.agents/skills/nemoclaw-contributor-onboard/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: nemoclaw-contributor-onboard
+description: Prepare a NemoClaw source checkout for compliant contribution through the repository's one-command setup and readiness doctor. Use when a new contributor asks to set up a development machine, prepare a checkout for a first PR, repair local contributor tooling, verify contributor readiness, launch the pinned coding agent, or decide whether optional runtime onboarding is needed. Trigger keywords - contributor setup, developer onboarding, first PR, dev setup, dev doctor, repair checkout, prepare development machine.
+---
+
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# Onboard a NemoClaw Contributor
+
+Use the repository setup script as the executable source of truth.
+Do not duplicate its dependency, build, hook, CLI-exposure, or readiness logic in agent commands.
+
+## Establish Trust First
+
+1. Read the root `AGENTS.md` and `CONTRIBUTING.md` completely.
+2. Inspect the worktree and current branch without discarding or overwriting existing changes.
+3. Refresh the trusted `origin/main` reference, then compare the entire checkout/worktree diff against that up-to-date base before executing any checkout-local code.
+   Include staged, unstaged, and untracked files; review lockfiles and all transitively executed source, not only the entry script or package manifests.
+4. If any execution surface differs from trusted `origin/main`, review the diff and obtain explicit approval before running it.
+
+## Route by Intent
+
+- **Readiness only:** run `./scripts/dev-setup.sh --doctor` and never run setup, repair, CLI exposure, runtime onboarding, or the pinned agent.
+  Use `./scripts/dev-setup.sh --doctor --json` when a machine-readable report helps.
+- **Initial checkout setup:** run `./scripts/dev-setup.sh` from the repository root.
+- **Explicit repository repair:** run `./scripts/dev-setup.sh --repair` only when the user asks to repair or retry repository-local setup.
+- **CLI exposure:** after explicit approval, run `./scripts/dev-setup.sh --expose-cli`.
+- **Runtime onboarding:** after explicit approval, run `./scripts/dev-setup.sh --with-runtime`.
+
+The default and repair modes may update repository-local dependencies, builds, hooks, and the root Python environment.
+They must not create a gateway or sandbox or expose a host-visible `nemoclaw` command.
+CLI exposure is an explicit opt-in that may use an npm link or a user-local shim.
+
+## Handle User-Controlled Changes
+
+Pause and obtain explicit approval before installing or changing host packages, starting or replacing a container runtime, accepting a license, generating or registering a signing key, changing GitHub state, or changing global Git configuration.
+
+- Ask for contributor name and email only when the doctor reports that identity is missing.
+- Prefer repository-local Git identity changes when the user approves them.
+- Use `gh auth login -h github.com` for missing GitHub authentication and pause for browser or device authentication.
+- Let the user choose and register a Git-supported commit-signing key.
+- Follow `../_shared/git-github-hard-stop.md` for authentication, authorization, SSH, remote-access, or push failures.
+- Never print tokens, credential values, private keys, or command output that may contain them.
+- Never place secrets in command arguments, generated reports, or tracked files.
+
+After an approved host, account, identity, or signing remediation, rerun `npm run dev:doctor` or `./scripts/dev-setup.sh --doctor` instead of rerunning setup.
+Reserve setup and `--repair` for repository-local dependency, build, or hook repair.
+
+## Decide on Runtime Onboarding
+
+Ask whether the intended issue requires a live gateway or sandbox after source setup is ready.
+Documentation work and isolated unit tests normally do not require runtime onboarding.
+
+If runtime validation is required and the user approves it, run:
+
+```bash
+./scripts/dev-setup.sh --with-runtime
+```
+
+This delegates to interactive `nemoclaw onboard` and also opts into development CLI exposure as part of that approved flow.
+Do not preselect third-party software acceptance, inference provider or model, credentials, sandbox name or resources, messaging integrations, or network policy unless the user already supplied those decisions.
+
+## Launch the Pinned Agent Only on Request
+
+When the user specifically asks to use the repository-pinned coding agent, run the doctor first.
+If readiness fails, report the remediation and obtain authorization for the matching setup or repair mode rather than mutating the checkout automatically.
+When readiness passes, run:
+
+```bash
+npm run agent
+```
+
+Pass user-supplied Pi arguments after `--`.
+Do not install or invoke a global Pi binary.
+
+## Prepare for the First PR
+
+Before the contributor starts implementation, explain this workflow:
+
+1. Create a feature branch from current `main`.
+2. Use Conventional Commits in `<type>(<scope>): <description>` form.
+3. Run tests targeted to the changed behavior and `npm run docs` for documentation changes.
+4. Commit with configured signing so every pushed commit appears as `Verified` on GitHub.
+5. Include `Signed-off-by: Name <email>` in the PR description for DCO compliance.
+6. Follow `.github/PULL_REQUEST_TEMPLATE.md` and monitor required CI and automated review feedback.
+
+Use `nemoclaw-contributor-create-pr` when the user asks to publish the changes.
+Do not create a branch, commit, push, or PR unless the user's request includes that action.
+
+## Report the Result
+
+Summarize repository-local setup performed, doctor status, user-controlled remediations still needed, whether CLI exposure or runtime onboarding ran, and the next safe contributor action.

.agents/skills/nemoclaw-contributor-onboard/agents/openai.yaml

@@ -0,0 +1,7 @@
+# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# SPDX-License-Identifier: Apache-2.0
+
+interface:
+  display_name: "NemoClaw Contributor Setup"
+  short_description: "Prepare a checkout for a first PR"
+  default_prompt: "Use $nemoclaw-contributor-onboard to set up this machine as a NemoClaw contributor and prepare it for a first PR."

.agents/skills/nemoclaw-contributor-update-docs/SKILL.md

@@ -18,6 +18,7 @@ Scan recent git history for commits that affect user-facing behavior and draft d
 - Before a release, to catch any doc gaps.
 - During daily release prep, before opening the release-note docs PR.
 - Before cutting a release tag, so release-note docs land on the same release train.
+- When maintainers run `/nemoclaw-contributor-update-docs for vX.Y.Z`, treat it as pre-tag release-prep docs for `vX.Y.Z` unless the tag already exists.
 - After a release only when maintainers missed the pre-tag docs step and need a catch-up PR.
 - When a contributor asks "what docs need updating?"