Walkthrough

Schema adds top-level commandAliases and activation fields (now required in the root schema); nemoclaw/openclaw.plugin.json declares a runtime-slash alias and activation.onStartup: true; tests are extended to accept valid fixtures and reject missing/extra activation and alias properties.

Changes

Command Alias and Startup Activation

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

fix

Suggested reviewers

• ericksoa
• cv

Poem

🐰 I hopped through JSON fields at dawn,
Declared a slash where commands are drawn,
A startup pulse, a tiny cheer,
Tests nod, the schema now is clear,
Plugins wake — the meadow's near. ✨

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• cloud-e2e (high): Runs install.sh, onboards a fresh OpenClaw sandbox, starts the live Gateway/runtime, and performs an OpenClaw-mediated inference turn. This is the best existing merge-blocking check that the changed plugin manifest does not break startup, sandbox creation, or the core assistant flow.

Optional E2E

• openclaw-tui-chat-correlation-e2e (high): Exercises the OpenClaw Gateway websocket/chat path against a fresh cloud-backed sandbox. Useful adjacent confidence for runtime command/chat registration changes, but it does not appear to directly assert the new /nemoclaw slash alias.
• launchable-smoke-e2e (medium): Validates the community launchable install path builds the CLI and plugin and onboards a sandbox. Useful because openclaw.plugin.json is packaged with the plugin, but cloud-e2e is the stronger required runtime check for this PR.

New E2E recommendations

• OpenClaw runtime slash command aliases (high): No existing E2E found that directly sends or resolves the new runtime-slash /nemoclaw alias after Gateway startup and verifies it maps to the NemoClaw plugin handlers without colliding with the root CLI command.
  • Suggested test: Add an OpenClaw Gateway/chat E2E that onboards a fresh sandbox, waits for onStartup plugin activation, invokes the /nemoclaw runtime slash command through the same surface users use, and asserts the NemoClaw plugin handles it successfully.
• Plugin activation metadata (medium): Existing E2E startup checks can catch gross startup failures, but they do not explicitly assert that activation.onStartup caused the NemoClaw plugin to be imported during Gateway startup.
  • Suggested test: Add a targeted assertion to an OpenClaw startup E2E that inspects Gateway/plugin registry state or logs for the NemoClaw plugin being loaded from openclaw.plugin.json on startup.

Dispatch hint

• Workflow: nightly-e2e.yaml
• jobs input: cloud-e2e

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• None. No scenario workflow, scenario metadata, scenario runtime, or validation-suite files changed.

Optional scenario E2E

• None.

Relevant changed files

• None.

🛠️ Needs attention

• Schema tests do not prove /nemoclaw reaches the OpenClaw command router (test/validate-config-schemas.test.ts:523): The linked issue is about user-visible runtime behavior: typing /nemoclaw should show autocomplete/subcommand hints, and pressing Enter should execute the command or display help. This PR only validates that the NemoClaw manifest contains commandAliases and activation.onStartup. In this checkout, commandAliases, activation.onStartup, and runtime-slash only appear in the changed manifest/schema/tests; no in-repo production consumer was found that imports the plugin on startup, populates slashScope, feeds autocomplete, or routes /nemoclaw status to handleSlashCommand(). The added tests would still pass if OpenClaw ignored these fields and the TUI behavior remained broken.
  • Recommendation: Add a regression at the closest available runtime boundary that fails without the fix and proves /nemoclaw is registered after startup. Good targets include a generated OpenClaw config/slashScope fixture, plugin-loader/activation contract test, command-router test, or a test that invokes /nemoclaw status through the same path used by OpenClaw and reaches the existing handler. If the behavior depends entirely on an external OpenClaw contract, pin that contract with a fixture/schema expectation in this repo.
  • Evidence: Issue [All Platform] /nemoclaw slash command not working in sandbox OpenClaw TUI #2021 expected: “Typing /nemoclaw should show autocomplete hints for available subcommands (status, shields, config, etc)” and “Pressing Enter should execute the command or display help output”. The latest reopen comment says openclaw.json slashScope was empty and /nemoclaw status was not processed. The PR adds schema-only tests around test/validate-config-schemas.test.ts:523-548.

🔎 Worth checking

