Greptile Summary

Fixes the plugin-sdk/channel-runtime-context DTS build break by removing the chained type ChannelRuntimeContextKey re-export (which the declaration emitter could not resolve) and replacing it with an inline type definition that is structurally identical to the canonical shape in src/channels/plugins/channel-runtime-surface.types.ts. Value exports are unchanged.

Confidence Score: 5/5

Safe to merge — the inline type matches the canonical definition exactly and value exports are untouched.

The only finding is a P2 style suggestion about adding a compile-time drift guard; there are no correctness, data-integrity, or runtime issues introduced by this narrow fix.

No files require special attention.

This is a comment left during a code review.
Path: src/plugin-sdk/channel-runtime-context.ts
Line: 7-11

Comment:
**Type drift risk from manual duplication**

The inline definition is currently byte-for-byte identical to `ChannelRuntimeContextKey` in `src/channels/plugins/channel-runtime-surface.types.ts`, but there's no enforcement keeping them in sync. If `accountId` is tightened, `capability` is narrowed, or a new required field is added to the canonical type, plugin authors will continue to compile against the stale plugin-sdk shape while the infra functions internally accept the updated type — leading to a structural mismatch that TypeScript's duck-typing may not immediately surface.

Consider adding a compile-time assertion near this definition to catch drift early:

```typescript
import type { ChannelRuntimeContextKey as _CanonicalKey } from "../channels/plugins/channel-runtime-surface.types.js";
// Ensure the plugin-sdk shape stays structurally compatible with the internal canonical type.
type _AssertCompat = _CanonicalKey extends ChannelRuntimeContextKey ? ChannelRuntimeContextKey extends _CanonicalKey ? true : never : never;
```

This is a pure type-level check (erased at emit) and wouldn't reintroduce the broken re-export path that triggered the DTS failure.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: stabilize plugin sdk channel runtim..." | Re-trigger Greptile}

Current head b4bcc34938 keeps PR N narrowly on the shared blocker it was opened for.

What changed on top of the original unblock:

• plugin-sdk still defines ChannelRuntimeContextKey inline so the d.ts build no longer depends on the broken internal re-export
• a type-only import + compile-time compatibility assertion now pins that inline shape to the canonical internal key type, so we don’t trade the build fix for silent drift later

Local validation passed:

• pnpm exec tsc -p tsconfig.plugin-sdk.dts.json --pretty false
• CI=1 pnpm exec vitest run src/infra/channel-runtime-context.test.ts

This remains intentionally narrow shared-CI/typecheck cleanup, not parity logic or runtime-slice scope.

Confirmed on main @ 462d8e3b. pnpm exec tsc -p tsconfig.plugin-sdk.dts.json fails with the ChannelRuntimeContextKey re-export resolution error at src/plugin-sdk/channel-runtime-context.ts:5. Applying this patch locally clears it. Defining the exported ChannelRuntimeContextKey shape directly (instead of routing through the re-export) is the right shape for the dts builder — narrow unblock looks correct.

Current head bd122aaabe now covers the shared channel-runtime/typecheck drift that was reproducing across the open parity branches.

Latest local validation:

• pnpm build:plugin-sdk:dts
• CI=1 pnpm exec vitest run src/infra/channel-runtime-context.test.ts src/gateway/server-channels.test.ts (18 tests)

This head now includes:

• the plugin-sdk/channel-runtime compatibility assertion
• the gateway server-channels test type update to ChannelRuntimeSurface
• the shared OpenClawConfig and loaded-channel typing fixes that rebased branches were inheriting from main

The remaining local pnpm check failure is a separate extensions/msteams/src/sdk.ts optional-dependency issue (@azure/identity) and no longer the channel-runtime blocker this PR was opened to fix.