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 沒有讓各團隊自動達成一致，而是讓分歧和責任在矛盾版本到達客户之前變得可見。