Leo/Arcrun
1
0
Fork 0
Code Issues 49 Pull Requests 5 Actions Packages Projects Releases Wiki Activity
265 Commits 27 Branches 0 Tags
a7d54751fb6be9491dc75794fa04b5c7b2605e35
Commit Graph

265 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
uncle6me-web a7d54751fb merge main：把 t176（拔雲端 LLM 下發）與 workers_ai_chat 種子併進 CIS 分支 
出貨前發現兩條分支各有一半：
  main                  → t176 拔掉雲端下發 extractor／刪 admin/extractor／workers_ai_chat 種子
  fix/cis-round3-portal → t181 新萃取端點 /portal/daemon/extract、CIS 視覺
**要合起來才是完整的出貨內容**（實測：合併前 bundle 仍含 admin/extractor ×2）。

原始碼三檔全自動合併；只有 portal-admin.test.ts 衝突——
HEAD 側是**過時的 t131/t122 測試**（測 main 已刪的端點，留著必紅），
main 側是刪除。解法：接受刪除、保留我這側的 t181 守衛。

測試 31 passed，唯一 failed 是基準線既有的 GET /portal 靜態資源案。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 15:33:43 +08:00
uncle6me-web 6fa68c73d5 移除誤入版控的 cypher-executor/node_modules 自指 symlink 
.gitignore 第 1 行本來就有 node_modules/，但 139d4c5 把它 commit 進去了，
且內容是**指向自己的 symlink**（node_modules -> .../cypher-executor/node_modules）。

害處（今天實撞兩次）：任何人 checkout 或 rm -rf node_modules/<子目錄> 後，
pnpm install 會炸 ELOOP: too many symbolic links，
且 vitest 起不來（exit 194、零輸出，看不出原因）。
解法是 rm node_modules 再 pnpm install——但下次 checkout 又會回來。

⇒ 從版控移除，讓 .gitignore 真正生效。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 15:14:10 +08:00
uncle6me-web 60f481938d t181 修正：/portal/daemon/extract 認證改用 X-Arcrun-API-Key（帳密行不通） 
【我自己的設計錯誤】前一版用帳密認證，但查證 daemon 實際行為後發現行不通：
**密碼只在連線精靈當下用過就丟、不落地**（config.json 沒有密碼欄，刻意的安全設計，
wiki 記為「密碼零落地」），而背景萃取是每輪自動跑的 ⇒ 根本拿不到密碼。

【改法】沿用 daemon 送卡片上雲時本來就帶的 `X-Arcrun-API-Key`（＝namespace，
collector/direct.go:355）⇒ 同一把憑證、同一個身份模型，不必為此新增任何儲存。
不符即 401（租戶隔離）。

測試四則全過（沒帶 key 401／key 錯 401／缺參數 400／
**回歸守衛：錯誤訊息不得出現 gemini_api_key 或 credential**）。
全檔 38 passed，唯一 failed 與 tsc 的 1190 行 'auto' 皆為基準線既有、與本次無關。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 14:37:16 +08:00
uncle6me-web d728071a6a t181：新增 POST /portal/daemon/extract——daemon 萃取走 Workers AI（免金鑰） 
【leo 08-04 列為最優先】「daemon 的 AI 改用 workers AI」
——「這是我的用戶**最大障礙**，造成首輪測試用戶的**好評或惡評**」。

【舊路徑的三種災難（實測）】要用戶自備 Gemini API Key ⇒
① 完全不知道去哪設定（台大資工碩士都卡住 ⇒ leo：「一般人就完蛋了」）
② 金鑰所屬 Google 帳號被 flag → 403 PERMISSION_DENIED，換專案也無效、申訴有死結
③ 52 檔全滅，還要把金鑰傳給總管實打才查得出真因

【修法】新端點收「已在本機轉成純文字的原稿」，用 env.AI binding 萃卡回傳
⇒ **完全不需要任何金鑰**，用的是用戶自己 CF 帳號內建的 AI，
他的 Google 帳號被封也不受影響。認證沿用 daemon/config 那把（帳密）。

為什麼放雲端：daemon 端沒有 AI binding（binding 是 Worker 專屬），
且模型選型集中在雲端才能統一換。
⚠️ 隱私邊界不變：送上來的是已轉文字的原稿、回傳知識卡，
原始檔案（docx/pdf）仍不出用戶電腦。

提示詞與 daemon 端 gemmaPrompt 同一份契約（第一行必須是「# <頁名>」），
兩邊要一起改。缺 AI binding 時回 501 並指名缺什麼（禁假綠）。

測試 4 則全過（含**回歸守衛：錯誤訊息不得出現 gemini_api_key/credential**
——若有人把它改回打 Google 會立刻紅）；全檔 38 passed，
唯一失敗是基準線既有的 GET /portal 靜態資源案，與本次無關。
tsc 對 portal.ts 零錯誤。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 14:10:00 +08:00
uncle6me-web 41d63b9712 t176 套到 CIS 版 portal：刪 AI 設定區塊（修我把視覺打回舊版的錯） 
【我犯的錯】08-03 出貨時用 `main` 建 UI bundle，但 CIS 新視覺在本分支
（fix/cis-round3-portal），main 上沒有 ⇒ **把 portal 打回 CIS 之前的樣子**。
leo 截圖坐實：新 AI 文案在（t176 生效）但 CIS 全不見（底色/字體/logo 都退回舊版）。

【為什麼會用錯】wiki 記「portal 真身＝matrix/arcrun main」——那是 08-01 記的，
而 CIS 是 08-02 才進本分支 ⇒ **記錄過時**。且我沒照規矩「抓線上內容反查真身」驗證。

【本 commit】把 t176 的改動（移除 AI 設定區塊＋其前端邏輯）套到 CIS 版上，
使兩者同時成立：
  CIS 特徵：--paper-a #FDFCFB ×8、IBM Plex Sans ×10、apple-touch-icon ×1
  t176：「這裡不需要任何設定」×1、st-ai-use-claude ×0
前端 JS 語法檢查通過（4 個 script 區塊 1344 行，node --check 綠）。

重建 UI bundle 後檔數 6 → **9**（多了 favicon.ico/favicon.svg/apple-touch-icon.png）
＝先前那份 bundle 確實漏了 CIS 資產的機械證據。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-04 08:38:02 +08:00
uncle6me-web 66f1b59f7f t176：雲端不再管地端 LLM 設定（leo 08-03 緊急） 
leo 回報四件事：①雲端 Gemini 無法用 ②搞不清楚設定 AI 是設雲端還是地端
③地端不會萃、每個人都死掉因為都去抓 Claude ④雲端還要設置明明就有 Workers AI。
目標：「雲端裝好就能用，地端輸一個 Gemini API Key，然後就開始用。」

根因：extractor_config 的 KV key 由 portalTenant() 組出，而 portalTenant 是
**worker 層級**環境變數（portal.ts:43）⇒ **全租戶共用一把**。任一處設了 claude，
所有人的 daemon 都收到 claude；沒裝 Claude Code 的機器萃取全滅，而 portal 的
Claude 勾選框又恆 disabled（daemon 從未實作 report-capabilities ⇒ daemon_caps 永遠空）
⇒ 用戶自己解不開（awindhon 08-03 實證：雲端同步成功、金鑰有效、零張卡）。

本次（雲端側）：
- POST /portal/daemon/config **不再下發** extractor／gemini_api_key／llm_model，
  只回連線欄位。⚠️ route 本身與 daemon/libraries 資料夾管理完全不動（leo 明確劃界：
  「雲端拉地端檔案夾部分不要刪，刪掉從雲端設置地端 LLM 選項部分」）。
- 移除 POST|GET /portal/admin/extractor（t122）——這是「雲端指定地端引擎」的入口，
  且無任何伺服器端驗證，打一下就能把全租戶設成 claude。
