Summary

Describe the problem and fix in 2–5 bullets:

• Problem: plugin-facing channel runtime and interactive APIs were still shaped around channel-specific surfaces, which pushed plugins toward Telegram/Discord/Slack-specific logic.
• Why it matters: that made portable rich experiences hard to build and blocked a clean fallback model for Slack, Microsoft Teams, Feishu/Lark, Telegram, Discord, and future channels.
• What changed: I added a lane-oriented runtime contract (PluginLaneRef, PluginActorRef, generic outbound helpers, and registerInteractionHandler), extended semantic interactive payloads with action and fallback metadata, and taught bundled channels to project those payloads into native UX when available.
• What did NOT change (scope boundary): I did not remove every raw channel runtime namespace yet; they remain host-owned escape hatches, and I kept the implementation plan in a separate commit so it can be dropped cleanly if desired.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• 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 #
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

• Root cause: the older plugin runtime exposed channel-shaped interaction and outbound seams, so plugin authors had to think in terms of per-channel transports instead of reply lanes, actors, semantic actions, and fallbacks.
• Missing detection / guardrail: there was no normalized plugin-facing lane/actor contract and no shared semantic interactive fallback model.
• Prior context (git blame, prior PR, issue, or refactor if known): this work follows the lane-oriented interface plan and the discussion around removing Telegram Bot API / Discord API ownership from plugins.
• Why this regressed now: N/A
• If unknown, what was ruled out: N/A

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should have caught this. Otherwise write N/A.

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/plugins/runtime.channel-outbound-delivery.test.ts, src/plugins/interactive.test.ts, extensions/msteams/src/outbound.test.ts, extensions/feishu/src/outbound.test.ts
• Scenario the test should lock in: a plugin can target normalized lanes/actors and semantic interactive payloads, and bundled channels project those payloads into native channel UX correctly.
• Why this is the smallest reliable guardrail: the risky part is the contract seam between plugin runtime, interactive dispatch, and channel outbound projection rather than a single leaf helper.
• Existing test that already covers this (if any): src/plugins/commands.test.ts and src/interactive/payload.test.ts now cover normalized lane refs and interactive fallback normalization.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

• Plugin authors now have a lane-oriented interaction/outbound contract instead of relying on channel-shaped runtime helpers.
• Semantic interactive replies now carry action ids plus text/command fallbacks.
• Microsoft Teams and Feishu/Lark channel plugins can project semantic interactive replies into native card UI instead of collapsing to plain text only.

Diagram (if applicable)

For UI changes or non-trivial logic flows, include a small ASCII diagram reviewers can scan quickly. Otherwise write N/A.

Before:
[plugin] -> [channel-specific send/callback helpers] -> [per-channel branching]

After:
[plugin semantic reply/action] -> [lane/actor runtime] -> [channel projection]
                                               -> [native rich UI or text/command fallback]

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 22 + pnpm
• Model/provider: N/A
• Integration/channel (if any): plugin runtime, Telegram, Discord, Slack, Microsoft Teams, Feishu/Lark
• Relevant config (redacted): local bundled-plugin/dev config only

Steps

1. Run pnpm lint.
2. Run pnpm test -- src/interactive/payload.test.ts src/plugins/commands.test.ts src/plugins/interactive.test.ts src/plugins/runtime.channel-outbound-delivery.test.ts extensions/msteams/src/outbound.test.ts extensions/feishu/src/outbound.test.ts.
3. Run pnpm build.

Expected

• The lane-oriented runtime compiles, targeted tests pass, and bundled channel projections build successfully.

Actual

• pnpm lint passed.
• The targeted tests passed.
• pnpm build passed.
• pnpm check is still blocked by a pre-existing unresolved merge-conflict marker in CHANGELOG.md:94, which is unrelated to this PR.

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: I verified the normalized lane/actor runtime flow, generic interaction registration, interactive fallback normalization, and Teams/Feishu rich projection through the targeted tests above, and I verified the full repo build completed successfully.
• Edge cases checked: Telegram topic lane normalization, Slack interaction response typing, and generic fallback behavior when a channel cannot render rich UI.
• What you did not verify: I did not run a full end-to-end manual chat flow across live Slack/Teams/Feishu/Telegram accounts in this branch.

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) No
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) Yes
• If yes, exact upgrade steps:
  1. Move plugin reply routing to PluginLaneRef / PluginActorRef.
  2. Use api.runtime.channel.outbound.sendToLane(...) and sendToActorDm(...) instead of channel-branded outbound helpers where possible.
  3. Prefer api.registerInteractionHandler(...) plus semantic InteractiveReply payloads with fallbacks.
  4. Treat raw api.runtime.channel.<id> namespaces as escape hatches for host-owned runtime work, not the default plugin contract.

Risks and Mitigations

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

• Risk: third-party plugins using the older channel-shaped interaction surface will need migration.
  • Mitigation: the PR includes migration docs and keeps the old channel-specific registration path available as a compatibility bridge for now.
• Risk: rich interactive projection can drift across bundled channels.
  • Mitigation: I added targeted outbound tests for Teams and Feishu and a seam test for normalized lane delivery.