5d00e71275
頂層 D22 決策(leo 2026-07-03 拍板):推什麼由開發環境歸屬決定, Gitea private=除機敏值/build 產物/.github 外全 push。 解 T1.5 卡點:雲端工人 clone 拿得到 credential-store-migration.md,可就地改寫 SDD。 機敏掃描兩輪通過(新增 189 檔約 2.1MB,node_modules/dist/wasm 照舊排除)。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
65 lines
5.2 KiB
Markdown
65 lines
5.2 KiB
Markdown
# workflow-discovery — Tasks
|
||
|
||
> **狀態**:方向待確認,**尚未實作**(全部 `[ ]`)。確認後才動 code。
|
||
> 對應 `design.md`。**tasks.md 是唯一進度來源**,每完成一個立刻標 `[x]`,不批次。
|
||
> 建立:2026-06-27(issue #8)
|
||
|
||
---
|
||
|
||
## Phase 0:方向確認(前置,擋住所有實作)
|
||
|
||
- [x] 0.1 SDD 三件式回報到 issue #8 comment,列關鍵決策(方案 C 雙寫 / YAML description 為準 / 提示式回填)
|
||
- [x] 0.2 等總管/richblack 點頭;拍板 design §9 的 4 個待決點 — **leo 2026-06-27 全拍定,Q2 翻案(CC 據實生成 vs 介面層不生成)已吸收進 design §3.2**
|
||
- [x] 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 據實生成、用戶可改)
|
||
|
||
- [x] 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 強制目標三選項都達成。
|
||
- [x] 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 資料層)
|
||
|
||
- [x] 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 綠
|
||
- [x] 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 介面層)
|
||
|
||
- [x] 3.1 cypher 新增 `GET /workflows/search?q=&mode=`:轉發 KBDB `/entries/search`(限 entry_type=workflow + 本租戶 owner_id,預設 mode=semantic 自動降級)— webhooks-named.ts。tsc 綠
|
||
- [x] 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)
|
||
|
||
- [x] 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
|
||
|
||
---
|
||
|
||
## 跨任務鐵律提醒
|
||
|
||
- 強制填 / 搜尋 / 回填全是**能力 → 落 API**;CLI/MCP 只暴露(rule 07)。
|
||
- **不假綠**:未開 Vectorize 就老實降級 + hint,不假裝語義(mindset §7)。
|
||
- **不自動編造 description**:強制是逼真的描述,自動填 = 假裝有(誠實)。
|
||
- **flag 紅線**:search/backfill 都是主動 pull,無 cron/輪詢/fan-out(C2)。
|
||
- 框架級改動 → 端到端實證(leo21c)才算完成,不是 tsc 綠就宣布。
|