diff --git a/system-dev/docs/3-specs/pending-changes.md b/system-dev/docs/3-specs/pending-changes.md
index fc8b3ec..833d972 100644
--- a/system-dev/docs/3-specs/pending-changes.md
+++ b/system-dev/docs/3-specs/pending-changes.md
@@ -8,7 +8,42 @@
 
 ## 待裁決
 
-（無）
+### P1｜host fn 二進位通道（解開「零件無法處理非文字檔」的框架級限制）— 2026-07-27
+
+**觸發**：leo 07-27 原話（arcrun-rag t73 收尾時）——
+> 「**解析各種檔案的零件還是要開發的，要記下來**，雖然跟現在無關，
+> 是因為**這次我用他本機來跑閃掉了**。」
+
+**現況＝框架級硬牆（2026-07-27 實測，非推論）**：
+Arcrun 的 host function 邊界是 **UTF-8 文字通道 ＋ 64 KB 上限**
+（`outBuf` 64KB／`res.text()`／host fn 內 `TextDecoder`）。後果：
+1. **零件拿不到二進位** ⇒ PDF/docx/圖片這類檔案，**做不出解析零件**。
+2. 雲端 workflow 的 `fetch_raw` 走同一顆 `http_request` ⇒ 同樣拿不到。
+3. 連純文字都受 64KB 限：15 頁 PDF 抽出約 40KB 尚可，**25 頁以上會爆**
+   ＝「轉好了卻進不去」的靜默失敗。
+
+**arcrun-rag 目前怎麼過關的（要講清楚，免得被誤會已解決）**：
+把轉檔搬到 **daemon 本機**（`collector/convert.go` 調度層＋PDFium-via-wazero）——
+**這是繞過（work around），不是修好**。leo 的原話「用他本機來跑閃掉了」講的就是這件事。
+
+**為什麼仍要做（不擋當前工作，但別遺忘）**：
+- **能力分裂**：現在只有「裝了 daemon 的人」有轉檔能力；**純雲端用戶永遠沒有**。
+- **地端/雲端兩版格式支援會分岔**，長期維護兩套。
+- 64KB 上限是**既有**限制，`.md` 今天就會撞到，PDF 只是讓它更快浮現。
+
+**變更範圍（提案，待 leo confirm 才動）**：
+① host fn 加二進位/base64 通道（或 ArrayBuffer 傳遞）
+② 放大或分塊化 `outBuf`（串流/分頁讀取，避免單次 64KB 天花板）
+③ 之上才談「各格式解析零件」
+
+**影響分析**：
+- **不受影響**：現行 active SDD `portal-auth` 的所有任務（不同層）。
+- **不擋**：arcrun-rag t73 本機轉檔層照做（已 commit `74d18ff`）。
+- **牽動**：`http_request` 零件、code 零件的 host fn 契約 ⇒ 屬**全人共用框架**改動，
+  影響所有既有零件，**必須 leo 拍板**（跨專案結構決策）。
+
+**現在不做的理由**：leo 明說「跟現在無關」＋客戶在等 daemon；本條僅**立案留底**，
+避免「本機能跑了」被後人誤讀成「這個限制已解決」。
 
 ## 已裁決
 
@@ -337,4 +372,52 @@ workflow/recipe/template 的實體在平台（CF/KBDB），不在 YAML——YAML
 3. 側載標記的呈現強度：只列表標記，或 console 加「無譜系 workflow」提醒區塊？
 4. P6 多源第一波範圍：只做「官方源＋直連一個外源」？org 私區（visibility=org）是否留第二波？
 
+---
 
+## [proposal] 兩個真缺口要進 SDD（2026-07-30，總管提，等 leo confirm）
+
+**來源**：頂層 CP `critical-paths/arcrun-usable.md`（leo confirm 開工）逐步查證後，
+發現兩件事**SDD 完全沒有**，而它們是「AI 不必寫 code」的前提。
+
+leo 的判準（2026-07-30）：
+> 「如果在這裡編任務，不就是廢掉了原本的 SDD，那到底要照 SDD 做事還是照 CP？」
+⇒ **照 SDD 做事、照 CP 排順序**。CP 不得自帶任務 ⇒ 這兩件必須進 SDD 才能做。
+
+### 缺口 ①：引擎缺條件邊（`ON_TRUE`／`ON_FALSE`）→ 建議進 `arcrun-core-mvp`
+
+- **實測**：`if_control` 的 output 是 `{result: boolean, branch: "true"|"false"}`，
+  但 `cypher-executor/src` 全域 grep `ON_TRUE|ON_FALSE` = **0**（圖的邊只有 `ON_SUCCESS`）
+- **後果**：AI 照規矩用 `if_control` 也只拿到布林值，**還是得寫 code 判斷該走哪裡**
+  ⇒ 這是「為什麼 workflow 全變成 code」的根（8 個 code 節點含 if×61）
+- **佐證**：`kbdb_upsert_block` 契約自述「解 arcrun workflow **缺 IF/branch 能力**的缺口
+  （arcrun.md P1 #1）」；Gitea **Arcrun#5**「if_control 無法真擋分支，filter+FOREACH 才是真閘」
+  於 **2026-07-04** 就發現，至今未修
+- **SDD 查證**：`grep "ON_TRUE|ON_FALSE|條件邊|分支"` 於全部 SDD → 7 命中**全是別義**
+  （「部署分支」「git 分支」），**條件邊本身完全沒設計過**
+- **影響面**：改圖 schema ＋ `graph-executor` 走邊邏輯＝引擎核心，風險最高
+  ⇒ 建議排在「查詢誠實」「節點替換」驗過之後
+
+### 缺口 ②：recipe 缺 payload 與回應處理層 → 建議進 `recipe-system`
+
+- **實測**：recipe schema 只有 `{canonical_id, endpoint, method, auth_service}`
+  （線上 `GET /recipes/telegram_send` 實查）
+- **後果**：`telegram_send` 的 description 明寫「body 帶 chat_id+text」但**schema 存不住 body**
+  ⇒ 任何要帶 body 的 API 都只能繞過 recipe、把 URL/header/body 整包寫進 workflow
+  ⇒ Gemini 就是這樣寫死的（`ask_llm` 三層全塌進節點）
+- **要補三層**
+  - `body_template`（payload）
+  - `response_map`（回應正規化：取值路徑／思考型模型旗標／淨化規則）
+    ——現在這段是 workflow 裡 2786 字元的 code（`finalize`）
+  - `auth` 加第四型 `binding`（免金鑰；一次打開 `env.AI`／`VECTORIZE`／`BROWSER`／`QUEUE`）
+- **SDD 查證**：`grep "body_template|response_map|payload"` → 17 命中**全是別的 payload**
+- **不做的話**：LLM 換源永遠要改 workflow（而非換 recipe），違反「LLM 可換源」原則
+
+### 誤標修正（誠實記錄）
+總管原本在 CP 標了 **5 個新缺口**，逐條查 SDD 後**只有上述 2 個是真的**：
+- `success_rate` 回寫 → **`arcrun-core-mvp/design.md:499` 早就設計**
+  （`success_rate = success_runs / total_runs * 100`、排序規則、UI 顯示），只是沒實作
+- 8 個壞範例、意圖節點替換 → 相關設計散在既有 SDD，已改為引用
+
+### ⏸ 等 leo confirm
+- confirm 後依 D35：兩份 SDD 目前皆 `paused`，要動需先處理單一活性
+  （現行 active＝`workflow-discovery`）