3.6/3.7 查詢誠實化：兩庫都查、缺件回 not_found＋分型指路 suggestion

📋 SDD：workflow-discovery task 3.6/3.7（leo 07-31 步驟 3 考題）
契約以頂層 arcrun-usable/verify.sh 01＋03 組為準。

- 3.6 recipe 納入 /cypher/search：零件 registry 落空後查 RECIPES KV
  （resolveRecipe，執行鏈同一套解析）；recipe found 附 source/description/endpoint
- 3.7 缺件分型指路：status 契約定 not_found（verify grep），suggestion 欄——
  名字含服務詞（google/telegram/…）＝外部 API 樣貌 → 指 skill write_recipe；
  含計算詞（encrypt/hash/…）＝計算原語樣貌 → 指 skill add_new_wasm_component 投稿 PR；
  判不出型誠實說判不出、兩條路都給。規則簡單可解釋（不接 LLM），判準在 code 註解
- 相近候選：not_found 附 similar_components/similar_recipes——全名搜不中就斷詞
  （ASCII 詞＋中日韓 2-gram）打 registry /components/search，
  「判斷有沒有新資料」媒合到 if_control（leo：AI 不用知道零件存在）
- 修頭節點假 found：resolveNodeRole 把無入邊頭節點判 Input，searchNodes 對 Input
  無條件 found ⇒ 「aes_encrypt >> … >> code」的頭被掩蓋。改為只有字面
  input/trigger/…/output 名才短路（isVirtualIoName），真名字照查兩庫
- registry 查詢層補 input_schema/output_schema 透傳：KV 一直有存
  （indexOnlyComponent），toComponentRecord 丟掉 ⇒ /cypher/search 給不出
  「怎麼填 payload」。順手補 REGISTRY_BASE_URL 可選覆蓋（比照 KBDB_GRAPH_URL 慣例，
  本地 dev／self-hosted registry 掛別處時用）

驗：cypher-executor＋registry tsc 全綠；vitest 9 failed/179 passed＝與 5cadc60
基線完全相同（既有債非本次造成）；本地 wrangler dev（cypher 指本地 registry，
KV 用 index-only 種入 20 份 repo 合約）跑頂層 verify.sh 01＋03 組 9/9 全綠，
含 telegram_send 種入後 recipe found 路徑實測。部署到實例後需對真環境重驗。

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

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

@@ -61,13 +61,24 @@
 > 機械考題已在頂層 `arcrun-usable/verify.sh` 03 組（aes_encrypt／google_slides_create 兩題，
 > 現對實例跑全紅＝正確標記）。**行為綠過才准佔用 arm 部署**（頂層 mistakes 07-31 條）。
 
-- [ ] 3.6 recipe 納入 `/cypher/search` 存在性查詢（現只查零件 registry ⇒ 說不出「某 recipe 沒有」）
-- [ ] 3.7 缺件回應分型指路：`suggestion` 欄——計算原語型→「投稿零件 PR」；外部 API 型→「自己寫 recipe」
+- [x] 3.6 recipe 納入 `/cypher/search` 存在性查詢（現只查零件 registry ⇒ 說不出「某 recipe 沒有」）
+      — 2026-07-31 search-nodes.ts：registry 落空後查 RECIPES KV（resolveRecipe），
+      recipe found 附 source:'recipe'+description+endpoint；本地實測 telegram_send found ✓
+- [x] 3.7 缺件回應分型指路：`suggestion` 欄——計算原語型→「投稿零件 PR」；外部 API 型→「自己寫 recipe」
       （欄位契約定案時同步頂層 verify.sh 03 組的 grep）
       **且每筆要帶「去哪裡看」**（leo 07-31 三次定調）：component 路→skill `add_new_wasm_component`
       （已存在、安裝器現會 seed 進新實例）；recipe 路→skill `write_recipe`（**不存在，見 3.8**）
-- [ ] 3.8 寫 `write_recipe` skill（registry/skills/）——「怎麼寫 recipe」的 playbook 目前是空地，
+      — 2026-07-31 完成：status 契約定 `not_found`（同 verify.sh 01/03 grep）；分型＝服務詞/計算詞
+      簡單規則（不接 LLM，規則在 code 註解）；附 similar_components/similar_recipes 相近候選
+      （自然語言「判斷有沒有新資料」媒合到 if_control）。順手修二病灶：①頭節點被 resolveNodeRole
+      判 Input 而免查（`aes_encrypt >> … >> code` 假 found）→ 只有字面 input/output 名才短路；
+      ② registry 查詢層把 KV 裡的 input_schema 丟掉 → 補透傳。本地 wrangler dev 跑頂層
+      verify.sh 01＋03 組 9/9 全綠（部署後要對真實例重驗）
+- [x] 3.8 寫 `write_recipe` skill（registry/skills/）——「怎麼寫 recipe」的 playbook 目前是空地，
       3.7 的 recipe 指路沒有目的地；寫完納入安裝器 seed 清單（compile-skills.mjs 自動收）
+      — 2026-07-31 完成：內容從真 code 反推（RecipeDefinition schema／api-recipe-seeds 的
+      telegram_send+gmail_send 真範例／auth-recipes 必填欄位／acr recipe push 打通檢查），
+      比照 write_intent_workflow 風格；INDEX.md＋write_intent_workflow.md 同步指路 not_found
 - 設計基調（leo 07-31 二次定調）：**回覆的重點是「缺哪些」不是「有哪些」**——
   有的照常編圖不必報告；缺的要兩庫（零件＋recipe）都搜過後點名＋給正確指示。
   驗收兩層：機械（verify 01/03）綠 → haiku 真考（只讀回覆就能說出缺什麼、該做什麼）。