このドキュメントは、このリポジトリで「どう変更を回すか」を説明します。
（CONTRIBUTING.md がある場合は、そちらも参照してください）
注意：これは 人間向け のガイドラインです。
AIエージェント向けの指示・制約はAGENTS.md/CLAUDE.mdを正とします。
誰でも Pull Request（PR）で変更提案できます。
ただし、アーキテクチャ・I/F・RFC準拠範囲・セキュリティ等に関わる 大きな変更は、 先に Issue を作成してください。
次に該当する変更は、Issue を作る（または既存Issueを参照する）ことが必須です。
- アーキテクチャ / 責務境界（SoT:
docs/design.md） - App ↔ AI の I/F / DTO / イベント名（SoT:
docs/app.md,docs/ai.md） - 受入条件（AC）/ テスト範囲（SoT:
docs/tests.md） - RFC準拠範囲・相互接続性（SoT:
docs/spec_compliance.md） - セキュリティ（PIIログ、認証、CORS、入力安全性、保存パス）
- 大規模リファクタ（ファイル移動、広範rename、横断的変更）
軽微修正（typo、コメント、挙動不変の小リファクタ等）は Issue なしでも良いですが、 PR本文で意図と影響範囲を明確にしてください。
個人開発のため、基本は軽量運用です。
- 通常PR：レビュー1回でOK（セルフレビュー＋チェックリストでも可）
- 重要PR：オーナー（私）のレビュー必須
重要PRの例：
- SoT（正本ドキュメント）に意味変更が入る
- 依存方向/責務境界に影響する
- セキュリティ影響（認証/CORS/ログ/保存/入力）
- SIP/RTP/SDPなどプロトコル挙動やRFC準拠範囲に影響する
- 可用性/信頼性に影響する（timeout/backpressure/retry/retransmit等）
- 大きなリファクタ（広範な差分）
次を満たしたらマージ可能です。
- 必要な場合、Issue参照がある（例：
Refs #10） - 受入条件（AC / Done）が明記され、満たしている
- 1PR=1テーマで、差分がレビュー可能な大きさ
- 振る舞いが変わるならテストを追加/更新し、実行コマンドをPRに書く
- 責務境界違反・境界侵食がない
- Refs:
- 変更内容 / 目的（Why）:
- 変更範囲（モジュール/ファイル）:
- 受入条件（AC / Done）:
- 実行したテスト（コマンド）:
- リスク/ロールバック（あれば）:
このプロジェクトは仕様駆動です。
- コードとdocsが矛盾したら docsが正（SoT）
- 仕様/責務/I/F/ACに影響する変更は docs → 実装 → テスト の順で進める
docsが不明確・矛盾している場合は、推測で進めません：
- 最小の文章案（diffでも可）＋ Yes/No質問 を Issue に書く
- 決めてから実装する
リファクタは原則 挙動不変（behavior-preserving）です。
- 小さなPRに分ける
- “将来拡張”を理由に抽象化を増やしすぎない
- trait/port導入は「差し替えたい境界（I/O、再送、外部サービス等）」に限定する
リリース（タグ付け・公開）は リポジトリオーナーが行います。
release_process.mdがある場合はそれに従う- 現状は手動運用（必要に応じて自動化を検討）
- Issueを作る/参照する（目的・非目標・AC・Refs）
- 必要ならSoT docsを先に更新
- 最小差分で実装
- ACを満たすテストを追加/更新
- PR作成（Refs＋実行したテストを記載）
- 軽量レビューしてマージ