• Source-of-truth review needed: OpenClaw plugin manifest metadata for lazy startup activation and runtime slash routing: The advisor marked localized patch analysis as missing.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: Changed files are limited to nemoclaw/openclaw.plugin.json, schemas/openclaw-plugin.schema.json, and test/validate-config-schemas.test.ts. The linked issue's latest reopen comment specifically says slashScope remained empty and /nemoclaw status was not processed.
• Manifest metadata contract needs source-of-truth evidence (nemoclaw/openclaw.plugin.json:6): This change appears to localize a fix for OpenClaw lazy startup activation and runtime slash routing by adding manifest metadata, but the repo does not show where the invalid installed-but-not-imported state is created or where these fields are consumed. Without a pinned host contract or runtime boundary test, the metadata can drift from OpenClaw's actual source of truth while still passing this repo's schema tests.
  • Recommendation: Document or test the OpenClaw contract that consumes commandAliases and activation.onStartup. Identify why the source boundary cannot be fixed in this PR, add a regression that would fail if OpenClaw ignores these fields, and state whether this is a permanent manifest contract or a compatibility workaround with a removal condition.
  • Evidence: Only nemoclaw/openclaw.plugin.json, schemas/openclaw-plugin.schema.json, and test/validate-config-schemas.test.ts changed. Grep found no in-repo production reader for commandAliases, activation.onStartup, runtime-slash, or slashScope.
• Startup-activated slash command lacks explicit authorization enforcement (nemoclaw/src/index.ts:345): The PR opts NemoClaw into startup activation, making the existing /nemoclaw command surface available during Gateway startup. The command registration does not set requireAuth: true, and the handler accepts PluginCommandContext.isAuthorizedSender without checking it. The commands are mostly read-only, but they can disclose sandbox/config state, endpoint/provider/model/profile details, onboard time, and rollback snapshot or backup paths.
  • Recommendation: Make authorization explicit for /nemoclaw, either by setting requireAuth: true if that is the OpenClaw host contract, or by checking ctx.isAuthorizedSender in handleSlashCommand and limiting unauthenticated callers to minimal help or denial output. Add a negative unit or contract test for unauthorized access.
  • Evidence: nemoclaw/src/index.ts registers api.registerCommand({ name: "nemoclaw", description, acceptsArgs: true, handler }) without requireAuth. nemoclaw/src/commands/slash.ts switches on subcommands without reading ctx.isAuthorizedSender. nemoclaw/openclaw.plugin.json now sets activation.onStartup: true.
• Onboard slash output echoes credentialEnv without safe env-name validation (nemoclaw/src/commands/slash.ts:123): With /nemoclaw activated at startup, /nemoclaw onboard can echo config.credentialEnv verbatim as a credential label. slashConfigShow already treats malformed persisted credential environment values as sensitive and avoids echoing them, but slashOnboard does not reuse that guard. If persisted onboard config is malformed or tampered with, a raw token accidentally stored in credentialEnv could be displayed.
  • Recommendation: Use the same safe environment-variable-name validation/redaction logic in slashOnboard that slashConfigShow uses, and add a negative test with a malformed credentialEnv value.
  • Evidence: slashOnboard builds `Credential: $${config.credentialEnv}`. slashConfigShow validates credentialEnv with /^[A-Z_][A-Z0-9_]*$/ and displays `(configured)` for malformed values.
• Runtime command alias names are not constrained to NemoClaw-safe command identifiers (schemas/openclaw-plugin.schema.json:45): The new schema permits any non-empty string for commandAliases[].name. Because these aliases are intended to feed runtime command routing/autocomplete in the host, an overly broad string contract can allow ambiguous, malformed, or unexpected command names to pass repository validation.
  • Recommendation: Constrain this manifest to the expected command name with const: "nemoclaw", or at least add a strict command identifier pattern such as ^[a-z][a-z0-9-]*$ and tests for malformed aliases.
  • Evidence: schemas/openclaw-plugin.schema.json defines commandAliases.items.properties.name with type string and minLength: 1 only. nemoclaw/openclaw.plugin.json uses the single expected value "nemoclaw", but the schema fixture accepts arbitrary "fixture" names and has no malformed-name rejection test.

🌱 Nice ideas

• None.

Current findings:

• Source-of-truth review needed: OpenClaw plugin manifest metadata for lazy startup activation and runtime slash routing: The advisor marked localized patch analysis as missing.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: Changed files are limited to nemoclaw/openclaw.plugin.json, schemas/openclaw-plugin.schema.json, and test/validate-config-schemas.test.ts. The linked issue's latest reopen comment specifically says slashScope remained empty and /nemoclaw status was not processed.
• Schema tests do not prove /nemoclaw reaches the OpenClaw command router (test/validate-config-schemas.test.ts:523): The linked issue is about user-visible runtime behavior: typing /nemoclaw should show autocomplete/subcommand hints, and pressing Enter should execute the command or display help. This PR only validates that the NemoClaw manifest contains commandAliases and activation.onStartup. In this checkout, commandAliases, activation.onStartup, and runtime-slash only appear in the changed manifest/schema/tests; no in-repo production consumer was found that imports the plugin on startup, populates slashScope, feeds autocomplete, or routes /nemoclaw status to handleSlashCommand(). The added tests would still pass if OpenClaw ignored these fields and the TUI behavior remained broken.
  • Recommendation: Add a regression at the closest available runtime boundary that fails without the fix and proves /nemoclaw is registered after startup. Good targets include a generated OpenClaw config/slashScope fixture, plugin-loader/activation contract test, command-router test, or a test that invokes /nemoclaw status through the same path used by OpenClaw and reaches the existing handler. If the behavior depends entirely on an external OpenClaw contract, pin that contract with a fixture/schema expectation in this repo.
  • Evidence: Issue [All Platform] /nemoclaw slash command not working in sandbox OpenClaw TUI #2021 expected: “Typing /nemoclaw should show autocomplete hints for available subcommands (status, shields, config, etc)” and “Pressing Enter should execute the command or display help output”. The latest reopen comment says openclaw.json slashScope was empty and /nemoclaw status was not processed. The PR adds schema-only tests around test/validate-config-schemas.test.ts:523-548.
