🌐 English version · 繁體中文（正本 / canonical）

思考內核：生成判準的七個動作

定位：各 domain 手冊（android/ios/flutter/frontend-web/backend-server playbook）是「判斷的結晶」； 本檔是「產生那些判斷的動作」。遇到手冊沒覆蓋的領域或情境，不要憑感覺——跑這七個動作， 自己生成判準。生成後寫回手冊並同步加一題測驗（規則與測驗同進退）。 完整的跨領域推導對照與陌生領域實戰示範見 references/derivations.md。

動作 1：證據力分級——「這個驗證能證明這個主張嗎？」

程序：①列出「驗證環境」與「主張所在環境」的差異軸（編譯模式、機器、資料量、並行度、環境旗標、時間） ②主張若落在某差異軸上，該驗證證據力為零 ③換一個覆蓋該軸的驗證，或明說「這點未驗」。 推導示範：debug 綠燈↛release 安全（R8 只在 release 生效）；單機測過↛滾動部署安全（部署窗口新舊並存）； 模擬器↛簽章/entitlement（模擬器不做真簽章）。 新領域套用：先問「這領域有哪幾條環境差異軸」——每條軸自動生出一批「X 驗不出 Y」判準。

動作 2：失敗情境構造——「什麼輸入/狀態 → 什麼壞結果？」

程序：對任何規則、寫法、review 意見，強制構造一條具體失敗鏈：「當 [輸入/狀態] 時會 [壞結果]」。 構造得出來 → 這是真問題，嚴重度看壞結果；構造不出來 → 降級為 nit 或刪掉。 推導示範：「catch 後只 log」→ 上傳失敗時使用者看到永遠轉圈的 spinner（真問題）； 「這裡命名不夠優雅」→ 構造不出失敗鏈 → nit。index 當 list key → 刪除一列時勾選狀態錯位到別列。 新領域套用：這是 review 與寫規則的品管閘：說不出失敗情境的意見不准進清單。

動作 3：可裁決性測試——「拿三個具體情境來，判得出 A 或 B 嗎？」

程序：寫下候選規則後，造三個邊界情境去測。任何一個判不出 → 補上數字門檻、次數、 明確訊號，直到三個都可裁決。判不出的規則等於沒寫。 推導示範：「保持元件簡潔」（判不出）→「同一結構第 3 次重複、需獨立測試、或有自有狀態才抽； 2 次先忍住」（可裁決）。「適時引入 UseCase」→「被 ≥2 個 ViewModel 用、或組合 ≥2 個 Repository 才建」。 新領域套用：把領域裡的每句格言（「保持簡單」「注意效能」）過一遍此測試，重寫成可裁決版。

動作 4：非法狀態不可表達——「這條紀律能不能變成機器強制？」

程序：發現「要靠人記得」的規則時，沿強制力階梯往上搬： 型別/schema > 編譯器/約束 > lint/CI > 文件 > 口頭紀律（越左越可靠）。 搬不上去的才留在文件層，並問為什麼搬不上去。 推導示範：「loading 和 error 不會同時為真」靠紀律 → sealed type/AsyncValue 讓矛盾態無法表達； 「註冊前先查 email 重複」靠先查再插 → DB unique constraint 讓重複無法寫入； 「UI 狀態要在主執行緒改」靠自覺 → @MainActor 型別層標註讓編譯器抓。 新領域套用：列出領域裡最常被違反的三條紀律，逐條問「階梯上能搬到哪一層」。

動作 5：生命週期與所有權對齊——「它該活多久？誰擁有它？真相在哪？」

程序：對任何狀態、資源、背景工作，回答三問：①需求上它該活多久 ②誰負責建立與銷毀 ③同一份資訊的「真相」只有一處嗎。機制的生命週期必須等於需求的生命週期——過長是洩漏，過短是資料遺失。 推導示範：「畫面關了上傳要繼續」→ 不能用畫面綁定的 scope，也不能用失控的全域（GlobalScope）， 要注入的 App 級 scope；遠端資料多處各存一份 useState → 真相分裂，改單一快取；ctx 存進 struct → 活過請求，錯。 新領域套用：把領域裡每種資源（連線、暫存、快取、任務）列出來各答三問，答不出的就是未來的洩漏點。

動作 6：打地鼠偵測與回退——「錯的是手，還是上游假設？」

程序：出現任一訊號：①同一錯誤修 2 次仍在（修法只是變形）②每修一處冒出新的一處 ③例外處理越加越多 ④想把測試/警告改掉讓它閉嘴 → 停止當前層的嘗試，往上一個決策點回退， 把該層的假設逐條寫出來重驗，而不是給第三種修法。 推導示範：keep 規則逐類補、補完一個爆下一個 → 回到規則層整包 keep model 目錄； suppressHydrationWarning 越灑越多 → 回到「render 期讀了什麼分歧值」；ANR 改寫三次還在 → 先量測找真正阻塞點。 新領域套用：此動作與領域無關，原樣可用；重點是「回退到哪一層」——列出你這條路依賴的假設，最可疑的先驗。

動作 7：成本不對稱權衡——「做錯的回頭成本 vs 事前多花的成本」

程序：行動前比較兩個數字：A=做錯後回頭的成本（不可逆？影響面？）B=事前防護的成本 （問一句、多驗一輪、分兩步走）。A≫B → 防護照做，嫌麻煩不是理由；A≈B 或可逆 → 直接做，別過度儀式。 推導示範：migration rename 一步到位（A=部署窗口 500 風暴）→ 寧可拆五步三個 release； 「要不要先問使用者」→ 兩種解讀返工成本高才問，變數命名不問；過早抽象（A=抽錯的解耦成本高於重複）→ 第 3 次再抽。 新領域套用：找出領域裡所有不可逆操作（刪資料、對外發送、改公開契約），它們就是防護預算該花的地方。

使用流程（遇到沒有手冊的領域時）

0. 入場預習：動手前先派 research agent 收集該領域的已知坑與慣例（官方 pitfalls、事故案例、release 檢查清單）——首次學費先付折扣價；產出餵給動作 1–3 當原料，不替代它們。
1. 動作 1 先跑：列環境差異軸 → 得到該領域的「release 必查清單」雛形。
2. 動作 5 次跑：列資源與狀態 → 得到架構判準雛形。
3. 動作 3 掃一遍領域格言 → 把不可裁決的重寫。
4. 產出的每條判準用動作 2 配失敗情境、用動作 4 問能否機器強制。
5. 寫成手冊（格式照 _meta/style-contract.md）＋每條高風險判準配一題測驗。

誠實條款（內核帶不走的部分）

七個動作能生成判準，但權衡的手感（多條判準衝突時的輕重、品味、審美）無法文件化。 遇到品味題：明說信心低、給選項附實例讓使用者選，禁止假裝有把握。標註不確定不扣分，編造才扣分。