create-ai-project 1.19.0 → 1.20.0

package/.claude/skills-en/documentation-criteria/references/task-template.md

@@ -13,8 +13,13 @@ Metadata:
 - [ ] [Implementation file path]
 - [ ] [Test file path]
 
+## Investigation Targets
+Files to read before starting implementation (file path, with optional search hint):
+- [e.g., src/orders/checkout (processOrder function) — determined by task-decomposer based on task nature]
+
 ## Implementation Steps (TDD: Red-Green-Refactor)
 ### 1. Red Phase
+- [ ] Read all Investigation Targets and record key observations
 - [ ] Review dependency deliverables (if any)
 - [ ] Verify/create contract definitions
 - [ ] Write failing tests

package/.claude/skills-en/integration-e2e-testing/SKILL.md

@@ -8,6 +8,7 @@ description: Designs integration and E2E tests with mock boundaries and behavior
 ## References
 
 - **[references/e2e-design.md](references/e2e-design.md)** - E2E test design principles with Playwright (candidate sources, selection criteria, UI Spec mapping)
+- **[references/e2e-environment-prerequisites.md](references/e2e-environment-prerequisites.md)** - E2E environment prerequisites (seed data, auth fixtures, environment checklist)
 
 ## Test Types and Limits
 
@@ -37,6 +38,8 @@ description: Designs integration and E2E tests with mock boundaries and behavior
 
 ### Required Comment Format
 
+Each test MUST include the following annotations.
+
 ```typescript
 // AC: "[Acceptance criteria original text]"
 // ROI: [0-100] | Business Value: [0-10] | Frequency: [0-10]
@@ -44,7 +47,7 @@ description: Designs integration and E2E tests with mock boundaries and behavior
 // @category: core-functionality | integration | edge-case | ux | e2e
 // @dependency: none | [component name] | full-system
 // @complexity: low | medium | high
-it.todo('[AC number]: [Test name]')
+// @real-dependency: [component name] (optional, when Test Boundaries specify non-mock setup)
 ```
 
 ### Property Annotations
@@ -52,7 +55,6 @@ it.todo('[AC number]: [Test name]')
 ```typescript
 // Property: `[Verification expression]`
 // fast-check: fc.property(fc.[arbitrary], (input) => [invariant])
-it.todo('[AC number]-property: [Invariant description]')
 ```
 
 ### ROI Calculation

package/.claude/skills-en/integration-e2e-testing/references/e2e-environment-prerequisites.md

@@ -0,0 +1,70 @@
+# E2E Environment Prerequisites
+
+E2E tests require a running application with real data state. Unlike unit/integration tests, environment setup is part of E2E test implementation scope.
+
+## Seed Data Strategy
+
+Prepare test data via API calls or database seeding — never through UI interaction:
+
+```typescript
+// fixtures/seed.fixture.ts
+import { test as base } from '@playwright/test'
+
+export const test = base.extend<{ seededData: SeedResult }>({
+  seededData: async ({ request }, use) => {
+    // Arrange: Create test data via API before test
+    // Example: adjust to the project's actual seeding mechanism
+    const result = await request.post('/api/test/seed', {
+      data: { scenario: 'e2e-user-with-subscription' }
+    })
+    const seedData = await result.json()
+
+    await use(seedData)
+
+    // Cleanup: Remove test data after test
+    await request.delete(`/api/test/seed/${seedData.id}`)
+  },
+})
+```
+
+**Principles**:
+- Use the application's existing seeding mechanism if present; create new seed endpoints only when no alternative exists
+- Seed data setup belongs to test fixtures, not to a separate manual step
+- Each test must be self-contained: create its own data, clean up after
+- Use API endpoints or direct DB access for seeding — not UI flows
+
+## Authentication Fixture
+
+Implement auth fixtures that match the application's actual login flow:
+
+```typescript
+// fixtures/auth.fixture.ts
+export const test = base.extend<{ playerPage: Page }>({
+  playerPage: async ({ page, request }, use) => {
+    // Use the application's existing auth endpoint — not admin backdoors
+    // Example: adjust the URL and payload to match the project's actual login flow
+    await request.post('/api/login', {
+      data: { loginId: E2E_LOGIN_ID, password: E2E_PASSWORD }
+    })
+    // Transfer session to browser context
+    await page.goto('/')
+    await use(page)
+  },
+})
+```
+
+**Principles**:
+- Use the application's existing authentication flow; auth fixtures must follow the same path that real users use
+- Store test credentials in environment variables, never hardcoded
+- If the auth flow requires specific user records, seed them in the fixture
+
+## Environment Checklist
+
+Before E2E tests can pass, verify:
+- [ ] Application is running and accessible at `baseURL`
+- [ ] Database has required seed data (test users, subscriptions, content)
+- [ ] Authentication flow works with test credentials
+- [ ] Environment variables are set (`E2E_*` prefixed)
+- [ ] External services are either available or mocked via `page.route()`
+
+When the work plan includes dedicated environment setup tasks (Phase 0), follow those tasks. When no setup tasks exist in the plan, address missing prerequisites as part of the E2E test implementation task itself.

