9609924818
提案補勾連：辨識碼的「更新者免碼」是靠那張紙，方向與直覺相反
...
不是用辨識碼找那張紙，是用那張紙免掉辨識碼（t154）。
紙搬到帳號上後，免碼判準自然變成去帳號看一眼，並讓 #120 情境變誠實：
帳號清空＝本來就是新裝，請填辨識碼是對的答案，不是把人關在門外。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-14 20:08:29 +08:00
cfb759a774
提案收斂：那張紙搬到用戶自己的帳號上，中心不再保管（leo 2026-08-14 第三次）
...
比「降級」更徹底——紙跟東西在同一個地方，一起消失
⇒ #120 不是被修好，是沒有地方可以發生。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-14 20:05:29 +08:00
73bdb90780
pending-changes：安裝器狀態判斷改看帳號、中心帳本降級（leo 2026-08-14 的檢修孔比喻）
...
同一天三次撞牆同一形狀：帳本與現場分岔時，安裝器相信帳本。
鐵律：帳本永遠不得產生停手；不合時以現場為準並順手改對帳本。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-14 20:03:05 +08:00
8286c8afec
docs(pending-changes): 提案——認證儲存搬回 D1/KV（撤 D61 的儲存層決定，留其明顯失敗語意）
...
arcrun-rag#99 止血修法（安裝精靈傳 OAuth token 給 cypher 建第一個帳號）只解一格，
之後的寫入（換密碼/加使用者/存金鑰）仍永久 writable:false，是留債。
查證（讀碼＋讀本機重打的 .worker-builds/manifest.json，非猜測）：D61 想解的病根
（重裝時 binding 被照名字重新指到新建空資源）已在 2026-08-13 被更通用的
shared/resource-rule（Arcrun#97）解掉——SESSIONS_KV、KBDB 的 D1 都在 cypher 的
requires 清單裡，且 runInstall:1762 每次安裝/更新都會走這條規則。技術前提成立。
提案：認證資料搬回 D1/KV（走 binding，零外部 CF token、零過期、零新 OAuth scope、
零手動步驟），保留 D61 加的三個明顯失敗機制。附影響分析、遷移考量、信心水位
（靜態推論，未動態實測）、D84 三段式驗法（③ uninstall 目前做不到，如實標記）。
⏸ 等 leo/總管 confirm，本 commit 不動任何架構程式碼。
順手修：writeAuthStore 的錯誤訊息移除誤導的「/ CF_ACCOUNT_ID」（已查證全新實例
一定有這個 var，installer worker.js:1354 無條件注入，列兩項只會讓下一個人白工）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-14 12:06:50 +08:00
9740794050
docs(3-specs): 立案 Arcrun App ↔ Portal 掛載協定 v0 提案（Leo/Arcrun#82）
...
設計全文住在票上，本檔只留指針＋影響分析，等 leo confirm。
病根實查：Portal「有哪些頁」在單檔 HTML 裡寫了四遍，出貨時整包內嵌成
單檔 worker，安裝器只會整顆換掉、無任何掛載點概念 ⇒ 加一個能力＝改核心。
未 confirm 前不開新 SDD、不動功能程式碼（現行 active＝workflow-discovery）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-09 22:02:08 +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
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
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
646e689b65
confirm(CP2-F): 二～四刀拆分過裁（leo 授權技術裁決）；四題答定（手寫驗證/arcrun-api/排程於 A 線後）
2026-07-24 18:11:10 +08:00
ab8e07201f
proposal(CP2-F): cypher 二～四刀拆分提案——bundle 528KB 實測解剖＋引擎留原地方案（待 leo confirm）
...
偵察實測（wrangler dry-run＋sourcemap byte 歸因，非推測）：
- 現碼 11,050 行／bundle 528.1KB——頂層 CP2-F 記載（15,446 行/748KB）是第一刀前舊數，提案 §0 更正
- zod 佔 130.6KB（24.7%），只服務兩條入口驗證鏈＝最大單一減重點
- 引擎真身僅 ~180KB，其餘 ~350KB 是管理/前端 API 面
方案：引擎留 cypher-executor 原地（webhook 觸發 URL 外部焊死、零改動），
新開 arcrun-api 收管理面；三刀漸進、每刀獨立回退；13 顆 SVC binding 不動。
依 D35 只寫 proposal 停下，不動 code、不部署。
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com >
2026-07-24 15:37:51 +08:00
Leo
1b687fedb0
fix(mcp): 解掉三個把人推去寫零件的誤導入口（leo 2026-07-21 拍板）
...
leo：「刪掉，技術者才會寫 component，在 Arcrun repo 寫一條如何 contribute
指向另一個 repo 就好。」
實測病灶：總管想寫「定期打 API 然後通知」的 workflow（Python 約 10 行），
問 foreach_control 怎麼用 → MCP 回傳 TinyGo 寫 WASM 零件教學（白名單/syscall/
contract schema）＝完全另一件事，40 分鐘未完成。
三處修正：
1. search_components 搜不到時的話術——原本建議 publish_component（把「我找不到」
翻譯成「你去造一個」，方向完全相反）。改為導向正確順序：語意搜尋知識庫→
auth-recipe list/scaffold→acr parts（http_request 能打任意 API）→acr list，
並明說 registry 可能是空的（已知問題），搜不到≠沒有這能力。
2. registry.ts 停用 publish_component / get_component_guide 兩個註冊
（檔案保留，只是不對 AI 暴露）。
3. 新增 CONTRIBUTING-components.md：三層責任分工（平台通用能力／熱門預鋪 recipe／
冷門誰用到誰開發）、什麼時候才真需要新零件、真要貢獻走 PR 的流程。
typecheck 通過。
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com >
2026-07-21 16:42:51 +08:00
a73de77a7f
docs(sdd): P-2026-07-19 confirmed——pending-changes 移入已裁決、artifact-sharing tasks 增補 Phase 1.5（bundle/譜系/訂閱/多源/self-check）
2026-07-19 06:43:38 +00:00
ffd50e7510
docs(sdd): pending-changes 收 P-2026-07-19 proposal——artifact-sharing 增補 bundle/譜系/訂閱/多源（leo 對話定調，正式 confirm 待明示）
2026-07-19 06:28:28 +00:00
7bd7b4b26a
SDD 生命週期鐵律遷移：單一活性制度上線（portal-auth=active，其餘 paused/draft）
...
- 鋪檔（自 system-dev-template v1.15.0）：SDD-LIFECYCLE.md＋pending-changes.md
＋sdd-guard.sh（覆蓋舊版，加單一活性檢查）＋sdd-check.md＋sdd-active-check.sh
- settings.json PreToolUse（Write|Edit|MultiEdit）掛上 sdd-guard.sh
- 全部 SDD design.md 掛 frontmatter：portal-auth=active（現行 portal 線，
#61 demo 四件套剛 merge）；artifact-sharing=draft（零任務動工）；
其餘 16 份＝paused（皆有未完成任務，無明顯死件，不硬 close）
- CLAUDE.md 加「SDD 生命週期鐵律」段（指向 SDD-LIFECYCLE.md＋濃縮五條）
＋SDD 速查表改以 frontmatter status: active 為現行判準
- 驗證：sdd-active-check exit 0（恰 1 份 active）；guard pipe-test code 檔
exit 0 帶現行 SDD 提示；反向測試（造 2 份 active）guard exit 2／check exit 1 全擋
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com >
2026-07-17 17:03:16 +08:00
uncle6me-web
Leo