Skip to content

OTR_QualityCompass

Jump to bottom
nishi_74322014 edited this page Oct 30, 2026 · 6 revisions

品質の羅針盤

概要

コーディング・エージェントに徹底的に書かせ、人はレビュー役に徹する開発で、**人が決める「レビューの方針」**を纏める。

  • 人は、個々の変更を具体的にレビューするより、どこを・何で・どれだけ確かめるかを決める羅針盤の役割を担う
    （Open 棟梁の課題と対応の 7）。
  • 羅針盤は、品質マップ（機能・領域ごとに、品質特性とリスクを当て、検証の手段と重みを決める表）と同じ発想の取り組みである。
    違いは、読み手にエージェントが加わることで、エージェントが読めて従える形（インストラクション・テストの規約・フック）に落とす。
  • 本ページは、両リポジトリに共通の方針と、導入の経緯を纏める。導入した後の一次情報は、各リポジトリの QUALITY.md である。

状態：導入中（2026-10-31 時点）。Open 棟梁は導入済みで、汎用認証サイトはこれからである。

リポジトリ 状態 内容
OpenTouryo 導入済み（#640。2026-10-30 に完了） origin/develop（0be547ca。PR #641 のマージ）に QUALITY.md・3 段の仕組み・期待値の根拠の属性が入った。develop・master とも expectation-change を必須のチェックにした。未リリース（最新のタグは 03-20）
MultiPurposeAuthSite 未着手（#315） エージェントによるレビューと修正（#294）の後に導入する見込み。下の汎用認証サイトの品質マップなどは、案のままである

決定事項

論点 決定
置き場所 各リポジトリの QUALITY.md。スキルにはせず、インストラクションにする（エージェントが常に読む）
承認の記録 Git・GitHub の操作は人が行う。スルーできないよう、フックと CI で塞ぐ（「3. テストの保護」）
品質マップの粒度 名前空間
レビューのモデル 書いたモデルとは別のモデルでレビューすることを提案に含める（現時点で費用の問題は無い見込み）

Open 棟梁への導入で、次を決めた（#640）。汎用認証サイトに導入するときの出発点になる。

論点 決定
Golden の期待値の変更 正規化しても差分が残る変更だけを数える。実行のたびに変わる値（日時・署名値など）を数えると、承認が形だけになるため
仕組み自体の変更 フック・検出器・ワークフローの変更・削除にも、トレーラーを求める（追加は数えない）。仕組みを緩めれば、期待値をいくら変えても通るため
CI の検出器 PR の側ではなく、ベース側の版を使う。PR で検出器を緩めても素通りにならない
develop の必須チェック develop にも expectation-change を置く。develop に必須チェックを置かないのはビルドを待たないためで、数秒で終わるこのチェックは当たらない
導入より前のコミット CI の対象にしない。規約が無かった時点のコミットだからである（個別に指定すれば検査でき、計測に使える）

詳細

羅針盤の構成

# 要素 何を決めるか
1 品質マップ 名前空間ごとのリスクと、検証の手段・重み、人が必ず見る箇所
2 正の定義 テストの期待値が、何（仕様・外部の基準）に基づくか
3 テストの保護 期待値・テストの変更を、どう記録し、どう塞ぐか
4 レビューの観点 名前空間ごとに、エージェントのレビューが見るべき観点。レビューのモデル
5 フィードバックの輪 見つかった問題を、回帰テストと観点と品質マップに戻す流れ
6 計測 羅針盤が効いているかを見る指標（開発基盤のKPIとKGIの「AI 駆動開発の品質の指標」）

置き場所：QUALITY.md（インストラクション）

  • 各リポジトリのルートに QUALITY.md を置き、1・2・3・4・5 を書く。
  • インストラクションとして常に読ませる：AGENTS.md から「変更の前に QUALITY.md を読む」と参照し、CLAUDE.md からも読み込む（@QUALITY.md）。
    スキル（必要なときだけ読まれる）にしないのは、品質の方針が、どの作業にも掛かる前提だからである。
  • 長くなりすぎないよう、QUALITY.md には方針と表だけを置き、詳しい手順は既存の TESTING.md などを参照する。

