@einja/dev-cli 0.1.38 → 0.1.39

package/presets/default/.claude/skills/einja-task-qa/SKILL.md

@@ -26,9 +26,9 @@ allowed-tools:
 - **QAテスト（あなたが実施）**: 画面フロー、API連携、データ永続化等の統合動作確認
 
 **必須参照ドキュメント**:
-- `reference/failure-patterns.md` - 失敗原因分類の実践例（10パターン）
-- `reference/usage-patterns.md` - 利用パターン（5パターン）
-- `reference/troubleshooting.md` - トラブルシューティング（6ケース）
+- `references/failure-patterns.md` - 失敗原因分類の実践例（10パターン）
+- `references/usage-patterns.md` - 利用パターン（5パターン）
+- `references/troubleshooting.md` - トラブルシューティング（6ケース）
 - `docs/einja/steering/acceptance-criteria-and-qa-guide.md` - 価値あるテストの判定基準
 
 ---
@@ -37,9 +37,9 @@ allowed-tools:
 
 ### ステップ0: 引数の解析と初期化
 
-**入力形式**: `{spec_dir} [--task-group-id {task_group_id}]`
+**入力形式**: 自然言語でAC指定（task-executerから呼び出される）
 
-**例**: `docs/specs/tasks/user-auth/ --task-group-id 1.1`
+**例**: `docs/specs/issues/issue42-magic-link/ のstory1.mdにあるAC1.1, AC1.2のテストを実行してください`
 
 **TODOリストの作成**: TodoWriteツールで8ステップのTODOを作成してください。
 
@@ -94,9 +94,11 @@ AskUserQuestion:
 
 **前提**: テスト仕様は `spec-qa-generator` が作成済み。task-qaは**実行のみ**を担当。
 
-1. **テスト仕様ファイルの特定**: タスクグループID "1.1" → `qa-tests/phase1/1-1.md`
-2. **シナリオテストの確認**: `qa-tests/scenarios.md` で該当タスクの実施タイミングを確認
-3. **テスト仕様の読み込み**: テストシナリオ、確認項目、期待値を把握
+1. **テスト仕様ファイルの特定**: 自然言語で指定されたAC番号からStoryを判定
+   - 例: 「AC1.1, AC1.2のテストを実行」→ AC番号の先頭数字（1）からStory 1を特定 → `qa-tests/story1.md`
+   - 例: 「AC2.3のテストを実行」→ `qa-tests/story2.md`
+2. **シナリオテストの確認**: `qa-tests/scenarios.md` で該当ACの実施タイミングを確認
+3. **テスト仕様の読み込み**: story{N}.md内の該当ACセクションからテストシナリオ、確認項目、期待値を把握
 
 **エラー時**: テスト仕様が存在しない場合は失敗分類B（要件齟齬）→ spec-qa-generatorで作成が必要
 
@@ -207,7 +209,7 @@ AskUserQuestion:
 既存のテスト仕様ファイルに実施結果を記録します。
 
 1. **結果欄の更新**: 各テストシナリオの「結果」列を ✅/❌/⚠️ で更新
-2. **エビデンス保存**: `qa-tests/phase{N}/evidence/` にスクリーンショット、ログを保存
+2. **エビデンス保存**: `qa-tests/evidence/story{N}/` にスクリーンショット、ログを保存
 3. **実行ログの記載**: scenarios.md の該当シナリオに実行ログを追記
 
 ---
@@ -221,7 +223,7 @@ AskUserQuestion:
   "status": "SUCCESS" | "FAILURE" | "PARTIAL",
   "failureCategory": "A" | "B" | "C" | "D" | null,
   "nextAction": "finisher" | "executer" | "qa-retry",
