FND-003: チーム編成、プロジェクトガバナンス、コントリビューションパイプライン

v0.7.0 以降 · 種別: ガバナンス · 改訂: 16

正式なリファレンス · チーム承認済み · 改訂 16 元のガバナンスに関する議論: #5577 フォローアップの作業レーンおよびラベルガバナンスポリシー: #6808

これを読む前にチームへの注意。

ソフトウェアプロジェクトは、コードが悪いから失敗するわけではありません。コードを書く人々がうまく連携できないから失敗するのです。機能が二度作られたり、バグが見過ごされたり、誰も書き留めなかったために良いアイデアが消えてしまったりします。新しいコントリビューターが手伝いたいと現れても、どこから始めればよいか分かりません。このRFCは、そうした失敗を防ぐための軽量な土台を作ることについてのものです。それはプロジェクトが整然と見えるためではなく、チームがより速く、より自信を持って、より少ない摩擦で動けるようにするためです。ここにある推奨事項はすべて、小規模で成長中の学生主導のオープンソースチームのために特別に選ばれています。ここにはプロジェクトマネージャー、スクラムマスター、あるいは正式な委員会を必要とするものは何もありません。

改訂履歴

目次

1. 調整問題
2. 3部構成システム
3. GitHub プロジェクト: ワークパイプライン
   • 3.6 ワークレーンと状態の所有権
4. GitHub Discussions: コミュニティでの議論と引き継ぎ
   • 4.5 ディスカッションの管理とDiscordからGitHubへの引き継ぎ
5. チームティアと貢献権限
6. CODEOWNERS とブランチ保護
   • 6.4 アーキテクチャ準拠: 人間のレビュー、AI支援
7. イシューテンプレート
8. RFCガバナンスループ
9. ラベルの階層構造
10. 完了の定義
11. 自動化
12. フェーズドロールアウト

1. 調整の問題

意図的な調整システムを持たないすべてのプロジェクトは、偶発的な調整システムを発展させます。多くのオープンソースプロジェクトにおける偶発的なシステムは以下のようになります：

• アイデアは誰かの頭の中にあるか、スクロールして画面から消えていくチャットメッセージの中にある
• トラッカーに優先順位、担当者、完了の明確な定義がないまま、問題が蓄積しています。
• コントリビューターが誰も求めていないものに対してPRを開いたり、手伝いを申し出ても無視されたりすることがあります。
• チームは受け身で動いている。一番大声で騒ぐ人が注目され、壊れたものが修正され、1週間以上先の計画は何も立てられない
• PRのコメントでアーキテクチャの決定が行われ、どこにも記録されない

これは誰かの努力を批判するものではありません。デフォルトで何が起こるかを説明しているのです。解決策はより多くのプロセスではありません。チームの規模と成熟度に応じて、適切なレベルで適用される適切なプロセスこそが解決策です。

ZeroClawには3つのものが必要です：

1. パイプラインは、アイデアを実装されたコードに変換するための仕組みで、各段階が可視化され、移行ごとに明確なゲートが設けられています。
2. メンテナンスされたディスカッションレーン: コミュニティからの質問、アイデア、ショーケース、まだパイプラインに乗せる準備ができていない初期段階の検討事項を、見失ったりアクティブな作業を散らかしたりすることなく扱うための場
3. ガバナンスモデルは、誰が何を決定できるか、アーキテクチャの決定がどのように行われるか、そしてチームがどのように成長するかを定義します。

これらは3つの異なる関心事です。これらを混同したり、すべてを1つのボードに入れたり、意思決定を非公式なチャットに頼ったりすることが、チームが逃れようとしている混乱を生み出す原因となります。

2. 3つの構成要素

重要な原則: Project ボードには、チームが検討すると確約した作業のみを含めます。 初期のコミュニティでの議論、アイデア、Q&A、ショーケースは、レーンが整備されていれば Discussions に置くことができます。評価され、承認され、スコープが定められた作業は Project に置きます。この区別こそが、ボードを有用に保ちます。

FND-003 は、作業レーンおよびコントリビューションパイプラインのポリシーに関する永続的なガバナンスソースです。RFC #6808 は、機能向け作業レーン、ラベルガバナンス、issue のトリアージ、メンテナールーティングに関するステージング段階の議論でした。そのポリシースライスがプロモートされた後、それらの永続的なルールはこのファウンデーションドキュメントと、以下にリンクされているメンテナー運用ページに格納されます。ポリシーがここにプロモートされた後は、RFC issue を競合するガバナンスドキュメントとして扱わないでください。

運用の詳細は、それを使用するワークフローの近くに意図的に配置されています。

3. GitHub プロジェクト: ワークパイプライン

3.1 パイプラインのステージ

プロジェクトボードには、7つの値を持つ単一のステータスフィールドがあります。各値はパイプラインのステージを表します。シーケンスは線形ですが、アイテムを後戻りさせることができます：

💡 Idea
    ↓  Gate: Vision alignment check
📋 Backlog
    ↓  Gate: Architecture fit + acceptance criteria
🎯 Defined
    ↓  Gate: Assignee, size, risk tier confirmed
🚧 In Progress
    ↓  Gate: Tests written, CI passing
👀 In Review
    ↓  Gate: Correct reviewer tier approved, docs updated
✅ Done

どこからでも到達可能なターミナル状態を1つ追加します：

🚫 Won't Do  ← explicit decision not to pursue; never silently closed

ボードレベルの Won't Do ステートは永続的なクローズ決定です。現在のクローズラベルの表記と置き換えプロセスのルールについては、メンテナーラベルガイドおよび置き換えガイドを参照してください。

3.2 ザ・ゲイト・クエスチョン

すべての遷移にはゲート質問があります。アイテムが先へ進む前に、その質問に「はい」と答えなければなりません。これはプロジェクトボードを実運用化したものです。Vision → Architecture → Design → Implementation → Testing → Documentation という階層が、各ステージのチェックリストになります。

学生チームにとって明示的なゲートが重要な理由: ゲートがないと、カードは「完了した」と誰かが感じたために移動し、完了の定義があるために移動するわけではありません。これは「完了」した作業が実際には完了していないという最も一般的な原因です。ゲートによって、完了の定義が可視化され、共有されます。

これらのゲート質問はガバナンスのためのプロンプトであり、すべてのPR本文やIssueコメントに複製するためのチェックリストではありません。運用上の形式は、メンテナーがすでに扱っている成果物の中に存在します。

• 課題テンプレートは、初期トリアージに必要なレポート、ユーザー価値、再現手順、アーキテクチャへの影響、リスクのヒントを収集します。
• PR テンプレートでは、スコープ境界、検証エビデンス、セキュリティ/プライバシーへの影響、互換性、ロールバック、ラベル、関連 issue を収集します。
• メンテナーのPRワークフローでは、Definition of Ready、Definition of Done、PRレーン、マージチェックを定義します。
• ラベルガイドでは、永続的な分類、stale-policy ラベル、およびクリーンアップシーケンスを定義します。
• レビュアープレイブックでは、受け入れ、レビューの深度、問題のトリアージ、自動化のオーバーライド、キューの整理について定義します。

古い FND-003 のゲート質問が見当たらない場合は、ここに別のコピーを追加する前に、まずそれらの運用先を確認してください。

3.3 カスタムフィールド

