create-ai-project 1.11.2

package/docs/adr/template-ja.md

@@ -0,0 +1,64 @@
+# [ADR番号] [タイトル]
+
+## ステータス
+
+[Proposed | Accepted | Deprecated | Superseded]
+
+## コンテキスト
+
+[決定が必要になった背景や理由を記述。問題の本質、現状の課題、制約事項などを含める]
+
+## 決定事項
+
+[実際に決定した内容を記述。具体的で明確な記述を心がける]
+
+### 決定の詳細
+
+| 項目 | 内容 |
+|------|------|
+| **Decision** | [一文での決定内容] |
+| **Why now** | [なぜ今これをやるのか（タイミングの理由）] |
+| **Why this** | [他案ではなくこれを選ぶ理由（1〜3行）] |
+| **Known unknowns** | [現時点で不確実な点を最低1つ] |
+| **Kill criteria** | [この決定を撤回すべきシグナルを1つ] |
+
+## 根拠
+
+[なぜこの決定を下したのか、他の選択肢と比較してなぜこれが最良なのかを説明]
+
+### 検討した選択肢
+
+1. **選択肢1**: [説明]
+   - 利点: [利点を列挙]
+   - 欠点: [欠点を列挙]
+
+2. **選択肢2**: [説明]
+   - 利点: [利点を列挙]
+   - 欠点: [欠点を列挙]
+
+3. **選択肢3（採用）**: [説明]
+   - 利点: [利点を列挙]
+   - 欠点: [欠点を列挙]
+
+## 影響
+
+### ポジティブな影響
+
+- [プロジェクトやシステムへの良い影響を列挙]
+
+### ネガティブな影響
+
+- [プロジェクトやシステムへの悪い影響や、受け入れる必要のあるトレードオフを列挙]
+
+### 中立的な影響
+
+- [良くも悪くもない、単に変化する事項を列挙]
+
+## 実装への指針
+
+[原則的な方向性のみ。実装手順はDesign Docへ]
+例：「依存性注入を使用」○、「Phase 1で実装」×
+
+## 関連情報
+
+- [関連するADR、ドキュメント、issue、PRなどへのリンク]

package/docs/design/template-en.md