-  "qaTestFile": "qa-tests/phase1/1-1.md",
+  "qaTestFile": "qa-tests/story1.md",
   "testSummary": {
     "total": 17,
     "passed": 12,
@@ -253,17 +255,17 @@ AskUserQuestion:
 ```
 {spec_dir}/
 └── qa-tests/
-    ├── phase1/
-    │   ├── 1-1.md
-    │   ├── 1-2.md
-    │   └── evidence/
-    ├── phase2/
-    │   └── ...
-    └── phase3/
-        └── ...
+    ├── scenarios.md
+    ├── story1.md
+    ├── story2.md
+    ├── story3.md
+    └── evidence/
+        ├── story1/
+        ├── story2/
+        └── story3/
 ```
 
-**パス規則**: タスクグループID "2.3" → `qa-tests/phase2/2-3.md`
+**パス規則**: AC番号 "AC2.3" → Story番号 2 → `qa-tests/story2.md`（AC2.3セクション）
 
 ---
 
@@ -297,9 +299,9 @@ AskUserQuestion:
 
 - `docs/einja/steering/acceptance-criteria-and-qa-guide.md` - QAテストの目的、失敗分類詳細、動作確認ツール使用法
 - `templates/qa-test-template.md` - QAテストファイルテンプレート
-- `reference/failure-patterns.md` - 失敗分類の実践例（10パターン）
-- `reference/usage-patterns.md` - 利用パターン（5パターン）
-- `reference/troubleshooting.md` - トラブルシューティング（6ケース）
+- `references/failure-patterns.md` - 失敗分類の実践例（10パターン）
+- `references/usage-patterns.md` - 利用パターン（5パターン）
+- `references/troubleshooting.md` - トラブルシューティング（6ケース）
 
 ---
 

package/presets/default/.claude/skills/einja-task-qa/{reference → references}/troubleshooting.md

@@ -34,7 +34,7 @@ QA実行時によくある問題と対処法。
 **対処法**:
 1. `ls -la {spec_dir}/qa-tests/` で権限確認
 2. `chmod -R u+w {spec_dir}/qa-tests/` で権限変更
-3. 不在時は `mkdir -p {spec_dir}/qa-tests/phase{N}/evidence/`
+3. 不在時は `mkdir -p {spec_dir}/qa-tests/evidence/story{N}/`
 
 ---
 

package/presets/default/.claude/skills/einja-task-qa/{reference → references}/usage-patterns.md

@@ -47,6 +47,6 @@ GitHub Actionsで自動QA実行（将来実装）
 ## パターン5: 手動QAレビュー
 
 ```
-ユーザー: "タスク1.1のQA結果を見せて"
-  → qa-tests/phase1/1-1.md読み込み → 結果サマリー表示
+ユーザー: "Story 1のQA結果を見せて"
+  → qa-tests/story1.md読み込み → 結果サマリー表示
 ```

package/presets/default/.claude/skills/einja-task-qa/templates/qa-test-template.md

@@ -1,8 +1,8 @@
-# Phase {phase_num}-{group_num}: {task_name} QAテスト結果
+# Story {N}: {ストーリー名} QAテスト結果
 
-## テスト対象タスク
-- **タスクID**: {開始タスクID}～{終了タスクID}
-- **タスク名**: {task_name}
+## テスト対象
+- **ストーリー**: Story {N} - {ストーリー名}
+- **対象AC**: AC{N}.1〜AC{N}.M
 - **実装日**: {date}
 - **テスター**: {tester}
 - **最終更新**: {date}
@@ -50,11 +50,11 @@ pnpm typecheck
 
 ---
 
-## タスク {task_id}: {task_name}
+## AC{N}.1: {ACの1文要約}
 
 ### 受け入れ条件
 <!-- requirements.md から該当ACの受け入れ条件を転記 -->
-- AC{N}.{M}: {Given-When-Then形式の基準}
+- AC{N}.1: {Given-When-Then形式の基準}
 
 ### テストシナリオ
 
@@ -70,7 +70,7 @@ pnpm typecheck
 - 「-」は手順のみで確認項目がない場合に使用
 - 備考欄はテストの区切りや注意事項を記載
 
-### 全体ステータス: - （未実施）
+### ステータス: - （未実施）
 
 #### 主な問題点
 - （実施後に記載）
@@ -79,26 +79,26 @@ pnpm typecheck
 - （実施後に記載）
 
 #### エビデンス
-- ログファイル: `qa-tests/phase{phase_num}/evidence/{task_id}-{evidence_id}.log`
-- スクリーンショット: `qa-tests/phase{phase_num}/evidence/{task_id}-{evidence_id}.png`
+- ログファイル: `qa-tests/evidence/story{N}/AC{N}-1-{evidence_id}.log`
+- スクリーンショット: `qa-tests/evidence/story{N}/AC{N}-1-{evidence_id}.png`
 
 ---
 
-<!-- 追加のタスクがある場合は上記セクションを繰り返す -->
+<!-- 追加のACがある場合は上記セクションを繰り返す -->
 
 ---
 
 ## 統合テスト結果サマリー
 
-### フェーズ{phase_num}-{group_num}全体結果
+### Story {N} 全体結果
 - **全体ステータス**: - （未実施）
-- **完了タスク**: 0/{total_tasks}
+- **完了AC**: 0/{total_acs}
 - **テスト合格率**: 0% (0/0)
 
 ### 修正が必要な項目
 - （実施後に記載）
 
-### 次フェーズへの引き継ぎ事項
+### 次ストーリーへの引き継ぎ事項
 - （実施後に記載）
 
 ### 改善提案

package/{scaffolds → presets/default}/.mcp.json

@@ -2,21 +2,34 @@
 	"mcpServers": {
 		"vibe_kanban": {
 			"command": "npx",
-			"args": ["-y", "vibe-kanban@latest", "--mcp"]
+			"args": [
+				"-y",
+				"vibe-kanban@latest",
+				"--mcp"
+			]
 		},
 		"codex": {
 			"type": "stdio",
 			"command": "codex",
-			"args": ["mcp-server"]
+			"args": [
+				"mcp-server"
+			]
 		},
 		"context7": {
 			"command": "npx",
-			"args": ["-y", "@upstash/context7-mcp"]
+			"args": [
+				"-y",
+				"@upstash/context7-mcp"
+			]
 		},
 		"playwright": {
 			"type": "stdio",
 			"command": "npx",
-			"args": ["-y", "@playwright/mcp", "--isolated"]
+			"args": [
+				"-y",
+				"@playwright/mcp",
+				"--isolated"
+			]
 		},
 		"serena": {
 			"type": "stdio",
@@ -29,7 +42,8 @@
 				"--context",
 				"claude-code",
 				"--open-web-dashboard",
-				"false"]
+				"false"
+			]
 		},
 		"github": {
 			"type": "http",
@@ -37,6 +51,13 @@
 			"headers": {
 				"Authorization": "Bearer ${GITHUB_TOKEN}"
 			}
+		},
+		"drawio": {
+			"command": "npx",
+			"args": [
+				"-y",
+				"@drawio/mcp@latest"
+			]
 		}
 	}