GitHub プロジェクトの設定で、次のフィールドを作成してください:

サイズ決め（Tシャツサイズ）について: ストーリーポイントにはチームがまだ持っていないキャリブレーションと履歴データが必要です。Tシャツサイズは直感的で、この段階のチームには十分です。

XL アイテムは、通常、進行中に入る前に細分化する必要があります。細分化できない場合は、設計が十分に完了していないことを意味します。

3.4 ビュー

プロジェクトに4つの名前付きビューを作成します:

ビュー1: ロードマップ

• タイプ: ロードマップ（タイムライン）
• グループ化基準: マイルストーン
• 表示されるフィールド: タイトル、タイプ、サイズ、コンポーネント、担当者
• 目的: 公開向け。「今後予定されていることと時期」を共有します。このリンクを README やコミュニティで共有してください。定期的に更新してください。

ビュー 2: ボード

• タイプ: ボード（カンバン）
• 列：ステータスフィールドの値
• フィルタリング: 現在のマイルストーンのみ
• 表示されるフィールド: タイトル、担当者、サイズ、リスクティア
• 目的: 日々の作業の可視化。現在、誰もが何に取り組んでいるのか？何がブロックされているのか？

ビュー3：バックログ

• タイプ: テーブル
• 優先度（降順）、次にサイズ（昇順）でソート
• フィルタ条件: ステータス = バックログ OR 定義済み
• 表示されるフィールド: タイトル、タイプ、優先度、サイズ、コンポーネント、マイルストーン、リスクティア
• 目的: ガーミングセッション中に使用されます。次に何を作業すべきか？サイズが決まり、引き受ける準備が整っているのはどれですか？

ビュー 4: マイワーク

• タイプ: ボード
• フィルタリング条件: 担当者 = @me
• 目的: 個人ダッシュボード。各コントリビューターはノイズなしで自分のアイテムのみを確認できます。

3.5 ピン留めされたアイテム

GitHubでは、リポジトリごとに最大6件のピン留めされたIssueを許可しています。これらは、重要な情報を常に目に見える形で伝えるために使用してください。

1. 現在議論中のアクティブなRFC
2. 最も要望の多かったコミュニティ機能（最高投票数のディスカッション）
3. 次のリリースマイルストーンを追跡する問題
4. 現在の good first issue 項目すべてにリンクする good first issue インデックス（イシュー）

ピン留めされたイシューはコミュニティへの約束です：これらは現在最も重要なものです。優先順位が変更されたら、それに応じて更新してください。

3.6 ワークレーンと状態の所有権

ワークレーンポリシーにより、ボード、ラベル、PR、issueが同じ問いに別々の場所で答えようとするのを防ぎます。

この分割を使用してください

PRレーン、コントリビューター受け入れラベル、stale除外ラベル、ラベル移行は永続的なガバナンスの概念ですが、その正確な運用基準はメンテナードキュメントに記載されています。FND-003がこの役割分担を管理します。ラベルは永続的な作業を分類し、プロジェクトボードは作業を計画し、ネイティブのPRステートはライブレビューとマージの状態を管理し、issue/RFCは決定事項を保持します。メンテナーPRワークフローはPRレーンの定義を管理し、ラベルガイドはラベルの正確な意味とクリーンアップルールを管理し、レビュアープレイブックはレビュアーがトリアージとレビューの際にこれらのシグナルをどのように適用するかを管理します。ライブラベル移行は通常のPRレビューではなく、メンテナーが承認した別個のクリーンアップ作業として扱ってください。

stale 免除はガバナンス上の例外であり、恒久的なラベルの保護ではありません。目標とするポリシーは、status:no-stale がレーンの運用ソースに、その issue がなぜ免除されているのか、そして次の判断を担う可視のルーティング証跡が何であるかを記録している場合にのみ有効である、というものです。メンテナー向けドキュメントは、それらの事実がどこに存在し、stale 自動化や stale スイープがどのようにこのルールを適用するかを定義します。

4. GitHub Discussions: コミュニティでのディスカッションと引き継ぎ

4.1 メンテナンス済みディスカッションレーン

GitHub Discussions は、メンテナンスされたコミュニティの場として扱ってください。Discussions は、質問、アイデア、投票、お知らせ、ショーケース、プロジェクトや統合機能のデモ、また Discord よりも永続性が求められるものの、まだ追跡対象の作業にはなっていない探索的なスレッドに役立ちます。

正確なカテゴリ、カテゴリの説明、レビューの頻度は運用上の詳細です。これらはコントリビューター向けコミュニケーションガイドおよびメンテナーワークフロードキュメントに記載されるべきものであり、この基盤ドキュメントを改訂することなく変更される可能性があります。

4.2 ディスカッションから追跡対象作業への昇格

Discussion はスレッドが存在するというだけでバックログ作業になるわけではありません。Discussion が具体的に追跡可能な成果を生み出したときに昇格させてください。コントリビューター向けのトリガー例は Communication を参照してください。

ターゲットは結果によって異なります。確認されたバグや受理された機能スコープはissueに移行します。アーキテクチャに関する決定はRFCプロセスを通じて処理されます。PR固有の詳細はPRコメントに移行します。恒久的な運用ルールはメンテナーまたはコントリビューター向けドキュメントに移行します。

発端となった Discussion でループを閉じます。カテゴリが回答をサポートしている場合は、適切なときに要約や追跡作業へのリンクを回答としてマークします。サポートしていない場合は、issue、RFC、PR、またはドキュメントへのリンクを記載した最終的な要約コメントを追加します。

4.3 投票を待たないアイデア

一部の項目は Discussions を経由せず、トラッキング対象に直接登録されます。

• セキュリティ脆弱性（プライベートなセキュリティレポート経由、公開されない）
• 再現手順付きのバグを確認しました（バグ報告のIssueテンプレートに直接進んでください）。
• RFCで承認されたアーキテクチャ項目（RFCのクローズループから直接派生）
• プロジェクトロードマップからのアイテム（コアチームによって直接配置）

4.4 アーキテクチャの探索

アーキテクチャの検討は、その問いがコミュニティに向けたものであり、まだ正式なRFCにする段階ではない場合、Discussionsから始めることができます。これにより、すべての初期段階の考えを追跡対象のポリシーにすることなく、設計上の懸念を提起する際のハードルを下げられます。

スレッドが具体的なアーキテクチャ提案に到達したら、RFC issue を作成し、永続的な提案を RFC サーフェスに移動してください。その後、Discussion から RFC へリンクを張ることで、Discussion が信頼できる唯一の情報源 (source of truth) ではなくなります。

4.5 ディスカッションの管理と Discord から GitHub への引き継ぎ

Discordは素早い会話のための場所です。GitHubは永続的な記録です。Discussionsは、Discordよりも永続性が必要だがまだ追跡対象の作業ではない、コミュニティ向けの会話のために維持されているGitHubの場の1つです。

ディスカッションは、誰かがそのレーンを所有している場合にのみアクティブになります。その所有権は、指名されたスチュワードであっても、文書化されたレビューの頻度であってもかまいません。所有権がなければ、ディスカッションは必須の受付経路ではなく、受動的なアーカイブにすぎません。

探索的、コミュニティ向け、または幅広いフィードバックを求めるスレッドには Discussions を使用します。結果がすでに具体的または確定的である場合は、issue、RFC issue、PR コメント、またはメンテナードキュメントを使用します。コントリビューター向けのトリガー一覧とカテゴリの例は Communication を参照してください。

