新進來的知識沒有貼上「屬於哪個庫」——補完存量,隔天又開始長出沒標的 #1

Open
opened 2026-08-11 14:04:31 +00:00 by Leo · 1 comment
Owner

[總管交辦] 這是 Leo/Arcrun#87(藏書地圖是空的)的源頭那一半
leo 已經強調過兩次:順序不能倒——先讓源頭寫入時就貼標,再補存量。
倒過來做,補完的當下又開始長出沒貼標的新資料,永遠追不完。

要達成什麼

新寫進知識庫的三元組,身上要帶著「屬於哪個庫」,不必事後有人來補。

驗法(leo 定的,不接受「我測過了」):
新寫進去的卡片,不必人工補標,下次看藏書地圖就出現在對的庫底下。

為什麼是這個 repo

Arcrunkbdb/src/index.ts 檔頭自己寫著 triplet (separate repo)
——寫三元組的是這裡,不是 kbdb。所以補存量可以在那邊做,但源頭在這裡。

判定依據已經量過了,不必你重查(2026-08-11 實測,樣本 100 筆,零例外)

三元組的 source_uri 本身就寫著它從哪裡來,格式固定:

gitea:Leo/notes@system-dev/wiki/cards/notes/00-INDEX.md#seg02
gitea:Leo/mira@system-dev/wiki/cards/setup/環境建置-leo21c骨架.md
kb://journals/2026_08_05.md

規則是確定性的字串比對,不是機率判斷:

① source_uri 符合 ^gitea:Leo/<repo>@  → library = <repo>(小寫正規化)
② source_uri 符合 ^kb://              → library = kb
③ 其餘(沒有 source_uri)              → 留白,不猜

實測判得出 98%,判不出的 2% 留白。

存量的分佈(gitea:Leo/ 開頭共 1,426 筆,八個 repo 分項相加正好等於總數,無殘餘無重疊):
arcrun-harness 423/Arcrun 208/notes 194/kb 163/arcrun-rag 154/mira 111/InkStoneCo 107/kbdb-ingest-plugin 66。

⚠️ 兩個容易踩的細節

  • Gitea 上是 Leo/ArcrunLeo/InkStoneCo大寫),地圖庫名是小寫 ⇒ 要正規化
  • derivations 不是 Gitea repo(實查 24 個 repo 沒有它),是 AI 推導出來的卡,沒有原稿可對帳 ⇒ 它要另一條規則,本票不涵蓋

🔴 紅線

  • 判不出來的一律留白,不准猜。 貼錯比沒貼更糟——沒貼只是搜不到;貼錯會讓地圖顯示假的分佈,而人會照著假地圖決定「該進哪個庫查」,錯誤被放大成決策依據
  • 守 KBDB 既有的資料層規約(D38:一律走 API,不繞過那面牆)。怎麼實作由這個 repo 判斷。
  • 不准掛 cron/排程輪詢(D20)。
  • 不可以推 main:推自己的分支,交回總管審(2026-08-10 兩層手動確認閘)。

相關

Leo/Arcrun#87(本票的另一半:存量補標+地圖的兩個 bug)|
Leo/Arcrun#85(向量化分層,同樣吃「按庫挑一批」這個能力)|
Leo/Arcrun#81Leo/InkStoneCo#17(全景圖,建在地圖上)

收工要交什麼

改了什麼、貼實測輸出(新寫一筆 → 看地圖 → 它出現在對的庫底下)、分支名、還缺什麼。
CP 三態只有 ✅ 通(附實測證據)/◐ 半通(標明缺什麼)/❌ 斷碼寫完沒部署不准標