-}
+}

package/presets/default/.vscode/settings.json

@@ -0,0 +1,18 @@
+{
+	"editor.codeActionsOnSave": {
+		"source.fixAll.eslint": "explicit",
+		"source.organizeImports.biome": "explicit",
+		"source.fixAll.biome": "explicit"
+	},
+	"editor.defaultFormatter": "biomejs.biome",
+	"editor.formatOnSave": true,
+	"eslint.enable": false,
+	"prettier.enable": false,
+	"prettier.useEditorConfig": false,
+	"[json]": {
+		"editor.defaultFormatter": "biomejs.biome"
+	},
+	"[jsonc]": {
+		"editor.defaultFormatter": "vscode.json-language-features"
+	}
+}

package/presets/default/CLAUDE.md.template

@@ -0,0 +1,192 @@
+# Claude Code 指示書
+- あなたの役割は世界的に有名な開発プロジェクトシニアマネージャーでありagentオーケストレーターです。
+- 回答は日本語で行ってください。
+- 必ずこのドキュメントの通りに作業を行ってください。
+
+## 基本原則
+
+1. **シンプルさ優先**: 必要最小限の変更に留める。過度な汎用化・抽象化をしない
+2. **根本原因の追求**: 一時的な回避策ではなく、根本原因を特定して他の開発者、他のAgentプロセスでも再現性のある修正をする
+3. **影響範囲の最小化**: 変更は必要な箇所のみ。関係ないコードに触れない
+4. **直接実装の禁止**: あなたは絶対に直接実装を行わない。すべての作業はsubagentに委託し、可能な限り並行で呼び出す。サブエージェントの出力はユーザにも見える場所に出力すること
+5. **実装品質の自己検証**: 複雑な変更では完了前に「よりエレガントな方法はないか」を自問する。ただし単純な修正には不要
+
+## サブエージェント委託ルール
+
+#### カスタムサブエージェント（直接委託）
+
+| 作業 | 委託先 |
+|------|--------|
+| コンフリクト解消 | `conflict-resolver` |
+| Codex作業（レビュー・実装支援等） | `codex-agent` |
+| フロントエンド アーキテクチャ設計 | `frontend-architect` |
+| フロントエンド デザイン実装 | `design-engineer` |
+| フロントエンド コーディング | `frontend-coder` |
+| バックエンド アーキテクチャ設計 | `backend-architect` |
+
+#### Skill・コマンド（直接呼び出し）
+
+| 名前 | 用途 |
+|------|------|
+| `einja-task-commit` | コミット・プッシュ |
+| `einja-conflict-resolver` | gitコンフリクト解消 |
+| `einja-skill-creator` | Skill作成・更新 |
+| `einja-infra-maintenance` | インフラ環境セットアップ・メンテナンス |
+| `einja:task-exec` | タスクグループ実行 |
+| `einja:spec-create` | 仕様書作成 |
+
+## コード変更時の動作方針
+
+**【厳守事項】コード変更の指示があった場合、絶対に即座に実装を開始してはならない。（サブエージェントとしての動作時は除く）**
+
+### 必須フロー
+1. 問題・要件を調査・分析する
+2. 修正計画を `docs/plans/` に作成し提示する
+3. **ユーザーの明示的な承認を得る**
+4. 承認後、`docs/plans/todo-{plan名}.md` で進捗管理しながら実装を開始する
+
+### 例外（承認不要）
+- 読み取り専用操作（質問への回答、情報調査、コード調査）
+
+### 提案文言
+「この変更について、まずPlanモードで計画を立てて提示しましょうか？」
+
+**注意**: この規則は新規セッションだけでなく、セッション継続中のすべてのコード変更に適用される。ユーザーが「直して」「修正して」「なおしたい」等と言った場合も、必ず計画を提示して承認を得ること。
+
+### 計画・進捗ファイルの規約
+
+| ファイル | パス | 管理者 |
+|---------|------|--------|
+| Plan | `docs/plans/{name}.md` | 親エージェント |
+| Todo | `docs/plans/todo-{name}.md` | 親エージェントのみ（サブエージェント編集禁止） |
+
+### 実装中のブロッカー対応
+
+| 状況 | 対応 |
+|------|------|
+| 技術的な軽微エラー（lint、型エラー、テスト修正） | サブエージェントが自律修正。再承認不要 |
+| 設計変更が必要なブロッカー | **即座に停止**。ユーザーに報告し再計画 |
+| 要件の曖昧さが判明 | **即座に停止**。AskUserQuestionで確認 |
+| 想定外の事態全般 | **即座に停止**。計画や想定と違う事実が発覚した場合、再計画 |
+
+## gitコンフリクト発生時の対応
+
+**【必須】** gitコンフリクトが発生した場合、必ず `.claude/skills/einja-conflict-resolver/SKILL.md` の手順に従うこと。
+
+## サブエージェントのgit操作安全ルール
+
+**【厳守事項】** サブエージェントは自身が変更したファイル以外のワーキングツリー状態を変更してはならない。
+
+### 禁止コマンド（絶対に使用禁止）
+
+| コマンド | 理由 |
+|---------|------|
+| `git checkout .` | 全ファイルの変更を破棄。他サブエージェントの変更が消失する |
+| `git restore .` | 同上 |
+| `git reset HEAD`（パスなし） | ステージング全体を解除。他サブエージェントのステージ済み変更が影響を受ける |
+| `git reset --hard` | ワーキングツリーとステージングの全変更を破棄 |
+| `git clean -fd` | 未追跡ファイルを全削除。他サブエージェントの新規ファイルが消失する |
+| `git stash` | 全変更を退避。他サブエージェントの変更も巻き込む |
+| `git add .` / `git add -A` | 全ファイルをステージ。他サブエージェントの変更を意図せずコミットに含める |
+
+### 許可操作
+
+- **ファイルパスを明示した操作のみ許可**: `git add <file>`, `git restore --staged <file>`, `git checkout -- <file>` 等
+- 自身が変更・作成したファイルのみを対象とすること
+
+### コミット時の注意
+
+- `git status` で他の変更が混入していないか必ず確認すること
+- 他サブエージェントの変更がステージされている場合は、`git restore --staged <file>` でアンステージすること
+
+### オーケストレーター（親エージェント）の責務
+
+- 並行実行するサブエージェント間で変更対象ファイルが重複しないよう事前に調整する
+- git操作（コミット・プッシュ）は可能な限り `einja-task-commit` Skill 経由で一元管理する
+- サブエージェントに直接コミットさせる場合は、変更対象ファイルを明示的に指定すること
+
+## プロジェクト概要
+
+Turborepoモノレポ構成（pnpm workspaces）。詳細が必要な場合は以下のSkillを参照:
+- `einja-project-overview` - 構成、技術スタック、頻出コマンド
+- `einja-coding-standards` - コーディング規約、インポートパス規約
+- `einja-infra-maintenance` - 開発環境セットアップ、サーバー管理
+
+## マネージドディレクトリ（編集禁止）
+
+`docs/einja/` は `@einja/dev-cli` パッケージで管理されている。`einja sync` で同期されるため、以下のルールを厳守すること。
+
+| ディレクトリ | 操作 | 理由 |
+|------------|------|------|
+| `docs/einja/steering/` | **読み取り専用** | CLI同期で上書きされる |
+| `docs/einja/templates/` | **読み取り専用** | CLI同期で上書きされる |
+| `docs/einja/instructions/` | **読み取り専用** | CLI同期で上書きされる |
+| `docs/einja/example/` | **読み取り専用** | CLI同期で上書きされる |
+| `docs/einja/memory/` | **読み書き可** | プロジェクト固有の学習記録（同期対象外） |
+
+**禁止事項**: `docs/einja/` 配下に新規ファイル・ディレクトリを作成しないこと（`memory/` 内を除く）
+
+## AskUserQuestion ツールの使用
+
+**不明点や曖昧な点がある場合は、推測で進めずに必ず AskUserQuestion ツールで確認してください。**
+
+### 基本姿勢
+- 要件が不明確な場合は**積極的に質問する**
+- 推測や仮定で実装を進めない
+- 確認することで手戻りを防ぐ
+
+### 使用必須シーン
+- **要件・仕様が不明確な場合**
+- **複数の実装方法・設計アプローチがある場合**
+- **技術的な判断が必要な場合**（ライブラリ選定、アーキテクチャ決定など）
+- 重要な判断（コミット分割、リファクタリング方針など）
+- 破壊的な操作の前
+
+### 提示形式
+- テーブル形式: 複数項目の比較
+- 番号付きリスト: 詳細説明が必要な場合
+- 推奨オプションには `（推奨）` と理由を付記
+
+## 報告ルール
+
+### 出力形式
+各エージェント定義の `skills: [output-format]` により、出力テンプレートは自動ロードされます。プロンプトへのテンプレート埋め込みは不要です。
+
+### 結果表示の原則
+- サブエージェントの最終出力は**そのまま全文**をユーザーに表示する
+- 省略・要約・言い換えは**禁止**
+
+### 進捗報告の原則
+- 複数ステップのタスクでは、各ステップ完了時にユーザーへ進捗を報告する
+- 完了した作業と次のステップを簡潔に示す
+- 問題が発生した場合は即座に共有する
+
+## 学習ループ
+
+ユーザーから修正・指摘を受けた場合、同じ失敗を繰り返さないために学習を記録する。
+
+| 記録先 | 内容 | 例 |
+|--------|------|-----|
+| `docs/einja/memory/decisions.md` | 判断の「なぜ」 | 技術選定理由、設計判断 |
+| `docs/einja/memory/patterns.md` | 解法の「どうやって」 | 再利用可能なパターン、失敗回避策 |
+
+### ルール
+- 修正指摘を受けたら、作業完了前に該当memoryファイルに記録する
+- 記録した内容をユーザーに報告する
+- セッション開始時にmemoryファイルを確認し、過去の学習を活用する
+
+## 完了判定の基準
+
+タスク完了を宣言する前に、以下を必ず検証する。
+
+### 必須チェック
+- [ ] 変更ファイルがディスク上に実在する（`grep`や`Read`で確認。サブエージェント報告を鵜呑みにしない）
+- [ ] `pnpm prepush`（lint + typecheck + test）が通る
+- [ ] 動作確認済み（API→curl、画面→Playwright MCP、スクリプト→実行確認）
+- [ ] `git diff` で意図しない変更が混入していないことを確認（`git diff --stat` で変更ファイル一覧を確認）
+
+### 禁止事項
+- サブエージェントの「完了」報告のみで完了判定しない
+- 検証をスキップして完了宣言しない
+
+

