@careerchain/stdd 0.1.0

package/assets/.claude/skills/documenting-specifications/guides/error-handling.md

@@ -0,0 +1,78 @@
+# エラーハンドリングガイド
+
+REQUIREMENTS.mdとTECH_DESIGN.mdでエラーケースを記述する際のガイドライン。
+
+## エラーの分類
+
+| エラー種別 | 記述先 | 内容 |
+|------------|----------|---------|
+| **ユーザー向けエラー** | `REQUIREMENTS.md` | エラーメッセージ文言<br>ユーザーへの影響<br>画面遷移<br>Priority |
+| **技術的なエラー** | `TECH_DESIGN.md` | エラーコード定義<br>HTTPステータス<br>ハンドリングロジック<br>テスト戦略 |
+
+## REQUIREMENTS.md: ユーザー向けエラー
+
+**原則**:
+- エラーケースも通常のユーザージャーニーとして扱う
+- 各エラージャーニーにPriorityを付与
+- クリティカルなエラーは**P0/P1**、その他は**P2**
+
+**例**:
+
+```markdown
+### P1 ジャーニー: 無効な認証情報（ID/パスワード）
+**Priority**: P1（Important）
+**Status**: ✅ 実装済み
+
+#### 手順
+1. ユーザーが`/login`ページでID/パスワードタブを選択
+2. ユーザーは間違ったメールアドレスまたはパスワードを入力
+3. ユーザーは「ログイン」ボタンをクリック
+4. システムは認証に失敗
+5. システムはエラーメッセージ「ログインに失敗しました。メールアドレスとパスワードを確認してください。」を表示
+6. ユーザーはログインページに留まり、再試行できる
+
+#### 期待結果
+- ユーザーに明確なエラーメッセージが表示される
+- セキュリティのため、「メールアドレスが存在しない」vs「パスワードが間違っている」を区別しない
+- ユーザーは再試行できる
+```
+
+## TECH_DESIGN.md: 技術的なエラーハンドリング
+
+**原則**:
+- 各エラーケースのテスト戦略を定義（E2E/Integration/Unit）
+- エラーハンドリングの実装方針を記述
+- テストカバレッジを明確化
+
+**例**:
+
+```markdown
+## 5. エラーハンドリング戦略
+
+### エラーコード定義
+
+| エラーコード | HTTPステータス | メッセージ | テスト戦略 |
+|------------|-------------|---------|---------------|
+| `AUTH_FAILED` | 401 | ログインに失敗しました | Integration + Unit |
+| `EMAIL_NOT_FOUND` | 404 | メールアドレスが見つかりません | Integration + Unit |
+| `INVALID_PASSWORD` | 401 | パスワードが正しくありません | Integration + Unit |
+
+### 実装方針
+
+- NextAuth Credentials Providerで認証失敗を検出
+- エラーメッセージを統一: `EMAIL_NOT_FOUND`と`INVALID_PASSWORD`を区別せず`AUTH_FAILED`を使用
+- クライアント側で`signIn()`の戻り値をチェックし、エラー時はSnackbarで通知
+
+### テストカバレッジ
+
+- **E2E**: ❌ 不要（認証フローは複雑でメンテナンスコストが高い）
+- **Integration**: ✅ NextAuth Credentials Providerの失敗ケース
+- **Unit**: ✅ エラーハンドリングロジック（`LoginClient.tsx`）
+```
+
+## 重要なポイント
+
+- **REQUIREMENTS.md**: ユーザー視点 - どのエラーメッセージが表示され、次に何が起こるか
+- **TECH_DESIGN.md**: 技術視点 - エラーコード、HTTPステータス、どう処理するか、どうテストするか
+- エラーケースも通常のジャーニーと同様にPriorityを付与
+- TECH_DESIGN.mdでエラーケースを適切なテストレベルにマッピング

package/assets/.claude/skills/documenting-specifications/guides/stdd-violations.md