@@ -0,0 +1,281 @@
+# [Feature Name] Design Document
+
+## Overview
+
+[Explain the purpose and overview of this feature in 2-3 sentences]
+
+## Design Summary (Meta)
+
+```yaml
+design_type: "new_feature|extension|refactoring"
+risk_level: "low|medium|high"
+main_constraints:
+  - "[constraint 1]"
+  - "[constraint 2]"
+biggest_risks:
+  - "[risk 1]"
+  - "[risk 2]"
+unknowns:
+  - "[uncertainty 1]"
+  - "[uncertainty 2]"
+```
+
+## Background and Context
+
+### Prerequisite ADRs
+
+- [ADR File Name]: [Related decision items]
+- Reference common technical ADRs when applicable
+
+### Agreement Checklist
+
+#### Scope
+- [ ] [Features/components to change]
+- [ ] [Features to add]
+
+#### Non-Scope (Explicitly not changing)
+- [ ] [Features/components not to change]
+- [ ] [Existing logic to preserve]
+
+#### Constraints
+- [ ] Parallel operation: [Yes/No]
+- [ ] Backward compatibility: [Required/Not required]
+- [ ] Performance measurement: [Required/Not required]
+
+### Problem to Solve
+
+[Specific problems or challenges this feature aims to address]
+
+### Current Challenges
+
+[Current system issues or limitations]
+
+### Requirements
+
+#### Functional Requirements
+
+- [List mandatory functional requirements]
+
+#### Non-Functional Requirements
+
+- **Performance**: [Response time, throughput requirements]
+- **Scalability**: [Requirements for handling increased load]
+- **Reliability**: [Error rate, availability requirements]
+- **Maintainability**: [Code readability and changeability]
+
+## Acceptance Criteria (AC) - EARS Format
+
+Each AC is written in EARS format. Keywords determine test type.
+
+### [Functional Requirement 1]
+
+- [ ] **When** user clicks login button with valid credentials, the system shall authenticate and redirect to dashboard
+- [ ] **If** credentials are invalid, **then** the system shall display error message "Invalid credentials"
+- [ ] **While** user is logged in, the system shall maintain the session for 60 minutes
+
+### [Functional Requirement 2]
+
+- [ ] The system shall display data list with pagination of 10 items per page
+- [ ] **When** input is entered in search field, the system shall apply real-time filtering
+  - **Property**: `filtered.every(item => item.name.includes(query))`
+
+## Existing Codebase Analysis
+
+### Implementation Path Mapping
+| Type | Path | Description |
+|------|------|-------------|
+| Existing | src/[actual-path] | [Current implementation] |
+| New | src/[planned-path] | [Planned new creation] |
+
+### Integration Points (Include even for new implementations)
+- **Integration Target**: [What to connect with]
+- **Invocation Method**: [How it will be invoked]
+
+## Design
+
+### Change Impact Map
+
+```yaml
+Change Target: [Component/feature to change]
+Direct Impact:
+  - [Files/functions requiring direct changes]
+  - [Interface change points]
+Indirect Impact:
+  - [Data format changes]
+  - [Processing time changes]
+No Ripple Effect:
+  - [Explicitly specify unaffected features]
+```
+
+### Architecture Overview
+
+[How this feature is positioned within the overall system]
+
+### Data Flow
+
+```
+[Express data flow using diagrams or pseudo-code]
+```
+
+### Integration Points List
+
+| Integration Point | Location | Old Implementation | New Implementation | Switching Method |
+|-------------------|----------|-------------------|-------------------|------------------|
+| Integration Point 1 | [Class/Function] | [Existing Process] | [New Process] | [DI/Factory etc.] |
+| Integration Point 2 | [Another Location] | [Existing] | [New] | [Method] |
+
+### Main Components
+
+#### Component 1
+
+- **Responsibility**: [Scope of responsibility for this component]
+- **Interface**: [APIs and type definitions provided]
+- **Dependencies**: [Relationships with other components]
+
+#### Component 2
+
+- **Responsibility**: [Scope of responsibility for this component]
+- **Interface**: [APIs and type definitions provided]
+- **Dependencies**: [Relationships with other components]
+
+### Type Definitions
+
+```typescript
+// Record major type definitions here
+```
+
+### Data Contract
+
+#### Component 1
+
+```yaml
+Input:
+  Type: [TypeScript type definition]
+  Preconditions: [Required items, format constraints]
+  Validation: [Validation method]
+
+Output:
+  Type: [TypeScript type definition]
+  Guarantees: [Conditions that must always be met]
+  On Error: [Exception/null/default value]
+
+Invariants:
+  - [Conditions that remain unchanged before and after processing]
+```
+
+### State Transitions and Invariants (When Applicable)
+
+```yaml
+State Definition:
+  - Initial State: [Initial values and conditions]
+  - Possible States: [List of states]
+
+State Transitions:
+  Current State → Event → Next State
+
+System Invariants:
+  - [Conditions that hold in any state]
+```
+
+### Error Handling
+
+[Types of errors and how to handle them]
+
+### Logging and Monitoring
+
+[What to record in logs and how to monitor]
+
+## Implementation Plan
+
+### Implementation Approach
+
+**Selected Approach**: [Approach name or combination]
+**Selection Reason**: [Reason considering project constraints and technical dependencies]
+
+### Technical Dependencies and Implementation Order
+
+#### Required Implementation Order
+1. **[Component/Feature A]**
+   - Technical Reason: [Why this needs to be implemented first]
+   - Dependent Elements: [Other components that depend on this]
+
+2. **[Component/Feature B]**
+   - Technical Reason: [Technical necessity to implement after A]
+   - Prerequisites: [Required pre-implementations]
+
+### Integration Points
+Each integration point requires E2E verification:
+
+**Integration Point 1: [Name]**
+- Components: [Component A] → [Component B]
+- Verification: [How to verify integration works]
+
+**Integration Point 2: [Name]**
+- Components: [Component B] → [Component C]
+- Verification: [How to verify integration works]
+
+### Migration Strategy
+
+[Technical migration approach, ensuring backward compatibility]
+
+## Test Strategy
+
+### Basic Test Design Policy
+
+Automatically derive test cases from acceptance criteria:
+- Create at least one test case for each acceptance criterion
+- Implement measurable standards from acceptance criteria as assertions
+
+### Unit Tests
+
+[Unit testing policy and coverage goals]
+- Verify individual elements of functional acceptance criteria
+
+### Integration Tests
+
+[Integration testing policy and important test cases]
+- Verify combined operations of functional acceptance criteria
+
+### E2E Tests
+
+[E2E testing policy]
+- Verify entire scenarios of acceptance criteria
+- Confirm functional operation from user perspective
+
+### Performance Tests
+
+[Performance testing methods and standards]
+- Verify performance standards of non-functional acceptance criteria
+
+## Security Considerations
+
+[Security concerns and countermeasures]
+
+## Future Extensibility
+
+[Considerations for future feature additions or changes]
+
+## Alternative Solutions
+
+### Alternative 1
+
+- **Overview**: [Description of alternative solution]
+- **Advantages**: [Advantages]
+- **Disadvantages**: [Disadvantages]
+- **Reason for Rejection**: [Why it wasn't adopted]
+
+## Risks and Mitigation
+
+| Risk | Impact | Probability | Mitigation |
+|------|--------|-------------|------------|
+| [Risk 1] | High/Medium/Low | High/Medium/Low | [Countermeasure] |
+
+## References
+
+- [Related documentation and links]
+
+## Update History
+
+| Date | Version | Changes | Author |
+|------|---------|---------|--------|
+| YYYY-MM-DD | 1.0 | Initial version | [Name] |

package/docs/design/template-ja.md

@@ -0,0 +1,285 @@
+# [機能名] Design Document
+
+## 概要
+
+[この機能の目的と概要を2-3文で説明]
+
+## Design Summary (Meta)
+
+```yaml
+design_type: "新機能|既存拡張|リファクタリング"
+risk_level: "low|medium|high"
+main_constraints:
+  - "[制約1]"
+  - "[制約2]"
+biggest_risks:
+  - "[リスク1]"
+  - "[リスク2]"
+unknowns:
+  - "[不確実な点1]"
+  - "[不確実な点2]"
+```
+
+## 背景とコンテキスト
+
+### 前提となるADR
+
+- [ADRファイル名]: [関連する決定事項]
+- 共通技術ADRがある場合は参照
+
+### 合意事項チェックリスト
+
+#### スコープ
+- [ ] [変更する機能/コンポーネント]
+- [ ] [追加する機能]
+
+#### 非スコープ（明示的に変更しないもの）
+- [ ] [変更しない機能/コンポーネント]
+- [ ] [保持する既存ロジック]
+
+#### 制約条件
+- [ ] 並行運用: [あり/なし]
+- [ ] 後方互換性: [必要/不要]
+- [ ] パフォーマンス測定: [必要/不要]
+
+### 解決する問題
+
+[この機能が解決しようとしている具体的な問題や課題]
+
+### 現状の課題
+
+[現在のシステムの問題点や制限]
+
+### 要件
+
+#### 機能要件
+
+- [必須の機能要件を列挙]
+
+#### 非機能要件
+
+- **パフォーマンス**: [応答時間、スループットなどの要件]
+- **スケーラビリティ**: [負荷増加時の対応要件]
+- **信頼性**: [エラー率、可用性などの要件]
+- **保守性**: [コードの理解しやすさ、変更のしやすさ]
+
+## 受入条件（AC）- EARS形式
+
+各ACはEARS形式で記述。キーワードがテスト種別を決定する。
+
+### [機能要件1]
+
+- [ ] **When** ユーザーが有効な認証情報でログインボタンをクリック, the system shall 認証成功しダッシュボードにリダイレクト
+- [ ] **If** 認証情報が無効, **then** the system shall エラーメッセージ「認証情報が正しくありません」を表示
+- [ ] **While** ユーザーがログイン状態, the system shall セッションを60分間維持
+
+### [機能要件2]
+
+- [ ] The system shall データ一覧を10件ずつページネーションして表示
+- [ ] **When** 検索フィールドに入力, the system shall リアルタイムでフィルタリングを適用
+  - **Property**: `filtered.every(item => item.name.includes(query))`
+
+## 既存コードベース分析
+
+### 実装パスマッピング
+| 種別 | パス | 説明 |
+|------|------|------|
+| 既存 | src/[実際のパス] | [現在の実装] |
+| 新規 | src/[計画パス] | [新規作成予定] |
+
+### 統合点（新規実装でも記載）
+- **統合先**: [どこと接続するか]
+- **呼び出し方法**: [どのように呼び出されるか]
+
+## 設計
+
+### 変更影響マップ
+
+```yaml
+変更対象: [変更するコンポーネント/機能]
+直接影響:
+  - [直接変更が必要なファイル/関数]
+  - [インターフェース変更箇所]
+間接影響:
+  - [データ形式の変更]
+  - [処理時間の変化]
+波及なし:
+  - [影響を受けない機能を明示]
+```
+
+### アーキテクチャ概要
+
+[システム全体の中でこの機能がどのように位置づけられるか]
+
+### データフロー
+
+```
+[データの流れを図や疑似コードで表現]
+```
+
+### 統合点一覧
+
+| 統合点 | 場所 | 旧実装 | 新実装 | 切り替え方法 |
+|---------|------|----------|----------|-------------|
+| 統合点1 | [クラス/関数] | [既存処理] | [新処理] | [DI/ファクトリ等] |
+| 統合点2 | [別の箇所] | [既存] | [新規] | [方法] |
+
+### 主要コンポーネント
+
+#### コンポーネント1
+
+- **責務**: [このコンポーネントの責任範囲]
+- **インターフェース**: [提供するAPIや型定義]
+- **依存関係**: [他のコンポーネントとの関係]
+
+#### コンポーネント2
+
+- **責務**: [このコンポーネントの責任範囲]
+- **インターフェース**: [提供するAPIや型定義]
+- **依存関係**: [他のコンポーネントとの関係]
+
+### 型定義
+
+```typescript
+// 主要な型定義をここに記載
+```
+
+### データ契約（Data Contract）
+
+#### コンポーネント1
+
+```yaml
+入力:
+  型: [TypeScript型定義]
+  前提条件: [必須項目、形式制約]
+  検証: [バリデーション方法]
+
+出力:
+  型: [TypeScript型定義]
+  保証: [必ず満たす条件]
+  エラー時: [例外/null/デフォルト値]
+
+不変条件:
+  - [処理の前後で変わらない条件]
+```
+
+### 状態遷移と不変条件（該当する場合）
+
+```yaml
+状態定義:
+  - 初期状態: [初期値と条件]
+  - 遷移可能状態: [状態のリスト]
+
+状態遷移:
+  現在状態 → イベント → 次状態
+
+システム不変条件:
+  - [どの状態でも成立する条件]
+```
+
+### エラーハンドリング
+
+[エラーの種類と対処方法]
+
+### ログとモニタリング
+
+[何をログに記録し、どのようにモニタリングするか]
+
+## 実装計画
+
+### 実装アプローチ
+
+**選択したアプローチ**: [アプローチ名または組み合わせ]
+**選択理由**: [プロジェクトの制約と技術的依存関係を考慮した理由]
+
+### 技術的依存関係と実装順序
+
+#### 実装の必要順序
+1. **[コンポーネント/機能A]**
+   - 技術的理由: [なぜこれを最初に実装する必要があるか]
+   - 依存される要素: [これに依存する他のコンポーネント]
+
+2. **[コンポーネント/機能B]**
+   - 技術的理由: [Aの後に実装する技術的必然性]
+   - 前提条件: [必要な事前実装]
+
+#### 並列実装可能な要素
+- [独立して実装可能なコンポーネント群]
+
+### 統合ポイントとE2E確認
+
+#### 統合ポイント1: [統合箇所]
+**確認手順**:
+1. [動作確認手順]
+2. [期待結果の確認]
+
+#### 統合ポイント2: [統合箇所]
+**確認手順**:
+1. [動作確認手順]
+2. [期待結果の確認]
+
+### 移行戦略
+
+[技術的な移行アプローチ、後方互換性の確保方法]
+
+## テスト戦略
+
+### テスト設計の基本方針
+
+受入条件から自動的にテストケースを導出：
+- 各受入条件に対して最低1つのテストケースを作成
+- 受入条件の測定可能な基準をアサーションとして実装
+
+### 単体テスト
+
+[単体テストの方針とカバレッジ目標]
+- 機能受入条件の個別要素を検証
+
+### 統合テスト
+
+[統合テストの方針と重要なテストケース]
+- 機能受入条件の結合動作を検証
+
+### E2Eテスト
+
+[E2Eテストの方針]
+- 受入条件のシナリオ全体を検証
+- ユーザー視点での機能動作を確認
+
+### パフォーマンステスト
+
+[パフォーマンステストの方法と基準]
+- 非機能受入条件のパフォーマンス基準を検証
+
+## セキュリティ考慮事項
+
+[セキュリティ上の懸念事項と対策]
+
+## 今後の拡張性
+
+[将来的な機能追加や変更に対する考慮]
+
+## 代替案の検討
+
+### 代替案1
+
+- **概要**: [代替案の説明]
+- **利点**: [利点]
+- **欠点**: [欠点]
+- **不採用の理由**: [なぜ採用しなかったか]
+
+## リスクと軽減策
+
+| リスク | 影響度 | 発生確率 | 軽減策 |
+|--------|--------|----------|--------|
+| [リスク1] | 高/中/低 | 高/中/低 | [対策] |
+
+## 参考資料
+
+- [関連するドキュメントやリンク]
+
+## 更新履歴
+
+| 日付 | 版 | 変更内容 | 作成者 |
+|------|-----|----------|--------|
+| YYYY-MM-DD | 1.0 | 初版作成 | [名前] |