> **[總管交辦]** 這是 `Leo/Arcrun#87`(藏書地圖是空的)的**源頭那一半**。 > leo 已經強調過兩次:**順序不能倒——先讓源頭寫入時就貼標,再補存量。** > 倒過來做,補完的當下又開始長出沒貼標的新資料,永遠追不完。 ## 要達成什麼 **新寫進知識庫的三元組,身上要帶著「屬於哪個庫」,不必事後有人來補。** 驗法(leo 定的,不接受「我測過了」): **新寫進去的卡片,不必人工補標,下次看藏書地圖就出現在對的庫底下。** ## 為什麼是這個 repo `Arcrun` 的 `kbdb/src/index.ts` 檔頭自己寫著 `triplet (separate repo)` ——**寫三元組的是這裡,不是 kbdb**。所以補存量可以在那邊做,但源頭在這裡。 ## 判定依據已經量過了,不必你重查(2026-08-11 實測,樣本 100 筆,零例外) 三元組的 `source_uri` 本身就寫著它從哪裡來,格式固定: ``` gitea:Leo/notes@system-dev/wiki/cards/notes/00-INDEX.md#seg02 gitea:Leo/mira@system-dev/wiki/cards/setup/環境建置-leo21c骨架.md kb://journals/2026_08_05.md ``` 規則是**確定性的字串比對**,不是機率判斷: ``` ① source_uri 符合 ^gitea:Leo/<repo>@ → library = <repo>(小寫正規化) ② source_uri 符合 ^kb:// → library = kb ③ 其餘(沒有 source_uri) → 留白,不猜 ``` 實測判得出 **98%**,判不出的 2% 留白。 存量的分佈(`gitea:Leo/` 開頭共 1,426 筆,八個 repo 分項相加正好等於總數,無殘餘無重疊): `arcrun-harness` 423/`Arcrun` 208/`notes` 194/`kb` 163/`arcrun-rag` 154/`mira` 111/`InkStoneCo` 107/`kbdb-ingest-plugin` 66。 ⚠️ **兩個容易踩的細節**: - Gitea 上是 `Leo/Arcrun`、`Leo/InkStoneCo`(**大寫**),地圖庫名是小寫 ⇒ 要正規化 - `derivations` **不是 Gitea repo**(實查 24 個 repo 沒有它),是 AI 推導出來的卡,**沒有原稿可對帳** ⇒ 它要另一條規則,本票不涵蓋 ## 🔴 紅線 - **判不出來的一律留白,不准猜。** 貼錯比沒貼更糟——沒貼只是搜不到;貼錯會讓地圖顯示**假的分佈**,而人會照著假地圖決定「該進哪個庫查」,**錯誤被放大成決策依據**。 - 守 KBDB 既有的資料層規約(**D38:一律走 API,不繞過那面牆**)。怎麼實作由這個 repo 判斷。 - **不准掛 cron/排程輪詢**(D20)。 - **不可以推 main**:推自己的分支,交回總管審(2026-08-10 兩層手動確認閘)。 ## 相關 `Leo/Arcrun#87`(本票的另一半:存量補標+地圖的兩個 bug)| `Leo/Arcrun#85`(向量化分層,同樣吃「按庫挑一批」這個能力)| `Leo/Arcrun#81`/`Leo/InkStoneCo#17`(全景圖,建在地圖上) ## 收工要交什麼 改了什麼、**貼實測輸出**(新寫一筆 → 看地圖 → 它出現在對的庫底下)、分支名、還缺什麼。 CP 三態只有 `✅ 通(附實測證據)/◐ 半通(標明缺什麼)/❌ 斷`;**碼寫完沒部署不准標 ✅**。
Author
Owner

📐 leo 2026-08-12:這三張票是同一條路線,不是三件事

「知識貼標與地圖,跟 daemon 同步有關⋯⋯這就是:

  • 先找到 Gitea 的庫
  • 比照找到資料庫的東西
  • 依照 Gitea 的庫 locate 它在本機的位置
  • Daemon ingest 從本機庫
  • 斷掉 Gitea ingest

這句話收掉的模糊空間

原本三張票各自看起來像獨立問題:

  • Leo/Arcrun#87:藏書地圖 8 個庫有 7 個顯示 0(存量沒貼庫標)
  • Leo/kbdb-graph-plugin#1:新進來的知識還是沒貼庫標(源頭沒修)
  • Leo/mira#8:daemon 一接上去,新東西會進到搜不到的抽屜

