"Process"
- 程序、服務與狀態怎麼判
要判斷一個程式活著沒、某個系統服務現在由誰提供、桌面 session 有沒有被鎖、或終端機多工器的 session 還在不在時，用對的權威來源而不是靠畫面或猜的名字
- 高 ROI 無外部觸發的工作會被結構性跳過
工作有兩個獨立維度：ROI 高低 + 是否有外部觸發。高 ROI + 無觸發 = ROI 的承諾、拖延的現實。靠紀律不可行 — 結構性偏差需要結構性對策（外部觸發 / CI / hook / 排程 / pair）。本卡是 #67 便利反相關、#68 checkpoint 跳過、#69 RED 跳過的共同上位原則。
- 分批 ship：低風險可見價值先行、結構性下輪
「一次 ship 全部」的衝動 vs 「分批 ship」的設計：判準三軸（使用者可見性 / 風險暴露面 / 驗證需求）。低風險 + 高可見 = 立刻 ship；高風險 + 需驗證 = 下輪。對抗「完整才完整」的全做衝動、避免一次塞太多 review surface 拖延上線。
- 卡片系統的迭代浮現：原子卡 → meta-卡 → reference 三層展開
知識卡片系統不是一次寫成、是 dialogue → 原子卡 → meta-卡 → reference 的迭代浮現。每一輪迭代解決上一輪的 over-fit / under-fit、串連分散的卡片、抽出 meta-原則、最後沉澱成可直接套用的 reference 文件。本卡是 cards-skills 系統設計的 process-level 元原則。
- 字面攔截 vs 行為精煉：驗證手段跟錯誤層次的對齊
驗證手段必須跟錯誤層次對齊：字面錯誤（typo / syntax / 缺欄位）用 hook / lint / CI 攔截；行為錯誤（思考偏差 / 判斷錯位 / collapse 反模式）用 multi-pass spiral 收斂。強行用 hook 蓋行為錯誤 = 給出 false confidence、反而比沒保護危險。本卡是 #72 結構性對策在「驗證粒度」維度的 ceiling — 不是所有錯誤都該被攔截。
- 升級 trigger 的量化設計：「不夠就升 Y」需要明確的「不夠」指標
「先做 L1、不夠時升 L2、再不夠升 L3」這個分批 ship 順序看似合理、但「不夠」沒量化就會 #72 結構性跳過 — 永遠覺得「再觀察一下」、永遠不升級。本卡定升級 trigger 的量化設計：閾值、觀測窗口、決策週期、自動 vs 人工觸發。預設是寫 L1 ship 時就同步定 L2 升級的 trigger 條件、不是 ship 後才想。
- 工具的預設行為決定使用者習慣 — 從版本錯置看工具設計的 opinion 責任
規範與工具預設不一致時工具會贏。預設路徑就是團隊的實際流程，接受自由輸入的介面設計時要負起 opinion 責任。
- 10 個 Ticket、57 個綠燈、0 條追溯：從需求文件到測試的銜接檢討
單元測試全綠、卻答不出「這些測試覆蓋了哪些 UseCase 場景」。需求到測試缺反向追溯時的流程缺口盤點與對應修法（追溯矩陣、存根策略、拆分規則）。