package/{scaffolds → presets/default/docs/einja}/example/README.md

@@ -24,7 +24,7 @@
 - 各セクションの具体的な記述例を確認
 
 ### 3. QA 仕様書の構造を理解する
-- qa-tests/phaseN/X-Y.md の形式を確認
+- qa-tests/story{N}.md の形式を確認
 - 失敗時の報告方法を参考にする
 
 ## 次のステップ

package/{scaffolds → presets/default/docs/einja}/example/specs/issues/issue999-example-task/qa-tests/README.md

@@ -2,39 +2,37 @@
 
 ## 概要
 このディレクトリは、タスク実装後のQAテスト結果を記録するためのサンプル構造です。
-実際のプロジェクトでは、タスクファイル（例：`.kiro/specs/subscription-management/tasks.md`）と同じディレクトリに`qa-tests`フォルダを作成して管理します。
+実際のプロジェクトでは、仕様書ディレクトリ（例：`docs/specs/issues/issue42-user-management/`）と同じディレクトリに`qa-tests`フォルダを作成して管理します。
 
 ## ディレクトリ構造
 ```
 qa-tests/
 ├── README.md       # このファイル（QAテストガイド）
 ├── scenarios.md    # シナリオテスト仕様（必須）
-├── phase1/         # フェーズ1のテスト
-│   ├── 1-1.md     # タスク1.1.xのテスト結果
-│   ├── 1-2.md     # タスク1.2.xのテスト結果
-│   ├── 1-3.md     # タスク1.3.xのテスト結果
-│   └── evidence/   # スクリーンショット等のエビデンス
-├── phase2/         # フェーズ2のテスト
-│   ├── 2-1.md
-│   └── evidence/
-└── summary.md      # 全体のテストサマリー（オプション）
+├── story1.md       # Story 1（AC1.x）のテスト結果
+├── story2.md       # Story 2（AC2.x）のテスト結果
+├── story3.md       # Story 3（AC3.x）のテスト結果
+└── evidence/       # エビデンス
+    ├── story1/     # Story 1のスクリーンショット等
+    ├── story2/     # Story 2のスクリーンショット等
+    └── story3/     # Story 3のスクリーンショット等
 ```
 
 ## QAテストファイルの記載内容
 
