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

10 Commits

Author SHA1 Message Date
uncle6me-web ceb7638d74 feat(kbdb): 樹狀 record 模型第一刀——record 有身分、關係是唯一機制、entry_values 拆表（v7 定稿實作） 
規格：system-dev/docs/3-specs/pending-changes.md「record 要有身分」v7 定稿（leo 2026-08-15 confirm）。
模型一句話（leo）：「真身在 pool 的 entry 裡，所有的虛擬表虛擬欄位都是指向這個 entry 的指標。」

- 0007 migration：池上型別化指標欄（src/rel/dst）＋一對方向 partial index＋啟動常數
  （sys_root/sys_belongs/sys_field_of）＋templates 鏡射成 sheet/field entry＋
  每筆 record 一顆身分 entry（id＝原 record_id，引用不失效）＋每格一條關係列
  （id 由舊儲存格列 id 衍生 ⇒ INSERT OR IGNORE 天然冪等）＋拆 entry_values
  （0006 墊表→搬→拆手法）。純 INSERT、value entries 一列不動（向量索引不失效）。
- record-crud 整份改寫到關係列（#128 指標語意/共用保護/N+1 批次/租戶過濾全數保留，
  驗收測試 232→236 綠）；library-map 四段縱轉橫 SQL、records triplet-stats 改查關係列。
- entry-crud：機制列隔離（未指定 entry_type 的列表/搜尋不回機制節點）；deleteEntry
  接手舊 entry_values FK 的不變量（dst 被指著→拒刪）。
- 孤兒偵測重設計（v7 §5 點名）：新模型孤兒＝指標指向不存在 id 的關係列，
  LEFT JOIN 斷鏈掃描（承接 2026-06-24 清理事故的 FK 形狀），
  GET /maintenance/relation-orphans 唯讀巡檢。
- cli deploy.ts：0007 逐句套用＋容錯 duplicate column（SQLite 無欄位級 IF NOT EXISTS，
  整檔送 /query 會在重跑時假紅）。
- 測試：tree-record-migration.test.ts 驗資料零漏／雙跑冪等／孤兒掃描；
  釘死三表的斷言依 confirm 後規格改口（execution-log/credential-legacy 兩處）。

遷移期雙軌（第二刀收）：templates 表仍是欄位定義真相源；六種 metadata_json 打包型
與 §7 減法封鎖（拿掉 entry_type/metadata_json 欄）留待第二刀。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-15 21:34:48 +08:00
uncle6me-web aa49b4eeb2 fix(kbdb): 刪 record 不再刪掉別人還指著的 entry（Arcrun#128 的必然配套） 
上一筆讓 slot 可以指向既有 entry 之後，同一條 entry 會同時被別的 record 指著。
deleteRecord 舊寫法是「這筆 record 的每個 entry_id 都刪掉」，在共用的情況下會：
  · 把**別人還在用**的那條水池資料一起刪掉（他的 slot 從此指向不存在的列），或
  · 撞上 `entry_values.entry_id REFERENCES entries(id)` 的 FK 而整個刪除失敗
⇒ 條件改成「已經沒有任何 entry_values 指著它」才刪
  （`DELETE FROM entries WHERE id = ? AND NOT EXISTS (SELECT 1 FROM entry_values WHERE entry_id = ?)`）

**沒有共用時行為與舊版完全相同**：這筆 record 的關聯列已先刪掉，若沒有別人指著，
NOT EXISTS 恆為真 ⇒ 照樣刪。差別只出現在真的被共用的那一條上。

驗（同檔 +2 條，真 SQLite 且 `PRAGMA foreign_keys = ON`）
· 兩筆 record 共用一段、刪掉其中一筆：entries 2 → 1（只少掉那筆自己專屬的 title），
  共用那條還在，另一筆 record 讀回來的 slot 值不受影響
· 沒有共用時：3 個 slot 的 entry 全刪、entry_values 歸零、getRecord 回 null（同舊版）

kbdb 全套 232 綠

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-15 14:44:32 +08:00
uncle6me-web 5b22d569c9 fix(kbdb): createRecord 的 slot 可以指向既有 entry——外鍵不再被實作成複製（Arcrun#128） 
leo 2026-08-15 的心智模型：「blocks 是一個大水池，template/slots 組成虛擬表和
fields，最後都指向水池的一條 entry⋯⋯連到三元組就是外鍵」。

