@einja/dev-cli 0.1.29 → 0.1.31

package/scaffolds/steering/development/database-guidelines.md

@@ -0,0 +1,239 @@
+<!-- @einja:managed:start -->
+# データベース設計ガイドライン
+
+## 概要
+
+このドキュメントでは、PostgreSQLを使用したデータベース設計のベストプラクティスとPrismaスキーマの実装ガイドラインを説明します。
+
+---
+
+## 目次
+
+1. [PostgreSQL日付型の使い分け](#1-postgresql日付型の使い分け)
+2. [PrismaのDateTimeとPostgreSQL型のマッピング](#2-prismaのdatetimeとpostgresql型のマッピング)
+3. [推奨Prismaテンプレート](#3-推奨prismaテンプレート)
+4. [timestamp（タイムゾーンなし）を避ける理由](#4-timestampタイムゾーンなしを避ける理由)
+5. [既存スキーマとの整合性に関する注意](#5-既存スキーマとの整合性に関する注意)
+
+---
+
+## 1. PostgreSQL日付型の使い分け
+
+### 用途別の型選択表
+
+| PostgreSQL型 | 用途例 | 保存される情報 |
+|-------------|-------|--------------|
+| `date` | 誕生日、締日、予約日（日付のみ） | 日付のみ（例: `2025-01-15`） |
+| `timestamptz`（**推奨**） | created_at、updated_at、ログ、イベント日時 | タイムスタンプ + タイムゾーン |
+| `time` / `timetz` | 営業時間、定期実行時刻 | 時刻のみ |
+| `timestamp`（**非推奨**） | 使用禁止 | タイムゾーンなしタイムスタンプ |
+
+### 選択基準
+
+- **日付のみが重要な場合**: `date`
+  - 例: ユーザーの誕生日、契約締日
+- **日時が重要で、タイムゾーンを考慮する必要がある場合**: `timestamptz`（推奨）
+  - 例: ログ、イベント発生日時、created_at/updated_at
+- **時刻のみが重要な場合**: `time` / `timetz`
+  - 例: 店舗の営業時間、定期バッチ実行時刻
+
+---
+
+## 2. PrismaのDateTimeとPostgreSQL型のマッピング
+
+### 型マッピング表
+
+| Prisma定義 | PostgreSQL型 | 推奨度 |
+|-----------|-------------|-------|
+| `DateTime`（デフォルト） | `timestamp(3)` タイムゾーンなし | ❌ 非推奨 |
+| `DateTime @db.Timestamptz` | `timestamptz` | ✅ 推奨 |
+| `DateTime @db.Date` | `date` | ✅ 推奨（日付のみの場合） |
+| `DateTime @db.Time` | `time` | ✅ 推奨（時刻のみの場合） |
+
+### 重要な注意点
+
+- **Prismaの `DateTime` 型のデフォルトは `timestamp(3)`**（タイムゾーンなし）です
+- **必ず `@db.Timestamptz` を明示的に指定する**ことで、タイムゾーン対応になります
+- 既存のスキーマで `@db.Timestamptz` が省略されている場合、タイムゾーンなしで動作しています
+
+---
+
+## 3. 推奨Prismaテンプレート
+
+### 基本パターン
+
+```prisma
+model User {
+  id        String   @id @default(cuid())
+  email     String   @unique
+  name      String
+
+  // 日時（タイムゾーン付き）- 推奨
+  createdAt DateTime @default(now()) @db.Timestamptz
+  updatedAt DateTime @updatedAt @db.Timestamptz
+
+  // 日付のみ
+  birthDate DateTime @db.Date
+
+  // 時刻のみ（必要に応じて）
+  preferredTime DateTime? @db.Time
+
+  @@map("users")
+}
+```
+
+### ログテーブルのパターン
+
+```prisma
+model ActivityLog {
+  id        String   @id @default(cuid())
+  userId    String
+  action    String
+  metadata  Json?
+
+  // ログはタイムゾーン付きで記録（必須）
+  occurredAt DateTime @default(now()) @db.Timestamptz
+
+  user User @relation(fields: [userId], references: [id], onDelete: Cascade)
+
+  @@map("activity_logs")
+}
+```
+
+### イベント管理のパターン
+
+```prisma
+model Event {
+  id          String   @id @default(cuid())
+  title       String
+  description String?
+
+  // イベント開始日時（タイムゾーン付き）
+  startAt DateTime @db.Timestamptz
+  endAt   DateTime @db.Timestamptz
+
+  // 登録日時
+  createdAt DateTime @default(now()) @db.Timestamptz
+  updatedAt DateTime @updatedAt @db.Timestamptz
+
+  @@map("events")
+}
+```
+
+---
+
+## 4. timestamp（タイムゾーンなし）を避ける理由
+
+### 問題1: サーバーのタイムゾーン設定に依存
+
+```sql
+-- タイムゾーンなし（timestamp）の場合
+INSERT INTO users (created_at) VALUES ('2025-01-15 10:00:00');
+-- サーバーのTZ設定が Asia/Tokyo なら JST として解釈
+-- サーバーのTZ設定が UTC なら UTC として解釈
+-- 同じデータが環境によって異なる意味になる
+```
+
+```sql
+-- タイムゾーン付き（timestamptz）の場合
+INSERT INTO users (created_at) VALUES ('2025-01-15 10:00:00+09:00');
+-- 常に UTC に変換して保存（内部的に 2025-01-15 01:00:00 UTC）
+-- 取得時にクライアントのTZに変換して返却
+-- 環境に依存せず一貫した動作
+```
+
+### 問題2: マルチリージョン展開で不整合が発生
+
+- **タイムゾーンなし**: 日本リージョンとUSリージョンで同じタイムスタンプが異なる意味になる
+- **タイムゾーン付き**: すべてUTCで保存され、表示時のみ各リージョンのTZで変換される
+
+### 問題3: サマータイム（DST）の扱いが曖昧
+
+- **タイムゾーンなし**: サマータイム切り替え時に同じ時刻が2回存在する可能性（曖昧性）
+- **タイムゾーン付き**: UTCで保存されるため曖昧性がない
+
+### 結論
+
+- **必ず `@db.Timestamptz` を使用する**
+- タイムゾーンなし（`timestamp`）は使用禁止
+
+---
+
+## 5. 既存スキーマとの整合性に関する注意
+
+### 既存カラムの変更はスコープ外
+
+このガイドラインは**新規カラム追加時に適用**します。
+
+- **既存の `createdAt` / `updatedAt` カラムが `@db.Timestamptz` なしで定義されている場合**:
+  - 既存カラムの変更は別タスクで実施（マイグレーションリスクあり）
+  - 新規追加カラムのみ `@db.Timestamptz` を使用する
+
+### 移行手順（既存カラムを変更する場合）
+
+既存の `timestamp(3)` を `timestamptz` に変更する場合の手順:
+
+```prisma
+// Before
+model User {
+  createdAt DateTime @default(now())
+}
+
+// After
+model User {
+  createdAt DateTime @default(now()) @db.Timestamptz
+}
+```
+
+**マイグレーション実行**:
+
+```bash
+pnpm prisma migrate dev --name change_timestamp_to_timestamptz
+```
+
+**注意**: 既存データは自動的にタイムゾーン付きに変換されます（PostgreSQLが現在のタイムゾーン設定でUTCに変換）。
+
+### 新規テーブル作成時
+
+新規テーブルを作成する場合は、**必ず `@db.Timestamptz` を使用**してください。
+
+```prisma
+model NewFeature {
+  id        String   @id @default(cuid())
+  name      String
+
+  // 必ず @db.Timestamptz を明示
+  createdAt DateTime @default(now()) @db.Timestamptz
+  updatedAt DateTime @updatedAt @db.Timestamptz
+
+  @@map("new_features")
+}
+```
+
+---
+
+## まとめ
+
+### チェックリスト
+
+新規カラム追加時の確認事項:
+
+- [ ] 日時カラムは `@db.Timestamptz` を使用しているか
+- [ ] 日付のみのカラムは `@db.Date` を使用しているか
+- [ ] タイムゾーンなし（`timestamp`）を使用していないか
+- [ ] ログやイベント日時は必ず `timestamptz` を使用しているか
+
+### 参考資料
+
+- [PostgreSQL 公式ドキュメント - Date/Time Types](https://www.postgresql.org/docs/current/datatype-datetime.html)
+- [Prisma 公式ドキュメント - PostgreSQL connector](https://www.prisma.io/docs/orm/reference/prisma-schema-reference#postgresql)
+<!-- @einja:managed:end -->
+
+---
+
+<!-- @einja:seed:start id="database-guidelines-project" -->
+## プロジェクト固有の設定
+
+<!-- このセクションはプロジェクト固有の内容を追記する場所です -->
+<!-- einja syncで上書きされません -->
+<!-- @einja:seed:end -->

package/scaffolds/steering/development/frontend-development.md

@@ -30,10 +30,11 @@ Tanstack Query、React Hook Form、Hono Clientを活用した型安全で保守
 5. [Tanstack Query（サーバー状態管理）](#5-tanstack-queryサーバー状態管理)
 6. [React Hook Form（フォーム処理）](#6-react-hook-formフォーム処理)
 7. [コンポーネント設計](#7-コンポーネント設計)
-8. [App Router構成](#8-app-router構成)
-9. [状態管理戦略](#9-状態管理戦略)
-10. [エラーハンドリング](#10-エラーハンドリング)
-11. [実装例](#11-実装例)
+8. [Layering / z-index ガイドライン](#8-layering--z-index-ガイドライン)
+9. [App Router構成](#9-app-router構成)
+10. [状態管理戦略](#10-状態管理戦略)
+11. [エラーハンドリング](#11-エラーハンドリング)
+12. [実装例](#12-実装例)
 
 ---
 
@@ -1189,7 +1190,81 @@ export function useDeletePost() {
 
 ---
 
-## 8. App Router構成
+## 8. Layering / z-index ガイドライン
+
+UIコンポーネントの重なり順序を一貫して管理するため、z-indexトークンを使用します。
+
+### z-indexトークン管理
+
+プロジェクト全体でz-indexの値をCSS変数（デザイントークン）として一元管理しています。ハードコードされたz-index値（`z-10`, `z-50`等）は使用せず、必ずトークンを使用してください。
+
+#### トークン定義場所
+
+- **Admin**: `packages/admin-ui/src/styles/tokens.css`
+- **Web**: `apps/web/src/app/globals.css`
+
+#### トークン階層
+
+| 値 | トークン | 用途 |
+|----|---------|------|
+| 0 | `--z-base` | ベースレイヤー |
+| 10 | `--z-sticky` | sticky要素（テーブルカラム、セクションヘッダー） |
+| 10 | `--z-sidebar` | サイドバー本体 |
+| 20 | `--z-sidebar-rail` | サイドバーリサイズハンドル |
+| 30 | `--z-mobile-panel` | モバイルスライドインパネル |
+| 40 | `--z-header` | 固定ヘッダー |
+| 50 | `--z-dropdown` | ドロップダウン / ポップオーバー（Popover, Tooltip, Select, DropdownMenu） |
+| 59 | `--z-drawer-overlay` | ドロワーオーバーレイ |
+| 60 | `--z-drawer` | ドロワー本体（Drawer/Sheet Content） |
+| 69 | `--z-dialog-overlay` | ダイアログオーバーレイ |
+| 70 | `--z-dialog` | ダイアログ本体（Dialog Content） |
+| 79 | `--z-alert-dialog-overlay` | アラートダイアログオーバーレイ |
+| 80 | `--z-alert-dialog` | アラートダイアログ本体（AlertDialog Content） |
+| 90 | `--z-toast` | トースト通知 |
+| 100 | `--z-tooltip` | ツールチップ |
+
+#### 使用方法
+
+Tailwind CSSの任意値記法でCSS変数を参照します：
+
+```tsx
+// ✅ 正しい: トークンを使用
+<div className="z-[var(--z-header)]">ヘッダー</div>
+<div className="z-[var(--z-dialog)]">ダイアログ</div>
+
+// ❌ 禁止: ハードコード値
+<div className="z-10">...</div>
+<div className="z-50">...</div>
+```
+
+#### 新しいトークンの追加
+
+新しいz-index値が必要な場合は、以下の手順で追加してください：
+
+1. 既存の階層を確認し、適切な値を決定する
+2. **両方**のトークン定義ファイルに追加する（Admin用・Web用）
+3. このドキュメントの階層表を更新する
+
+### 優先順位
+
+**Tooltip > Toast > AlertDialog > Dialog > Drawer > Dropdown > Header > Mobile Panel > Sidebar Rail > Sidebar/Sticky**
+
+より重要な（ユーザーの注意を引く必要がある）要素ほど高いz-index値を持ちます。
+
+### 使用ルール
+
+1. **数値直書き禁止**: `z-50`等の直書きは禁止。必ずトークン参照を使用
+
+2. **Overlay < Content**: 同一コンポーネント内でOverlayはContentより1段下
+   - Dialog: Overlay(69) < Content(70)
+   - Drawer: Overlay(59) < Content(60)
+   - AlertDialog: Overlay(79) < Content(80)
+
+3. **時間依存制御禁止**: `setTimeout`等でのレイヤー制御は禁止
+
+---
+
+## 9. App Router構成
 
 ### ルートグループ
 

package/scaffolds/steering/development/review-guidelines.md

@@ -53,6 +53,11 @@
 - [ ] **パッケージエクスポート**
   - index.ts不使用（直接ファイルパス指定）
   - 絶対パスインポート（`@repo/server-core/...`）
+- [ ] **日付型の適切な使用**
+  - 新規DateTimeカラムに`@db.Timestamptz`が付与されているか
+  - 日付のみのカラムに`@db.Date`が使用されているか
+  - タイムゾーンなし`timestamp`を使用していないか
+  - 詳細: [データベースガイドライン](database-guidelines.md)
 
 ---
 

package/scaffolds/steering/development-workflow.md

@@ -65,6 +65,7 @@
 │  pnpm task:loop <issue-number>                                              │
 │      │                                                                       │
 │      ├── 初期化: Issue取得、ブランチ作成、Vibe-Kanban接続                     │
+│      │      ├── Phase毎に親Issue作成（MCP create_issue）                     │
 │      │                                                                       │
 │      └── ループ開始 ─────────────────────────────────────────┐               │
 │           │                                                   │               │
@@ -75,7 +76,7 @@
 │           │                                                   │               │
 │           ▼                                                   │               │
 │      ┌─────────────────────────────────────────────────────┐ │               │
-│      │ Vibe-Kanbanにタスク作成 → start_task_attempt        │ │               │
+│      │ サブIssue作成（親Issue配下） → start_workspace_session│ │               │
 │      │ （Claude Codeが自動起動されて実装開始）              │ │               │
 │      └─────────────────────────────────────────────────────┘ │               │
 │           │                                                   │               │
@@ -111,6 +112,11 @@
 │           ▼                                                                   │
 │      task:loopがDone検知 → GitHub Issueチェックボックス更新                   │
 │           │                                                                   │
+│      Phase全サブIssue完了？                                                   │
+│      ├─ Yes → 親Issue Workspace作成 → PR作成・マージ                         │
+│      │        → 親Issue自動Done                                               │
+│      └─ No  → スキップ                                                       │
+│           │                                                                   │
 │           └──────────────────────────────────────────────────┘               │
 │                        次のタスクグループを自動開始                            │
 │                                                                              │
@@ -187,6 +193,8 @@ pnpm task:loop 123 --branch develop       # develop ブランチベースで実
 
 実行後、specで作成されたタスクが着手可能なものから自動で実行開始されます。
 
+Phase毎に親Issueが自動作成され、タスクグループはサブIssueとして管理されます。
+
 1. **Vibe-Kanbanの画面を眺める** - タスクの進捗を確認
 2. **In Reviewになったら自己レビュー** - 実装内容を確認
 3. **OKなら「Create PR」ボタンをクリック** - PRが自動作成される
@@ -234,6 +242,12 @@ task-executer → task-reviewer → task-qa → In Review
 │      ↓                                                      │
 │  GitHub Issue: チェックボックス更新（自動）                 │
 │      ↓                                                      │
+│  Phase 全サブIssue完了？                                    │
+│      ├─ Yes → 親Issue Workspace作成                         │
+│      │        → Phase→Issue PR作成・マージ                  │
+│      │        → 親Issue自動Done（タイムアウト2分）           │
+│      └─ No  → スキップ                                      │
+│      ↓                                                      │
 │  次のタスクが自動開始                                       │
 └─────────────────────────────────────────────────────────────┘
 ```

package/scaffolds/steering/infrastructure/deployment.md

@@ -176,9 +176,12 @@ flowchart TB
 
     subgraph "ci/action.yml"
         C1[setup action 呼び出し] --> C2[pnpm generate]
-        C2 --> C3[pnpm typecheck]
+        C2 --> C2B{database-url?}
+        C2B -->|あり| C2C[db:migrate:deploy]
+        C2B -->|なし| C3
+        C2C --> C3[pnpm typecheck]
         C3 --> C4[pnpm lint]
-        C4 --> C5[pnpm test]
+        C4 --> C5[pnpm test<br/>DATABASE_URL]
     end
 
     subgraph "migrate/action.yml"
@@ -197,7 +200,7 @@ flowchart TB
 | Action | ファイル | 内容 | 呼び出し元 |
 |--------|---------|------|-----------|
 | **Setup** | `actions/setup/action.yml` | pnpm + Node.js + install | ci action, migrate action, cleanup |
-| **CI** | `actions/ci/action.yml` | setup → generate → typecheck → lint → test | deploy-stable-branches, deploy-pr-preview |
+| **CI** | `actions/ci/action.yml` | setup → generate → [migrate] → typecheck → lint → test | deploy-stable-branches, deploy-pr-preview |
 | **Migrate** | `actions/migrate/action.yml` | setup → generate → migrate → seed (optional) | deploy-stable-branches |
 | **Neon Export Env** | `actions/neon-export-env/action.yml` | .env.previewからNeon環境変数をエクスポート | deploy-pr-preview, cleanup-pr-preview-on-close |
 
@@ -231,30 +234,31 @@ sequenceDiagram
     GH->>Actions: deploy-pr-preview トリガー
 
     rect rgb(240, 248, 255)
-        Note over Actions,CI: CI Checks
-        Actions->>CI: ci action 呼び出し
+        Note over Actions,CI: CI Checks（PostgreSQLサービスコンテナ付き）
+        Actions->>CI: ci action 呼び出し (database-url付き)
         CI->>CI: setup (pnpm + Node.js)
         CI->>CI: pnpm generate
+        CI->>CI: db:migrate:deploy (テスト用DB)
         CI->>CI: pnpm typecheck
         CI->>CI: pnpm lint
-        CI->>CI: pnpm test
+        CI->>CI: pnpm test (DATABASE_URL付き)
         CI-->>Actions: CI完了
     end
 
     rect rgb(255, 248, 240)
-        Note over Actions,Neon: Neon Branch 作成
+        Note over Actions,Neon: Neon Branch 作成（connection_uri API方式）
         Actions->>Actions: dotenvx で NEON_API_KEY 取得
         Actions->>Actions: pnpm generate (Prisma Client生成)
         Actions->>Neon: preview/pr-{番号} ブランチ作成
-        Neon-->>Actions: DB URL (direct + pooled)
-        Actions->>Neon: pnpm db:push (スキーマ同期)
+        Neon-->>Actions: DB URL (connection_uri APIから取得)
+        Actions->>Neon: pnpm db:push --accept-data-loss (スキーマ同期)
         Actions->>Neon: pnpm db:seed (データ投入)
     end
 
     rect rgb(240, 255, 240)
         Note over Actions,Vercel: Vercel デプロイ
         Actions->>Vercel: vercel pull
-        Actions->>Vercel: 環境変数同期 (ブラックリスト除外)
+        Actions->>Vercel: 環境変数同期 (encrypted-only)
         Actions->>Vercel: vercel build (DATABASE_URL=pooled)
         Actions->>Vercel: vercel deploy --prebuilt
         Vercel-->>Actions: Preview URL
@@ -279,20 +283,21 @@ sequenceDiagram
     GH->>Actions: deploy-stable-branches トリガー
 
     rect rgb(240, 248, 255)
-        Note over Actions,CI: CI Checks
-        Actions->>CI: ci action 呼び出し
+        Note over Actions,CI: CI Checks（PostgreSQLサービスコンテナ付き）
+        Actions->>CI: ci action 呼び出し (database-url付き)
         CI->>CI: setup (pnpm + Node.js)
         CI->>CI: pnpm generate
+        CI->>CI: db:migrate:deploy (テスト用DB)
         CI->>CI: pnpm typecheck
         CI->>CI: pnpm lint
-        CI->>CI: pnpm test
+        CI->>CI: pnpm test (DATABASE_URL付き)
         CI-->>Actions: CI完了
     end
 
     Actions->>Actions: ブランチ判定 (環境変数セット)
 
     rect rgb(255, 248, 240)
-        Note over Actions,Neon: DB マイグレーション (main/stagingのみ)
+        Note over Actions,Neon: DB マイグレーション (main/stagingのみ・if分岐方式)
         Actions->>Neon: pnpm db:migrate:deploy
     end
 
@@ -303,7 +308,7 @@ sequenceDiagram
     rect rgb(240, 255, 240)
         Note over Actions,Vercel: Vercel デプロイ
         Actions->>Vercel: vercel pull
-        Actions->>Vercel: 環境変数同期 (ブラックリスト除外)
+        Actions->>Vercel: 環境変数同期 (encrypted-only)
         Actions->>Vercel: vercel pull (Re-pull: 同期後の最新化)
         Actions->>Vercel: vercel build [--prod]
         Actions->>Vercel: vercel deploy --prebuilt [--prod]
@@ -521,14 +526,14 @@ flowchart TD
 
 ### Vercel環境変数の自動同期
 
-ワークフローは `ENV_VAR_EXCLUDE` ブラックリスト正規表現で**同期対象外**を制御:
+ワークフローは **encrypted-only方式** で同期対象を制御:
 
-| ワークフロー | 除外フィルタ | 説明 |
-|------------|-----------|------|
-| PR Preview | `^(DOTENV_\|NEON_\|NODE_ENV$\|VERCEL_)` | DOTENV/Neon/Vercel内部変数を除外。DATABASE_URLはNeonブランチURLを`--env`で注入するため別途除外 |
-| Stable Branches | `^(DOTENV_\|NODE_ENV$\|VERCEL_)` | DOTENV/Vercel内部変数を除外。DATABASE_URL含む全アプリ変数を同期 |
+| ワークフロー | 同期対象 | 除外 | 説明 |
+|------------|---------|------|------|
+| PR Preview | `.env.preview` 内の `encrypted:` キー | `NEON_*`, `DATABASE_*` | dotenvxで管理しているもの = Vercelに同期すべきもの |
+| Stable Branches | `.env.{env}` 内の `encrypted:` キー | なし | dotenvxで管理している全キーを同期 |
 
-**設計意図**: ホワイトリスト方式だと新しい環境変数追加時にフィルタ更新漏れが発生するため、ブラックリスト方式を採用。
+**設計意図**: dotenvxの暗号化ファイル内の `encrypted:` を含む行のキー名のみを対象とし、「dotenvxで管理 = Vercelに同期」の意図を明確にする。ブラックリスト方式（全env走査）ではシステム変数混入や新変数追加時の漏れリスクがあるため廃止。
 
 ---
 
@@ -574,6 +579,7 @@ flowchart TD
 | タスク | キャッシュ | 理由 |
 |--------|----------|------|
 | build | ✅ | ビルド成果物を再利用 |
+| generate | ✅ | `src/__generated__/**` をキャッシュ（outputs定義） |
 | lint | ✅ | ソースコード未変更時はスキップ |
 | typecheck | ✅ | 型定義未変更時はスキップ |
 | test | ✅ | テストコード・対象未変更時はスキップ |

package/scaffolds/steering/task-management.md

@@ -455,6 +455,26 @@ server-coreパッケージが動作し、DBに接続できること（AC1.1を
 design.md「Server Core構築」セクション
 ```
 
+### 親Issue/サブIssue階層（task:loop使用時）
+
+`pnpm task:loop` 使用時は、Vibe-Kanban上でPhase→親Issue、タスクグループ→サブIssueの階層構造で管理されます。
+
+**親Issueタイトル形式**:
+```
+[Issue{N} Phase{M}] {Phase名}
+```
+例: `[Issue17 Phase1] 基盤構築`
+
+**サブIssueタイトル形式**:
+```
+[Issue{N} {X.Y}] {タスクグループ名}
+```
+例: `[Issue17 1.1] Server Core構築とDB設定`
+
+**親子関係の設定**: サブIssue作成後、REST API（PATCH `/api/remote/issues/{id}`）で `parent_issue_id` を設定します。
+
+**注意**: `/einja:task-exec` による単発実行時はこの階層構造は使用されません。`pnpm task:loop` 使用時のみ適用されます。
+
 ## コマンドリファレンス
 
 ### タスク管理関連コマンド
@@ -483,6 +503,7 @@ pnpm task:loop <issue番号> --branch <ブランチ> # ベースブランチ指
 ```
 - 着手可能なタスクグループを並列でVibe-Kanbanに登録
 - Done状態を監視して次のタスクを自動開始
+- Phase毎に親Issueを作成し、タスクグループをサブIssueとして管理（詳細は「親Issue/サブIssue階層」を参照）
 - **前提**: `npx @einja/cli init` 実行済み、Claude Code インストール済み
 
 **仕様書からドキュメント更新**:

package/scaffolds/templates/README.md

@@ -31,16 +31,20 @@
 受け入れ基準は以下の形式で記載してください：
 
 ```markdown
-- [ ] Given: [前提条件]
-      When: [実行する操作]
-      Then: [期待される結果]
+- [ ] **AC1.1**: [振る舞いの1文要約]
+  - Given: [前提条件]
+  - When: [実行する操作]
+  - Then: [期待される結果]
+  - 検証レベル: [Unit / Integration / E2E / Browser]
 ```
 
 **良い例**:
 ```markdown
-- [ ] Given: ログインページにアクセスした
-      When: 有効なメールアドレスを入力して送信
-      Then: 成功メッセージが表示され、メールが送信される
+- [ ] **AC1.1**: 有効なメールアドレスで送信すると、成功メッセージが表示されメールが送信される
+  - Given: ログインページにアクセスした
+  - When: 有効なメールアドレスを入力して送信
+  - Then: 成功メッセージが表示され、メールが送信される
+  - 検証レベル: Integration
 ```
 
 **悪い例**:
@@ -76,7 +80,7 @@
 **重要なセクション**:
 - **受け入れ基準（Acceptance Criteria）**: QAエージェント（task-qa）がこのセクションを参照してテストシナリオを作成します
 - **AC番号体系**: AC1.1, AC1.2 のように、ストーリー番号.連番 で一意に識別
-- **検証レベル**: Unit/Integration/E2E を必ず指定
+- **検証レベル**: Unit/Integration/E2E/Browser を必ず指定
 - **検証者**: task-executer または task-qa を明記
 
 **使い方**: