一口閘門 (hanipman-gate)
就一口。 別整碗端出來。
AI 開始寫程式後，瓶頸轉移了。產生變快了，但理解力還是老樣子。一次丟出60個檔案的 diff，人類三分鐘內就會放棄精讀，轉成快速掃過。
這個 repo 是把那個瓶頸從紀律轉移到結構的工具集。透過 Claude Code 插件市場發佈。
做什麼
設計討論
│
├─ ledger decide ────────▶ 決定記錄
│ ├ 當前設計 (僅已確認者 · 原子性替換)
│ └ 決定日誌 (僅追加 · 保留 SUPERSEDED)
│ │
│ current --topic 唯讀 (不讀完整文件)
│ ▼
└─ /impl-pipeline ──▶ 切片分解 ──▶ 委派 ──▶ /review-gate ──▶ /change-walkthrough
│ │
僅 GREEN ▼
通過 人類閱讀的是
"需要判斷 N 項"
總共就三條規則。
不讀完整設計文件。 委派時不傳文件路徑，只把已確認的決定本文放入提示。Token 成本與文件長度無關。
只把通過閘門的 diff 送到人類面前。 先跑診斷、慣例、設計一致性、範圍外洩。審查時間取決於需要判斷的項目數量，而非 diff 總量。
狀態無法手動記載。 跨多個 repo 的工作完成與否，由唯讀探針直接遠端查詢。不知道就保持未驗證。這比假的已完成好。
安裝
/plugin marketplace add 5hseok/hanipman-gate
/plugin install design-pipeline@hanipman-gate
插件分為三個部分。只裝需要的即可。
| 插件 | 功能 | 使用時機 |
|---|---|---|
design-pipeline | 決定記錄 → 切片 → 閘門 → 審查指南 | 設計與實作時。這是主體 |
track-ledger | 用探針實測多個 repo/工作階段的順序 | 同時執行多個工作階段或部署順序交錯時 |
explain-aids | 用於理解設計與 diff 的互動式 HTML | 需要向他人（或未來的自己）解釋大型變更時 |
session-board | 將工作階段現況濃縮成一張 Artifact | 追蹤文件太麻煩，只想看"現在進行到哪"時 |
技能
design-pipeline
| 技能 | 角色 |
|---|---|
design-workflow | 政策原始檔。記錄規則、閱讀協議、檢查點提交、風險等級 |
impl-pipeline | 協調器。將設計切成切片並跑完閘門 |
review-gate | 自動閘門。診斷、慣例、設計一致性、範圍外洩 |
change-walkthrough | 審查指南。按請求流程順序重新排列變更 |
design-reconcile | 記錄清理。搬移過期內容（不刪除） |
convention-audit | 慣例檢查。由 review-gate 實際呼叫 |
track-ledger
| 技能 | 角色 |
|---|---|
track-ledger | 建立與操作追蹤 |
track-ledger-policy | 不可變規則與跨工作階段通訊標準 |
session-board
| 技能 | 角色 |
|---|---|
session-board | 讀取 Claude 工作階段註冊表，將板子以 Artifact 發佈並用相同 URL 更新 |
沒有 CLI 也沒有伺服器。如果 track-ledger 感覺太重，可以先從這個開始。
explain-aids
| 技能 | 角色 |
|---|---|
explain-design-html | 實作前。為什麼選擇這個方向，捨棄了什麼 |
explain-diff-html | 實作後。什麼東西如何改變了 |
explain-skills-workflow | 上述兩者何時建議的標準 |
幾個設計判斷
閘門是非對稱的。 違反慣例用 RED 擋下，但"與設計不同"不擋，而是轉到判斷清單。慣例基於規則所以明確，而設計一致性是 LLM 的判斷，可能混有誤報；如果誤報一直阻擋正確實作，人類就會把閘門關掉。
不把部分失敗變成整體失敗。 raw diff 是真實的，產出是輔助的。產出生成失敗時會報告失敗，但不會阻止審查。
切片不是提交。 審查邊界與提交邊界分離。代理可以建議提交，但不會執行。
不加解釋註解。 不在程式碼註解中留下變更原因。那是審查指南負責的。註解弄髒程式碼，但指南在程式碼外部，審查結束後就會被丟棄。
需求
- Claude Code
- Python 3（僅標準函式庫。無第三方依賴）
- git
非必需，但有了會大幅改善：
- codebase-memory MCP —
change-walkthrough的核心產出"受影響但未修改"（呼叫變更的程式碼但自身未變更的程式碼）需要提取實際呼叫鏈。沒有它，這個項目會整個消失。 gh·aws·terraform— 追蹤探針使用。沒有則對應步驟保持未驗證。
記錄放哪裡都可以
技能不知道記錄在哪。只呼叫 ledger。
ledger current --file <task> --topic <slug> # 僅已確認的決定。不讀完整文件
ledger decide --file <task> --topic <slug> --title ... --supersedes D-3
ledger doctor # 哪個後端為何被選中
預設是 repo 內的 markdown（.claude/design/）。如果你在使用 Obsidian 筆記庫，
只要在 ~/.claude/ledger.json 寫入路徑就能直接使用現有文件。
{ "backend": "obsidian", "root": "/path/to/vault" }
尚未確認的事項
在製作者的機器上可以運作，但以下尚未確認：
- 從未在其他人的環境中從頭建置過。 已確認在空 repo 中用
markdown後端往返，但實際安裝並執行完整週期的只有製作者的環境。 - 從未用
markdown後端完成過整個管線。 已驗證轉接器往返，但尚未以 markdown 記錄完整執行impl-pipeline→review-gate→change-walkthrough。 - 不知道在非韓文專案中會如何呈現。 標題透過別名映射能識別兩種語言，但技能本文、閘門報告、板 UI 都是韓文。
- 從未實際測量審查時間是否減少。 設計意圖是"與需要判斷的項目數量成比例，而非 diff 總量"，但沒有前後比較的數據。
範例
examples/ 中包含一套記錄文件與一套追蹤文件。兩者都是用實際工具製作並重新讀取驗證過的，因此規格不會有誤。
授權條款
MIT。請參閱 LICENSE。
名稱由來
就一口。不是要整碗端走，只是要一口。這個工具也是這樣對代理說的。
gate 是兩個系統的共同語言。管線端有 review-gate，追蹤記錄端的步驟欄位本身就是 gate: merge / gate: apply / gate: deploy。