而 `entry_values` 的約束只有 `UNIQUE(record_id, slot_name)`、`entry_id` 上沒有任何
unique ⇒ 一條 entry 本來就能被無限多筆 record 的無限多個 slot 參照，
**儲存層早就是外鍵語意，壞的只有寫入路徑**：createRecord 對每個 slot 值都無條件
createEntry ⇒ 每設一次外鍵就把被參照的資料複製一份。那不是外鍵，那是複製。

為什麼是地基而不是省空間：複製讓資料量隨「有幾個 App 參照它」線性膨脹，而且兩份
從此各自漂移 ⇒ 遲早要有人來清 ⇒ 直接違背這個模型的產品承諾「加一個 App 只要建一份
template，不必遷移、不需要工程師」（llm-wiki-schema.md）。#129（wiki template）、
#130（三元組正規化）、#60（alias 餵了沒用）三票都卡在它後面。

做了什麼（不動 schema、不動舊資料、不加表）
· CreateRecordInput 多一個 entry_ids：{slot: 既有 entry id}，與 values 並存
  —— 給字串照舊新建（舊呼叫端一個字不用改），給 id 就只插一列 entry_values
· POST /records 接受只給 entry_ids（舊版這裡回 400），並驗兩個 map 的型別
· 寫入前先把被參照的 entry 讀出來，一次擋掉三種錯，且**檢查全在第一筆 INSERT 之前**
  ⇒ 失敗＝一列都沒寫（base 沒有交易，這是唯一保證得了的原子性）
    ① id 不存在（FK 只會回一句 SQLITE_CONSTRAINT，說不出是哪個 slot）
    ② 🔴 跨租戶：新路徑讓呼叫端能自己指定 entry_id，不擋就等於開一扇
       「把別人的 entry 掛進自己的 record 再讀回內容」的門（rules 02 §6.1 同精神）
    ③ 指到 template 沒有的 slot → 報錯，不學 values 那條靜默略過
       （外鍵無聲消失是最難查的失敗：呼叫端以為建好了，template= 查詢卻永遠撈不到）

驗（tests/record-entry-ref.test.ts，17 條，真 SQLite 套 0001_base.sql 原檔——
「列數變不變」是 capture-DB 驗不到的東西，必須有真的表在數）
· 五個 slot 全指既有 entry：entries 5 → 5（差 0），entry_values 0 → 5
  對照組同樣五段給字串：entries 5 → 10（差 5）＝原本的複製行為
· 一條 entry 同時被兩筆 record、且被同一筆 record 的兩個 slot 指到 → 讀回都正確
· 改水池那一份 → 兩筆 record 都看到新內容（副本做不到，證明真的是同一條）
· searchByTemplate('wiki','leo') 撈得到，五個 slot 值正確
· 舊路徑逐項不變：3 筆新 entry、entry_type='value'、owner_id 帶歸屬、
  template 沒有的 slot 照舊只 echo 不存；POST 舊 body 仍 200

kbdb 全套 215 → 230 綠（新增 15 條，既有一條都沒動）

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-15 14:43:42 +08:00
uncle6me-web 10d150ac2b fix(mcp): MCP 用登入者的身分查詢，不再去找一把服務內部金鑰 
leo 2026-08-12：「人類進 Portal 輸入帳密表示你是主人，可以查到你權限所有東西；
AI 透過輸入帳密的 MCP 查詢表示是授權的 AI，可以查到主人允許查的任何東西。」
「掛上 MCP 並輸入帳密，那個動作本身就是授權」⇒ 下游不得再要求第二次認證。

病根（不是金鑰沒同步，是身分沒接住）：
  oauth/routes.ts 驗完 Portal 帳密只留下 `loginOk = res.ok` 一個布林值，身分當場丟棄，
  namespace 改從 `MCP_OWNER_NAMESPACE || "leo"` 拿。於是查詢時手上沒有身分可帶，
  只好用 KBDB_INTERNAL_TOKEN 直打 KBDB——那條路繞過 portal 所有庫過濾，
  而且不管誰登入都看到同一格、看到全部。CLI 也從不注入 MCP_OWNER_NAMESPACE，
  所以那個 "leo" 預設值是每台實例的實際行為，不是理論上的邊角。

修法（走既有那條路，不發明新的）：
1. 接住身分：/authorize 解析 /portal/login 回應，把 portal session token ＋
   display_name/role/libraries 存進 authorization code → access token。
   /portal/login 補回 session_expires_in，access_token TTL 夾成
   min(自己的 TTL, portal session TTL)——不讓「MCP 還連著、底下 session 早死」。
   cypher 回 200 但沒給 session_token（舊版）→ 不發碼，不簽一張沒有身分的 token。
