docs(contributing): route community solutions

.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.**
 

.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.

.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

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
 

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.

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.

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.