@@ -0,0 +1,237 @@
+# STDD違反例と対策ガイド
+
+このドキュメントでは、実際に発生したSTDD違反例を記録し、同じミスを繰り返さないための教訓を共有します。
+
+## 実装開始前の必須チェックリスト
+
+**⚠️ 重要**: 以下のチェックリストをすべて✅にするまで、**絶対に実装コードを書いてはいけません**。
+
+```
+□ 1. 対応するREQUIREMENTS.mdを読んだ
+□ 2. 対応するTECH_DESIGN.mdを読んだ
+□ 3. TECH_DESIGN.mdの「Test Strategy」セクションを確認した
+□ 4. TECH_DESIGN.mdに記載されたテスト総数を確認した（例: 合計33件）
+□ 5. Unit/Integration/E2Eのテスト内訳を理解した（例: Unit 18件, Integration 9件, E2E 6件）
+□ 6. テスト作成タスクをTodoWriteに追加した
+□ 7. テストファイルを作成した（Red状態）
+□ 8. テストファイルをコミットした
+```
+
+**このチェックリストを完了するまで、Server Actions、UI Components、Pages等の実装コードは一切書かないこと。**
+
+---
+
+## 違反例1: テスト作成をスキップして実装開始
+
+**発生日**: 2026-01-04
+**機能**: パスワード再設定機能（`<app.id>`）
+
+### ❌ 何が間違っていたか
+
+```
+1. REQUIREMENTS.md + TECH_DESIGN.md 作成 ✅
+2. Tasks分解 ✅
+3. Server Actions実装開始 ❌ ← ここが間違い！テストを飛ばした
+4. UI実装 ❌
+5. テスト作成（後から） ❌ ← 実装後にテストを書いてしまった
+```
+
+### ✅ 正しい手順
+
+```
+1. REQUIREMENTS.md + TECH_DESIGN.md 作成 ✅
+2. Tasks分解 ✅
+3. Unit テスト作成（18件） ✅ ← 実装前に必須！
+4. Integration テスト作成（9件） ✅
+5. E2E テスト作成（6件） ✅
+6. テストコミット ✅
+7. 実装 + テスト更新（Red → Green） ✅
+8. テスト実行・通過確認 ✅
+```
+
+### 教訓
+
+- テストを先に書くことで、仕様の理解漏れを防ぎ、Red-Green-Refactorサイクルを回せる
+- TECH_DESIGN.mdには必ずテスト総数が記載されているので、実装前に確認すること
+- TodoWriteでタスクを作成する際、テスト作成を最優先タスクとして明記すること
+
+### 再発防止策
+
+- 実装タスクを開始する前に、必ず「実装開始前の必須チェックリスト」を確認する
+- チェックリストの項目7「テストファイルを作成した」が✅になるまで、実装コードを書かない
+
+---
+
+## 違反例2: TECH_DESIGN.mdのテスト総数を確認せずに実装
+
+### ❌ 悪い例
+
+```
+TECH_DESIGN.mdに「合計33件（Unit: 18件, Integration: 9件, E2E: 6件）」と明記されているのに、
+テスト総数を確認せずに実装を開始してしまう
+```
+
+### ✅ 正しい手順
+
+```
+1. TECH_DESIGN.mdの「Test Strategy」セクションを開く
+2. テスト総数を確認: 「合計33件」
+3. 内訳を確認: Unit 18件, Integration 9件, E2E 6件
+4. TodoWriteに33件分のタスクを作成
+5. 33件すべてのテストファイルを作成してからコミット
+6. この時点で初めて実装を開始
+```
+
+### 教訓
+
+TECH_DESIGN.mdには必ずテスト総数が記載されているので、実装前に必ず確認すること
+
+---
+
+## 違反例3: TECH_DESIGN.mdを見ずにE2Eテストを作成
+
+### ❌ 悪い例
+
+```typescript
+// TECH_DESIGN.mdには「利用規約のE2Eテストは不要」と書いてあるのに作成してしまう
+test('利用規約リンクが別タブで開く', async ({ page }) => {
+  // このテストはTECH_DESIGN.mdに記載がない = 不要
+});
+```
+
+### ✅ 正しい手順
+
+```
+1. タスク受領: "ログイン機能のE2Eテストを作成して"
+2. ドキュメント確認:
+   - docs/<app.id>/login/REQUIREMENTS.md を読む
+   - docs/<app.id>/login/TECH_DESIGN.md を読む
+   - TECH_DESIGN.mdの「Journey別テスト戦略」セクションを確認
+3. 実装:
+   - TECH_DESIGN.mdに記載されたテストケースのみを実装
+   - TECH_DESIGN.mdに記載されていないテストは作成しない
+```
+
+---
+
+## TodoWriteでのタスク分解の正しい順序
+
+```typescript
+// ❌ 悪い例（実装を優先してしまう）
+[
+  { content: "Server Actions実装", status: "in_progress" },
+  { content: "UI実装", status: "pending" },
+  { content: "テスト作成", status: "pending" }, // 後回しは禁止！
+]
+
+// ✅ 良い例（テスト作成を最優先）
+[
+  { content: "Unit テスト作成（18件）", status: "in_progress" }, // 最優先
+  { content: "Integration テスト作成（9件）", status: "pending" },
+  { content: "E2E テスト作成（6件）", status: "pending" },
+  { content: "テストをコミット", status: "pending" },
+  // ↓ テスト完了後に実装を開始
+  { content: "実装 + テスト更新（Green状態へ）", status: "pending" },
+  { content: "テスト実行・通過確認", status: "pending" },
+]
+```
+
+---
+
+## 実装・テスト修正時のSpecドキュメント更新ルール
+
+**絶対に守るべき原則**: テストや実装を修正した場合は、**必ず対応するREQUIREMENTS.mdとTECH_DESIGN.mdも更新の必要がないか確認し、適宜更新すること**。
+
+⚠️ **更新時もSSOT原則を厳守する**。Specには「現在の最新仕様」だけを書き、変更前後の比較・変更理由・「今回の追加」は一切書かない。履歴はgit log・PR・issueに任せる。詳細は[SKILL.md「絶対ルール: SSOT原則」](../SKILL.md)を参照。
+
+### テスト修正時の更新ルール
+
+1. **テストケースを追加した場合**
+   - TECH_DESIGN.mdの該当セクション（E2E/Integration/Unit）にテストケースを追加
+   - テスト総数を更新（「テストカバレッジサマリー」セクション）
+
+2. **テストケースを削除した場合**
+   - TECH_DESIGN.mdから該当テストケースを除去
+   - テスト総数を更新
+   - **削除理由・「削除した」旨の注記は書かない**（履歴はgit logが保持する）
+   - ただし、現在の仕様として「このケースはUnitテストでカバーする」など読者が必要とする情報があれば、現在仕様の説明として記述してよい
+
+3. **テストの実装方法を変更した場合**
+   - TECH_DESIGN.mdの「実装方法」セクションを**現在の方式のみ**に書き換える
+   - **「変更前」「変更後」「変更理由」のラベルや比較表現を使わない**
+
+### 実装修正時の更新ルール
+
+1. **実装方法を変更した場合**
+   - TECH_DESIGN.mdの該当する「Decision」「Technical Implementation」セクションを**現在の方式のみ**に書き換える
+   - 「現在この方式を採用している理由」は書いてよい（設計根拠）。「以前の方式から変更した理由」は書かない（履歴）
+
+2. **UIを変更した場合**
+   - REQUIREMENTS.mdのUser Journey、画面仕様を**現在のUIのみ**を反映する形で書き換える
+   - TECH_DESIGN.mdの画面設計セクションを書き換える
+   - **E2Eテスト、Integrationテストの両方を確認・更新**
+
+### 更新チェックリスト
+
+```
+□ 1. TECH_DESIGN.mdのテストケース一覧を確認・更新
+□ 2. TECH_DESIGN.mdのテスト総数を確認・更新
+□ 3. TECH_DESIGN.mdの実装方法・技術的詳細を「現在の仕様のみ」に更新
+□ 4. SSOT原則違反の禁止語（変更前/変更後/今回/既存/...）が含まれていないかgrep
+□ 5. REQUIREMENTS.mdのUser Journey、画面仕様を確認
+□ 6. E2Eテストが実装と整合しているか確認・更新
+□ 7. Integrationテストが実装と整合しているか確認・更新
+```
+
+**重要**: UI変更を行った場合は、E2EテストとIntegrationテストの**両方**を必ず確認すること。
+
+---
+
+## 具体例
+
+### 例1: テストケースを除去した場合
+
+✅ **良い例**（現在の仕様のみ記述）:
+
+```markdown
+**SignupForm（`<app.path>/components/auth/SignupForm.test.tsx`）**:
+
+1. メール検証リンク送信（正常系）
+2. Googleアカウントで新規登録（正常系）
+3. メールアドレス重複エラー（異常系）
+4. 空のメールアドレスのバリデーションエラー
+5. ネットワークエラー/サーバーエラー
+
+**メール形式バリデーションについて**: `type="email"`のHTML5バリデーションが先に実行されるため、
+React Hook Form側ではテストせず、`signupSchema`のUnitテストでカバーする。
+
+**テスト総数**: 36件（E2E: 5件、Integration: 9件、Unit: 31件）
+```
+
+❌ **悪い例**（履歴・削除理由を書いている）:
+
+```markdown
+~~6. 無効なメール形式のバリデーション~~ ← 削除
+**削除理由**: HTML5バリデーションが先に動くためテストできない
+```
+
+### 例2: 実装方法を変更した場合
+
+✅ **良い例**（現在の方式のみ記述）:
+
+```markdown
+### メール送信実装
+
+`admin.generateLink()` でリンクを生成し、Resend経由でHTMLメールを送信する。
+HTMLテンプレートのカスタマイズ性を確保するため、Supabase Authの組み込みメール送信は使わない。
+```
+
+❌ **悪い例**（変更前後を比較している）:
+
+```markdown
+### メール送信実装
+
+**変更前**: `supabase.auth.signUp()`でSupabase Auth経由でメール送信
+**変更後**: `admin.generateLink()` + Resend経由でHTMLメール送信
+**変更理由**: テンプレートのカスタマイズ性
+```