package/.claude/skills-en/subagents-orchestration-guide/SKILL.md

@@ -56,13 +56,15 @@ graph TD
 
 ### Document Creation Agents
 6. **requirement-analyzer**: Requirement analysis and work scale determination (WebSearch enabled, latest technical information research)
-7. **prd-creator**: Product Requirements Document creation (WebSearch enabled, market trend research)
-8. **ui-spec-designer**: UI Specification creation from PRD and optional prototype code (frontend/fullstack features)
-9. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
-10. **work-planner**: Work plan creation from Design Doc and test skeletons
-11. **document-reviewer**: Single document quality, completeness, and rule compliance check
-12. **design-sync**: Design Doc consistency verification (detects explicit conflicts only)
-13. **acceptance-test-generator**: Generate separate integration and E2E test skeletons from Design Doc ACs and optional UI Spec
+7. **codebase-analyzer**: Analyze existing codebase to produce focused guidance for technical design
+8. **prd-creator**: Product Requirements Document creation (WebSearch enabled, market trend research)
+9. **ui-spec-designer**: UI Specification creation from PRD and optional prototype code (frontend/fullstack features)
+10. **technical-designer**: ADR/Design Doc creation (latest technology research, Property annotation assignment)
+11. **work-planner**: Work plan creation from Design Doc and test skeletons
+12. **document-reviewer**: Single document quality, completeness, and rule compliance check
+13. **code-verifier**: Verify Design Doc claims against existing codebase (used pre-review in design flow)
+14. **design-sync**: Design Doc consistency verification (detects explicit conflicts only)
+15. **acceptance-test-generator**: Generate separate integration and E2E test skeletons from Design Doc ACs and optional UI Spec
 
 ## My Orchestration Principles
 
@@ -108,8 +110,10 @@ I repeat this cycle for each task to ensure quality.
 
 Subagents respond in JSON format. Key fields for orchestrator decisions:
 - **requirement-analyzer**: scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions
-- **task-executor**: status (escalation_needed/blocked/completed), testsAdded, requiresTestReview
-- **quality-fixer**: approved (true/false)
+- **codebase-analyzer**: analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations
+- **code-verifier**: (in design flow) consistencyScore, discrepancies[], reverseCoverage (including dataOperationsInCode, testBoundariesSectionPresent)
+- **task-executor**: status (escalation_needed/completed), escalation_type (design_compliance_violation/similar_function_found/similar_component_found/investigation_target_not_found/out_of_scope_file), testsAdded, requiresTestReview
+- **quality-fixer**: status (approved/blocked). Discriminate blocked type by `reason` field: `"Cannot determine due to unclear specification"` → read `blockingIssues[]` for specification details; `"Execution prerequisites not met"` → read `missingPrerequisites[]` with `resolutionSteps` — present these to the user as actionable next steps
 - **document-reviewer**: approvalReady (true/false)
 - **design-sync**: sync_status (synced/conflicts_found)
 - **integration-test-reviewer**: status (approved/needs_revision/blocked), requiredFixes
@@ -121,7 +125,7 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 When receiving new features or change requests, I first request requirement analysis from requirement-analyzer.
 According to scale determination:
 