1. 品質マップ

リスクは、壊れたときの影響（セキュリティ・データ・後方互換性）と、仕様の複雑さで付ける。
リスクの高い名前空間ほど、検証の手段を重ね、人の確認点を増やす。 リスクの低い名前空間は、エージェントに任せ、壊れたら作り直す（コアと枝葉）。

Open 棟梁（導入済み。名前空間の接頭辞 Touryo.Infrastructure. は省略。一次情報は QUALITY.md の 1 節）

名前空間 リスク 正の根拠 検証の手段 人が必ず見る箇所
Public.Security（.Aead・.Jwt・.KeyExg・.Pwd・.Xml） 高 RFC（JWS・JWE・JWK）、XML 署名（W3C）、NIST の推奨 NUnit、Golden（net48・net10.0・Linux）、CodeQL 既定値（アルゴリズム・鍵長）の変更、暗号文の互換性、署名の検証の対象
Framework.Authentication 高 OAuth2 / OIDC・SAML2 の仕様 NUnit（対象モジュールの行 94.6%）、汎用認証サイトの E2E 検証を省く分岐、後方互換性（パラメタ・既定）
Public.Db 中〜高 各 DBMS の文法（リテラル・エスケープ） NUnit、クロス DB（Oracle・MySQL・PostgreSQL） リテラル・識別子の組み立て（SQL インジェクション）
Public.Str（CustomEncode）・Public.Util（RandomValueGenerator） 中〜高 エンコードの仕様（HTML・URL・Base64）、乱数 NUnit エンコードする文字の範囲、乱数の生成元
Framework.Business・.Dao・.Presentation・.Transmission・.Exceptions、ServiceInterface 中 方式の設計書・ANALYSIS.md 疎通（Golden のサンプル） 方式の変更（例外・トランザクション・ログ）
Business.*（ベースクラス2） 中 方式の設計書 疎通 利用者がカスタマイズする箇所の互換性
Public.Log・.IO・.Str・.Dto・.Util・.Xml ほか（上の行に挙げたクラスを除く） 中〜低 — NUnit 例外の型・既定値の変更（後方互換性）
CustomControl・Framework.RichClient など、UI 寄りの部品 低 — 疎通 原則として見ない
ツール・サンプル（Frameworks/Tools・Samples・Samples4NetCore） 低 — 疎通 原則として見ない（使い捨てが効く）

汎用認証サイト（案。名前空間の接頭辞 MultiPurposeAuthSite. は省略）

名前空間 リスク 正の根拠 検証の手段 人が必ず見る箇所
Extensions.Sts・TokenProviders・Util.Sts 高 RFC 6749・7636（PKCE）・9449（DPoP）・8705（mTLS）、OIDC Core、FAPI E2E（根拠付き、JWT は実装と独立に検証）、適合性テスト（D-14、導入予定） 「観測」から「検証」への昇格、拒否すべき要求の扱い
SamlProviders 高 SAML 2.0 Core・Bindings E2E（SA-*）、Open 棟梁の NUnit 署名の対象と消費する要素の一致（XSW）、リプレイ、Audience、有効期限
Controllers 高 OIDC・OAuth2（エンドポイント）、RFC 7591・7592（DCR） E2E 認可の抜け、redirect_uri の完全一致、管理画面へのアクセス
Extensions.FIDO・Password 高 WebAuthn、パスワードの保存の推奨 E2E 認証の強度、既定値
Util.IdP（上流の IdP との連携） 中〜高 OIDC・SAML2 E2E（RT-*） 鍵の選び方、ロールオーバー
Data・Entity・Manager・Co 中 — E2E（コンテナ、DB 3 方言） 秘密の扱い（暗号化・ログへの出力）、設定キーの互換性
ViewModels・Resources・Notifications・Log 低〜中 — E2E（WebUI） ログ・通知に秘密が出ないこと

