create-ai-project 1.20.9 → 1.22.0

package/.claude/skills-en/project-context/references/external-resources-infra.md

@@ -0,0 +1,76 @@
+# Infrastructure External Resource Axes
+
+Hearing axes for deployment, environment configuration, or infrastructure-as-code work. `/project-inject` loads this file when the user selects the Infrastructure domain.
+
+## Axis 1: IaC Source
+
+The canonical source of infrastructure definitions.
+
+**AskUserQuestion choices**:
+- Terraform configuration in the repository
+- Pulumi or CDK code in the repository
+- Kubernetes manifests / Helm charts in the repository
+- Cloud-provider-native templates (e.g., CloudFormation, Bicep, Deployment Manager)
+- Manual console configuration (no IaC)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: directory path.
+- **Access method**: CI pipeline name when plan/apply runs automatically, or CLI command when an operator runs it manually.
+
+## Axis 2: Environment Configuration
+
+How per-environment settings (development, staging, production) differ.
+
+**AskUserQuestion choices**:
+- Per-environment configuration files in the repository (e.g., `terraform/envs/`, `config/staging.yaml`)
+- Environment variables managed by the deployment platform
+- Workspace or stack abstraction in the IaC tool itself
+- Single shared configuration (no per-environment differences)
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: configuration file paths, platform setting names, or workspace identifiers where environment-specific values are stored.
+- **Access method**: file read, platform console URL, or CLI command.
+
+When multiple environments are tracked separately (development, staging, production), capture each as a separate entry per the multiple-instance rule in `template.md`, using the environment name as the disambiguating suffix.
+
+## Axis 3: Secrets in Infrastructure
+
+How infrastructure code references secrets while keeping their values out of source control.
+
+**AskUserQuestion choices**:
+- Secrets sourced from a secret manager via IaC data lookup
+- Secrets injected at apply time via environment variables
+- Encrypted secret files committed alongside IaC
+- No secrets in infrastructure
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: secret manager service name or IaC data source identifier.
+- **Access method**: data lookup syntax, environment variable name, or apply-time injection mechanism.
+
+When the same secret store appears in the Backend domain, render this axis as a cross-axis reference back to that location (notation defined in `template.md`).
+
+## Axis 4: Deployment Trigger
+
+How infrastructure and application changes reach environments.
+
+**AskUserQuestion choices**:
+- CI pipeline triggered on merge to a specific branch
+- Manual approval step in CI
+- Local apply by an operator
+- Deployment platform's auto-deploy on push
+- Not applicable
+
+**Follow-up (when the axis is present)**: Capture two fields:
+- **Location**: CI pipeline name or deployment platform identifier.
+- **Access method**: branch / tag convention that triggers each environment, plus any required manual approval step.
+
+## Self-Declaration Phase
+
+After the four structured axes, ask once: "Are there any other infrastructure external resources this project depends on beyond what the structured questions covered? List each in your next message, or reply 'none'."
+
+Capture free-form answers under the "Additional Resources" subsection of the Infrastructure block. Run this phase even when every structured axis returned "Not applicable".
+
+Examples of resources that surface only via self-declaration: state-storage backend for IaC tools, runbook documents for incident response, on-call rotation, observability dashboards, cost monitoring tools, compliance / audit logging targets.

package/.claude/skills-en/project-context/references/template.md