• Manifest metadata contract needs source-of-truth evidence (nemoclaw/openclaw.plugin.json:6): This change appears to localize a fix for OpenClaw lazy startup activation and runtime slash routing by adding manifest metadata, but the repo does not show where the invalid installed-but-not-imported state is created or where these fields are consumed. Without a pinned host contract or runtime boundary test, the metadata can drift from OpenClaw's actual source of truth while still passing this repo's schema tests.
  • Recommendation: Document or test the OpenClaw contract that consumes commandAliases and activation.onStartup. Identify why the source boundary cannot be fixed in this PR, add a regression that would fail if OpenClaw ignores these fields, and state whether this is a permanent manifest contract or a compatibility workaround with a removal condition.
  • Evidence: Only nemoclaw/openclaw.plugin.json, schemas/openclaw-plugin.schema.json, and test/validate-config-schemas.test.ts changed. Grep found no in-repo production reader for commandAliases, activation.onStartup, runtime-slash, or slashScope.
• Startup-activated slash command lacks explicit authorization enforcement (nemoclaw/src/index.ts:345): The PR opts NemoClaw into startup activation, making the existing /nemoclaw command surface available during Gateway startup. The command registration does not set requireAuth: true, and the handler accepts PluginCommandContext.isAuthorizedSender without checking it. The commands are mostly read-only, but they can disclose sandbox/config state, endpoint/provider/model/profile details, onboard time, and rollback snapshot or backup paths.
  • Recommendation: Make authorization explicit for /nemoclaw, either by setting requireAuth: true if that is the OpenClaw host contract, or by checking ctx.isAuthorizedSender in handleSlashCommand and limiting unauthenticated callers to minimal help or denial output. Add a negative unit or contract test for unauthorized access.
  • Evidence: nemoclaw/src/index.ts registers api.registerCommand({ name: "nemoclaw", description, acceptsArgs: true, handler }) without requireAuth. nemoclaw/src/commands/slash.ts switches on subcommands without reading ctx.isAuthorizedSender. nemoclaw/openclaw.plugin.json now sets activation.onStartup: true.
• Onboard slash output echoes credentialEnv without safe env-name validation (nemoclaw/src/commands/slash.ts:123): With /nemoclaw activated at startup, /nemoclaw onboard can echo config.credentialEnv verbatim as a credential label. slashConfigShow already treats malformed persisted credential environment values as sensitive and avoids echoing them, but slashOnboard does not reuse that guard. If persisted onboard config is malformed or tampered with, a raw token accidentally stored in credentialEnv could be displayed.
  • Recommendation: Use the same safe environment-variable-name validation/redaction logic in slashOnboard that slashConfigShow uses, and add a negative test with a malformed credentialEnv value.
  • Evidence: slashOnboard builds `Credential: $${config.credentialEnv}`. slashConfigShow validates credentialEnv with /^[A-Z_][A-Z0-9_]*$/ and displays `(configured)` for malformed values.
• Runtime command alias names are not constrained to NemoClaw-safe command identifiers (schemas/openclaw-plugin.schema.json:45): The new schema permits any non-empty string for commandAliases[].name. Because these aliases are intended to feed runtime command routing/autocomplete in the host, an overly broad string contract can allow ambiguous, malformed, or unexpected command names to pass repository validation.
  • Recommendation: Constrain this manifest to the expected command name with const: "nemoclaw", or at least add a strict command identifier pattern such as ^[a-z][a-z0-9-]*$ and tests for malformed aliases.
  • Evidence: schemas/openclaw-plugin.schema.json defines commandAliases.items.properties.name with type string and minLength: 1 only. nemoclaw/openclaw.plugin.json uses the single expected value "nemoclaw", but the schema fixture accepts arbitrary "fixture" names and has no malformed-name rejection test.