五条已经拍板的取舍

先交付可评审本体与分层，再按阶段过门实现。所有写入只经命令网关，没有表单式 CRUD。

否决：先做 CRM 再补架构 → 客户表会先落地，以后迁不动。

通讯外购。OS 只做连接器。审批事实留在 ApprovalCase。

否决：站内信当主通道 → 12 个月后就是自研 IM。

一个可部署单元 + 一个 PostgreSQL + 包级领域边界。

否决：一上来微服务 → 必复制主数据。

业主、供应商、员工都是 Party + 角色。外键只许 ObjectId。

否决：每系统自建客户晚上 ETL 对 → 白天已分叉。

每模块一份 manifest；对象归 owner；扩展别人只能 1:1 扩展表与 validate/before/after 钩子；权限只收紧；槽位不 XPath；配置声明、部署时应用；禁用不删数据。

否决：直接用 Odoo 二开 → 后台交易模型不是本体，界面与国情摩擦大，人力市场稀。运行时 monkeypatch → 升级即重做。

只消费发现文档 + JWKS；登录主体绑定 Party，没有用户表；can_command / can_approve / can_read / can_export 由模块片段取交集，只收紧；Agent 在会话内行动。

否决：自建账号密码 → 第二张用户表；handler 里 if (role === "经理") → 权限散落不可审计。

声明过的查询是模块间唯一读接口；owner validator 与审批前预检；扩展字段走 owner 命令 + 扩展方钩子；旧 ID 永远可解析到新 ID；Agent 读记审计、人读不记；冻结后只修不扩。

否决：留着 ADR 与代码的矛盾不管 → 半年后没人知道哪个是真的。