Fork & Upstream Synchronization Policy

[!NOTE] 最新の実装状況は 機能実装ステータス (Remaining Functionality) を参照してください。

目的: フォークされたサブプロジェクト（例: space_debris_management）の管理方法を定め、共有コードの品質とサプライチェーン整合性を維持する。

要点:

• フォークが許容されるケース:
• 実験的な急速プロトタイプ（非本番）で、独立した短期的改変が必要な場合。

• ライセンス上許可され、かつチームがフォークの責任者を明確にできる場合。

• フォーク手順（推奨）:

• フォーク提案を Issues に登録し、目的・期間・責任者を明示する。
• 共有コードに対する変更は shared/ または専用パッケージ化されたモジュールに切り出す。

• 重要な API 変更は PR ベースでオリジナルリポジトリへ提案する（同期ポリシー）。

• 同期とマージ運用:

• 週次または機能完了ごとに upstream の main をマージし、差分レビューを行う。

• セキュリティ/ライセンスに関わる変更は必ず upstream に報告し、可能な限り upstream へ逆流させる。

• 長期維持方針:

• 90 日以上の運用継続が見込まれるフォークは、shared コードをパッケージ化して pip/pyproject で依存管理する。

• 重要なバグ修正は 72 時間以内に upstream に通知するか、緊急パッチを適用する（ポリシーに従う）。

• コードレビューとセキュリティ:

• フォークには自動テストと基本的なセキュリティスキャン（Bandit 等）を必須とする。

• 外部データ/モデルを取り扱う場合は取扱方針（TOS、データライセンス）を明記する。

• ドキュメント:

• フォークされたプロジェクトは README に "FORKED FROM" と upstream のコミットハッシュを明示する。

付録: フォーク管理テンプレートと簡易チェックリストを Docs/FORK_POLICY_TEMPLATE.md として追加する予定。