2. 攜帶身分：kbdb_* 全部改走 cypher `/portal/data/*`，Authorization 帶登入者的
   session。庫過濾／租戶注入／停用即時生效全在 server 側，與人類走 portal 網頁同一道閘。
   kbdb_graph_neighbors 因此不再需要 kbdb_base（server 自己知道查哪個庫）。
   藏書地圖（含連線時注入 instructions 的那份）同樣只回有權限的庫，快取改 per-session
   分格——地圖本身就是情報，不能讓先連上的人把視野留給下一個。
3. fail-closed：舊 token 沒有身分 → 誠實要求重新連線，不偷偷退回服務金鑰那條老路。
   服務級憑據（static token / partner key）維持既有 KBDB 直連，arcrun_* 零回歸。

新增 cypher portal 資料面端點（能力長在 API，MCP 只暴露；rule 07）：
  GET  /portal/data/map、/portal/data/map/:library
  GET  /portal/data/templates、POST /portal/data/templates
  GET  /portal/data/records/by-template/:t、GET /portal/data/records/:id
  POST /portal/data/records
全部：呼叫端自帶 owner_id 一律不生效；越權與不存在同回 404；寫入 owner_id 由 server 定死。

KBDB base：`GET /records/:id` 與 by-template 補回 owner_id 欄位——原本不回，
呼叫端無從判斷「這筆是不是我的」，按 id 直讀等於沒有租戶邊界。

沒動：KBDB fail-closed 閘、任何金鑰、租戶字串仍不下發給呼叫端。

