feat: add sandbox export/import backup commands

.agents/skills/update-docs-from-commits/SKILL.md → .agents/skills/update-docs/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: update-docs-from-commits
+name: update-docs
 description: Scan recent git commits for changes that affect user-facing behavior, then draft or update the corresponding documentation pages. Use when docs have fallen behind code changes, after a batch of features lands, or when preparing a release. Trigger keywords - update docs, draft docs, docs from commits, sync docs, catch up docs, doc debt, docs behind, docs drift.
 ---
 

.coderabbit.yaml

@@ -0,0 +1,114 @@
+# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
+language: "en-US"
+early_access: false
+reviews:
+  profile: "chill"
+  request_changes_workflow: false
+  high_level_summary: true
+  poem: true
+  review_status: true
+  review_details: false
+  auto_review:
+    enabled: true
+    drafts: false
+  path_instructions:
+    - path: "docs/**"
+      instructions: |
+        You are an editorial reviewer for NemoClaw documentation.
+        Review every docs change against the style guide below. Flag violations
+        inline as review comments. Do not rewrite the content — point out the
+        issue and cite the relevant rule so the author can fix it.
+
+        ## Voice and Tone
+
+        - Active voice required. Flag passive constructions.
+          Bad: "A gateway is created by the CLI."
+          Good: "The CLI creates a gateway."
+        - Second person ("you") when addressing the reader.
+        - Present tense. Flag future tense ("will") in descriptions of current behavior.
+        - No hedge words: flag "simply," "just," "easily," "of course."
+
+        ## LLM-Generated Patterns (Flag These)
+
+        These are common in AI-generated text and erode trust with technical readers.
+        Flag every occurrence:
+
+        - Unnecessary bold on routine instructions ("This is a **critical** step"
+          when nothing is actually critical). Bold is reserved for UI labels,
+          parameter names, and genuine warnings.
+        - Excessive em dashes. One per paragraph is fine; multiple per paragraph
+          or em dashes used instead of commas/periods should be flagged.
+        - Superlatives and marketing language ("powerful," "robust," "seamless,"
+          "cutting-edge"). Say what it does, not how great it is.
+        - Emoji in documentation prose.
+        - Rhetorical questions ("Want to secure your agents? Look no further!").
+          State the purpose directly.
+        - Filler introductions ("In this section, we will explore..."). Start
+          with the content.
+
+        ## Formatting Rules
+
+        - Every sentence must end with a period.
+        - One sentence per line in source (makes diffs readable). Flag paragraphs
+          where multiple sentences appear on the same line.
+        - CLI commands, file paths, flags, parameter names, and values must use
+          inline `code` formatting.
+        - CLI code blocks must use the `console` language tag with `$` prompt
+          prefix. Flag ```bash or ```shell for CLI examples.
+        - Use MyST admonitions (:::{tip}, :::{note}, :::{warning}) for callouts,
+          not bold text or blockquotes.
+        - No nested admonitions.
+        - Do not number section titles. Flag "Section 1: ...", "Step 3: ...", etc.
+        - No colons in titles. Flag "Inference: Cloud and Local" — should be
+          "Cloud and Local Inference."
+        - Colons should only introduce a list. Flag colons used as general
+          punctuation between clauses.
+
+        ## Word List (Flag Incorrect Usage)
+
+        | Correct        | Incorrect (flag these)                              |
+        |----------------|------------------------------------------------------|
+        | NVIDIA         | Nvidia, nvidia                                       |
+        | NemoClaw       | nemoclaw (in prose), Nemoclaw                        |
+        | OpenClaw       | openclaw (in prose), Openclaw                        |
+        | OpenShell      | Open Shell, openShell, Openshell, openshell (in prose)|
+        | CLI            | cli, Cli                                             |
+        | API key        | api key, API Key                                     |
+        | mTLS           | MTLS, mtls                                           |
+        | YAML           | yaml (in prose), Yaml                                |
+        | gateway        | Gateway (unless starting a sentence)                 |
+        | sandbox        | Sandbox (unless starting a sentence)                 |
+
+        Words inside code blocks or inline code spans are exempt from the word
+        list (e.g., `nemoclaw onboard` is correct).
+
+        ## Page Structure
+
+        When reviewing new pages, verify:
+        - SPDX license header is present after frontmatter.
+        - Frontmatter includes title, description, keywords, topics, tags,
+          content type, difficulty, audience, and status fields.
+        - H1 heading matches the `title.page` frontmatter value.
+        - Page starts with a one- or two-sentence introduction.
+        - Sections use H2 and H3, each starting with an introductory sentence.
+        - A "Next Steps" section at the bottom links to related pages.
+
+        ## Severity
+
+        - Word list and voice violations: flag as suggestions.
+        - Missing SPDX header, broken cross-references, or incorrect code
+          block language: flag as issues.
+        - LLM-generated patterns (bold overuse, em dashes, superlatives,
+          hedge words): flag as suggestions with the note "LLM pattern detected."
+    - path: "**/*.md"
+      instructions: |
+        This rule applies to all Markdown files project-wide. For files
+        under docs/, the stricter docs/** rules defined earlier in this
+        file take precedence; this rule adds baseline checks for every
+        other Markdown file (README, CONTRIBUTING, architecture docs, etc.).
+
+        - NVIDIA must be all caps (not Nvidia, nvidia).
+        - NemoClaw, OpenClaw, and OpenShell must use correct casing.
+        - No emoji in technical prose.
+chat:
+  auto_reply: true

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,55 @@
+name: Bug Report
+description: Report a bug you confirmed and could not fix.
+labels: ["bug", "status: triage"]
+body:
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: What happened? What did you expect to happen?
+    validations:
+      required: true
+
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: Reproduction Steps
+      description: Minimal steps to reproduce the issue.
+      placeholder: |
+        1. Run `nemoclaw onboard`
+        2. Select "local" inference
+        3. ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: environment
+    attributes:
+      label: Environment
+      description: OS, Node.js version, Docker version, NemoClaw version, and any other relevant details.
+      placeholder: |
+        - OS: macOS 15.2 / Ubuntu 24.04 / Windows 11 + WSL2
+        - Node.js: v20.x
+        - Docker: Docker Desktop 4.x / Docker Engine 27.x
+        - NemoClaw: v0.x.x (output of `nemoclaw --version`)
+    validations:
+      required: true
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Logs
+      description: Relevant log output, error messages, or stack traces.
+      render: shell
+    validations:
+      required: false
+
+  - type: checkboxes
+    id: checklist
+    attributes:
+      label: Checklist
+      options:
+        - label: I confirmed this bug is reproducible
+          required: true
+        - label: I searched existing issues and this is not a duplicate
+          required: true

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,7 @@
+blank_issues_enabled: false
+contact_links:
+  - name: Security vulnerability?
+    url: https://github.com/NVIDIA/NemoClaw/blob/main/SECURITY.md
+    about: >
+      Do not report security vulnerabilities through GitHub issues. Follow
+      the disclosure process in SECURITY.md.

.github/ISSUE_TEMPLATE/doc_issue.yml

@@ -0,0 +1,42 @@
+name: Documentation Issue
+description: Report incorrect, missing, or unclear documentation.
+labels: ["documentation", "status: triage"]
+body:
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: What is wrong, missing, or unclear in the docs?
+    validations:
+      required: true
+
+  - type: input
+    id: page
+    attributes:
+      label: Affected Page
+      description: URL or file path of the doc page (e.g., docs/get-started/quickstart.md).
+      placeholder: docs/reference/commands.md
+    validations:
+      required: false
+
+  - type: dropdown
+    id: issue-type
+    attributes:
+      label: Issue Type
+      options:
+        - "Inaccurate information"
+        - "Missing documentation"
+        - "Unclear or confusing"
+        - "Broken link or cross-reference"
+        - "Formatting or rendering problem"
+        - "Other"
+    validations:
+      required: true
+
+  - type: textarea
+    id: suggestion
+    attributes:
+      label: Suggested Fix
+      description: If you know what the correct content should be, describe it here.
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,51 @@
+name: Feature Request
+description: Propose a feature with a design. Not a "please build this" request.
+labels: ["enhancement", "status: triage"]
+body:
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem Statement
+      description: What problem does this solve? Why does it matter?
+    validations:
+      required: true
+
+  - type: textarea
+    id: design
+    attributes:
+      label: Proposed Design
+      description: |
+        How should this work? Describe the system behavior, components involved, and user-facing interface.
+        This should be a design, not a wish list.
+    validations:
+      required: true
+
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternatives Considered
+      description: What other approaches did you evaluate? Why is the proposed design better?
+    validations:
+      required: false
+
+  - type: dropdown
+    id: category
+    attributes:
+      label: Category
+      options:
+        - "enhancement: feature"
+        - "enhancement: provider"
+        - "enhancement: platform"
+        - "enhancement: testing"
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: checklist
+    attributes:
+      label: Checklist
+      options:
+        - label: I searched existing issues and this is not a duplicate
+          required: true
+        - label: This is a design proposal, not a "please build this" request
+          required: true

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,40 @@
+## Summary
+<!-- 1-3 sentences: what this PR does and why. -->
+
+## Related Issue
+<!-- Link to the issue: Fixes #NNN or Closes #NNN. Remove this section if none. -->
+
+## Changes
+<!-- Bullet list of key changes. -->
+
+## Type of Change
+<!-- Check the one that applies. -->
+- [ ] Code change for a new feature, bug fix, or refactor.
+- [ ] Code change with doc updates.
+- [ ] Doc only. Prose changes without code sample modifications.
+- [ ] Doc only. Includes code sample changes.
+
+## Testing
+<!-- What testing was done? -->
+- [ ] `make check` passes.
+- [ ] `npm test` passes.
+- [ ] `make docs` builds without warnings. (for doc-only changes)
+
+## Checklist
+
+### General
+- [ ] I have read and followed the [contributing guide](CONTRIBUTING.md).
+- [ ] I have read and followed the [style guide](docs/CONTRIBUTING.md). (for doc-only changes)
+
+### Code Changes
+<!-- Skip if this is a doc-only PR. -->
+- [ ] `make format` applied (TypeScript and Python).
+- [ ] Tests added or updated for new or changed behavior.
+- [ ] No secrets, API keys, or credentials committed.
+- [ ] Doc pages updated for any user-facing behavior changes (new commands, changed defaults, new features, bug fixes that contradict existing docs).
+
+### Doc Changes
+<!-- Skip if this PR has no doc changes. -->
+- [ ] Follows the [style guide](docs/CONTRIBUTING.md). Try running the `update-docs` agent skill to draft changes while complying with the style guide. For example, prompt your agent with "`/update-docs` catch up the docs for the new changes I made in this PR."
+- [ ] New pages include SPDX license header and frontmatter, if creating a new page.
+- [ ] Cross-references and links verified.

.github/workflows/docs.yaml

@@ -0,0 +1,43 @@
+# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+# SPDX-License-Identifier: Apache-2.0
+
+name: docs
+
+on:
+  pull_request:
+    types: [opened, synchronize, reopened]
+    paths:
+      - "docs/**"
+      - "README.md"
+      - "pyproject.toml"
+      - "uv.lock"
+      - ".github/workflows/docs.yaml"
+
+permissions:
+  contents: read
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.11"
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v4
+
+      - name: Install doc dependencies
+        run: uv sync --group docs
+
+      - name: Build docs (strict)
+        run: uv run --group docs sphinx-build -W -b html docs docs/_build/html