package/assets/.claude/skills/documenting-specifications/templates/requirements.md

@@ -0,0 +1,184 @@
+# REQUIREMENTS.md テンプレート
+
+**目的**: ビジネス要件とユーザージャーニーをステークホルダー視点で定義
+
+**配置**: `docs/<app>/<path>/REQUIREMENTS.md`
+
+## テンプレート構造
+
+```markdown
+# [機能名] 仕様書
+
+---
+
+## 1. 概要
+
+### 解決する問題
+
+（この機能が解決する問題）
+
+### 対象ユーザー
+
+（対象ユーザー）
+
+### ビジネス目標
+
+（ビジネス目標 - 箇条書きで3-5項目）
+
+---
+
+## 2. ユーザージャーニー
+
+### [メインフロー名]
+
+**Priority**: P0 (Critical Path)
+
+#### 手順
+
+1. ユーザーが...する
+2. システムは...する
+3. ユーザーは...する
+
+#### 期待結果
+
+- xxが...されること
+- xxが...すること
+- xxが...されないこと
+
+---
+
+### [別のクリティカルパス]
+
+**Priority**: P0 (Critical Path)
+
+#### 手順
+
+1. ...
+
+#### 期待結果
+
+- ...
+
+---
+
+### [重要なエラーケース]
+
+**Priority**: P1 (Important)
+
+#### 手順
+
+1. ユーザーが（誤った操作）...
+2. システムはエラーメッセージ「...」を表示
+3. ユーザーは...
+
+#### 期待結果
+
+- エラーメッセージが明確
+- ユーザーが次のアクションを理解できる
+
+---
+
+### [エッジケース]
+
+**Priority**: P2 (Nice to Have)
+
+#### 手順
+
+1. ...
+
+#### 期待結果
+
+- ...
+
+---
+
+## 3. UI/UXデザイン
+
+ワイヤーフレーム（WF）はHTMLで `./wireframes/` 配下に置き、本セクションからリンクする。
+WFは `generating-wireframes` スキルで生成する（低忠実度・グレースケール・主要文言は実値）。
+ASCIIアートは使わない。
+
+### ワイヤーフレーム
+
+- [ワイヤーフレーム一覧（index）](./wireframes/index.html)
+
+| 画面 | 状態 | WF |
+|------|------|----|
+| [画面名1] | 通常 / 空 / エラー | [画面名1](./wireframes/[screen-1].html) |
+| [画面名2] | 通常 | [画面名2](./wireframes/[screen-2].html) |
+
+### 画面ごとの要点
+
+#### [画面名1]
+
+- 主な操作（ボタン文言）: [検索] / [新規登録] / ...
+- 表示要素: （ヘッダー / 検索条件 / 一覧 / ページネーション など要点）
+- インタラクション: （選択・遷移・送信時の挙動）
+
+#### [画面名2]
+
+- 主な操作（ボタン文言）: ...
+- 表示要素: ...
+
+---
+
+### 表示要素
+
+| 要素 | 説明 |
+|------|------|
+| 要素名 | 説明 |
+| 要素名 | 説明 |
+
+---
+
+### 空状態・エラー状態
+
+（コンテンツがない場合やエラー時の表示）
+
+---
+
+## 4. エッジケース
+
+### [ケース名1]
+- 詳細説明
+
+### [ケース名2]
+- 詳細説明
+
+---
+
+## 5. 成功基準
+
+（この機能の成功基準 - チェックリスト形式）
+
+- ✅ [達成すべき項目1]
+- ✅ [達成すべき項目2]
+- ✅ [達成すべき項目3]
+
+---
+
+## 6. スコープ外
+
+- （この機能で対応しない項目）
+- （将来的な拡張として残す項目）
+```
+
+## 重要なポイント
+
+### 記述すべき内容
+
+- すべてのユーザージャーニーを記述（正常系、エラーケース、エッジケース）
+- 各ジャーニーにPriority（P0/P1/P2）を付与
+- **ユーザー視点で記述（What & Why）**
+- **ユーザーから見える挙動のみを記述**
+- UI/UXデザイン（HTMLワイヤーフレームへのリンク、表示要素、空状態）→ generating-wireframes スキルで生成
+- 成功基準（この機能の成功基準チェックリスト）
+
+### 記述不要な内容
+
+- データモデル（テーブル定義、RLSポリシー）→ TECH_DESIGN.mdに記載
+- セッション管理の実装詳細（NextAuth、JWT等）
+- 実装ファイルへの参照・行番号
+- 関数名、クラス名などのコード詳細
+- テスト実装の詳細（TECH_DESIGN.mdに記載）
+- 実装方法の詳細（TECH_DESIGN.mdに記載）