-### Large Scale (6+ Files) - 11 Steps (backend) / 13 Steps (frontend/fullstack)
+### Large Scale (6+ Files) - 13 Steps (backend) / 15 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis + Check existing PRD **[Stop]**
 2. prd-creator → PRD creation
@@ -130,24 +134,28 @@ According to scale determination:
 5. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
 6. technical-designer → ADR creation (if architecture/technology/data flow changes)
 7. document-reviewer → ADR review (if ADR created) **[Stop: ADR Approval]**
-8. technical-designer → Design Doc creation (cross-layer: per layer, see Cross-Layer Orchestration)
-9. document-reviewer → Design Doc review (cross-layer: per Design Doc)
-10. design-sync → Consistency verification **[Stop: Design Doc Approval]**
-11. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
-12. work-planner → Work plan creation **[Stop: Batch approval]**
-13. task-decomposer → Autonomous execution → Completion report
+8. codebase-analyzer → Codebase analysis (pass requirement-analyzer output + PRD path)
+9. technical-designer → Design Doc creation (pass codebase-analyzer output as additional context; cross-layer: per layer, see Cross-Layer Orchestration)
+10. code-verifier → Verify Design Doc against existing code (doc_type: design-doc)
+11. document-reviewer → Design Doc review (pass code-verifier results as code_verification; cross-layer: per Design Doc)
+12. design-sync → Consistency verification **[Stop: Design Doc Approval]**
+13. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
+14. work-planner → Work plan creation **[Stop: Batch approval]**
+15. task-decomposer → Autonomous execution → Completion report
 
-### Medium Scale (3-5 Files) - 7 Steps (backend) / 9 Steps (frontend/fullstack)
+### Medium Scale (3-5 Files) - 9 Steps (backend) / 11 Steps (frontend/fullstack)
 
 1. requirement-analyzer → Requirement analysis **[Stop]**
-2. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation
-3. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
-4. technical-designer → Design Doc creation (cross-layer: per layer, see Cross-Layer Orchestration)
-5. document-reviewer → Design Doc review (cross-layer: per Design Doc)
-6. design-sync → Consistency verification **[Stop: Design Doc Approval]**
-7. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
-8. work-planner → Work plan creation **[Stop: Batch approval]**
-9. task-decomposer → Autonomous execution → Completion report
+2. codebase-analyzer → Codebase analysis (pass requirement-analyzer output)
+3. **(frontend/fullstack only)** Ask user for prototype code → ui-spec-designer → UI Spec creation
+4. **(frontend/fullstack only)** document-reviewer → UI Spec review **[Stop: UI Spec Approval]**
+5. technical-designer → Design Doc creation (pass codebase-analyzer output as additional context; cross-layer: per layer, see Cross-Layer Orchestration)
+6. code-verifier → Verify Design Doc against existing code (doc_type: design-doc)
+7. document-reviewer → Design Doc review (pass code-verifier results as code_verification; cross-layer: per Design Doc)
+8. design-sync → Consistency verification **[Stop: Design Doc Approval]**
+9. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
+10. work-planner → Work plan creation **[Stop: Batch approval]**
+11. task-decomposer → Autonomous execution → Completion report
 
 ### Small Scale (1-2 Files) - 2 Steps
 
@@ -164,14 +172,18 @@ Replace the standard Design Doc creation step with per-layer creation:
 
 | Step | Agent | Purpose |
 |------|-------|---------|
-| 6a | technical-designer | Backend Design Doc |
-| 6b | technical-designer-frontend | Frontend Design Doc |
-| 7 | document-reviewer ×2 | Review each Design Doc separately |
-| 8 | design-sync | Cross-layer consistency verification **[Stop]** |
+| 8 | codebase-analyzer ×2 | Codebase analysis per layer (pass req-analyzer output, filtered to layer) |
+| 9a | technical-designer | Backend Design Doc (with backend codebase-analyzer context) |
+| 9b | technical-designer-frontend | Frontend Design Doc (with frontend codebase-analyzer context + backend Integration Points) |
+| 10 | code-verifier ×2 | Verify each Design Doc against existing code |
+| 11 | document-reviewer ×2 | Review each Design Doc (with code-verifier results as code_verification) |
+| 12 | design-sync | Cross-layer consistency verification **[Stop]** |
+
+Steps marked with ×2 invoke the agent once per layer. These invocations are independent and can run in parallel when the orchestrator supports concurrent Agent tool calls.
 
 **Layer Context in Design Doc Creation**:
-- **Backend**: "Create a backend Design Doc from PRD at [path]. Focus on: API contracts, data layer, business logic, service architecture."
-- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Reference backend Design Doc at [path] for API contracts and Integration Points. Focus on: component hierarchy, state management, UI interactions, data fetching."
+- **Backend**: "Create a backend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for backend layer]. Focus on: API contracts, data layer, business logic, service architecture."
+- **Frontend**: "Create a frontend Design Doc from PRD at [path]. Codebase analysis: [JSON from codebase-analyzer for frontend layer]. Reference backend Design Doc at [path] for API contracts and Integration Points. Focus on: component hierarchy, state management, UI interactions, data fetching."
 
 **design-sync**: Use frontend Design Doc as source. design-sync auto-discovers other Design Docs in `docs/design/` for comparison.
 
@@ -230,6 +242,16 @@ Every subagent prompt must include:
 
 Construct the prompt from the agent's Input Parameters section and the deliverables available at that point in the flow.
 
+### Call Example (codebase-analyzer)
+- subagent_type: "codebase-analyzer"
+- description: "Codebase analysis"
+- prompt: "requirement_analysis: [JSON from requirement-analyzer]. prd_path: [path if exists]. requirements: [original user requirements]. Analyze the existing codebase and produce design guidance."
+
+### Call Example (code-verifier — design flow)
+- subagent_type: "code-verifier"
+- description: "Design Doc verification"
+- prompt: "doc_type: design-doc document_path: [Design Doc path] Verify Design Doc against existing code."
+
 ## My Main Roles as Orchestrator
 
 1. **State Management**: Grasp current phase, each subagent's state, and next action
@@ -240,6 +262,16 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    - Compose commit messages from changeSummary -> **Execute git commit with Bash**
    - Explicitly integrate initial and additional requirements when requirements change
 
+   #### codebase-analyzer → technical-designer
+
+   **Pass to codebase-analyzer**: requirement-analyzer JSON output, PRD path (if exists), original user requirements
+   **Pass to technical-designer**: codebase-analyzer JSON output as additional context in the Design Doc creation prompt. The designer uses `focusAreas` and `dataModel` to inform the Existing Codebase Analysis section.
+
+   #### code-verifier → document-reviewer (Design Doc review)
+
+   **Pass to code-verifier**: Design Doc path (doc_type: design-doc). `code_paths` is intentionally omitted — the verifier independently discovers code scope from the document.
+   **Pass to document-reviewer**: code-verifier JSON output as `code_verification` parameter.
+
    #### *1 acceptance-test-generator → work-planner
 
    **Pass to acceptance-test-generator**:
@@ -255,7 +287,7 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
    - E2E test file: [path] (execute only in final phase)
 
    **On error**: Escalate to user if files are not generated
-3. **Quality Assurance and Commit Execution**: After confirming approved=true, immediately execute git commit
+3. **Quality Assurance and Commit Execution**: After confirming `status: "approved"`, immediately execute git commit
 4. **Autonomous Execution Mode Management**: Start/stop autonomous execution after approval, escalation decisions
 5. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
 

package/.claude/skills-en/task-analyzer/references/skills-index.yaml

@@ -69,6 +69,7 @@ skills:
       - "Test Implementation Conventions"
       - "Test Quality Criteria"
       - "Mock Type Safety Enforcement"
+      - "Data Layer Testing"
       - "Basic Vitest Example"
 
   technical-spec:
@@ -147,6 +148,7 @@ skills:
       - "Node.js Testing Best Practices - Yoni Goldberg"
       - "Property-Based Testing - 2025 Practices"
       - "references/e2e-design.md - E2E test design principles"
+      - "references/e2e-environment-prerequisites.md - E2E environment prerequisites"
     sections:
       - "References"
       - "Test Types and Limits"

package/.claude/skills-en/typescript-testing/SKILL.md

