diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md new file mode 100644 index 0000000..000010e --- /dev/null +++ b/.github/copilot-instructions.md @@ -0,0 +1,46 @@ +# Copilot Instructions for Lepus Development Guidelines + +This repository contains the engineering team's documentation standards, review policies, and PR templates. It is **documentation-only**—no code or build/test automation is present. + +## Key Knowledge for AI Agents + +### 1. Repository Purpose & Scope +- **Internal use only**: PRs from outside Lepus Group are not accepted. +- All content is for documentation, not code implementation. +- Main files: `README.md`, `README.ja.md`, `CONTRIBUTING.md`, `docs/en/REVIEW_POLICY.md`, `docs/ja/REVIEW_POLICY.md`, PR templates in `docs/en/` and `docs/ja/`. + +### 2. Pull Request Workflow +- **Branch from `main`** for changes. +- Use the PR template (`docs/en/PULL_REQUEST_TEMPLATE.md` or `docs/ja/PULL_REQUEST_TEMPLATE.md`). +- PRs must include: + - Background/purpose (ticket link, rationale) + - Main changes (bulleted) + - Acceptance criteria (checklist) + - Impacted packages/areas + - Test evidence (screenshots, CI results, reproduction steps) +- **No external PRs**—fork if you wish to adapt. + +### 3. Review Policy Highlights +- **Review levels**: + - L0: Minor fix (light check, focus on CI/tests) + - L1: Feature addition/modification (AC & evidence required) + - L2: High-risk (schema/security/external integration) → Pair review + manual verification +- **Mandatory**: Acceptance criteria, test results, and reproduction steps. +- **Commit conventions**: Use `test:`, `fix:`, `refactor:` prefixes. Large renames/formatting → separate PRs. +- **Explicit impact scope**: Always state affected areas (API/DB/auth/UI/external systems). + +### 4. Patterns & Conventions +- **Single Responsibility Principle**: Bug fixes and refactoring should be separate PRs (except minimal, behavior-preserving refactoring). +- **RACI matrix**: Developer (implementation/tests), Reviewer/Tech Lead (quality/design/risk), QA/PM (AC definition/validation). +- **Test-first for bug fixes**: Reproduction test → fix → regression check. + +### 5. Language & Documentation +- All documentation is available in both English (`docs/en/`) and Japanese (`docs/ja/`). +- Reference the appropriate language version for PRs and reviews. + +## Examples +- See `docs/en/REVIEW_POLICY.md` and `docs/ja/REVIEW_POLICY.md` for detailed review criteria and RACI roles. +- See PR templates for required sections and checklists. + +--- +For questions or unclear conventions, consult `README.md` or open an issue for clarification. diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..9f6bf31 --- /dev/null +++ b/.gitignore @@ -0,0 +1,23 @@ +# macOS system files +.DS_Store +.AppleDouble +.LSOverride + +# macOS folder attributes +._* + +# macOS Trash +.Trashes + +# macOS Spotlight files +.Spotlight-V100 + +# macOS volume files +.VolumeIcon.icns + +# macOS Finder files +.fseventsd + +# VSCode settings and workspace files +.vscode/ +*.code-workspace diff --git a/README.ja.md b/README.ja.md index 8e83b4c..cd68104 100644 --- a/README.ja.md +++ b/README.ja.md @@ -1,5 +1,7 @@ # LEPUS 開発ガイドライン ![version](https://img.shields.io/badge/バージョン-1.0-blue) +🇯🇵 **日本語** | 🇺🇸 [English](README.md) + このリポジトリには、**レプスグループ エンジニアリングチームの開発ガイドラインとベストプラクティス** が含まれています。 コードレビュー、プルリクエスト、テスト、チームコラボレーションに関する原則を定義しています。 @@ -7,30 +9,32 @@ ## 📖 利用可能なドキュメント -- [レビューポリシー (日本語)](docs/ja/REVIEW_POLICY.md) - - [PR単位の原則](docs/ja/REVIEW_POLICY.md#pr単位の原則) +- [レビューポリシー](docs/ja/REVIEW_POLICY.md) + - [PR 単位の原則](docs/ja/REVIEW_POLICY.md#pr単位の原則) - [レビューの心得](docs/ja/REVIEW_POLICY.md#-レビューの心得) - [簡易チェックリスト](docs/ja/REVIEW_POLICY.md#-簡易チェックリスト) - [レベル判定ガイド](docs/ja/REVIEW_POLICY.md#-レベル判定ガイド) - - [RACIマトリクス](docs/ja/REVIEW_POLICY.md#-raciマトリクス) -- [Review Policy (English)](docs/en/REVIEW_POLICY.md) - - [PR Size Guidelines](docs/en/REVIEW_POLICY.md#pr-size-guidelines) - - [Review Mindset](docs/en/REVIEW_POLICY.md#-review-mindset) - - [Quick Checklist](docs/en/REVIEW_POLICY.md#-quick-checklist) - - [Level Decision Guide](docs/en/REVIEW_POLICY.md#-level-decision-guide) - - [RACI Matrix](docs/en/REVIEW_POLICY.md#-raci-matrix) -- [プルリクエストテンプレート (日本語)](docs/ja/PULL_REQUEST_TEMPLATE.md) + - [RACI マトリクス](docs/ja/REVIEW_POLICY.md#-raciマトリクス) +- [プルリクエストテンプレート](docs/ja/PULL_REQUEST_TEMPLATE.md) - [テスト証跡](docs/ja/PULL_REQUEST_TEMPLATE.md#-テスト証跡) - [チェックリスト](docs/ja/PULL_REQUEST_TEMPLATE.md#-チェックリスト) -- [Pull Request Template (English)](docs/en/PULL_REQUEST_TEMPLATE.md) - - [Test Evidence](docs/en/PULL_REQUEST_TEMPLATE.md#-test-evidence) - - [Checklist](docs/en/PULL_REQUEST_TEMPLATE.md#-checklist) +- [サードパーティパッケージ選定基準](docs/ja/DEPENDENCIES_GUIDELINES.md) + - [目的](docs/ja/DEPENDENCIES_GUIDELINES.md#目的) + - [信頼性](docs/ja/DEPENDENCIES_GUIDELINES.md#1-信頼性popularity--ecosystem-trust) + - [セキュリティ](docs/ja/DEPENDENCIES_GUIDELINES.md#2-セキュリティsecurity--compliance) + - [コード品質](docs/ja/DEPENDENCIES_GUIDELINES.md#3-コード品質code-quality) + - [プロジェクト継続性](docs/ja/DEPENDENCIES_GUIDELINES.md#4-プロジェクト継続性project-sustainability) + - [ライセンス](docs/ja/DEPENDENCIES_GUIDELINES.md#5-ライセンスlicense-compliance) + - [選定プロセス](docs/ja/DEPENDENCIES_GUIDELINES.md#6-選定プロセスevaluation-process) + - [継続的チェック](docs/ja/DEPENDENCIES_GUIDELINES.md#7-継続的チェックongoing-review) + - [例外ルール](docs/ja/DEPENDENCIES_GUIDELINES.md#8-例外ルールexception-rules) --- ## 🏗️ 対象範囲 このガイドラインには以下が含まれます： + - コードレビューの責務と原則 - プルリクエストのテンプレートとワークフロー - テストと証跡に関する必須要件 @@ -38,13 +42,27 @@ --- +## 📂 ディレクトリ構成 + +``` +. +├── docs/ +│ ├── en/ # 英語ドキュメント +│ └── ja/ # 日本語ドキュメント +├── LICENSE # リポジトリのライセンス +├── README.md # 英語版 README +└── README.ja.md # このファイル (日本語版 README) +``` + +--- + ## 🤝 貢献について 改善提案はいつでも歓迎します。 -ただし、**レプスグループ 外部からのプルリクエストは受け付けていません**。 +ただし、**レプスグループ 外部からのプルリクエストは受け付けていません**。 詳細は [CONTRIBUTING.md](CONTRIBUTING.md) を参照してください。 -社内メンバーは `main` ブランチに向けてプルリクエストを作成してください。 +社内メンバーは `main` ブランチに向けてプルリクエストを作成してください。 --- @@ -54,4 +72,4 @@ --- -© レプスグループ – エンジニアリングチーム \ No newline at end of file +© レプスグループ – エンジニアリングチーム diff --git a/README.md b/README.md index e9d2624..1479c34 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,7 @@ # LEPUS Development Guidelines ![version](https://img.shields.io/badge/version-1.0-blue) +🇺🇸 **English** | 🇯🇵 [Japanese](README.ja.md) + This repository contains the **development guidelines and best practices** of the Lepus Engineering Team. It defines our principles for code review, pull requests, testing, and collaboration. @@ -7,30 +9,32 @@ It defines our principles for code review, pull requests, testing, and collabora ## 📖 Documentation Index -- [Review Policy (日本語)](docs/ja/REVIEW_POLICY.md) - - [PR Size Guidelines (日本語)](docs/ja/REVIEW_POLICY.md#pr単位の原則) - - [Review Mindset (日本語)](docs/ja/REVIEW_POLICY.md#-レビューの心得) - - [簡易チェックリスト](docs/ja/REVIEW_POLICY.md#-簡易チェックリスト) - - [Level Decision Guide](docs/ja/REVIEW_POLICY.md#-レベル判定ガイド) - - [RACIマトリクス](docs/ja/REVIEW_POLICY.md#-raciマトリクス) -- [Review Policy (English)](docs/en/REVIEW_POLICY.md) - - [PR Size Guidelines (English)](docs/en/REVIEW_POLICY.md#pr-size-guidelines) - - [Review Mindset (English)](docs/en/REVIEW_POLICY.md#-review-mindset) +- [Review Policy](docs/en/REVIEW_POLICY.md) + - [PR Size Guidelines](docs/en/REVIEW_POLICY.md#pr-size-guidelines) + - [Review Mindset](docs/en/REVIEW_POLICY.md#-review-mindset) - [Quick Checklist](docs/en/REVIEW_POLICY.md#-quick-checklist) - [Level Decision Guide](docs/en/REVIEW_POLICY.md#-level-decision-guide) - [RACI Matrix](docs/en/REVIEW_POLICY.md#-raci-matrix) -- [Pull Request Template (日本語)](docs/ja/PULL_REQUEST_TEMPLATE.md) - - [Test Evidence (日本語)](docs/ja/PULL_REQUEST_TEMPLATE.md#-テスト証跡) - - [Checklist (日本語)](docs/ja/PULL_REQUEST_TEMPLATE.md#-チェックリスト) -- [Pull Request Template (English)](docs/en/PULL_REQUEST_TEMPLATE.md) - - [Test Evidence (English)](docs/en/PULL_REQUEST_TEMPLATE.md#-test-evidence) - - [Checklist (English)](docs/en/PULL_REQUEST_TEMPLATE.md#-checklist) +- [Pull Request Template](docs/en/PULL_REQUEST_TEMPLATE.md) + - [Test Evidence](docs/en/PULL_REQUEST_TEMPLATE.md#-test-evidence) + - [Checklist](docs/en/PULL_REQUEST_TEMPLATE.md#-checklist) +- [Third-Party Package Selection Guidelines](docs/en/DEPENDENCIES_GUIDELINES.md) + - [Objectives](docs/en/DEPENDENCIES_GUIDELINES.md#objectives) + - [Trustworthiness](docs/en/DEPENDENCIES_GUIDELINES.md#1-trustworthiness-popularity--ecosystem-trust) + - [Security & Compliance](docs/en/DEPENDENCIES_GUIDELINES.md#2-security--compliance) + - [Code Quality](docs/en/DEPENDENCIES_GUIDELINES.md#3-code-quality) + - [Project Sustainability](docs/en/DEPENDENCIES_GUIDELINES.md#4-project-sustainability) + - [License Compliance](docs/en/DEPENDENCIES_GUIDELINES.md#5-license-compliance) + - [Evaluation Process](docs/en/DEPENDENCIES_GUIDELINES.md#6-evaluation-process) + - [Ongoing Review](docs/en/DEPENDENCIES_GUIDELINES.md#7-ongoing-review) + - [Exception Rules](docs/en/DEPENDENCIES_GUIDELINES.md#8-exception-rules) --- ## 🏗️ Scope These guidelines cover: + - Code review responsibilities and principles - Pull Request templates and workflows - Testing and evidence requirements @@ -38,13 +42,27 @@ These guidelines cover: --- +## 📂 Directory Structure + +``` +. +├── docs/ +│ ├── en/ # English documentation +│ └── ja/ # Japanese documentation +├── LICENSE # Repository license +├── README.md # This file +└── README.ja.md # Japanese README +``` + +--- + ## 🤝 Contribution Suggestions for improvement are always welcome. -Please open a Pull Request against the `main` branch. +Please open a Pull Request against the `main` branch. ⚠️ **Note:** External contributions (PRs from outside the Lepus Group) are **not accepted**. -For details, see [CONTRIBUTING.md](CONTRIBUTING.md). +For details, see [CONTRIBUTING.md](CONTRIBUTING.md). --- @@ -54,4 +72,4 @@ This repository is licensed under the [MIT License](LICENSE). --- -© Lepus Group – Engineering Team \ No newline at end of file +© Lepus Group – Engineering Team diff --git a/docs/en/DEPENDENCIES_GUIDELINES.md b/docs/en/DEPENDENCIES_GUIDELINES.md new file mode 100644 index 0000000..8abae58 --- /dev/null +++ b/docs/en/DEPENDENCIES_GUIDELINES.md @@ -0,0 +1,167 @@ +# Third-Party Package Selection Guidelines (Application Level) + +This document defines guidelines for selecting third-party packages used by applications to reduce the risks of external dependencies, including supply chain attacks. + +## Objectives + +- Adopt only trustworthy packages to ensure maintainability and safety +- Maintain a secure ecosystem that assumes ongoing vulnerability management +- Avoid person-dependent decisions and apply unified criteria across projects + +--- + +# 1. Trustworthiness (Popularity & Ecosystem Trust) + +## MUST + +- Demonstrates sufficient usage among similar packages + Roughly top 3-5 by downloads +- Has a healthy download volume + 100k+ downloads +- Updated within the last six months +- Follows SemVer-based versioning + +## SHOULD + +- At least 1-2 years since initial release + (allow exceptions for official SDKs from major vendors) +- Does not have unnecessary dependency bloat +- Does not introduce frequent breaking changes + +--- + +# 2. Security & Compliance + +## MUST + +- No unresolved critical/high vulnerabilities + - GitHub Security Advisories + - NVD (National Vulnerability Database) + - Packagist Security Advisories, etc. +- Maintainer team is not exclusively anonymous accounts + +## SHOULD + +- Supports generating an SBOM (Software Bill of Materials) +- Security incidents are handled promptly +- Compatible with automated security updates (Dependabot / Renovate, etc.) +- Release tags are signed (or protected) + +--- + +# 3. Code Quality + +## MUST + +- Test code exists and CI is running +- Basic documentation (README, usage examples, etc.) is available + +## SHOULD + +- Supports static analysis tools (PHPStan / Psalm / ESLint / MyPy, etc.) +- Code is readable and not excessively complex +- Architecture principles are clear and APIs are consistent + +--- + +# 4. Project Sustainability + +## MUST + +- Commits or responses to issues within the last six months +- Issues/PRs are not left unaddressed + +## SHOULD + +- Multiple maintainers (bus factor is not 1) +- Supported by sponsors, companies, or a community + +--- + +# 5. License Compliance + +## MUST + +- License permits commercial use + - MIT, Apache-2.0, BSD variants, etc. +- Do not adopt licenses that conflict with the application (e.g., GPL) + +## SHOULD + +- License compatibility is confirmed for dependencies as well + (verifiable via SBOM, etc.) + +--- + +# 6. Evaluation Process + +1. All MUST items must be satisfied +2. Meeting 70% or more of the SHOULD items is recommended +3. If a package fails the criteria but you still want to adopt it, submit an **exception request** +4. Exceptions require a team review or architect approval + +--- + +# 7. Ongoing Review + +- Periodically inventory existing packages + - Vulnerability checks + - Maintenance status review + - Consider replacing deprecated packages +- Keep Dependabot / Renovate enabled for continuous updates + +--- + +# 8. Exception Rules + +In the following cases, packages that do not meet the usual MUST/SHOULD criteria may be allowed. + +## 8.1 Official SDKs / Official Clients + +- Packages officially provided and maintained by vendors such as AWS, GCP, Stripe, PayPal, Slack +- Short time since initial release or low download counts are exempt from the criteria +- If responses to security advisories are slow, evaluate alternatives + +## 8.2 Domain-Specific Libraries for Business Requirements + +- No alternatives exist to meet specific business requirements +- Usage is internal and impact is limited +- Perform additional safety evaluations (e.g., code reviews) for the package + +## 8.3 Emerging but Promising Libraries + +- Community is growing quickly and could become a future standard +- Maintainers are reliable and active (e.g., well-known OSS developers) +- Introduce as a "trial adoption" and monitor in production for six months + +## 8.4 Assuming Internal Forks/Modifications + +- OSS version has issues, but we can fork and maintain it internally +- License must permit forking +- Once forked, dependency is detached from the external supply chain, so criteria may be relaxed + +## 8.5 Packages Required by Infrastructure or Security Products + +- APM (New Relic, etc.), security agents, observability agents +- Required for platform compatibility +- Follow the vendor's support policies + +--- + + diff --git a/docs/en/PULL_REQUEST_TEMPLATE.md b/docs/en/PULL_REQUEST_TEMPLATE.md index 41b764d..09b18dc 100644 --- a/docs/en/PULL_REQUEST_TEMPLATE.md +++ b/docs/en/PULL_REQUEST_TEMPLATE.md @@ -1,72 +1,72 @@ -## 📝 背景・目的 - -- チケット番号: [TICKET-1234](リンクを貼る) -- 対応理由: +## 📝 Background & Purpose + +- Ticket Number: [TICKET-1234](paste link here) +- Reason for this change: --- -## 🔄 変更内容 - +## 🔄 Changes + - --- -## ✅ 受け入れ基準 (Acceptance Criteria) - -- [ ] ○○できること -- [ ] △△のケースでもエラーにならないこと -- [ ] 境界値 (例: 0件/最大件数) でも動作すること +## ✅ Acceptance Criteria + +- [ ] Ability to do ○○ +- [ ] No errors even in △△ cases +- [ ] Works with boundary values (e.g., 0 items / maximum items) --- -## 📦 影響するパッケージ - +## 📦 Affected Packages + - --- -## 🧪 テスト証跡 - -- [ ] 単体テスト追加 → 実行結果 (スクショ/CIリンク) -- [ ] 統合/E2Eテスト追加 → 実行結果 (スクショ/CIリンク) -- [ ] 手動確認のスクリーンショット or 動画 -- [ ] 再現手順を記載（レビュアーが追試可能な形） +## 🧪 Test Evidence + +- [ ] Unit test added → Execution results (screenshot/CI link) +- [ ] Integration/E2E test added → Execution results (screenshot/CI link) +- [ ] Manual verification screenshot or video +- [ ] Reproduction steps described (reviewers can reproduce) --- -## 🖥️ 動作確認手順 - -1. ブランチをチェックアウト -2. `make start` で環境起動 -3. `/xxx` にアクセスして ○○ を実行すると △△ が表示される +## 🖥️ Verification Steps + +1. Check out the branch +2. Start the environment with `make start` +3. Access `/xxx` and execute ○○ to see △△ displayed --- -## 📌 影響範囲 - +## 📌 Impact Scope + - [ ] API -- [ ] DBスキーマ -- [ ] 認可/認証 +- [ ] DB Schema +- [ ] Authorization/Authentication - [ ] UI/UX -- [ ] 外部システム +- [ ] External Systems --- -## 📋 このPRの性質 -- [ ] バグ修正のみ（リファクタなし） -- [ ] バグ修正 + **最小の機械的リファクタ**（別コミットに分離済み） -- [ ] 準備リファクタ（振る舞い不変）※修正は別PRで実施 +## 📋 Nature of this PR +- [ ] Bug fix only (no refactoring) +- [ ] Bug fix + **minimal mechanical refactoring** (separated into different commits) +- [ ] Preparatory refactoring (behavior unchanged) ※ Fix will be done in a separate PR --- -## 🔍 チェックリスト -- [ ] CIがグリーンである -- [ ] 受け入れ基準を満たしている -- [ ] テスト証跡が揃っている -- [ ] セキュリティ/権限/パフォーマンス影響を考慮した -- [ ] レビュアーに伝えるべき既知の制約・TODOを記載した +## 🔍 Checklist +- [ ] CI is green +- [ ] Acceptance criteria are met +- [ ] Test evidence is complete +- [ ] Security/permissions/performance impact considered +- [ ] Known constraints/TODOs that should be communicated to reviewers are documented --- -> 🛈 詳細なレビュー基準については [REVIEW_POLICY.md](REVIEW_POLICY.md) を参照してください -> 📂 このテンプレートはプロジェクトの `.github` ディレクトリに配置してください。PRの作成時に自動で適用されます。 +> 🛈 For detailed review criteria, please refer to [REVIEW_POLICY.md](REVIEW_POLICY.md) +> 📂 This template should be placed in the `.github` directory of the project. It will be automatically applied when creating a PR. diff --git a/docs/ja/DEPENDENCIES_GUIDELINES.md b/docs/ja/DEPENDENCIES_GUIDELINES.md new file mode 100644 index 0000000..d84c990 --- /dev/null +++ b/docs/ja/DEPENDENCIES_GUIDELINES.md @@ -0,0 +1,168 @@ +# サードパーティパッケージ選定基準（アプリケーションレベル） + +本ドキュメントは、サプライチェーン攻撃を含む外部依存のリスクを低減するため、 +アプリケーションが利用するサードパーティパッケージの選定ガイドラインを定義する。 + +## 目的 + +- 信頼性の高いパッケージのみを採用し、保守性と安全性を確保する +- 継続的な脆弱性管理を前提とした安全なエコシステムを維持する +- パッケージ選定の属人化を避け、プロジェクト横断で統一基準を適用する + +--- + +# 1. 信頼性（Popularity & Ecosystem Trust） + +## MUST（必須） + +- 同用途パッケージの中で一定以上の利用実績がある + ダウンロード数が上位 3〜5 位程度 +- ダウンロード数が十分にある + 10 万 DL 以上 +- 直近半年以内にアップデートが行われている +- SemVer に基づいたバージョニングを行っている + +## SHOULD（推奨） + +- 初回リリースから 1〜2 年以上経過している + （ただし大手企業公式 SDK などは例外ルールを認める） +- 依存関係が不必要に多くない +- 破壊的変更が頻繁でない + +--- + +# 2. セキュリリティ（Security & Compliance） + +## MUST（必須） + +- 既知の重大な脆弱性（Critical / High）が未解決で残っていない + - GitHub Security Advisories + - NVD（National Vulnerability Database） + - Packagist Security Advisories など +- メンテナーチームが匿名のみで構成されていない + +## SHOULD（推奨） + +- SBOM（Software Bill of Materials）の生成が可能である +- セキュリティインシデント対応履歴が迅速である +- Dependabot / Renovate などのセキュリティ更新に対応している +- リリースタグが署名されている（または保護されている） + +--- + +# 3. コード品質（Code Quality） + +## MUST（必須） + +- テストコードが存在し、CI が稼働している +- 最低限のドキュメント（README、使用例など）が整備されている + +## SHOULD（推奨） + +- 静的解析ツール（PHPStan / Psalm / ESLint / MyPy 等）に対応している +- コードが読みやすく、極端に複雑な実装でない +- アーキテクチャ思想が明確であり、API が一貫している + +--- + +# 4. プロジェクト継続性（Project Sustainability） + +## MUST（必須） + +- 直近 6 ヶ月以内にコミットまたは Issue への反応がある +- Issue / PR が放置されていない + +## SHOULD（推奨） + +- メンテナーが複数人いる（バスファクターが 1 ではない） +- スポンサー、企業、コミュニティなど別の支援母体が存在する + +--- + +# 5. ライセンス（License Compliance） + +## MUST（必須） + +- ライセンスが業務利用に適していること + - MIT, Apache-2.0, BSD 系など +- GPL など、アプリケーションとライセンス衝突するものは採用しない + +## SHOULD（推奨） + +- 依存ライブラリも含めてライセンスの整合性がある + （SBOM 等で確認可能であること） + +--- + +# 6. 選定プロセス（Evaluation Process） + +1. 上記 MUST をすべて満たすこと +2. SHOULD の 70% 以上を満たすことを望ましい +3. 基準を満たさないが採用したい場合、**例外申請** を行うこと +4. 例外はチーム内レビューまたはアーキテクト承認を必要とする + +--- + +# 7. 継続的チェック（Ongoing Review） + +- 定期的に既存パッケージの棚卸しを行う + - 脆弱性チェック + - メンテ状況の確認 + - 非推奨パッケージの置き換え検討 +- Dependabot / Renovate による更新を常時有効にする + +--- + +# 8. 例外ルール（Exception Rules） + +以下の場合、通常の MUST/SHOULD 基準を満たさないパッケージでも採用を認めることがある。 + +## 8.1 公式 SDK / 公式クライアント + +- AWS, GCP, Stripe, PayPal, Slack などの **公式が提供・保守しているパッケージ** +- 初回リリースからの期間が短い、DL 数が少ないなどは基準対象外 +- ただしセキュリティアドバイザリ対応が遅い場合は代替案を検討する + +## 8.2 業務要件に固有のドメインライブラリ + +- 特定の業務要件を満たすために代替が存在しない場合 +- 内部に閉じた利用であり、影響範囲が限定的な場合 +- そのパッケージの安全性評価（コードレビューなど）を追加で行うこと + +## 8.3 新興だが有望なライブラリ + +- コミュニティの成長速度が速く、今後の標準になり得るもの +- メンテナーの信頼性・活動実績が高い場合（例：著名 OSS 開発者） +- 導入時に「試験導入」とし、運用プロジェクトで実際の動向を半年観測する + +## 8.4 社内フォーク・内部改修を前提とする場合 + +- OSS 版に課題があるが、**社内でフォークし保守できる体制がある** +- ライセンスがフォークを許可していることが必須 +- フォーク後は依存が外部サプライチェーンから切り離されるため、基準緩和を認める + +## 8.5 インフラ構成やセキュリティ製品が強制するパッケージ + +- APM（New Relic 等）、セキュリティエージェント、Observability エージェント +- プラットフォームとの互換性のため採用が必須のケース +- ベンダー側のサポートポリシーに準拠する + +--- + +