合流 batch：步驟 3/4/5/6 併成一版出貨（同一顆 cypher worker，bundle 是 worker 粒度）
鐵律（08-01 血淚）：CP 可分步驗收，但 bundle 是 worker 粒度——凡改同一顆 worker 的多步， 出貨前必先合流成一版再重生 bundle，否則 stage 只拿到一步（三條分支各自建 bundle 的坑）。 base=feat/step3-missing-guidance（最前緣，已含 step4+step6＋t158-t162 prod 修） merge=feat/step5-conditional-edges（引擎條件邊＋recipe 三層＋教材世代修）
This commit is contained in:
uncle6me-web
@@ -132,6 +132,87 @@
|
||||
|
||||
---
|
||||
|
||||
## 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）。
|
||||
|
||||
- [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
|
||||
行為必須零變化（跑一次證明）。
|
||||
- [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 格式。
|
||||
要補三層：`body_template`（payload 模板＋變數插值）／`response_map`（回應正規化：
|
||||
取值路徑・思考型模型旗標・淨化規則）／`auth` 第四型 `binding`（免金鑰，
|
||||
一次打開 `env.AI`／`VECTORIZE`／`BROWSER`／`QUEUE`）。
|
||||
**相容硬要求**：既有 recipe（無新欄位）行為完全不變。
|
||||
- [◐] 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。
|
||||
|
||||
---
|
||||
|
||||
## 跨任務鐵律提醒
|
||||
|
||||
- 強制填 / 搜尋 / 回填全是**能力 → 落 API**；CLI/MCP 只暴露（rule 07）。
|
||||
|
||||
Reference in New Issue
Block a user