- 移除 POST /portal/daemon/report-capabilities（t131）——daemon 端從未實作該呼叫。
- 移除 t131 那組重複註冊的 /portal/admin/ai。**它是重複 route**：後段（arcrun-rag#10）
  另有同路徑一組，Hono 先到先比 ⇒ 舊的一直贏，後段修好的「金鑰真的寫進 credentials」
  形同死碼。保留後段那組（只管 Gemini 金鑰、走 storeCredential），並拿掉 Claude 偏好欄。
- portal 設定頁「AI 設定」整塊移除，改成一句話說明：雲端不需設定（Workers AI 免金鑰），
  地端請在同步小幫手的「AI 設定…」填 Gemini Key。順手清掉 main 上既有的 conflict 標記。
- 清掉隨之孤兒化的 helper（ExtractorConfig／AiConfig／DaemonCapabilities／
  syncExtractorFromAiConfig／readAiPref 等）。

測試：**相對 merge 前 main 基準線，新增失敗 = 0**（基準線本就 9 紅：console 藏書地圖 6／
portal HTML 殼 2／POST execute 1，皆與本次無關）。t122/t131 兩組測試改寫成
**回歸守衛**（斷言那些端點/欄位確實 404、確實不存在），不是刪掉充綠。
順手修 health bundle_version 測試與實作對齊（實作刻意省略該欄，測試卻期待空字串）。

未送達：本 commit 只到 code，尚未部署上線。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-03 22:11:45 +08:00
uncle6me-web eee3f93815 merge feat/workers-ai-chat-t152：雲端聊天改 Workers AI（免金鑰） 
leo 08-03 緊急事件之一：「雲端還要設置明明就有 workers AI」。
本分支帶進 workers_ai_chat 種子（auth: binding，不需要任何金鑰），
讓「雲端裝好就能用」成立——用戶不必再去申請/貼 Gemini key 才能聊天。

測試差異（相對 merge 前的 main 基準線 9 紅）：
- 新增 3 紅＝/portal/admin/ai 的 Claude 偏好案，正是接下來要刪的功能（t176），隨刪一併處理
- 新增 1 紅＝health bundle_version 回 undefined 而非 ''，本分支既有小瑕疵，
  與本次緊急事件無關，另記待修
- 原 9 紅為 merge 前既有（console 藏書地圖 6／portal HTML 殼 2／POST execute 1）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-03 18:20:33 +08:00
Leo 47c6aaea03 feat(t152): workers_ai_chat 種子（auth: binding，免金鑰）＋ 修 /init/seed 吃掉 3.12 欄位＋ 修 D1 LIKE 長查詢 500 
SDD: workflow-discovery 3.12/3.13（不是新規格；3.12 已 confirmed 並實作完成）

## 1) workers_ai_chat 種子（新）
Cloudflare Workers AI 走 env.AI binding ⇒ 用戶不必填任何 API 金鑰就能問答。
放種子表而非產品安裝器：「裝好後預設有哪些 recipe」是平台能力（rule 07 薄殼原則）。
換模型／換供應商＝改這一筆 recipe，workflow 不動。

選型實測（1.4.4 實例，真實長度 RAG prompt，每個模型連跑 2 次）：
  llama-4-scout-17b        2373／2173 ms  ✅ 答案最完整、引用正確 ← 選它
  llama-3.3-70b-fp8-fast   3261／2147 ms  ✅ 可用但波動較大
  mistral-small-3.1-24b    3560／3631 ms
  qwen2.5-coder-32b        3572／3353 ms
  gpt-oss-120b             1971／2295 ms  ❌ 回應形狀不同，response 取不到文字
  gemma-3-12b-it           ❌ 5018 帳號無權限
對照舊路徑 Gemini gemma-4-31b-it：同型提問 16.87 s，且吐整段英文思考草稿。

## 2) 修 /init/seed 靜默吃掉 3.12 欄位
3.12 給 RecipeDefinition 加了 body_template/response_map/auth/binding_name，
但 /init/seed 是**列舉欄位重建** recipe record ⇒ 不在名單上的欄位被丟掉。
最惡劣的地方是「哪裡都不會紅」：recipe 查得到、endpoint 對，只有跑起來像沒設定過。
與 08-02 syncManifest 吃掉 manifest.daemon 欄同型（教訓：東西還在不在也要進機械閘）。
加 tests/init-seed-recipe-fields.test.ts：拿掉修復會紅、補回會綠（已實測會擋）。

## 3) 修 D1 LIKE pattern 50 bytes 上限造成的 500
/entries/search?q=… 只要 q 超過 48 bytes 就回 HTTP 500，沒有錯誤訊息。
逐 byte 二分：48→200／49→500；中文 16 字→200／17 字→500。
判別實驗：q 固定 48 bytes、其他 filter 全塞滿讓 SQL 變很長 → 仍 200
⇒ 爆的是 LIKE 的 pattern（'%'+q+'%' = 50），不是 statement 長度。
中文問句超過 16 字是常態，而 rag_chat 用整句問題當 q ⇒ 聊天對正常問句等於不能用。
（＝InkStoneCo status.md 待辦第 1 條「KBDB keyword 長查詢會炸」的根因。）
修法：q ≤ 48 bytes 走原路（行為逐字不變），超過才拆詞／切 UTF-8 邊界片段。
kbdb 全套 83 測全綠（含新增 8 項）。

## 4) 順手
- 移除被 commit 進 repo 的 node_modules 壞 symlink（指向 leo Mac 的絕對路徑，
  害任何 fresh clone 裝不起來、切分支還會把裝好的蓋掉——本次撞了兩次）。
- pending-changes.md 加 P2 提案（fan-out 並行執行）＋等裁決，未動引擎。

驗證：cypher-executor 新增測試 17/17 綠；tsc 與基線逐字相同；
全套測試失敗集合與基線**逐字相同**（基線 14 個失敗，本分支 t173 既有，非本次引入）。
 2026-08-03 02:56:53 +00:00
Leo 5b983c47b8 Merge branch 'main' into fix/merge-main-into-batch-t173 
# Conflicts:
#	console-ui/public/portal/index.html
#	cypher-executor/src/routes/health.ts
#	cypher-executor/src/routes/portal.ts
#	registry/components/kbdb_upsert_block/component.contract.yaml
#	registry/examples/km-wiki-ingest/workflow.yaml
 2026-08-02 23:43:16 +08:00
uncle6me-web e570714472 portal 設定頁加版本卡：顯示目前版本＋落後紅點＋一鍵更新（帶 email，t154 免辨識碼） 
leo 08-02：「不顯示的話用戶不知道要不要更新」「發現落後就按一下開啟 install
直接帶它的 email 和辨識碼」。
比法＝自己的 bundle_version（cypher /health）vs 最新版（安裝器 /api/latest），
semver 逐段數字比（避免 1.4.10 < 1.4.9 的字串比錯誤）；
舊格式版本（日期+sha）一律判為落後，舊實例才會被正確提示更新。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-02 19:23:12 +08:00
uncle6me-web 1e89be1ea0 portal 字形對齊 landing（9 處 Songti 明體→無襯線）＋側邊欄 logo 縮小並讓出左右空白 
leo 08-01：「RAG, Install 都沒有襯線，但這裡的字形帶襯線，要複製那裡的 Style」
「logo 再小一點，因為在側邊欄顯得很大，讓出左右的空白」
 2026-08-01 18:54:35 +08:00
uncle6me-web bb023a12fb portal 底色對齊 landing：--paper-a #F2F1ED→#FDFCFB（Paper）、--paper-b/-bar-bg #ECEAE4→#F2F1ED（Canvas） 
leo 08-01：「換了 logo 和部分配色，但整個 style 不同，如果可以修就簡單修」
差異根因：portal 用 Canvas 當主表面色、還自訂了不在 CIS 裡的 #ECEAE4，
整個背景比 landing 暗一階 ⇒ 看起來偏暖褐。改兩個變數即對齊。
其餘 9 種非 CIS 色為狀態色（成功綠/錯誤紅）與深色模式暗底，landing 同款，不動。
 2026-08-01 18:18:06 +08:00
