用途：指导 Bitwarden 服务端数据库相关开发，包括架构、迁移与双 ORM 策略。
主要能力： 双 ORM 架构：MSSQL 使用 Dapper 加存储过程；PostgreSQL、MySQL、SQLite 使用 Entity Framework Core。两者运行时互斥，但遵循相同仓储接口。新增仓储功能需同时实现 Dapper 与 EF Core，除非该功能明确仅限 EF（如 Secrets Manager）。以向后兼容方式修改现有存储过程（如新增带默认值的参数）时无需改 EF Core。
演进式数据库设计：Bitwarden Cloud 采用不可回滚的数据库部署，服务器可回滚但迁移不可，因此迁移须避免成为停机来源。MSSQL 迁移位于 util/Migrator/DbScripts/，按文件名 YYYY-MM-DD_##_Description.sql 时间顺序执行。DbScripts_transition/ 与 DbScripts_finalization/ 当前未使用，可忽略。简单增量变更（新增可空列、新表、新存储过程）通常只需一个迁移脚本。
存储过程兼容性：非破坏性变更（带默认值参数，如 @NewParam BIT = NULL）向后兼容，无需 _V2；破坏性变更（结果集结构变化、调用模式变化、新增无默认值必填参数、查询语义不同）需创建 ProcedureName_V2 并保留原过程。表级破坏性变更（删列、改类型）常级联到存储过程，往往需要 _V2。迁移策略复杂且依赖上下文，应始终交由开发者决定：编写迁移脚本后询问是否需要 _V2 或额外步骤。
关键位置：src/Sql/dbo 为主架构来源；util/Migrator/DbScripts 存放全部迁移。
实现分工：实现 Dapper 仓储方法、存储过程或 MSSQL 迁移脚本时启用 implementing-dapper-queries 技能；实现 EF Core 仓储、生成 EF 迁移或处理 PostgreSQL/MySQL/SQLite 时启用 implementing-ef-core 技能。
关键规则：迁移文件命名 YYYY-MM-DD_##_Description.sql；所有架构对象使用 dbo 架构；约束命名 PK_TableName、FK_Child_Parent、IX_Table_Column、DF_Table_Column；迁移脚本使用 IF NOT EXISTS / IF COL_LENGTH(...) 守卫保证幂等；新仓储功能需同时实现 Dapper 与 EF Core，除非明确仅限 EF 或为向后兼容的存储过程修改；集成测试使用 [DatabaseData] 属性，对全部已配置数据库提供程序运行。
限制：资料未提供具体安装命令、收费信息或平台支持细节。