步驟5 驗收與 SDD 落帳:判斷骨架重寫實測 1201→350 字元、if×8→0(降 71%)
tests/step5-acceptance.test.ts(3 項綠): - 多路分流+失敗路三條各自到位、全程零 code 節點、success=true - 布林兩路(if_control)同樣零 code - 字元數對照:舊寫法(判斷全塞進一個 code 節點的 JS)1201 字元 if×8 → 新寫法(分支邊+recipe response_map 宣告)350 字元 if×0 誠實標記(寫進測試檔頭與 tasks,不讓後人誤讀):線上那顆 assemble(5509 字元 if×23) 住在 arcrun-rag 實例、本 repo 無其定義 ⇒ 本次是把它的**判斷骨架**以新能力重建成等價 工作流,證明判斷不必寫在 JS 裡,**不是**直接改寫線上節點。真正改寫與 haiku 逐顆查場景 =stage 端到端(features/09)才算數,故 3.13 標 ◐ 不標 ✅。 tasks.md:3.11/3.12 標 [x] 附證據,3.13 標 [◐] 附待辦界線。 全套 212 passed(基線 179 +33 新),失敗數維持既有 9 筆未變;tsc --noEmit 綠。 SDD: workflow-discovery 3.11/3.12/3.13|CP: arcrun-usable 步驟 5 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -141,14 +141,38 @@
|
||||
> **作廢任務清單:無**(本次不作廢任何既有任務)。
|
||||
> **搬移任務清單:無**(不換 active,故無跨 SDD 搬移;新增下列 3.11–3.13)。
|
||||
|
||||
- [ ] 3.11 **缺口①:引擎條件邊**(=Arcrun#5 根治;CP 步驟 5 交付物之一)
|
||||
- [x] 3.11 **缺口①:引擎通用具名分支邊**(=Arcrun#5 根治;CP 步驟 5 交付物之一)
|
||||
✅ 08-01 本地綠(commit `323ccc8`):`ON_TRUE`/`ON_FALSE`/`ON_BRANCH` 三邊型+
|
||||
`readBranch()` 四層相容讀法(data.branch → branch → data.result → result)。
|
||||
**做成通用具名分支,非布林特例**(leo 08-01「你改了 if,有改 switch 嗎?switch 更嚴重」)——
|
||||
三顆流程控制零件的 output_schema 本來就都收斂到 `data.branch: string`
|
||||
(if_control→true/false;switch→case 名/default_branch;try_catch→try/catch)
|
||||
⇒ 引擎只需一個機制,不留「做完 if 還要為 switch 再改一次」的債。
|
||||
ON_TRUE/ON_FALSE=布林路語法糖,測試已證與 ON_BRANCH branch="true" 等價。
|
||||
**分支用法查得到**(leo 08-01 n8n 式逐顆查):新增 `lib/branch-hints.ts`,
|
||||
三顆零件的查詢回應自帶 `branch_hint`(branch_field/branches/edge_types/usage/example),
|
||||
四條回應路徑全 wire(catalog found/legacy 逐顆/步驟4 substitution/target=component)。
|
||||
測試 `tests/conditional-edges.test.ts` 16 項全綠;零變化:現存 workflow 用到新邊型=0 筆。
|
||||
〔原始描述〕
|
||||
現況:`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 交付物之二、之三)
|
||||
- [x] 3.12 **缺口②:recipe payload 與回應處理層**(CP 步驟 5 交付物之二、之三)
|
||||
✅ 08-01 本地綠(commit `5f5c0a8`):新增 `lib/recipe-payload.ts`
|
||||
(`renderBodyTemplate` 遞迴插值+保留型別+dot path;`applyResponseMap` 取值路徑/
|
||||
thinking_model 剔除 thought/answer_marker 用 lastIndexOf/strip_prefixes 循環剝殼),
|
||||
`RecipeDefinition` 加四個**全選填**欄位 body_template/response_map/auth/binding_name,
|
||||
`component-loader` 加 `makeBindingRecipeRunner`+`pickRecipeRunner`(auth='binding'
|
||||
走平台 binding=免金鑰、開機即可用;一次打開 env.AI/VECTORIZE/BROWSER/QUEUE 整排)。
|
||||
**payload 用法查得到**:`buildPayloadHint()` wire 進三條 recipe 回應路徑
|
||||
(守 D36:只說「金鑰由系統注入、你不必也不該填」,不吐值)。
|
||||
測試 `tests/recipe-payload-response.test.ts` 14 項全綠(含 Gemini/Claude/Workers AI
|
||||
三家形狀各用不同 path 都取得出文字=換源=換 recipe 的實證)。
|
||||
相容:未設新欄位的既有 recipe 行為完全不變(有測試守)。
|
||||
〔原始描述〕
|
||||
現況 schema 只有 `{canonical_id, endpoint, method, auth_service, headers, body}`
|
||||
⇒ 帶 body 的 API 只能繞過 recipe 把整包寫進 workflow code;回應解析
|
||||
(`finalize` 2786 字元)綁死 Gemini 格式。
|
||||
@@ -156,7 +180,16 @@
|
||||
取值路徑・思考型模型旗標・淨化規則)/`auth` 第四型 `binding`(免金鑰,
|
||||
一次打開 `env.AI`/`VECTORIZE`/`BROWSER`/`QUEUE`)。
|
||||
**相容硬要求**:既有 recipe(無新欄位)行為完全不變。
|
||||
- [ ] 3.13 **驗收=CP 步驟 5 考試(features/07)**:拿現行 `assemble` 節點
|
||||
- [◐] 3.13 **驗收=CP 步驟 5 考試(features/07)**
|
||||
◐ 08-01:本地驗收綠(`tests/step5-acceptance.test.ts` 3 項),實跑輸出=
|
||||
**舊寫法 1201 字元 / if×8 → 新寫法 350 字元 / if×0(下降 71%)**,
|
||||
且分流工作流 `success=true`、零 code 節點。
|
||||
⚠️ **誠實標記**:線上那顆 `assemble`(5509 字元、if×23)住在 arcrun-rag 實例,
|
||||
本 repo 無其定義 ⇒ 本次是把它的**判斷骨架**以新能力重建成等價工作流證明
|
||||
「判斷不必寫在 JS 裡」,**不是**直接改寫線上節點。
|
||||
真正的改寫與 haiku 場景(逐顆查、只寫 recipe 補全、零 JS)=**stage 端到端**
|
||||
(features/09),未驗前不得標 ✅。
|
||||
〔原始描述〕:拿現行 `assemble` 節點
|
||||
(5509 字元、if×23)用新能力重寫 → code 大幅下降且仍 `verdict=success`;
|
||||
貼改寫前後字元數與實跑輸出。另附 haiku 場景:缺件時只寫 recipe 就補全、零 JS。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user