從 Obsidian Vault 到 DeMinds 工作文件
Obsidian Vault 往往不是單一 Markdown 文件，而是一組由目錄、首頁、Wiki Link、附件與寫作習慣共同形成的知識結構。DeMinds 處理這類內容時，並不嘗試接管整個 Vault，也不把自己變成另一個 Obsidian。
更準確地說，DeMinds 做的是：把使用者明確選擇的 Vault 內容，歸一為一份可閱讀、可編輯、可預覽、可匯出的 Markdown 工作文件。
1. 先識別入口，而不是盲目開啟 README
一般 Markdown 文件包通常會使用 README.md、index.md 或與包名相同的 Markdown 作為入口。但 Obsidian Vault 經常有自己的首頁，例如 Home/Home.md，並且可能透過 .obsidian/app.json 或 Homepage 外掛設定指向它。
DeMinds 會優先識別這些 Obsidian 首頁訊號。這樣，使用者開啟 Vault 時看到的是更接近原 Vault 閱讀路徑的推薦入口，而不是被根層 README.md 誤導。
這一步的重點不是「自動匯入整個 Vault」，而是協助使用者從正確的位置開始選擇。
2. 由使用者明確選擇要開啟的文件
Obsidian Vault 裡的每個 Markdown 都可能有自己的用途：有些是首頁，有些是目錄頁，有些是草稿、範本、歸檔或日記。DeMinds 不會遞迴跟隨所有 Wiki Link，也不會把整個 Vault 自動拼成一篇長文件。
使用者可以在 Document Chooser 中選擇一個或多個 Markdown 文件：
- 單選時，DeMinds 會將該文件作為工作文件開啟
- 多選時，DeMinds 會依照使用者選擇或 Vault 結構生成新的 baseline
- 取消時，不建立工作區，也不寫入快照
這種設計讓 DeMinds 保持清楚邊界：它讀取 Vault，但不索引整個 Vault；它生成工作文件，但不原地改寫使用者的 Obsidian 目錄。
3. 保留 Vault 結構，而不是拍平所有文件
當使用者選擇多個文件時，DeMinds 可以依照 Vault 結構生成工作文件。例如 Areas/Research/Methods/Literature Review.md 不會被簡單放進一個扁平列表，而是保留它在 Vault 中的組織語義。
這對閱讀體驗很重要。Obsidian 的目錄結構本身往往就是知識組織方式：Product、Package、Obsidian、Scenarios 等目錄，不只是資料夾，而是內容邊界和上下文。
DeMinds 的歸一化結果應讓這些結構繼續可見，同時把它們收斂到一份 Markdown 工作文件中，便於在導圖和 Markdown Preview 中繼續閱讀。
4. 靜態處理 Wiki Link 與 Wiki Embed
Obsidian 的 [[Wiki Link]] 和 ![[Wiki Embed]] 是 Vault 內部閱讀體驗的重要部分。但 DeMinds 不執行 Obsidian 外掛，也不展開整個連結圖。
因此，DeMinds 採用靜態歸一化策略：
- 已選擇且能唯一解析的 Wiki Link，可轉換為工作文件內的內部跳轉
- 未選擇、缺失或歧義的 Wiki Link，降級為可讀文字
- 圖片類 Wiki Embed 會轉換為標準 Markdown 圖片引用
- 筆記類 Embed 不遞迴展開，只保留可讀引用
這樣做的好處是：內容可讀，結構可控，匯出後仍然是普通 Markdown，而不是依賴 Obsidian 執行時的專有狀態。
5. 資源路徑需要保持自洽
Markdown 文件包和 Obsidian Vault 中經常出現同名資源。例如不同目錄下都可能有 a.png，或者某個文件引用 images/a.png，另一個文件引用 assets/a.png。
如果只按檔名合併，圖片很容易串圖。DeMinds 需要按路徑建立資源閉包，只複製使用者選擇文件直接引用、實際存在且在安全邊界內的資源。
在合併 baseline 中，資源路徑會被重寫到可解釋、可匯出的相對路徑下。這樣匯出後的 Markdown 包仍然自洽，可以脫離 DeMinds 繼續查看和維護。
6. Package 能力是 Obsidian 支援的基礎
Obsidian Vault 支援並不是孤立能力。它建立在 DeMinds 對 Markdown Package 的基礎能力之上：入口推薦、Document Chooser、多選合併、資源閉包和路徑保持。
普通 Markdown Package 預設更適合「順序合併」；Obsidian Vault 預設更適合「Vault 結構」。兩者共享底層原則：圍繞使用者選擇生成工作文件，而不是複製整個文件包。
7. DeMinds 的價值：把結構變成可繼續工作的文件
DeMinds 的目標不是取代 Obsidian，也不是把所有知識庫功能搬進應用程式裡。它更適合這樣的工作流：
- 從 Obsidian、網頁、AI 對話或文件包中取出需要繼續處理的內容
- 歸一為 Markdown 工作文件
- 在導圖中查看結構
- 在 Markdown Preview 中閱讀
- 繼續編輯、整理和匯出
對於長期知識資產來說，這種方式的價值在於：內容仍然是 Markdown，結構可以被導圖化，資源路徑保持可遷移，工作結果不被鎖死在單一工具裡。
8. 一個典型場景：整理 AI 對話
很多 AI 對話在生成時很有價值，但長期保存後往往變成難以維護的長文字。DeMinds 可以把這類內容整理成結構化 Markdown，再進一步匯出或進入知識庫。
這個流程和 Obsidian Vault 的處理邏輯是一致的：DeMinds 關注的不是「來源是什麼工具」，而是能否把內容變成可讀、可編輯、可遷移的結構化 Markdown。
結語
「從 Obsidian Vault 到 DeMinds 工作文件」不是一次完整遷移，也不是對 Obsidian 的替代。
它更像一次結構化閱讀：DeMinds 識別入口，讓使用者選擇內容，保留 Vault 結構，靜態處理連結與附件，並生成一份可以繼續工作的 Markdown 文件。
這也是 DeMinds 的核心定位：本地優先的 Markdown + 導圖工作區，讓知識資產保持可讀、可編輯、可遷移。