uncle6me-web a78cbbce64 portal CIS 收尾：側邊欄壞 SVG（字腔缺失）換 2x 官方圖＋.logo svg→img CSS 修正＋全站 logo 加 responsive clamp 2026-08-01 16:31:07 +08:00
uncle6me-web 47d90c9feb fix: portal 登入頁 lockup 換裁淨版 PNG，字太小問題修正 
同 rag/install 問題：官方 PNG 畫布 1840x560 只有 32% 高度是實際字形，
height:44px 時實際字高僅約 14px。改用裁淨版（493x88，長寬比 5.604:1，
四邊已裁到字腔邊緣），height 保持 44px 不變，但現在等於實際字高。

兩處 <div class="brand"> 各兩張圖（wm-ink + wm-paper）全部換裝。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-01 16:02:30 +08:00
uncle6me-web a542eb5b5b CIS 緊急修正：wordmark 字腔缺失，改用官方 PNG（portal） 
同 landing/install 根因（自產 SVG outline compound path，a/u/n 字腔洞
未畫進去）與修法：兩處 .brand 內嵌 svg（登入頁×2）改用官方
arcrun-cis/arcrun-lockup-h-ink.png + arcrun-lockup-h-paper-on-ink.png
as base64 data URI。本頁主題靠 data-theme 屬性切換（非 media query），
:root[data-theme="dark"] 時顯示 -paper-on-ink，預設（無屬性＝light）
顯示 -ink。favicon（另外的 favicon.svg/.ico）未動。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-01 15:39:10 +08:00
uncle6me-web f078eba34a CIS 復盤修正 t3b：favicon chevron 筆畫加粗，修 weight mismatch 
同 t1b/t2b（landing/install）根因與修法：CHEV_STROKE 46→109，重產三件套
（favicon.svg/favicon.ico 16·32·48/apple-touch-icon 180×180），三站現在
是同一份位元組。本地驗證（512px 畫布中線段寬）：a 字身 78px／
chevron 85px／chevron 85px，與官方 mark-square-ink.svg 基準（85px）吻合。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-01 15:08:41 +08:00
uncle6me-web 8dfed921dd CIS 第三輪 t3：portal 換裝 CIS 色票 + 真向量 wordmark + favicon 三件套 
leo 08-01 親驗「Portal 裡的色彩都沒改還是跟原來一樣」——實測前 CIS 色票 0
命中、favicon 0（連宣告都沒有）、<svg>=2（皆非 CIS，是既有 graph 視覺化）。

改動（console-ui/public/portal/index.html，僅視覺層，未動
cypher-executor/ 或任何後端邏輯）：
- :root 色板整套換裝：--paper-a/b（舊宣紙米白）→ Canvas #F2F1ED／
  --ink（舊墨字）→ Ink #17181A／--amber（舊琥珀金）→ Relation #B04A2F
  （dark 模式對應 Relation-dark #D9784F）。
- 6 處直接寫死的舊 hex（#241804/#e8b45a/#e57373/#c0392b/#b4462f/#b98330）
  一併清零，統一走 CSS 變數或既有 err token。
- 登入頁/首次設定頁的 .brand、側邊欄 .logo：原本是 Songti 襯線純文字
  「Arcrun」＋ var(--amber) 上色（違反「mark 永遠單色」＋不該用 Relation
  當 logo 色）→ 換成真向量 WORDMARK_SVG（同 t1/t2 那份 IBM Plex Sans
  SemiBold outline + chevron compound path），單色 var(--ink)。
- 新增 favicon.svg（a 加雙 chevron，Ink 底 Paper 挖空）／favicon.ico
  （16/32/48）／apple-touch-icon.png（180×180）到 console-ui/public/
  根目錄，<head> 補三個 <link> 宣告（原本連宣告都沒有）。

本地 Chrome headless 截圖驗證：淺色/深色模式登入頁、側邊欄 logo 三張截圖，
wordmark 與按鈕色階層正確（登入按鈕 Relation 底 + Paper 字）。

已知未盡（誠實列出，留給下一輪）：
- var(--amber) 在原設計裡被當「次要強調色」大量使用（連結色/標題色/
  hover 態，39 處），超出 CIS「≤5% 螢幕」的精神——這次只換色票本身
  沒收斂用法，需要更大範圍的互動色階層重新設計，故未動。
- console/index.html、console/dashboard/index.html 同族問題（舊宣紙+
  琥珀配色、無 favicon）未套用，任務允許但為避免半套改動造成視覺不
  一致，留待下一輪明確處理。

分支從 main 開（fix/cis-round3-portal），未動目前 checkout 的
fix/kbdb-search-deprecated-t24（那份是 7/24 舊版）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-01 14:57:28 +08:00
uncle6me-web 36cdc8fba6 #10 補測試守衛＋console 兩頁同族 fallback 一併拔 
① tests/portal-admin-ai.test.ts（6 項綠）＝**route 消失就會紅**的迴歸防線。
   這條 route 以前不存在、前端卻一直在打它 ⇒ key 從來沒存進去（藍字＝假綠），
   所以最該守的就是「它還在不在」。覆蓋：未登入 401（**不是 404**＝route 真的在）／
   非 admin 403／GET 回 has_key 布林且回應不含任何金鑰欄位（D36）／
   空 body 400 不假裝成功／只改偏好不誤報 has_key／同測試內寫→讀一致。
   註：vitest-pool-workers 預設 isolatedStorage=true ⇒ 跨 it 的 KV 會還原，
   驗來回一致必須在同一個 it 內完成（我第一版寫成跨 it，測試如實抓出來了）。

② console/index.html 與 console/dashboard/index.html 也有同一個寫死
   `|| "https://cypher.arcrun.dev"` fallback（與 portal 同族）⇒ 一併拔掉。
   靜態 config.js 保留無妨：build-ui-bundle.mjs 的 SKIP 會跳過它、改由 worker 動態產生。

驗證：cypher tsc 綠、全套 248 passed（9 既有失敗未變）；
UI 產物 grep 寫死 fallback 歸 0；stage verify.sh 仍 11/3（無迴歸）。
 2026-07-31 20:57:05 +08:00
uncle6me-web 0d49989c19 修 arcrun-rag#10：補 /portal/admin/ai（key 從來沒存進去的真因）＋UI 已輸入態 
真因（不是重裝洗掉，是從來沒存進去）：前端唯一寫入路徑 POST /portal/admin/ai
**後端從來沒有這條 route** ⇒ 用戶填 key → 404 → 什麼都沒存，畫面卻像成功了（藍字＝假綠）。
產物層鐵證：bundle tier2/ui grep 'portal/admin/ai'=1、tier2/cypher=0；兩實例實打皆 404。
反證（別改不壞的東西）：走正確端點寫入 → 完整重裝 24/24 → credential 仍在、
rag_chat verdict failed→success ⇒ **重裝不洗 credential，資料層本來就是保留式的**。

① cypher 補 GET|POST /portal/admin/ai（routes/portal.ts）
   - POST 內部轉呼 credentials.ts 既有 storeCredential()＝**唯一寫入路徑**，不另造第二套
   - GET 只回 has_key 布林，**永不回傳 key 本身**（D36）
   - credential 的 api_key 欄＝租戶 slug（portalTenant），與安裝器 seedCredential 寫
     kbdb_internal_token 用的 ns 同值 ⇒ 同租戶分區，彼此查得到
   - use_claude_for_extract 存 KV（單一布林偏好，不為它開 KBDB template）
   - claude_available 目前無訊號來源（該由小幫手回報）⇒ **誠實回 false 不假綠**
   - 寫入失敗回 502 帶原因——本 bug 的教訓就是「不能讓前端以為存好了」
   - 兩者皆未提供 → 400，避免「看起來成功但什麼都沒做」