2. 正の定義（何を正とするか）

  • テストの期待値には、根拠を書く。汎用認証サイトの E2E は、テストケースごとに根拠（RFC・OIDC の該当箇所）を書く形式になっている（TESTCASES.md）。\
  • 「検証」と「観測」を分ける（汎用認証サイトの既存の方式）。仕様が幅を持つ項目は観測とする。
    観測から検証へ上げるのは、人が根拠を確かめてから。
  • Open 棟梁では、次のように入れた（QUALITY.md の 2・7 節）。
    • NUnit の属性 [Basis]（検証）と [Observation]（観測）で書く。根拠の種類は、仕様（節まで）・別実装・設計（文書に書いた約束）・Issue の 4 つである。
    • Golden は全体を観測とする。仕様に照らせる値は、NUnit に [Basis] 付きで書く。
    • 汎用認証サイトとの違い：汎用認証サイトの E2E は観測を判定しないが、Open 棟梁の観測は落ちる。
      部品のライブラリなので、振る舞いが変わること自体が、利用者への影響（後方互換性）になるためである。
  • 外部の基準を、最終的な正とする：適合性テスト（D-14）、CodeQL などの静的解析。
    同じエージェントが書いたテストとコードは、仕様の読み違いを共有しうるため。

検証（[Basis]）と観測（[Observation]）の分析

検証は「正しいと言える値を確かめる」テストで、観測は「今そうなっていることを記録する」テストである。
どちらも値を見るが、その値が正しいと言える根拠があるかどうかが違う。テストが通るという事実だけでは、この 2 つを区別できない。

用語の関係は次のとおりである。根拠があるから、検証と言える。

用語 意味 どこに表れるか
根拠 期待値が何に基づくか [Basis("RFC 7617 2（…）")] の引数
検証 根拠が付いたテストの分類 [Basis] が付いていること
観測 根拠が無いテストの分類 [Observation("…")]。引数は根拠ではなく、根拠が無い理由
未分類 どちらも付いていないテスト 属性なし
検証 観測
問い 仕様に照らして正しいか 前と変わっていないか
期待値の出どころ 仕様、別の実装、文書にした約束、Issue 今の実装の振る舞い
通ったときの意味 正しいことの裏付け 変わっていないことだけ（正しいとは言えない）
違いが出たときの意味 不具合 変わってよいかを人が判断する
一般的な呼び名 仕様ベースのテスト 特性テスト（Characterization Test）、ゴールデン マスター テスト

同じメソッドでも、期待値ごとに分かれる。

  • Basic 認証：: で連ねて Base64 にするのは RFC 7617 2 に書かれているので検証、: の無い形を id だけとして受けるのは、RFC に書かれていない今の振る舞いなので観測である。
  • ハッシュ：計算の結果はテスト ベクタで確かめられるので検証、Default が SHA256 になるのは、約束が書かれていないので観測である。

[Observation] は、正しさを判断する材料が、まだ無いという印である。次の場面で使う。

場面 例
標準の仕様の範囲外 CIBA の request_uri（CIBA Core には無く、独自の拡張）
仕様の範囲内だが、幅がある SHOULD・MAY の項目（認可コードの再利用のときに、発行済みのトークンも失効させるか）
仕様に関係しない 既定値など、文書に約束が無い実装の都合
まだ確かめていない 根拠がありそうだが、原典で確認していない
  • 判断が決まれば、[Basis] に上げられる。例えば、既定値を XML コメントに約束として書けば、「設計」の根拠が付く。
  • Open 棟梁では、検討の余地が無くても、利用者が今の振る舞いに依存しているかもしれないので、変わったら気付けるように残すという役割もある。

分ける理由は次のとおりである。

  1. 「テストが通る＝正しい」という誤解を防ぐ。今の実装を写しただけのテストは、実装に誤りがあれば、誤りごと固定する。
  2. 落ちたときの対応が変わる。検証ならコードを疑い、観測なら変わってよいかを判断する。
  3. テストの書き換えに気付きやすくする。根拠の無い期待値は、書き換えて通しても気付きにくい。
  4. 読み違いの共有を見えるようにする。同じエージェントが書いたテストとコードが一致しても、独立した確認にはならない。期待値を外部の根拠と結び付けて、初めて独立する。

