按能力协商适配器，而不是绑定数据库
让知识持续可靠 · 数据库只做 adapter
lorebit 不会从零实现数据库内核。它会根据每种存储的真实能力，通过 adapter 组合知识工作流；不能完成的能力必须显式暴露，而不是悄悄降级。
适配器分层
先列任务需要的能力
不要从“我们已经在用什么数据库”开始。先对照用户任务列出必要能力，再判断某个 adapter 是否能诚实提供它：
任何一个问题的答案是“不能”都不是失败；关键是把它公开为能力边界，再调整工作流或补充适配器。
能力协商比“支持某数据库”更重要
同一个数据库产品可能只启用了部分索引、过滤或事务能力。因此 adapter 应声明 capabilities，core 再据此决定一条查询或重建路径是否可执行。
这让使用者能看见选择的代价：例如只有向量检索时，系统可以明确说明关键词匹配不可用；而不是把结果变化伪装成正常行为。
用能力卡评审一条知识流程
未来 0.x 版本应让使用者或集成方看见每条流程实际协商到了什么能力，以及缺少它时影响哪个用户结果。它不要求今天给出某个 provider 名称或配置格式。
一张能力卡的结论可以是“当前不支持这条流程”，这比用不等价的降级悄悄给出看似正常的答案更诚实。
0.x 目标合同如何约束 adapter
adapter 是为了兑现 U6，而不是为了让 lorebit 绑定更多数据库。core 需要基于 adapter 声明的真实能力决定一条资料处理、检索或恢复路径能否满足用户合同；当不能满足时，使用者应得到确定性的限制说明、可选的缩小结果或明确的不支持，而不是 provider-specific 的隐式行为。
不属于 adapter 的事
- 决定哪一份 revision 当前有效。
- 在部分失败后协调重试或重建。
- 把检索结果组织成带来源的上下文。
- 把 DevCodex 或其他宿主当成唯一产品边界。
选择时避免两个误区
第一，不要把“能存向量”误写成“能交付可信答案”；检索只是证据路径的一段。第二，不要把 provider 名称写进核心规则；不同团队可能需要不同的文档、全文、向量、图或检查点能力组合。lorebit 的用户文档只帮助你表达这些选择，不替你指定供应商。
下一步：检查质量与恢复。