Merge pull request #8 from y-ok/fix/plugin-build-and-agents

Fix/plugin build and agents

Author: y-ok

.gitignore

@@ -1,4 +1,5 @@
 target/
+.flattened-pom.xml
 
 !.mvn/wrapper/maven-wrapper.jar
 !**/src/main/**/target/

AGENTS.md

@@ -1,182 +1,155 @@
 # 背景
 
-これは、AIに対するルールファイルです。
-AIがコーディングを行う際に、このルールファイルを常に参照しています。
-
-## AI駆動開発 共通ガイドライン
-
-## 開発の基本理念
-
-- 動くコードを書くだけでなく、品質・保守性・安全性を常に意識する
-- プロジェクトの段階（プロトタイプ、MVP、本番環境）に応じて適切なバランスを取る
-- 問題を見つけたら放置せず、必ず対処または明示的に記録する
-- ボーイスカウトルール：コードを見つけた時よりも良い状態で残す
-
-## エラーハンドリングの原則
-
-- 関連が薄く見えるエラーでも必ず解決する
-- エラーの抑制（try-catch で握りつぶす等）ではなく、根本原因を修正
-- 早期にエラーを検出し、明確なエラーメッセージを提供
-- エラーケースも必ずテストでカバーする
-- 外部APIやネットワーク通信は必ず失敗する可能性を考慮
-
-## コード品質の基準
-
-- DRY原則：重複を避け、単一の信頼できる情報源を維持
-- 意味のある変数名・関数名で意図を明確に伝える
-- プロジェクト全体で一貫したコーディングスタイルを維持
-- 小さな問題も放置せず、発見次第修正（Broken Windows理論）
-- コメントは「なぜ」を説明し、「何を」はコードで表現
-
-## テスト規律
-
-- テストをスキップせず、問題があれば修正する
-- 実装詳細ではなく振る舞いをテスト
-- テスト間の依存を避け、任意の順序で実行可能に
-- テストは高速で、常に同じ結果を返すように
-- カバレッジは指標であり、質の高いテストを重視
-
-## 保守性とリファクタリング
-
-- 機能追加と同時に既存コードの改善を検討
-- 大規模な変更は小さなステップに分割
-- 使用されていないコードは積極的に削除
-- 依存関係は定期的に更新（セキュリティと互換性のため）
-- 技術的負債は明示的にコメントやドキュメントに記録
-
-## セキュリティの考え方
-
-- APIキー、パスワード等は環境変数で管理（ハードコード禁止）
-- すべての外部入力を検証
-- 必要最小限の権限で動作（最小権限の原則）
-- 不要な依存関係を避ける
-- セキュリティ監査ツールを定期的に実行
-
-## パフォーマンスの意識
-
-- 推測ではなく計測に基づいて最適化
-- 初期段階から拡張性を考慮
-- 必要になるまでリソースの読み込みを遅延
-- キャッシュの有効期限と無効化戦略を明確に
-- N+1問題やオーバーフェッチを避ける
-
-## 信頼性の確保
-
-- タイムアウト処理を適切に設定
-- リトライ機構の実装（指数バックオフを考慮）
-- サーキットブレーカーパターンの活用
-- 一時的な障害に対する耐性を持たせる
-- 適切なログとメトリクスで可観測性を確保
-
-## プロジェクトコンテキストの理解
-
-- ビジネス要件と技術要件のバランスを取る
-- 現在のフェーズで本当に必要な品質レベルを判断
-- 時間制約がある場合でも、最低限の品質基準を維持
-- チーム全体の技術レベルに合わせた実装選択
-
-## トレードオフの認識
-
-- すべてを完璧にすることは不可能（銀の弾丸は存在しない）
-- 制約の中で最適なバランスを見つける
-- プロトタイプなら簡潔さを、本番なら堅牢性を優先
-- 妥協点とその理由を明確にドキュメント化
-
-## Git運用の基本
-
-- コンベンショナルコミット形式を使用（.gitmessage.txt参照）
-- コミットは原子的で、単一の変更に焦点を当てる
-- 明確で説明的なコミットメッセージを英語で記述
-- mainブランチへの直接コミットは避ける
-
-## コードレビューの姿勢
-
-- レビューコメントは建設的な改善提案として受け取る
-- 個人ではなくコードに焦点を当てる
-- 変更の理由と影響を明確に説明
-- フィードバックを学習機会として歓迎
-
-## デバッグのベストプラクティス
-
-- 問題を確実に再現できる手順を確立
-- 二分探索で問題の範囲を絞り込む
-- 最近の変更から調査を開始
-- デバッガー、プロファイラー等の適切なツールを活用
-- 調査結果と解決策を記録し、知識を共有
-
-## 依存関係の管理
-
-- 本当に必要な依存関係のみを追加
-- 新しい依存関係追加前にライセンス、サイズ、メンテナンス状況を確認
-- セキュリティパッチとバグ修正のため定期的に更新
-
-## ドキュメントの基準
-
-- READMEにプロジェクトの概要、セットアップ、使用方法を明確に記載
-- ドキュメントをコードと同期して更新
-- 実例を示すことを優先
-- 重要な設計判断はADR (Architecture Decision Records)で記録
-
-## 継続的な改善
-
-- 学んだことを次のプロジェクトに活かす
-- 定期的に振り返りを行い、プロセスを改善
-- 新しいツールや手法を適切に評価して取り入れる
-- チームや将来の開発者のために知識を文書化
-
-### 禁止事項
-
-- 許可なくファイル、フォルダを勝手に削除しないこと。
-- AGENTS.mdと同等の領域にあるファイル、フォルダのみアクセス可能とすること。
-- テストコードで `setAccessible` を使用しないこと。private メソッドのテストは不要。public API 経由でカバレッジ100%を達成すること。public API 経由でカバーできない場合はプロダクションコードの構造を見直すこと。
-
-### コーディング規約
-
-- YAGNI原則を準拠
-- Java11、Spring Boot 2.7.18に準拠
-- pom.xmlに定義したOSSライブラリを有効活用
-- 可読性が高くなるように、わかりづらい実装はコメントで補足
-- 三項演算子は使わない
-- 防御的な実装はしないこと。
-
-### コミュニケーション/開発ルール
-
-- 今後のやり取りは日本語で行うようにしてください。
-- ただし、プロジェクト内のコメント、JavaDoc、README、コミットメッセージ、PR説明などの成果物テキストは英語で統一すること。
-
-### テスト・ビルドについて
-
-- 新規に作成したクラス、改修を行なった場合は、単体テスト `mvn clean test` を実行し、検証してください。ただし、テスト内容に変更がない体裁修正は検証不要です。
-- テスト実行前に、変更内容を「ロジック変更 / 設定変更 / 体裁修正のみ」に分類して明示すること。
-- テスト実行前に、実行理由を1行で明示すること。理由が明示できない場合は実行しないこと。
-- 次のいずれかに該当する場合はテストを実行しないこと：「実行結果が変わらない変更」「テストコード変更なし」「体裁修正のみ」。
-- テスト/ビルドが失敗した場合は、原因特定し、テストが成功するまで処置をすること。
-- C0、C1カバレッジ100%となっていなかった場合、テストケースを追加してください。
-- `mvn clean test` を実行した作業は、完了報告時に C0/C1（INSTRUCTION/BRANCH）の実測値（% と covered/total）を必ず明記すること。未報告で完了扱いにしないこと。
-- 改修時は未使用のフィールド・ローカル変数・importを残さないこと。`The value of the field xxx is not used` を含む未使用警告を0件にしてから完了報告すること。
-- リリース作業時は、`pom.xml` の `<version>` とリリースタグを一致させること。タグ作成前に差分確認で `pom.xml` を必ず確認すること。
-- リリース作業時は、対象コミットの CI（`ci.yml`）が全ジョブ成功してからタグを作成すること。失敗中・実行中の状態でタグ作成しないこと。
-- リリース作業時は、C0/C1（INSTRUCTION/BRANCH）カバレッジ100%を `jacoco.xml` または CIログで確認し、未達ならリリースしないこと。
-- リリース作業時は、`main` への push 完了後に注釈付きタグを作成し、タグ push で `release.yml` を起動すること。
-- リリース完了条件は、`release.yml` 成功・GitHub Release 作成・想定 Assets 登録完了の3点を確認した状態とすること。
-- テストメソッド名称は、<メソッド名>_xxxケース_<検証内容>_<規格値> と書くこと。xxxは正常もしくは異常がはいる。また、規格値は「〜であること」と言葉を揃えること。
-- 「検証内容」は具体的な条件を動詞（〜する）で示し、「規格値」は名詞や結果を表す表現で「〜であること」で締める
-- 「規格値」で不自然な「〜する状態であること」を避け、可能な限り「〜が返る」「〜が設定される」「〜が再スローされる」などの結果を名詞化して表現すること
-- 検証内容には条件を簡潔に書き、可能であれば文末に「〜すること」を付けずに記載してください。補足が必要な場合はテスト内コメントで補足すること。
-- 追加、修正、削除をした場合、テスト実行による検証作業において、テスト失敗した場合、分析して、処置をすること。
-- JUnit5、mockitを使用すること。
-
-### JavaDoc 記述ルール
-
-- JavaDoc は全て `/** … */` 形式で記載し、private メソッドを含む全メソッドに簡潔な説明を追加してください（テストコードは対象外）。
-- 引数／戻り値には `@param`／`@return` を使い、該当要素の意味や条件を明記します（たとえば `@param request` には「評価対象の HTTP リクエスト」、`@return` には「判定条件が揃えば true」など）。
-- 仕様や判定基準を補足したい場合は本文に追記し、特定の例外や副作用があれば `@throws` も活用してください。
-
-## 現状の問題点
-
-かなり長いルールファイルになってしまっています。
-このままだと全体のコンテキストが長大になり、性能が低下してしまう可能性があります。
-
-## 命令
-
-元の内容を保持しつつも、内容を圧縮・整理してください。
+このファイルは、AI が本リポジトリで作業する際に常時参照するルールです。  
+目的は、品質・保守性・安全性を維持しつつ、判断基準を短く一貫した形で示すことです。
+
+## 基本方針
+
+### 品質と設計
+
+- 動作だけでなく、品質・保守性・安全性を常に考慮する。
+- 現在のフェーズ（プロトタイプ / MVP / 本番）に応じて、適切な品質水準を選ぶ。
+- 問題は放置せず、修正するか、少なくとも明示的に記録する。
+- ボーイスカウトルールに従い、触れた箇所はより良い状態で残す。
+- DRY を守り、単一の信頼できる情報源を維持する。
+- 命名は意図が伝わるものにし、スタイルはプロジェクト全体で統一する。
+- 小さな不整合も放置せず修正する。
+- コメントは「なぜ」を補足し、「何を」はコードで表現する。
+- 機能追加時は既存コードの改善も検討する。
+- 大きな変更は小さな段階に分ける。
+- 未使用コードは積極的に削除する。
+- 技術的負債はコメントやドキュメントで明示する。
+- YAGNI を守る。
+- 可読性を優先し、わかりづらい実装のみ簡潔に補足する。
+- 三項演算子は使わない。
+- 防御的な実装はしない。
+
+### エラー処理と信頼性
+
+- 関連が薄く見えるエラーも放置せず解決する。
+- 例外を握りつぶさず、根本原因を修正する。
+- エラーは早期検出し、明確なメッセージを出す。
+- エラーケースもテスト対象に含める。
+- 外部 API / ネットワークは失敗を前提に設計する。
+- タイムアウトを適切に設定する。
+- 必要に応じてリトライ（指数バックオフ含む）を検討する。
+- 必要に応じてサーキットブレーカーパターンを活用する。
+- 一時障害に耐えられる設計にする。
+- 適切なログとメトリクスで可観測性を確保する。
+
+### テストと検証
+
+- テストはスキップせず、問題があれば原因を特定して修正する。
+- 実装詳細ではなく振る舞いを検証する。
+- テスト間の依存をなくし、任意順で実行可能にする。
+- テストは高速かつ再現性を持たせる。
+- カバレッジは指標であり、質を優先する。
+- エラーやビルド失敗は成功するまで処置する。
+
+### セキュリティ・性能・依存管理
+
+- 秘密情報は環境変数で扱い、ハードコードしない。
+- すべての外部入力を検証する。
+- 最小権限で動作させる。
+- 不要な依存は追加しない。
+- 依存はライセンス、サイズ、保守状況を確認してから追加する。
+- 依存はセキュリティ修正・バグ修正のため定期更新する。
+- セキュリティ監査ツールは定期的に実行する。
+- 最適化は推測ではなく計測に基づいて行う。
+- 初期段階から拡張性を意識する。
+- 必要になるまでリソース読み込みを遅延させる。
+- キャッシュは期限と無効化戦略を明確にする。
+- N+1 やオーバーフェッチを避ける。
+
+### 開発運用
+
+- ビジネス要件と技術要件のバランスを取る。
+- 時間制約下でも最低限の品質基準は守る。
+- チームの技術レベルに合う実装を選ぶ。
+- すべてを完璧にはできない前提で、制約下の最適解を選ぶ。
+- プロトタイプでは簡潔さ、本番では堅牢性をより重視する。
+- 妥協点と理由は明文化する。
+- コンベンショナルコミットを使用する（`.gitmessage.txt` 参照）。
+- コミットは原子的にし、単一の変更に集中させる。
+- コミットメッセージは明確な英語で書く。
+- `main` へ直接コミットしない。
+- レビューはコードに対して行い、建設的提案として扱う。
+- 変更理由と影響を明確に説明する。
+- フィードバックは学習機会として扱う。
+- デバッグは再現手順確立、二分探索、最近の変更確認を基本とする。
+- 必要に応じてデバッガーやプロファイラーを使う。
+- 調査結果と解決策は記録し、再利用可能にする。
+- README には概要、セットアップ、利用方法を明確に書く。
+- ドキュメントはコード変更に追随させる。
+- 実例を優先する。
+- 重要な設計判断は ADR で記録する。
+- 学んだことは次の作業に活かし、定期的に改善する。
+- 新しいツールや手法は適切に評価して取り入れる。
+- チームや将来の開発者のために知識を文書化する。
+
+## 禁止事項
+
+- 許可なくファイルやフォルダを削除しない。
+- `AGENTS.md` と同等の領域にあるファイル / フォルダのみアクセス対象とする。
+- テストコードで `setAccessible` を使わない。
+- private メソッドを直接テストしない。public API 経由で C0 / C1 100% を目指す。
+- public API 経由でカバーできない場合は、プロダクションコードの構造を見直す。
+
+## プロジェクト固有ルール
+
+### コミュニケーション
+
+- 対話は日本語で行う。
+- ただし、プロジェクト内のコメント、JavaDoc、README、コミットメッセージ、PR 説明などの成果物テキストは英語で統一する。
+
+### 実装規約
+
+- Java 11、Spring Boot 2.7.18 に準拠する。
+- `pom.xml` に定義済みの OSS ライブラリを活用する。
+- 改修時は未使用の field / local variable / import を残さない。
+- `The value of the field xxx is not used` を含む未使用警告は 0 件にして完了とする。
+
+### テスト・ビルド
+
+- 新規作成や改修を行った場合は、原則として `mvn clean test` を実行して検証する。
+- ただし、体裁修正のみ、テストコード変更なし、実行結果が変わらない変更は実行しない。
+- テスト実行前に、変更を「ロジック変更 / 設定変更 / 体裁修正のみ」に分類して明示する。
+- テスト実行前に、実行理由を 1 行で明示する。理由を明示できない場合は実行しない。
+- テスト / ビルドが失敗した場合は、原因を特定し、成功するまで処置する。
+- C0、C1 が 100% でない場合は、必要なテストケースを追加する。
+- `mvn clean test` を実行した作業は、完了報告時に C0 / C1（INSTRUCTION / BRANCH）の実測値（% と covered / total）を必ず記載する。
+- 実測値未記載のまま完了扱いにしない。
+- 追加 / 修正 / 削除を行った作業でテストが失敗した場合は、分析して処置する。
+- JUnit 5、mockit を使用する。
+
+### テストメソッド命名
+
+- テストメソッド名は `<メソッド名>_xxxケース_<検証内容>_<規格値>` とする。
+- `xxx` には `正常` または `異常` を入れる。
+- 規格値は必ず「〜であること」で統一する。
+- 検証内容は、具体条件を動詞（〜する）で簡潔に表現する。
+- 規格値は、名詞または結果表現で締める。
+- 「〜する状態であること」は避け、可能な限り「〜が返る」「〜が設定される」「〜が再スローされる」などを名詞化して表現する。
+- 検証内容は可能なら「〜すること」を付けずに記述し、補足が必要な場合はテスト内コメントで補う。
+
+### リリース
+
+- リリースタグは `pom.xml` の `<version>` と一致させる。
+- タグ作成前に差分確認で `pom.xml` を必ず確認する。
+- 対象コミットの CI（`ci.yml`）が全ジョブ成功してからタグを作成する。
+- CI が失敗中または実行中の状態ではタグを作成しない。
+- C0 / C1（INSTRUCTION / BRANCH）100% を `jacoco.xml` または CI ログで確認し、未達ならリリースしない。
+- `main` への push 完了後に注釈付きタグを作成し、そのタグ push で `release.yml` を起動する。
+- リリース完了条件は、`release.yml` 成功、GitHub Release 作成、想定 Assets 登録完了の 3 点確認とする。
+
+### JavaDoc
+
+- JavaDoc はすべて `/** ... */` 形式で記載する。
+- テストコードを除き、private メソッドを含む全メソッドに簡潔な説明を付ける。
+- 引数と戻り値には `@param` / `@return` を使い、意味や条件を具体的に記載する。
+- 仕様、判定基準、例外、副作用の補足が必要な場合は、本文や `@throws` を使って明記する。
+
+## このファイルの改善方針
+
+- 現状の問題は、ルールの総量が増え、コンテキスト負荷が高くなっていること。
+- そのため、今後も内容は維持しつつ、重複削減・章立て整理・表現統一を優先して更新する。