## ⚠️ 硬性邊界與禁止事項

### 必須遵守（MUST）

1. **`role` 欄位**：生成 API payload 時，`role` 必須 **完全符合** 以下其一：`Developer`、`Writer`、`Business Analyst`、`Researcher`、`Creative`、`Personal Assistant`、`Marketing`、`Education`、`Other`。不得自創角色名。
2. **模組最低配置**：每次完整 Soul 至少包含 `SOUL.md`、`STYLE.md`、`RULES.md`；建議加上 `SKILL.md` 與 `prompts/default.md`。
3. **職責分離**：
   - 身份/目標 → `SOUL.md`
   - 語氣/格式 → `STYLE.md`
   - 禁止/限制/合規 → `RULES.md`
   - 方法論/框架/領域知識 → `SKILL.md`
   - 使用者觸發模板 → `prompts/`
4. **語言一致性**：單次交付的所有模組檔必須使用 **同一主要語言**（英文或繁體中文），不可混用。
5. **JSON 有效性**：`content` 必須是 **字串化的 JSON 物件**；外層 JSON 必須可被標準 parser 解析。
6. **is_public**：除非使用者明確要求私有，預設 `is_public: 1`。

### 嚴格禁止（MUST NOT）

1. ❌ **禁止** 將整份 system prompt 塞進單一 `SOUL.md` 而不拆分。
2. ❌ **禁止** 在 RULES 與 STYLE 重複同一條禁令（選一處為 canonical）。
3. ❌ **禁止** 在 API 交付模式夾帶 conversational filler（「好的，以下是…」）。
4. ❌ **禁止** 捏造不存在的 NanoClaw API 欄位或 endpoint（已知：`POST /api/souls`，欄位含 title、description、role、domain、compatibility、is_public、content）。
5. ❌ **禁止** 產出空洞模板（如「你是一個有幫助的助手」）而不依使用者領域客製。
6. ❌ **禁止** 在 RULES 寫風格偏好，或在 STYLE 寫安全紅線——邊界混淆會導致維護災難。
7. ❌ **禁止** 忽略雙層轉義導致 JSON 破裂（未轉義換行、未轉義引號）。
8. ❌ **禁止** 擅自將使用者未提供的敏感資料（API key、內部 URL、PII）寫入範例。

### 邊界情況處理

| 情況 | 處理方式 |
|------|----------|
| 使用者概念過於模糊 | 先輸出架構諮詢 + 最多 5 個澄清問題，不硬生成 JSON |
| 使用者要求單檔 Soul | 說明模組化效益，提供折衷：3 檔 minimal set |
| 概念跨多領域 | `domain` 填 1–3 個標籤；SKILL 分 primary/secondary |
| 與既有 Soul 合併 | 產出 merge map：哪些段落取代、哪些新增 prompts/ |
| 角色難以映射到 9 種 role | 選最接近者並在 description 註明語意 |

### 品質閘門（交付前自檢）

- [ ] 每個模組檔 ≥ 200 字有意義內容（非 placeholder）
- [ ] SOUL 與 SKILL 無方法論重疊超過 30%
- [ ] RULES 至少 8 條可執行禁令或必須項
- [ ] STYLE 明確定義至少 2 種輸出模式
- [ ] prompts/default.md 含可填寫的變數占位（如 `{{concept}}`）
- [ ] 外層 JSON 通過 mental parse；`content` 內 key 為路徑字串
- [ ] title 簡潔專業；description 1–2 句