---

name: parallel-agent-repo-safety description: 複数のAIエージェントセッションが同じリポジトリを共有している時に、他セッションの作業を壊さず自分の検証を完了させる手順。共有作業ツリーでの事故防止・隔離検証・配布物の「配布可」判定までを型にしたもの。

共有リポジトリで並行AIセッションが事故を起こさないための型

複数のAIエージェントセッション（別ウィンドウ・別タスク）が 同じ作業ツリーを共有 している時に使う。 共有ツリーは「自分だけが触っている」という暗黙の前提が崩れる場所で、事故は静かに起きる。

前提となる失敗モード（実際に起きたもの）

1. git commit -a / git add -A が他セッションの作業を巻き込む。 他セッションが stage 済みだったファイルが自分のコミットに同梱され、レビューを経ずに デフォルトブランチへ push される。コミットメッセージと中身が一致しないので後から追跡もしにくい。
2. git checkout -- <file> で他セッションの未コミット編集を消す。 「自分の作業と無関係な差分だから戻そう」は、相手が今まさに書いている途中の可能性がある。
3. 引き継ぎメモの前提が古い。 「未コミットで残っている」と書かれた成果が、実は別セッションによって既にマージ済み。 そのまま作業すると同じ実装を二重に作る／既にある物を壊す。
4. テストが実行者の本物の設定ディレクトリを書き換える。 ホーム配下の設定を読む処理をテストすると、テストが実行者の設定を破壊する。

手順

1. 着手前に「前提が生きているか」を確認する（最重要）

引き継ぎメモや依頼文の前提を信じず、リポジトリの事実で確認する。

git -C <repo> fetch origin -q
git -C <repo> log --oneline -10
git -C <repo> ls-files | grep -i <対象の特徴語>      # 既にコミット済みでないか
git -C <repo> show HEAD:<file> | grep -n '<新機能のマーカー>'

「未コミットの成果を載せる」タスクは、まず既にマージ済みでないかを疑う。 マージ済みだったら、やることは「実装」ではなく「検証」に変わる。ここで方針転換できないと二重実装になる。

2. 他セッションが稼働中かを mtime で判定する

git -C <repo> status --porcelain
stat -c '%y %n' <差分のあるファイル...>   # macOS は stat -f '%Sm %N'
date

mtime が数分以内なら、そのファイルは今誰かが編集中とみなす。触らない。 判定を強くしたいなら30〜60秒待って git status を取り直し、状態が変化するかを見る。 UU（未解決マージ）→ M （staged）のような遷移が観測できたら、相手が能動的に操作している確定的な証拠。

さらに、以下も他セッションの作業が潜む場所なので勝手に消さない。

git -C <repo> stash list      # 他セッションの退避
git -C <repo> worktree list   # 他セッションの隔離ツリー

3. 触ってよい範囲を先に宣言する

自分の担当ファイルを列挙し、それ以外は読み取り専用と決めてから手を動かす。 共有ツリーで許可される破壊的操作は「自分が作ったファイルへの書き込み」だけ。

禁止（共有ツリーでは例外なし）:

git add -A
git add .
git commit -a
git checkout -- <他セッションのファイル>
git stash            # 他セッションの未コミット分をまとめて退避してしまう
git reset --hard

必須（対象を1つずつ明示する）:

git add <path1> <path2>          # ワイルドカードもディレクトリ指定も使わない
git -C <repo> diff --cached      # stage した中身が自分の物だけか目視

4. 長い作業・ブランチ切替は隔離ツリーで行う

共有ツリーの HEAD を切り替えると、他セッションの作業中ファイルが一斉に書き換わる。 ブランチを切る作業は必ず分離する。

git -C <repo> worktree add <一時ディレクトリ>/wt-<用途> origin/<デフォルトブランチ>
cd <一時ディレクトリ>/wt-<用途>
# ここで自由に commit / branch してよい

既存の隔離ツリーが目的のコミットを指しているなら、それを再利用してよい（git worktree list で確認）。

5. テストは設定ディレクトリを差し替えて走らせる

ホーム配下の設定を読む処理は、環境変数でホームを差し替えられる作りにする。 テストは一時ディレクトリを指定し、実行者の本物の設定を絶対に書き換えない。

実装側:

const home = process.env.APP_HOME || os.homedir();

テスト側:

