Ledgerly 的委托计费功能在技术上仍处于 Beta。工程知道，产品知道，发布目录也写得很清楚。但周三早上，一名销售经理转发了一份公司销售助手生成的方案。方案声称委托计费已经正式可用，并承诺任何账户管理员都能立即转移账户所有权。
两句话都不是真的。
这家 75 人 SaaS 公司并不是没有记录功能，而是在太多地方分别记录。产品规范描述预期体验，Identity 管理权限模型，Billing 管理财务约束，支持团队有一份 Beta 排错指南，Security 有一项威胁模型例外，销售则把旧发布 Brief 复制到自己的 AI 空间。每个团队都在自身边界内谨慎工作，但公司的 AI 工具并不共享同一个发布状态。
Ledgerly 为委托计费建立 onemind Launch Project。它没有把全部来源复制进一个巨型文档，而是引用 Product、Identity、Billing 和 Security 的正式条目，再加入本次发布特有的负责人、Cohorts、证据和公开表述。只有 Product 能改变发布状态；只有 Identity 能批准授权规则；Billing 拥有“所有权转移不能让未付余额消失”等财务约束；Security 拥有威胁控制。Sales 和 Support 消费这些事实，但不能重新定义它们。
销售助手的工具包最先改变。它收到 Beta Cohort、两条获批表述、三条禁止表述和企业合同问题的升级路径。支持助手收到当前客户 Cohort 已发布行为、诊断步骤和账户安全语言。Cursor、Codex 和 Claude Code 收到授权规则、API 合同、迁移和回归测试。Security Agent 收到威胁评审和证据要求。
Beta 开始两周后，Acme Holdings 提交支持工单。一名管理员把计费工作委托给同事，原账户 Owner 随后离职。同事可以准备发票，却无法完成所有权转移。支持助手搜索正式指引，没有找到答案，于是升级处理，而不是编造一个。onemind 创建与发布关联的 Incident 子 Project。
支持团队附上经过账户安全处理的时间线。Identity 负责人发现权限模型默认原 Owner 始终可用。Billing 发现第二个风险：如果在待处理发票期间改变所有权，税务文件接收者可能改变。编程 Agent 提出简单绕过方式，但 onemind 展示 Billing 约束和必须进行身份验证恢复的 Security 规则。
各团队最终同意一套恢复流程：需要两名授权管理员，或使用经过验证的支持流程。Identity 批准规则，Billing 批准发票状态行为，Security 批准证据要求，工程加入实现和回归测试。每项批准相互独立且清晰可见；产品经理不能代替 Security 批准安全解释。
正式条目变化后，onemind 计算受影响工具包。它更新编程工具，把两个开放 Pull Requests 标为过期，给 Support 增加排错分支，并修改 Beta 文档。Sales 收到更窄的获批表述。一份已为另一客户生成的草稿因为引用被替代工具包而被标记；onemind 没有静默修改文件，而是告诉销售人员哪些内容需要重新评审。
正式发布前，Launch Project 显示五条就绪通道。代码和测试是绿色，Security 证据已批准，支持文档已更新，但 Analytics 缺少一个恢复事件，两名 Sales 用户仍在使用旧工具包。缺失事件上线、旧用户更新或取得有记录的例外之前，发布不能标记为就绪。
所有项目关闭后，产品负责人才能改变发布状态。该事件重建 Support 和 Sales 的正式发布工具包，但不会改变历史 Beta 对话或事故证据。
三个月后，Ledgerly 比较普通跨职能变更。从产品变化正式接受到所有受影响工具确认更新，过去非正式需要两三天，现在大部分可在同一工作日完成。更重要的结果出现在评审里：因为公司已经决定的事实而需要纠正的支持回答、销售草稿和 Pull Requests 明显减少。onemind 没有让各团队自动达成一致，而是让分歧和责任在矛盾版本到达客户之前变得可见。