Summary

• Problem: the existing source-level tests covered the dist-runtime singleton fix, but CI did not run a post-build smoke that proves bundled plugins loaded from dist-runtime still register commands onto the canonical built runtime graph.
• Why it matters: the original regression broke bundled plugin commands like /pair, /phone, and /voice in built environments. Without a built smoke, future build-layout or loader changes could regress that path without being caught by unit tests alone.
• What changed: renamed the post-build startup-memory lane to build-smoke, added pnpm test:build:singleton, added a stable built smoke entrypoint at dist/plugins/build-smoke-entry.js, and added a smoke script that stages a temp bundled plugin through dist-runtime, imports openclaw/plugin-sdk, loads it through the built loader, and asserts the canonical built command registry sees /pair.
• What did NOT change (scope boundary): this does not change plugin runtime behavior, plugin manifests, or command semantics outside of adding a stronger CI regression check.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

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

Linked Issue/PR

• Closes #
• Related fix(plugins): keep built plugin loading on one module graph #48595

User-visible / Behavior Changes

• None.

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 25 / local repo build
• Model/provider: N/A
• Integration/channel (if any): bundled plugins, dist-runtime build smoke
• Relevant config (redacted): local repo build with default dist/ and dist-runtime/

Steps

1. Run pnpm build.
2. Run pnpm test:build:singleton.
3. Run pnpm test:startup:memory.

Expected

• The built smoke entrypoint is emitted into dist/plugins/build-smoke-entry.js.
• A temp bundled plugin loaded from dist-runtime through the built loader can import openclaw/plugin-sdk and still register /pair onto the canonical built command registry.
• The existing startup memory smoke still passes under the renamed post-build lane.

Actual

• pnpm build emitted the stable smoke entrypoint.
• pnpm test:build:singleton passed and verified the built loader + canonical command registry path.
• pnpm test:startup:memory passed after the lane rename.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: ran pnpm build; verified dist/plugins/build-smoke-entry.js exists; ran pnpm test:build:singleton; ran pnpm test:startup:memory.
• Edge cases checked: the singleton smoke fixture now imports openclaw/plugin-sdk so the check covers the built root-alias/native-loading path in addition to canonical command registration.
• What you did not verify: I did not run a live Telegram session or other channel end-to-end flow; this PR is limited to a post-build regression smoke.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR, or remove the new pnpm test:build:singleton step from the build-smoke lane.
• Files/config to restore: .github/workflows/ci.yml, package.json, tsdown.config.ts, src/plugins/build-smoke-entry.ts, scripts/test-built-plugin-singleton.mjs
• Known bad symptoms reviewers should watch for: build smoke failing to locate the stable built entrypoint, the bundled temp plugin failing to import openclaw/plugin-sdk, or /pair not appearing in the canonical built command registry during the smoke.

Risks and Mitigations

• Risk: the new smoke could become coupled to build internals and fail on unrelated bundle-layout churn.

• Mitigation: the smoke now imports a stable source-owned built entrypoint (dist/plugins/build-smoke-entry.js) rather than scraping hashed chunks.

• Risk: the smoke could prove only direct api.registerCommand behavior and miss the built openclaw/plugin-sdk alias path.

• Mitigation: the fixture imports openclaw/plugin-sdk and uses emptyPluginConfigSchema(), so the smoke covers the actual alias/native-loading path involved in the original regression.