驗證：
  mcp        tsc 綠；vitest 113/113 綠（改前 48 綠 29 紅）
  cypher     vitest 400 綠 / 14 紅，14 紅與 base commit a24f291 逐條相同（既有）
  kbdb       vitest 208 綠 / 5 紅，5 紅同為既有（migrations/*.sql 被 gitignore）
  端到端     ◐ 未驗：需部署到 leo21c，那道閘要 leo 親手解（見 PR）

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-12 19:33:12 +08:00
uncle6me-web 0860e84d22 feat(t135): 庫目錄可自主移除＋標示還在不在同步 
leo：「需要加移除按鈕。因為別人裝錯我沒辦法幫他弄，需要可以自主」
＋「你應該要顯示這個庫沒有本地對應的 folder，那就不容易刪錯」
（兩態非三態——leo 二修：「分兩種沒意義」，那是內部狀態不是用戶分類）。
- DELETE /portal/admin/libraries/:id（登記簿）與 by-name/:name（auto 庫需輸入庫名確認）
- kbdb 加 deprecate-by-library（auto 庫移除＝標 deprecated，資料保留可還原）
- daemon/libraries 存 active 清單 → 卡片標 🟢同步中／灰目前沒有在同步
- 不自動刪（daemon 可能沒開機）；daemon 從未回報時整列不標
vitest 24 passed（1 紅＝console HTML 搬遷陳舊測試，非本案）。
（實作＝子 CC；驗證+commit＝總管。含 t116/t117 先前未 commit 的 graph-executor/wasi-shim 修正）
 2026-07-29 14:45:44 +08:00
Claude (總管雲端) 0ca3af4d1a kbdb: searchByTemplate 修 N+1（100 筆 record 逐筆 getRecord ≈ 19 秒 → 批次 IN 查詢 1.3 秒） 
leo 客戶測試「圖譜/AI 查詢 20-30 秒」的病根：by-template 列表對每筆 record
各跑一次 getRecord（每筆一次 D1 往返）。改為 record id 以 90 一組（D1 綁定
參數上限 100）批次 IN 撈 slot 值，輸出排序與形狀不變。
實測 uncle6：/records/by-template/triplet 19s→1.3s、portal 圖譜 20s→3s、
總圖 1.8s。kbdb 測試 20/20 綠、tsc 0。
 2026-07-18 08:30:38 +00:00
Leo 1260d8cffb portal-auth P2（#24 #25）：portal_user 模型＋認證 API（不 merge，待總管審） (#51) 2026-07-14 04:19:54 +00:00
uncle6me-web 934b9265d9 feat: KBDB self-hosted 查詢 + embed 模組 + thin-shell 收窄 + search_workflow（code done 待端到端） 
按 issue 分段標明（檔 #5/#8 改動交疊處無法乾淨拆檔，故併一個 commit）：

#4 thin-shell §3.1 自力救濟階梯 + code-node 規則（純文檔/規則，code-node 零件未實作）
#5 KBDB source filter（json_extract metadata_json 零建表）+ 能力對照；documents 聚合與
   DELETE proxy 部分擱置等頂層 T8
#7 base embed 模組（kbdb/src/embed.ts）+ vectorize 開關（deploy/config/wrangler.toml 註解範本）
   + 語義查詢降級閉環（mode=semantic 未開→LIKE+capability_hint）
#8 部分（workflow-discovery）：
   - KBDB /entries/search 加 base 通用 entry_type filter（entry-crud/embed/route/kbdb-proxy 透傳）
   - /webhooks/named 強制 description（空→400，訊息要求操盤 AI 據實寫一句）
   - 部署雙寫 entry_type=workflow embeddable entry（waitUntil 非阻塞，供 search）
   - cypher GET /workflows/search + MCP u6u_search_workflows（優先語意、降級 hint）
   - cypher POST /workflows/backfill-search-entries（無 desc 列出不編造）
   - GET /webhooks/named 補回 description/created_at 欄位（為 list 來源收斂備）

⚠️ tsc 綠 = code done，非完成（mindset §7 禁假綠）：
- #7/#8 端到端待 leo21c 部署驗（Vectorize 需官方憑證、CC 跑不了）
- #8 ①-a（MCP deploy 改打 /webhooks/named）未做、MCP deploy 那半仍 404
- #8 端到端（強制填擋空/語義命中/租戶隔離/降級 hint）未驗

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-27 17:52:52 +08:00
uncle6me-web eeafd5c094 fix(kbdb): searchByTemplate 真按 owner_id 過濾（修租戶隔離洩漏） 
煙霧測試發現 searchByTemplate 的 `if (rec && (!owner_id || true))` 是 stub，
`|| true` 讓 owner_id 過濾失效 → 任何租戶查同 template 看得到別人的 record。
改：給 owner_id 時 JOIN entries 在 SQL 限定 e.owner_id（record 歸屬存底層
entries.owner_id，createRecord 寫入時帶）；沒給才不限（內部/全域查詢）。

cypher KBDB proxy 強制注入 owner_id，故端到端隔離靠這條 SQL 落地。
searchEntries 早已正確按 owner_id 過濾，無此 bug。kbdb tsc exit 0。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
 2026-06-14 22:18:17 +08:00
uncle6me-web 6a75117ba3 feat(kbdb): recipe 公庫/私庫雙向機制 + UUID 身份 + KBDB Base + 市場數據 
kbdb-base SDD §7.5（公庫/私庫雙向機制，richblack 2026-06-07 拍板）。

## KBDB Base worker（新）
- kbdb/：D1-only 核心三表（entries/templates/entry_values）+ CRUD + LIKE search
  + recipe-stats 端點（市場數據）+ 0001_base.sql migration（含 recipe_stat seed）

## Phase 2.3：init 建 D1 + 套 migration
- cli cf-api.ts 加 listD1Databases/ensureD1Database；init 建 arcrun-kbdb D1
- deploy.ts 部署後對 D1 套 0001_base.sql（CF /d1/query API，idempotent）+ 注入 database_id

## Phase 5.1：recipe 成功記錄（市場數據來源）
- GraphExecutor 收集本次用到的 recipe uuid（usedRecipeKeys）
- executeWebhookGraph 執行結束一次性記 per-uuid 成功/失敗到 KBDB（fire-and-forget）

## Phase 7.5：recipe UUID 身份 + app-store 模型
- recipe 領 uuid=唯一身份；canonical_id/author/公私=屬性（§7.5.5）
- recipe:{uuid} + idx:canonical/installed/hash；resolveRecipe 向後相容不破執行鏈
- POST /recipes/submit=領新 uuid 新增作者版本（非覆蓋，app-store）
- GET /public-recipes 搜尋（多作者+per-uuid 市場星數）/ :id pull（選市場最佳）
- 落空→found:false 創作引導（§7.5.6 閉環）
- POST /recipes/migrate-uuid 一次性轉舊 key（增量寫不刪舊、冪等）
- init-seed 用 UUID（author=system）

## 薄殼（rule 07 §5：CLI + MCP 覆蓋同組能力）
- CLI: acr recipe search/pull/submit-p（config 加 DEFAULT_PUBLIC_LIBRARY_URL）
- MCP: arcrun_recipe_search/pull/submit_p/push/list/delete（補齊漂移）

## 壓測修正
- api-recipe-seeds: google_sheets_append PUT→POST（:append 正確動詞，階段12）

四 worker tsc 全綠（cypher/cli/kbdb/mcp）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-06-07 16:18:10 +08:00