@@ -135,6 +135,45 @@ const sdkMock = {
 } as unknown as ExternalSDK // Complex external SDK type structure
 ```
 
+## Data Layer Testing
+
+### Mock Limitations for Data Layer
+
+Mocks validate call patterns but cannot verify data layer correctness. The following pass through undetected with mock-only testing:
+- Schema mismatches (table names, column names, data types)
+- Query correctness (joins, filters, aggregations, grouping)
+- Database constraints (NOT NULL, UNIQUE, foreign keys)
+- Migration drift (schema changes that make code out of sync)
+
+### When Mocks Are Appropriate for Data Access
+
+- Testing business logic that receives data from the data layer (mock the repository, test the service)
+- Testing error handling paths (simulating connection failures, timeouts)
+- Unit tests where data access is a dependency, not the subject under test
+
+### When Mocks Are Insufficient for Data Access
+
+- Testing repository or data access implementations themselves
+- Verifying query correctness (joins, filters, aggregations, grouping)
+- Testing data integrity constraints
+- Testing migration compatibility
+
+### Real Database Testing (Environment-Dependent)
+
+Options for verifying data layer correctness against a real database engine:
+- **Containerized databases** for CI environments
+- **In-memory databases** for fast feedback (note: dialect differences may mask issues)
+- **Dedicated test databases** with seed data
+
+The appropriate approach depends on project environment and CI/CD capabilities.
+
+### AI-Generated Code and Schema Awareness
+
+- AI-generated data access code has heightened schema hallucination risk
+- Generated queries may use correct syntax but reference nonexistent schema elements
+- Mock-based tests pass regardless of schema accuracy
+- Mitigation: Design Docs should include explicit schema references; code-verifier reverse coverage verifies data operations against documented schemas
+
 ## Basic Vitest Example
 
 ```typescript

package/.claude/skills-ja/documentation-criteria/references/design-template.md

@@ -266,6 +266,26 @@ unknowns:
 
 機能に関連する信頼境界がない場合は、簡潔な理由とともにN/Aと記載。
 
+## テスト境界
+
+### モック境界決定
+
+| コンポーネント/依存先 | モック化? | 根拠 |
+|---------------------|----------|------|
+| [外部API / DB / ファイルシステム 等] | [Yes/No] | [この境界を選択した理由] |
+
+### データ層テスト戦略
+
+- **スキーマ依存先**: [この機能が読み書きするテーブル/モデルの一覧と定義ファイルパス]
+- **テストデータ手法**: [テストデータの提供方法 — fixtures, factories, seed scripts, 実DB]
+- **モックの限界**: [この機能でモックだけでは信頼性のあるテストができない箇所]
+
+機能にデータ層の依存がない場合は、簡潔な理由とともにN/Aと記載。
+
+### 統合検証ポイント
+
+- [ユニットレベルのモックを超えるテストが必要な重要な統合ポイントの一覧]
+
 ## 代替案
 
 ### 代替案1

package/.claude/skills-ja/documentation-criteria/references/task-template.md

@@ -13,8 +13,13 @@
 - [ ] [実装ファイルパス]
 - [ ] [テストファイルパス]
 
+## 調査対象
+実装開始前に読むべきファイル（ファイルパス、任意でサーチヒント付き）:
+- [例: src/orders/checkout (processOrder関数) — タスクの性質に基づきtask-decomposerが決定]
+
 ## 実装ステップ（TDD: Red-Green-Refactor）
 ### 1. Redフェーズ
+- [ ] 全ての調査対象を読み、主要な所見を記録
 - [ ] 依存関係の成果物を確認（ある場合）
 - [ ] 契約定義を確認・作成
 - [ ] 失敗するテストを書く

package/.claude/skills-ja/integration-e2e-testing/SKILL.md

@@ -8,6 +8,7 @@ description: 統合テストとE2Eテストを設計。モック境界と振る
 ## References
 
 - **[references/e2e-design.md](references/e2e-design.md)** — E2Eテスト設計原則（候補ソース、選定基準、UI Specからのマッピング）
+- **[references/e2e-environment-prerequisites.md](references/e2e-environment-prerequisites.md)** — E2E環境前提条件（seed data、auth fixture、環境チェックリスト）
 
 ## テスト種別と上限
 
