PR #72216: fix(nostr): keep setup status off full surface

• Repository: openclaw/openclaw
• Author: SnowSky1
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/72216

Description (problem / solution / changelog)

## Summary Problem: Opening Onboard / model switching can scan bundled setup surfaces. The Nostr setup-only plugin was using the delegated setup wizard proxy for status resolution, so a status check imported the full setup-surface.js. That full surface imports nostr-key-utils, which imports nostr-tools, so packaged installs without optional Nostr runtime deps could fail even when Nostr was not configured.

What changed:

• Keep Nostr setup status resolution on the lightweight channel.setup.ts surface.
• Preserve the existing lightweight setup adapter and account/status behavior.
• Add a regression test that mocks the full setup-surface.js to throw, then verifies setup status still resolves without loading it.

Closes #72182

Change Type

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope

• Integrations
• UI / DX
• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• API / contracts
• CI/CD / infra

Root Cause / Regression History

The setup-only Nostr entry point already avoids static nostr-tools imports, but createDelegatedSetupWizardProxy delegates status.resolveConfigured and status detail resolvers to the full wizard. Status/discovery paths can call those resolvers before the user enables Nostr, which pulls in the full setup surface and its Nostr runtime dependency graph.

This keeps the cold setup/status path on the local lightweight resolver instead of delegating to the full wizard for status-only work.

Regression Test Plan

Coverage level that should have caught this:

• Unit test
• Seam / integration test
• End-to-end test
• Existing coverage already sufficient

Target test file: extensions/nostr/src/channel.setup.test.ts

Scenario locked in: Nostr setup status resolves when the full setup-surface.js would fail to load. The test mocks ./setup-surface.js to throw, then asserts unconfigured/configured setup status still works from channel.setup.ts.

User-visible / Behavior Changes

Onboard and setup status scans should no longer fail on missing nostr-tools when Nostr is unconfigured. Configuring or running the Nostr channel is unchanged.

Security Impact

New permissions/capabilities? No Secrets/tokens handling changed? No New/changed network calls? No Command/tool execution surface changed? No Data access scope changed? No

Repro + Verification

Repro before fix:

1. Use a packaged install where bundled Nostr runtime deps have not been installed.
2. Open Onboard / model switching so setup surfaces are scanned.
3. Nostr status discovery can import the full setup surface and fail with missing nostr-tools.

Verification run locally:

• OPENCLAW_VITEST_INCLUDE_FILE=<temp json for extensions/nostr/**/*.test.ts> node scripts/run-vitest.mjs run --config test/vitest/vitest.extension-messaging.config.ts — 13 files / 271 tests passed.
• pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/nostr/src/channel.setup.ts extensions/nostr/src/channel.setup.test.ts
• pnpm exec oxlint --tsconfig tsconfig.oxlint.extensions.json extensions/nostr/src/channel.setup.ts extensions/nostr/src/channel.setup.test.ts
• git diff --check

Compatibility / Migration

Backward compatible? Yes Config/env changes? No Migration needed? No

Failure Recovery

Revert this commit. The change is scoped to Nostr setup-only status discovery and does not modify Nostr runtime send/receive behavior.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/nostr/src/channel.setup.test.ts (added, +43/-0)
• extensions/nostr/src/channel.setup.ts (modified, +20/-24)