db-engine-selection

db-engine-selection（M0）——给出建议，不评分

M0 在设计阶段 / /claude-db:start运行，此时可能还没有架构，只有对工作负载的描述。它回答“这应该使用哪种数据库？”它不是评分模块：不会输出任何发现项，没有维度或严重性，也不会进入 score.mjs 或两个评分中的任何一个。它的输出是一份独立的建议契约（见下文）。它会沿着 references/engine-selection-tree.md 中的决策树进行判断。

收集的输入

从用户的描述中收集（或通过 references/detection-signals.md 检测技术栈）：

• 访问模式——按键精确查询、范围扫描、复杂的多实体联接、全文／语义搜索、按时间排序的分析、图遍历、扇出读取／写入。
• 一致性与完整性需求——强一致／事务性还是最终一致；多行不变量；是否需要由数据库强制执行引用完整性。
• 规模与形态——预期规模、写入速率、读写比、基数、数据是否为只追加／时间序列数据，以及向量／嵌入工作负载。
• 可运维性与团队——托管还是自托管、无服务器／边缘、现有专业知识、平台限制（与 db-platform-fit M21 交叉检查）。

如何做出决策（决策树摘要；完整决策树见参考文档）

1. 对事务性、多实体、对完整性要求高的工作负载，默认选择关系型数据库（Postgres 是稳妥的默认选项；若生态系统要求，则选择 MySQL/MariaDB）。
2. 当数据以聚合为中心、通过单一访问模式读取、嵌入优于联接，且团队接受由应用程序强制执行完整性时，选择文档型数据库（Mongo/Firestore）。
3. 对已知键的精确访问、缓存、会话和高吞吐量简单操作，选择键值型数据库（Redis/DynamoDB）。
4. 对大规模、写入密集型、每个查询对应一张表、以分区为先的工作负载，选择宽列型数据库（Cassandra/Scylla）。
5. 对语义搜索／RAG，选择向量数据库（pgvector/Qdrant 等）——通常是与主存储搭配使用，而非取而代之。
6. 对只追加的指标／事件以及时间范围分析，选择时序数据库（Timescale/ClickHouse/Influx）。
7. 当遍历深度／关系查询是核心工作负载，而非事后考虑时，选择图数据库（Neo4j）。 多存储方案也是合理选项：说明每种存储及其用途。若单一引擎能够可靠地满足工作负载，优先选择“Postgres + 扩展”（pgvector、JSONB、分区、FTS），再考虑添加第二种引擎。

建议契约（M0 的输出——不是发现项）

一份由 /claude-db:start 呈现的结构化建议对象，包含以下字段：

• recommended — { paradigm, engine, platform? }。
• rationale — 指明哪些访问模式／一致性／规模事实促成了该建议，并对应决策树中的分支。
• runner_up — { paradigm, engine }，以及选择该建议而非备选项的明确权衡（你将放弃什么）。
• assumptions — 假设的工作负载事实；如果某项事实未知，应在此列出，不得凭空编造。
• confidence — established | directional | speculative（仅根据描述提供的输入，置信度最高为 directional）；缺少关键信息时为 speculative。
• caveats — 关于锁定、可运维性和平台的说明（具体价格／限制由 M21 或供应商页面提供）。 此对象作为指导呈现；它不符合 schema/finding.schema.json，也不会出现在 audit-report.schema.json 中。

验证与诚信

• 绝不编造基准测试、延迟、吞吐量、价格或行数上限来为选择背书。 根据有文档记录的属性（如一致性模型、是否支持 FK、索引类型、可运维性、供应商锁定）进行比较， 并将各项程度标为高|中|低。仅在引用原文时通过 WebFetch 引用供应商页面。
• 始终指出次优选项及其权衡——没有备选方案的推荐是一个危险信号。
• 如果工作负载描述不充分，请明确说明并提问（或标记 confidence: speculative）；不要凭空做出选择。
• M0 不产生评分，也绝不设上限——其设计本身仅提供参考。当存在现有架构时，正确性判断应交由经过评分的模块（M1..M22）和审计器负责。