# feat #1430 — `.mulmoterminal.local.json`

同じリポジトリを何本も clone して並行作業する運用（`mulmoterminal` / `2` … `6`、
`mulmoclaude` / `2` … `5`）では、**プロジェクトとしての設定は全 clone 共通**なのに、
**色と grid 順だけ clone ごとに違う**。1ファイルしか無いと共通部分が clone の数だけコピーされ、
片方だけ直して食い違う。

- `.mulmoterminal.json` — リポジトリの設定。**色も含めて単体で完結**（clone を1本しか持たない人は
  これだけで色が付く）。コミットしてよい
- `.mulmoterminal.local.json` — その clone だけの上書き。gitignore する

## 合成規則: トップレベルのキー単位で置き換え

深いマージにしない。**1キー = 1つの意図**だから。7つの色は元々別キーなので「この clone は緑」は
これで素直に書ける。`colors`（xterm パレット）を一部だけ上書きしたい clone は、そのブロックを
丸ごと書けばよく、部分マージの規則を覚える必要がない。2ファイルから組み立てないと分からない
パレットより、1か所で読み切れる方が予測しやすい。

## 実装の中心: 生の JSON をマージしてから1回だけ検証する

二度読んで結果の `DirConfig` を合成する、ではない。

```
mergedDirConfigRaw(base) -> { raw: {...shared, ...local}, localKeys }
loadDirConfig           -> 既存のフィールドパーサに merged raw を通す
```

こうすると:

- 値の規則（色の形式、フォントの正規化、パスの封じ込め）が**1か所に書かれたまま**になる。
  合成側に「null をどう扱うか」を書き直すと、そこが2つ目の規則になる
- 相対パス（`icon` / `sound` / `addDirs`）は**どちらのファイルに書かれていても同じディレクトリ基準**。
  ファイル基準ではなくディレクトリ基準なのが正しく、マージ後に解決すれば自動的にそうなる
- 各ファイルは独立して寛容（欠落・読めない・オブジェクトでない → 何も寄与しない）。
  片方が壊れて**もう片方まで巻き添えにしない**のは、「色がおかしい」と「全部戻った」の違い

## あわせて必要だったもの

- **ライブリロード**: `dirConfigWriteTarget` を両ファイルで発火させる。ユーザーが一番よく触るのは
  自分の clone の local ファイルで、共有ファイルだけ見ていると「いま変えた設定が反映されない」になる
- **設定プレビュー**: `localFile` と `source.local`（local が持っていったキー）を返す。
  2ファイルになった以上「効いているか」だけでなく**「どちらが勝ったか」**が必要で、
  「変えたのにセルが違う」の答えはたいていもう片方のファイルが勝っていること
- **worktree 継承**: マージ後の値から派生する（worktree は「その clone の見た目」を継ぐべき）。
  書き出すのは worktree 側の `.mulmoterminal.json` 1本のまま

## テスト

合成規則（共有を残す / local が奪う / 片方だけ）、オブジェクト値は丸ごと置換、local の値も検証を通る、
相対パスの基準、片方が壊れたときの寛容さ、ライブリロードの発火条件、プレビューの両パス報告と
local だけが持つキーの分類、worktree がマージ後から派生すること。

## ドキュメント

README、`docs/guide/{en,ja}/config.md`、`mulmoterminal-dirs` の SKILL.md。
スキルには「複数 clone を見つけたらこの形にする」「共有ファイルは色まで含めてフルにする
（1本しか持たない人が色無しになるので、共通部分だけに削らない）」「local は gitignore」を書く。
