昨天把 llm-wiki 的 Schema 訂好了，規則有了，接下來準備資料來源。

Raw Sources 內容選擇

這次我先把系統架構、部署設定、資料庫 migration、監控與告警設計整理到 sources/architecture/。

這些資料會成為 Agent 後續整理 Wiki 和判斷弱點時使用的原始依據：

• docs/architecture.md：系統架構、服務依賴關係與悲觀鎖設計。
• CLAUDE.md / README.md：專案背景、本機啟動方式與技術架構說明。收錄後分別命名為 lite-bank-CLAUDE.md 與 lite-bank-README.md。
• helm/litebank/：K8s 實際部署使用的 values 與 templates。
• db/migration/：資料庫 schema 與初始資料。
• docs/sre/ / grafana/：SLO、告警設計與 Grafana dashboard。

除了這些系統資料，後續完成的混沌實驗也會成為 Raw Sources 的一部分。每次實驗使用的 YAML、執行結果與監控證據，都會放進 sources/experiment-runs/。

目前先從架構與部署資料開始，讓 Agent 建立對系統的初步認知。後續實驗跑得越多，可以參考的原始證據也會跟著累積。

前面提到的 Raw Sources 主要是架構、部署與實驗資料，那專案程式碼要不要也整包複製進 sources/？

專案的 Java 原始碼很多，全部複製進來會增加資料量，Agent 也會讀到很多目前用不到的內容。因此，程式碼先留在原本的 repo。

但程式碼不在這裡，Agent 後面要怎麼知道程式碼實際寫了什麼？

這個問題先留到後面的實作。等到分析特定 service 時，再來說明 Agent 怎麼讀取需要的程式碼，並把找到的內容整理進 Wiki。

不過，專案程式碼會持續迭代。今天看到的內容，過幾天可能已經改掉。要怎麼確保 Agent 之後還能讀到這次準備 Raw Sources 時的版本？

manifest.json 說明

Karpathy 原本介紹的 llm-wiki 沒有說明 Raw Sources 的版本要怎麼管理。為了讓後面整理出的系統知識與弱點都能回頭查證，我在 sources/architecture/ 加入一份 manifest.json。

它會記錄來源 repo、使用的 commit、建立 snapshot 的時間，以及這次收錄和沒有收錄的檔案。即使來源 repo 後來繼續更新，我們仍然可以確認 Agent 當時根據哪一版資料整理 Wiki。

以下擷取幾個主要欄位：

{
  "snapshot_id": "snapshot-003",
  "snapshot_time": "2026-07-10T00:36:53+08:00",
  "target": "lite-bank-demo",
  "source": {
    "repo": "lite-bank-demo",
    "path": "/path/to/lite-bank-demo",
    "branch": "main",
    "commit_hash": "6e9bedc763e077c8792717cc5fad6c5049f881da"
  },
  "files": [
    {
      "src": "docs/architecture.md",
      "dst": "docs/architecture.md",
      "role": "主架構文件"
    },
    {
      "src": "helm/litebank/",
      "dst": "helm/litebank/",
      "role": "K8s 部署設定"
    }
  ]
}

這幾個欄位分別處理不同問題：

• snapshot_id：這一批 Raw Sources 的版本編號。
• snapshot_time：建立 snapshot 的時間。
• target：這次建立 Raw Sources 的目標系統，本次是 lite-bank-demo。
• source：來源 repo、branch 與 commit hash。
• files：實際收錄了哪些檔案，以及每份資料的用途。

完整的 manifest.json 還有三個重要欄位：

• services_in_scope：列出這次要建立 Wiki 頁面與掃描弱點的 services，本次共有 10 個。
• services_excluded：記錄刻意排除的項目與原因，本次排除前端 dashboard。
• not_captured：記錄這次沒有收錄的資料，Java 原始碼目前列在這裡。

Helm chart 整包收錄原因

前面提到，Java 原始碼先留在原本的 repo。至於 Helm chart，這次我選擇把 helm/litebank/ 完整複製到 Raw Sources。

主要原因是這次只想先驗證 llm-wiki 的流程。Helm chart 的目錄規模較小，而且 values、templates 與 migration 會互相引用。完整保存比較容易保留當下的部署設定，也能避免挑選檔案時漏掉關聯內容。

當然，Helm chart 也會持續變更。所以後續應該用 snapshot 管理。每次更新 Raw Sources 時，重新保存當下的 Helm chart，並在 manifest.json 記錄對應的 commit，避免不同版本的部署設定混在一起。

所以這是我在這次測試中先採用的做法。之後專案規模變大，或需要更頻繁地更新資料來源時，還要再調整 Raw Sources 的收錄方式。

Raw Sources 目錄結構

最後整理一下目前的 sources/。以下省略部分檔案，只保留主要目錄與這篇提到的內容：

llm-wiki/
└── sources/
    ├── architecture/
    │   ├── manifest.json
    │   ├── lite-bank-CLAUDE.md
    │   ├── lite-bank-README.md
    │   ├── docker-compose.yml
    │   ├── docs/
    │   │   ├── architecture.md
    │   │   └── sre/
    │   ├── db/
    │   │   └── migration/
    │   ├── helm/
    │   │   └── litebank/
    │   └── grafana/
    │       ├── alerting/
    │       └── dashboards/
    └── experiment-runs/

Raw Sources 目前分成兩類：

• architecture/：保存系統架構、部署設定、資料庫 migration、監控與告警設定。
• experiment-runs/：保存後續實驗使用的設定、執行結果與監控證據。

現在 experiment-runs/ 還是空的。等後面真的跑過實驗，再把當時使用的 YAML、數據與報告放進來。

結論

到這裡，sources/architecture/ 已經放好架構、部署、資料庫與監控資料，manifest.json 也記錄了這批資料的來源版本。

專案程式碼目前先留在原本的 repo，後續完成的實驗資料則會放進 experiment-runs/。這些資料會成為 Agent 之後整理 Wiki 與分析系統時使用的原始依據。

Raw Sources 準備好後，照理說下一步就可以開始 Ingest。不過這個專案後面還會加入弱點掃描、實驗設計與故障注入，這些工作由外層的 chaos-agent 負責。

所以正式開始操作前，下一篇先說明 llm-wiki 與 chaos-agent 各自負責什麼，避免後面把知識整理和實驗操作混在一起。

今天就先寫到這，我們明天見！