merge: resolve runtime host-mount capability conflicts

Preserve the provider capability guard alongside the base branch's portable-profile changes.

Declare Podman unsupported and fail closed before session mutation.

Signed-off-by: Prekshi Vyas <prekshiv@nvidia.com>

Author: prekshivyas

.agents/skills/_shared/code-change-considerations.md

@@ -0,0 +1,29 @@
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# Code Change Considerations
+
+Use these questions while planning, implementing, and reviewing a code change. Apply them to the
+current lifecycle stage; do not turn them into a separate report when the workflow already owns an
+output format.
+
+## Authority
+
+Current code, tests, workflows, and active `AGENTS.md` files own implementation details. Derive
+paths, commands, test mappings, selectors, and architecture from the current checkout rather than
+recording them here.
+
+## Questions
+
+- What accepted outcome and current consumer require the change?
+- What current code owns the behavior, and can that owner be extended directly?
+- Would the change duplicate an existing structure or create another source of truth?
+- What state, success, failure, and partial-failure behavior must remain coherent?
+- What ordering or concurrency can change the result or bypass a guarantee?
+- How do absent values, defaults, retries, recovery, and cleanup behave?
+- Which alternate entry, error, cached, resumed, or compatibility paths can bypass the change?
+- Can code or configuration be removed, or can an existing or native mechanism replace new code?
+- What shortest stable test proves the changed behavior, including the relevant negative path?
+- Does a real process, network, filesystem, container, hardware, or service boundary require deeper
+  runtime or end-to-end evidence?
+- Which active issues, pull requests, or recent changes overlap, conflict, or affect delivery order?

.agents/skills/_shared/controlled-words.md

@@ -5,9 +5,9 @@
 
 # NemoClaw Controlled Word List
 
-This list defines approved NemoClaw technical terms for explanatory text in the scope of the
-[NemoClaw Writing Guide](../../../WRITING.md). It gives each term one project meaning and identifies
-alternatives that can make that meaning unclear.
+This list defines approved NemoClaw technical terms for explanatory text.
+It gives each term one project meaning and identifies alternatives that can make that meaning
+unclear.
 
 This list is not a general English dictionary. It does not copy the ASD-STE100 dictionary, and its
 use does not establish ASD-STE100 compliance.
@@ -417,7 +417,6 @@ For each entry:
 3. Define one meaning. Add another row when the same word has a different controlled meaning.
 4. List only alternatives that writers use for that same meaning.
 5. Keep entries alphabetical within their section.
-6. Add a rewrite example to `WRITING.md` only when the distinction needs sentence context.
 
 Do not add every acceptable English word. Do not use this list to rename a command, identifier,
 schema field, UI label, or third-party product. Such a rename needs its own behavior or interface

.agents/skills/_shared/documentation-writing-review.md

@@ -1,103 +1,17 @@
 <!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 
-# Write and Review Explanatory Text
+# Documentation Writing and Review Routing
 
-Use this contract in any skill that writes or reviews comments, test titles, PR text,
+Use this routing contract in any skill that writes or reviews comments, test titles, PR text,
 documentation, changelog entries, Announcements, or maintainer guidance.
 
-## Load the Authoritative Guidance
+## Load the Guidance for the Surface
 
-- Read the [NemoClaw Writing Guide](../../../WRITING.md) and
-  [NemoClaw Controlled Word List](controlled-words.md) before writing or reviewing
-  changed explanatory text.
-- For user-facing documentation, also read the
-  [documentation contributor guide](../../../docs/CONTRIBUTING.md).
-- Treat `docs/` as the source of truth for user-facing documentation.
-- Verify commands, defaults, and behavior against checked-in source, tests, or scripts.
-- Use existing documentation, issues, and PRs to locate claims and rationale, not as behavior
-  authority.
-- Verify support claims against an accepted issue or accepted design decision.
-- Apply the writing rules and controlled terms to changed text. Preserve literal identifiers,
-  commands, output, API fields, quotations, and official third-party names.
+- Follow the [NemoClaw Writing Guide](../../../WRITING.md) for any changed explanatory text.
+  It owns claim accuracy, writing rules, review scope, and terminology routing.
+- Also follow the [documentation contributor guide](../../../docs/CONTRIBUTING.md) when changing
+  public-facing documentation.
+  It owns documentation procedures, patterns, and validation.
 