@@ -0,0 +1,154 @@
+# Project Context Section Catalog
+
+This file is the section catalog used by `/project-inject`. Consumer agents load `SKILL.md` only; this file is loaded only during update operations.
+
+## Section Index
+
+| Section | Inclusion Rule | Source of Hearing Questions |
+|---------|----------------|-----------------------------|
+| Project Overview | Always include | This file (below) |
+| Domain Constraints | Include when at least one rule changes AI decisions | This file (below) |
+| Development Phase | Include when phase materially changes AI behavior (e.g., suppresses test scaffolding for prototype) | This file (below) |
+| Directory Conventions | Include when non-obvious file placement rules exist | This file (below) |
+| External Resources | Include when the project depends on resources outside the repository (design source, schema source, secret store, IaC source, etc.) | `external-resources-{frontend,backend,api,infra}.md` (load only the domains relevant to the project) |
+
+## Section Definitions
+
+### Project Overview
+
+**Inclusion**: Always.
+
+**Hearing**:
+- AskUserQuestion 1: "What does this project do? (1–2 sentences)"
+- AskUserQuestion 2: "What domain does it belong to?" with concrete option examples drawn from common categories (e.g., developer tooling, fintech, healthcare, e-commerce, internal platform). Always include "Other".
+
+**Output structure**:
+```markdown
+## Project Overview
+- **What this project does**: <one to two sentences>
+- **Domain**: <domain>
+```
+
+### Domain Constraints
+
+**Inclusion**: Include when at least one constraint, if ignored, would cause a bug or compliance failure.
+
+**Hearing**:
+- AskUserQuestion: "Are there domain-specific rules that AI must follow when making decisions in this project?" Options: "Yes, I will list them" / "No, no domain constraints apply".
+- When "Yes": for each rule (cap at 3), capture the rule statement plus a measurable check. Accept statements only when they evaluate as pass/fail; reframe subjective phrasings into measurable form (e.g., turn "be careful with PII" into "log output uses anonymized patient IDs").
+- Adapt example phrasings to the domain captured in Project Overview (e.g., for fintech: "every monetary mutation appends an audit log entry"; for developer tooling: "generated code keeps lockfile commands invocable").
+
+**Output structure** (omit the section entirely when zero constraints):
+```markdown
+## Domain Constraints
+1. <measurable rule 1>
+2. <measurable rule 2>
+3. <measurable rule 3>
+```
+
+### Development Phase
+
+**Inclusion**: Include when phase materially changes AI behavior. Skip when behavior is identical across phases.
+
+**Hearing**:
+- AskUserQuestion: "Which phase is this project in?" Options: "Prototype", "Production", "In operation", "No meaningful difference between phases".
+- When "No meaningful difference": omit the section.
+
+**Output structure**:
+```markdown
+## Development Phase
+- **Phase**: <Prototype | Production | In operation>
+```
+
+### Directory Conventions
+
+**Inclusion**: Include when at least one file placement rule is non-obvious from the repository structure (i.e., a contributor reading the tree would guess wrong).
+
+**Hearing**:
+- AskUserQuestion: "Are there file placement rules that AI should follow?" Options: "Yes" / "No".
+- When "Yes": capture each rule as a single line stating the trigger and the destination (e.g., "Temporary working files: place under `./tmp/` and remove on completion").
+
+**Output structure** (omit the section entirely when zero rules):
+```markdown
+## Directory Conventions
+- <rule 1>
+- <rule 2>
+```
+
+### External Resources
+
+**Inclusion**: Include the section when at least one selected domain has a present axis OR a non-empty self-declaration. Otherwise omit the section.
+
+**Hearing routing**:
+- AskUserQuestion: "Which external-resource domains apply to this project?" Multi-select options:
+  - Frontend (design source, design system, guidelines, visual verification environment)
+  - Backend (database schema, migration history, secret store, background jobs)
+  - API contract (schema source, mocks, authentication, schema change process)
+  - Infrastructure (IaC source, environment configuration, infrastructure secrets, deployment trigger)
+  - None apply
+- For each selected domain, load the matching reference file using the slug map below and run its hearing protocol.
+
+**Domain to file slug mapping**:
+| Domain (user-facing label) | Reference file |
+|---------------------------|----------------|
+| Frontend | `external-resources-frontend.md` |
+| Backend | `external-resources-backend.md` |
+| API contract | `external-resources-api.md` |
+| Infrastructure | `external-resources-infra.md` |
+
+**Hearing protocol** (per domain reference): each reference defines structured axes plus a self-declaration phase. The structured phase asks one AskUserQuestion per axis, offering "Not applicable" as one explicit choice. The self-declaration phase always runs once, asking for free-form additions, regardless of how the structured choices landed.
+
+**Per-axis output schema** (3 fields):
+```markdown
+#### <Axis name>
+- Source type: <verbatim text of the AskUserQuestion choice the user selected>
+- Location: <URL | file path | service or package name>
+- Access method: <WebFetch | file read | MCP server name | CLI command | manual procedure>
+```
+
+**Axis output rules**:
+
+1. **Axis output is conditional on whether the schema can be filled.** Render the axis block when the user's choice points to an external resource with identifiable **Location** and **Access method** values. The following choices produce zero output lines for that axis:
+   - Listed absence-declaring choices: "Not applicable", "No <resource>", "No <resource> required", "No documented <resource>", "Ad-hoc <resource>", "Manual <process> (no <resource>)".
+   - Any other choice whose Location and Access method values resolve to blank.
+
+2. **Multiple instances within one axis** (e.g., primary and analytics databases, separate guideline files for CSS and accessibility) — repeat the axis block with a disambiguating suffix:
+   ```markdown
+   #### Database Schema Source — Primary
+   - Source type: Schema file in the repository
+   - Location: prisma/schema.prisma
+   - Access method: file read
+
+   #### Database Schema Source — Analytics
+   - Source type: Database MCP server that introspects a live database
+   - Location: bigquery-prod
+   - Access method: MCP server `bigquery`
+   ```
+
+3. **Cross-axis reference** (e.g., the same secret store appears under both Backend and Infrastructure) — the first occurrence carries the canonical fields; the second occurrence renders as a reference back to it:
+   ```markdown
+   #### Secrets in Infrastructure
+   - Source type: Secrets sourced from a secret manager via IaC data lookup
+   - Reference: same store as Backend > Secret Store
+   - Access method: <inherited; record only differences if any>
+   ```
+
+**Domain block layout**:
+```markdown
+### <Domain>
+
+<axis blocks in catalog order, each rendered per the rules above>
+
+#### Additional Resources
+
+<rendered only when self-declaration captured items; placed after the last present axis within the same domain>
+- <free-form description from user>
+```
+
+## Output Assembly Rules
+
+After hearing completes, the calling command (`/project-inject`) assembles the configured `SKILL.md` per the order it specifies. This file owns the per-section content shape (above) and these cross-section rules:
+
+1. Sections marked for omission produce zero output lines. The rebuilt body advances directly to the next included section.
+2. Domain blocks within External Resources appear in catalog order (Frontend → Backend → API contract → Infrastructure), regardless of the order in which the user selected them during hearing.
+3. The Vagueness rejection rule (defined in `/project-inject` Step 3) is a hearing-time filter applied to every `add` and `update` section. The captured rules that pass the filter are written through normal section output; the filter contributes zero output lines of its own.

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