ハンドオフではチャット全体をコピーする必要はありません。成果と、別のメンテナーが作業を継続できるだけの十分なコンテキストを記録してください。Discussion から後に追跡対象の作業や恒久的なポリシーが生じた場合は、その結果をそれを所有するサーフェスに昇格させてください。

5. チームのティアと貢献権限

5.1 3つの階層

オープンソースプロジェクトは実力主義で運営されています。影響力と権限は、実際の貢献によって得られるものであり、年功や肩書き、人脈によって得られるものではありません。これはオープンソースが企業のソフトウェアと異なる点の一つであり、明示的に教える価値があります。

3つの階層は、プロジェクトに対する示されたコミットメントの増加を反映しています：

ティア1：コミュニティ

誰でも。承認は不要です。

何ができるか:

• 問題テンプレートを使用して問題をオープンする
• 任意のIssueやPRにコメントする
• ディスカッションにリアクションし、アイデアに投票する
• プルリクエストを送信してください（マージ前にレビューされます）。
• GitHub Wiki を編集する

できないこと:

• 課題を割り当てる（割り当てをリクエストすることも可能）
• PRを承認する
• PRをマージする
• 拘束力のある権限を持つRFCに投票する

ティア2: コントリビューター

master ブランチに少なくとも2つのPRがマージされたコミュニティメンバー。

なるには: PRを2件マージしてもらい、Core Teamメンバーに認められること。Tier 2には現在、永続的なメンバーシップ記録がありません。§5.3を参照してください。

コミュニティが提供するものを超えるもの：

• 課題を割り当て可能
• PRでレビュアーとしてリクエストできます（必須ではないレビュー）。
• ディスカッションでのアイデアへの投票数は、昇格の閾値にカウントされます。
• Discussions を経由せずに RFC の議論をリクエストできます

まだできないこと:

• 高リスクパスのPRを承認する
• PRをマージする
• RFC投票のキャスト

このティアが存在する理由: 新規コントリビューターにとって、視覚的に分かりやすく達成可能な最初のマイルストーンを作成します。「もっとどのように関与すればよいですか？」に対する明確な答えは、2つのPRをマージすることです。これは初期の良好な貢献を促進し、チームがコントリビューターを公に認識する方法を提供します。

ティア3: コアチーム

長期間にわたり一貫して高品質な貢献を行い、既存のコアチームメンバーから招待されたコントリビューター。

参加方法: 既存のコアチームメンバーからの招待により、Discussionsで公開発表されます。正式な基準はなく、過去の貢献の質・一貫性・方向性の一致に基づいた判断となります。

Contributor として得られるもの：

• リポジトリへの書き込みアクセス
• レビュー要件を満たしたPRをマージできます
• High Risk パスの PR を承認する権限があります（CODEOWNERS の要件に従う必要があります）。
• RFCに対するバインディング投票を行う
• プロジェクトパイプラインを介してアイテムを移動できます
• リリースをカットできます
• ガバナンスの意思決定に参加する（コアチームの議論）

責任:

• 新規のイシューを3営業日以内にトリアージする
• 専門分野のPRを5営業日以内にレビューする
• RFC投票に参加する
• プロジェクトの行動規範を遵守してください

5.2 遅延コンセンサスルール

日常的な意思決定、たとえばラベルの追加、放置されたissueのクローズ、ドキュメントの更新などについて、コアチームのメンバーは**消極的合意（lazy consensus）**に基づいて行動します。該当のissueで自分の意図を表明し、48時間以内にコアチームのメンバーから異論が出なければ、そのまま進めて構いません。これにより、すべてに明示的な承認を求めることによる停滞を防ぎつつ、可視性を維持できます。

遅延コンセンサスは以下には適用されません：

• RFCの承認または拒否
• リリース
• CODEOWNERS またはブランチ保護ルールの変更
• このガバナンス文書への変更
• コアチームへの追加

これらは常に明示的なコアチームの投票が必要です。

5.3 チームメンバーシップの記録

メンバーシップそのものは、ファイルや GitHub の設定ではなく、決定によって確立されます。§5.1 に従い、既存の Core Team メンバーからの招待によって Core Team に加わり、Discussions で公開されます。その決定と公開された告知が信頼できる情報源です。以下のすべては、それに付随する何かの記録であり、いずれもメンバーシップの名簿ではありません:

core-contributors GitHub チームと組織設定内のリポジトリコラボレーターリストは、メンバーシップの記録ではなくアクセス制御です。これらは誰がリポジトリに書き込めるかを示すものであり、メンバーシップの定義ではなくその結果です。これらはメンバーリストと双方向に食い違う可能性があることを想定してください。人ではない自動化アカウントが含まれていたり、アクセスが直接付与されていたり、メンバーシップの決定より前から保持されていたり、あるいは招待の承諾がまだ保留中であったりします。誰がプッシュできるかを知る必要があるときは、これらを参照してください。誰が Core Team であるかを知る必要があるときは、そのメンバーを承認したアナウンスを参照してください。

リポジトリルートの .github/CODEOWNERS: レビューのルーティングであり、メンバーシップではありません。どのパスで誰にレビューが依頼されるかを記録します。そこに記載されていてもメンバーシップが付与されるわけではなく、メンバーであっても記載されているとは限りません。これを変更するには、§5.2 に従って Core Team の明示的な投票が必要です。

Communication のメンテナーテーブル: 現在のメンバーとそれぞれの担当領域を人間が読める形でまとめたものです。公開されたメンバーリストに最も近いものですが、手作業で管理されているため、入会決定の要約として扱い、権威ある情報源としては扱わないでください。フォーカスエリアについては CODEOWNERS の便宜的なビューであり、両者が異なる場合は CODEOWNERS が優先されます。

削除はアドミッションと同じように機能します。削除は決定であり、その決定が行われた場所に記録されます。アクセスの取り消しや CODEOWNERS からの削除は離脱を実装するものであり、それ自体が離脱を構成するわけではありません。

このドキュメントのリビジョン1から7では、リポジトリのルートに階層別のメンバーシップ記録としてCONTRIBUTORS.mdファイルを規定し、zeroclaw-coreおよびzeroclaw-contributorsというGitHubチームを指定していました。この3つはいずれも作成されることはなく、組織では代わりに単一のcore-contributorsチームを使用しています。RFC #6808も独立して同じ結論に達しており、FND-003のチーム階層構造は現在の可視的なルーティングモデルではなく、新しいレーンルールをそれを基盤として構築すべきではないと記録しています。これらの参照は、存在しない仕組みの記述として残しておくのではなく、ここで廃止します。

Tier 2 には現在、永続的なメンバーシップ記録がありません。そのような記録を設けるか、この階層を廃止するかは、チームにとって未解決の課題です。

6. CODEOWNERS とブランチ保護

6.1 CODEOWNERS

CODEOWNERS ファイルによって、ガバナンスが自動化されます。このファイルは、PR をマージする前に、どのパスがどのチームのレビューを必要とするかを定義します。GitHub はこれを必須レビューとして強制します。要件が満たされるまで、PR はマージできません。