手法との関係は次のとおりである。

手法・分野 根拠の扱い
TDD 明示しないのが普通である。テスト自体を仕様とみなす
BDD・ATDD、要件駆動、仕様駆動 中心的な考え方である。受け入れ基準や要件とテストを結び付ける。[Basis] の根拠を、要件の番号や節にして使える
安全性が重要な分野（航空・車載・医療機器） 要件とテストの追跡が、規格（DO-178C、ISO 26262、IEC 62304）で求められる
標準の仕様の実装（暗号・プロトコル） RFC のテスト ベクタや適合性テストを使うのが普通である
一般の業務システム・Web 開発 テストに Issue の番号を付ける程度が多い
  • 要件駆動では、理想的には観測は要らない。要件があれば、その時点で正しい値が決まるためである。
    実際には、要件で決まっていない部分（既定値、エラーの細部、順序）と、既存のコードに後からテストを足す部分に残る。
  • 発想は一般的だが、属性で機械的に数え、節まで書き、原典で確かめるのは、一般の開発より厳しい。暗号や認証を扱うなら、妥当な水準である。
  • 期待値の正しさを誰が保証するかは、「テスト オラクル問題」として昔からある論点である。テストとコードを同じエージェントが書くと、外部の根拠を書かせる意味が大きくなる。

Open 棟梁で付けた結果は次のとおりである（テスト メソッド単位。719c449b の時点、#640 の報告）。

名前空間 テスト 検証 観測のみ 未分類
Public.Security 192 67（35%） 10（5%） 115（60%）
Framework.Authentication 152 100（66%） 3（2%） 49（32%）
計 344 167（49%） 13（4%） 164（48%）
  • 未分類が多いのは、付け残しではない。根拠を書けないテストが多いためである。
    同じ実装の往復だけを見るテスト（暗号化して戻せる、署名して検証できる）は、動作の確認にはなるが、仕様どおりであることは示せない。Public.Security の割合が低いのは、このためである。
  • 観測は、すべて既定値など、約束の書かれていない振る舞いだった。
  • 根拠を原典で確かめる作業で、仕様とのずれが見つかった（#642・#643・#644）。根拠を付けることは、記録であると同時に、問題の発見の手段でもある。

3. テストの保護

エージェントは、テストを書き換えて通すことがある（ImpossibleBench。Open 棟梁の課題と対応の 7）。
Git・GitHub の操作は人が行うが、人の注意に頼らず、仕組みでスルーできないようにする。

期待値の変更の定義

次を「期待値の変更」と呼ぶ。機械的に検出できるものに絞る。

リポジトリ 検出する変更
両方 テストの削除（テスト属性の行の削除）、Skip・Ignore の追加
Open 棟梁 Golden の期待値（Tests/Golden/**/Result*.txt）の、正規化しても差分が残る変更。[Explicit]・Assert.Ignore の追加。[Basis] の削除（検証から観測への格下げ）
汎用認証サイト TESTCASES.md の「検証」の行の削除、「検証」から「観測」への移動

承認の記録：コミットのトレーラー

  • 期待値の変更を含むコミットには、トレーラーで理由を書く。

    Expectation-Change: <何が・なぜ変わったか（仕様の該当箇所・Issue 番号）>

  • コミットするのは人なので、トレーラーを書くこと自体が、人が差分を見て承認した記録になる。

3 段で塞ぐ

