diff --git a/.agents/skills/nemoclaw-maintainer-day/MERGE-GATE.md b/.agents/skills/nemoclaw-maintainer-day/MERGE-GATE.md index 9a8cdfb0b13..48eaf418a3a 100644 --- a/.agents/skills/nemoclaw-maintainer-day/MERGE-GATE.md +++ b/.agents/skills/nemoclaw-maintainer-day/MERGE-GATE.md @@ -9,12 +9,13 @@ Run the last maintainer check before approval. Never merge automatically. For the full priority list see [PR-REVIEW-PRIORITIES.md](PR-REVIEW-PRIORITIES.md). A PR is approval-ready only when **all** hard gates pass: -1. **Contributor compliance** — the PR body contains the contributor's `Signed-off-by:` declaration and every PR commit appears as `Verified` in GitHub. Reject noncompliant PRs; maintainers do not repair contributor history. -2. **CI green** — all required checks in `statusCheckRollup`. -3. **No conflicts** — `mergeStateStatus` clean. -4. **No major CodeRabbit** — ignore style nits; block on correctness/security bugs. -5. **PR Review Advisor: merge_as_is** — `check-gates.ts` checks this automatically. The gate passes only when the latest advisor comment has `recommendation: merge_as_is`. All other recommendation values — including `blocked`, `needs_rework`, `merge_after_fixes`, `superseded`, `info_only`, and any unknown value — fail the gate. The referenced Actions run is validated (name, event, head SHA, run attempt, timestamp) before the recommendation is trusted. Correctness, security, acceptance, and test-depth findings block until addressed or explicitly judged false-positive by a maintainer. -6. **Risky code tested** — see [RISKY-AREAS.md](RISKY-AREAS.md). Confirm tests exist (added or pre-existing). +1. **Product scope approved** — confirm that the PR implements existing supported behavior or a linked, accepted product decision. Do not approve a new integration, solution, third-party stack, custom image, or canonical documentation surface merely because it works. Require defined ownership, lifecycle, compatibility, security, and validation expectations. Route independent solutions through [Community Solutions](../../../docs/resources/community-contributions.mdx). +2. **Contributor compliance** — the PR body contains the contributor's `Signed-off-by:` declaration and every PR commit appears as `Verified` in GitHub. Reject noncompliant PRs; maintainers do not repair contributor history. +3. **CI green** — all required checks in `statusCheckRollup`. +4. **No conflicts** — `mergeStateStatus` clean. +5. **No major CodeRabbit** — ignore style nits; block on correctness/security bugs. +6. **PR Review Advisor: merge_as_is** — `check-gates.ts` checks this automatically. The gate passes only when the latest advisor comment has `recommendation: merge_as_is`. All other recommendation values — including `blocked`, `needs_rework`, `merge_after_fixes`, `superseded`, `info_only`, and any unknown value — fail the gate. The referenced Actions run is validated (name, event, head SHA, run attempt, timestamp) before the recommendation is trusted. Correctness, security, acceptance, and test-depth findings block until addressed or explicitly judged false-positive by a maintainer. +7. **Risky code tested** — see [RISKY-AREAS.md](RISKY-AREAS.md). Confirm tests exist (added or pre-existing). ## Step 1: Run the Gate Checker @@ -23,11 +24,13 @@ node --experimental-strip-types --no-warnings .agents/skills/nemoclaw-maintainer ``` This checks all gates programmatically and returns structured JSON with `allPass`, per-gate `pass`/`details`, and non-blocking `advisories`, including contributor/approver overlap. Use [PR CI and Automated Review Follow-Up](../_shared/pr-follow-up.md) for the shared triage loop when individual findings need investigation. +The product-scope gate is a human decision and is not represented by `allPass`. ## Step 2: Interpret Results The script handles the deterministic checks. You handle judgment calls: +- **Product scope not established:** Stop before approval when the PR would create a new supported product surface and no accepted issue or design decision establishes ownership and lifecycle expectations. Technical correctness, successful tests, green CI, and `merge_as_is` advisor output do not substitute for product approval. Ask a maintainer for the product decision or route an independent solution through [Community Solutions](../../../docs/resources/community-contributions.mdx). - **Missing required checks:** The script verifies that `checks`, `commit-lint`, and `dco-check` are present in the status rollup. If any are missing, **workflows have not been triggered** — this happens on fork PRs from first-time contributors that need "Approve and run" clicked in the Actions tab. Go to the PR's Checks tab, approve the workflows, wait for all checks to complete, then re-run the gate checker. **Never approve a PR with missing checks.** - **Contributor compliance failed:** Reject the PR and ask the contributor to provide the PR-body DCO declaration or replace unverified commits with a clean verified history. Do not approve, merge, amend, sign, or force-push on the contributor's behalf. - **Contributor/approver overlap:** Surface `advisories.contributorApprovalOverlap` when the same account not recognized as automated by the supported login conventions appears as the current PR opener, commit author, or co-author and its latest opinionated review is approved. The invalid state detected here is contributor and approver identity overlap in the current GitHub PR metadata; the source boundary is the current opener plus all commit-author and review pages fetched through GitHub's GraphQL API. The advisory includes contributors whose commits remain in the current PR head at check time; it does not retain original push actors or authors removed when history is rebased, squashed, or fixed up. A clear result is not proof of independent approval. Missing, invalid, or conflicting review timestamps, or failure to retrieve complete paginated history, produce a warning because the latest opinion cannot be selected reliably. @@ -42,7 +45,7 @@ The script handles the deterministic checks. You handle judgment calls: ## Step 3: Approve or Report -**Approve only when:** `allPass` is true and `mergeStateStatus` is not DIRTY. `allPass` now includes the PR Review Advisor gate, so a blocked advisor comment alone prevents approval. Approving a PR with conflicts is wasted effort — the rebase will invalidate the approval. +**Approve only when:** the human product-scope gate passes, `allPass` is true, and `mergeStateStatus` is not DIRTY. `allPass` includes the deterministic PR Review Advisor gate but does not establish product approval. Approving a PR with conflicts is wasted effort — the rebase will invalidate the approval. The correct sequence for a conflicted PR: **salvage (rebase) → CI green → approve → report ready for merge.** diff --git a/.agents/skills/nemoclaw-maintainer-day/PR-REVIEW-PRIORITIES.md b/.agents/skills/nemoclaw-maintainer-day/PR-REVIEW-PRIORITIES.md index de9e15bb159..11610d6170c 100644 --- a/.agents/skills/nemoclaw-maintainer-day/PR-REVIEW-PRIORITIES.md +++ b/.agents/skills/nemoclaw-maintainer-day/PR-REVIEW-PRIORITIES.md @@ -7,13 +7,14 @@ Ordered list of what NemoClaw maintainers look for in a pull request. Higher ite ## Hard gates (all must pass to approve) -1. **Contributor compliance** — the PR body has the contributor's DCO declaration and every commit appears as `Verified` in GitHub. Maintainers reject noncompliant PRs and do not repair contributor history. -2. **Security correctness** — no sandbox escape, SSRF, credential exposure, policy bypass, or installer trust violation. PRs touching risky areas (see [RISKY-AREAS.md](RISKY-AREAS.md)) get a deep security pass before anything else. -3. **CI green** — all required checks in `statusCheckRollup` must pass. -4. **No merge conflicts** — `mergeStateStatus` must be clean. -5. **No unresolved major/critical CodeRabbit findings** — correctness and safety findings block; style nits do not. Use judgment on borderline cases. -6. **No unresolved actionable PR Review Advisor findings** — correctness, security, acceptance-coverage, and test-depth findings block unless explicitly judged false-positive. Ask the user before acting on ambiguous or design-changing advice. -7. **Tests for touched risky code** — risky areas must have test coverage, either added in the PR or pre-existing. No exceptions. +1. **Product scope approved** — the PR implements existing supported behavior or a linked, accepted product decision. Working code and green checks do not authorize a new integration, solution, third-party stack, custom image, or documentation surface. If ownership and lifecycle are not established, do not approve. Route independent solutions through [Community Solutions](../../../docs/resources/community-contributions.mdx). +2. **Contributor compliance** — the PR body has the contributor's DCO declaration and every commit appears as `Verified` in GitHub. Maintainers reject noncompliant PRs and do not repair contributor history. +3. **Security correctness** — no sandbox escape, SSRF, credential exposure, policy bypass, or installer trust violation. PRs touching risky areas (see [RISKY-AREAS.md](RISKY-AREAS.md)) get a deep security pass before anything else. +4. **CI green** — all required checks in `statusCheckRollup` must pass. +5. **No merge conflicts** — `mergeStateStatus` must be clean. +6. **No unresolved major/critical CodeRabbit findings** — correctness and safety findings block; style nits do not. Use judgment on borderline cases. +7. **No unresolved actionable PR Review Advisor findings** — correctness, security, acceptance-coverage, and test-depth findings block unless explicitly judged false-positive. Ask the user before acting on ambiguous or design-changing advice. +8. **Tests for touched risky code** — risky areas must have test coverage, either added in the PR or pre-existing. No exceptions. ## Quality expectations (block if violated, but fixable via salvage) @@ -44,3 +45,5 @@ Version labels activate release work; they are not readiness claims. If an open - **Code style and formatting** — not a reason to block or delay. No opportunistic reformatting. - **Documentation completeness** — not required for approval unless the PR changes user-facing behavior. - **Architectural elegance** — the goal is lower future merge pain, not aesthetic cleanup. + +Product scope approval is distinct from architectural elegance and remains a hard gate. diff --git a/.agents/skills/nemoclaw-maintainer-day/SKILL.md b/.agents/skills/nemoclaw-maintainer-day/SKILL.md index 84265521aef..d39c178ee6d 100644 --- a/.agents/skills/nemoclaw-maintainer-day/SKILL.md +++ b/.agents/skills/nemoclaw-maintainer-day/SKILL.md @@ -8,7 +8,7 @@ user_invocable: true Execute one pass of the maintainer loop, prioritizing version-targeted work. -**Autonomy:** push small fixes and approve when gates pass. Surface contributor/approver overlap reported by the merge gate as an advisory warning; it does not require another reviewer or change merge readiness. Never merge. Stop and ask for merge decisions, architecture decisions, and unclear contributor intent. +**Autonomy:** push small fixes and approve when gates pass. Surface contributor/approver overlap reported by the merge gate as an advisory warning; it does not require another reviewer or change merge readiness. Never merge. Stop and ask for merge decisions, product scope decisions, architecture decisions, and unclear contributor intent. ## References @@ -69,6 +69,7 @@ Keep unrelated `.agents/skills/` changes out of ordinary code or docs PRs. ## Stop and Ask When +- A PR would create a new supported product surface without an accepted product decision - Broad refactor or architecture decision needed - Contributor intent unclear and diff would change semantics - Multiple subsystems must change for CI diff --git a/AGENTS.md b/AGENTS.md index be5311830a4..0dfe85e4e26 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -9,6 +9,13 @@ NVIDIA NemoClaw is an open-source reference stack for running always-on AI agent Status: Active development. Interfaces may change without notice. +## Product Scope Gate + +Technical correctness, passing tests, and green CI do not establish product approval. +Before implementing or approving a change that creates a supported integration, solution recipe, custom image, third-party stack, or other product surface, confirm that an accepted issue or design decision establishes the scope and that ownership, lifecycle, compatibility, security, and validation expectations are defined. +If the product decision is missing, do not approve or document the contribution as canonical NemoClaw behavior. +Stop and request maintainer direction, or route an independent solution through [Community Solutions](docs/resources/community-contributions.mdx). + ## Agent Skills This repo ships agent skills under `.agents/skills/`. @@ -180,10 +187,11 @@ All hooks managed by [prek](https://prek.j178.dev/) (installed via `npm install` 1. Read `CONTRIBUTING.md` for the full contributor guide 2. Before coding, state what success looks like. Ask only when a choice changes behavior, security, data safety, or a supported contract. Then make the smallest change that works. For a QA-escaped defect, also add the test or diagnostic that should have caught it. -3. For a first-time checkout, use `.agents/skills/nemoclaw-contributor-onboard/SKILL.md` or run `npm run dev:setup` -4. Run `npm run dev:doctor` to verify the contributor environment without changing it -5. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval for host-visible CLI exposure -6. Run the tests targeted to the behavior you change once per relevant change set; rerun them after later edits or hook autofixes that can affect that behavior +3. Apply the product scope gate above before implementing or approving a new supported surface +4. For a first-time checkout, use `.agents/skills/nemoclaw-contributor-onboard/SKILL.md` or run `npm run dev:setup` +5. Run `npm run dev:doctor` to verify the contributor environment without changing it +6. Use `./scripts/dev-setup.sh --expose-cli` only with explicit approval for host-visible CLI exposure +7. Run the tests targeted to the behavior you change once per relevant change set; rerun them after later edits or hook autofixes that can affect that behavior ### Plain Language and Direct Design diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6c82245082a..8b1b20f4453 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,7 +20,7 @@ We welcome many types of contributions: | **Tests** | New or improved test coverage in `test/` or `nemoclaw/test/` | | **Feature proposals** | Proposals that state the problem and desired behavior before implementation | | **Integrations** | Support for new inference backends, providers, or tools | -| **Examples** | Worked usage examples added under `docs/` | +| **Examples** | Product-supported examples under `docs/`, or independent solutions routed through [Community Solutions](docs/resources/community-contributions.mdx) | Security vulnerabilities must follow [SECURITY.md](SECURITY.md) — **not** GitHub issues. @@ -34,6 +34,7 @@ Before starting larger work: - Start a [GitHub Discussion](https://github.com/NVIDIA/NemoClaw/discussions) before writing code for significant changes. - Open an issue after the problem, desired behavior, and current constraints are clear enough for maintainer review. - For questions, open a [GitHub Discussion](https://github.com/NVIDIA/NemoClaw/discussions) or comment on a related issue. +- Confirm whether an integration, recipe, custom image, or end-to-end solution is an approved NemoClaw product surface or belongs in NemoClaw Community. Before editing, translate the request or issue into observable success criteria and define the intended change boundary. State assumptions only when they materially affect behavior, security, data safety, or a supported contract. @@ -409,6 +410,15 @@ In the issue or pull-request narrative, record the product root cause, why the e Search adjacent code paths for the same failure class within a bounded scope; fix adjacent instances only when they share the root cause and fit the current change, otherwise report them separately. Keep the analysis proportionate to the escaped defect and avoid assigning individual blame; ordinary defects do not require a heavyweight RCA. +### Product Scope Approval + +Technical correctness and green CI are necessary, but they do not establish product approval. +A pull request must not define a new supported integration, solution workflow, custom image, third-party stack, or documentation surface without prior maintainer alignment on product scope. + +Before opening or approving such a PR, confirm that an accepted issue or design decision defines the intended product behavior, ownership, compatibility and upgrade expectations, security review, lifecycle support, and validation boundary. +If that decision is missing, stop implementation or review and request maintainer direction. +Route independent solutions, complete use-case examples, and third-party integrations through [Community Solutions](docs/resources/community-contributions.mdx). + ### DCO Sign-Off This project requires a [Developer Certificate of Origin (DCO)](https://developercertificate.org/) sign-off declaration in every pull request description. @@ -444,6 +454,9 @@ Do not add links to third-party code repositories, community collections, or uno Links to official documentation for tools we depend on (e.g., Node.js and Python) and industry standards (e.g., Conventional Commits) are acceptable. +The project-owned NVIDIA NemoClaw Community repository is the designated destination for independent solutions. +Use the canonical [Community Solutions](docs/resources/community-contributions.mdx) page to route contributors there instead of adding direct repository links throughout the docs. + **Why:** External repositories are outside our control. They can change ownership, inject malicious content, or misrepresent an endorsement by NVIDIA. Keeping references within our own repo avoids these risks entirely. If you believe an external resource belongs in our docs, open an issue to discuss it with maintainers first. diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index faa62a365bd..1b1d3f3b1fb 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -17,6 +17,17 @@ Update documentation when your change: - Fixes a bug that the docs describe incorrectly. - Changes an API, protocol, or policy schema. +## Confirm Product Scope Before Writing Docs + +Canonical documentation describes behavior that NemoClaw has chosen to support and maintain. +A documentation PR must not establish a new supported integration, solution workflow, custom image, third-party stack, or product surface by itself. + +Technical correctness, successful builds, and working examples are necessary evidence, but they are not product approval. +Before documenting a new surface, confirm that an accepted issue or design decision defines ownership, compatibility and upgrade expectations, security review, lifecycle support, and validation. + +Route independent solutions, complete use-case examples, and third-party integrations through [Community Solutions](resources/community-contributions.mdx). +If the correct destination is unclear, request maintainer direction before drafting the page. + ## Update Docs with Contributor Skills If you use an AI coding agent (Cursor, Claude Code, Codex, etc.), the repo includes the `nemoclaw-contributor-update-docs` skill that automates doc work. @@ -276,6 +287,9 @@ feat(cli): add policy-add command When reviewing documentation: +- Confirm that the page documents an approved and maintained NemoClaw product surface. +- Do not approve a new integration or solution solely because its instructions work or its checks pass. +- Route independent third-party solutions to [Community Solutions](resources/community-contributions.mdx) when no product decision establishes core ownership. - Check that the style guide rules above are followed. - Watch for LLM-generated patterns (excessive bold, em dashes, filler). - Verify code examples are accurate and runnable. diff --git a/docs/about/ecosystem-deepagents.mdx b/docs/about/ecosystem-deepagents.mdx index 4d55f2d22a5..af6ab433235 100644 --- a/docs/about/ecosystem-deepagents.mdx +++ b/docs/about/ecosystem-deepagents.mdx @@ -100,4 +100,4 @@ Use the following table to choose NemoClaw or custom OpenShell integration. - [Quickstart with Deep Agents](../get-started/quickstart) installs NemoClaw and launches your first Deep Agents sandbox. - [Choose an Inference Provider](../inference/learn-and-choose/choose-inference-provider) explains provider choices and the `inference.local` route. - [Deep Agents Code overview](https://docs.langchain.com/oss/python/deepagents/code/overview) explains upstream `dcode` capabilities and commands. -- [NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community) collects community-driven blueprint examples, showcases, and integrations that demonstrate complete blueprint patterns. +- [Community Solutions](../resources/community-contributions) explains how to contribute community-driven examples, showcases, and complete blueprint patterns. diff --git a/docs/about/ecosystem-hermes.mdx b/docs/about/ecosystem-hermes.mdx index ecfaba53bcc..66c075fc648 100644 --- a/docs/about/ecosystem-hermes.mdx +++ b/docs/about/ecosystem-hermes.mdx @@ -100,4 +100,4 @@ Use the following table to choose NemoHermes or OpenShell. - [How It Works](how-it-works) describes how NemoClaw runs, the blueprint, sandbox creation, routing, and protection layers for Hermes. - [Architecture](../reference/architecture) shows the repository structure and technical diagrams. - [Quickstart with Hermes](../get-started/quickstart) installs NemoClaw and launches your first Hermes sandbox. -- [NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community) collects community-driven examples, showcases, and integrations that demonstrate complete blueprint patterns. +- [Community Solutions](../resources/community-contributions) explains how to contribute community-driven examples, showcases, and complete blueprint patterns. diff --git a/docs/about/ecosystem.mdx b/docs/about/ecosystem.mdx index 14b34da1981..010c524ad95 100644 --- a/docs/about/ecosystem.mdx +++ b/docs/about/ecosystem.mdx @@ -99,4 +99,4 @@ Use the following table to choose NemoClaw or OpenShell. - [Overview](overview) defines NemoClaw's capabilities, benefits, and use cases. - [How It Works](how-it-works) describes how NemoClaw runs, including the plugin, blueprint, sandbox creation, routing, and protection layers. - [Architecture](../reference/architecture) shows the repository structure and technical diagrams. -- [NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community) collects community-driven examples, showcases, and integrations that demonstrate complete blueprint patterns. +- [Community Solutions](../resources/community-contributions) explains how to contribute community-driven examples, showcases, and complete blueprint patterns. diff --git a/docs/about/overview.mdx b/docs/about/overview.mdx index 108b97f9f0f..915d8e2a060 100644 --- a/docs/about/overview.mdx +++ b/docs/about/overview.mdx @@ -96,7 +96,7 @@ Use these topics to learn more about NemoClaw and how to install and use it. - Read [Ecosystem](ecosystem) to understand how your agent, OpenShell, and NemoClaw relate in the wider stack, and when to use NemoClaw versus OpenShell. - Follow [Quickstart with OpenClaw](../get-started/quickstart) to install NemoClaw and run your first OpenClaw sandbox. - Read [AI Agent Docs](../resources/agent-skills) to let your AI coding assistant fetch NemoClaw Markdown docs. -- Explore [NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community) for community-driven blueprint examples, showcases, and integrations. +- Review [Community Solutions](../resources/community-contributions) for community-driven blueprint examples, showcases, and integrations. - Read [Choose an Inference Provider](../inference/learn-and-choose/choose-inference-provider) to check the inference providers that NemoClaw supports and how inference routing works. @@ -106,7 +106,7 @@ Use these topics to learn more about NemoClaw and how to install and use it. - Read [Ecosystem](ecosystem) to understand how Hermes, OpenShell, and NemoClaw relate in the wider stack, and when to use NemoClaw versus OpenShell. - Follow [Quickstart with Hermes](../get-started/quickstart) to install NemoClaw and run your first Hermes sandbox with `$$nemoclaw`. - Read [AI Agent Docs](../resources/agent-skills) to let your AI coding assistant fetch NemoClaw Markdown docs. -- Explore [NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community) for community-driven blueprint examples, showcases, and integrations. +- Review [Community Solutions](../resources/community-contributions) for community-driven blueprint examples, showcases, and integrations. - Read [Choose an Inference Provider](../inference/learn-and-choose/choose-inference-provider) to check the inference providers that NemoClaw supports and how inference routing works. @@ -116,7 +116,7 @@ Use these topics to learn more about NemoClaw and how to install and use it. - Read [Ecosystem](ecosystem) to understand how Deep Agents, OpenShell, and NemoClaw relate in the wider stack, and when to use NemoClaw versus OpenShell. - Follow [Quickstart with Deep Agents](../get-started/quickstart) to install NemoClaw and run your first Deep Agents sandbox with `$$nemoclaw`. - Read [AI Agent Docs](../resources/agent-skills) to let your AI coding assistant fetch NemoClaw Markdown docs. -- Explore [NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community) for community-driven blueprint examples, showcases, and integrations. +- Review [Community Solutions](../resources/community-contributions) for community-driven blueprint examples, showcases, and integrations. - Read [Choose an Inference Provider](../inference/learn-and-choose/choose-inference-provider) to check the inference providers that NemoClaw supports and how inference routing works. diff --git a/docs/index.mdx b/docs/index.mdx index c604ddd2ea1..edf7e4dc170 100644 --- a/docs/index.mdx +++ b/docs/index.mdx @@ -108,9 +108,9 @@ Use the following resources to explore NemoClaw end-to-end examples, showcases, - + -Browse community-driven examples, showcases, and integrations built from NemoClaw blueprints. +Learn where to contribute third-party solutions, showcases, and integrations built with NemoClaw. Examples diff --git a/docs/index.yml b/docs/index.yml index 166009daa06..25a036a0ba2 100644 --- a/docs/index.yml +++ b/docs/index.yml @@ -287,8 +287,9 @@ navigation: - page: "AI Agent Docs" path: _build/agent-variants/resources/agent-skills.openclaw.generated.mdx slug: agent-skills - - link: "Community Examples" - href: https://github.com/NVIDIA/nemoclaw-community + - page: "Community Solutions" + path: _build/agent-variants/resources/community-contributions.openclaw.generated.mdx + slug: community-contributions - link: "Discord" href: https://discord.gg/XFpfPv9Uvx - link: "Report Vulnerabilities" @@ -498,8 +499,9 @@ navigation: - page: "AI Agent Docs" path: _build/agent-variants/resources/agent-skills.deepagents.generated.mdx slug: agent-skills - - link: "Community Examples" - href: https://github.com/NVIDIA/nemoclaw-community + - page: "Community Solutions" + path: _build/agent-variants/resources/community-contributions.deepagents.generated.mdx + slug: community-contributions - link: "Report Vulnerabilities" href: https://github.com/NVIDIA/NemoClaw/blob/main/SECURITY.md - page: "License" @@ -756,8 +758,9 @@ navigation: - page: "AI Agent Docs" path: _build/agent-variants/resources/agent-skills.hermes.generated.mdx slug: agent-skills - - link: "Community Examples" - href: https://github.com/NVIDIA/nemoclaw-community + - page: "Community Solutions" + path: _build/agent-variants/resources/community-contributions.hermes.generated.mdx + slug: community-contributions - link: "Report Vulnerabilities" href: https://github.com/NVIDIA/NemoClaw/blob/main/SECURITY.md - page: "License" diff --git a/docs/network-policy/integration-policy-examples.mdx b/docs/network-policy/integration-policy-examples.mdx index e031421c0f8..5f9b866a153 100644 --- a/docs/network-policy/integration-policy-examples.mdx +++ b/docs/network-policy/integration-policy-examples.mdx @@ -15,7 +15,7 @@ import { AgentOnly } from "../_components/AgentGuide"; Use these examples when a sandbox is already installed and an integration needs network access. This page covers only integrations that NemoClaw currently ships as maintained policy preset YAML under `nemoclaw-blueprint/policies/presets/`. -For complete blueprint examples that combine a model, agent harness, OpenShell policy, and integration workflow, refer to [NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community). +For complete blueprint examples that combine a model, agent harness, OpenShell policy, and integration workflow, refer to [Community Solutions](../resources/community-contributions). Integration setup usually has two separate parts: - Configure the integration itself, such as a bot token, OAuth credential, or agent plugin setting. diff --git a/docs/resources/community-contributions.mdx b/docs/resources/community-contributions.mdx new file mode 100644 index 00000000000..cb5655a9967 --- /dev/null +++ b/docs/resources/community-contributions.mdx @@ -0,0 +1,84 @@ +--- +# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. +# SPDX-License-Identifier: Apache-2.0 +title: "Contribute Community Solutions" +sidebar-title: "Community Solutions" +description: "Choose whether a solution belongs in the canonical NemoClaw repository or the NVIDIA NemoClaw Community repository." +description-agent: "Routes third-party solutions, custom integrations, recipes, custom images, and end-to-end examples to NemoClaw Community unless maintainers approved them as a supported NemoClaw product surface. Use when submitting or reviewing a contribution that may create product scope." +keywords: ["nemoclaw community contributions", "nemoclaw third-party integrations", "nemoclaw examples", "nemoclaw product scope"] +content: + type: "concept" +--- + +NemoClaw's canonical documentation describes behavior that the project has chosen to support and maintain. +The [NVIDIA NemoClaw Community](https://github.com/NVIDIA/nemoclaw-community) repository hosts community-driven examples, showcases, custom integrations, and complete solution workflows. + +A solution can work correctly from an engineering perspective without becoming a supported NemoClaw product surface. + + +Passing tests, building successfully, or working in one environment does not establish product approval. +Canonical documentation creates an ongoing commitment to compatibility, security review, lifecycle support, and maintenance. + + +## Choose the Contribution Destination + +Use the repository whose ownership model matches the contribution. + +| Contribution | Destination | +|---|---| +| Documentation for behavior already implemented and maintained by NemoClaw | Canonical NemoClaw repository | +| Implementation of an accepted NemoClaw issue or design | Canonical NemoClaw repository | +| Third-party tool integration or custom image that NemoClaw does not ship | NemoClaw Community repository | +| End-to-end solution for a specific use case | NemoClaw Community repository | +| Showcase, deployment recipe, or complete blueprint pattern | NemoClaw Community repository | +| Proposal for a new supported product surface | NemoClaw Discussion before implementation or documentation | + +## Use the Canonical Repository + +Submit a product or documentation contribution to the canonical NemoClaw repository only when all of the following conditions are satisfied. + +- The contribution implements existing supported behavior or an accepted product decision. +- The affected functionality has a clear maintainer and long-term ownership model. +- Compatibility, upgrade, security, and lifecycle expectations are defined. +- Tests validate the supported behavior at the appropriate runtime boundary. +- The documentation describes the maintained implementation instead of serving as its first definition. + +If a contribution would make users reasonably believe that NemoClaw supports a new integration, workflow, or third-party stack, obtain maintainer alignment on that product decision before opening the implementation or documentation PR. + +## Use the Community Repository + +Submit a solution to NemoClaw Community when it combines NemoClaw with components or workflows that the core project does not maintain. + +Common community contributions include: + +- Custom sandbox images and third-party tool stacks. +- Application-specific agents and automation workflows. +- Complete blueprints that combine an agent, model, policy, and integration. +- Deployment recipes and showcases for particular environments. +- Working solutions that demonstrate demand for a possible future product capability. + +Follow the contribution and review requirements in the NemoClaw Community repository. +Community placement does not imply that the solution is insecure or low quality. +It keeps ownership and support expectations accurate while allowing users to share useful work. + +## Propose Promotion into NemoClaw + +A community solution may later become a supported NemoClaw capability. + +Start a [NemoClaw Discussion](https://github.com/NVIDIA/NemoClaw/discussions) to establish product scope, ownership, lifecycle expectations, and acceptance criteria. +If maintainers accept the proposal, implement and validate the supported capability before adding it to the canonical documentation. + +## Review Product Scope Before Approval + +Reviewers must evaluate product alignment before technical merge readiness. + +Ask the following questions: + +- Does the PR document or implement behavior that NemoClaw already supports? +- Would merging the PR create a new support promise or product surface? +- Is there an accepted issue or design decision for that scope? +- Who owns compatibility, upgrades, security review, testing, and user support? +- Would the contribution remain valuable as a community solution without becoming a core feature? + +Do not approve a PR only because the implementation works or automated checks pass. +When the product decision is missing, request maintainer alignment or route the contribution to NemoClaw Community.