Arcrun

Leo/Arcrun

Fork 0

Commit Graph

Author	SHA1	Message	Date
uncle6me-web	6985bf4850	fix(kbdb): 搜尋框打的 % 和 _ 是字，不是萬用字元（Arcrun#94）使用者在搜尋框打 `%` 或 `_`，搜出來一堆跟他打的字無關的東西。病根：pattern 一直是 `'%' + 使用者輸入 + '%'` 直接內插，而 SQLite 的 LIKE 有兩個萬用字元（`%` 任意長度、`_` 任意一字）且沒有預設跳脫字元——不寫 ESCAPE 就沒有任何辦法表示「字面上的 %」。所以他打的符號被當成 pattern 語法： `100%` → `%100%%` → 「100」後面接什麼都算 ⇒ 撈回一堆不相干的 `owner_id` → `%owner_id%` → `_` 匹配任一字元 ⇒ ownerXid 也中單打 `%`／`_` → `%%%`／`%_%` → 整個庫都回來舊病，不是 08-10 斷詞（#84）引進的：pattern 從來就是這樣拼的。之前關鍵字搜尋幾乎恆為 0 命中，這個洞被那個洞蓋住；斷詞讓搜尋真的會回東西之後才浮出來。斷詞那段一個字都沒動。修法：pattern 產生點全部收斂到兩支 helper—— · escapeLikeLiteral()：跳脫 `%` `_` `\` 三個字元 · CONTENT_LIKE 常數：每個 `content LIKE ?` 一律帶 `ESCAPE '\'` 為什麼跳脫字元本身（`\`）也要處理：宣告 ESCAPE 之後 `\` 就變成 pattern 裡有意義的字元，而且它會把後面那個字吃掉、且不報錯——打 `C:\` 會變成去找 `C:%` （真正的 `C:\` 反而漏掉）；只跳脫 %/_ 而漏掉 `\`，打 `C:\_temp` 時 `\\` 先被讀成字面 `\`、後面的 `_` 變回萬用字元 ⇒ 撈到 `C:\Xtemp`。三個是一組的。 `[` `]` `?` `*` 不需要跳脫（那是 GLOB／別的方言，LIKE 不吃），多跳只會白白吃掉 pattern 的 byte 預算。連帶：跳脫會變長（`%`→`\%`），所以 50 bytes 上限改用「跳脫後」的長度算（likeBytes），否則打 48 個 `%` 會產生 98 bytes 的 pattern ⇒ 退回 2026-08-03 修掉的那個 HTTP 500。不含這三個字元的查詢 likeBytes ≡ utf8Len ⇒ 既有查詢逐字不變。 search-long-query.test.ts 兩條「逐字比對謂詞字串」的斷言跟著新字串更新——改的是比對用的常數、不是放寬檢查（仍逐字相等比對），pattern 本身一個字都沒變。沒有引進第三種搜尋機制，沒有動資料層（三表不變），沒有動斷詞。	2026-08-12 11:59:36 +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

Author

SHA1

Message

Date

uncle6me-web

6985bf4850

fix(kbdb): 搜尋框打的 % 和 _ 是字，不是萬用字元（Arcrun#94）

使用者在搜尋框打 `%` 或 `_`，搜出來一堆跟他打的字無關的東西。

病根：pattern 一直是 `'%' + 使用者輸入 + '%'` 直接內插，而 SQLite 的 LIKE 有
兩個萬用字元（`%` 任意長度、`_` 任意一字）且**沒有預設跳脫字元**——不寫
ESCAPE 就沒有任何辦法表示「字面上的 %」。所以他打的符號被當成 pattern 語法：

    `100%`     → `%100%%`  → 「100」後面接什麼都算 ⇒ 撈回一堆不相干的
    `owner_id` → `%owner_id%` → `_` 匹配任一字元 ⇒ ownerXid 也中
    單打 `%`／`_` → `%%%`／`%_%` → 整個庫都回來

舊病，不是 08-10 斷詞（#84）引進的：pattern 從來就是這樣拼的。之前關鍵字搜尋
幾乎恆為 0 命中，這個洞被那個洞蓋住；斷詞讓搜尋真的會回東西之後才浮出來。
斷詞那段一個字都沒動。

修法：pattern 產生點全部收斂到兩支 helper——
  · escapeLikeLiteral()：跳脫 `%` `_` `\` 三個字元
  · CONTENT_LIKE 常數：每個 `content LIKE ?` 一律帶 `ESCAPE '\'`

為什麼跳脫字元本身（`\`）也要處理：宣告 ESCAPE 之後 `\` 就變成 pattern 裡有
意義的字元，而且它會把後面那個字吃掉、且不報錯——打 `C:\` 會變成去找 `C:%`
（真正的 `C:\` 反而漏掉）；只跳脫 %/_ 而漏掉 `\`，打 `C:\_temp` 時 `\\` 先被
讀成字面 `\`、後面的 `_` 變回萬用字元 ⇒ 撈到 `C:\Xtemp`。三個是一組的。
`[` `]` `?` `*` 不需要跳脫（那是 GLOB／別的方言，LIKE 不吃），多跳只會白白吃掉
pattern 的 byte 預算。

連帶：跳脫會變長（`%`→`\%`），所以 50 bytes 上限改用「跳脫後」的長度算
（likeBytes），否則打 48 個 `%` 會產生 98 bytes 的 pattern ⇒ 退回 2026-08-03
修掉的那個 HTTP 500。不含這三個字元的查詢 likeBytes ≡ utf8Len ⇒ 既有查詢逐字不變。

search-long-query.test.ts 兩條「逐字比對謂詞字串」的斷言跟著新字串更新——改的是
比對用的常數、不是放寬檢查（仍逐字相等比對），pattern 本身一個字都沒變。

沒有引進第三種搜尋機制，沒有動資料層（三表不變），沒有動斷詞。

2026-08-12 11:59:36 +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

2 Commits