以下のブロックは、保護されたレビューのルーティングについて示していた推論を残すために掲載している元の例示的な提案です。現在のファイルではないため、コピーしないでください。.github/CODEOWNERS はすでに存在し、現在も積極的に保守されています。このファイルはチームのハンドルではなく個人のハンドルにルーティングし、そのパスは #6537 で確立された post-microkernel のクレートレイアウトに従っています。ここで使用されている @zeroclaw-labs/zeroclaw-core と @zeroclaw-labs/zeroclaw-contributors のハンドルは作成されたことがありません。§5.3 を参照してください。ここでの広範なルーティングパスは、現在の risk:high 分類子ではありません。現在のルーティングとリスクの意味については、実際のファイルとメンテナーラベルガイドを確認してください。

# CODEOWNERS — Automatic review routing by protected surface
# See the maintainer label guide for risk definitions.
# See the governance foundation doc and RFC issue template for team tier definitions.

# ── Protected review routing: Core Team review ──────────────────────────────

src/security/**                 @zeroclaw-labs/zeroclaw-core
src/gateway/**                  @zeroclaw-labs/zeroclaw-core
src/runtime/**                  @zeroclaw-labs/zeroclaw-core
src/tools/shell.rs              @zeroclaw-labs/zeroclaw-core
src/tools/file_write.rs         @zeroclaw-labs/zeroclaw-core
src/tools/security_ops.rs       @zeroclaw-labs/zeroclaw-core

# ── Governance and configuration: requires Core Team approval ───────────────

.github/**                      @zeroclaw-labs/zeroclaw-core
CODEOWNERS                      @zeroclaw-labs/zeroclaw-core
Cargo.toml                      @zeroclaw-labs/zeroclaw-core
deny.toml                       @zeroclaw-labs/zeroclaw-core

# ── Architecture documents: requires Core Team review ───────────────────────

docs/book/src/foundations/**    @zeroclaw-labs/zeroclaw-core
docs/book/src/architecture/decisions/**  @zeroclaw-labs/zeroclaw-core
AGENTS.md                       @zeroclaw-labs/zeroclaw-core

# ── Default: any Contributor or Core Team member can review ─────────────────

*                               @zeroclaw-labs/zeroclaw-contributors

特定のコアチームメンバーがコンポーネントのオーナーシップを持つようになったら、チームのハンドルと並べて個人のハンドルを追加してください。CODEOWNERSでは具体性が優先されます。より具体的なパスのルールが、より一般的なルールを上書きします。

6.2 ブランチ保護ルール

master ブランチの以下の保護ルールを設定してください：

管理者がバイパスできない理由: 小規模チームのプロジェクトで最もよくある間違いの1つは、ブランチ保護を「他人のためのもの」と捉えてしまうことです。管理者がバイパスできる場合、時間的なプレッシャーの中、緊急時には、「今回だけ」とバイパスしてしまうものです。そしてそれが常態化していきます。ルールは、意味を持つためには全員に適用されなければなりません。本当に緊急事態が起きた場合の正しい対応は、プロセスをスキップすることではなく、より速くプロセスに従うことです。

GitHub のネイティブな承認数は、PR ラベルによる条件分岐ではなく、保護されたブランチまたはルールセットの対象ごとに設定されます。Core Team の承認を示す機械可読な権威情報を備えた、別途承認済みの技術的強制適用設計が整うまでは、メンテナーは文書化されたマージチェックリストを通じて risk:high OR domain:security の要件を適用し、監査可能なレビュー記録を保持する必要があります。risk:manual は将来の自動的なリスク置換のみを凍結するものであり、この要件を緩和することはできません。

6.3 必須のステータスチェック

PRがマージされる前に通過しなければならないCIチェック:

build (stable)          ← cargo build --release
test                    ← cargo test
fmt                     ← cargo fmt --all -- --check
clippy                  ← cargo clippy --all-targets -- -D warnings

ワークスペースがアーキテクチャ RFC に基づいてクレートに分割されるため、各クレートごとのチェックを追加します。crates/zeroclaw-api への変更に対しては、そのクレートのテストスイートを独立して実行する必要があります。

6.4 アーキテクチャ準拠：人間のレビュー、AI支援

このセクションが存在するのは、この疑問が必ず出てくる（すでに出ています）ためであり、PRごとに議論するのではなく、明確で文書化された回答を示すべきだからです。

質問: RFC で定義されたアーキテクチャや設計パターンに準拠しているかどうかを確認する自動化されたゲートを追加すべきでしょうか？

答え: いいえ。なぜそうなのかを理解することが重要です。

品質の強制には、根本的に異なる2つの種類があり、それぞれ異なるメカニズムが必要です。

最初の種類は構文準拠です：このコードは機械的なルールに違反していますか？zeroclaw-kernel は TelegramChannel をインポートしていますか？依存関係グラフのエッジが逆方向を指していますか？clippy の警告がありますか？これらは二値的な質問です。コードがルールに違反しているか、していないかのいずれかです。このルールは、コンパイラ、cargo deny、および cargo clippy --workspace によって既に強制されています。人間も AI も必要ありません。機械が権威を持ち、速く、事実上の違反については決して誤りません。

2つ目は_アーキテクチャ上の意図_です。この判断はここに属するのか？この抽象化は適切なレイヤーにあるのか？このトレードオフはビジョンと整合しているのか？この結合はフェーズ3で苦痛をもたらさないか？このPRは今日のdiffには見えない保守の負担を生み出さないか？こうした問いには、判断力、文脈、そしてアーキテクチャが存在する_理由_への理解が必要であり、単にルールが何であるかだけではありません。自動化ツールがこれらに確実に答えることはできません。なぜなら、その答えはdiffには含まれていない情報、すなわちロードマップ、チームの現在の優先事項、コントリビューターの意図、そしてその判断の長期的なコストに依存するからです。

建築的判断を自動化することの失敗モードは、どちらも悪い。

微妙なアーキテクチャ違反を通過させてしまうゲートは、誤った安心感を生み出します。開発者は ✅ を見て、自分の判断が検証されたと思い込みます。最も有害なアーキテクチャの逸脱、つまり解きほぐすのに何年もかかる類のものは、構造的には正しく見えます。コンパイルも通ります。lint も通ります。依存関係グラフにも問題はありません。問題は、それが設計の精神に反していることであり、それは後になって、つまり巻き戻すコストが高くなったときに初めて明らかになるのです。

ツールが文脈を誤解して有効なアーキテクチャ上の判断をフラグ付けするゲートは、開発者にゲートを完全に無視する癖をつけてしまいます。チームがノイズの多い自動チェックを無視して先に進む方法を学んでしまうと、CI 上でチェックが実行され続けていても、実質的にはチェックは機能しなくなります。プロジェクトは負の価値を生むために CI の分を費やすことになります。

CODEOWNERS はアーキテクチャ準拠のゲートです。レビュアーはそのツールです。

§6.1 の CODEOWNERS 設定では、クレートの境界、trait 定義、依存関係グラフ、src/security/、.github/ などの保護対象レビュー領域が、すでに Core Team のレビュアーに割り当てられています。この割り当ては risk:* 分類とは別のものです。RFC を参照フレームワークとする Core Team のレビュアーが、アーキテクチャ適合性チェックを担います。そのレビュアーは、自動化では再現できない文脈に即した判断をもたらします。

これが RFC、AGENTS.md ファイル、およびドキュメント基準が存在する理由です。機械がそれらを解析してスコアを生成するためではなく、人間のレビュアーが一貫性のある文書化されたフレームワークを適用できるようにするためです。RFC は「なぜこのアーキテクチャが存在するのか」に答えます。レビュアーは「この PR がその理由に貢献しているか、それともそれを弱めているか」を判断します。

AIはマージゲートではなく、開発ループに属すべきです。

AIツール、Claude、Copilot、Cursor、そしてこの先登場するであろうものは、適切な場所で使えば、アーキテクチャ作業において実際に役立ちます。適切な場所とは、_マージゲートの段階_ではなく、_開発の段階_です。

開発中、RFC とクレートの AGENTS.md を備えた AI アシスタントは、コントリビューターが新しい機能を実装する前に、その機能がどのクレートに属するかを理解するのを助け、コードがまだ設計段階にある間に潜在的な依存関係の逆転を指摘し、なぜ特定のデザインパターンが存在するのかを説明し、新しい抽象化が適切なレイヤーにあるかどうかを提案することができます。これは追加的な効果をもたらします。コントリビューターの能力を向上させます。

レビュー中に、AI アシスタントは人間のレビュアーが構造化されたフィードバックをドラフト作成したり、変更を RFC と照合したり、PR に関連する RFC の議論の質問を特定したりするのに役立ちます。これは追加的な機能でもあります。レビュアーが判断を行い、AI が速度と記憶力を提供します。

AIにできないのは、判断の代替です。「AIがこのPRの評価を手助けする」と「AIがこのPRを自動的にゲート管理する」はまったく別物であり、アーキテクチャに関する意思決定で機能するのは前者だけです。プロジェクトがアーキテクチャ準拠の判定を、どれほど高度であっても自動ゲートに委ねるようになった日が、誰も気づかないうちにアーキテクチャがじわじわとずれ始め、手遅れになるまで放置される日の始まりです。

実際のポリシーを簡潔に述べると：

• 構造的な適合性（インポートの方向性、依存関係グラフ、リンティング、フォーマット）はCIによって強制されます。これは非交渉事項であり、自動化されています。
• アーキテクチャの意図の遵守は、CODEOWNERS による Core Team のレビュアーへのルーティングによって強制されます。これは非交渉事項であり、人間が行います。
• AIツールは、開発中の貢献者を支援し、レビュー中のレビュアーをサポートします。ただし、それら自身の権限でマージを制限することはありません。
• チームが将来 AI支援のレビューツールを評価したい場合、その評価はまずRFCプロセスを通じて行われます。文書化された決定がない限り、.github/workflows/には追加されません。

このポリシーは、AI や自動化に対する制限ではありません。これは、異なる問題には異なるツールが必要であり、適切なツールを適切な場所で使用することが、アーキテクチャ RFC がコードベースに求めていることそのものであることを認識したものです。

7. イシューテンプレート

Issue テンプレートは、人間が対応する前に、着信するレポートを適切なプロセスに振り分けます。適切に記述されたテンプレートは、トリアージに必要な情報を自動的に収集します。テンプレートが欠落しているか無視されると、問題の理解に3回のコメントのやり取りが必要になります。

信頼できる運用上の情報源は .github/ISSUE_TEMPLATE/ です。テンプレートの完全な YAML をここに複製しないでください。テンプレートの文言が変更された場合は、issue フォーム自体を更新し、このセクションは恒久的な意図のレベルに留めてください。

現在の受付レーン:

セキュリティ脆弱性には公開のイシューテンプレートを用意していません。config.yml には、非公開のセキュリティポリシー、Discord、GitHub Discussions、コントリビューションガイド、RFC プロセス、メンテナーの PR ワークフローへのリンクが含まれており、コントリビューターは追跡対象のイシューを作成する前に適切な窓口を選択できます。

Issue テンプレートはエビデンスを収集するものであり、それ自体で最終的なラベルを決定するものではありません。メンテナーは、本文、ディスカッション、リンクされた作業を確認した後、status:accepted、status:no-stale、help wanted、good first issue といった判断が必要なラベルを引き続き適用します。特に、status:no-stale はテンプレートから自動的に適用すべきではありません。トラッカー、RFC、または長期間継続して受け入れられた Issue では、stale 保護を追加または維持する前に、stale 除外の理由と、目に見える次の判断もしくは再検討の場の両方を記録する必要があります。

8. RFCガバナンスループ

RFCプロセスは、ドキュメントRFCおよびアーキテクチャRFCで確立されました。このセクションでは、クローズループ（RFCが提案から決定、そしてアクションへとどのように移行するか）を定義します。

RFC が必要な場合。 RFC は、実装前に永続的なプロジェクトレベルの決定を記録します。提案が次のうち少なくとも 1 つに該当する場合は、RFC を必須とします:

• 新たなセキュリティレイヤー、またはプロジェクトのセキュリティモデルへの重大な変更;
• ガバナンス、コントリビューションプロセス、またはプロジェクトの権限に関する変更;
• 既存の境界をまたいで所有権または契約を変更する、横断的なアーキテクチャのリファクタリング。または
• 新しいサブシステム、またはプロジェクト全体に関わる別の機能境界。

通常の機能追加、スキーマまたはデータの移行、設定フィールドやデフォルト値の変更、あるいは範囲が限定された実装のリファクタリングを含むという理由だけで、RFCを必須にしないでください。これらはissueとPRを通じて進めます。実質的な影響が上記のトリガーのいずれかにも該当する場合にのみ、RFCが必要です。

トリガーとなるのは、課題のタイトルや作成者、AI 支援による発生元、あるいは移行・機能・デフォルトの変更が単に存在することではなく、プロジェクトへの実質的な影響です。セキュリティ脆弱性については非公開で報告し、公開 RFC は決して使用しません。

メンテナーは、提出された RFC がトリガーを満たさない場合、通常の issue、機能リクエスト、または実装フォローアップとしてラベルを付け直したり、クローズしたりできます。処理方針には、元の作業が引き続き有効かどうか、およびどこで継続されるかが示されます。これは作業の振り分けであり、内容に基づく却下ではありません。

8.1 RFCの完全なライフサイクル

著者による通常の改訂や議論中の明確化では、カウントダウンはリセットされません。提案された決定を実質的に変更する改訂では、公開で識別された新しい安定スナップショットが確立され、該当する最短議論期間のカウントダウンが再開されます。

1. AUTHOR opens an RFC issue using the RFC issue template,
   naming the trigger the proposal crosses
           |
2. DISCUSSION PERIOD, against a visible proposal
     minimum 48 hours for an ordinary RFC
     minimum 72 hours when the exceptional unanimous path is requested
   Anyone can comment. Core Team members engage substantively.
           |
3. VOTE OPENS once the period has elapsed and the proposal is stable.
   The vote-opening comment records:
     - the immutable proposal snapshot (artifact, commit, or issue-body digest)
     - the assigned active electorate, and inactive Core notified for re-entry
     - the threshold, and why it applies
     - that quorum requires two explicit ballots
     - the exact UTC deadline, 72 hours after opening
           |
4. CORE TEAM BALLOTS, one of:
     APPROVE  accept the snapshot as written
     REVISE   request changes, withhold approval, do not veto
     REJECT   blocking objection, with a specific reason
   A member's latest ballot before the deadline supersedes their earlier one.
           |
5. OUTCOME, applied in this precedence order:
     a. Fewer than two explicit ballots        -> DEFERRED
     b. Quorum met and any final ballot REJECT -> REJECTED
     c. Quorum met, no REJECT, two-thirds
        approving explicitly or by silence     -> ACCEPTED
     d. Otherwise                              -> RETURNED TO DISCUSSION

承認された RFC には status:accepted が付与され、終了記録では、すべての REVISE の懸念に対処したことを示し、懸念を破棄したことにはしません。却下された RFC は、阻止となった異議を記録し、根本的な問題が継続している関連 issue へのリンクを付けて終了します。却下によって終了するのは現在の提案であり、必ずしも問題そのものではありません。保留された提案は、再投票の条件を記録したままオープンにしておき、内容に変更のない保留提案は、議論を繰り返さずに新たな 72 時間投票に戻すことができます。

現在有効な type:rfc と status:accepted ラベルを使用します。並行する rfc:* ステータスラベル系列はありません。

Rev. 15 は、承認後に開始された RFC の投票に適用されます。以前に承認された RFC が自動的に無効になるわけではありません。過去のプロセスの監査および修正作業は、引き続き別途追跡されます。

投票は、最終的にアクティブな投票者の全員が明示的に承認し、かつ、それ以外は非アクティブな Core コントリビューターから投票期間全体を求める申し出がない場合に限り、期限前に終了できます。終了記録には、期限前に終了した理由を記載しなければなりません。例外的な全会一致投票は、割り当てられた全投票者から明示的な承認を得た場合に限り、期限前に終了できます。

8.2 投票の閾値

最終的な有効投票者数の3分の2がデフォルトのしきい値であり、投票者数の整数になるよう切り上げます。最終的な有効投票者数は、投票開始時に割り当てられた投票者数に、同じ投票で投票するその他の現在のCore Teamメンバーを加えたものです。

• Quorum には、現在の Core コントリビューターのうち少なくとも 2 人が明示的に投票する必要があります。無回答がクォーラムに算入されることはありません。
• 最終的なアクティブ投票者からの沈黙はAPPROVEとして数えられます。これは定足数に達した後の通常の投票に限られます。
• REVISE は未承認として扱われ、拒否権はありません。
• REJECT は定足数に達すると承認を拒否します。

たとえば、最終的な有効投票者が4人の場合、明示的な APPROVE が1人、明示的な REVISE が1人、無応答のメンバーが2人いると、4人中3人の承認となり、しきい値を満たします。

**全会一致は、**ライセンスや法的所有権の変更など、コストや不可逆性のために特別多数決による承認では不十分な決定に限って適用します。投票開始時には、全会一致を適用する理由を説明しなければなりません。全会一致の投票では、割り当てられた、投票資格を持つすべての Core コントリビューターから明示的な APPROVE が必要です。沈黙によって全会一致を成立させることはできません。

アクティブな投票者。 アクティブな Core contributor とは、現在の Core Team メンバーであり、直前30日間に正式に開始された RFC 投票で明示的な APPROVE、REVISE、または REJECT の投票を行い、かつ投票期間中に公に離脱を表明したり、参加不能を記録したりしていない人を指します。現在非アクティブな Core メンバーには通知が行われ、その投票で投票することで、投票の最終的な投票者に加わることができます。これにより、後続の投票に向けても再びアクティブになります。

定足数と分母は、投票ごとに個別に決定されます。活動状況は投票開始時に確認されるため、後から別の並行投票で行われた活動によって、すでに開始された投票の有権者集合が変わることはありません。

8.2a コアミーティングの決定事項と GitHub ブリッジ

GitHub は、提案文、議論、投票の開始、投票用紙、締め切り、結果に関する正本です。Discord では RFC の告知や議論を行えますが、ガバナンスの状態を確定するものではありません。

コアコントリビューター会議で決定され、プロジェクトで承認された内部意思決定記録に記録された内容は、メンテナーによる即時の対応の指針となる場合があり、以前の内部方針に優先する場合があります。そのような対応によってプロジェクトの公開状態が変更される場合は、影響を受ける issue、PR、tracker、または RFC に GitHub ブリッジ記録を残す必要があります。ブリッジ記録には、会議の日付または意思決定記録を明記し、適用した決定を要約し、実施した公開上の対応を記載し、それが一度限りの例外なのか、恒久的なルール変更なのかを示します。

会議での決定によって、この文書、コントリビューター向けドキュメント、ラベル、Issue テンプレート、または RFC の結論が黙って書き換えられることはありません。永続的なガバナンスの変更がポリシーとなるのは、関連する GitHub およびドキュメント上の各所に反映された場合に限られます。例外的な全会一致の決定については、内部会議の記録が承認メンバーを記録し、公開された issue にその根拠が記録されていない限り、必要な明示的な GitHub 承認に代えることはできません。

8.3 永続的なフォロースルーとADRの関連性

新たに承認された RFC については、実装を進める前に、最終形と継続的なフォローアップが RFC issue から確認できる状態でなければなりません。承認だけでは、ガバナンス上の引き継ぎは完了しません。実装後に監査される承認済み RFC については、完了済みの作業を再オープンせずに、対応結果を遡及的に記録してください。

各処置記録には、正式な最終形、選択した処置とその根拠、永続的な成果物または納品トラッカー、そしてフォローアップが残っている場合の担当者または次のアクションが記載されます。

4つの処理方法のいずれかを使用してください。

• ADR: その決定が将来のアーキテクチャを実質的に制約する場合に必要です。予期しないシステム境界、自明でないトレードオフ、あるいは将来のアーキテクチャの選択肢を実質的に制限する選択などが指標となります。
• 常設ドキュメントの更新: 継続的な成果が、新しいアーキテクチャ上の決定ではなく、運用・リファレンス・ワークフロー・セキュリティ・ユーザー契約である場合に必要です。
• 実装またはトラッカーのフォローアップ: 既存の ADR、FND、または常設ドキュメントが既に決定を記載しており、提供作業が残っている場合に必要です。提供トラッカーとその次のアクションをリンクしてください。
• 独立した成果物なし: 特定された既存のFND、ADR、常設ドキュメント、完了済み実装、または上位の決定が既に結果を保持しており、追加の納品追跡が不要な場合に許可されます。issueにはその根拠を記録し、恒久的な参照先へのリンクを含める必要があります。

RFC は議論と承認のための場です。ADR は重要なアーキテクチャ上の決定を恒久的に記録するものであり、承認されたすべての RFC の必須要約ではありません。常設ドキュメントや実装トラッカーは、承認された決定が上記のアーキテクチャ基準を満たす場合、ADR の代わりにはなりません。

8.4 基礎的なRFC

これまでの初期の提案ドキュメントは、その後 RFC の issue や基盤ドキュメントとして表現されてきました。

9. ラベルの階層構造

ラベルは、イシューやプルリクエストにおけるメタデータ層です。一貫性のある、よく設計されたラベルシステムは、フィルタリング、レポート作成、自動化を可能にします。一貫性のないラベルシステム（イシューを作成した人がその場で場当たり的にラベルを追加するという、よくあるケース）は、ノイズを生み出します。

名前空間付きのラベルシステムを使用します。各ラベルには、そのカテゴリを識別するプレフィックスがあります：

type: これはどのような種類の作業ですか？

priority: これはどれくらい緊急ですか？

size: この作業項目はどのくらいの大きさですか？

component: システムのどの部分か？

component:kernel · component:gateway · component:channels · component:tools · component:memory · component:security · component:hardware · component:docs · component:infra

すべてのコンポーネントラベルに #f1f5f9（ライトグレー）を使用して、視覚的に他のカテゴリと区別してください。

risk: リスクの階層は何ですか？（AGENTS.md に対応）

status: プロセスのどの段階にあるか

この表はガバナンスの意図と過去の分類体系の構造を記録するものです。現在運用中のラベルのセマンティクスや自動化の挙動については、メンテナー向けラベルガイドを運用上のリファレンスとして参照してください。メンテナー向けドキュメントには、#6808 以降のラベルポリシーの修正が反映されています。

コミュニティによるピックアップで実際に使われているラベルはプレフィックスなしの good first issue と help wanted であり、上記の status:* ピックアップ行は過去の分類体系です。現在の運用上のリスクラベルでは、issueリスク（報告内容から推定される修正の影響範囲）とPRリスク（レビュー対象の実際の差分）も区別しています。実際のポリシーについてはメンテナー向けラベルガイドを参照してください。

ターミナルクロージャーラベルは運用ポリシーであり、この基盤ドキュメントの歴史的な status:* 分類体系の一部ではありません。現在の解決ラベルについてはメンテナーラベルガイドを、置き換えプロセスのルールについては置き換えガイドを参照してください。

rfc: RFC固有のステータス

Rev. 15 で廃止され、ライブラベルとして作成されたことはありません。RFC の状態ではライブの type:rfc と status:accepted ラベルを使用します。§8.1 を参照してください。

10. 完了の定義

「完了」には明確な意味があります。それを定義しなければ、各人がそれぞれ異なる定義を持つことになり、その食い違いが最悪のタイミングで表面化します。つまり、レビュー中、リリース中、あるいはユーザーがバグを報告した後にです。

あるアイテムが完了しているのは、以下のすべての条件が満たされている場合です：

コード変更について

• PRは、必要なレビュアーの階層（CODEOWNERSおよびリスクレベルに基づく）によってレビューされ、承認されました。
• すべてのCIチェックがパスしました: cargo fmt、cargo clippy、cargo test
• 新しいまたは変更された動作に対するテストが存在します（少なくともユニットテスト；ユーザー向け機能にはインテグレーションテスト）。
• PR 前にパスしていたテストカバレッジは失われていません
• PR の説明では、_何が_変更され、_なぜ_変更されたのかを説明します（単なる「バグ修正」ではなく、どのバグで、何が問題で、何を変更したのか）
• 変更がユーザーに見える動作に影響を与える場合、関連する参照ドキュメントは同じPRで更新されます。
• 変更が重要な場合、CHANGELOG.md の適切なマイルストーンセクションにエントリが追加されます。
• 変更がADRを必要とする場合、ADRは実装PRと同時、またはそれ以前に作成され、リンクされ、マージされます。

ドキュメントの変更について

• YAMLのフロントマターが存在し、有効です。
• すべての内部リンクが正しく解決されます
• ドキュメントが現在の動作を説明している場合、それは現在の master ブランチに対して正確です。
• ADR の場合、Nygard フォーマットに従い、status フィールドが含まれます。

リリース向け

• マイルストーンのすべてのアイテムが Done ステータスになっているか、または理由を説明するコメント付きで次のマイルストーンに明示的に移動されています。
• リリースの CHANGELOG.md のエントリは完成です。
• このマイルストーンで承認されたすべての RFC について、恒久的な処理方針が記録されており、必要な ADR と恒常的なドキュメントの更新がマージされ、残りのデリバリートラッカーがリンクされている
• このリリースは少なくとも1つのプラットフォーム（Linux x86_64以上）でテストされています。
• リリースタグはセマンティックバージョニングに従います。

「完了完了」ルール

ソフトウェアチームには、「完了」だが「完全に完了」ではない作業という概念があります。「完了」とはコードが書かれた状態を指し、「完全に完了」とはテスト、ドキュメント化、レビュー、マージ、リリースが完了した状態を指します。上記の「完了の定義」は「完全に完了」を説明しています。完全な定義を満たすまで、何も「完了」として扱うべきではありません。

11. 自動化

GitHub Projects v2 と GitHub Actions を組み合わせることで、手動の調整オーバーヘッドを大幅に削減する強力な自動化が可能になります。以下に、価値対労力比を考慮して実装すべき内容を記載します。

11.1 プロジェクトボードの自動化（ビルトイン、アクション不要）

プロジェクトの組み込み自動化設定でこれらを設定してください：

11.2 GitHub Actions ワークフロー

変更されたファイルによる自動ラベル付け:

アクティブなパスラベラーは、変更されたファイルに基づいてPRにスコープラベルを適用します。リスクラベルとサイズラベルは現在メンテナーが手動で適用しています。メンテナーラベルガイドは、ラベル名、自動化ステータス、リスクセマンティクスの最新の情報源です。

CODEOWNERS のレビューを自動リクエストする（CODEOWNERS に組み込まれており、Action は不要）:

GitHub は、CODEOWNERS ファイルが存在し、ブランチ保護で必要とされている場合に自動的に CODEOWNERS を適用します。アクションは不要です。

長期間更新のない issue の管理（メンテナー主導）:

現在、リポジトリには GitHub Actions の stale ワークフローが設定されていません。メンテナーは、影響を受けるコミュニティに対して定められた応答期間を確保しつつ、非アクティブな issue が蓄積するのを防ぐために stale パスを実行します。issue stale ポリシーは、タイミング、対象となるアクティビティ、除外条件、および再エンゲージメントに関する唯一の運用上の情報源です。issue トリアージのプロトコルには実行の仕組みのみが記載されています。

PRサイズラベリング（将来/オプション）:

後でサイズの自動化が追加された場合、メンテナーのラベルガイドのライブ名（size:XS から size:XL まで）に従い、プッシュされた更新時に再計算して、ラベルがレビュー中の差分を表すようにする必要があります。それまでは、サイズラベルはメンテナーによって適用されます。

PRマージ時のマイルストーンチェック (.github/workflows/milestone-check.yml):

マイルストーンが割り当てられたissueがリンクされていないままPRがマージされた場合に、警告（ブロックではなく）を表示します。これは厳格なゲートではなく、緩やかなリマインダーです。リリースへのトラッキングなしに作業が進められるのを防ぐことが目的です。

11.3 まだ自動化すべきではないこと

• 自動リリースドラフト: GitHub の release-drafter は便利ですが、設定のオーバーヘッドが増加します。チームが安定したリリースリズムを確立した後に導入してください。
• 自動依存関係の更新（Dependabot の PR）: Dependabot のセキュリティ更新を有効化します（無料、ノイズが少ない）。ただし、CI の安定性が確保されるまで、自動的なバージョンの更新は延期してください。バージョンを更新すると、CI の基盤が安定する前にノイズが発生します。
• スプリントプランニングの自動化: スプリントプランニングを自動化しないでください。このチーム規模では、キャパシティ、優先順位、チームのコンテキストに関する人間の判断が不可欠であり、自動化では代替できません。

12. フェーズドロールアウト

ガバナンスとツールは段階的に導入する必要があります。チームが各要素の存在意義を理解する前にすべてを導入すると、オーバーヘッドが生じます。

第1フェーズ・今週：「基礎」

最小限のガバナンス設定。チームの調整をすぐに開始します。

• ステータス、タイプ、優先度、マイルストーンフィールドを含むGitHubプロジェクトを作成します。
• 4つのプロジェクトビュー（ロードマップ、ボード、バックログ、マイワーク）を作成します
• コントリビューターコミュニケーションおよびメンテナーワークフローのドキュメントに記載された管理対象カテゴリで GitHub Discussions を有効化する
• 既存の提案（セクション 8.4）に対して、3つのRFC課題を作成する
• セクション7に記載されているIssueテンプレートを追加してください
• CODEOWNERS ファイルを作成する（セクション 6.1）
• master ブランチの保護ルールを有効にする（セクション 6.2）
• 残りのラベル階層（セクション 9）をリポジトリに追加する
• 3つのRFCの課題と次のリリースのマイルストーン課題を固定する

成功のシグナル: 新しい課題がプロジェクトに自動的に表示されます。チームはアクティブな作業を確認する場所やアイデアを投稿する場所を把握しています。

フェーズ 2 · v0.7.0 マイルストーン: 「The Pipeline」

承認されたRFCから完全なワークフローを確立し、バックログを埋める。

• プロジェクトにサイズ、リスクティア、およびコンポーネントのフィールドを追加
• バックログにマイクロカーネルアーキテクチャのRFCからの成果物を追加する
• バックログに、ドキュメント基準のRFCからの成果物を追加する
• 既存の3つの提案に対する最初の公式RFC投票を実施する
• 選定された基盤 ADR セット（docs RFC に従う ADR-001 から ADR-007）を完了する
• パスによる自動ラベル付けのActionsワークフローを実装する
• 古いIssueの管理ワークフローを実装する
• 当初予定されていた 2 つのチームではなく、単一の core-contributors チームとして Core Team GitHub チームを作成します。それと併記されていた CONTRIBUTORS.md の名簿項目は廃止されました。§5.3 を参照してください。

成功のシグナル: チームはボードを日常的に使用しています。アイテムは可視化されたゲートチェックを通じてステージを移動します。マイクロカーネルアーキテクチャに関するRFCには、記録された投票結果があります。

フェーズ3・v0.8.0マイルストーン：「コミュニティの成長」

プラグインシステムが実用的になるにつれて、外部からの貢献者が増えることになります。貢献のためのインフラストラクチャは準備できていなければなりません。

• PRのサイズラベリングワークフローを実装する
• プラグインSDK作業のための最初のバッチとなる good first issue 項目（最低5件）を作成する
• Good First Issue Index を現在の good first issue へのリンクを含むピン留めされた issue として追加する
• アイデアの促進閾値を設定し、最初のDiscussionアイデアをイシューに促進します
• コアチーム拡大プロセスの文書化：新しいコアチームメンバーを招待する基準

成功のシグナル: 少なくとも1人の外部コントリビューター（現在のチームに属していない人）が good first issue を通じて PR を提出する。Discussions の Ideas カテゴリにコミュニティが活発に参加している。

フェーズ4 · v1.0.0:「持続可能なガバナンス」

v1.0.0 までに、ガバナンスモデルは自立的に機能するようになっているべきです。チームがそれについて考える必要はなく、ただ機能するだけであるべきです。

• 機能した点と機能しなかった点を踏まえ、ガバナンス文書を見直して更新してください。
• リリース頻度（リリースの頻度、誰がリリースを行うか）を決定する
• プラグインレジストリのガバナンス文書（アーキテクチャRFCに基づく）を公開する
• マイルストーンベースの計画が緩すぎると感じる場合は、タイムボックス化されたサイクル（2週間または4週間）の導入を検討してください。
• Core Team メンバーが退任する、または非アクティブになるプロセスを文書化する

成功のシグナル: 直近6ヶ月の開発履歴において、パイプラインの一貫した使用が確認されています。問題は3日以内に分類され、PRは5日以内にレビューされています。CHANGELOGはマージのたびに更新されています。

付録 A: 用語集

バックログのグルーミング: チームがバックログをレビューし、項目の優先順位を再設定し、古くなった項目をクローズし、上位の項目が「定義済み」で着手可能な状態であることを確認する、定期的なチーム活動（通常は週次または隔週）。

ブランチ保護: 保護されたブランチへの直接プッシュを防ぎ、マージ前に要件（レビュー、CIチェック）を強制するGitHubの機能。

CODEOWNERS: PRで所有しているファイルが変更されたときに、指定した個人やチームへ自動的にレビューを依頼するGitHubのファイルです。

完了の定義: 作業項目において「完了」が具体的に何を意味するのかを定めた共有チェックリストです。共有された定義がなければ、「完了」の意味は人によってバラバラになってしまいます。

遅延合意（Lazy consensus）: 提案されたアクションが、定められた期間内に誰も異議を唱えなければ進行する意思決定の手法。日常的な意思決定に明示的な承認を求める手間を軽減します。

実力主義（Meritocracy）: 権限や影響力を、在籍期間や肩書きではなく、実証された貢献を通じて獲得するガバナンスモデル。オープンソースプロジェクトにおける標準的な形態です。

マイルストーン: GitHubの機能で、IssueとPRをリリースターゲットごとにグループ化します。マイルストーンはソフトウェアのバージョンを表します。

T シャツサイズ見積もり: 数値的なストーリーポイントではなく、抽象的なサイズ（XS、S、M、L、XL）を使用する見積もり手法。過去のキャリブレーションデータがなくても使いやすく、初期段階のチームには十分です。

トリアージ: 新しいissueをレビューして、それが有効であることを確認し、ラベルと優先度を割り当て、マイルストーンにリンクし、それらをバックログに含めるべきか、またはクローズすべきかを判断するプロセス。

付録B: 参考文献

• GitHub Projects ドキュメント: GitHub Projects v2 機能の完全なリファレンスです。
• GitHub Discussions ドキュメント: GitHub Discussions のセットアップガイドとガバナンスオプション。
• CODEOWNERS構文リファレンス: CODEOWNERSファイルの完全な構文。
• “Producing Open Source Software”: Karl Fogel 著: オープンソースプロジェクトの運営に関する決定版的な書籍。producingoss.com で無料で読めます。ガバナンス、コントリビューター管理、コミュニケーションに関する章は、直接的に応用できます。
• 「オープンソースガバナンスモデル入門」: Apache Software Foundation のガバナンスドキュメントは、成熟したオープンソースプロジェクトが権限と意思決定をどのように形式化するかを示す優れたモデルです: https://www.apache.org/foundation/governance/
• Vale 文章リンター: Vale: ドキュメント RFC で参照されています。good first issue のドキュメント改善ワークフローと統合されています。

この提案は、ZeroClaw v0.6.8 および先行する2つのアーキテクチャ・ドキュメントRFCを背景として策定されました。ここで提案するガバナンスモデルは、コミュニティ成長の初期段階にある学生主導のプロジェクト向けに、意図的に軽量な設計となっています。このモデルはスケールするように設計されており、チームの成長に合わせてプロセスを追加していくものであり、一度にすべてを導入するものではありません。

最も優れたガバナンスモデルは、チームが実際に従う最もシンプルなものです。ここから始め、学んだ内容に基づいて調整してください。