PJR-P7HY 1つの項目が複数リポジトリを変更する場合の統合を扱う

1. 概要

別リポジトリ構成で1つの SpecDojo が複数のプロダクトリポジトリを管理する場合、単一の登録簿項目が 複数のプロダクトを同時に変更する状況が生じうる。この場合の統合順序と回復手順が定まっていない。

app1/              プロダクト
app1-marketing/    マーケティング
app1-specdojo/     SpecDojo（両方を管理）

複数プロジェクトの管理そのものは現状の設計で成立する。specdojo.config.json の projects は 複数を保持し、パスは base_path を起点にプロジェクトごとへ分かれる。すべてのコマンドが --project <id> を受け取る。

未対応なのは、1つの項目が複数リポジトリを跨いで変更する場合だけである。

2. 課題

prj-0001:pjr-qhka-docs-structure-detached-unit は、docs とソースの2リポジトリを扱う二重 worktree を整理した。統合順序をソース先行とすることで部分状態が1通りに定まり、回復は統合段の 再試行で足りると結論した。

プロダクトが複数になると、この前提が崩れる。

論点	プロダクト1つ	プロダクト複数
worktree の隔離	2 組（docs と src）	3 組以上
統合の順序	src の次に docs	どの src を先にするか
親検証	実行先が 2 つ	リポジトリごとに異なる
部分状態	1 通り	組み合わせの分だけ増える

プロダクトが2つの場合、統合の失敗パターンは「1つ目で失敗」「2つ目で失敗」「docs で失敗」の 3通りになる。それぞれで統合済みの範囲が違うため、回復手順も分かれる。

3. 優先度が低い理由

実務上この状況は稀と考えられる。プロダクトとマーケティングの成果物を同一項目で変更する場面は 限定的である。項目をプロジェクト単位に分ければ回避でき、その方が変更の意図も明確になる。

そのため本項目は、複数プロダクトを実際に管理する必要が生じてから着手してよい。先行して実装 しても、要件が想像で決まり過剰になる恐れがある。

4. 完了条件

• 1つの項目が複数のプロダクトリポジトリを変更する場合の統合順序が定まっている。
• 各失敗パターンで統合済みの範囲と回復手順が示されている。
• 親検証をリポジトリごとに割り当てられる。
• 部分状態での item_status が定まっている。
• 実際に複数プロダクトを管理する構成で動作を確認している。

5. 検討事項

• そもそも1つの項目で複数リポジトリを変更させるべきかを判断する。禁止して項目の分割を求める 方が、統合の複雑さを持ち込まずに済む。その場合は検出と警告の実装になる。
• 統合順序の決め方を定める。プロジェクトの宣言順、依存関係、優先度のいずれで決めるか。
• 部分状態の粒度を決める。どのリポジトリまで統合したかを記録する必要がある。

6. 作業内容

No	作業	担当	状態	メモ
1	複数リポジトリ変更を許すかを判断する	ARC	done	禁止する選択肢も検討する
2	許す場合の統合順序を定める	ARC	done	宣言順か依存関係か
3	失敗パターンごとの回復手順を定める	ARC	done	統合済みの範囲を記録する
4	親検証のリポジトリ別割り当てを実装する	ARC	done	prj-0001:pjr-qhka-docs-structure-detached-unit と共通
5	実構成で動作を確認する	ARC	done	複数プロダクトの構成を用意する

7. 対応結果

本項目では実装を行っていない。起票（2026-09-06）の後、次の項目で完了条件をすべて満たしたため、orchestrator が対応関係を確認して完了とした（2026-10-07）。

完了条件	満たした項目	根拠
統合順序が定まっている	prj-0001:pjr-5822-multi-repo-item-design とその実装	specdojo:docs-structure-guide の「複数リポジトリの worktree と統合順序」。事前検査で全リポジトリの統合可否を確かめ、宣言順にプロダクトを統合してからプロジェクトを統合する
各失敗パターンの統合済みの範囲と回復手順	prj-0001:pjr-9kst-multi-repo-resume-precheck-register-records、prj-0001:pjr-6rn3-resume-sync-remerges-integrated-products	同ガイドの「複数リポジトリの統合の失敗と再開」。事前検査・n 番目のプロダクト・プロジェクトの失敗位置ごとに統合済みの範囲と再開の扱いを定める
親検証をリポジトリごとに割り当てられる	prj-0001:pjr-v96b-multi-repo-parent-validations	pipeline.parent_validations の { id, repo }
部分状態での item_status	同ガイド	一部だけ統合済みの状態は waiting とし、review へ進めない。リポジトリ別の状態は pipeline-state.json の stages.integrate.repos に記録する
実構成での動作の確認	prj-0001:pjr-69vp-multi-repo-e2e-docs	3 リポジトリ構成の e2e と、claude・codex・antigravity での 2 プロダクトへの書き込みの確認

検討事項の「1 つの項目で複数リポジトリの変更を許すか」は、prj-0001:pjr-5822-multi-repo-item-design で許す方針に決まった。

8. 関連ドキュメント

• prj-0001:pjr-qhka-docs-structure-detached-unit: 別リポジトリ構成の整理。本項目はその未対応部分。
• specdojo:docs-structure-guide: 構成の記載先。