② 前端（console-ui/public/portal/index.html）
   - 拔掉寫死 `|| "https://cypher.arcrun.dev"` fallback ⇒ 缺 config.js 就顯示紅色橫幅明顯報錯。
     **寧可明顯失敗，不要靜默把用戶金鑰送去中央實例。**
     ⚠️ 更正我先前的錯誤診斷：config.js **有**正確注入（實查 leo 實例指向自己的 cypher），
     跨租戶錯置未發生；這條是未爆彈不是現行災情。
   - leo 規格：已存 → 唯讀「已輸入」＋「修改」鈕（不顯示 key）；按修改才變回輸入框；
     未存 → 一般輸入框。舊版只改 placeholder＝讀起來像臨時提示，是它像 UI bug 的原因。
   - 只有真的送了新 key 才切回「已輸入」（單純改 Claude 勾選不誤報）

tsc 綠；三個 script 區塊 node --check 全過。
卷：system-dev/docs/3-specs/journeys/gemini-key-lost-on-reinstall.md
 2026-07-31 19:56:47 +08:00
uncle6me-web c735b911a0 🔴 修教材反向教壞：skill §7 自打臉＋補「分支怎麼算成功」＋刪 publish 死代碼 
端到端 haiku 考 0/3、1/3，**斷點在教材不在引擎**（另一 agent 取證，別重查）：
探針零 code 實測 n=10→TRUE、n=1→FALSE 兩次 success；**考生的作品其實會動**
（amount=5000→true、amount=100→false 條件求值全對），但它以為跑不通而放棄改寫 code；
考生第二次自己指認「MCP 說明聲稱不支援 ON_TRUE/ON_FALSE，與實際系統行為不符」。

① skill `write_intent_workflow` **同一份前後打架**（我 08-01 只改了 §2 沒掃全篇）：
   §2.1 教用 ON_TRUE，§7 第 1 條卻把 ON_TRUE 列為「不存在的邊」⇒ 教材自我否定。
   改：§7 只留 ON_FAILURE（真的沒有），並明寫「ON_TRUE/ON_FALSE/ON_BRANCH 是存在的，
   見 §2.1，本行舊世代已更正」。全篇 grep 過確認無其他矛盾。

② **補 §2.2「怎麼確認分支真的走對」**——這是「看到對的結果卻以為失敗」的直接解：
   看 verdict，且**走 true 路時 false 路節點不出現＝正確行為不是失敗**；
   附 08-01 實撞案例，明講「只有一條路有輸出」不該判定壞掉。
   MCP instructions 同步加這段（比 skill 更前置，AI 一連上就讀到）。

③ #23 殘留清除（leo 08-01：「已經沒有 publish 了，零件等級一律走 PR，這條路封了」）：
   `git rm mcp/src/tools/arcrun_publish_component.ts`＋拔掉 registry.ts 的 import
   （註冊呼叫本來就已註解掉＝純死代碼配活 import）。刪前 grep 全 repo 呼叫方：
   除本檔與 registry.ts 外，其餘命中全是 md/SDD 的歷史記載（不需動）。tsc 綠。
   替代路徑＝`Leo/arcrun-components` fork→PR→人審，已寫進 registry.ts 註解。

SDD: workflow-discovery 3.11｜CP: arcrun-usable 步驟 5
 2026-07-31 18:37:48 +08:00
uncle6me-web eefbed98b6 合流 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 三層＋教材世代修）
 2026-07-31 16:56:09 +08:00
uncle6me-web a9a47b7c37 🔴 步驟5 補斷點：教材說「引擎不支援條件分支」＋意圖語法收不到分支標籤 
備考 haiku 真考時自查發現的兩個斷點——**若不補，考試必掛，且掛的是我自己的教材**。
形狀＝步驟1 那個「世代脫節」的翻版：能力做好了，但教 AI 的地方還停在舊世代。

斷點①：三處教材主動說「沒有條件分支」，還教了正好造成腹語術的替代法
  - mcp/src/mcp-handler.ts:44「**沒有** ON_TRUE／ON_FALSE——引擎目前不支援條件分支」
  - registry/skills/write_intent_workflow.md:39「不要寫 ON_TRUE／ON_FALSE…
    需要判斷時**寫成一個獨立節點**再接 ON_SUCCESS」← 這正是「判斷退回 code」的入口
  - registry/skills/INDEX.md:44「已知的坑：引擎沒有條件分支」
  ⇒ 三處全部更新成現況（三顆零件都輸出 data.branch、引擎依標籤選路、
    查零件回應附 branch_hint 照著接即可），並保留「不要寫 ON_FAILURE」（那個真的沒有）。

斷點②（更隱蔽，靜默失效）：`graph-builder` 只認得 `對每個 X` 的參數化 label，
  `ON_BRANCH(branch_active)` 帶括號會落到 toEdgeType 預設值 **PIPE**
  ⇒ 我在 skill 教的寫法，編圖收不到，而且**不報錯**——AI 以為分支了、實際全走同一條。
  「教了語法但引擎不收」比沒做更糟，故與文件同批補上：比照 FOREACH 抽 iterator 的作法
  抽 branch 標籤（半形/全形括號都收），寫進 edge.branch。

新增 tests/intent-branch-syntax.test.ts（7 項綠）：守「文件教的寫法，編圖真的收得到」
——ON_TRUE/ON_FALSE 不退化成 PIPE、中文「成立時/否則」、ON_BRANCH(標籤) 抽得出 branch、
全形括號、try/catch 標籤；零變化：ON_SUCCESS 仍是 ON_SUCCESS、對每個 X 的 iterator 不受干擾。

全套 234 passed（前 227 +7），失敗數維持既有 9 筆；tsc 綠。

SDD: workflow-discovery 3.11｜CP: arcrun-usable 步驟 5

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 16:51:19 +08:00
uncle6me-web e688d805ea 步驟5 抽驗補證：三型分支用「真零件實跑輸出」端到端驗過（不再是推論） 
總管 08-01 抽驗要求（正確）：ON_CASE/ON_CATCH grep=0，我用 ON_BRANCH 通用承接，
但既有測試是用 Input 節點**手餵分支形狀**——那只證明「引擎依標籤選邊」，
**沒證明「真零件吐的標籤對得上」**。leo 特別點名 switch／try_catch，故補實測。

