[xiaoyumuxi]

概要

数据库插件后端接入结构化日志 v2：改用支持 litheLogging 1 的官方 Rust SDK，由 SDK 自动上报每次调用的成功/失败终态，插件只补充“结果被裁剪”这一条降级事实；高频的浏览、元数据和探测调用不再产生 INFO。诊断事实由宿主 Core 校验后写入 plugins/<id>/host，不含 SQL、连接信息、路径或行数据。

依赖：

• 宿主 https://github.com/1lck/Lithe-IDEA/pull/1699（Core 侧 litheLogging 协议、目录事件、lithe/log 校验）
• SDK https://github.com/Lithe-IDEA/lithe-plugin-docs/pull/17（三语言 SDK 的协商与诊断 API；本仓库 vendor 的就是这批源码）

SDK 来源：从 git 依赖改为 vendor 源码快照

• backend/Cargo.toml 的 lithe-plugin-sdk 从 git rev = 5da0524… 改为 path = "../vendor/lithe-plugin-sdk"；backend/Cargo.lock 只删除了对应的 git source 行。
• 新增 vendor/lithe-plugin-sdk/：Cargo.toml、LICENSE（Apache-2.0）、src/{backend,diagnostics,error,framing,host,lib,panic_boundary,protocol,stdio}.rs。基线是 lithe-plugin-docs 29b245c0e1d77c761d9032a3144a301d1818bfc7，加上 SDK PR #17 的日志改动。
• vendor/lithe-plugin-sdk/source-provenance.json 记录真实基线 commit、哪些文件带本地改动，以及逐文件 SHA-256。这不是已发布的 SDK 版本，也没有伪造 git revision。
• 新增 scripts/verify-sdk-source.mjs：按来源记录逐文件校验，拒绝漂移、遗漏或多余文件。CI 新增 “Verify SDK source provenance” 步骤，scripts/package.mjs 打包前也会先跑。

诊断行为（backend/crates/backend/src/service.rs）

• 按注册抑制成功事实：workspace.load、history.list、history.append、connections.previewDBX。失败照常 ERROR。
• database.call 一个入口同时承载显式查询和 UI 浏览，所以按真实 method 只抑制当前调用的成功事实：checkWriteProtection、describeTable、diagnostics、listDatabases、listForeignKeys、listIndexes、listObjects、listTables、pageTable、nacosGetConfig、nacosListConfigs、nacosListInstances、nacosListServices、redisGetKey、redisScan。查询、写入和连接测试仍记 INFO；这些调用的失败和降级照常上报。
• 结果超过上限被裁剪（sizeLimited）时上报 degraded(<函数 ID>, "result_size_limited")，每个后端生命周期只报一次（AtomicBool），重复的大结果不会刷屏。失败调用由 SDK 记录，不会重复记一次。
• 删除对旧 SDK NOT_NEGOTIATED 错误码的分支：新 SDK 没有这个常量，plugin.host.* 的映射不变。
• main.rs：协议通道建立前（listen 之前）的启动失败不再 eprintln!，直接以退出码结束，由宿主的进程生命周期记录，避免出现第二个 stderr 写入方。

端到端测试与 CI

• scripts/e2e.mjs 改为必须显式传 --source 和 --ref：新 SDK 要求 Core 支持 litheLogging 1，原来 e2e/lithe-core.json 固定的旧 commit 已不满足。
• e2e/database_plugin.rs：每次调用后读取 diagnostics.drainCoreEvents，断言恰好一条类型化终态事实，并核对通道 plugins/<id>/host、级别（成功 INFO，失败 ERROR）、operation 和 op 关联；被抑制的调用不应出现成功事实。
• .github/workflows/ci.yml 与 release.yml 的 e2e 改为 --source https://github.com/1lck/Lithe-IDEA.git --ref preview。
• README 新增“宿主日志接入”一节，说明协商、抑制规则、降级事实，以及日志不写安装目录。

验证

• 本地（backend/ 目录，与 CI 一致）：cargo fmt --all -- --check、cargo clippy --locked --all-targets -- -D warnings 通过；cargo test --locked 20 + 22 项通过；node scripts/verify-sdk-source.mjs 通过。
• 此前在 Codex 工作区对本地宿主分支跑了 e2e：真实 SQLite 大结果触发一次 result_size_limited，SQL 失败记 ERROR，Core 中的 INFO/WARN/ERROR 级别和 op 关联正确；日志里没有 SQL、路径或行数据。

预期的 CI 状态与合并顺序

• 宿主 #1699 合并进 preview 之前，CI 和 release 的 e2e 会因 Core 不支持 litheLogging 1 而失败，这是预期结果。
• 合并顺序：宿主 #1699 → SDK #17（先同步 contract/v1）→ 本 PR。发布前把 vendor/lithe-plugin-sdk/ 重新固定到 SDK #17 合并后的 commit，并更新 source-provenance.json。
• 本 PR 没有改插件版本号，按插件发布流程另行发版。

限制

• 只覆盖 macOS 宿主；Windows 仍是 v1 writer，未做 Windows 验收。
• 未在 Lithe 整机日志窗口里做端到端验收。

配套 PR：

• 宿主 Core：feat(logging): 插件与调试适配器接入结构化日志 v2 1lck/Lithe-IDEA#1699
• SDK：feat(sdk): 三种 SDK 接入 litheLogging 1 结构化诊断 lithe-plugin-docs#17
• Database 插件：https://github.com/Lithe-IDEA/lithe-plugin-database/pull/2（本 PR）
• Docker 插件：feat(logging): 接入 litheLogging 1 结构化诊断 lithe-plugin-docker#3
• HTTP Client 插件：feat(logging): 接入 litheLogging 1 结构化诊断 lithe-plugin-http-client#5
• Cargo 插件：feat(logging): 接入 litheLogging 1 结构化诊断 lithe-plugin-cargo#5
• SVN 插件：feat(logging): 接入 litheLogging 1 结构化诊断 lithe-plugin-svn#2
• Maven 插件：feat(logging): 接入 litheLogging 1 结构化诊断 lithe-plugin-maven#9
• Lua 插件：feat(logging): LuaLS 日志写入宿主会话日志目录 lithe-plugin-lua#6
• Go 插件：feat(logging): 接入结构化日志 v2 插件操作事实（由宿主代记） lithe-plugin-go#3
• Gradle 插件：feat(logging): 接入结构化日志 v2 插件操作事实（由宿主代记） lithe-plugin-gradle#5
• LLDB 插件：feat(logging): 接入结构化日志 v2 插件操作事实（由宿主代记） lithe-plugin-lldb#3
• PHP 插件：feat(logging): 接入结构化日志 v2 插件操作事实（由宿主代记） lithe-plugin-php#3