Workspace 設定

在設計 OpenPress 的設定系統時，我們面臨一個常見的難題：如何既保持設定的靈活性，又避免創造出一個龐大、複雜且難以維護的全域設定檔？

為了解決這個問題，OpenPress 採用了「職責分離」與「慣例優於設定」的雙重策略。我們將工作區的設定明確地切割為三個不同性質的領域。

1. 文件中繼資料 (Metadata)：歸屬於元件

關於文件本身的屬性——例如這是一份什麼樣的文件、它的標題是什麼、它使用的紙張幾何尺寸為何——這些資訊被設計為依附在特定的出版物（Press）元件上。

為什麼這樣設計？ 因為在一個工作區內，可能會同時存在多份不同的出版物（例如一份直式的提案報告與一份橫式的發表簡報）。如果將這些資訊放在全域設定中，很快就會變得難以區分與管理。透過將中繼資料作為 React 元件的屬性（Props），我們確保了設定總是緊密跟隨其所描述的對象，實現了完美的封裝。

2. 操作設定 (Operations)：歸屬於專案配置

有些設定與文件的內容無關，而是與「工作區如何運作」有關，例如：這份文件最終要部署到哪一個代管平台？部署時需要哪些特定的平台參數？

這些操作層級的設定被放置在標準的專案設定檔（如 package.json）中。

為什麼這樣設計？ 這類設定通常在專案的生命週期中只會設定一次。更重要的是，像部署腳本或持續整合（CI）工具這類外部系統，需要在不執行任何 React 程式碼或編譯文件的情況下，就能夠快速讀取這些環境資訊。將其放在標準設定檔中，確保了與外部工具列的無縫整合。

3. 目錄結構：慣例優於設定

對於檔案應該放在哪裡（例如：主題樣式在哪裡？共用元件放在哪裡？編譯後的輸出會去哪裡？），OpenPress 刻意不提供太多自訂的空間，而是採用了固定的路徑慣例。

為什麼這樣設計？ 這看似減少了自由度，實則帶來了巨大的好處。當所有的 OpenPress 專案都遵循相同的檔案結構時，AI Agent 就能夠在沒有任何額外指導的情況下，精確地知道該去哪裡尋找資源或寫入檔案。這種標準化也極大地降低了人類作者在不同專案間切換時的認知負荷。這些路徑慣例並非可以隨意調整的旋鈕，而是產品核心架構的一部分。