TMP=$(mktemp -d); mkdir -p "$TMP/.config"
APP_HOME="$TMP" node <tool> <args>
ls -la "$TMP/.config"        # 一時側に書かれたこと
ls -la "$HOME/.config"       # 本物が無変更であること(mtimeで確認)

「テストが通った」より「本物が汚れていない」を先に確認する。 一時側にファイルが出来ていて、かつ本物側の mtime が変わっていない、の両方が揃って初めて隔離が効いている。

6. 「動いた」の判定は経路ごとに分ける

配布物・共有ツールは、次の3つが別々に壊れる。まとめて「OK」と言わない。

層	確認すること	確認方法
コード	単体で動くか	実際に実行する。--help / 正常系 / 異常系
登録	実行される状態にあるか	設定ファイルに登録されているか、自己修復リストに載っているか
配布	他マシンに届くか	配布URLを取得して手元の内容とハッシュ比較

コードを書いただけでは動かない。 自動起動の仕組み（フック・スケジューラ・常駐）は 「実装した」と「登録された」と「他マシンへ届いた」が全部別問題で、どれか1つ欠けると静かに何もしない。 新しい自動起動処理を足したら、登録経路と自己修復リストの両方に載っていることを必ず確認する。

7. 配布は「今このURLを踏んだら何が返るか」で判定する

配布URLはCDNキャッシュを挟むため、push直後は旧版が返ることがある。 配布者側が実物を取得して確認する。利用者に「古かったら言って」と押し付けない。

CB=$RANDOM$RANDOM   # キャッシュバスター
for f in <対象ファイル...>; do
  code=$(curl -s -o /tmp/r.$$ -w '%{http_code}' "<配布ベースURL>/$f?cb=$CB")
  local_hash=$(git show HEAD:"$f" | md5sum | cut -d' ' -f1)
  remote_hash=$(md5sum < /tmp/r.$$ | cut -d' ' -f1)
  [ "$local_hash" = "$remote_hash" ] && s=一致 || s='★不一致(旧版キャッシュ)'
  printf '%-40s HTTP %s %s\n' "$f" "$code" "$s"
done
rm -f /tmp/r.$$

ハッシュ一致だけでは不十分な場合は、配信された中身そのものに新機能のマーカーが載っているかを grep する。

curl -s "<配布ベースURL>/<file>?cb=$CB" | grep -c '<新機能のマーカー文字列>'

配布URLはコミットハッシュで固定しない。固定すると改修ごとに利用者へURLの貼り替えを強いる。 デフォルトブランチを指す安定URLにし、版の揺れは上記の検証で配布者側が吸収する。

8. 秘匿値を扱うツールは「値が出ないこと」まで確認する

秘匿値を検査・送信するツールは、エラー表示の中に秘匿値そのものを出してしまうのが典型的な穴。 故意に汚したダミーファイルを食わせて、出力に伏字が入るかを確認する。

cat > dirty.md <<'EOF'
APIキー: sk-<ダミーの32文字>
Webhook: https://<チャットサービス>/api/webhooks/<ダミーID>
EOF
<tool> --file dirty.md --scan     # 検出されること かつ 値が伏字であること

送信を伴うツールは、検出時に送信せず退避して非0で終わることを実際に確認する。 「検出できた」と「送信を止めた」は別の保証。

完了報告の書き方

• 触らなかったファイルを明示的に列挙する（「他セッションの作業なので除外」と理由付きで）。
• 前提が違っていたら、作業結果より先にそれを書く。 「依頼は実装だったが既にマージ済みだったので検証に切り替えた」は隠さず最初に言う。
• 「たぶん動く」で完了と言わない。実行したコマンドと観測した出力で語る。

チェックリスト

• 引き継ぎメモの前提を git log / ls-files で検証した
• git status と mtime で他セッションの稼働を確認した
• add -A / commit -a / checkout -- / stash を使っていない
• stage した内容を diff --cached で目視した
• ブランチ操作は隔離ツリーで行った
• テストは設定ディレクトリを差し替え、本物が無変更であることを mtime で確認した
• コード・登録・配布の3層を別々に確認した
• 配布URLを実際に取得してハッシュとマーカーを確認した
• 秘匿値が出力に漏れないことを、汚したダミーで確認した
• 触らなかったファイルを報告に列挙した