package/assets/.claude/skills/documenting-specifications/templates/screen-items-definition.md

@@ -0,0 +1,179 @@
+# SCREEN_ITEMS_DEFINITION.md テンプレート
+
+**目的**: 画面の入力項目・表示項目を「UI × バリデーション × DBマッピング」の粒度で定義する実装SSoT（Single Source of Truth）
+
+**配置**: `docs/<app>/<path>/SCREEN_ITEMS_DEFINITION.md`
+
+**作成タイミング**（オプション。以下に当てはまる画面で作成を検討）:
+
+- フォーム項目が多い画面
+- 複雑なバリデーションルール／操作モード（Create / Edit / View）がある
+- 表示形式（フォーマット・単位）や DB カラムとの対応の明示が必要
+
+**画面タイプ別の使い分け**:
+
+| 画面タイプ | 使うセクション |
+| --- | --- |
+| 入力フォーム（登録・編集） | 0. 操作モード / 1. 画面項目定義（入力） / 操作ボタン定義 / 3. バリデーション適用ルール |
+| 一覧・検索 | 1.x 検索条件項目 + 1.x 一覧表示項目 |
+| 詳細・表示専用 | 1. 画面項目定義（表示） + 表示レイアウト |
+
+不要なセクション（操作モード・バリデーション適用ルール等）は表示専用画面では省略してよい。
+
+> **記述粒度の方針**: 本書は技術スタック非依存とする。言語固有の型（TS型等）・ORM・フレームワーク詳細は記載せず TECH_DESIGN.md に委ねる。DBマッピング（保存先テーブル・カラム）は画面項目と DB スキーマの対応を示す SSoT として記載する。
+
+## テンプレート構造
+
+```markdown
+# [画面名]（[SCREEN_ID]）画面項目定義
+
+本ドキュメントは、[画面名]画面における **画面項目定義（実装SSoT）** を定義する。
+
+- 画面レイアウト（Excel / 画像 / WF）を正（SSoT）とする
+- DB スキーマは画面項目定義に追従する（DB のメタデータは本書には定義しない）
+- SELECT 項目は label-only（表示文字列＝保存値）とする
+- デフォルト値の表記は **null で統一**する
+
+---
+
+## 0. 操作モード定義  ← 入力フォームの場合のみ
+
+| モード | 説明                       |
+| ------ | -------------------------- |
+| Create | 新規登録時の操作           |
+| Edit   | 既存編集時の操作           |
+| View   | 参照専用モード（初期表示） |
+
+※ View モードではすべての項目を非活性とする（表中には明示しない）
+
+---
+
+## 1. 画面項目定義（UI × Validation × DB Mapping）
+
+### 表記ルール  ← 操作モードを持つ画面のみ
+
+- **必須条件**：操作モード（Create / Edit）ごとの必須可否を記載（例: Create: 必須 / Edit: 必須）
+- **活性条件**：操作モード（Create / Edit）ごとの入力可否を記載（例: Create: 活性 / Edit: 非活性）
+- **デフォルト値**：新規登録時（Create）のみ適用
+- **SELECT定義**：`2. SELECT項目定義` 内の参照先ID（例: `S.1 業界`）を記載
+
+#### 列の意味（列レジェンド）
+
+| 列 | 内容 |
+| --- | --- |
+| 項目名 | 画面に表示するラベル |
+| 必須（条件） | 必須可否。操作モードがある場合はモードごと |
+| 活性（条件） | 入力可否。操作モードがある場合はモードごと |
+| デフォルト値 | Create 時の初期値（なければ null） |
+| 入力コンポーネント | Text / TextArea / Number / Date / Select / Checkbox / Tag など |
+| 制約 | maxLen / 範囲（0–100）/ 相関（From ≤ To）/ 形式 など |
+| SELECT定義 | SELECT 項目の参照先ID（なければ – ） |
+| DBテーブル | 保存先テーブル |
+| DBカラム | 保存先カラム |
+| 備考 | 連動・特記事項（新規カラム・FK 等もここに記す） |
+
+---
+
+### 1.1 [セクション名（例: 基本情報）]  ← 入力フォーム
+
+| 項目名 | 必須条件 | 活性条件 | デフォルト値（Create） | 入力コンポーネント | 制約 | SELECT定義 | DBテーブル | DBカラム | 備考 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [項目名] | Create: 必須 / Edit: 必須 | Create: 活性 / Edit: 活性 | null | Text | maxLen=100 | – | [table] | [column] | |
+| [項目名] | Create: 任意 / Edit: 任意 | Create: 活性 / Edit: 活性 | null | Select | – | S.1 [選択肢名] | [table] | [column] | |
+
+---
+
+### 1.x 検索条件項目  ← 一覧・検索画面
+
+| 項目名 | 必須 | 活性 | デフォルト値 | 入力コンポーネント | 制約 | SELECT定義 | DBテーブル | DBカラム | 備考 |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| [項目名] | 任意 | 活性 | null | Text | 部分一致 | – | [table] | [column] | OR検索 |
+
+### 1.x 一覧表示項目  ← 一覧・検索画面
+
+| 項目名 | 表示 | ソート | DBテーブル | DBカラム | 備考 |
+| --- | --- | --- | --- | --- | --- |
+| [項目名] | ○ | ○ | [table] | [column] | |
+
+---
+
+### 1.x [タブ名]表示項目  ← 詳細・表示専用画面
+
+| 項目名 | 表示 | DBテーブル | DBカラム | 備考 |
+| --- | --- | --- | --- | --- |
+| [項目名] | ○ | [table] | [column] | 表示形式（例: 「XX歳」/ From–To）を備考に記載 |
+
+---
+
+### 1.x 操作ボタン定義  ← ボタンを持つ画面
+
+| ボタン名 | 表示条件 | 活性条件 | アクション | 備考 |
+| --- | --- | --- | --- | --- |
+| [登録] | Create / Edit モード | Create: 活性 / Edit: 活性 / View: 非活性 | 全バリデーション後に保存 | |
+| [キャンセル] | Create / Edit モード | Create: 活性 / Edit: 活性 | 未保存変更があれば破棄確認 | |
+
+---
+
+## 2. SELECT項目定義（共通参照）
+
+- 本画面で使用する SELECT 項目の選択肢は共通定義（例: `[SELECT_ITEM_DEFINITION.md](../../../common/SELECT_ITEM_DEFINITION.md)`）を参照する。
+- 表中の「SELECT定義」列には、参照先ID（例: `S.1 業界`）を記載する。
+- 共通定義を持たない場合は、本セクションに `S.x [名称]` 単位で選択肢一覧を直接定義する。
+
+---
+
+## 3. バリデーション適用ルール  ← 下書き保存等のモードがある画面
+
+| バリデーション種別 | 説明 | Create / Edit（本登録） | 下書き保存 |
+| --- | --- | --- | --- |
+| 必須チェック | 必須条件列で「必須」と定義された項目の入力有無を検証 | ✅ 適用 | ❌ スキップ |
+| 型チェック | 型の整合性を検証 | ✅ 適用 | ✅ 適用 |
+| 桁数・文字数チェック | maxLen 等の上限値を検証 | ✅ 適用 | ✅ 適用 |
+| 形式チェック | 日付・メール等のフォーマットを検証 | ✅ 適用 | ✅ 適用 |
+| 範囲・相関チェック | From ≤ To、0–100 等を検証 | ✅ 適用 | ✅ 適用 |
+
+※ スキップされるのは必須チェックのみ。入力値が存在する場合の型・桁数・形式・範囲チェックは常に実施する。
+
+---
+
+## 4. DBスキーマ変更方針（[table]）
+
+- **1. 画面項目定義の表に記載された DBカラムを正とする**
+- 既存 DB に同一カラム名が存在する場合はそれを利用する
+- 存在しない場合は新規追加する
+- 使用されていないカラムを削除する際は、必ず開発者へ確認をとる
+- 新規追加が必要なカラムも `1. 画面項目定義` 表の DBテーブル / DBカラム に記載し（必要なら備考に「新規」と注記）、別表で再掲しない（SSoTの二重化を避ける）
+
+---
+
+## 5. 補足
+
+- 本ドキュメントは、実装・DB設計・QA における **Single Source of Truth** とする
+- （画面固有の前提: ページング方式・閲覧権限・未登録項目の表示「-」など）
+```
+
+## 重要なポイント
+
+### 記述すべき内容
+
+- 画面に存在するすべての入力項目・表示項目を網羅
+- 各項目の：必須/活性条件、デフォルト値、入力コンポーネント、制約、SELECT参照、DBマッピング（テーブル・カラム）
+- 操作モード（Create / Edit / View）がある場合はモードごとの差異
+- 操作ボタンの表示/活性条件とアクション
+- バリデーション適用ルール（特に下書き保存など必須チェックを緩めるモード）
+
+### 記述不要な内容
+
+- ユーザージャーニー・画面遷移の文脈 → REQUIREMENTS.md に記載
+- 技術設計・アーキテクチャ・実装コード → TECH_DESIGN.md に記載
+- 言語固有の型定義・実装技術に依存する記述（TS型・ORM・フレームワーク詳細）→ TECH_DESIGN.md に記載
+- DB のメタデータ詳細（インデックス・RLS 等）→ TECH_DESIGN.md に記載
+- 関数名・クラス名・ファイル行番号などのコード参照
+
+### 運用上の原則
+
+- **画面レイアウト（Excel / 画像 / WF）を正（SSoT）とし、DB スキーマは画面項目定義に追従する**
+- 本書は技術スタック非依存。言語固有の型やフレームワーク詳細は持ち込まない
+- SELECT 項目は label-only（表示文字列＝保存値）を基本とする
+- デフォルト値の表記は null で統一する
+- 共通の選択肢は SELECT 共通定義ファイルに切り出し、本書からは参照IDで指す