段 仕組み 何を塞ぐか Open 棟梁の状態
1. エージェント Claude Code の PreToolUse フック：期待値のファイルの編集を、確認（ask）にする エージェントが黙って期待値を書き換えること。人に、その場で見せる 導入済み（.claude/settings.json → ExpectationGuard.ps1）。止めずに確認を出す
2. 人のコミット Git の commit-msg フック：ステージした差分に期待値の変更があり、トレーラーが無ければ、コミットを拒否する 期待値の変更を、理由無しにコミットすること 導入済み（.githooks/commit-msg → CheckExpectationChange.ps1）。各自の手元で有効にする
3. PR CI のチェック：PR のコミットに、トレーラーの無い期待値の変更があれば失敗させる。ブランチの保護で、必須のチェックにする フックの未設定や --no-verify での迂回。最終的にスルーできないのはここ 導入済み（expectation-change.yml。develop・master とも必須のチェック）
  • フックは、リポジトリ内のフォルダ（例：.githooks/）に置いて版管理し、git config core.hooksPath で有効にする（設定は人が行う。手順を QUALITY.md に書く）。
  • 段 1 の設定（.claude/settings.json）もリポジトリに置き、版管理する。
  • 導入の前（初回の計測）：Open 棟梁の 2026-10 の期待値の変更 8 件は、すべてコードの変更と同じコミットだった。
    典型的な改ざんではないが、承認の記録が残っていなかった。
  • 導入の後：段 2 はトレーラーの無い変更を実際の git commit で拒否し、段 3 は PR #641 で動いた（#640 の報告）。

4. レビューの観点とモデル

  • 名前空間ごとの観点を、QUALITY.md にチェックリストとして書く（インストラクションなので、レビューのたびに読まれる）。
  • 例（認証・署名）
    • SAML2：署名の対象と消費する要素の一致（XSW）、InResponseTo・リプレイ、Audience、NotBefore / NotOnOrAfter、署名と暗号のアルゴリズム。
    • OIDC / OAuth2：state・nonce、redirect_uri の完全一致、PKCE、認可コードの再利用、トークンの紐付け（mTLS・DPoP）、alg の固定。
    • 暗号：既定値、鍵長、モード（ECB を使わない）、乱数、鍵の導出。
    • DB：リテラル・識別子の組み立て、DBMS ごとのエスケープ。
  • 作る役と検証する役を分ける
    • 少なくとも、書いたセッションとは別のセッション（文脈を引き継がない）でレビューする。
    • さらに、書いたモデルとは別のモデルでレビューすることを提案する。同じモデルは、同じ読み違いをしやすいためである。
      品質マップの「高」の名前空間に触れる変更から始める。現時点で、費用の問題は無い見込み。
    • CodeQL のような、LLM とは別系統の検査も併用する。
  • Open 棟梁での最初の実施：#642・#643・#644 の修正を、書いたモデル（Claude Opus 5.5）とは別のモデル（Claude Sonnet 5.5）の別のセッションでレビューした。
    指摘 6 件を判定し、書いたモデルでは見つからなかった指摘として数えたのは 1 件（根拠の書き方の誤り）である。
    指摘をそのまま不具合と数えず、判定を経てから数えることにした（#640 の報告）。

5. フィードバックの輪

見つかった問題は、次の 3 か所に戻す。

  1. 回帰テスト：Issue に紐付けて残す（汎用認証サイトの RT-<Issue> の形式。既に 58 件・263 ケース）。
  2. レビューの観点：QUALITY.md のチェックリストに足し、次からレビューで拾えるようにする。
  3. 品質マップ：その名前空間のリスク・検証の手段・人の確認点を見直す。

例：Open 棟梁の SignedXml2.Verify（Public.Security.Xml）の XSW の修正（2026-10-19）は、
回帰テスト（署名の付け替えを拒否する）、SAML2 の観点（署名の対象の一致）、品質マップ（Public.Security の「人が必ず見る箇所」）に戻す。

6. 計測

  • 開発基盤のKPIとKGIの「AI 駆動開発の品質の指標」を、リリースごとに計測する。
  • 羅針盤に固有のものとして、次を足す。
    • 期待値の変更のうち、トレーラー（理由）が付いたものの割合（3 段で塞げば 100% になるはず。漏れがあれば仕組みの穴）。
    • 品質マップの「高」の名前空間で、根拠付きのテストの割合。
    • 別モデルのレビューで見つかり、書いたモデルのレビューでは見つからなかった指摘の数。
  • Open 棟梁の初回の値（#640 の報告。2026-10-30）