真零件實跑（wasmtime 跑 .component-builds/*.wasm，原文抄進測試當 given）：
  if_control  active   → {"data":{"branch":"true","result":true},"success":true}
  if_control  inactive → {"data":{"branch":"false","result":false},"success":true}
  switch      case1    → {"data":{"branch":"branch_active"},"success":true}
  switch      case3    → {"data":{"branch":"branch_pending"},"success":true}
  switch      無匹配   → {"data":{"branch":"branch_default"},"success":true}
  try_catch   成功     → {"data":{"branch":"try","result":{"value":42}},"success":true}
  try_catch   失敗     → {"data":{"branch":"catch","error":"boom"},"success":true}
⇒ 三顆的標籤與 readBranch 讀的 data.branch **完全對得上**，非「理論上支援」。

新增 tests/branch-real-components.test.ts（8 項綠）：把上列真輸出送進引擎，
驗 if 兩路／switch 多路（含**第 3 條 case** 證明第 N 路走對）＋default／
try_catch ok 與 catch 兩路，每項都驗「該走的走、不該走的沒走」。

新增 tests/branch-hint-response.test.ts（7 項綠）：驗逐顆查三顆的回應
自帶 branch_field/branches/edge_types/usage/example，並把 AI 實際看到的內容印出來
（總管要求「貼回應」）。另驗不分岔零件（http_request/code）無此欄＝不加噪音。

全套 227 passed（前 212 +15），失敗數維持既有 9 筆未變；tsc --noEmit 綠。

SDD: workflow-discovery 3.11｜CP: arcrun-usable 步驟 5

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 16:43:25 +08:00
uncle6me-web c9feb15a37 步驟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>
 2026-07-31 16:34:20 +08:00
uncle6me-web 5f5c0a89e2 步驟5 缺口②：recipe 補 payload／回應正規化／binding 三層（leo 三層模型的第③層） 
問題：舊 recipe schema 只有 {canonical_id, endpoint, method, auth_service}（body 有但淺）
⇒ ①帶 body 的 API 只能繞過 recipe 把整包寫進 workflow code
  ②回應解析綁死單一供應商（rag_chat 的 finalize 2786 字元全在對付 Gemini 形狀）
  ③Cloudflare binding（env.AI/VECTORIZE/BROWSER/QUEUE）整類被「只認 HTTP+金鑰」的抽象排除
⇒ 換 LLM 供應商＝改 workflow，而非換 recipe，違背「外部 API 只有一條一致的路」。

新增 lib/recipe-payload.ts（純函式，好測）：
- renderBodyTemplate：遞迴插值，單一 {{x}} 保留原型別、混合文字拼字串、
  支援 dot path、取不到保留原樣（不靜默吞掉，看得見才好 debug）。
  語義刻意與 graph-executor 的 interpolateData 一致，不新造第二種插值行為。
- applyResponseMap：text_path 取值／thinking_model 剔除 thought=true 取最後一個非 thought／
  answer_marker 用 lastIndexOf（自檢清單內文也會提到標記）／strip_prefixes 循環剝殼
  （實撞三型「Draft: 【答】」「* 【答】」「Answer: * 【答】」，單趟剝不乾淨）。

RecipeDefinition 加四個**全選填**欄位：body_template／response_map／auth／binding_name。
- component-loader：body_template 優先於 body，兩者皆無才沿用 ctx 當 body（既有行為）
- response_map 有設才附 text 欄，未設原樣回傳 ⇒ 既有 recipe 行為完全不變
- 新增 makeBindingRecipeRunner＋pickRecipeRunner：auth='binding' 走平台 binding（免金鑰、
  開機即可用），其餘一律走既有 HTTP 路徑。binding 缺綁定/無 run() 時回可操作錯誤，不假綠。
  這型不是為 Workers AI 開特例——一次打開 env.AI/VECTORIZE/BROWSER/QUEUE 整排。

payload 用法要「查得到」（同 branch_hint 動機，leo 08-01 的 n8n 式逐顆查）：
buildPayloadHint() 讓 recipe 的查詢回應說得出「payload 怎麼填、回應怎麼取值、
認證誰負責」，wire 進 discover 混搜／legacy 逐顆／target=recipe 三條路徑。
金鑰鐵律 D36：hint 只說「走 auth recipe X，金鑰由系統注入、你不必也不該填」，不吐值。

測試：tests/recipe-payload-response.test.ts 14 項全綠（含三家形狀 Gemini/Claude/Workers AI
用不同 path 都取得出文字＝換源＝換 recipe 的實證；未設 response_map 原樣回傳的相容性）。
全套 209 passed（前 179 +30 新），失敗數維持既有 9 筆未變；tsc --noEmit 綠。

SDD: workflow-discovery task 3.12｜CP: arcrun-usable 步驟 5

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 16:31:58 +08:00
uncle6me-web 323ccc8475 步驟5 缺口①：引擎通用具名分支邊（ON_TRUE/ON_FALSE/ON_BRANCH）＝Arcrun#5 根治 
問題（「全變成 code」的根）：if_control 回 {result, branch} 卻沒有邊讀得懂它，
圖的邊只有 ON_SUCCESS/IF/FOREACH ⇒ 就算照規矩用零件，仍得寫 code 判斷走哪條。
leo 08-01 追問「你改了 if，有改 switch 嗎？switch 更嚴重」——確認 switch(N 路)
與 try_catch(try/catch) 同病，故一次做成通用機制，不留「為 switch 再改一次」的債。

設計：三顆流程控制零件的 output_schema 本來就都收斂到同一形狀 data.branch: string
（if_control→true/false；switch→case 名或 default_branch；try_catch→try/catch）
⇒ 引擎只需「依標籤選邊」一個機制 ON_BRANCH；ON_TRUE/ON_FALSE 是布林路的語法糖，
底層同一條路（測試已證等價）。讀不出分支＝不走（誠實，不亂挑一條）。

- types/schemas/constants：新增三邊型（純新增，既有列舉不動）＋ GraphEdge.branch
- graph-executor：readBranch() 依 data.branch → branch → data.result → result 四層相容
- 中文語意詞：成立時/為真時=ON_TRUE，不成立時/為假時/否則=ON_FALSE，BRANCH=ON_BRANCH

分支用法要「查得到」（leo 08-01：AI 可能像 n8n 那樣逐顆查、自己組圖）：
新增 lib/branch-hints.ts，讓 if_control/switch/try_catch 的查詢回應自帶 branch_hint
（branch_field/branches/edge_types/usage/example）——只看這一顆的回應就知道怎麼接下一步，
不必回頭讀 skill。四條回應路徑全wire：catalog found／legacy 逐顆／步驟4 substitution／
target=component 名字搜尋（＝n8n 式那條）。不分岔的零件不加此欄，避免噪音。

測試（先寫測試再改引擎，紅線要求）：tests/conditional-edges.test.ts 16 項全綠
——if 兩路／switch 多路＋default／try_catch 成功與失敗路／語法糖等價／
context 傳遞／同分支 fan-out／無匹配不走／混合邊時 PIPE 不受影響／schema 放行。
零變化保證：195 passed（前 179 +16 新），失敗數維持既有 9 筆未變（console/portal
HTML 資產未建置＋executor 斷言字串漂移，皆與本次無關）；tsc --noEmit 綠。
現存 workflow/example 用到新邊型＝0 筆（grep 實查）⇒ 既有行為不可能被改動。

SDD: workflow-discovery task 3.11｜CP: arcrun-usable 步驟 5

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 16:26:26 +08:00
uncle6me-web 9f777ff43e t161+t162 修 leo prod 實撞兩病：庫清單靜默空白／「需要更新」假警報迴圈 
t162（假警報，實錘）：daemon cloudVersionStale() 讀 cypher /health 的 bundle_version
比對 minCloudBuilt(2026-07-28)，但 **/health 從來只回 {ok:true}、沒有這個欄位**
⇒ 恆讀到空字串 ⇒ 恆判 stale ⇒ 「知識庫需要更新」永遠不消失，重裝也沒用
（leo：「按下就跳到 install，但重新更新後並不會消失，這個訊息是幹嘛的？」）。
安裝器其實一直有注入 ARCRUN_BUNDLE_VERSION（worker.js:819），只是沒人吐出來。
修：/health 讀該 var 誠實回報（未注入則省略欄位＝老實例，daemon 判 stale 是對的）。
新 bundle 注入值 2026-07-31+<commit7> ≥ 2026-07-28 ⇒ 重裝後警報自然消失。

t161（庫清單空白）：portal 前端 guard401 → dropSession() **靜默**清 token 跳登入頁，
畫面不說任何原因 ⇒ 用戶看到的是「庫不見了」而非「請重新登入」（leo：「實際上根本
沒連上任何庫，清單空白」）。修：dropSession 帶原因寫進 #login-status——
「你的登入已過期，請重新登入（你的資料都還在，不會遺失）。」
資料側無恙（portal_library records=2 已驗），純讀側 session 過期＋靜默 UX 缺陷。

