decision-draw — 整體藍圖與捆綁決策的最終簽核 是做什麼的？
當五個或十個決策待定時，人們很容易迷失在孤立選項的細節中，而忽略新興系統的全貌。decision-draw 並不描述替代方案；它描繪出運作中的整體：一旦所有推薦方案到位，各個系統如何合作？使用者對整張藍圖進行簽核，或提供針對性的反饋。
使用時機
- 多項相互依賴的決策（來自 decision-briefing 或決策簡報文件）不應通過繁瑣的個別問題清單來逐一處理。
- 使用者希望在批准之前，先看到各個組件在實作後於日常實踐中如何實際互動。
- 透過依賴圖譜 (decision-path) 識別出的緊密耦合決策群組，可以作為一個功能單元一併簽核。
- 觸發詞：
/decision-draw、「如果我們同意所有事項，整體看起來會是什麼樣子」、「畫出整體藍圖」、「總體決策概念」、「decision draw」、「這些系統之後如何協同運作」、「整體簽核圖景」。 - 不要使用：
- 當使用者希望逐項評估不同選項並透過字母 (A/B/C) 選擇時——這由 decision-briefing 處理。
- 僅在終端機中進行因果與瓶頸分析時——這由 decision-path 處理。
- 針對單一議題或緊密分組的問題，進行離散選項評估（情境、各選項優缺點、建議）時——這由 decision-shot 處理。
- 為系統性地評估單一未決政策問題時——這由 decide 處理。
在決策家族中的邊界
| 技能 | 使用者體驗與焦點 | 對選項的立場 | 簽核模式 |
|---|---|---|---|
decision-briefing | 分解為個別項目 | 顯示所有選項 A/B/C/D | 字母代碼 (1A 2C 3B) |
decision-path | 結構化因果關係 | 在圖表中評估選項 | 終端機診斷 (ASCII) |
decision-draw | 連貫的目標圖景（捆綁相互依賴的決策） | 僅描述推薦的變體（替代方案透過連結引用） | 整體簽核或修正句子 |
decision-shot | 結構化的離散區塊（用於單一議題或緊密群組） | 顯示選項及 2–4 個優缺點條列 | 主管決策 / 個別審查 |
decide | 推敲出單一議題 | 評估矩陣（標準） | 分析性建議 |
核心規則：
decision-draw僅描述推薦的變體。被捨棄的替代方案並未消失——它們記錄在 decision-briefing、decision-shot 或連結的工單中，並在標題表格中引用。沒有此連結的繪圖會剝奪使用者的選擇權，而非簡化它。
強制結構（七個部分）
完整的 decision-draw 嚴格遵循此七部分佈局：
1. 捆綁與範圍
捆綁中所有項目的表格摘要：
- 縮寫 / ID（例如
BH-A、MD-A、CF-A） - 工單連結
- 項目標題
- 假定的推薦方案（此整體藍圖的前提）
decision-avatar信心水準（🟢 已記錄、🟡 權衡取捨、🔴 需要升級）- 連結至完整分析 / 替代方案
2. 概念
以連貫散文描述的目標狀態：
- 當所有推薦方案完全按計劃執行時，會浮現出什麼樣的系統景觀或工作流程？
- 沒有並排的選項比較，沒有假設性措辭（「也可以」）。
- 清晰、確定的陳述語氣：這就是系統在其目標狀態下的運作方式。
3. 相互作用
該技能的功能核心：
- 各決策組件在實作後如何實際結合在一起？
- 沿著具體的端到端營運流程來構建（例如「工單到達 → 代理啟動 → 後端分配 → 部署到主機」），而非靜態的組件列表。
- 釐清資料流、介面和營運責任。
4. 實作
具體的逐步推出計劃：
- 在實踐中，一步一步會發生什麼？
- 直接繼承 decision-path 的執行序列與依賴邏輯。
- 獨立的工作流被誠實地表示為平行軌道（不要發明人為的因果鏈；一個捆綁可以由多個平行軌道組成）。只有在有實質的依賴關係或截止日期時，才斷言順序排序。
- 強調關卡、遷移腳本和驗證檢查。
5. 此藍圖未涵蓋的內容
針對虛假完整性的邊界防禦：
- 哪些次要問題、未解決的問題或 🔴 信心水準被刻意排除？
- 與相鄰系統的邊界在哪裡？
- 一個隱藏其邊界的藍圖會產生虛假的安全感。
6. 簽核
使用者互動：
- 使用者審查整張藍圖。
- 回應選項 1：明確的整體簽核（「看起來不錯」、「批准」、「按提議實施一切」）。只有在這種情況下，所有捆綁項目才被記為已決策。
- 回應選項 2：以自然語言進行針對性修正（「BH-A 偏好較小變體」、「MD-A 不要自動重啟」、「VM-A 維持現狀」）。觸發分解為離散決策；所有未修正的項目保持開放。
7. 回寫
將使用者反饋系統性地轉譯為個別帳本條目：
- 無自動聯合記帳： 未更改的項目僅在明確的整體簽核時才被記帳。部分修正不是整體批准！
- 修正時的隔離： 如果使用者提交修正，它會被分解為個別決策；捆綁中的所有其他項目嚴格保持開放（在來源工單 / 帳本中），直到使用者接受調整後的整體藍圖或個別確認其餘項目。
- 強制回寫表格： 每個部分反饋都會生成一個結構化的評估表格，包含四列：
- 原始修正：使用者陳述的逐字內容。
- 受影響的鍵：哪些捆綁 ID 被更改（包括一擊多中，即一個陳述影響多個決策時）。
- 多米諾狀態：decision-path 中的哪些依賴節點或下游假設崩潰或需要重新評估。
- 未解決的歧義：修正允許多種解讀，需要在記帳前釐清的地方。
- 處理一擊多中： 單一使用者陳述可以同時更改多個決策。回寫必須解開此耦合並一起捕獲所有受影響的鍵。
- 獨佔寫入路徑 via Phase 4：
decision-draw對工單或登錄檔沒有原生寫入路徑。帳本更新僅透過 decision-briefing Phase 4 中的標準化協議（記錄並持久化到DECIDED-AND-DONE.md或TO-DECIDE-USER.txt）進行。
範例（試點數據集：Ticket-Master 2026-09-13 – BACH 與系統叢集）
來自日期為 2026-09-13 的 Ticket-Master 決策簡報的真實捆綁：BH-A、MD-A、CF-A、VM-A、PD-A。
# DECISION-DRAW：BACH 核心叢集與營運完整性
## 1. 捆綁與範圍
| 鍵 | 工單 / 來源 | 主題 | 假定推薦方案 | 信心水準 | 替代方案與詳情 |
|---|---|---|---|---|---|
| `BH-A` | `T-20260913-896336887` | 模型後端 = Heart | 1A / 2A / 3A / 4B / 5A / 6A | 🟢 | `docs/MODELL-BACKEND-KONZEPT_2026-09-13.md` |
| `MD-A` | `T-20260913-799464688` | Mac 部署與重啟 | A1 + 腳本（24/7 僅報告） | 🟢 | 工單 `T-20260913-799464688.txt` |
| `CF-A` | `T-20260913-947070291` | 跨主機的配置目標 | 1C（合理） / 2B（主機依賴） / 3B（高） | 🟢 / 🟡 | 工單 `T-20260913-947070291.<HOST>.txt` |
| `VM-A` | `T-20260906-496406575` | VersicherungsManager 時區 | A（應用程式級設定，如同 routinika） | 🟢 | 工單 `T-20260906-496406575.<HOST>.txt` |
| `PD-A` | `T-20260913-609930207` | USMC 頁面可見性 | A（將宣告對齊為公開，保持現狀） | 🟢 | 工單 `T-20260913-609930207.txt` |
*注意：所有被捨棄的替代方案（例如 BH-A E5=B ocean-heart、MD-A A2 完整寫入金鑰、VM-A B 每個設定檔區域）仍記錄在 Ticket-Master 決策簡報中。*
---
## 2. 概念
我們建立一個乾淨、解耦的多主機架構，其中模型後端作為一個名為 `agents-heart` 的獨立核心模組運作。角色、權限和預算在一個關聯式 SQLite 資料庫中乾淨地維護，而模型路由決策則分兩階段進行：BACH 建立領域限定的候選集合，而 clutch 在該集合中選擇成本與能力最優的模型。
在 Mac Studio 上，24/7 背景服務透過唯讀部署金鑰安全且可靠地運作；程式碼更新被自動拉取，而正在運行的 24/7 服務會收到溫和的通知，而非被粗暴終止。配置可能保留主機特定的設定（如果效能要求如此），而應用程式級設定（例如 VersicherungsManager 中遵循經過驗證的 routinika 模式的時區）則被確定性地硬編碼。USMC 仍然是規範性的公開記憶體外觀，並保留其在公開網站上的位置。
---
## 3. 相互作用
這五個項目並未形成序列因果鏈；相反，它們代表了模組化、解耦的日常營運完整性支柱，並行地在系統中相互連結：
- **核心架構與模型路由 (`BH-A`)：** `agents-heart` 模組將模型指派解耦。當任務到達時，BACH 決定領域限定的候選集合，而 clutch 選擇成本與容量最優的模型。
- **主機配置與部署完整性 (`CF-A`、`MD-A`)：** 雖然一致的推理努力適用於筆記型電腦和工作站 (`CF-A`；主機依賴模型保持透明)，但 Mac Studio 在驗證設定下執行持久背景進程。對於更新，Mac 透過唯讀部署金鑰拉取程式碼 (`MD-A`)；GUI 伺服器重啟，而長時間運行的 24/7 服務則溫和地通知儀表板有關更新要求。
- **領域持久性與截止日期 (`VM-A`)：** 類似 VersicherungsManager 的應用程式，遵循 routinika 模式，針對應用程式級 `settings` 表格持久化截止日期。計算和截止日期監視器在所有設定檔上，基於相同的 IANA 時區，以確定性方式運作。
- **公開展示 (`PD-A`)：** 夜間站點建置器驗證儲存庫狀態。USMC 在其修正後的 `public` 宣告下被乾淨地發布，在安全閘門中觸發零警報。
---
## 4. 實作
由於來源數據集並未在依賴圖譜 ([decision-path](../decision-path/SKILL.md)) 中證實這五個項目之間的序列鏈，因此推出計劃被誠實地結構化為四個獨立、平行的工作流（方法 a：平行軌道而非發明因果關係）。順序排序僅在存在外部截止日期或內部步驟時才適用：
- **軌道 A（時間緊迫 – 截止日期 2026-09-14）：**
1. 將 USMC 中繼資料對齊為 `public` (`PD-A`)；捨棄草稿 PR #2。由於夜間建置器運行，不能容忍延遲，但此步驟在技術上完全獨立於所有其他軌道。
- **軌道 B（主機配置與 Mac 部署 – 可平行化）：**
1. B1：在 `.SYNC` 中將配置目標編纂化 (`CF-A`)，將兩個主機的推理努力同步至 `high`。
2. B2（獨立於 B1）：在 Mac Studio 上安裝唯讀部署金鑰並設定拉取與報告自動化腳本 (`MD-A`)。
- **軌道 C（領域資料庫 – 可平行化）：**
1. 在 VersicherungsManager 中，遵循 routinika 模式實作應用程式級 `settings` 表格遷移 (`VM-A`)，為後續的發布者開發建立乾淨的基線。
- **軌道 D（架構提取 – 內部多階段計劃）：**
1. D1：在 `agents-heart` 中設定角色和預算的 SQLite 結構 (`BH-A` E1)。
2. D2：將後端目錄提取為 Python 模組 (`BH-A` E3) 並綁定 clutch 分配接縫 (`BH-A` E2)。
3. D3：提取並綁定 `agents-heart` 模組 (`BH-A` E5, E6)。
---
## 5. 此藍圖未涵蓋的內容
- **任務認領競爭條件：** 允許重複任務認領的並發錯誤正在專門的熱修復工單中處理，不在本次簽核範圍內。
- **駕駛艙前端：** 監控駕駛艙 (`BH-A` E4) 被刻意延遲，直到後端產生即時營運遙測資料為止。
- **發布公開儲存庫：** 合併和暫存程式碼不會自動使私有儲存庫公開；最終的可見性切換保留給使用者。
---
## 6. 簽核
您可以整體簽核此系統叢集，或提供自然語言調整：
- **明確的整體簽核：** 「看起來不錯，完全按提議實施。」（只有這樣才能觸發所有項目的記帳）。
- **修正範例：**
- *「Mac 不要主機特殊處理：MD-A 需要完整寫入金鑰 (A2) 以直接推送，而 CF-A 應嚴格將所有配置對齊到工作站 (Group 1=A, 2=A)。」*（一擊多中）
- *「對於 BH-A E5，將其命名為 ocean-heart 而不是 agents-heart。」*
- *「暫時推遲 VM-A；發布者可以等。」*
---
## 7. 回寫
當概念被批准或修改時，該技能將反饋轉譯為帳本條目：
### 案例 A：明確的整體簽核
當使用者明確批准整體藍圖時（例如*「看起來不錯，完全按提議實施」*）：
- 所有五個項目（`BH-A: 1A/2A/3A/4B/5A/6A`、`MD-A: A1`、`CF-A: 1C/2B/3B`、`VM-A: A`、`PD-A: A`）作為 DECIDED 傳遞給 [decision-briefing](../decision-briefing/SKILL.md) Phase 4。
- Phase 4 執行帳本記
…
[為翻譯而截斷]