步驟5 缺口②：recipe 補 payload／回應正規化／binding 三層（leo 三層模型的第③層）

問題：舊 recipe schema 只有 {canonical_id, endpoint, method, auth_service}（body 有但淺）
⇒ ①帶 body 的 API 只能繞過 recipe 把整包寫進 workflow code
  ②回應解析綁死單一供應商（rag_chat 的 finalize 2786 字元全在對付 Gemini 形狀）
  ③Cloudflare binding（env.AI/VECTORIZE/BROWSER/QUEUE）整類被「只認 HTTP+金鑰」的抽象排除
⇒ 換 LLM 供應商＝改 workflow，而非換 recipe，違背「外部 API 只有一條一致的路」。

新增 lib/recipe-payload.ts（純函式，好測）：
- renderBodyTemplate：遞迴插值，單一 {{x}} 保留原型別、混合文字拼字串、
  支援 dot path、取不到保留原樣（不靜默吞掉，看得見才好 debug）。
  語義刻意與 graph-executor 的 interpolateData 一致，不新造第二種插值行為。
- applyResponseMap：text_path 取值／thinking_model 剔除 thought=true 取最後一個非 thought／
  answer_marker 用 lastIndexOf（自檢清單內文也會提到標記）／strip_prefixes 循環剝殼
  （實撞三型「Draft: 【答】」「* 【答】」「Answer: * 【答】」，單趟剝不乾淨）。

RecipeDefinition 加四個**全選填**欄位：body_template／response_map／auth／binding_name。
- component-loader：body_template 優先於 body，兩者皆無才沿用 ctx 當 body（既有行為）
- response_map 有設才附 text 欄，未設原樣回傳 ⇒ 既有 recipe 行為完全不變
- 新增 makeBindingRecipeRunner＋pickRecipeRunner：auth='binding' 走平台 binding（免金鑰、
  開機即可用），其餘一律走既有 HTTP 路徑。binding 缺綁定/無 run() 時回可操作錯誤，不假綠。
  這型不是為 Workers AI 開特例——一次打開 env.AI/VECTORIZE/BROWSER/QUEUE 整排。

payload 用法要「查得到」（同 branch_hint 動機，leo 08-01 的 n8n 式逐顆查）：
buildPayloadHint() 讓 recipe 的查詢回應說得出「payload 怎麼填、回應怎麼取值、
認證誰負責」，wire 進 discover 混搜／legacy 逐顆／target=recipe 三條路徑。
金鑰鐵律 D36：hint 只說「走 auth recipe X，金鑰由系統注入、你不必也不該填」，不吐值。

測試：tests/recipe-payload-response.test.ts 14 項全綠（含三家形狀 Gemini/Claude/Workers AI
用不同 path 都取得出文字＝換源＝換 recipe 的實證；未設 response_map 原樣回傳的相容性）。
全套 209 passed（前 179 +30 新），失敗數維持既有 9 筆未變；tsc --noEmit 綠。

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

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

cypher-executor/src/routes/recipes.ts

@@ -16,6 +16,7 @@
 import { Hono } from 'hono';
 import type { Bindings } from '../types';
 import { deriveRecipeHash } from '../lib/hash';
+import type { ResponseMap } from '../lib/recipe-payload';
 
 export const recipesRouter = new Hono<{ Bindings: Bindings }>();
 
@@ -34,6 +35,26 @@ export interface RecipeDefinition {
   method?: string;          // GET | POST | PUT | PATCH | DELETE，預設 POST
   headers?: Record<string, string>;
   body?: Record<string, unknown>;
+  /**
+   * ③ payload 層（SDD workflow-discovery 3.12）：帶 body 的 API 把 payload 收回 recipe，
+   * 不必寫進 workflow code。與 `body` 的差別＝支援巢狀 {{var}} 與 dot path、
+   * 單一引用保留原型別。兩者並存時 body_template 優先（新欄位贏，舊 recipe 不受影響）。
+   */
+  body_template?: Record<string, unknown>;
+  /**
+   * ③ 回應正規化層：各家 API 回應形狀不同（Gemini／Claude／Workers AI），
+   * 取值路徑・思考型模型旗標・淨化規則**隨 recipe 走** ⇒ 換源＝換 recipe，不必改 workflow。
+   * 未設＝原樣回傳（既有 recipe 行為零變化）。
+   */
+  response_map?: ResponseMap;
+  /**
+   * 認證型別。未設＝沿用既有 auth_service 判斷（向後相容）。
+   * `binding`＝**免金鑰**，用平台內建能力（env.AI／VECTORIZE／BROWSER／QUEUE），
+   * 不是為 Workers AI 開特例——Cloudflare 這一整類都被舊抽象（只認 HTTP+金鑰）排除在外。
+   */
+  auth?: 'static_key' | 'service_account' | 'oauth2' | 'binding';
+  /** auth='binding' 時指定用哪個 binding（例 'AI'／'VECTORIZE'）。 */
+  binding_name?: string;
   /**
    * 此 recipe 要用哪個 auth recipe（auth_recipe:{auth_service}）。
    * 讓多個 recipe 共用同一把 auth（例：kbdb_get / kbdb_create_block 都設 "kbdb"）。
@@ -116,6 +137,11 @@ recipesRouter.post('/recipes', async (c) => {
     method: (body.method ?? 'POST').toUpperCase(),
     headers: body.headers,
     body: body.body,
+    // ③ payload/回應/binding 三層（3.12）：全選填，沒給就是 undefined＝既有行為
+    body_template: body.body_template,
+    response_map: body.response_map,
+    auth: body.auth,
+    binding_name: body.binding_name,
     auth_service: body.auth_service,
     credentials_required: body.credentials_required,
     created_at: existing?.created_at ?? now,