課題：同じリポジトリを 3 本 clone すると、全部同じ色のマスになる
AI を並列で動かす方法は 2 つあります。
- git worktree で作業フォルダだけ増やす — 1 件の作業ごとの使い捨て
- プロジェクトを丸ごと何本も clone する — 常設
後者を使うことがあります。acme / acme2 / acme3 と並べて、それぞれに常駐の AI を置く、という使い方です。MulmoTerminal のグリッドで、常時 3 本のうちどれかで作業しています。
マスに色を付けると見分けられるようになりますが、プロジェクトの色設定（.mulmoterminal.json）はリポジトリの中にあります。clone すれば一緒に来るので、3 本とも同じ色になります。
同じ型の機械が 3 台並ぶのと同じ状態です。工場だと誰かが号機の札を付けますが、clone した側は共有の設定を書き換えると全員の .mulmoterminal.json を書き換えてしまうので、個別に印は付けられません。
9 枚のマスのうち 3 枚が同じ顔をしていて、どの clone で作業していたかが分からなくなります。
違うべきなのは、見分けるための色だけ
ここが整理のポイントです。
プロジェクトとしては同じものなので、名前もモデルも配色の系統も同じでいい。違うべきなのは、グリッドで見分けるための色だけ。仕様書は 1 冊で、札だけ 3 枚。
共有ファイルの隣に、clone 1 本だけの設定を置く
共有の .mulmoterminal.json の隣に、.mulmoterminal.local.json を置けます。
// .mulmoterminal.json — プロジェクトの設定。
// 色も含めて単体で完結しているので、clone を 1 本しか持たない人はこれだけでよい。
// コミットして構わない
{
"name": "acme-web",
"theme": "nord",
"badgeColor": "#1b3479",
"headerColor": "#2d4ea9",
"headerTextColor": "#ffffff",
"orderPriority": 30
}
// .mulmoterminal.local.json — この clone だけ。.gitignore に入れる
{
"badgeColor": "#27b4a8",
"headerColor": "#4ed0c5",
"orderPriority": 65
}共有側が 単体で完結しているのが設計上の要点です。clone を 1 本しか持たない人は共有ファイルだけでよく、2 枚目の存在を知る必要がありません。
規則は 5 つ
1. local が勝つ。ただしキー単位で
.mulmoterminal.local.json に書いていないキーは、共有ファイルの値がそのまま残ります。上の例なら、name と theme と headerTextColor は共有側から来ます。
2. キーごと丸ごと置き換える。深いマージはしない
.mulmoterminal.local.json の headerColor は、共有側の headerColor を丸ごと置き換えます。これは意図的です。
1 キー = 1 つの意図だからです。深くマージする作りだと、「実際に効いている配色がどちらのファイルにも書いていない」状態になります。そうなると、直そうとしたときに 2 枚を見比べながら組み立てることになって、追えません。
2 つのファイルから組み立てないと分からない配色より、1 か所で読み切れるほうが予測しやすい、という選択です。
3. 検証は同じように効く
local は規則を迂回する手段ではありません。#rrggbb でない色、綴り違いのキーは、共有ファイルに書いたときと同じように落とされます。
4. 相対パスの意味も同じ
icon や sound のパスは、ファイルではなくフォルダを基準に解決されます。どちらに書いても、同じパスは同じ場所を指します。
5. どちらか片方だけでも動く
local だけの clone もあり得ますし、片方が壊れていてももう片方は生きたままです。
どちらを書き換えても、すぐ反映される
3 本並べて色を決めるときに、これが無いと毎回タブを再読み込みします。「濃すぎた、もう少し薄く」を 10 回繰り返す作業なので、即反映かどうかで体験が変わります。
AI にファイルを書かせたときは即座に効きます。エディタで手書きしたときはタブを再読み込みします。これは共有側も local 側も同じです。
.gitignore に 1 行だけ、先に足す
.mulmoterminal.local.json は共有してはいけないので、.gitignore に入れます。
# .gitignore
.mulmoterminal.local.jsonこれが入っていないと、git から見て未追跡ファイルとして現れます。commit で混ぜ込んでしまうと、clone した全員の色が揃うという元の問題に戻ります。
worktree も、同じファイルに書く
MulmoTerminal で worktree を切ると、プロジェクトの設定のコピーが自動で worktree に書き込まれます。その書き込み先が .mulmoterminal.local.json です。
これで worktree の git status が汚れません（.gitignore に入っているので）。
このファイルは 2 つの役目を兼ねています。
- 手で書くとき → clone 1 本だけの色
- 自動で書かれるとき → worktree 用の色（元のプロジェクトから色相を 12 度ずらしたグラデーション）
どちらも「共有設定の上に重なる、この checkout 1 本だけのもの」なので、同じ場所でよい、という整理です。
worktree 側に既に .mulmoterminal.local.json がある場合、MulmoTerminal は上書きしません。手で書いた色があるならそれが答えなので、上書きする筋合いが無いからです。
効いていないときの調べ方
Settings → Directory settings を開くと、ディレクトリごとに次が出ます。
- 効いている値（色は見本付き）
- どのファイル由来か（グローバル / 共有 / local）
- 書式が不正で捨てられたキー
- このアプリが読まないキー（綴り違いなど）
変えたのにマスの色が違うときの答えは、たいていここに出ます。「共有側を編集したのに、.mulmoterminal.local.json が同じキーを持っていた」が一番多いパターンです。
2 枚あることを忘れるのがこの仕組みの唯一の弱点なので、画面がそれを言ってくれるのは助かります。
使ってみる
既存の MulmoTerminal があれば追加のインストールは不要です。初めての方は MulmoTerminal 完全ガイド の「使い方 3 ステップ」から。
動作確認の最小シナリオ
- 対象のリポジトリの
.gitignoreに 1 行足す:.mulmoterminal.local.json - 共有ファイルの隣（プロジェクトフォルダ直下）に
.mulmoterminal.local.jsonを作る - 中身を書く（共有側と違う色を 1〜2 つ）:
{ "badgeColor": "#27b4a8", "headerColor": "#4ed0c5" } - その clone で開いているマスのヘッダーが新しい色になり、他の clone は共有の色のままなら成功
やめるときは、.mulmoterminal.local.json を消せば共有ファイルの色に戻ります。
まとめ
- 同じリポジトリを何本も clone すると、設定ファイルも一緒に来るので 3 本とも同じ色になる
- 違うべきなのは、見分けるための色だけ。仕様書は 1 冊で札だけ 3 枚
.mulmoterminal.local.jsonを共有ファイルの隣に置くと、clone 1 本だけの設定になる- キー単位で上書きし、深いマージはしない。実際に効いている値を 1 か所で読めるため
.gitignoreに 1 行足すのが前提。worktree も自動で同じファイルに書き込む- 効いていないときは Settings → Directory settings で、どのファイル由来かを確認できる
関連: MulmoTerminal 公式ガイドの .mulmoterminal.local.json / MulmoTerminal の git worktree 隔離 / MulmoTerminal でプロジェクトごとに色と名札を付ける