-各QAテストファイル（例：`phase1/1-1.md`）には以下を記載：
+各QAテストファイル（例：`story1.md`）には以下を記載：
 
-1. **ヘッダー情報**: テスト対象タスクID、タスク名、実装日、テスト実施日
-2. **各タスクのテスト内容**: 受け入れ条件（AC番号）、テストシナリオ（表形式）、全体ステータス、主な問題点、対応策、エビデンス
-3. **統合テスト結果サマリー**: フェーズ全体の結果サマリー、次フェーズへの引き継ぎ事項、改善提案
+1. **ヘッダー情報**: テスト対象ストーリー、対象AC範囲、実装日、テスト実施日
+2. **各ACのテスト内容**: 受け入れ条件（AC番号）、テストシナリオ（表形式）、ステータス、主な問題点、対応策、エビデンス
+3. **統合テスト結果サマリー**: ストーリー全体の結果サマリー、次ストーリーへの引き継ぎ事項、改善提案
 4. **報告と対応**: 失敗原因分類、差し戻し情報、修正優先度
 
 ## テスト結果の更新方針
 
 - **上書き更新**: 実施結果セクションは最新の結果のみを記載。過去の履歴は保持しない（Gitで管理）。更新日時を必ず記載。
 - **ステータス定義**: ✅ PASS（すべての受け入れ条件を満たす）、❌ FAIL（要修正）、⚠️ PARTIAL（軽微な問題あり）、🔄 未実施（テスト未実施）
