pending-changes：兩個真缺口提案（引擎條件邊／recipe payload+response+binding）
來源＝頂層 CP arcrun-usable 逐步查證。依 leo「照 SDD 做事、照 CP 排順序」，
CP 不得自帶任務 ⇒ 這兩件必須進 SDD 才能做，先走 pending-changes 等 confirm（D35）。
缺口①引擎條件邊：if_control 回 {result,branch} 但 cypher-executor grep ON_TRUE|ON_FALSE=0
⇒ 用了零件仍得寫 code 判斷＝「全變成 code」的根。Arcrun#5 於 07-04 發現至今未修。
SDD 查證：7 個字面命中全是「部署分支」等別義，條件邊本身完全沒設計過。
缺口②recipe 缺 payload/response 層：schema 只有 {canonical_id,endpoint,method,auth_service}
⇒ telegram_send 自述「body 帶 chat_id+text」但存不住 body ⇒ 只能繞過 recipe 寫進 workflow。
要補 body_template／response_map／auth:binding 三層。SDD 查證 17 命中全是別的 payload。
This commit is contained in:
@@ -8,7 +8,42 @@
|
||||
|
||||
## 待裁決
|
||||
|
||||
（無）
|
||||
### P1｜host fn 二進位通道（解開「零件無法處理非文字檔」的框架級限制）— 2026-07-27
|
||||
|
||||
**觸發**：leo 07-27 原話（arcrun-rag t73 收尾時）——
|
||||
> 「**解析各種檔案的零件還是要開發的，要記下來**，雖然跟現在無關，
|
||||
> 是因為**這次我用他本機來跑閃掉了**。」
|
||||
|
||||
**現況＝框架級硬牆（2026-07-27 實測，非推論）**：
|
||||
Arcrun 的 host function 邊界是 **UTF-8 文字通道 ＋ 64 KB 上限**
|
||||
（`outBuf` 64KB／`res.text()`／host fn 內 `TextDecoder`）。後果：
|
||||
1. **零件拿不到二進位** ⇒ PDF/docx/圖片這類檔案，**做不出解析零件**。
|
||||
2. 雲端 workflow 的 `fetch_raw` 走同一顆 `http_request` ⇒ 同樣拿不到。
|
||||
3. 連純文字都受 64KB 限：15 頁 PDF 抽出約 40KB 尚可，**25 頁以上會爆**
|
||||
＝「轉好了卻進不去」的靜默失敗。
|
||||
|
||||
**arcrun-rag 目前怎麼過關的（要講清楚，免得被誤會已解決）**：
|
||||
把轉檔搬到 **daemon 本機**（`collector/convert.go` 調度層＋PDFium-via-wazero）——
|
||||
**這是繞過（work around），不是修好**。leo 的原話「用他本機來跑閃掉了」講的就是這件事。
|
||||
|
||||
**為什麼仍要做（不擋當前工作，但別遺忘）**：
|
||||
- **能力分裂**：現在只有「裝了 daemon 的人」有轉檔能力；**純雲端用戶永遠沒有**。
|
||||
- **地端/雲端兩版格式支援會分岔**，長期維護兩套。
|
||||
- 64KB 上限是**既有**限制，`.md` 今天就會撞到，PDF 只是讓它更快浮現。
|
||||
|
||||
**變更範圍（提案，待 leo confirm 才動）**：
|
||||
① host fn 加二進位/base64 通道（或 ArrayBuffer 傳遞）
|
||||
② 放大或分塊化 `outBuf`（串流/分頁讀取，避免單次 64KB 天花板）
|
||||
③ 之上才談「各格式解析零件」
|
||||
|
||||
**影響分析**：
|
||||
- **不受影響**：現行 active SDD `portal-auth` 的所有任務（不同層）。
|
||||
- **不擋**：arcrun-rag t73 本機轉檔層照做（已 commit `74d18ff`）。
|
||||
- **牽動**：`http_request` 零件、code 零件的 host fn 契約 ⇒ 屬**全人共用框架**改動，
|
||||
影響所有既有零件，**必須 leo 拍板**（跨專案結構決策）。
|
||||
|
||||
**現在不做的理由**：leo 明說「跟現在無關」＋客戶在等 daemon；本條僅**立案留底**，
|
||||
避免「本機能跑了」被後人誤讀成「這個限制已解決」。
|
||||
|
||||
## 已裁決
|
||||
|
||||
@@ -337,4 +372,52 @@ workflow/recipe/template 的實體在平台（CF/KBDB），不在 YAML——YAML
|
||||
3. 側載標記的呈現強度：只列表標記，或 console 加「無譜系 workflow」提醒區塊？
|
||||
4. P6 多源第一波範圍：只做「官方源＋直連一個外源」？org 私區（visibility=org）是否留第二波？
|
||||
|
||||
---
|
||||
|
||||
## [proposal] 兩個真缺口要進 SDD（2026-07-30，總管提，等 leo confirm）
|
||||
|
||||
**來源**：頂層 CP `critical-paths/arcrun-usable.md`（leo confirm 開工）逐步查證後，
|
||||
發現兩件事**SDD 完全沒有**，而它們是「AI 不必寫 code」的前提。
|
||||
|
||||
leo 的判準（2026-07-30）：
|
||||
> 「如果在這裡編任務，不就是廢掉了原本的 SDD，那到底要照 SDD 做事還是照 CP？」
|
||||
⇒ **照 SDD 做事、照 CP 排順序**。CP 不得自帶任務 ⇒ 這兩件必須進 SDD 才能做。
|
||||
|
||||
### 缺口 ①：引擎缺條件邊（`ON_TRUE`／`ON_FALSE`）→ 建議進 `arcrun-core-mvp`
|
||||
|
||||
- **實測**：`if_control` 的 output 是 `{result: boolean, branch: "true"|"false"}`，
|
||||
但 `cypher-executor/src` 全域 grep `ON_TRUE|ON_FALSE` = **0**（圖的邊只有 `ON_SUCCESS`）
|
||||
- **後果**：AI 照規矩用 `if_control` 也只拿到布林值，**還是得寫 code 判斷該走哪裡**
|
||||
⇒ 這是「為什麼 workflow 全變成 code」的根（8 個 code 節點含 if×61）
|
||||
- **佐證**：`kbdb_upsert_block` 契約自述「解 arcrun workflow **缺 IF/branch 能力**的缺口
|
||||
（arcrun.md P1 #1）」；Gitea **Arcrun#5**「if_control 無法真擋分支，filter+FOREACH 才是真閘」
|
||||
於 **2026-07-04** 就發現，至今未修
|
||||
- **SDD 查證**：`grep "ON_TRUE|ON_FALSE|條件邊|分支"` 於全部 SDD → 7 命中**全是別義**
|
||||
（「部署分支」「git 分支」），**條件邊本身完全沒設計過**
|
||||
- **影響面**：改圖 schema ＋ `graph-executor` 走邊邏輯＝引擎核心，風險最高
|
||||
⇒ 建議排在「查詢誠實」「節點替換」驗過之後
|
||||
|
||||
### 缺口 ②：recipe 缺 payload 與回應處理層 → 建議進 `recipe-system`
|
||||
|
||||
- **實測**：recipe schema 只有 `{canonical_id, endpoint, method, auth_service}`
|
||||
（線上 `GET /recipes/telegram_send` 實查）
|
||||
- **後果**：`telegram_send` 的 description 明寫「body 帶 chat_id+text」但**schema 存不住 body**
|
||||
⇒ 任何要帶 body 的 API 都只能繞過 recipe、把 URL/header/body 整包寫進 workflow
|
||||
⇒ Gemini 就是這樣寫死的（`ask_llm` 三層全塌進節點）
|
||||
- **要補三層**
|
||||
- `body_template`（payload）
|
||||
- `response_map`（回應正規化：取值路徑／思考型模型旗標／淨化規則）
|
||||
——現在這段是 workflow 裡 2786 字元的 code（`finalize`）
|
||||
- `auth` 加第四型 `binding`（免金鑰；一次打開 `env.AI`／`VECTORIZE`／`BROWSER`／`QUEUE`）
|
||||
- **SDD 查證**：`grep "body_template|response_map|payload"` → 17 命中**全是別的 payload**
|
||||
- **不做的話**：LLM 換源永遠要改 workflow（而非換 recipe），違反「LLM 可換源」原則
|
||||
|
||||
### 誤標修正（誠實記錄）
|
||||
總管原本在 CP 標了 **5 個新缺口**，逐條查 SDD 後**只有上述 2 個是真的**：
|
||||
- `success_rate` 回寫 → **`arcrun-core-mvp/design.md:499` 早就設計**
|
||||
（`success_rate = success_runs / total_runs * 100`、排序規則、UI 顯示），只是沒實作
|
||||
- 8 個壞範例、意圖節點替換 → 相關設計散在既有 SDD，已改為引用
|
||||
|
||||
### ⏸ 等 leo confirm
|
||||
- confirm 後依 D35：兩份 SDD 目前皆 `paused`，要動需先處理單一活性
|
||||
（現行 active＝`workflow-discovery`）
|
||||
|
||||
Reference in New Issue
Block a user