ub-governance

UB ガバナンス

概要

このスキルを、採用した現在のリポジトリまたはプロジェクトにおけるガバナンスの責任者として使用します。

このスキルは、通常のワークフローに基づく作業では簡潔に保ち、選択したモードまたはスコープで実際に必要な場合にのみ、より厳格な制御を有効にします。

組み込みの契約

これらのルールはこのスキルの基本契約であり、正しく適用するために別のドキュメントに依存してはなりません。

1. ユーザーが根拠を示して advanced を明示的に要求しない限り、デフォルトで lean プロファイルを使用します。
2. ガバナンスゲートの状態には、pass、fail、blocked のみを使用します。
3. 有界な例外にはすべて、owner、rationale、created_at、expires_at、follow_up を含めます。
4. 通常の Level 1 のワークフローに基づく作業では、ワークフローの成果物をデフォルトの永続的な運用記録として扱います。
5. 意思決定が単一の取り組みを超えて永続する場合、リポジトリ全体に及ぶ場合、高リスクの場合、または Level 2 で明示的に管理される場合に限り、ADR とクレームの仕組みにエスカレーションします。
6. ガバナンス上のブロッキング判断は、決定論的な成果物に結び付けます。

運用モード

1. repository mode：リポジトリの衛生管理、CI とリリースのガバナンス、ブランチまたはルールセットのポリシー、決定論的なツール
2. testing mode：動作優先の TDD ガバナンスと、シグナルの弱いテストに関するアンチパターンのレビュー
3. evidence mode：エビデンスのライフサイクル、ADR との整合性、クレームの検証、ゲートの準備状況
4. core-contract mode：プロファイル、ゲート、例外、レポートのセマンティクスの共有
5. full governance audit mode：リポジトリ、テスト、エビデンスの各チェックを、決定論的な順序で実行します

テストシグナルモデル

通常のガイダンスでは説明的な名前を使用します。 ツールと互換性のため、数値 ID は安定した内部コードとして維持します。

ブロッキングシグナル：

1. Type Redundancy（TG001）：型システムの保証を言い換えるランタイムテスト
2. Interaction Without Outcome（TG002）：観測可能な結果のアサーションを伴わないインタラクションのアサーション
3. Pass-Through Test（TG003）：単純なゲッターまたはセッターの受け渡しテスト
4. Happy-Path-Only Suite（TG004）：境界条件やエラーの表現がなく、正常系に繰り返し偏ったテストスイート

警告のみのシグナル：

1. Internal-Detail Bias（TG005）：公開動作より内部の詳細を検証している可能性が高いケース

機能的リアリズムのシグナルには、自動的に新しいゲートを追加するのではなく、リスクに応じたガイダンスを使用します。

1. Local Source Mocking（TG006）：レビュー対象の動作に関わるローカルなアプリケーションソースをテストで置き換えること
2. Uncontracted Test Double（TG007）：モック、スタブ、フェイク、フィクスチャ、ルートインターセプトに、明確な境界上の理由または契約のエビデンスがないこと
3. Mock-Dominant Test（TG008）：テストの大部分が、観測可能な結果ではなく、テストダブルのセットアップや呼び出しのアサーションで占められていること
4. Missing Functional Guard（TG009）：リスクのある動作について、公開サーフェスに対する機能、統合、契約、コンポーネント、または E2E のチェックがないこと
5. Mutation Survivor on Changed Logic（TG010）：ミューテーションのエビデンスがすでにスコープ内にあるとき、変更された重要なロジックにレビューされていない生存ミュータントがあること
6. Snapshot/Coverage-Only Proof（TG011）：動作の変更の証明が、スナップショット、レンダリングのスモークテスト、カバレッジ、または例外が発生しないことの確認だけに依存していること

トリガーに応じたリファレンスの読み込み

これらの読み込み階層を文字どおりに使用してください。 トリガーが有効でない場合は、リファレンスが存在するというだけの理由で読み込まないでください。

• [phase:decision-boundary] ワークフロー成果物で十分か、ADR とクレームのエスカレーションが必要かを判断する際に、 references/decision-memory-and-claims.md を読み込みます。
• [phase:testing-mode] テストポリシーを確認する際、または テストのアンチパターンモデルを適用する際に、 references/testing-policy-and-signals.md を読み込みます。
• [phase:testing-mode] タスクが TDD の実行順序、回帰テストを先行させるバグ修正、またはテストワークフローの衛生管理に関する場合は、 references/execution-playbook.md を読み込みます。
• [phase:command-or-audit] ユーザーがチェックの実行方法を尋ねた場合、または監査パスを実行する場合は、 references/governance-commands.md を読み込みます。
• [edge:glossary-or-normalization] 用語集の支援または表現の正規化が必要な場合に限り、 references/vocabulary.md を読み込みます。
• [edge:repository-mode] リポジトリガバナンスが実際に対象となる場合に限り、 references/repository-baseline.md、 references/github-implementation-playbook.md、および references/release-please-playbook.md を読み込みます。
• [edge:evidence-level-2] 明示的に Level 2 またはエビデンスを重視したガバナンスが有効な場合に限り、 references/evidence-baseline.md、 references/evidence-lifecycle.md、 references/evidence-artifact-taxonomy.md、 references/ci-artifact-contract.md、および references/stack-baseline.md を読み込みます。
• [edge:schema-or-data] これらの具体的な成果物を作成または検証する場合に限り、 references/high-risk-paths.yaml、 references/agent-validation-record.schema.json、 references/adr-registry.schema.json、 references/claim-register.schema.json、および references/adr-template-madr.md を読み込みます。
• [edge:authoring-conventions] ルーティングまたは共通の作成構造を調整する場合に限り、 ../ub-authoring/references/authoring-conventions.md を読み込みます。