-- **エビデンスの保存**: `qa-tests/phase1/evidence/` 配下にログファイル、スクリーンショット、テストレポート等を保存。命名規則: `{タスク番号}-{内容}.{拡張子}`
-- **実施タイミング**: タスク完了時（個別テスト）、フェーズ完了時（統合テスト）、リリース前（回帰テスト）
+- **エビデンスの保存**: `qa-tests/evidence/story{N}/` 配下にログファイル、スクリーンショット、テストレポート等を保存。命名規則: `AC{N}-{M}-{内容}.{拡張子}`
+- **実施タイミング**: AC実装完了時（個別テスト）、ストーリー全AC完了時（統合テスト）、リリース前（回帰テスト）
 
 ## テストシナリオの記載形式
 
@@ -88,12 +86,11 @@ curl -X POST http://localhost:3000/api/auth/magic-link \
 #### スクリーンショット命名規則
 ```
 evidence/
-├── [画面名]-[状態].png
-├── login-default.png          # ログイン画面のデフォルト状態
-├── login-error.png            # ログイン画面のエラー状態
-├── email-sent.png             # メール送信確認画面
-├── error-expired.png          # エラー画面（期限切れ）
-└── ...
+├── story{N}/
+│   ├── AC{N}-{M}-[状態].png
+│   ├── AC1-1-default.png          # AC1.1のデフォルト状態
+│   ├── AC1-1-error.png            # AC1.1のエラー状態
+│   └── ...
 ```
 
 ## テストツール使用例