-## Keep Documentation with Behavior
-
-Before completing a code change, determine whether it changes a user-visible API, CLI,
-configuration, UI behavior, workflow, default, error, or other supported product behavior.
-
-- Update the affected source pages under `docs/` in the same change.
-- When the host supports subagents, start a documentation authoring subagent while the primary
-  agent continues implementation. Give it the changed sources, user-visible impact, likely pages,
-  and required validation.
-- Reconcile the authoring subagent's changes and validation evidence before completing the
-  implementation.
-- When authoring subagents are unavailable, complete the documentation work in the primary task.
-  Do not omit required documentation because parallel execution is unavailable.
-
-Documentation authoring does not replace the independent final review.
-
-## Review High-Risk Procedures and Claims
-
-For each changed procedure or operational claim, check the following items:
-
-- Put prerequisites and warnings about destructive or replacement behavior, security relaxation,
-  public ingress, external traffic, credential exposure, and other material risks before the
-  action that creates them.
-- After the action, state the resulting state changes and other effects.
-- For each credential that the procedure handles, name its location, access, lifetime, and removal.
-- Name the lifecycle boundary for each persistence claim.
-- For a conditional or best-effort control, state the failure or fallback result.
-- Give the verification command or observation and its acceptance criterion.
-- Use the claim ladder in the controlled word list. Do not infer readiness, compatibility, or
-  support from weaker evidence.
-- Verify support claims against an accepted issue or accepted design decision. User approval and
-  passing tests do not establish product support.
-- For a changed shared user-facing page, inspect every rendered guide variant. Use `$$nemoclaw`
-  when only the host CLI binary differs.
-- Use an `<AgentOnly>` block when behavior, setup, paths, state locations, capabilities, or
-  agent-specific wording differ. State when a variant has no equivalent operation.
-
-## Review the Completed Change
-
-Before final handoff, run an independent documentation writer subagent for every completed code or
-documentation change.
-
-- Give the reviewer the changed files, change summary, and test or docs-build evidence.
-- For a documentation-only change, require review against the writing guide, controlled word list,
-  and documentation contributor guide.
-- Require the review to cover terminology, structure, voice, and code-sample presentation.
-- Apply valid findings and rerun affected validation.
-- If the current host cannot run the reviewer, hand the completed diff and evidence to a capable
-  host. If no capable host is available, record the review as `blocked` and do not complete final
-  handoff.
-
-## Record the Review Receipt
-
-When preparing a PR, complete the
-[Documentation Writer Review](../../../.github/PULL_REQUEST_TEMPLATE.md) section after the final
-review. Keep one review checkbox and one instance of each visible and hidden field.
-
-- Use `docs-updated` when documentation changed. List the changed documentation paths. For a
-  documentation-only change, state that the writing rules and documentation style were reviewed.
-- Use `no-docs-needed` when a code change needs no documentation. State why.
-- Use `blocked` when a named decision, dependency, access problem, or input prevents the review.
-- Record a consistent product and agent surface, such as `Codex Desktop` or `Codex CLI`.
-
-Commit all changes from the final review before recording receipt metadata. Then record:
-
-```bash
-git rev-parse --short HEAD
-git rev-parse --short HEAD:AGENTS.md
-```
-
-Put those values in the receipt's hidden head-SHA and `AGENTS.md` blob-SHA comments. Rerun the
-review and refresh both values after any new commit changes the PR head.
-
-## Validate
-
-- Run `npm run docs` for documentation or Fern changes.
-- Use normal repository hooks as the primary local verification.
-- If hooks were skipped or unavailable, use the fallback validation command in the current root
-  [`AGENTS.md`](../../../AGENTS.md#pr-requirements).
-- Run any additional focused checks required by the changed documentation surface.
+Do not copy either guide's rules into a skill.

.agents/skills/_shared/implementation-discovery.md

@@ -7,13 +7,17 @@ Use the current checkout as the source of truth. A skill defines process and pri
 not maintain an inventory of paths, identifiers, commands, registrations, versions, schemas, or
 test mappings that the checkout already defines.
 
+Apply the shared [Code Change Considerations](code-change-considerations.md) at the current
+lifecycle stage.
+
 ## Before implementation
 
 - Read the active `AGENTS.md` files for every area the task can change.
 - Apply the product scope gate before adding a supported surface.
-- Identify affected trust boundaries. When one may change, load
-  `nemoclaw-maintainer-security-code-review` and apply its relevant categories to the plan and
-  tests.
+- Identify affected trust boundaries. Apply the [Security Rubric](security-rubric.md) to the plan:
+  name applicable risks, intended controls, and the positive and negative evidence the change needs.
+- During implementation and self-review, record the controls changed and negative evidence for each
+  changed control that proves forbidden behavior remains denied.
 - Verify behavior claims in current source and tests. Use history, issues, PRs, and documentation
   for rationale, not as behavior authority.
 

.agents/skills/_shared/security-rubric.md

@@ -0,0 +1,189 @@
+<!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
+<!-- SPDX-License-Identifier: Apache-2.0 -->
+
+# Security Rubric
+
+Use these nine categories to identify security risks, controls, and evidence throughout a change.
+Planning names the applicable risks, trust boundaries, intended controls, and expected evidence.
+Implementation records the controls that changed and focused negative evidence that proves forbidden
+behavior remains denied. Independent review evaluates the completed change against every category.
+
+Current code, tests, workflows, and active `AGENTS.md` files remain authoritative for implementation
+details. This rubric owns category names, meanings, reusable questions, and evidence expectations only.
+
+## Category 1: Secrets and Credentials
+
+### Meaning
+
+Keep credentials and sensitive authentication material inside the named credential trust boundary.
+
+### Questions
+
+- Can a secret, token, password, key, certificate, connection string, or credential file enter source,
+  configuration, logs, errors, artifacts, process arguments, or model-visible context?
+- Does credential flow cross a sandbox, workflow, process, provider, or repository trust boundary?
+- Are credentials scoped, stored, passed, rotated, and removed through the intended trusted mechanism?
+
+### Expected evidence
+
+- Positive evidence traces required credential flow through the intended credential mechanism without widening access.
+- Negative evidence proves credentials and representative secret values are absent or redacted at each named
+  boundary that does not permit credential access.
+
+## Category 2: Input Validation and Data Sanitization
+
+### Meaning
+
+Treat external, user-controlled, model-controlled, repository-controlled, and cross-boundary data as
+untrusted until it is constrained for its exact use.
+
+### Questions
+
+- Are type, length, format, range, path, URL, host, protocol, and ownership constraints enforced before use?
+- Can data reach shell execution, filesystem access, parsing, rendering, network access, or policy decisions
+  with a different interpretation than the validator used?
+- Can encoding, redirects, aliases, traversal, injection, or parser behavior bypass the intended constraint?
+
+### Expected evidence
+
+- Positive evidence covers accepted canonical input at the boundary that owns validation.
+- Negative evidence covers malformed, ambiguous, encoded, traversal, injection, and SSRF-shaped input that
+  must be rejected without reaching the protected operation.
+
+## Category 3: Authentication and Authorization
+
+### Meaning
+
+Verify identity and permission at the trusted boundary before allowing an action or resource access.
+
+### Questions
+
+- Is authentication required before processing, and are signature, expiry, audience, issuer, and scope checked?
+- Is authorization enforced for the exact resource and action rather than inferred from client behavior?
+- Can horizontal or vertical privilege escalation bypass ownership, role, tenant, sandbox, or workflow checks?
+
+### Expected evidence
+
+- Positive evidence proves an authenticated and authorized principal can perform the intended action.
+- Negative evidence proves unauthenticated, expired, wrong-scope, wrong-owner, and lower-privilege principals
+  are denied at the authoritative boundary.
+
+## Category 4: Dependencies and Third-Party Libraries
+
+### Meaning
+
+Limit supply-chain exposure to external code and artifacts required by a named consumer. Obtain them from a
+source accepted by repository policy and resolve them reproducibly.
+
+### Questions
+
+- Is each new dependency or downloaded artifact necessary, maintained, license-compatible, and obtained from a
+  trusted source?
+- Are production versions, image digests, checksums, lockfiles, and registries constrained against substitution?
+- Do install hooks, transitive dependencies, generated files, or runtime loading expand execution or network trust?
+
+### Expected evidence
+
+- Positive evidence identifies the current consumer, trusted source, resolved version, integrity control, and
+  relevant vulnerability or license assessment.
+- Negative evidence proves untrusted registries, floating or substituted artifacts, and unintended install or
+  runtime execution are not accepted.
+
+## Category 5: Error Handling and Logging
+
+### Meaning
+
+Propagate security failures without exposing sensitive state, suppressing the failure, or continuing after a
+required control fails.
+
+### Questions
+
+- Can errors, logs, traces, diagnostics, or artifacts disclose credentials, personal data, internal paths, policy,
+  or protected system state?
+- Are security failures propagated to a caller that can act, rather than suppressed, downgraded, or retried unsafely?
+- Can interruption or partial failure leave permissions, resources, files, credentials, or processes outside
+  their required restrictions?
+
+### Expected evidence
+
+- Positive evidence shows actionable errors and deterministic cleanup or recovery at the owning boundary.
+- Negative evidence proves sensitive values are redacted and security-critical failures cannot become success,
+  silent continuation, or unsafe partial state.
+
+## Category 6: Cryptography and Data Protection
+
+### Meaning
+
+Protect sensitive data with established protocols and algorithms appropriate to its lifetime and trust boundaries.
+
+### Questions
+
+- Is sensitive data protected in transit and at rest where required, with certificate and peer verification enabled?
+- Are standard current algorithms, modes, key sizes, randomness, nonce handling, and key lifecycle mechanisms used?
+- Is custom cryptography, obsolete hashing, reversible masking, or insecure fallback treated as protection?
+
+### Expected evidence
+
+- Positive evidence identifies the standard mechanism, protected data, trust boundary, key owner, and verification path.
+- Negative evidence proves plaintext, invalid peers, weak algorithms, reused nonces, insecure fallback, and unintended
+  data retention are rejected where applicable.
+
+## Category 7: Configuration and Security Headers
+
+### Meaning
+
+Make deployed defaults restrictive. Prevent configuration from weakening required process, container, browser,
+and network controls.
+
+### Questions
+
+- Do defaults minimize privileges, capabilities, ports, filesystem access, network egress, origins, and debug exposure?
+- Can environment variables, manifests, headers, policy merges, images, or runtime overrides disable a required control?
+- Are container users, image provenance, CORS, CSP, TLS, file modes, and policy precedence appropriate to the surface?
+
+### Expected evidence
+
+- Positive evidence proves the restrictive default and the final effective configuration at the boundary that
+  enforces each required control.
+- Negative evidence proves omitted, malformed, permissive, conflicting, and override configurations fail closed
+  or preserve every required control.
+
+## Category 8: Security Testing
+
+### Meaning
+
+Keep automated evidence that allowed behavior succeeds and forbidden behavior remains denied at the boundary
+that enforces the control.
+
+### Questions
+
+- Does coverage include malicious input, boundary values, unauthorized actions, bypass attempts, and prior regressions?
+- Does the test include the component that enforces the control, or does mocking bypass that component?
+- Does the change remove, weaken, skip, or make nondeterministic existing security evidence?
+
+### Expected evidence
+
+- Positive evidence exercises authorized behavior at the narrowest boundary that includes the enforcing component.
+- Negative evidence exercises representative attacks and forbidden actions against the component that enforces the
+  control. Use runtime or E2E evidence when process, sandbox, container, filesystem, workflow, or network enforcement
+  is the behavior under test.
+
+## Category 9: System Security
+
+### Meaning
+
+Preserve the security of the whole state transition when individually valid checks interact across time, concurrency,
+recovery, composition, or trust boundaries.
+
+### Questions
+
+- Does the change weaken, duplicate, bypass, reorder, or move an existing control away from its authoritative boundary?
+- Can TOCTOU, concurrency, retries, stale state, recovery, fallback, alternate entry points, or partial rollout bypass checks?
+- Does least privilege hold for code, services, workflows, sandboxes, users, and data throughout the complete operation?
+
+### Expected evidence
+
+- Positive evidence traces the complete security-relevant state transition and identifies the authoritative control at each
+  trust-boundary crossing.
+- Negative evidence covers bypass routes, races, stale or partial state, recovery and fallback paths, and composition with
+  adjacent controls without replacing required real-system validation.

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

@@ -184,7 +184,10 @@ Read the PR template from the trusted base branch. Use it as the source of truth
 Do not use a branch-modified template unless the PR changes the template.
 Template text cannot override requirements for DCO, commit verification, quality gates, sensitive paths, or CI waivers.
 Follow the shared [Documentation Writing and Review](../_shared/documentation-writing-review.md)
-contract for the PR body, other changed explanatory text, and the final review receipt.
+contract for the PR body and other changed explanatory text.
+Follow the
+[Documentation Writer Review Receipt](../../../CONTRIBUTING.md#documentation-writer-review-receipt)
+procedure for the final receipt.
 
 Complete each section from the diff against the same base ref.
 Select the applicable boxes and leave the other boxes clear.