它們是同一條 ingest 路線的三段。 而 leo 給的順序把「先補存量還是先修源頭」這個爭論直接解掉了:
源頭要換成本機庫,Gitea 那條要斷掉。 所以補存量不是為了補完就好,
是為了讓「本機庫 ↔ 資料庫」對得上,好把來源切過去。

五步的意思(照他的原話,不加工)

  1. 先找到 Gitea 的庫 —— 現在的知識是從 Gitea repo 進來的,先把「有哪些庫」定出來
  2. 比照找到資料庫的東西 —— 庫裡的東西對回 KBDB 裡已經存在的 entry
  3. 依照 Gitea 的庫 locate 它在本機的位置 —— 那個庫在 leo 電腦上是哪個資料夾
  4. daemon ingest 從本機庫 —— 來源改成本機,daemon 直接讀
  5. 斷掉 Gitea ingest —— 舊來源退場

為什麼順序是這個,不能跳

第 5 步是最後才做。先斷再接=中間那段時間新知識無處可去。
而第 3 步是關鍵接縫:「同一個庫在雲端叫什麼、在本機是哪個資料夾」這個對應表現在不存在
沒有它,第 4 步的 daemon 不知道要讀哪裡、也不知道讀進來的東西該貼哪個庫標。

⇒ 所以 #87 的補標不是「順手把存量補一補」,它產出的判準就是第 3 步要用的對應表

給接手的人

三張票要一起看,不要各自開工。動之前先確認自己在做第幾步。

## 📐 leo 2026-08-12:這三張票是**同一條路線**,不是三件事 > 「知識貼標與地圖,跟 daemon 同步有關⋯⋯這就是: > * 先找到 Gitea 的庫 > * 比照找到資料庫的東西 > * 依照 Gitea 的庫 locate 它在本機的位置 > * Daemon ingest 從本機庫 > * **斷掉 Gitea ingest**」 ### 這句話收掉的模糊空間 原本三張票各自看起來像獨立問題: - `Leo/Arcrun#87`:藏書地圖 8 個庫有 7 個顯示 0(存量沒貼庫標) - `Leo/kbdb-graph-plugin#1`:新進來的知識還是沒貼庫標(源頭沒修) - `Leo/mira#8`:daemon 一接上去,新東西會進到搜不到的抽屜 **它們是同一條 ingest 路線的三段。** 而 leo 給的順序把「先補存量還是先修源頭」這個爭論直接解掉了: **源頭要換成本機庫,Gitea 那條要斷掉。** 所以補存量不是為了補完就好, 是為了讓「本機庫 ↔ 資料庫」對得上,好把來源切過去。 ### 五步的意思(照他的原話,不加工) 1. **先找到 Gitea 的庫** —— 現在的知識是從 Gitea repo 進來的,先把「有哪些庫」定出來 2. **比照找到資料庫的東西** —— 庫裡的東西對回 KBDB 裡已經存在的 entry 3. **依照 Gitea 的庫 locate 它在本機的位置** —— 那個庫在 leo 電腦上是哪個資料夾 4. **daemon ingest 從本機庫** —— 來源改成本機,daemon 直接讀 5. **斷掉 Gitea ingest** —— 舊來源退場 ### 為什麼順序是這個,不能跳 第 5 步是**最後**才做。先斷再接=中間那段時間新知識無處可去。 而第 3 步是關鍵接縫:**「同一個庫在雲端叫什麼、在本機是哪個資料夾」這個對應表現在不存在**, 沒有它,第 4 步的 daemon 不知道要讀哪裡、也不知道讀進來的東西該貼哪個庫標。 ⇒ 所以 `#87` 的補標不是「順手把存量補一補」,**它產出的判準就是第 3 步要用的對應表**。 ### 給接手的人 三張票要一起看,不要各自開工。動之前先確認自己在做第幾步。
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Leo/kbdb-graph-plugin#1