@@ -126,6 +126,27 @@ I repeat this cycle for each task to ensure quality.
 
 ## Structured Response Specifications
 
+All subagent invocation uses the **Agent tool** with:
+- `subagent_type`: Agent name (e.g., "task-executor")
+- `description`: Concise task description (3-5 words)
+- `prompt`: Specific instructions including deliverable paths
+
+### Orchestrator's Permitted Tools
+
+The orchestrator coordinates work using only the following tools:
+
+| Tool | Purpose |
+|------|---------|
+| Agent | Invoke subagents |
+| AskUserQuestion | User confirmations and questions |
+| TaskCreate / TaskUpdate | Progress tracking |
+| Bash | Shell operations (git commit, ls, verification commands) |
+| Read | Deliverable documents for information bridging between subagents |
+
+All implementation work (Edit, Write, MultiEdit) is performed by subagents, not the orchestrator.
+
+### Subagent Response Format
+
 Subagents respond in JSON format. Key fields for orchestrator decisions:
 
 | Agent | Key Fields | Decision Logic |
@@ -138,8 +159,8 @@ Subagents respond in JSON format. Key fields for orchestrator decisions:
 | document-reviewer | approvalReady (true/false) | Proceed to next step on true; request fixes on false |
 | design-sync | sync_status (NO_CONFLICTS/CONFLICTS_FOUND) | On CONFLICTS_FOUND: present conflicts to user before proceeding |
 | integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | On needs_revision: re-invoke the routed executor in Fix Mode with the same task_file and requiredFixes[] |
-| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | On needs_revision: create a consolidated fix task file with affected files in Target Files, then invoke executor in Fix Mode with that task_file and requiredFixes[] (see build/implement recipes) |
-| acceptance-test-generator | status, generatedFiles (integration: path\|null, e2e: path\|null), budgetUsage, e2eAbsenceReason (null when E2E emitted, otherwise: no_multi_step_journey\|below_threshold_user_confirmed) | Verify files exist, pass to work-planner with absence reason |
+| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | On needs_revision: create a consolidated fix task file with the affected file paths from `requiredFixes[].location` populated into Target Files, then invoke the routed executor in Fix Mode with that task_file and the `requiredFixes[]` array, then quality-fixer, then re-invoke security-reviewer to verify resolution. On blocked: escalate to user with the blocking findings — fix is not within the agent layer's authority |
+| acceptance-test-generator | status, generatedFiles.{integration,fixtureE2e,serviceE2e} (path\|null per lane), budgetUsage per lane, e2eAbsenceReason per E2E lane (null when emitted; reason enum is owned by acceptance-test-generator and integration-e2e-testing skill) | Verify each non-null file path exists, pass per-lane paths and absence reasons to work-planner |
 
 ### quality-fixer Blocked Handling
 
@@ -191,6 +212,15 @@ According to scale determination:
 
 Note: At Small scale the implementation step still runs through task-executor with the standard 4-step cycle (`task-executor → escalation judgment → quality-fixer → commit`). Direct orchestrator edits are not used.
 
+### Implementation Readiness Marker
+
+For Medium / Large scale, after Batch approval the work plan carries an `Implementation Readiness:` header (work-planner emits `pending`; promotion to `ready` or `escalated` is an external orchestration concern). The marker takes one of three values:
+- `pending` — initial state set by work-planner
+- `ready` — readiness verification has completed with no remaining gaps; safe to start the task execution cycle
+- `escalated` — readiness verification has completed but residual gaps require user judgment before execution
+
+External orchestration owns both the producer that promotes the marker beyond `pending` and the consumer that reads it before invoking task-executor. This guide does not invoke any orchestrator above the agent layer; agents read/write the marker only when explicitly asked.
+
 ## Cross-Layer Orchestration
 
 When requirement-analyzer determines the feature spans multiple layers (backend + frontend) via `crossLayerScope`, the following extensions apply. Step numbers below follow the large-scale flow. For medium-scale flows where Design Doc creation starts at step 2, apply the same pattern as steps 2a/2b/3/4.