驗：cypher tsc 全綠；vitest 9 failed/187 passed＝基線不變。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 15:34:27 +08:00
uncle6me-web 341bcb13c8 t160 測試跟上規格：人工建庫 POST → 404（庫只從 daemon 同步來） 
舊測試驗「POST 建庫 200＋重複 409」＝已刪端點的規格；vitest 回基線 9 failed/187 passed。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 14:57:22 +08:00
uncle6me-web 832f270f52 Merge branch 'feat/step6-success-rate' into feat/step3-missing-guidance 2026-07-31 14:54:25 +08:00
uncle6me-web 5c5109cd45 Merge branch 'feat/step4-node-substitution' into feat/step3-missing-guidance 
# Conflicts:
#	system-dev/docs/3-specs/workflow-discovery/tasks.md
 2026-07-31 14:54:25 +08:00
uncle6me-web e744ad1f96 t160 世代債清除（leo：「如果你會搞不清楚，就把錯的東西刪掉」）——repo 只留一個 UI 世代 
事故鏈（07-31 深夜，leo 刷新撞到）：t159 重打包 staging bundle 時，build-ui-bundle
吃了 feat/step3 分支的 console-ui/public/——該分支基底早於 main d7fab7c
「拿掉登記新庫」，public 停在舊世代 ⇒ youlin 實例 UI 被打回被淘汰的
「登記新庫」人工表單典範（07-27 mistakes 已記帳的 src/public 雙世代債，
這次由「分支副本停舊代」路徑引爆——債沒還，任何一個部署路徑都會引爆它）。

刪掉的（舊世代，git rm 實體刪除）：
- console-ui/src/（console.ts/console-dashboard.ts/portal-ui.ts）＝07-22 從
  cypher-executor 搬出的 renderer 快照，自 07-27 起與 public/ 真身脫鉤、只會
  重產舊 UI
- console-ui/scripts/build.mjs＝從上述舊 renderer 重產 public 的 build 步驟
  （deploy.mjs 原自動跑它＝引爆器本體）
- cypher POST /portal/admin/libraries（人工建庫端點）＝死端點（e28e190 起 UI
  零呼叫；leo 規格「要直通 daemon，同步，沒有登記這回事」）。GET 列表／PATCH
  管理／t159 daemon 自動登記照舊

新唯一源：console-ui/public/＝手改演進的真身（本 commit 同步到 main e28e190
世代＋註解字樣改寫達成「登記新庫」全檔 0 命中）；deploy.mjs 改為直接託管
public（無 build 步）＋世代閘（缺「不需要人工新增」或含「登記新庫」拒部署）。

驗：tsc 全綠；deploy.mjs node --check 過；重打 ui bundle 242KB 過世代閘，
指紋「登記新庫」=0／「不需要人工新增」=1。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 14:36:48 +08:00
uncle6me-web cae0d7be3b 3.9 落帳＋pending-changes 提案：workflow export/import 一等公民化（D35 ③，接線待 confirm） 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 14:15:33 +08:00
uncle6me-web 062757f1b1 t159 修 portal 庫目錄空：補上 daemon 一直在打、但從未存在的登記端點 
診斷更正（重要）：kbdb 裡 50+ 筆 entry_type=value（content=資料夾名）**不是孤兒**——
那是 91 筆 triplet records 的 library slot 正常構造（records 全部組裝完整，資料同步
一切正常，無失敗無重試）。真病灶＝**POST /portal/daemon/libraries 這個 route
從來不存在**：daemon registerLibraries（arcrun-tray main.go:505，t52「用戶可以看到
我有 2 個庫」）連線精靈時打它 → 404 → 被 daemon「失敗不擋連線」設計靜默吞掉
→ portal_library 登記簿永遠 0 筆 → portal「庫目錄管理」空。

- 新 route 契約照 daemon 既有呼叫：{email, password, libraries:[{name, display_name}]}
- 帳密驗證沿用 /portal/session 同一套（isLocked/findUserRecordId/verifyPassword/
  recordLoginFail；daemon 只在精靈那刻拿帳密不存）
- 冪等：listRecordsByTemplate 比 name，已登記跳過（重跑精靈不堆重複）
- 庫名走 isValidLibraryName 同閘（拒 "*" 與非法字元）

驗：tsc 全綠；youlin 實例資料層已手動補登記（探針 record PATCH 成
youlinhsieh-test1＋新建 test2，portal_library count=2）；route 部署驗證
隨下批 staging bundle（假帳密應回 401 而非 404）。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 14:07:05 +08:00
uncle6me-web 9c9aff0046 t158 P1 素材：workflow export/import 原語（definition 端點＋CLI 命令，未接線） 
leo 07-31：「你要做的就是一個叫 export，另一個是 import……現在如果我要把我做的
工作流分享給同事，我要怎麼 export？他要如何 import？是缺了功能用 search 來湊嗎？」

- cypher GET /webhooks/named/:name/definition：吐可攜定義（graph＋config＋description
  ＝record 原樣）——export 的引擎端；import 端直接 POST /webhooks/named 即送進任何實例
- cli/commands/workflow.ts：acr workflow export <name>（definition→.workflow.yaml，
  flow 從 graph.edges 反推供人讀）／import <file>（graph 直 POST，零編圖零 search
  零存在性驗證＝V2 純複製；手寫 yaml 無 graph → 指去 acr push）
- ⚠️ 未接線：index.ts 尚未掛 workflow 命令組（P1 收尾：接線＋分享場景 A export→
  B import 驗收＋parser 共用模組化）

安裝器側 P0（rag-installer 5a6539d）已用同形狀（打包期預編 graph＋純上傳）上 prod。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 13:49:23 +08:00
uncle6me-web d48f83ae6f t159 步驟4 意圖節點→真實零件/recipe 替換＋/cypher/search 加 target 指定搜尋對象 
CP arcrun-usable 步驟 4（目的：AI 只要填 payload——系統把「傳到 telegram」
翻成 http_request＋recipe telegram_send）＋leo 07-31 追加：
「難道我不能指定要搜尋工作流或節點或 recipe 嗎？」

替換（只動 discover，t158「部署≠發現」邊界不碰）：
- 兩庫 exact 落空後，在 t158 一次抓好的清單記憶體內媒合，零新增 round-trip
- 規則 A 服務詞→recipe：名字全部服務詞命中同一 recipe 且唯一才換
  （google_slides_create 不被 google_sheets 誤吃）
- 規則 B 強欄位斷詞→零件：canonical/display/aliases 強命中×10＋弱命中，
  需至少一強命中且分數唯一最高（aes_encrypt 無強命中不換）
- 換到＝status resolved＋substitution{from,componentId,recipe,reason}，
  cypher 圖節點直接帶真實 componentId；換不到照舊 not_found＋3.7 指路

target 參數（各走既有機制，不新造第二套搜尋）：
- triplets＋target=component|recipe＝只查該庫
- query＋target＝名字搜尋：component→registry /components/search（＝MCP
  arcrun_search_components 同路）；recipe→私庫 RECIPES KV（回應註明公庫走
  arcrun_recipe_search）；workflow→新抽 lib/workflow-search.ts，
  GET /workflows/search 與 target=workflow 共用（＝arcrun_search_workflows 同路）
- 防呆：compile＋target 400／target=workflow 吃 query 不吃 triplets／非法 target 400

驗（本地 wrangler dev，registry 種 20 合約＋init/seed 10 recipe）：
- 「判斷有沒有新資料 >> ON_SUCCESS >> 傳到 telegram」→ if_control（resolved）
  ＋telegram_send（substitution.componentId=http_request）＝feature 06 驗法過
