Merge branch 'main' into fix/9291-hermes-api-route-only-port

Author: rluo8

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

@@ -341,7 +341,7 @@ For a persistence claim, name the applicable `stop` and `start`, `restart`, `reb
 | `contributor` | Technical noun | A person or agent that proposes or authors a repository change. | developer, submitter |
 | `docs build` | Technical noun | The repository command and result that validate and render the documentation source. | docs test, site build |
 | `documentation-only PR` | Technical noun | A PR whose diff changes explanatory documentation but no executable or behavior-affecting source. | docs PR when scope is not clear |
-| `documentation writer review` | Technical noun | The required review that determines documentation impact for a code change and checks changed explanatory text against repository writing and documentation rules. | docs review, writing pass |
+| `documentation writer review` | Technical noun | The independent review that checks a workflow-produced documentation candidate or direct documentation-only change against repository writing and documentation rules. | docs review, writing pass |
 | `E2E test` | Technical noun | A test that exercises a complete user journey across integrated components. | integration test when the full journey is not exercised |
 | `evidence` | Technical noun | A reproducible result or artifact tied to the revision, environment, and claim it supports. | proof without the supporting result, observation |
 | `feature branch` | Technical noun | A non-default Git branch that contains one proposed change. | working branch, PR branch before a PR exists |

.agents/skills/_shared/pr-follow-up.md

@@ -118,21 +118,17 @@ After editing:
 
 1. Run targeted validation.
 2. Commit the candidate change set after validation passes.
-3. Run the independent documentation writer review against that commit.
-4. If the review reports valid findings, apply them and rerun affected validation.
-5. Commit the corrections and review the new `HEAD`.
-6. Run one final complete collection for the latest PR commit. Restart the collection if `headRefOid` changes.
-7. Classify every finding.
-8. After classification, remove retained collection evidence by its exact artifact path or identifier. Verify its absence.
-9. Determine which unresolved findings require a change. If the user explicitly defers a non-blocking suggestion, that suggestion does not require a change in this review cycle.
-10. If any unresolved finding requires a change, do not push. Complete these actions:
+3. Run one final complete collection for the latest PR commit. Restart the collection if `headRefOid` changes.
+4. Classify every finding.
+5. After classification, remove retained collection evidence by its exact artifact path or identifier. Verify its absence.
+6. Determine which unresolved findings require a change. If the user explicitly defers a non-blocking suggestion, that suggestion does not require a change in this review cycle.
+7. If any unresolved finding requires a change, do not push. Complete these actions:
     - Repair each unresolved finding that requires a change.
     - Rerun affected validation.
     - Commit the corrections.
-    - Run the independent documentation writer review with that commit as the commit under review.
     - Repeat the final collection.
-11. Push once when the receipt identifies the reviewed `HEAD` and no unresolved finding requires a change.
-12. Monitor the latest PR commit for new findings that require a change.
+8. Push once when no unresolved finding requires a change.
+9. Monitor the latest PR commit for new findings that require a change.
 
 Repeat the applicable steps whenever an unresolved finding requires a change. Stop if the user tells you to stop.
 

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

@@ -62,7 +62,10 @@ When this workflow pushes an update to an open PR, first follow [Follow Up on PR
 
 Group valid code-changing findings by root cause. Route each valid code-changing finding to `nemoclaw-contributor-implement-issue` as part of its root-cause group. That workflow owns the repair, its validation, and its evidence. Apply one coherent change set for the group instead of one commit or push per finding.
 
-This workflow owns the push gate. After the routed repair returns, follow the numbered steps under `After editing:` in the [Handle results](../_shared/pr-follow-up.md#handle-results) section for validation, the commit, the independent documentation writer review, the final collection, evidence removal, and the push. If that review identifies a valid finding, return the repair to `nemoclaw-contributor-implement-issue`, commit the result, and rerun the review against the new `HEAD`. Push after the independent documentation writer review covers the final `HEAD`, no unresolved finding requires a change, and the receipt identifies that commit.
+This workflow owns the push gate. After the routed repair returns, follow the numbered steps under
+`After editing:` in the [Handle results](../_shared/pr-follow-up.md#handle-results) section for
+validation, the commit, the final collection, evidence removal, and the push. Push after no
+unresolved finding requires a change.
 
 Immediately before pushing, repeat the complete collection. Confirm that its initial and final `headRefOid` values match.
 
@@ -193,9 +196,6 @@ 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 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.
@@ -230,10 +230,11 @@ Follow these rules when filling in the template:
   - Why a direct change is not sufficient.
   - The test that protects the behavior.
 - **Type of Change:** Check one box. Use `[x]` for checked, `[ ]` for unchecked.
-- **Quality Gates:** Select one tests line and one docs line. Select each other line that applies.
-  Explain why tests or docs are not necessary.
-  Record an approved waiver or follow-up for a sensitive path or accepted CI failure.
-- **Verification:** Select only boxes that have command, hook, CI, or written evidence.
+- **Quality Gates:** Select the lines that apply. Explain why tests are not necessary when no test
+  command applies. Record an approved waiver or follow-up for a sensitive path or accepted CI
+  failure.
+- **Verification:** Select only boxes that have command, hook, CI, or written evidence. For a direct
+  documentation PR, record the applicable documentation validation here.
   Do not select a box for a skipped step.
   Select the DCO and commit-verification box after Step 4 passes.
   Leave the broad-gate box clear unless you ran that gate.

.agents/skills/nemoclaw-contributor-implement-issue/SKILL.md

@@ -92,8 +92,9 @@ evidence only when the real process, filesystem, network, container, hardware, w
 boundary owns the behavior. Run focused tests after the final behavior-affecting edit and record the
 exact command and result.
 
-Update user-facing documentation with the behavior when required. Use the shared documentation
-contract for authoring, validation, and final independent review.
+Keep owning repository guidance in the same change.
+This includes active `AGENTS.md` files, `.agents/skills/**`, and `test/e2e/**/README.md`.
+Defer only `docs/**`, `fern/docs.yml`, and `fern/assets/**`.
 
 ## Self-review the completed change
 

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

@@ -1,28 +1,23 @@
 ---
 name: nemoclaw-contributor-update-docs
-description: Find user-visible changes in current NemoClaw history and update their owning documentation. Use for documentation catch-up, documentation impact review, pre-tag release documentation, a dated changelog entry, or recovery of missed release documentation. Derive pages, commands, variants, and validation from the current checkout. Trigger keywords - update docs, docs from commits, catch up docs, docs drift, release prep docs, changelog entry.
+description: Find user-visible changes merged to NemoClaw and update their owning documentation. Use in the post-merge documentation workflow or for direct documentation catch-up. Derive pages, commands, variants, and validation from the current checkout. Trigger keywords - update docs, docs from commits, catch up docs, docs drift.
 ---
 
 <!-- SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved. -->
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 
 # Update Documentation from Changes
 
-Update documentation from current behavior. Use Git history and PR context to find candidate
-changes. Use checked-in source, tests, and accepted product scope as behavior authority.
+Update documentation from current behavior. Use checked-in source, tests, and accepted product
+scope as behavior authority.
 
-## Establish the documentation task
+## Establish the range
 
-Determine whether the request is:
+For `Docs / Post-Merge Catch-Up`, inspect changes from the latest reachable semver tag through the
+exact pushed `main` commit. Do not advance either boundary while authoring. For a direct
+documentation task, use the commit range supplied by the user or current checkout context.
 
-- documentation impact for one change;
-- catch-up across a supplied or inferred commit range;
-- pre-tag release preparation for an exact version and planned date; or
-- post-release recovery for documentation that missed the release.
-
-For `/nemoclaw-contributor-update-docs for vX.Y.Z`, use pre-tag release preparation unless the tag
-already exists. Ask before selecting a release version or date when current maintainer context does
-not determine them.
+Release-entry completion belongs to `nemoclaw-maintainer-evening`, not this workflow.
 
 ## Load current authority
 
@@ -39,9 +34,6 @@ source tree, package scripts, and workflows.
 
 ## Find documentation impact
 
-Select the commit range from the user's request or current release policy. For release preparation,
-reconcile commits since the prior release with the items assigned to the target release.
-
 For each candidate change:
 
 1. Read the commit and PR context.
@@ -65,29 +57,15 @@ State the user outcome, prerequisites, risks, lifecycle effects, and acceptance
 current behavior supports. Do not infer a command, default, path, or support claim from historical
 documentation or a commit message.
 
-## Handle release preparation
-
-Every pre-tag release-note docs PR must add or update the canonical
-`docs/changelog/YYYY-MM-DD.mdx` entry for the exact target version. Derive its format and link rules
-from the current documentation contributor guide and neighboring entries.
-
-For pre-tag work:
-
-1. Confirm the target version and planned release date.
-2. Include every intended release item or record its evidence-backed exclusion.
-3. Identify the target release label required by the current
-   [release-train policy](../nemoclaw-maintainer-policies/references/release-train.md) and verify
-   that it exists.
-4. Stop before PR creation when the required release label does not exist.
-
-Use post-release recovery rules only when the target release already exists.
-
 ## Validate and hand off
 
-Run the current documentation checks discovered from repository guidance and package scripts.
-Inspect generated variants and links affected by the change. Then run the required independent
-documentation writer review and apply valid findings.
+In `Docs / Post-Merge Catch-Up`, change only `docs/**`, `fern/docs.yml`, and `fern/assets/**`; the workflow independently reviews the patch.
+Required PR checks run `npm run docs`; do not perform GitHub writes from the authoring step.
+
+For a direct documentation task, run the current documentation checks discovered from repository
+guidance and package scripts. Inspect generated variants and links affected by the change and
+follow the shared writing and review contract.
 
 Summarize updated pages, new pages, skipped changes, product-scope exclusions, and validation
-evidence. Use `nemoclaw-contributor-create-pr` for PR preparation and follow-up. When the user asks
-to open a PR, pass the labels required by current repository policy through that workflow.
+evidence. Use `nemoclaw-contributor-create-pr` when the user asks to publish a direct documentation
+PR.