@@ -325,21 +355,13 @@ Two additional rules:
 
    #### *1 acceptance-test-generator → work-planner
 
-   **Pass to acceptance-test-generator**:
-   - Design Doc: [path]
-   - UI Spec: [path] (if exists)
+   **Pass to acceptance-test-generator**: Design Doc path; UI Spec path (if exists).
 
-   **Orchestrator verification items**:
-   - Verify `generatedFiles.integration` is a valid path (when not null) and the file exists
-   - Verify `generatedFiles.e2e` is a valid path (when not null) and the file exists
-   - When `generatedFiles.e2e` is null, verify `e2eAbsenceReason` is present — this is intentional absence, not an error
+   **Orchestrator verification**: Every non-null `generatedFiles.<lane>` path exists on disk. For each null lane, `e2eAbsenceReason.<lane>` is present — this is intentional absence, not an error.
 
-   **Pass to work-planner**:
-   - Integration test file: [path] (create and execute simultaneously with each phase implementation)
-   - E2E test file: [path] or null (execute only in final phase, when provided)
-   - E2E absence reason: [reason] (when E2E is null — pass this so work-planner can skip E2E Gap Check for intentional absence)
+   **Pass to work-planner**: integration / fixture-e2e / service-integration-e2e file paths (or null per lane), per-lane absence reasons, plus timing guidance — integration tests are created alongside each phase implementation, fixture-e2e tests are created alongside the UI feature phase, service-integration-e2e tests are executed only in the final phase.
 
-   **On error**: Escalate to user if integration file generation failed unexpectedly (status != completed). E2E being null with a valid absence reason is not an error.
+   **On error**: Escalate to user when status != completed and integration file generation failed unexpectedly. A null E2E lane with a valid absence reason is not an error.
 3. **ADR Status Management**: Update ADR status after user decision (Accepted/Rejected)
 
 ## Important Constraints

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

@@ -95,11 +95,6 @@ skills:
     size: small
     key-references:
       - "Project-specific (empirical)"
-    sections:
-      - "Project Overview"
-      - "Domain Constraints"
-      - "Development Phase"
-      - "Directory Conventions"
 
   documentation-criteria:
     skill: "documentation-criteria"

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

@@ -4,6 +4,8 @@
 種別: feature|fix|refactor
 想定影響範囲: Xファイル
 関連Issue/PR: #XXX（該当する場合）
+<!-- 下記の行はmedium / large規模のみ — small規模はこのplan-templateではなくtask-templateを使用する。値の行は末尾コメントを付けず、下流のパーサがbare statusの抽出（pending | ready | escalated）を行えるように保つこと。 -->
+Implementation Readiness: pending
 
 ## 関連ドキュメント
 - 設計書:
@@ -46,6 +48,26 @@ Design Docの各技術要件をカバーするタスクへのマッピング。
 
 **ギャップステータス値**: `covered`（タスクあり）、`gap`（タスクなし — 備考に理由必須、計画承認前にユーザー確認が必要）
 
+## UI Specコンポーネント → タスクマッピング
+
+入力にUI Specが含まれる場合のみ本セクションを記載する。UI Specに記述された各コンポーネントを実装するタスクへのマッピング。task-decomposerはこの表を読み込み、対応するUI Specセクションを各タスクのInvestigation Targetsに伝播させる。UI Specがない場合は本セクションを省略する。
+
+| UI Specコンポーネント（セクション見出し） | カバーする状態 | カバーするタスク | ギャップステータス | 備考 |
+|---|---|---|---|---|
+| [UI Specの見出しを完全一致で記載。例: "§ コンポーネント: AlertCard"] | [default / loading / empty / error / partial — 実装が満たすべき状態を列挙] | [Phase X タスクY] | covered | |
+
+**参照キーのルール**: 列1のコンポーネント識別子はUI Specのセクション見出し（完全一致）。ui-spec-designerが見出しの一意性を保証するため、この参照は1つのセクションに一意に解決する。
+
+**ギャップステータス値**: `covered`（タスクあり）、`gap`（タスクなし — 備考に理由必須、計画承認前にユーザー確認が必要）
+
+## Connection Map
+
+実装が複数のパッケージ、サービス、またはプロセス境界をまたがる場合のみ本セクションを記載する。各境界を文書化することで、task-decomposerは境界の文脈を両側の実装タスクに伝播できる。実装が単一パッケージ内に収まる場合は本セクションを省略する。
+
+| 境界 | オーナー（左側） | オーナー（右側） | 期待されるシグナル | カバーするタスク |
+|---|---|---|---|---|
+| [例: "web client → API gateway"] | [リクエスト側のモジュール/パッケージ] | [レスポンス側のモジュール/パッケージ] | [境界の動作を裏付ける観測可能な証拠 — 例: "ContractAに一致するスキーマでHTTP 200"、"tableBに行が挿入される"、"topicCにメッセージが発行される"] | [Phase X 各側のタスクY] |
+
 ## 目的
 [なぜこの変更が必要か、何を解決するか]
 

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