コアワークフロー

1. リポジトリの実態に基づいて、要求されたガバナンスモードと評価対象範囲を特定します。
2. プロファイルを選択します。デフォルトは lean、明示的な根拠がある場合に限り advanced を選択します。
3. 通常のワークフローに基づく作業では、Level 1 のファストパスを優先し、永続的な記録はワークフロー成果物に残します。
4. 意思決定の対象範囲、リスク、または明示的なガバナンス実行によって必要な場合に限り、エスカレーションします。
5. 選択したモードのコントロールを実行し、出力の決定性を保ちます。
6. 範囲を限定した例外は、正式な例外契約を通じてのみ適用します。
7. 成果物のパスを含む、追跡可能なゲートの判定結果を出力します。

簡単な例

1. Does this auth change need an ADR or claim work? evidence mode と意思決定境界のリファレンスを使用し、通常のワークフロー成果物で十分か、変更が真にリポジトリ全体に関わるもの、高リスク、または Level 2 に該当するかを判断します。
2. Are these tests mostly checking mock calls without user-visible outcome assertions? testing mode を使用してテストシグナルモデルを適用し、外部から観測可能な結果を確認せずにインタラクションだけを検証している場合に限り、該当する可能性のある TG002 の指摘をブロッキングとして扱います。
3. Show me the host repository's maintenance checks for README, AGENTS, and skill schema. これをガバナンス経由で処理しないでください。これらのチェックはホストリポジトリ独自のメンテナンス／チェック機能に属します。

使用しない場合

• ワークフローの受付、PRD の具体化、ロードマップの作成、スプリントの準備、または再開可能な取り組みのオーケストレーションには、このスキルを使用しないでください。これらは ub-workflow に委ねてください。
• タスクがガバナンスポリシーやゲートのセマンティクスではなくコード変更に関する場合、フレームワーク固有の実装ガイダンスを提供する主な手段として、このスキルを使用しないでください。
• タスクの実際の担当が ub-quality である場合、汎用的なドキュメント正規化レイヤーとしてこのスキルを使用しないでください。

モード別ワークフロー

リポジトリモード

1. リポジトリのベースライン成果物と決定論的なツールポリシーを確認します
2. CI、権限、マージゲートのコントロールを確認します
3. Conventional Commits と release-please を使用したリリースポリシーを確認します

テストモード

1. スタックとテストランナーを検出します
2. 報告された不具合は、コード修正を受け入れる前に、回帰を優先する作業として扱います
3. TG001 から TG004 をブロッキングとして適用し、TG005 は警告のみとします
4. TG006 から TG011 は機能的なリアリズムに関する指針として適用し、リスク、エビデンスレベル、または明示的なゲートの範囲が正当化する場合に限り、適用を強化します
5. 振る舞いを変更する作業では、振る舞いを優先する TDD フローを必須とします
6. 助言的な指針を新たなゲートに変えることなく、テストに関する指針を読みやすく、境界を意識した、決定論的なものに保ちます

エビデンスモード

1. changeType、evidenceLevel、profile を分類します
2. スコープ上必要な場合、高リスクのパスへの影響を検出します
3. 決定のスコープに合致する、最も軽量で永続性のある記録を選択します
4. 通常のレベル 1 作業では、ワークフローに裏付けられたイニシアチブの成果物を、デフォルトの運用記録として扱います
5. レベル 2、リポジトリ全体にわたる永続的な決定、または明示的な高リスクガバナンスが適用される場合に限り、ADR との整合性確認にエスカレーションします
6. ブロッキングの根拠がクレームに依存する場合に限り、クレームレジスターの検証を必須とします
7. 選択したパスに必要な成果物と鮮度を検証します

コアコントラクトモード

1. 正式なプロファイル、ゲート、例外、レポートのセマンティクスを適用します
2. ステータス表現を統一し、レポートコントラクトの使用を標準化します
3. 重複または競合するスキーマ定義を拒否します

ガバナンス全体監査モード

1. repository mode を実行します
2. testing mode を実行します
3. evidence mode を実行します
4. 正式なレポートセクションに出力を集約します

ルール

• デフォルト設定は簡素に保ち、高度な制御は明示的に有効化します。
• 通常のレベル 1 のワークフローに裏付けられた作業では、リポジトリの ADR 機構がデフォルトの記録であるかのように示してはいけません。
• 例外メタデータは、範囲を限定し、明示的で、期限付きのものとします。
• メインスキルに短いルールがすでに組み込まれている場合、ファイル間で正式なコントラクトの定義を重複させてはいけません。
• リポジトリ保守用ツールが、簡素なガバナンス指針と自動的に同じものになるわけではありません。

出力要件

重要なガバナンス出力を生成する際は、次の項目を含めます。

1. environment_note
2. scope_note
3. decision_note
4. gate_note
5. exception_note
6. validation_note

該当する場合は、モード固有のセクションを追加します。

1. テストモードでは quality_gate_note
2. エビデンスモードでは evidence_inventory と claim_note

完了チェックリスト

• 選択したモードが明示されています。
• プロファイルの選択（lean または advanced）が明示されています。
• 通常のレベル 1 の迅速な経路と、レベル 2 のエスカレーション経路が明示されています。
• 必要な決定論的成果物が存在するか、明示的に不足として示されています。
• ゲートの結果を追跡でき、再現可能です。
• 例外には正式なフィールドを使用し、範囲を限定しています。
• ガバナンス指針は自己完結しており、内部で一貫しています。