feat: implement channel runtime connectors

docs/superpowers/plans/2026-06-02-channel-connectors-foundation.md

@@ -6,6 +6,8 @@
 
 **Architecture:** Add a connector layer under `beaver/interfaces/channels/connections/` while keeping `ChannelRuntime`, `MessageBus`, and existing adapters as the message path. A `ChannelConnectionStore` persists setup state, a small credential vault stores secrets by reference, and `ChannelConnectorRegistry` materializes enabled connections into `ChannelConfig` objects during app startup. The first concrete connector is Telegram because token validation and runtime materialization are simple and testable with fake clients.
 
+**Weixin Follow-Up Constraint:** Weixin personal-account support is not implemented in this foundation slice. The follow-up Weixin plan must use a docker-compose predeclared sidecar service and Beaver must only call the existing connector HTTP API; Beaver must not dynamically create containers or require Docker socket access. Because the sidecar owns Weixin protocol, QR login, receive, and send behavior, Beaver should expose it to `ChannelRuntime` as an `ExternalConnectorChannel`, not as a protocol-level `WeixinAdapter`.
+
 **Tech Stack:** Python dataclasses, FastAPI, Pydantic v2, local JSON stores, pytest, existing Beaver channel runtime.
 
 ---
@@ -28,7 +30,7 @@ Excluded from this plan:
 
 - Terminal authenticated pairing.
 - Feishu/Lark official SDK integration.
-- Weixin external connector process.
+- Weixin docker-compose sidecar pairing and bridge implementation. The later Weixin plan must use a predeclared sidecar service plus Beaver HTTP bridge endpoints, not local host dependencies, dynamic container creation, or a Beaver-owned Weixin protocol adapter.
 - QQBot connector.
 - Frontend connection wizard.
 - Hot starting/stopping adapters without backend restart.
@@ -1739,9 +1741,19 @@ rg -n "token-1|token-2|bad-token|secret-token" tests/unit beaver || true
 
 Expected: test fixture strings only appear in test files. They must not appear in implementation files or generated event log code.
 
-- [ ] **Step 4: Update adapter spec wording if still contradictory**
+- [ ] **Step 4: Update connector and adapter spec wording if still contradictory**
 
-If `docs/superpowers/specs/2026-06-02-chat-platform-channel-adapters-design.md` still says pairing is out of scope and Node sidecars are disallowed, change only the Non-Goals and Access Control text:
+If `docs/superpowers/specs/2026-06-02-channel-connectors-and-pairing-design.md` still says Weixin uses a local plugin installer, dynamically launched connector process, or `ChannelRuntime external adapter`, change only the Weixin/external-process wording to this architecture:
+
+```markdown
+Weixin personal-account support uses a docker-compose predeclared sidecar connector. Beaver calls the sidecar's existing HTTP API and must not dynamically create containers or require Docker socket access.
+```
+
+```markdown
+For Weixin, the sidecar owns the platform protocol, QR login, inbound receive loop, outbound send, and login-state persistence. Beaver exposes it to the runtime through an `ExternalConnectorChannel`: inbound sidecar webhooks call Beaver's connector bridge endpoint, which submits normalized messages to `ChannelRuntime.accept_inbound()`, while outbound runtime messages call the sidecar `/send` API.
+```
+
+If `docs/superpowers/specs/2026-06-02-chat-platform-channel-adapters-design.md` still describes `WeixinAdapter` as the Beaver-owned protocol adapter, change only the Weixin adapter scope and access-control text:
 
 ```markdown
 - Use internal adapters by default, but allow external connector processes where platform SDK or login state requires them.
@@ -1751,17 +1763,40 @@ If `docs/superpowers/specs/2026-06-02-chat-platform-channel-adapters-design.md`
 Pairing is owned by the connector layer. Platform adapters assume a materialized `ChannelConnection` and adapter-ready runtime config.
 ```
 
+```markdown
+For Weixin personal-account support, the runtime channel is an `ExternalConnectorChannel`, not a Beaver-owned `WeixinAdapter`. The docker-compose sidecar is the Weixin protocol adapter; Beaver only owns connector setup state, bridge API validation, message normalization boundaries, runtime dedupe, and outbound HTTP calls to the sidecar.
+```
+
 - [ ] **Step 5: Commit spec alignment if changed**
 
 If Step 4 changed docs:
 
 ```bash
-git add docs/superpowers/specs/2026-06-02-chat-platform-channel-adapters-design.md
-git commit -m "docs: align channel adapter spec with connector layer"
+git add \
+  docs/superpowers/specs/2026-06-02-channel-connectors-and-pairing-design.md \
+  docs/superpowers/specs/2026-06-02-chat-platform-channel-adapters-design.md
+git commit -m "docs: align channel specs with external connector channels"
 ```
 
 If Step 4 made no change, do not create an empty commit.
 
 - [ ] **Step 6: Summarize remaining rollout**
 
-Record in the final implementation response that this first plan does not implement Terminal pairing, Feishu/Lark connector, Weixin external connector, QQBot connector, frontend wizard, or hot adapter restart. Those are separate plans.
+Record in the final implementation response that this first plan does not implement Terminal pairing, Feishu/Lark connector, Weixin docker-compose sidecar pairing/bridge, QQBot connector, frontend wizard, or hot adapter restart. Those are separate plans.
+
+For Weixin specifically, record the agreed follow-up architecture:
+
+```text
+Weixin sidecar connector
+  -> Beaver connector bridge endpoint
+  -> ChannelRuntime.accept_inbound()
+  -> MessageBus
+  -> AgentService
+
+AgentService
+  -> MessageBus outbound
+  -> ExternalConnectorChannel.send()
+  -> Weixin sidecar connector /send
+```
+
+Do not describe the follow-up path as `sidecar -> WeixinAdapter -> ChannelRuntime`. The sidecar is the Weixin protocol adapter; Beaver's runtime object should be named `ExternalConnectorChannel` or an equivalently generic connector-bridge channel.