Leo/Arcrun
1
0
Fork 0
Code Issues 49 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
Files
062757f1b15fb6181e61633ea41c3a2c01edcbbd
Arcrun/system-dev/docs/3-specs/workflow-discovery/tasks.md
T
uncle6me-web 1794072179 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>
2026-07-31 11:56:15 +08:00

8.0 KiB
Raw Blame History

workflow-discovery — Tasks

狀態：方向待確認，尚未實作（全部 [ ]）。確認後才動 code。 對應 design.md。tasks.md 是唯一進度來源，每完成一個立刻標 [x]，不批次。 建立：2026-06-27（issue #8）

Phase 0：方向確認（前置，擋住所有實作）

  • 0.1 SDD 三件式回報到 issue #8 comment，列關鍵決策（方案 C 雙寫 / YAML description 為準 / 提示式回填）
  • 0.2 等總管/richblack 點頭；拍板 design §9 的 4 個待決點 — leo 2026-06-27 全拍定，Q2 翻案（CC 據實生成 vs 介面層不生成）已吸收進 design §3.2
  • 0.3 實作前核實 /entries/search 是否支援 entry_type filter — 總管查證：不支援（只有 q/owner_id/source/mode），schema 有欄位+索引，要改 4 處（route/searchEntries/semanticSearch/kbdb-proxy），做 base 通用 filter

Phase 1：強制 description（R1，Q2 定案：CC 據實生成、用戶可改）

  • 1.1 cypher POST /webhooks/named：description 改必填，trim 後空 → 400 + 可操作錯誤訊息（定位：要求操盤 CC 據實寫一句「能做什麼」，非逼用戶手填、非介面層機械塞）— webhooks-named.ts 加驗證，tsc 綠
  • [⏸] 1.2/1.3 MCP deploy 改走 /webhooks/named（方向①，leo 拍定）— 卡在 ①-a/b/c 子決策（design §3.1b/c）：實作期發現 /webhooks/named 吃 graph 非 YAML，YAML→graph 編排現在寫在 CLI push.ts 介面層；MCP 複製＝違 rule 07。等總管定 ①-a（複製）/①-b（編排下沉新 /workflows/deploy 吃 YAML，CLI 也改用）/①-c（先 a 通、b 另開 issue）。注：無論哪個，MCP 最終打 /webhooks/named（已強制 description，1.1 完成）→ description 強制目標三選項都達成。
  • 1.3b（方向①前置，三選項共需）GET /webhooks/named 補回 description/created_at/cron_expr 欄位，讓 MCP list 改讀本端點時欄位齊 — webhooks-named.ts，tsc 綠
  • 1.4 驗證：兩條路徑各跑一次「無 description 部署」→ 都被擋（端到端，非只 tsc）— CLI 路徑已可驗，MCP 待 ①-a/b/c 收

Phase 2：可搜 entry 雙寫（R2 資料層）

  • 2.1 cypher 部署 handler：record 寫完後雙寫一個 entry_type=workflow entry（content=description、metadata_json.embed:true、owner_id=apiKey），waitUntil 非阻塞 — webhooks-named.ts 加 writeWorkflowSearchEntry helper（注意：KBDB 用 metadata_json 字串非 metadata 物件）。tsc 綠
  • 2.2 補 KBDB /entries/search 的 entry_type filter（base 通用，不寫死 workflow）— 改 4 處：searchEntries(entry-crud.ts) + semanticSearch(embed.ts，entry_type 已 index) + route(entries.ts) + cypher kbdb-proxy /kbdb/search 透傳。kbdb+cypher tsc 綠
  • 2.3 驗證：部署一個帶 description 的 workflow → KBDB 查得到對應 entry（owner_id 正確）

Phase 3：search_workflow 工具（R2 介面層）

  • 3.1 cypher 新增 GET /workflows/search?q=&mode=：轉發 KBDB /entries/search（限 entry_type=workflow + 本租戶 owner_id，預設 mode=semantic 自動降級）— webhooks-named.ts。tsc 綠
  • 3.2 MCP 新增 u6u_search_workflows(query)：呼叫 3.1，格式化結果，透傳 capability_hint（AI 看到可主動問用戶開 Vectorize）— 新檔 + registry 註冊。tsc 綠
  • 3.3 驗證 mode=keyword（Vectorize 未開）：LIKE 命中 + 回 capability_hint「叫 CC 幫你開語義查詢」
  • 3.4 驗證 mode=semantic（Vectorize 開，需 self-hosted leo21c）：語意命中，限本租戶
  • 3.5 租戶隔離驗證：A 租戶搜不到 B 租戶的 workflow（count=0）

Phase 4：既有工作流回填（R3）

  • 4.1 cypher POST /workflows/backfill-search-entries（限本租戶）：有 description 的 record → 補寫 entry；無 description 的 → 列出回報，不自動編造 — webhooks-named.ts，tsc 綠
  • 4.2 backfill 經 CLI/MCP 暴露為主動指令（非 cron，守 C2）
  • 4.3 驗證：對既有 workflow 跑 backfill → 有 desc 的可搜、無 desc 的被正確列出待補

Phase 5：薄殼對稱補（R2.5，次階段，可獨立驗收）

  • 5.1 CLI acr workflow search <query>：對等 MCP 工具（同一 cypher 端點）
  • 5.2 驗證：CLI/MCP 同 query 回同一組結果（底層同端點，差異只來自介面慣例）

Phase 6：收尾

  • 6.1 tsc 全綠（cypher / mcp / cli / kbdb 受影響者）
  • 6.2 部署 + 端到端實證（leo21c 帳號跑強制填 + 搜尋 + 回填，收客觀證據非自報）
  • 6.3 issue #8 comment 回報端到端綠燈證據；由實證決定結案時機（待端到端綠才 close）
  • 6.4 同步更新 design.md（若實作中發現偏差）+ wiki status

3.x 追加（2026-07-31，頂層總管交棒；出處＝leo 定義步驟 3 考題）

leo：「你要找的 Google Slides API 我沒有，你可以自己做。有 2 種： 一種是要一個零件（如 Crypto）但沒有→用 PR 產生； 另一種是要一個 recipe（如 Google Slides）但沒有→自己寫 recipe。」 機械考題已在頂層 arcrun-usable/verify.sh 03 組（aes_encrypt／google_slides_create 兩題， 現對實例跑全紅＝正確標記）。行為綠過才准佔用 arm 部署（頂層 mistakes 07-31 條）。

  • 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 ✓
  • 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） — 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 全綠（部署後要對真實例重驗）
  • 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 真考（只讀回覆就能說出缺什麼、該做什麼）。

跨任務鐵律提醒

  • 強制填 / 搜尋 / 回填全是能力 → 落 API；CLI/MCP 只暴露（rule 07）。
  • 不假綠：未開 Vectorize 就老實降級 + hint，不假裝語義（mindset §7）。
  • 不自動編造 description：強制是逼真的描述，自動填 = 假裝有（誠實）。
  • flag 紅線：search/backfill 都是主動 pull，無 cron/輪詢/fan-out（C2）。
  • 框架級改動 → 端到端實證（leo21c）才算完成，不是 tsc 綠就宣布。
Reference in New Issue View Git Blame Copy Permalink