@@ -59,6 +59,8 @@ PRDの受入条件をプロトタイプの参照先にマッピング。プロ
 
 ### コンポーネント: [ComponentName]
 
+> コンポーネント見出しの一意性: すべての`コンポーネント: [ComponentName]`見出しはUI Spec内で一意でなければならない。work-plannerとtask-decomposerは見出しテキストの完全一致でコンポーネントを参照するため、重複した名前や言い換えがあると実装タスクへの伝播が破綻する。
+
 #### 状態×表示マトリクス
 
 | 状態 | デフォルト | ローディング | Empty | エラー | 部分表示 |

package/.claude/skills-ja/frontend-typescript-testing/references/e2e.md

@@ -1,5 +1,16 @@
 # PlaywrightによるE2Eテスト実装
 
+## レーン選択
+
+本ワークフローのE2Eテストは2つのレーンに分割される（integration-e2e-testingスキル参照）:
+
+| レーン | バックエンド構成 | 使用するパターン |
+|------|---------------|----------------|
+| **fixture-e2e** | `page.route()` またはフィクスチャローダーでモック化、ライブサービスなし | ページオブジェクトパターン、Locator戦略、アサーション、後述の **フィクスチャベースのバックエンド** セクション |
+| **service-integration-e2e** | 実サービスを伴うローカルスタックでライブ実行 | 上記の全パターンに加えて、アプリケーションのログインフローに対する実認証Fixture と seed済みのテストデータ |
+
+スケルトンの `@lane:` アノテーションがテストの所属レーンを宣言する。これに合わせて実装パターンを選択する。
+
 ## テストフレームワーク
 - **Playwright Test**: `@playwright/test`
 - テストインポート: `import { test, expect } from '@playwright/test'`
@@ -10,18 +21,23 @@
 ```
 tests/
 └── e2e/
-    ├── pages/              # ページオブジェクト
+    ├── pages/                       # ページオブジェクト（レーン間で共通）
     │   ├── login.page.ts
     │   └── dashboard.page.ts
-    ├── fixtures/           # テストFixture
+    ├── fixtures/                    # テストFixture（auth、seed）
     │   └── auth.fixture.ts
-    └── *.e2e.test.ts       # テストファイル
+    ├── data/                        # fixture-e2e用の静的フィクスチャデータ
+    │   └── *.fixture.json
+    ├── *.fixture-e2e.test.ts        # fixture-e2eテストファイル
+    └── *.service-e2e.test.ts        # service-integration-e2eテストファイル
 ```
 
 ### 命名規則
-- テストファイル: `{FeatureName}.e2e.test.ts`
+- fixture-e2eファイル: `{FeatureName}.fixture-e2e.test.ts`
+- service-integration-e2eファイル: `{FeatureName}.service-e2e.test.ts`
 - ページオブジェクト: `{PageName}.page.ts`
 - Fixture: `{Purpose}.fixture.ts`
+- 静的フィクスチャデータ: `{scenario}.fixture.json`
 
 ## ページオブジェクトパターン
 