指標 値 範囲
期待値の変更のうち、トレーラーが付いたものの割合 100%（4 コミット中 4） 導入のブランチの 16 コミット。導入前の 1 件は見ていない
リスク「高」の名前空間で、根拠付きのテストの割合 49%（344 メソッド中 167） Public.Security は 35%（192 中 67）、Framework.Authentication は 66%（152 中 100）。719c449b の時点
別モデルのレビューでだけ見つかった指摘 1 件 #642・#643・#644 の修正の 1 回のレビュー
  • 残りの多くは未分類で、付け残しではなく、根拠を書けないテストである（同じ実装の往復だけを見るテストなど）。
    同じ実装の往復は仕様の読み違いを共有しうるので、検証と数えていない。
  • トレーラーの 100% は、導入の期間の 4 件だけの値で、効き目の証拠としては、まだ小さい。

残り

  • Open 棟梁：品質マップのリスクと「人が必ず見る箇所」の人の確認（#640 の報告で「未」だった。その後の状況は記録が無い）。段 1 も、同じ報告の時点では実地で確かめていない。
  • Open 棟梁：根拠を付ける際に見つかった #642・#643・#644 の修正。
  • 汎用認証サイト：#315 の導入。上の Open 棟梁の決定を出発点に、差を埋める。

起票した本文（記録）

2026-10-29 に両方のリポジトリに起票した Issue の本文。導入の結果との差は、ここでは直さない。

  • 両リポジトリの仕組み（QUALITY.md の構成・トレーラー・フック・CI）には、今は差がある。
    起票後の修正では、互いの Issue を相互参照しながら差を埋めていく（共通にできるものは揃える）。
  • 起票済み：OpenTouryo #640、MultiPurposeAuthSite #315（2026-10-29。互いに「関連」として参照）。

OpenTouryo

# 品質の羅針盤（QUALITY.md・期待値の変更の承認・レビューの観点）の導入

