仕様書の更新

ご自分の目標は、新要件または既存コードの更新に基づいて、既存の仕様書ファイル ${file} を更新することです。

仕様書は、ソリューションコンポーネントの要件、制約、およびインターフェースを、生成AIによる効果的な使用に向けて明確で曖昧さがなく構造化された方法で定義する必要があります。確立されたドキュメント標準に従い、コンテンツが機械可読でありながら自己完結していることを確認してください。

AI対応仕様書のベストプラクティス

• 正確で明示的で曖昧さのない言葉を使用してください。
• 要件、制約、および推奨事項を明確に区別してください。
• 構造化フォーマット(見出し、リスト、テーブル)を使用して、パースを容易にしてください。
• イディオム、隠喩、またはコンテキストに依存した参照は避けてください。
• すべての頭字語とドメイン固有の用語を定義してください。
• 該当する場合は、例とエッジケースを含めてください。
• ドキュメントが自己完結しており、外部コンテキストに依存していないことを確認してください。

仕様書は /spec/ ディレクトリに保存し、次の規則に従って命名してください: [a-z0-9-]+.md 。名前は仕様書のコンテンツを説明的に表し、高レベルな目的から始まる必要があります。この目的は [schema、tool、data、infrastructure、process、architecture、または design] のいずれかです。

仕様書ファイルは整形されたMarkdown形式である必要があります。

仕様書ファイルは以下のテンプレートに従い、すべてのセクションが適切に入力されていることを確認する必要があります。Markdownのフロントマターは、以下の例に従って正しく構造化される必要があります:

---
title: [仕様書の焦点を説明する簡潔なタイトル]
version: [オプション: 例: 1.0、日付]
date_created: [YYYY-MM-DD]
last_updated: [オプション: YYYY-MM-DD]
owner: [オプション: この仕様書の責任者となるチーム/個人]
tags: [オプション: 関連するタグまたはカテゴリのリスト。例: `infrastructure`、`process`、`design`、`app` など]
---

# はじめに

[仕様書の簡潔な紹介と、それが達成することを目的とした目標。]

## 1. 目的とスコープ

[仕様書の目的とその適用スコープについて、明確で簡潔な説明を提供します。意図された対象者と仮定を述べてください。]

## 2. 定義

[この仕様書で使用されているすべての頭字語、省略形、およびドメイン固有の用語をリストアップして定義します。]

## 3. 要件、制約、ガイドライン

[すべての要件、制約、ルール、およびガイドラインを明示的にリストアップします。明確性のために箇条書きまたはテーブルを使用してください。]

- **REQ-001**: 要件 1
- **SEC-001**: セキュリティ要件 1
- **[3 LETTERS]-001**: その他の要件 1
- **CON-001**: 制約 1
- **GUD-001**: ガイドライン 1
- **PAT-001**: 従うべきパターン 1

## 4. インターフェースとデータコントラクト

[インターフェース、API、データコントラクト、または統合ポイントを説明します。スキーマと例についてはテーブルまたはコードブロックを使用してください。]

## 5. 受入基準

[Given-When-Then形式を使用して、各要件の明確でテスト可能な受入基準を定義します。]

- **AC-001**: Given [コンテキスト]、When [アクション]、Then [期待される結果]
- **AC-002**: システムは [条件] のときに [特定の動作] を実行しなければならない
- **AC-003**: [必要に応じて追加の受入基準]

## 6. テスト自動化戦略

[テストのアプローチ、フレームワーク、および自動化要件を定義します。]

- **テストレベル**: ユニット、統合、エンドツーエンド
- **フレームワーク**: MSTest、FluentAssertions、Moq (.NETアプリケーション用)
- **テストデータ管理**: [テストデータの作成とクリーンアップのアプローチ]
- **CI/CD統合**: [GitHub Actionsパイプラインでの自動テスト]
- **カバレッジ要件**: [最小コードカバレッジ閾値]
- **パフォーマンステスト**: [負荷およびパフォーマンステストのアプローチ]

## 7. 根拠とコンテキスト

[要件、制約、およびガイドラインの背後にある推論を説明します。設計決定のコンテキストを提供してください。]

## 8. 依存関係と外部統合

[この仕様書に必要な外部システム、サービス、およびアーキテクチャ依存関係を定義します。**どのように** 実装されるかではなく、**何が** 必要かに焦点を当ててください。アーキテクチャ上の制約を表す場合を除き、特定のパッケージまたはライブラリバージョンの指定は避けてください。]

### 外部システム
- **EXT-001**: [外部システム名] - [目的と統合タイプ]

### サードパーティサービス
- **SVC-001**: [サービス名] - [必要な機能とSLA要件]

### インフラストラクチャ依存関係
- **INF-001**: [インフラストラクチャコンポーネント] - [要件と制約]

### データ依存関係
- **DAT-001**: [外部データソース] - [形式、頻度、およびアクセス要件]

### テクノロジープラットフォーム依存関係
- **PLT-001**: [プラットフォーム/ランタイム要件] - [バージョン制約と根拠]

### コンプライアンス依存関係
- **COM-001**: [規制またはコンプライアンス要件] - [実装への影響]

**注意**: このセクションはアーキテクチャおよびビジネス依存関係に焦点を当てるべきであり、特定のパッケージ実装ではありません。例えば、「Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1」ではなく「OAuth 2.0認証ライブラリ」を指定します。

## 9. 例とエッジケース

```code
// ガイドラインの正しい適用を示すコードスニペットまたはデータ例。エッジケースを含めます

10. 検証基準

[この仕様書への準拠のために満たさなければならない基準またはテストをリストアップします。]

11. 関連仕様書 / さらに詳しく

[関連仕様書 1へのリンク] [関連する外部ドキュメントへのリンク]