@@ -102,6 +118,59 @@ export const test = base.extend<{ authenticatedPage: Page }>({
 })
 ```
 
+## フィクスチャベースのバックエンド（fixture-e2e）
+
+fixture-e2eテストは決定論的フィクスチャに対して実ブラウザを動かす — ライブバックエンドなし、DBなし、外部サービスなし。ネットワークをフェイクするには以下のパターンのいずれかを使用する:
+
+### パターンA: page.route() による傍受
+
+```typescript
+import { test, expect } from '@playwright/test'
+import cardsFixture from './data/cards.fixture.json'
+
+test('Dismissしてからのundoでカードが復元される', async ({ page }) => {
+  // Arrange: 全てのバックエンド呼び出しを決定論的レスポンスで傍受
+  await page.route('**/api/cards', async (route) => {
+    await route.fulfill({ json: cardsFixture })
+  })
+  await page.route('**/api/cards/*/dismiss', async (route) => {
+    await route.fulfill({ status: 204 })
+  })
+
+  await page.goto('/cards')
+  await page.getByRole('button', { name: 'Dismiss' }).first().click()
+  await page.getByRole('button', { name: 'Undo' }).click()
+
+  await expect(page.getByText(cardsFixture[0].title)).toBeVisible()
+})
+```
+
+### パターンB: フィクスチャローダーの注入
+
+```typescript
+// data/cards-with-dismiss.fixture.json — テストと一緒にコミット
+// ルートヘルパーまたはアプリレベルのテストモード経由でロード
+```
+
+**fixture-e2e の原則**:
+- バックエンドはフェイクされ、稼働していない。これらのテストの実行に `npm run start:backend` は不要
+- フィクスチャはリポジトリ内（`tests/e2e/data/`）にバージョン管理される。マシンを越えて決定論的なテストになる
+- 認証が必要な場合もフェイクする（`page.context().addCookies()` でテストCookieをセット、またはfixtureモードのバイパスを使用）
+- 外部インフラのプロビジョニングなしにCIで実行可能
+
+## E2E環境前提条件（service-integration-e2e のみ）
+
+service-integration-e2eテストは実データ状態を持つ起動済みアプリケーションを必要とする。fixture-e2eと異なり、環境セットアップはテスト実装スコープの一部である。
+
+service-integration-e2eテストがパスする前に確認すべき項目:
+- [ ] アプリケーションが起動しており`baseURL`でアクセス可能
+- [ ] データベースに必要な seed data がある（テストユーザー、必要なレコード）
+- [ ] テストクレデンシャルで実認証フローが動作する
+- [ ] 環境変数が設定されている（`E2E_*` プレフィックス）
+- [ ] 外部サービスが利用可能、またはスタブされている
+
+作業計画書に環境セットアップ用の専用タスク（Phase 0）が含まれる場合、それに従う。計画にセットアップタスクがない場合、テスト実装タスク自体の中で不足する前提条件に対処するか、検証を fixture-e2e に移せないか検討する。
+
 ## Locator戦略
 
 アクセシブルなLocatorを以下の優先順位で使用:
@@ -168,13 +237,14 @@ test.describe('レスポンシブナビゲーション', () => {
 
 ## スケルトンコメント形式
 
-E2Eテストスケルトンは統合テストと同じアノテーション形式に従う:
+E2Eテストスケルトンは統合テストと同じアノテーション形式に従う。レーンを宣言する `@lane:` アノテーションを必ず付与する（上記「レーン選択」参照）:
 
 ```typescript
 // AC: [元の受入条件テキスト]
 // Behavior: [ユーザーアクション] → [システムレスポンス] → [観測可能な結果]