## 背景
コーディング・エージェントに書かせ、人はレビューの方針を決める（羅針盤）進め方を取る。
方針は、品質マップ（名前空間ごとのリスク・検証の手段・人が必ず見る箇所）と同じ発想で、
エージェントが常に読むインストラクション（QUALITY.md）と、スルーできない仕組み（フック・CI）に落とす。
方針案：[NetDevInfraWiki の OTR_QualityCompass（品質の羅針盤）](https://github.com/NetDevInfraWGinOSSConsortium/NetDevInfraWiki/wiki/OTR_QualityCompass)
関連：OpenTouryoProject/MultiPurposeAuthSite#315（相互参照しながら差を埋める）

## エージェントの作業
- [ ] `QUALITY.md` を作る（リポジトリのルート）
  - 品質マップ（名前空間の単位）：`Public.Security.*`・`Framework.Authentication`・`Public.Db` を「高」〜「中〜高」とする案から始める
  - 正の定義：期待値には根拠（仕様の該当箇所・Issue）を書く。外部の基準（CodeQL）を最終的な正とする
  - 期待値の変更の定義：Golden の `Result*.txt` の変更、テストの削除、`[Ignore]`・`Assert.Ignore` などの追加
  - レビューの観点（チェックリスト）：署名・暗号、SAML2・OAuth2 / OIDC のクライアント、DB（リテラル・識別子）
  - フィードバックの輪：見つかった問題を、回帰テスト・観点・品質マップに戻す
  - 別モデルによるレビュー：品質マップの「高」の名前空間に触れる変更は、書いたモデルとは別のモデルでレビューする
- [ ] `AGENTS.md`・`CLAUDE.md` から `QUALITY.md` を読み込む（インストラクションにする）
- [ ] 期待値の変更のトレーラー `Expectation-Change: <理由>` を規約にする
- [ ] 段 1：Claude Code の PreToolUse フック（`.claude/settings.json`）で、期待値のファイルの編集を確認付きにする
- [ ] 段 2：commit-msg フック（`.githooks/`）で、トレーラーの無い期待値の変更のコミットを拒否する
- [ ] 段 3：GitHub Actions に、PR のコミットのトレーラーを検査するジョブを足す（develop・master 宛の PR）
- [ ] NUnit・Golden の期待値に根拠を書く形式を、`Public.Security`・`Framework.Authentication` から入れる

## 人の作業
- [ ] 段 3 のジョブを、ブランチ保護の必須のチェックにする
- [ ] 各自の手元で `git config core.hooksPath .githooks` を設定する（手順は QUALITY.md）
- [ ] 品質マップのリスクと「人が必ず見る箇所」を確認する

## 検討事項
- アサーションの緩和（比較を弱めるなど）を、どこまで機械的に検出するか（残りはレビューの観点にする）
- 別モデルのレビューで使うモデル（同じ提供元の別モデルか、別の提供元か）
- Claude Code 以外のエージェントでの段 1 の扱い（段 2・3 で最終的には塞がる）

## 完了条件
- QUALITY.md・フック・CI がリポジトリにあり、トレーラーの無い期待値の変更が PR を通らない

MultiPurposeAuthSite

# 品質の羅針盤（QUALITY.md・期待値の変更の承認・レビューの観点）の導入

## 背景
OpenTouryo の同名の Issue と同じ方針を、汎用認証サイトに入れる。
方針案：[NetDevInfraWiki の OTR_QualityCompass（品質の羅針盤）](https://github.com/NetDevInfraWGinOSSConsortium/NetDevInfraWiki/wiki/OTR_QualityCompass)
関連：OpenTouryoProject/OpenTouryo#640（相互参照しながら差を埋める）

## エージェントの作業
- [ ] `QUALITY.md` を作る（リポジトリのルート）
  - 品質マップ（名前空間の単位）：`Extensions.Sts`・`TokenProviders`・`SamlProviders`・`Controllers`・`Extensions.FIDO` を「高」とする案から始める
  - 正の定義：TESTCASES.md の根拠・「検証」と「観測」の区別を正式な規約にする。適合性テスト（D-14）を最終的な正として位置付ける（導入は品質の向上の後）
  - 期待値の変更の定義：TESTCASES.md の「検証」の行の削除・「観測」への移動、テストの削除、Skip の追加
  - レビューの観点（チェックリスト）：SAML2（XSW・リプレイ・Audience・有効期限）、OIDC / OAuth2（state・nonce・redirect_uri の完全一致・PKCE・トークンの紐付け・alg の固定）
  - フィードバックの輪：見つかった問題を、回帰テスト（`RT-<Issue>`）・観点・品質マップに戻す
  - 別モデルによるレビュー：OpenTouryo と同じ
- [ ] `AGENTS.md`・`CLAUDE.md` から `QUALITY.md` を読み込む
- [ ] 期待値の変更のトレーラー `Expectation-Change: <理由>` を規約にする（OpenTouryo と共通）
- [ ] 段 1：PreToolUse フック（`.claude/settings.json`）
- [ ] 段 2：commit-msg フック（`.githooks/`）
- [ ] 段 3：GitHub Actions を新設する（このリポジトリには、まだワークフローが無い）
  - PR のコミットのトレーラーを検査するジョブ
  - テストを変えたのに TESTCASES.md が作り直されていないことを検出するジョブ（TESTCASES.md は生成物のため）

## 人の作業
- [ ] GitHub Actions の有効化と、段 3 のジョブのブランチ保護の必須のチェック化
- [ ] 各自の手元で `git config core.hooksPath .githooks` を設定する
- [ ] 品質マップのリスクと「人が必ず見る箇所」を確認する

## 検討事項
- OpenTouryo と同じ
- TESTCASES.md の作り直しを CI で行うか、検出だけにするか（E2E の実行には DB・コンテナが要る）

## 完了条件
- OpenTouryo と同じ

参考

Tags: 再構築

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki
開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally