5919c6b90f
liveTripletCountsByLibrary 沒有過濾 status,recomputeLibraryMap 只算 COALESCE(status,'active')='active'——兩邊判準不一致,只要庫裡有一筆 superseded triplet 就永遠判定 stale,導致每次讀地圖(GET /map、GET /map/:library、 kbdb_get_map MCP 工具)都觸發重算並新建一筆 library_map record,無止盡寫 D1, 且加劇既有的非原子 supersede 競態(kb 44 筆全 superseded、notes 兩筆同時 active 即 arcrun-rag#50 的共同根因之一)。 修法:liveTripletCountsByLibrary 的 SQL 改成 pivot 出 status 再套用與 recomputeLibraryMap 逐字一致的過濾,兩邊判準對齊。 新增迴歸測試釘住此 bug(反向驗證:跑在修前的 SQL 上會失敗,非空氣測試); 獨立用 leo21c MCP 連線連讀兩次 kbdb_get_map() 重現修前症狀 (general 庫 updated_at 從 1786457080 前進到 1786457114,中間無寫入)。 kbdb/tests/library-map.test.ts 19/19 全綠。既有殘骸(100 筆 library_map record) 未清——目前沒有可用的 DELETE 通道,待部署後另行處理。 kbdb-sql-ok:liveTripletCountsByLibrary 的 .prepare 呼叫是牆內本體 (kbdb/src/actions/),本次 checkout 開在巢狀 worktree matrix/arcrun/.worktree-fix-87/(避免打斷另一 session 佔用中的 matrix/arcrun 主 checkout),kbdb-api-wall-guard.sh 的字面路徑比對 *matrix/arcrun/kbdb/src/* 吃不到中間多出的 worktree 目錄層,非真的繞牆。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>