專案與工作區模型

MindMux 圍繞一個本地專案根目錄來組織。程式碼層面有時會把它實現成工作區（workspace），但面向使用者時，更準確的概念是專案（project）：一個承載知識、會話、任務和外部輸入的持久工作單元。

兩層儲存結構

從宏觀上看，一個專案包含兩個彼此分離的層級：

• brain/：儲存可持久、可審查的專案知識
• 本地執行狀態：儲存會話、任務和專案級設定

這種分離是刻意設計出來的。

brain/：持久知識層

brain/ 的目標是跨會話、跨機器、跨執行時持續存在。它應該具備這些特點：

• 人類可讀
• 方便 Git 管理
• 容易備份
• 即使脫離應用也容易檢視

brain 中通常會包含：

• background.md、architecture.md、roadmap.md 等 root docs
• pages/：帶有生命週期狀態的結構化知識頁面
• mindmux.json 等後設資料

執行狀態層

本地執行狀態儲存的是通常不應該納入原始碼控制的應用狀態，比如：

• 會話日誌和後設資料
• 任務狀態
• 專案級設定

這樣執行期的狀態記錄就不會和長期專案知識混在一起。

為什麼這種拆分重要

MindMux 對什麼應該進入長期專案記錄有明確偏好。

適合放進 brain/ 的內容包括：

• 穩定的產品上下文
• 架構決策
• 設計理由
• 長期可複用的參考資料

適合作為本地執行狀態儲存的內容包括：

• 正在進行的會話記錄
• 任務執行期事件
• 臨時性的執行後設資料

專案命名

MindMux 會把一個很小的後設資料檔案放在 brain/mindmux.json 裡，讓專案擁有穩定的顯示名稱。這個名稱會隨 brain 一起移動和保留。

brain 位置的靈活性

預設模式是“專案大腦放在專案內部”。應用也支援覆蓋專案大腦根目錄等能力，但原則不變：整個工作上下文應該圍繞一個穩定的專案大腦來組織。

實踐建議

對大多數團隊來說，最合適的起步方式是：

1. 把 brain/ 放在倉庫內，或者放在專案根目錄旁邊。
2. 讓執行狀態保持本地化且不納入版本控制。
3. 把專案大腦當成共享專案記憶，而不是隨手記事本。

這種佈局最符合 MindMux 內部設計，也讓整個產品模型更容易理解。