update-specification

仕様の更新

あなたの目標は、新しい要件や既存のコードへの更新に基づいて、既存の仕様ファイル ${file} を更新することです。

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

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

• 正確で、明示的で、曖昧さのない言葉を使用してください。
• 要件、制約、および推奨事項を明確に区別してください。
• 解析しやすいように構造化されたフォーマット（見出し、リスト、表）を使用してください。
• 慣用句、比喩、または文脈に依存する参照を避けてください。
• すべての頭字語とドメイン固有の用語を定義してください。
• 該当する場合は、例とエッジケースを含めてください。
• ドキュメントが自己完結しており、外部の文脈に依存しないことを確認してください。

仕様は /spec/ ディレクトリに保存し、次の命名規則に従って名前を付ける必要があります：[a-z0-9-]+.md。名前は仕様の内容を表すものとし、高レベルの目的（[schema、tool、data、infrastructure、process、architecture、design] のいずれか）で始めてください。

仕様ファイルは、整形式の Markdown でフォーマットする必要があります。

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

---
title: [Concise Title Describing the Specification's Focus]
version: [Optional: e.g., 1.0, Date]
date_created: [YYYY-MM-DD]
last_updated: [Optional: YYYY-MM-DD]
owner: [Optional: Team/Individual responsible for this spec]
tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
---

# Introduction

[A short concise introduction to the specification and the goal it is intended to achieve.]

## 1. Purpose & Scope

[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]

## 2. Definitions

[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]

## 3. Requirements, Constraints & Guidelines

[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]

- **REQ-001**: Requirement 1
- **SEC-001**: Security Requirement 1
- **[3 LETTERS]-001**: Other Requirement 1
- **CON-001**: Constraint 1
- **GUD-001**: Guideline 1
- **PAT-001**: Pattern to follow 1

## 4. Interfaces & Data Contracts

[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]

## 5. Acceptance Criteria

[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]

- **AC-001**: Given [context], When [action], Then [expected outcome]
- **AC-002**: The system shall [specific behavior] when [condition]
- **AC-003**: [Additional acceptance criteria as needed]

## 6. Test Automation Strategy

[Define the testing approach, frameworks, and automation requirements.]

- **Test Levels**: Unit, Integration, End-to-End
- **Frameworks**: MSTest, FluentAssertions, Moq (for .NET applications)
- **Test Data Management**: [approach for test data creation and cleanup]
- **CI/CD Integration**: [automated testing in GitHub Actions pipelines]
- **Coverage Requirements**: [minimum code coverage thresholds]
- **Performance Testing**: [approach for load and performance testing]

## 7. Rationale & Context

[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]

## 8. Dependencies & External Integrations

[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]

### External Systems
- **EXT-001**: [External system name] - [Purpose and integration type]

### Third-Party Services
- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]

### Infrastructure Dependencies
- **INF-001**: [Infrastructure component] - [Requirements and constraints]

### Data Dependencies
- **DAT-001**: [External data source] - [Format, frequency, and access requirements]

### Technology Platform Dependencies
- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]

### Compliance Dependencies
- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]

**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".

## 9. Examples & Edge Cases

```code
// Code snippet or data example demonstrating the correct application of the guidelines, including edge cases

10. 検証基準

[この仕様への準拠のために満たす必要がある基準またはテストをリストアップしてください。]

11. 関連仕様 / 参考文献

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