feat(adapters): 新增Claude Code、CodeBuddy跨平台适配器，实现四层记忆引擎多平台接入（腾讯犀牛鸟开源）

[rainforest888]

完成内容

实现 Issue #235 全部四个验收标准：

基础 ✅ 架构图与数据流

• 阅读 TdaiCore、HostAdapter、Gateway 源码
• 绘制完整架构图，标注 /recall→handleBeforeRecall 等映射
• 文件: docs/tdai-adapter-architecture.md

进阶 ✅ Claude Code 适配器

• MCP stdio server (169行，纯 JSON-RPC 2.0，零框架依赖)
• 4 个工具: tdai_memory_search / tdai_conversation_search / tdai_recall / tdai_capture
• E2E 验证: Gateway 四端全通，MCP 协议合规

深入 ✅ 三平台适配 + 对比文档

• 新增 CCHostAdapter (59行) + CodeBuddyHostAdapter (38行)
• 复用已有 Hermes Provider
• 对比文档: docs/platform-adapter-comparison.md

拓展 ✅ 统一适配器 SDK

• TdaiPlatformAdapter 接口 + TDAI_TOOLS 标准工具定义
• 新平台接入: 实现 HostAdapter (~85行) 即可
• 三步接入指南: docs/methodology.md

核心设计

复用项目原生 HostAdapter 模式（与 OpenClawHostAdapter/StandaloneHostAdapter 一致），不引入额外抽象层。

验证

• ✅ Gateway health check 通过
• ✅ MCP 协议合规（CodeBuddy 审查，3 个协议 bug 已修复）
• ✅ 跨平台 E2E: Hermes 写入 → CC 召回 → CodeBuddy 召回
• ✅ CC 和 CodeBuddy MCP 均已连接 (claude mcp list / codebuddy mcp list)

新增文件

文件	说明
src/adapters/claude-code/host-adapter.ts	CCHostAdapter (59行)
src/adapters/codebuddy/host-adapter.ts	CodeBuddyHostAdapter (38行)
src/adapters/shared/types.ts	统一SDK接口 + 标准工具定义
docs/tdai-adapter-architecture.md	架构图 + 数据流
docs/platform-adapter-comparison.md	平台对比文档
docs/methodology.md	使用说明 + 三步接入指南

Closes #235

[rainforest888]

有任何问题请直接联系我！谢谢导师或者其他开源伙伴的帮助！

[gugu23456789]

Thanks for the thoughtful comparison! A few clarifications from the PR #339 side:

You are right that directly extending HostAdapter is the canonical pattern for pure TS adapters. Your CCHostAdapter and CodeBuddyHostAdapter at ~40-60 lines each are cleaner than what we did for the TS path. If our goal were only to add more TypeScript platform adapters, your approach would be the right one.

Where the difference comes from: cross-language goal. PR #339 is not just a TS adapter -- it also provides a Python SDK (bridge_adapter) and a standalone MCP stdio server. Python has no HostAdapter, no Hermes provider, so we needed a new abstraction layer (TdaiAdapter ABC) on that side. The TypeScript TdaiAdapter interface exists mainly for parity with the Python ABC, so that both SDKs speak the same contract.

On the MCP server side: The self-gated server (G0-G4: format check, HMAC auth, rate limit, circuit breaker, audit) is designed as a standalone fallback that works without Hermes. In production it sits behind agentgateway and only activates as a safety net -- different role from the Hermes MCP provider.

I think these two approaches are complementary:

• You are adding IDE adapters horizontally (more platforms)
• We are building a cross-language bridge vertically (Python + TS + MCP)
• Both serve the same issue Cross-Platform Adapters for the Memory Plugin #235 goal: making TDAI memory accessible from anywhere

Happy to discuss further if any of this is unclear. Good work on the Claude Code and CodeBuddy adapters!

[Maxwell-Code07]

Thank you for submitting this PR and participating in Tencent Rhino-bird Open-source Training Program!
We have successfully received your submission. The program is currently in full swing, and we will complete the Code Review for you as soon as possible. Please keep an eye on the status notifications for this PR so you can follow up promptly once the review feedback is provided.
Thanks again for your contribution and open-source spirit! 🚀

[rainforest888]

Hi @gugu23456789, thanks a lot for the detailed clarification — it really helps frame the two PRs correctly, and I appreciate the constructive tone.

Fully agree with your complementary framing:

• This PR (horizontal) — extends IDE platforms in TypeScript by reusing the existing HostAdapter (CC + CodeBuddy, plus Hermes reuse).
• PR feat(adapter): add bridge_adapter Python SDK + TypeScript MemoryAdapter interface #339 (vertical) — builds the cross-language bridge: Python bridge_adapter SDK + standalone gated MCP server + a TS TdaiAdapter for parity with the Python ABC. Your point about Python having no HostAdapter / Hermes provider — hence the need for the TdaiAdapter ABC — is well taken; that's a genuinely different layer from what we're doing in TS.

Both serve Issue #235's goal of making TDAI memory accessible from anywhere, and they operate at different layers, so they don't conflict.

One housekeeping note: to keep this PR's docs self-contained, I've removed the cross-PR comparison from docs/platform-adapter-comparison.md rather than maintaining a side-by-side section — the complementary positioning is better captured here in the discussion than in repo files. If there's a natural place to align the two later (e.g. a shared tool/contract schema so the TS thin-shell adapters and the cross-language SDK speak the same tools), I'd be glad to discuss and collaborate.

Thanks again for the feedback, and nice work on the Python SDK + standalone MCP server! 🚀