- 機械考 27/27 全綠（01 組×5＋03 組×4 迴歸＋06 組×8＋target×8＋compile 迴歸×2）
- 冷啟第一發 94ms、熱 8–13ms（t158 病史對照：舊 25.7s）；compile 39ms unchecked 照舊
- tsc 全綠；vitest 9 failed/179 passed＝t158 基線完全相同

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 13:49:09 +08:00
uncle6me-web ea1c0571c1 步驟6 執行統計回寫：每顆零件跑完回寫 success_rate（task 29，design.md「執行統計設計」） 
- registry 新增 POST /analytics/record：ANALYTICS_KV 計數器（stats:{hash_id}:{version}）
  為唯一真相源，衍生值（success_rate/avg_duration_ms/call_count）回填 comp: 記錄
  ——查詢讀取端讀哪就寫哪，不開第二真相源。KV 無 CAS，誠實標註非原子。
- cypher-executor execution-evaluator 從 stub 改真實作：執行收尾（/cypher/execute
  成功與 ExecutionError 路徑＋webhook 路徑）對 trace 裡每顆 Component 節點
  fire-and-forget 回寫，waitUntil 包、不增加執行同步延遲（仿 recordRecipeStats 慣例）。
  成敗判定＝trace error 或 output.success===false（makeHttpRunner 非 2xx 不 throw）。
- registry 位置沿 search-nodes 慣例：REGISTRY_BASE_URL 覆蓋，未設走 wasmWorkerUrl。
- 新增單測 13 個全綠；本地雙 wrangler dev 端到端實測：http_request 跑 5 次
  （3 成功＋2 失敗）→ success_rate 1→0.6、call_count 0→5，/cypher/search 同步可見。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 13:45:05 +08:00
uncle6me-web 7e631a890a t158 迴歸修復「部署≠發現」：複製路徑回毫秒級純編圖，誠實化只留在 discover 
leo 07-31 定調：「這裡只是複製一些工作流的 data 過去，沒有要在這裡驗證，難怪這麼慢。
就算是我自己寫了錯的工作流，也可以跑跑看，如果錯誤就修改，
沒有說有錯誤還要一個個驗證這回事。」

