| name | thinking-kernel |
| description | Use when working in a technical domain with no existing playbook, writing new coding guidelines / review criteria / checklists from scratch, judging whether a verification method actually proves a claim (test passed but does it count?), or when repeated fixes keep failing and the direction feels wrong. Domain-agnostic reasoning moves that generate concrete decision criteria for any field — not tied to any language or framework. |
🌐 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 次再抽。
新領域套用：找出領域裡所有不可逆操作（刪資料、對外發送、改公開契約），它們就是防護預算該花的地方。
使用流程（遇到沒有手冊的領域時）
- 入場預習：動手前先派 research agent 收集該領域的已知坑與慣例（官方 pitfalls、事故案例、release 檢查清單）——首次學費先付折扣價；產出餵給動作 1–3 當原料，不替代它們。
- 動作 1 先跑：列環境差異軸 → 得到該領域的「release 必查清單」雛形。
- 動作 5 次跑：列資源與狀態 → 得到架構判準雛形。
- 動作 3 掃一遍領域格言 → 把不可裁決的重寫。
- 產出的每條判準用動作 2 配失敗情境、用動作 4 問能否機器強制。
- 寫成手冊（格式照
_meta/style-contract.md）＋每條高風險判準配一題測驗。
誠實條款（內核帶不走的部分）
七個動作能生成判準，但權衡的手感（多條判準衝突時的輕重、品味、審美）無法文件化。
遇到品味題：明說信心低、給選項附實例讓使用者選，禁止假裝有把握。標註不確定不扣分，編造才扣分。
