chore(wiki): wiki-init 補骨架 + system-dev-template 安裝/更新腳本

wiki 已初始化過（push 檔活躍維護），本次補從沒建的 pull 層 + arcrun 化範本：
- cards/decisions/ 14 張決策原子卡（含 gloss/實體/typed-edge 三元組）：
  從 decisions-summary 全量改寫 13 + 新增「薄殼規則晚於實作-MCP漂移是歷史債」1
- TAXONOMY 從 PKM 範本換成 arcrun 軸（子系統 零件架構/cypher/credential/recipe/kbdb/
  薄殼/部署/平台原則 + 形態 架構決策/踩坑/機制說明/禁令/案例經驗）
- principles 填 13 條跨全局原則（從 rules/ + mindset 蒸餾）
- INDEX 真實視圖（子系統角度 + 決策角度，指向 cards）
- system-dev/scripts/ + scripts/ install/update 安裝腳本（template 接入）

純基建/文檔，無業務 code（功能 code 見前一 commit）。
raw source（docs/）0 異動、wiki 卡際連結無斷鏈。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

system-dev/wiki/cards/decisions/Haiku能驅動是設計目標.md

@@ -0,0 +1,39 @@
+---
+tags: [平台原則, 架構決策]
+gloss: arcrun 能用 Haiku 驅動才算設計達成。撞牆不是換模型，是信號要改介面。
+---
+# Haiku 能驅動是設計目標
+
+← [[decisions/00-INDEX]]
+
+**來源**：`system-dev/wiki/decisions-summary.md`（Haiku 就能搞定是設計目標）、`.claude/rules/06-mindset.md §1`
+**最後更新**：2026-06-27
+
+## 摘要
+arcrun 的價值主張是「比直接開發容易 + 省 token + 省時間」。只有 Sonnet 能驅動時，「省」就不成立。Haiku 通過才是設計目標達成的證明；反之，Haiku 撞牆=介面缺陷信號，應改介面而非換模型。
+
+## 重點
+- **設計思想**：Haiku 作為基礎模型，若某操作需要 Sonnet 才行，代表介面太難、太多隱含上下文、需要手工智能補齊——這是架構欠債。
+- **測試邏輯**：
+  - Haiku 通過 ✅ → 設計目標達成，介面夠清晰
+  - Haiku 不通 → 升 Sonnet：
+    - Sonnet 通過 → 介面缺陷，要改介面白痴化
+    - Sonnet 也不通 → 功能 bug，要改邏輯
+- **不要的做法**：「Haiku 過不了就換 Sonnet」= 放棄設計目標、接受介面複雜度只有豪華模型才能應付。
+- **改進信號**：Haiku 哪個步驟卡住（參數寫法？狀態機理解？錯誤訊息太模糊？），就是該改哪個介面。
+- **誠實限制**（mindset §7）：Haiku 撞牆不要假綠（mock 迴應），要誠實標「需要 Sonnet」或「無法 resolve」，作為改進指標。
+
+## 實體
+- **Haiku**（Claude 3.5 Haiku）— 輕量級語言模型，arcrun 驅動的基準。
+- **設計達成**（design achievement）— 介面清晰度高到 Haiku 能自主操作，無需人工介入。
+- **介面缺陷**（interface defect）— Haiku 無法理解但 Sonnet 能理解的操作，表示介面隱含前置知識過多。
+- **功能 bug**（functional bug）— Sonnet 也無法做到的操作，表示後端邏輯確實有問題。
+
+## 關聯
+### 內文知識關係
+- 設計達成 >> 以 Haiku 通過 >> 衡量
+- Haiku 不通 >> 信號 >> 介面缺陷
+- 介面缺陷 >> 應該 >> 改介面
+- 功能 bug >> 應該 >> 改邏輯
+### 卡片關係
+- [[Haiku能驅動是設計目標]] >> 對應 mindset >> [[工作流是default零件是例外]]