Arcrun

Leo/Arcrun

Author SHA1 Message Date

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	046ceba29c	fix(kbdb): credential 目錄自癒搬遷（D38 收尾）——修 youlin 20/20 全敗事故根因（2026-08-07 youlin 測試實例）：7ba7855 把 credential 讀寫端從舊表 credentials（0002）改走 KBDB entries（entry_type='credential'），但舊表資料的搬遷 migration（0006）要人手動觸發部署才會跑。實查 youlin 的 D1： credentials 表有 1 筆（yuga3bse/kbdb_internal_token），entries 對應筆數為 0——新讀取端上線、舊資料還沒搬，20 次 workflow 全部找不到 credential。 leo 追加硬要求：credential 資料住在用戶自己的 CF 帳號，換讀取路徑＝每個既有實例都要遷移，但用戶不准做任何手動步驟——搬遷必須內建在既有更新流程裡、天然無感。解法（kbdb/src/actions/credential-legacy-migration.ts）：把「搬」變成「讀」的副作用而非獨立步驟。KBDB worker（D38 唯一允許碰 SQL 的牆內）在每次查詢某租戶的 credential 目錄前，先確認舊表資料是否已搬進 entries ——沒有就搬（per-owner scoped、NOT EXISTS 冪等），有就是零成本的 sqlite_master 短路檢查。呼叫時機掛在 GET /entries?entry_type=credential （cypher-executor 熱路徑本來就會打的端點），故只要更新 KBDB worker，下一次任何人跑 workflow 該租戶就自動搬好，不需要用戶或安裝器多做任何事。刻意不執行退場（DROP TABLE）——多個實例搬遷時間點不同，舊表留著才能讓「已搬」與「還沒搬」的實例同時安全運作；退場留給之後獨立的清理步驟。 kbdb/tests/credential-legacy-migration.test.ts：反向驗證重建 2026-08-07 事故的確切前置狀態（真 SQLite + 0001/0002/0005 migration 原檔），證明補丁加入前 entries.length 回 0（事故重現），加入後回 1（修好）；另驗冪等（連呼叫三次不重複搬）、多租戶互不干擾、舊表已清理時的終態安全。 cypher-executor/tests/credentials.test.ts：補齊 `7ba7855` 留下的刻意紅燈（原 placeholder 五項清單），涵蓋租戶隔離的讀寫、真刪除（非 deprecated 標記）、零原生 SQL 原始碼掃描、密文本體不落 KBDB。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 22:51:31 +08:00

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

046ceba29c

fix(kbdb): credential 目錄自癒搬遷（D38 收尾）——修 youlin 20/20 全敗事故

根因（2026-08-07 youlin 測試實例）：7ba7855 把 credential 讀寫端從舊表
credentials（0002）改走 KBDB entries（entry_type='credential'），但舊表
資料的搬遷 migration（0006）要人手動觸發部署才會跑。實查 youlin 的 D1：
credentials 表有 1 筆（yuga3bse/kbdb_internal_token），entries 對應筆數
為 0——新讀取端上線、舊資料還沒搬，20 次 workflow 全部找不到 credential。

leo 追加硬要求：credential 資料住在用戶自己的 CF 帳號，換讀取路徑＝每個
既有實例都要遷移，但用戶不准做任何手動步驟——搬遷必須內建在既有更新流程
裡、天然無感。

解法（kbdb/src/actions/credential-legacy-migration.ts）：把「搬」變成
「讀」的副作用而非獨立步驟。KBDB worker（D38 唯一允許碰 SQL 的牆內）在
每次查詢某租戶的 credential 目錄前，先確認舊表資料是否已搬進 entries
——沒有就搬（per-owner scoped、NOT EXISTS 冪等），有就是零成本的
sqlite_master 短路檢查。呼叫時機掛在 GET /entries?entry_type=credential
（cypher-executor 熱路徑本來就會打的端點），故只要更新 KBDB worker，
下一次任何人跑 workflow 該租戶就自動搬好，不需要用戶或安裝器多做任何事。
刻意不執行退場（DROP TABLE）——多個實例搬遷時間點不同，舊表留著才能讓
「已搬」與「還沒搬」的實例同時安全運作；退場留給之後獨立的清理步驟。

kbdb/tests/credential-legacy-migration.test.ts：反向驗證重建 2026-08-07
事故的確切前置狀態（真 SQLite + 0001/0002/0005 migration 原檔），證明補丁
加入前 entries.length 回 0（事故重現），加入後回 1（修好）；另驗冪等
（連呼叫三次不重複搬）、多租戶互不干擾、舊表已清理時的終態安全。

cypher-executor/tests/credentials.test.ts：補齊 7ba7855 留下的刻意紅燈
（原 placeholder 五項清單），涵蓋租戶隔離的讀寫、真刪除（非 deprecated
標記）、零原生 SQL 原始碼掃描、密文本體不落 KBDB。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-07 22:51:31 +08:00

2 Commits