@@ -37,6 +38,8 @@ description: 統合テストとE2Eテストを設計。モック境界と振る
 
 ### 必須コメント形式
 
+各テストに以下のアノテーションを含めること。
+
 ```typescript
 // AC: "[受入条件原文]"
 // ROI: [0-100] | ビジネス価値: [0-10] | 頻度: [0-10]
@@ -44,6 +47,7 @@ description: 統合テストとE2Eテストを設計。モック境界と振る
 // @category: core-functionality | integration | edge-case | ux | e2e
 // @dependency: none | [コンポーネント名] | full-system
 // @complexity: low | medium | high
+// @real-dependency: [コンポーネント名]（任意、テスト境界で非モックセットアップが指定された場合）
 it.todo('[AC番号]: [テスト名]')
 ```
 

package/.claude/skills-ja/integration-e2e-testing/references/e2e-environment-prerequisites.md

@@ -0,0 +1,70 @@
+# E2E環境前提条件
+
+E2Eテストはリアルなデータ状態で動作するアプリケーションが必要です。ユニット/統合テストと異なり、環境セットアップはE2Eテスト実装スコープの一部です。
+
+## Seed Data Strategy
+
+テストデータはAPI callまたはdatabase seedingで準備する — UI操作によるデータ作成は行わない:
+
+```typescript
+// fixtures/seed.fixture.ts
+import { test as base } from '@playwright/test'
+
+export const test = base.extend<{ seededData: SeedResult }>({
+  seededData: async ({ request }, use) => {
+    // Arrange: テスト前にAPI経由でテストデータを作成
+    // 例: プロジェクトの実際のseeding機構に合わせて調整
+    const result = await request.post('/api/test/seed', {
+      data: { scenario: 'e2e-user-with-subscription' }
+    })
+    const seedData = await result.json()
+
+    await use(seedData)
+
+    // Cleanup: テスト後にテストデータを削除
+    await request.delete(`/api/test/seed/${seedData.id}`)
+  },
+})
+```
+
+**原則**:
+- アプリケーションに既存のseeding機構がある場合はそれを使用する。代替手段がない場合のみ新規seedエンドポイントを作成
+- seed dataのセットアップはtest fixturesに属する。手動ステップとして分離しない
+- 各テストは自己完結: 自身のデータを作成し、テスト後にクリーンアップ
+- seedingにはAPIエンドポイントまたは直接DB操作を使用 — UIフローは使わない
+
+## Authentication Fixture
+
+アプリケーションの実際のログインフローに合わせたauth fixtureを実装:
+
+```typescript
+// fixtures/auth.fixture.ts
+export const test = base.extend<{ playerPage: Page }>({
+  playerPage: async ({ page, request }, use) => {
+    // アプリケーションの既存認証エンドポイントを使用 — admin backdoorは使わない
+    // 例: プロジェクトの実際のログインフローに合わせてURL・payloadを調整
+    await request.post('/api/login', {
+      data: { loginId: E2E_LOGIN_ID, password: E2E_PASSWORD }
+    })
+    // セッションをブラウザコンテキストに移行
+    await page.goto('/')
+    await use(page)
+  },
+})
+```
+
+**原則**:
+- アプリケーションの既存認証フローを使用する。auth fixtureは実ユーザーと同じ経路を通ること
+- テスト認証情報は環境変数に格納し、ハードコードしない
+- 認証フローに特定のユーザーレコードが必要な場合はfixture内でseedする
+
+## 環境チェックリスト
+
+E2Eテストがパスするために、以下を確認:
+- [ ] アプリケーションが`baseURL`で起動・アクセス可能
+- [ ] データベースに必要なseed dataがある（テストユーザー、サブスクリプション、コンテンツ）
+- [ ] テスト認証情報で認証フローが動作する
+- [ ] 環境変数が設定されている（`E2E_*`プレフィックス）
+- [ ] 外部サービスが利用可能、または`page.route()`でモック済み
+
+作業計画に専用の環境セットアップタスク（Phase 0）が含まれる場合はそれに従う。計画にセットアップタスクがない場合は、E2Eテスト実装タスクの一部として不足する前提条件に対応する。