decision-path — 待處理決策的 ASCII 相依性圖表
決策並非發生在真空中。孤立看來合理的決策，經常會阻礙後續工作、預設了尚未建立的先決條件，或繞過已建立的安全閘門。decision-path 將因果關係、執行順序與矛盾透明地呈現於終端機中。
使用時機
- 已有待處理決策的庫存（來自 decision-briefing 階段 1、工作階段上下文或票務決策簡報），需要進一步結構化。
- 你必須識別哪些決策可以立即執行（根節點），以及哪些依賴於先決條件或外部阻礙。
- 你需要一個概覽，了解哪些建議能融洽地組合在一起，以及哪些建議在邏輯上或操作上相互衝突。
- 觸發詞：
/decision-path、「哪些決策彼此相依」、「決策相依性圖表」、「視覺化決策路徑」、「ASCII 決策樹」、「決策間的矛盾」、「檢查因果相依性」。 - 請勿使用：
- 首次發現並庫存開放問題 — 這由 decision-briefing 階段 1 負責。
- 將推薦選項整合成單一連貫概念以進行簽核 — 這由 decision-draw 負責。
- 以緊湊的五部分區塊呈現選項及其優缺點 — 這由 decision-shot 負責。
- 系統性地評估單一複雜決策（如加權評分、情境分析） — 這由 decide 負責。
決策家族中的邊界
| 技能 | 角色 | 輸入 | 輸出 |
|---|---|---|---|
decide | 系統性地結構化單一決策 | 標準、選項 | 評分矩陣、單一決策 |
decision-briefing | 將多個待處理決策分解為個別問題與選項 | 待處理項目清單 | 編號的 A/B/C/D 簡報、粗略相依性標記、批次預約 |
decision-path | 驗證並視覺化跨多項決策的因果關係與矛盾 | 來自簡報/註冊表的粗略標記 | ASCII 相依性圖表，包含 5 種節點評估與邊線狀態 |
decision-draw | 將建議整合為一個連貫整體以進行簽核 | 來自 decision-path 的彙整 | 概念、相互影響（僅建議變體）、反向傳遞 |
decision-shot | 將已完成的分析壓縮為主管摘要（1 個決策或緊湊組合） | 1 個已分析的問題或群組 | 五部分簡表，包含選項、優缺點與完整分析連結 |
decision-avatar | 建模使用者偏好與行為歷史 | 上下文、過去選擇 | 信心評級 🟢 / 🟡 / 🔴 |
與 decision-briefing 的合約與責任
decision-briefing 階段 1 已在攝入期間推導出粗略的相依性與執行順序（例如來自「之後自動：」、阻礙者或票務引用等訊號）。decision-path 不會重複此推導，而是直接建立在這些粗略標記之上：
- decision-briefing 提供粗略標記： 它提供待處理項目的原始庫存與初始耦合提示。
- decision-path 驗證、評估並視覺化： 它根據記錄的事實驗證訊號，將已確認的邊線與推測的邊線分開，為每個節點分配五項評估，並揭露閘門衝突。
- 關於差異的回饋迴路： 如果
decision-path發現簡報中缺少或錯誤表示的相依性，它絕不會默默吸收，而是明確地將其回報為修正註記給簡報。
每個節點的五項評級（以及邊線驗證狀態）
五個維度 [S E U Z W] 用於評估節點（在其系統脈絡中的待處理或已確定決策）。邊線則承載其語義關係類型（例如解鎖、阻擋、先決條件）與驗證狀態（已確認 vs. 推測）。
圖表中的每個節點都顯示一個緊湊的五元素評估字串：
[S+ E:<Option> U<Direction><Confidence> Z+ W-]
-
合理 (
S) — 技術與架構穩健性：S+：解決方案穩健，解決了實際問題，避免了人為複雜性。S~：部分合理，但存在維護或營運開銷。S-：錯誤的解決方案、表面文章或已被證實的死路（例如在錯誤的槓桿點進行過濾）。
-
建議 (
E) — 具體、有證據支持的建議行動：E:<Option>：明確的選擇（例如E:A、E:B、E:resolve、E:Step1）。E-：無法提出可行的建議（缺少事實或屬於高層級政策問題）。
-
使用者典型 (
U) — 與使用者過去習慣和已編碼規則的一致性（透過decision-avatar）： 分別編碼方向（選項是否符合習慣？）和驗證信心度：- 方向（
U後第一個字元）：+：使用者典型 — 符合過往決策、政策（CLAUDE.md）或明確偏好。~：中立 / 開放 — 無記錄在案的顯著歷史偏好。-：非典型 — 偏離慣常工作流程或既定習慣。
- 驗證信心度（第二個字元）：
- 在 ASCII 圖表中使用純 ASCII：
!：高 / 有根據（在文字中為 🟢 已記錄）。~：中 / 合理（在文字中為 🟡 取捨本質上屬於使用者）。?：低 / 未驗證（在文字中為 🔴 政策問題，無先例）。寧可升級處理也不要猜測！
- 在 ASCII 圖表中使用純 ASCII：
- 範例：
U+!（典型且已記錄）、U+~（典型，但需使用者判斷）、U-!（記錄在案的非典型）、U~?（開放，無先例 -> 升級）。
- 方向（
-
連貫 (
Z) — 與相鄰節點的軟性架構與風格和諧：Z+：與先決和後續決策無縫整合；形成一個無摩擦的 cohesive 整體。Z~：輕微的風格摩擦或營運開銷，但功能上可行。Z-：系統交互中明顯的摩擦（例如配置擴散、彆腳的耦合），但未違反硬性規則。
-
矛盾 (
W) — 硬性矛盾與政策/閘門違反（最重要的輸出 — 警報！）：W-：與其他建議、政策和有效安全閘門無矛盾。W+：硬性衝突 / 警報！ 使另一個建議無效、違反既定政策（CLAUDE.md、P-00x），或繞過有效的安全閘門。衝突的節點始終在矛盾區段中明確標示，並附上根本原因與解決路徑。
邊線類型與推導規則
相依性嚴格從來源文字推導，絕不憑空發明。邊線承載其關係類型與驗證狀態：
| 來源中的訊號 | 邊線類型 | 表示法 | 意義 |
|---|---|---|---|
| 「之後自動：...」、「解鎖」、「啟用」 | 解鎖 | +--> | 僅在來源決策之後，目標決策才變得可行（已記錄） |
| 「阻擋」、「防止」、「安全閘門觸發」 | 阻擋 | => | 在來源決策解決之前，目標決策被阻擋 |
| 「需要」、「事先需要」、「先決條件」 | 需求 | --> | 目標決策在邏輯上和時間上都需要來源決策 |
| 「後續決策」、「之後第二步驟」 | 序列 | --> | 執行之後的後續邏輯進展 |
| 「被測量結果反駁」、「過時」、「被取代」 | 使無效 | --X--> | 來源見解使目標決策過時 |
| 共享的 D-ID、Ticket-ID 或相同子系統但無文字證據 | 推測 | ?--> | 合理的耦合但無記錄在案的因果證明（未驗證） |
關於未驗證邊線的規則： 當文字中不存在明確的因果陳述時，邊線必須標記為推測 (
?-->) — 絕不能視為已確認的事實。若未記錄任何關係，則節點保持並列且不相連。
ASCII 圖表的格式指南
- 等寬字型與終端機最佳化： 最大行寬 100 欄。無寬表格導致換行而破壞終端機佈局。
- 字元集與純淨性： 純 ASCII。在圖表程式碼區塊內，不得出現表情符號（🟢🟡🔴）；信心度僅透過 ASCII 標記（
!、~、?）表示。 - 節點 ID： 僅使用現有識別碼（
PD-A、MD-A、BH-A、VM-A、QR-A、CL-A、MO-A、D-001、732597768）。絕不發明合成 ID！如果項目缺少縮寫，則使用其項目編號。後續內部步驟表示為未編號的邊線註解(...)。 - 分層結構：
LEVEL 0 - 獨立: 根節點、未受阻項目、外部觸發器。LEVEL 1 - 僅依賴一個: 直接後續項目。LEVEL 2 - 依賴多個 / 深層鏈: 多重相依性或深層序列節點。矛盾: 硬性衝突、閘門違反和相互矛盾的建議 (W+)。圖例: 每個圖表輸出中的必要項目。圖表中使用的每個結構字元（|、=Option、(...)、邊線箭頭）都必須列出並在圖例中解釋。
- 可選的 Mermaid 程式碼區塊： 如有幫助，可以附加一個額外的
mermaid程式碼區塊；但 ASCII 圖表仍是主要且權威的輸出。
範例（試點資料集：Ticket-Master 2026-09-13）
來自 Ticket-Master 決策簡報的真實摘錄（732597768、MO-A、CL-A、QR-A、387521104、CL-B）：
====================================================================================================
DECISION-PATH: 相依性圖表 (試點 Ticket-Master 2026-09-13)
====================================================================================================
LEVEL 0 - 獨立 (根決策與外部阻礙)
[732597768] 解決 GitHub 帳單問題 [S+ E:resolve U+! Z+ W-]
| 解鎖
+--> [MO-A] 發布 Wave 2 [S+ E:A U+~ Z+ W-]
[CL-A] clutch admin 合併 PR #6 與 PR #8 [S+ E:A U+! Z+ W-]
| 受阻於: [閘門「1 個審查核准」(無法自行核准)]
--> (後續決策: 將分支保護設為 0 或機器人)
[QR-A] 佇列重新命名 NTFS 接合點 (_TICKETS -> TICKETS) [S+ E:B U+! Z+ W-]
+--> [387521104] 夜間時段執行 (已記錄: 僅在 B 下)
[CL-B] 審查閘門試點: Mac 簽署金鑰 [S+ E:Step1 U+~ Z+ W-]
--> (後續步驟 2-4: 在金鑰佈建後建立模型自動化)
LEVEL 1 - 僅依賴一個先決條件
[MO-A] 發布 Wave 2 [S+ E:A U+~ Z+ W-]
| 需要: [732597768] (帳單已解決, 遠端 CI 閘門再次啟用)
| 需要: [閘門 PRIVATE.txt "綠燈遠端 CI"]
--> (後續步驟: 切換可見性仍僅限使用者操作)
LEVEL 2 - 依賴多個 / 深層鏈
[387521104] 在夜間時段自動遷移執行 [S+ E:B U+! Z+ W-]
| 需要: [QR-A]=B (NTFS 接合點已建立)
| 需要: (透過轉移票證在第二台主機上設定接合點 -
| 票證號碼未在簡報中說明)
----------------------------------------------------------------------------------------------------
矛盾與閘門衝突
----------------------------------------------------------------------------------------------------
[MO-A]=B X [閘門 PRIVATE.txt "綠燈遠端 CI"]
衝突: 選項 B 將僅基於本地測試就發布 Wave 2，
儘管兩個模組合約明確要求綠燈遠端 CI。
解決方案: 建議 A 強制先行處理 [732597768] (帳單)，從而解決衝突。
[CL-A]=StatusQuo X [閘門「1 個審查核准」(無法自行核准)]
衝突: master 分支要求 1 個審查，但唯一的儲存庫帳戶是 lukisch。
解決方案: 建議 A (管理員合併) 合法地打破了這個死胡同。
----------------------------------------------------------------------------------------------------
圖例與評級鍵
----------------------------------------------------------------------------------------------------
邊線與結構:
+--> 解鎖 / 啟用 (因果關係在來源中記錄)
=> 阻擋 / 防止 (閘門或外部阻礙)
--> 需要 / 序列 (先決條件或後續步驟)
?--> 推測相依性 (合理的耦合，但未記錄)
--X--> 使無效 / 取代 (來源見解使目標過時)
X 矛盾 / 衝突 (閘門或政策違反)
| 垂直層級線 / 屬性對應
[ID] 決策節點 (簡報中的項目縮寫或項目編號)
[閘門] 外部閘門 / 規則 / 合約 - 非決策節點
=Opt 節點的特定選項 (例如 [MO-A]=B)
(...) 未編號的邊線註解 / 後續步驟 (無發明的合成 ID)
節點評估 [S E U Z W]:
S: 合理 (+ 穩健 / ~ 有條件 / - 不合理)
E: 建議 (A, B, C, resolve, Step1, - 無)
U: 使用者典型 (方向: + 典型 / ~ 中立 / - 非典型;
信心度: ! 有根據 / ~ 取捨 / ? 升級)
[! = 已記錄 (文字中綠色), ~ = 使用者取捨 (文字中黃色),
? = 未驗證 / 升級 (文字中紅色)]
Z: 連貫 (+ 協調 / ~ 輕微摩擦 / - 架構斷裂)
W: 矛盾 (- 無衝突 / + 與閘門或政策的硬性衝突)
====================================================================================================
decision-path 不做什麼
- 不做決策： 此技能提供結構透明度。決策權屬於使用者。
- 不發明選項： 此技能不會腦力激盪新的替代方案或加權標準；這屬於 decide 或 decision-briefing 的範疇。
- 不執行緣由分析或框架評估： 系統性的權衡 (trade-off) 分析或加權評分矩陣，請參閱 decide。
- 不將多個決定合併為單一概念： 在圖表完成且矛盾解決後，將建議的整體概念整合起來，是 decision-draw 的工作。
- 不重複 decision-briefing 的攝取工作： 此技能期望一個現有的編號庫存，不會從頭開始編目待處理問題。
與決策生態系統的互動
- decision-briefing → 產生原始庫存、粗略標記與批次 ID。
- decision-path → 驗證標記、分析依賴關係、分配評級、繪製 ASCII 圖表、標記衝突。
- decision-avatar → 提供使用者典型性評級 (
U) 及邊線信心度 (!/~/?) 的查詢。 - decision-draw → 接收已驗證的結構；將推薦選項整合為單一概念以進行簽核。
- decide → 當單一節點需要多標準評估時，可被
decision-path或decision-draw調用。 - decision-shot → 將已完成的決定壓縮為供主管閱讀的摘要。