MDBX 执行模型规则
这个文件用于告诉低端模型如何在 MDBX 项目中工作，避免做出破坏性或低质量决策。
主要目标
产出必须与整套规范兼容。 如果遇到歧义，默认按以下优先级收敛：
- 保持本地优先
- 保持长期格式稳定
- 保持以
project为中心的存储模型 - 保持附件是一等能力
- 保持可安全合并
- 保持比 KDBX 更好的同步性能
绝对规则
你必须：
- 先读
README.md或README.zh-CN.md - 在提出架构变更前读完所有编号规范文件
- 把这个目录视为唯一规范来源
- 保持术语稳定
- 保持要求可测试
- 在满足规范的前提下优先选择更简单的方案
- 在任何修订中保持后向兼容
- 读写结构化记录时保留未知字段
- 保证秘密数据静态加密且有完整性认证
你绝对不能：
- 未经规范更新就发明新的核心对象类型
- 把
project替换成纯平铺entry模型 - 把附件做成没有 schema 支撑的临时外挂能力
- 让正常打开、编辑、保存、导入、导出、合并、恢复依赖服务器
- 让每次小修改都走全库重写
- 静默自动合并同一秘密字段的冲突值
- 为了短期实现方便破坏长期兼容性
- 在核心行为上写
TBD
必须遵守的工作方法
实现或规划时按下面顺序做：
- 先确认当前任务受哪个规范文件约束
- 列出会受影响的核心不变量
- 设计满足规范的最小方案
- 先定义数据结构，再定义 API
- 先定义持久化，再定义 UI
- 先定义冲突处理，再写同步逻辑
- 先定义验收方式，再宣布完成
默认领域假设
除非后续规范明确覆盖，否则默认认为：
- 密码按
project组织 - 每个
project可以包含多个entry - 一个
project可以有零个或多个附件 - 一个
entry也可以有零个或多个附件 - 附件是数据库中的一等数据，不是未记录的边缘文件
- 同步提供方是不可信的
- 网盘列目录、重命名等行为可能不是原子的
- 数据库必须离线可用
- 格式文档必须足够清晰，便于第三方实现
规范写作要求
如果你新增规范文档，必须：
- 先写规范性规则
- 使用简短而稳定的章节标题
- 术语定义一次后保持复用
- 明确写出拒绝情形
- 写出验收标准
- 如果影响兼容性，说明迁移影响
设计冲突时的优先级
如果两个方案都能工作，按以下优先级选：
- 安全正确性
- 数据耐久性与恢复能力
- 兼容性稳定
- 本地优先
- 同步友好
- 性能
- 实现简单度
- UI 便利性
当性能与规范冲突时
如果更快的方案会伤害耐久性、恢复性、兼容性或合并安全，就拒绝它。 MDBX 可以在内部更复杂，但不能牺牲长期可靠性。
当简单性与规范冲突时
只有在以下条件都满足时，才能选择更简单的方案：
- 不削弱安全
- 不削弱兼容性
- 不削弱同步行为
- 不移除
project模型 - 不移除附件原生能力
任务交付模板
给 MDBX 拆任务时，每个任务最好都包含：
- 目标
- 涉及文件或模块
- 假设
- 非目标
- 实现步骤
- 边界情况
- 测试
- 验收标准
失败定义
如果一个方案出现以下情况，就说明失败：
- 一个很小的元数据修改也会导致正常路径下重写整个 vault
- 密码只是无结构平铺列表，没有
project主容器 - 附件只是随意散落的外部文件，没有元数据、完整性和归属规则
- 不能解释并发修改如何检测
- 不能解释部分损坏如何恢复
- 不能解释未来版本兼容性如何处理