定性＝迴歸非新設計：部署路徑純複製是既有設計（arcrun-rag installer/src/index.js:13
「workflows.json 是既有 workflows/*.local.yaml 的搬運（打包期抽 flow/config）」＋
arcrun-rag wiki「workflow 打包期預編成 workflows.json（worker 免帶 parser）」）。
5cadc60 起誠實化漏進 /cypher/search ⇒ 複製路徑也逐節點跑兩庫查詢＋相似搜尋
（每 missing 節點 1+9 次 HTTP＋recipe KV 掃）⇒ 冷實例 8 節點實測 25.7s、
安裝器 15s timeout 必炸（leo stage 實走 rag_takedown_direct aborted）。

改動：
- /cypher/search 加 mode：compile＝純編圖零查詢（安裝器/acr push 複製路徑）；
  discover＝誠實查詢預設（AI 問「有沒有」的既有契約，not_found＋分型指路全保留）
- /cypher/execute 一律 compile（存在性由 component-loader 執行時決定＝原權威）
- compile 的節點 status 標 unchecked（誠實「沒查」，不回假 found）
- discover 批次化：registry 新增 GET /components/catalog（一次回全目錄含
  input_schema，補 CP2-B「沒有列表端點」缺口）＋recipe 清單一次抓，
  存在判定與相似度全記憶體比對；舊 registry 無 catalog 端點 → 退回逐顆（相容）；
  registry 整個查不通 → unknown 照舊（不誤判 not_found）
- cli push 帶 mode:compile＋拔 missing 擋（push 不看 missing；要問有沒有走 validate）

驗（本地 wrangler dev 誠實環境，registry 種 20 合約）：
- compile 編圖：graph_neighbors 39ms／rag_chat(11節點) 3ms／rag_ingest_card 2ms／
  rag_takedown_direct(8節點) 3ms——回迴歸前毫秒級
- 安裝器 pushWorkflowTo（mode:compile）4/4 ok（44/7/7/5ms）
- 故意引用不存在零件的 workflow：部署 ok=true，trigger 執行時誠實報
  「找不到零件…」＋可用零件清單（部署≠發現實證）
- discover 契約：邏輯名 missing=2＋not_found＋suggestion（21ms）；
  頂層 verify.sh 01 組 5/5＋03 組 4/4 全綠
- cypher+registry tsc 全綠；vitest 9 failed/179 passed＝5cadc60 基線完全相同

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 13:31:33 +08:00
uncle6me-web 7e87a3336b 3.8 新增 write_recipe skill——recipe 指路終於有目的地 
📋 SDD：workflow-discovery task 3.8（3.7 的 suggestion 指 skill write_recipe，
之前是空地——指路會指到不存在的 skill）。

- registry/skills/write_recipe.md：從真 code 反推，不是憑空教學——
  schema＝routes/recipes.ts RecipeDefinition（canonical_id/endpoint/method/auth_service…）；
  真範例＝api-recipe-seeds.ts 的 telegram_send（URL path 注入）＋gmail_send（service account）；
  auth recipe 必填欄位（required_secrets 的 help_url 必填）照 POST /auth-recipes 驗證邏輯；
  常犯錯收錄實錄（sheets append PUT→POST、telegram auth recipe 漏種、金鑰只准名字 D36）
- INDEX.md 補 write_recipe 入口；「/cypher/search 假 found」坑改標已修（2026-07-31）
- write_intent_workflow.md §6 status 表改 not_found 契約＋suggestion/similar_* 欄說明

安裝器 seed：registry/skills/*.md 由 sync-registry-to-kbdb.py 自動收，新檔即納入。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-31 11:56:30 +08:00
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
uncle6me-web 747dc3f843 3.7 補指引目的地＋3.8 write_recipe skill（recipe 指路現為空地） 2026-07-31 11:38:26 +08:00
uncle6me-web c56863a7e0 3.6/3.7 補設計基調：回覆重點=缺哪些；兩庫都搜；驗收=機械綠→haiku 真考 2026-07-31 11:36:01 +08:00
uncle6me-web fc6c98cd58 workflow-discovery 補 3.6/3.7（頂層交棒）：recipe 入查詢＋缺件分型指路——leo 07-31 定義步驟 3 考題 2026-07-31 11:26:20 +08:00
uncle6me-web 0a426c4e16 fix(cypher): CORS origin 空值放行——CLI/curl/MCP 無 Origin 標頭時不再 500 2026-07-31 10:50:57 +08:00
Leo b8ca98cb49 MCP 認證改用 Portal 帳密，廢掉 MCP_OWNER_SECRET（leo 指定做法） 
leo：「claude 裡有一個直接輸入帳密連線的，為什麼不用那個？跟他輸入 portal 的帳密一樣不就好了？」

為什麼換（三個封測撞出來的實際問題）：
① 沒人給得了封測者——安裝器產生後從不顯示（完成頁 grep「Owner 祕密」=0），
   CF secret 又唯寫讀不回 ⇒ 用戶卡在同意頁，只能找 leo 手動 wrangler 覆寫
② 多一把要記的金鑰——違反「拿一把金鑰就很難了」
③ 全實例共用一把，無法分辨誰連上來（企業多人版必要）

風險評估（leo 判斷，總管原本誇大成「繞過帳密的旁路」已認錯）：
secret 要貼進 claude.ai（本身有帳密保護）⇒ 洩漏 secret 與洩漏 portal 帳密風險相同。

改動：
- consent.ts：一個「Owner 祕密」欄位 → email ＋ password 兩欄
- routes.ts POST /authorize：constantTimeEqual(MCP_OWNER_SECRET)
  → 走 CYPHER_EXECUTOR binding 打 /portal/login（認證下沉到唯一真相源，
    同樣吃它的節流與停用檢查）
- routes.ts GET /authorize：移除「未設 MCP_OWNER_SECRET → 503」
  （那是「每個封測者都死在這頁」的直接原因）

驗：tsc 零錯誤；已部署 youlin。
 2026-07-31 00:44:15 +08:00
Leo cda1c7b261 instructions 補「你配備了 Arcrun、別上網搜」＋新增 skills/INDEX（LLM wiki 式導航） 
leo 兩個洞察：
① 「整個 arcrun instruction 很像 LLM wiki…它會拿到一個 index 把所有文件說明都塞給它，
   它不會就可以查，範本全部寫在裡面」
   ⇒ 對照 wiki 的 push/pull 分法：我原本只做了 push（instructions 開場），
     漏了 pull（INDEX 導航）。補 registry/skills/INDEX.md：
     什麼症狀查哪支 skill／查現成零件recipe workflow 的九支工具／四個已知的坑／腹語術紅線
② 「它不去查就不知道…如果它去上網搜因為它不知道自己有配備呢？」
   ⇒ 實測確認 instructions 是 **push**（本 session system prompt 內就有藏書地圖那段）
     ⇒ AI 不會去上網搜，但原本的 instructions 沒說「你配備了什麼」
     ⇒ 開場補：Arcrun 是什麼／你現在就有完整能力／不要上網搜（網路上沒有）

驗：tsc 零錯誤。⚠️ 未部署——實測總管 token 只有 account(read)，無法部署任何 CF worker。
 2026-07-30 22:38:37 +08:00
Leo fac7d6c9bb AI 一連上 MCP 就知道從哪開始（leo 追問揪出的最後一哩） 
leo：「arcrun_get_skill 放在 MCP 裡，現在人類說『幫我用 arcrun 寫 xxx』，
Haiku 會說『arcrun 是什麼？我看看』然後發現有個 arcrun mcp 就去執行？
如果不會，要寫什麼在外面讓它一聽到就知道要用這些資源？」

實測答案：**不會**。
① 總管寫的指引沒有任何入口指向它（真實 AI 找不到）
② MCP 五個 skill 沒有「怎麼寫意圖工作流」這支
③ AI 只看到 41 個工具名 → 自己猜 → 很可能直接 push_workflow 瞎編，
   或去讀 registry/examples 那 8/13 引用不存在零件的壞範例

兩件修法：
1. registry/skills/write_intent_workflow.md — 把指引變成 AI 拿得到的 skill
   （範本全取自實跑 verdict=success 的四支 workflow；含「查詢現在回假 found」的已知限制警告）
2. mcp-handler.ts instructions 開場指路 — instructions 是唯一「AI 一連上就必看」的欄位
   ⇒ 開場就寫明五步順序（先讀 write_intent_workflow → whoami → 查零件 → list_skills → 缺件怎麼補）
   ＋邊只有兩種、第一個節點是 input、不要因查不到就改寫 code
   ⚠️ 靜態常數：KBDB 掛了也必出現（守「不擋連線」鐵律）

驗：tsc 零錯誤。⏳ 待部署後由 leo 真的問 haiku「幫我用 arcrun 做 X」驗證它會不會自己讀 skill。
 2026-07-30 22:29:28 +08:00
Leo 0686d39fa1 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。
 2026-07-30 22:06:48 +08:00
Leo 156cdcbe7b chore: 刪掉兩個死零件與其壞範例（leo：這裏的每個不要的零件還存在啊） 
📋 SDD：workflow-discovery（active）／對應 CP arcrun-usable 步驟 5「死代碼清除」

刪除（git rm 保留歷史）：
- registry/components/km_writer      + .component-builds/km_writer
- registry/components/kbdb_upsert_block + .component-builds/kbdb_upsert_block
- registry/examples/km-wiki-ingest（唯一引用 kbdb_upsert_block 的範例，Mira 時代同源產物）

為什麼刪（Arcrun 自己的 06-mindset.md §1 早已載明）：
「mira 的 claude_api / km_writer 就是這樣被錯做成零件的（其實是自用服務膠水）」
＋ kbdb_upsert_block 是「一個 CRUD 操作一個零件」（leo：總不能每個都建一個零件）
＋ 兩者綁的 Mira 已於 2026-06-29 蒸發＝死零件。

刪前實測引用數：workflows.json 0／cypher src 0／examples 僅 km-wiki-ingest。
零件數 22 → 20。

✅ 投影模型驗證成功：build-bundles.mjs 掃 .component-builds/ 目錄（readdirSync），
重跑後 manifest 自動 25 顆 → 23 顆，兩顆消失，**不需手動改 manifest**。
⇒ 證明 manifest 這層本來就是投影（leo 的設計），只有 registry KV 那層是獨立登記簿（待改）。

驗：vitest 9 failed/179 passed＝與刪除前相同（既有債）。
 2026-07-30 21:30:26 +08:00
Leo 5cadc60e36 feat(workflow-discovery): /cypher/search 改為真查 registry——修「查詢回假信號」 
📋 SDD：workflow-discovery（本 commit 同時執行 D35 交接：portal-auth 26/26 完成 → closed
   superseded_by workflow-discovery；workflow-discovery paused → active。單一活性已驗＝1 份）
🎯 對應 task：3.x 搜尋端誠實化（CP2-B）

病灶（leo 2026-07-30 定性「腹語術」）：
search-nodes.ts 無條件回 status:'found'、missingNodes 永遠 []——
型別宣告了 'missing' 但程式碼從不使用。實測「完全不存在的東西xyz」也回 found。
⇒ AI 拿到假信號 → 以為零件存在 → 部署才發現沒有 → 改寫 code
⇒ 正式 workflow 只用 2 個零件、8 個 code 節點含 if×61。

修法：
- 查 registry 判真實存在（走 HTTP，守 D28 禁新增 service binding；
  URL 用既有 wasmWorkerUrl() 慣例組，不自創）
- found 時附 input_schema／success_rate／stability
  ⇒ AI 才填得出 payload、才看得到「測過幾次」（leo：AI 只要填 payload）
- 查不通回 'unknown' 而非 'missing'——**誠實限制**：
  不能因查詢失敗就宣告零件不存在（那會讓 AI 誤判而重寫 code）
- missing 真的回傳出去（原本寫死 []）

⚠️ 實測發現 registry **沒有列表端點**（GET /components → 404，只有 /components/<id>）
⇒ 改為逐個查（節點數通常 <10、5s timeout）。補列表端點後可改抓一次＝CP2-B 待辦。

驗：tsc 零錯誤；vitest 9 failed/179 passed＝**與改動前 stash 對帳完全相同**（既有債非本次造成）。
⏳ 待部署到實例後跑 arcrun-usable/verify.sh 驗 01 那組轉綠。
 2026-07-30 20:41:53 +08:00
Leo e28e19069f t142: 雲端子庫顯示同步幾張卡＋幾個三元組（政府專案驗收需求） 
leo 07-29：「要在雲端子庫顯示同步了幾個 wiki，既然這樣也同步顯示有幾個三元組，
這是為了政府專案驗收。」

kbdb 兩支統計端點：
- entries.ts: COUNT(DISTINCT page_name) AS card_count
  ⚠️ 必須 distinct——算 block 數會膨脹 3-5 倍，政府驗收看到假數字比沒數字更糟
- records.ts: COUNT(*) AS triplet_count（三元組本來就算全部）
portal.ts 聚合兩者掛進庫目錄；前端 index.html 顯示。

驗：卡數確為 COUNT(DISTINCT page_name)／前端內嵌 JS node --check 全通過
（07-29 白畫面事故教訓）／portal-admin 測試 34 passed（改動前 31 passed，
唯一的 1 failed 是既有債：GET /portal 回 404，改動前後相同，非本次造成）。

註：此為子 CC 完成後未 commit 的懸置工作，總管收工檢查時發現並補收。
 2026-07-29 19:55:03 +08:00