Summary

Describe the problem and fix in 2–5 bullets:

• Problem: The nextcloud-talk extension imported waitForAbortSignal via a repo-relative ../../../src/infra/abort-signal.js path.
• Why it matters: Built/distributed installs cannot resolve that internal path, so plugin load fails at gateway startup.
• What changed: Exported waitForAbortSignal from openclaw/plugin-sdk, switched Nextcloud Talk to consume the public SDK export, and added a regression test for plugin-sdk export availability.
• What did NOT change (scope boundary): No behavior change to abort handling semantics, monitor lifecycle logic, or Nextcloud webhook protocol.

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 [Bug]: nextcloud-talk extension fails to load: abort-signal.js import not available in built project #30057
• Related fix(ui): support string-object unions in config form schema #31762

User-visible / Behavior Changes

• Nextcloud Talk extensions now load correctly in built/distributed installs when using the public openclaw/plugin-sdk entrypoint.

Security Impact (required)

• 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)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS (dev), issue repro reported on Ubuntu Jammy
• Runtime/container: local Node/pnpm test runtime
• Model/provider: N/A
• Integration/channel (if any): nextcloud-talk extension
• Relevant config (redacted): channels.nextcloud-talk enabled

Steps

1. Enable the Nextcloud Talk plugin in config.
2. Start gateway from a built/distributed install.
3. Ensure plugin bootstrap resolves imports from openclaw/plugin-sdk only.

Expected

• Nextcloud Talk channel loads without module resolution errors.

Actual

• After this change, no missing src/infra/abort-signal resolution path is required.

Evidence

Attach at least one:

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

Passing tests/checks run locally:

• pnpm test src/plugin-sdk/index.test.ts extensions/nextcloud-talk/src/channel.startup.test.ts
• pnpm exec oxfmt --check src/plugin-sdk/index.test.ts src/plugin-sdk/index.ts extensions/nextcloud-talk/src/channel.ts CHANGELOG.md

Note on repo baseline:

• pnpm check still fails on pre-existing unrelated TypeScript errors in:
  • src/process/exec.windows.test.ts
  • src/slack/monitor/events/messages.ts

Human Verification (required)

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

• Verified scenarios:
  • waitForAbortSignal is exported from plugin-sdk.
  • Nextcloud Talk startup test still waits on abort and stops monitor correctly.
• Edge cases checked:
  • Already-aborted signal path remains correct.
• What you did not verify:
  • Full end-to-end startup on an Ubuntu package install in this run.

Compatibility / Migration

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

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Revert this PR commit.
• Files/config to restore:
  • src/plugin-sdk/index.ts
  • extensions/nextcloud-talk/src/channel.ts
• Known bad symptoms reviewers should watch for:
  • Extension load failures mentioning unresolved waitForAbortSignal from plugin-sdk.

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk: Broadening plugin-sdk surface by one helper could increase public API maintenance burden.
  • Mitigation: Export is narrow and already used internally with test coverage guarding export presence and behavior.