メインコンテンツまでスキップ

リポジトリガバナンス

本文書は、所有、レビュー、リリース、監査上の判断に関する公開記録である。非公開の計画資料は転載しない。

変更統制​

  • 変更は main 以外のブランチから GitHub プルリクエストで提案する。
  • ローカル必須ゲートは make lint、make test、make docs-check である。Go CI は同じ make verify-go を呼び出し、PostgreSQL ジョブは全マイグレーションを2回適用してから統合テストを実行する。
  • 変更のトレーサビリティに従い、全 PR と人が作成した全コミットを公開 Issue に関連付ける。Traceability ワークフローは要求、設計、コミット参照の不足を拒否する。
  • 作成者は自分の変更を承認できない。DB マイグレーションと監査ロール変更には独立した Admin のレビューが必要である。これは現時点では運用上の約束であり、main の Ruleset が実際に何をブロックし何をブロックしていないかはmain の保護設定に記録している。
  • ルール API の新しい版は無効状態で作成される。別の認証済み Admin が有効状態を変更し、ADR-0014 に従って正確な対象版の判定と承認イベントを原子的にコミットする。
  • 本番マイグレーションは MERLON_MIGRATION_DATABASE_URL を使用する。API role は audit_logs と rule_activation_events を UPDATE／DELETE できず、本番起動時に危険な所有権または権限を拒否する。

main の保護設定​

main の Ruleset は2段階で適用する。フェーズ1は単独メンテナ体制でもサーバー側で強制できる範囲であり、フェーズ2はレビュー要件を追加するもので、第2のメンテナが存在するまで有効化できない。

適用済み（フェーズ1）​

  • PR 経由、squash merge のみ、線形履歴、ブランチ削除と force push の禁止。
  • push 後の古いレビューの破棄、全レビュー会話の解決。
  • 最新コミット上の CI Required、Security Required、Traceability Required、check-signoffs。GitHub が必須チェックを照合するのは check-run 名、すなわちジョブ名であり、<ワークフロー> / <ジョブ> 形式ではない。一度も報告されないコンテキストを指定すると全 PR が pending のまま止まるため、main 向けの PR で無条件に実行されるチェックのみを列挙する。

未充足の統制​

2026-07-25 時点の記録である。以下は本文書が宣言しながら GitHub が現時点でブロックしていない統制である。削除せず明記するのは、実装されていない統制を実装済みであるかのように書くことが、ギャップを明示するより悪いためである。

  • 独立した承認、CODEOWNERS レビュー、最終 push 者以外による承認。 GitHub は作成者自身による PR の承認を許さず、.github/CODEOWNERS は単一の所有者しか記載していない。現時点で強制すると、第2のメンテナを追加する PR を含め、すべての PR がマージ不能になる。それまでの間、変更統制の「作成者は自分の変更を承認できない」はサーバー側のブロックではなく運用上の約束である。また本番リリースは停止したままとなる（リリースチェックリストは既にバックアップメンテナを事前条件としている）。解除条件は、第2のメンテナを .github/CODEOWNERS に追加し、Ruleset スクリプトを --require-approvals 付きで再適用することである。
  • ドキュメントサイトのビルド。 Build & Check Docs Site はパスフィルタ付きであり、ドキュメントのパスを変更しない PR では一切報告されない。報告されないチェックを必須にするとマージが恒久的に止まるため、必須にしていない。docs ビルドの失敗は PR 上で見えるが、マージはブロックしない。

リリースタグ Ruleset は v*.*.* を対象に更新と削除を禁止する。リリースワークフローも独立して、軽量タグ、SemVer でない名前、main から到達できないコミットを拒否する。

scripts/configure-github-ruleset.sh は既定では GitHub を変更せず、設定内容を表示する。独立したメンテナが出力をレビューした後、権限を持つ運用者が --apply を指定し、有効な Ruleset API 応答をリリース証跡として保存する。ゲート対象ジョブの改名や削除は check-run 名を変えるため、同じ変更の中でスクリプトを再適用しなければならない。リポジトリプランがこれらを提供しない場合、本番リリースは停止したままとする。テンプレートと CODEOWNERS はサーバー側のマージブロックを代替しない。

リリース統制​

main から到達可能な注釈付きセマンティックバージョンタグだけがリリースワークフローを開始する。固定済みコンテナイメージをビルドし、不変ダイジェストを公開し、SBOM とリリースマニフェストを生成し、GitHub の artifact provenance attestation を要求する。リリース承認、タグ保護、復元証跡、脆弱性対応訓練、バックアップメンテナ、各必須ワークフロー3回の成功は、リリースチェックリストの事前条件である。

受容済みの履歴上の扱い​

  • main から到達可能な履歴は書き換えず、これに対する force push による是正は行わない。オープンな PR ブランチについては、マージ前にコミットのメタデータを是正するための rebase を妨げない。
  • 過去の大規模実装コミットは来歴として保持する。
  • 初回リリース基準を満たす前にリリースタグを作成しない。
  • Issue 参照がない過去の変更は履歴証跡として保持し、新しい PR とコミットに追跡性ゲートを適用する。