-// @category: e2e
-// @dependency: full-system
+// @category: fixture-e2e | service-integration-e2e
+// @lane: fixture-e2e | service-integration-e2e
+// @dependency: full-ui (mocked backend) | full-system
 // @complexity: high
 // ROI: [スコア]
 test('AC1: [説明]', async ({ page }) => {
@@ -183,3 +253,7 @@ test('AC1: [説明]', async ({ page }) => {
   // Assert: [検証の説明]
 })
 ```
+
+**レーン別の `@dependency` 選択**:
+- `fixture-e2e` → `@dependency: full-ui (mocked backend)`（ライブサービスなし、`page.route()` またはフィクスチャローダーでネットワークを傍受）
+- `service-integration-e2e` → `@dependency: full-system`（起動済みのローカルスタックが必要）

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

@@ -12,10 +12,17 @@ description: 統合テストとE2Eテストを設計。モック境界と振る
 
 ## テスト種別と上限
 
-| 種別 | 目的 | ファイル形式 | 上限 |
-|------|------|-------------|------|
-| 統合テスト | コンポーネント間連携検証 | `*.int.test.ts` | 機能あたり3件 |
-| E2Eテスト | クリティカルユーザージャーニー検証 | `*.e2e.test.ts` | 機能あたり1-2件 |
+| テスト種別 | 目的 | スコープ | 外部依存 | ファイル形式 | 機能あたり上限 | 実装タイミング |
+|-----------|------|---------|---------|-------------|--------------|--------------|
+| 統合 | in-processでのコンポーネント間連携を検証 | システムの部分的な統合（in-processモジュール、UIコンポーネントの場合はReact/TSではRTL+MSW） | モック または in-process | `*.int.test.ts` | 最大3件 | 実装と並行して作成 |
+| fixture-e2e | 決定論的フィクスチャを用いてブラウザ上でUIの振る舞いを検証 | UIフロー全体（モックバックエンド/フィクスチャ駆動の状態） | モック/フィクスチャのみ — ライブサービスなし | `*.fixture-e2e.test.ts` | 最大3件 | UI機能と並行して作成 |
+| service-integration-e2e | 起動済みのローカルスタックに対してクリティカルユーザージャーニーを検証 | サービスをまたいだシステム全体 | ローカルの実サービスまたはスタブ | `*.service-e2e.test.ts` | 最大1-2件 | 最終フェーズでのみ実行 |
+
+**レーン選択（E2Eのみ）**:
+- ユーザー向けUIジャーニーのデフォルトレーンは **fixture-e2e** — 決定論的フィクスチャに対して実ブラウザを動かし、ユニット/統合テストでは捕捉できないバグ（ボタンが動作しない、状態が更新されない、ナビゲーションが壊れる等）を検出でき、インフラ準備なしにCIで実行可能
+- **service-integration-e2e** は、ジャーニーの正しさが安全にフェイクできない実サービス間の挙動（データ永続化、トランザクション整合性、外部サービスのコントラクト）に依存する場合のみ追加
+
+2つのE2Eレーンの予算は独立して計上される — あるジャーニーに fixture-e2e があっても service-integration-e2e の予算は消費されず、その逆も同様。
 
 **クリティカルユーザージャーニー**: 収益影響・法的要件・大多数のユーザーが日常的に利用する機能
 
@@ -44,13 +51,19 @@ description: 統合テストとE2Eテストを設計。モック境界と振る
 // AC: "[受入条件原文]"
 // ROI: [0-100] | ビジネス価値: [0-10] | 頻度: [0-10]
 // 振る舞い: [トリガー] → [処理] → [観測可能な結果]
-// @category: core-functionality | integration | edge-case | ux | e2e
-// @dependency: none | [コンポーネント名] | full-system
+// @category: core-functionality | integration | edge-case | ux | fixture-e2e | service-integration-e2e
+// @lane: integration | fixture-e2e | service-integration-e2e
+// @dependency: none | [コンポーネント名] | full-ui (mocked backend) | full-system
 // @complexity: low | medium | high
 // @real-dependency: [コンポーネント名]（任意、テスト境界で非モックセットアップが指定された場合）
 it.todo('[AC番号]: [テスト名]')
 ```
 
+**`@lane` 選択ルール**:
+- `integration` — in-processでのコンポーネント間連携、ブラウザを使用しない（例: React/TSではRTL+MSW、その他言語でも in-process のモジュール/ハンドラ統合）
+- `fixture-e2e` — モックバックエンド/フィクスチャ駆動の状態に対するブラウザレベルのUI検証。`@dependency` は通常 `full-ui (mocked backend)`
+- `service-integration-e2e` — 起動済みローカルサービスまたはスタブに対するブラウザレベルまたはエンドツーエンドの検証。`@dependency` は `full-system`
+
 ### Property注釈
 
 ```typescript
@@ -73,17 +86,14 @@ it.todo('[AC番号]-property: [不変条件記述]')
 
 ### ユーザー向け vs サービス内部の分類
 
-マルチステップジャーニーはE2E予算判断のためにさらに分類される:
+マルチステップジャーニーは予約スロット適用判定のために分類される:
 
-| 分類 | 条件 | E2E予約スロット | 例 |
+| 分類 | 条件 | 予約スロット適用 | 例 |
 |------|------|----------------|-----|
-| **ユーザー向け** | 人間のユーザーが直接ステップをトリガーし結果を観察する（UI、CLI、または直接的なAPIインタラクション経由） | 対象 | Web購入フロー、CLIセットアップウィザード、モバイルオンボーディング |
-| **サービス内部** | バックエンドサービスがユーザーの直接操作なしにステップをトリガーする | 予約スロット対象外 | 非同期ジョブパイプライン、サービス間saga、スケジュールバッチ処理 |
+| **ユーザー向け** | 人間のユーザーが直接ステップをトリガーし結果を観察する（UI、CLI、または直接的なAPIインタラクション経由） | 対象 — デフォルトで **fixture-e2e** の予約スロットに割り当て。ジャーニーの正しさが実サービス間の挙動に依存する場合のみ service-integration-e2e の予約スロットを追加 | Web購入フロー、CLIセットアップウィザード、モバイルオンボーディング |
+| **サービス内部** | バックエンドサービスがユーザーの直接操作なしにステップをトリガーする | 予約スロット対象外 — 統合テストを使用。フルシステム検証が妥当な場合は通常のROI > 50パスを通じた service-integration-e2e は引き続き有効 | 非同期ジョブパイプライン、サービス間saga、スケジュールバッチ処理 |
 
-**この分類のスコープ**:
-- **E2E予約スロット**: ユーザー向けジャーニーのみが対象。サービス内部ジャーニーは予約スロットから除外される。
-- **通常のROI > 50パス**: ユーザー向け・サービス内部の両方が追加E2Eスロット（最大1件）をROI実績で競う。この分類はこのパスに影響しない。
-- **E2Eギャップチェック**: ユーザー向けジャーニーのみがgap警告をトリガーする。サービス内部ジャーニーはトリガーしない。
+この分類は予約スロットルールおよびE2Eギャップチェックに適用される。それ以外の選定はレーンごとのROIルール（後述）に従う。
 
 ### ROI計算
 
@@ -95,20 +105,29 @@ ROI Scoreは**同一テスト種別内での優先順位付け**に使用する
 
 ROI Scoreが高い = 同一テスト種別内での優先度が高い。正規化やキャッピングは適用しない — 生のスコアをそのままランキングに使用する。重複排除は候補自体を除外する別のステップであり、スコアは変更しない。
 
-#### E2EのROI閾値
+#### レーン別ROI閾値
 
-E2Eテストは所有コストが高い（作成・実行・保守それぞれが統合テストの3〜10倍）。予約スロット（ユーザー向けマルチステップジャーニー）を超える追加E2Eスロットには **ROI Score > 50** が必要。
+2つのE2Eレーンは所有コストが大きく異なるため、独立した閾値を使用する。
+
+| レーン | ROI閾値 | 理由 |
+|------|---------|------|
+| fixture-e2e | ROI ≥ 20（予約スロット以外） | ハーネスが整備されていればコストは統合テストと同等。少数のテストで十分な場合に MAX 3 を低シグナルなテストで埋めてしまうことを避けるためのフロア（基準点） |
+| service-integration-e2e | ROI > 50（予約スロット以外） | 作成・実行・保守コストが統合テストの3〜10倍。他の方法では価値を立証できないジャーニーのみに使用 |
+
+予約スロットのルールはレーンごとに適用され、閾値を上書きする（予約された候補はROIスコアに関わらず出力される）。予約スロット以外でフロアを下回る候補は出力されず、予算は意図的に未消化のまま残し、低価値なテストで埋めない。
 
 #### ROI計算例
 
 | シナリオ | BV | Freq | Legal | Defect | ROI Score | テスト種別 | 選択結果 |
 |----------|----|------|-------|--------|-----------|-----------|---------|
-| コア決済フロー | 10 | 9 | true | 9 | 109 | E2E | 選択（予約スロット: ユーザー向けマルチステップジャーニー） |
-| 決済エラー処理 | 8 | 3 | false | 7 | 31 | E2E | 閾値未満（31 < 50）、不選択 |
-| プロフィール保存フロー | 7 | 6 | false | 6 | 48 | E2E | 閾値未満（48 < 50）、不選択 |
+| コア決済UIフロー | 10 | 9 | true | 9 | 109 | fixture-e2e | 選択（予約スロット: ユーザー向けマルチステップジャーニー、フィクスチャによるブラウザ検証） |
+| 実決済サービスへのコア決済 | 10 | 9 | true | 9 | 109 | service-integration-e2e | 選択（実サービスでの正しさ。ROI閾値超過） |
+| Dismissボタンによる UI 状態更新 | 6 | 7 | false | 8 | 50 | fixture-e2e | 選択（fixture-e2e 予算3件中ランク2位） |
+| 決済エラーメッセージ表示（UI） | 5 | 4 | false | 7 | 27 | fixture-e2e | 選択（fixture-e2e 予算3件中ランク3位） |
+| 任意フィルタ切替 | 3 | 4 | false | 2 | 14 | fixture-e2e | 不選択（ランク4位、予算上限到達） |
+| 実プロバイダへの決済リトライ | 8 | 3 | false | 7 | 31 | service-integration-e2e | ROI閾値未満（31 < 50）、不選択 |
 | DB永続化チェック | 8 | 8 | false | 8 | 72 | 統合 | 選択（3件中ランク1位） |
-| エラーメッセージ表示 | 5 | 3 | false | 4 | 19 | 統合 | 選択（3件中ランク2位） |
-| 任意フィルタ切替 | 3 | 4 | false | 2 | 14 | 統合 | 不選択（ランク4位、上限到達） |
+| 純粋なデータ変換 | 5 | 3 | false | 4 | 19 | 統合 | 選択（3件中ランク2位） |
 
 ## 実装ルール
 
@@ -170,8 +189,14 @@ it('AC2-property: モデル名は常にgemini-3-pro-image-preview', () => {
 
 ### E2Eテストの実行条件
 
-- 全コンポーネント実装完了後に実行
-- モック禁止（`@dependency: full-system`）
+**fixture-e2e**:
+- UI機能の実装フェーズと並行して実行（最後に先送りしない）
+- モックバックエンド/フィクスチャ駆動の状態を使用（`@dependency: full-ui (mocked backend)`）。ライブサービス不要
+- インフラ準備なしにCIで実行可能
+
+**service-integration-e2e**:
+- 全コンポーネント実装完了かつローカルスタック起動後、最終フェーズでのみ実行
+- ローカルの実サービスまたはサービススタブを使用 — 検証対象コンポーネントに対して in-process モックは使用しない（`@dependency: full-system`）
 
 ## レビュー基準