@@ -122,7 +119,7 @@ mcp_playwright.type({
 
 // スクリーンショット取得
 mcp_playwright.screenshot({
-  path: 'qa-tests/phase1/evidence/test.png'
+  path: 'qa-tests/evidence/story1/AC1-1-screenshot.png'
 })
 ```
 

package/{scaffolds → presets/default/docs/einja}/example/specs/issues/issue999-example-task/qa-tests/scenarios.md

@@ -13,12 +13,11 @@
 
 ### 関連
 - **受け入れ条件**: AC1.1, AC1.2, AC1.3, AC1.4, AC1.5, AC1.6, AC1.7, AC1.8, AC1.9
-- **関連タスク**: 1.1.1, 1.1.2, 1.1.3, 2.1.1
 
 ### 実施タイミング
-- **タスク1.1.3完了後**: Step 1-4まで（部分実行：API認証まで）
-- **タスク2.1.5完了後**: 全Step（フル実行：UI実装完了）
-- **タスク2.1.8完了後**: 全Step（リグレッション：Phase 2完了確認）
+- **AC1.1〜AC1.3実装後**: Step 1-4まで（部分実行：API認証まで）
+- **AC1.4〜AC1.9実装後**: 全Step（フル実行：UI実装完了）
+- **全AC実装後**: 全Step（リグレッション：最終確認）
 
 ### テスト手順
 
@@ -45,12 +44,11 @@
 
 ### 関連
 - **受け入れ条件**: AC2.1, AC2.2, AC2.3
-- **関連タスク**: 1.2.1, 1.2.2
 
 ### 実施タイミング
-- **タスク1.2.1完了後**: Step 1-2まで（部分実行：取得APIのみ）
-- **タスク1.2.2完了後**: 全Step（フル実行：プロフィールAPI実装完了）
-- **タスク2.1.8完了後**: 全Step（リグレッション：認証UI変更の影響確認）
+- **AC2.1実装後**: Step 1-2まで（部分実行：取得APIのみ）
+- **AC2.1〜AC2.3実装後**: 全Step（フル実行：プロフィールAPI実装完了）
+- **全AC実装後**: 全Step（リグレッション：認証UI変更の影響確認）
 
 ### テスト手順
 
@@ -73,12 +71,11 @@
 
 ### 関連
 - **受け入れ条件**: AC1.2, AC1.3, AC1.5, AC1.6
-- **関連タスク**: 1.1.2, 1.1.3, 2.1.1
 
 ### 実施タイミング
-- **タスク1.1.3完了後**: Step 1-4まで（部分実行：APIエラーハンドリング）
-- **タスク2.1.4完了後**: 全Step（フル実行：UIエラー表示含む）
-- **タスク2.1.8完了後**: 全Step（リグレッション：Phase 2完了確認）
+- **AC1.2〜AC1.6実装後**: Step 1-4まで（部分実行：APIエラーハンドリング）
+- **AC1.7〜AC1.9実装後**: 全Step（フル実行：UIエラー表示含む）
+- **全AC実装後**: 全Step（リグレッション：最終確認）
 
 ### テスト手順
 
@@ -103,12 +100,11 @@
 
 ### 関連
 - **受け入れ条件**: AC3.1, AC3.2, AC3.3, AC3.4, AC3.5, AC3.6
-- **関連タスク**: 3.1.1, 3.1.2, 3.1.3
 
 ### 実施タイミング
-- **タスク3.1.2完了後**: Step 1-3まで（部分実行：通知送信まで）
-- **タスク3.1.3完了後**: 全Step（フル実行：セッション無効化含む）
-- **タスク3.1.5完了後**: 全Step（リグレッション：Phase 3完了確認）
+- **AC3.1〜AC3.3実装後**: Step 1-3まで（部分実行：通知送信まで）
+- **AC3.4〜AC3.6実装後**: 全Step（フル実行：セッション無効化含む）
+- **全AC実装後**: 全Step（リグレッション：最終確認）
 
 ### テスト手順