步驟5 缺口①：引擎通用具名分支邊（ON_TRUE/ON_FALSE/ON_BRANCH）＝Arcrun#5 根治

問題（「全變成 code」的根）：if_control 回 {result, branch} 卻沒有邊讀得懂它，
圖的邊只有 ON_SUCCESS/IF/FOREACH ⇒ 就算照規矩用零件，仍得寫 code 判斷走哪條。
leo 08-01 追問「你改了 if，有改 switch 嗎？switch 更嚴重」——確認 switch(N 路)
與 try_catch(try/catch) 同病，故一次做成通用機制，不留「為 switch 再改一次」的債。

設計：三顆流程控制零件的 output_schema 本來就都收斂到同一形狀 data.branch: string
（if_control→true/false；switch→case 名或 default_branch；try_catch→try/catch）
⇒ 引擎只需「依標籤選邊」一個機制 ON_BRANCH；ON_TRUE/ON_FALSE 是布林路的語法糖，
底層同一條路（測試已證等價）。讀不出分支＝不走（誠實，不亂挑一條）。

- types/schemas/constants：新增三邊型（純新增，既有列舉不動）＋ GraphEdge.branch
- graph-executor：readBranch() 依 data.branch → branch → data.result → result 四層相容
- 中文語意詞：成立時/為真時=ON_TRUE，不成立時/為假時/否則=ON_FALSE，BRANCH=ON_BRANCH

分支用法要「查得到」（leo 08-01：AI 可能像 n8n 那樣逐顆查、自己組圖）：
新增 lib/branch-hints.ts，讓 if_control/switch/try_catch 的查詢回應自帶 branch_hint
（branch_field/branches/edge_types/usage/example）——只看這一顆的回應就知道怎麼接下一步，
不必回頭讀 skill。四條回應路徑全wire：catalog found／legacy 逐顆／步驟4 substitution／
target=component 名字搜尋（＝n8n 式那條）。不分岔的零件不加此欄，避免噪音。

測試（先寫測試再改引擎，紅線要求）：tests/conditional-edges.test.ts 16 項全綠
——if 兩路／switch 多路＋default／try_catch 成功與失敗路／語法糖等價／
context 傳遞／同分支 fan-out／無匹配不走／混合邊時 PIPE 不受影響／schema 放行。
零變化保證：195 passed（前 179 +16 新），失敗數維持既有 9 筆未變（console/portal
HTML 資產未建置＋executor 斷言字串漂移，皆與本次無關）；tsc --noEmit 綠。
現存 workflow/example 用到新邊型＝0 筆（grep 實查）⇒ 既有行為不可能被改動。

SDD: workflow-discovery task 3.11｜CP: arcrun-usable 步驟 5

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

system-dev/docs/3-specs/workflow-discovery/tasks.md

@@ -114,6 +114,54 @@
 
 ---
 
+## 3.y 追加（2026-08-01，leo confirm 兩缺口進 SDD；服務 CP `arcrun-usable` 步驟 5）
+
+> **D35 處置（鐵律④ 判斷結果：不開新 SDD、不換 active、不搬移 paused 任務）**
+>
+> leo 2026-08-01 confirm 頂層 `pending-changes.md` 07-30 兩段（缺口①引擎條件邊／
+> 缺口② recipe payload 與回應處理層）。處置理由逐條：
+>
+> 1. **不開新 SDD**——鐵律②「CC 在任何情況下不得主動建新 SDD」。confirm 的是
+>    「規格層 proposal」，鐵律④只規定「**開新 SDD 時**」的搬移程序，並未要求每個
+>    confirm 都必開新 SDD。本案能落進現行 active 就不該增生第三本。
+> 2. **不把 active 交給 arcrun-core-mvp／recipe-system**——兩本 paused 的未完成任務
+>    （core-mvp 14 筆＝credential 注入／auth-worker／multi-tenant KV／analytics；
+>    recipe-system 10 筆＝prompt_recipe 的 MCP tool 與 mira wiki 端到端）
+>    **與本次兩缺口零交集**。升任一本為 active 就得先收掉 workflow-discovery（16 筆
+>    未完成、正在服務 CP 步驟 3/4），等於為了掛兩筆新任務把進行中的鏈打斷。
+> 3. **落在 workflow-discovery＝任務層變更（鐵律②第二類）**——CP `arcrun-usable`
+>    步驟 3→4→5 是**同一條有序鏈**，步驟 3（誠實查詢）、步驟 4（節點替換）的任務
+>    本來就掛在本 SDD 的 3.x；步驟 5 是同鏈的下一步，且**改的是同一顆 worker**
+>    （cypher-executor）。掛同一本＝與既有 3.6–3.10 同源，不是新方向。
+> 4. **兩本 paused 維持 paused、未完成任務原地不動**——沒有被取代、沒有被繼承，
+>    故不填 `superseded_by`、不移入 archive/。pending-changes 原提案標的
+>    （缺口①→arcrun-core-mvp、缺口②→recipe-system）僅為「議題歸屬」描述，
+>    非活性歸屬；實作歸屬依鐵律①走現行 active。
+>
+> **作廢任務清單：無**（本次不作廢任何既有任務）。
+> **搬移任務清單：無**（不換 active，故無跨 SDD 搬移；新增下列 3.11–3.13）。
+
+- [ ] 3.11 **缺口①：引擎條件邊**（＝Arcrun#5 根治；CP 步驟 5 交付物之一）
+      現況：`if_control` 只回 `{result, branch}`，`cypher-executor/src` grep
+      `ON_TRUE|ON_FALSE`＝0，圖的邊只有 `ON_SUCCESS`／`IF`／FOREACH ⇒ AI 照規矩用
+      `if_control` 也還是得寫 code 判斷該走哪條路 ⇒「全變成 code」的根。
+      要做：`EdgeType` 加 `ON_TRUE`／`ON_FALSE`＋`graph-executor` 走邊邏輯依上游
+      `branch` 選路。**引擎核心、風險最高：先寫測試再改**；既有 4 支官方 workflow
+      行為必須零變化（跑一次證明）。
+- [ ] 3.12 **缺口②：recipe payload 與回應處理層**（CP 步驟 5 交付物之二、之三）
+      現況 schema 只有 `{canonical_id, endpoint, method, auth_service, headers, body}`
+      ⇒ 帶 body 的 API 只能繞過 recipe 把整包寫進 workflow code；回應解析
+      （`finalize` 2786 字元）綁死 Gemini 格式。
+      要補三層：`body_template`（payload 模板＋變數插值）／`response_map`（回應正規化：
+      取值路徑・思考型模型旗標・淨化規則）／`auth` 第四型 `binding`（免金鑰，
+      一次打開 `env.AI`／`VECTORIZE`／`BROWSER`／`QUEUE`）。
+      **相容硬要求**：既有 recipe（無新欄位）行為完全不變。
+- [ ] 3.13 **驗收＝CP 步驟 5 考試（features/07）**：拿現行 `assemble` 節點
+      （5509 字元、if×23）用新能力重寫 → code 大幅下降且仍 `verdict=success`；
+      貼改寫前後字元數與實跑輸出。另附 haiku 場景：缺件時只寫 recipe 就補全、零 JS。
+
+---
+
 ## 跨任務鐵律提醒
 
 - 強制填 / 搜尋 / 回填全是**能力 → 落 API**；CLI/MCP 只暴露（rule 07）。