SPEC ベース開発

- id: REQ-001
  type: ubiquitous
  priority: HIGH
  text: "システムはすべてのユーザー入力を検証しなければならない"
  acceptance_criteria:
    - "すべての入力値に対して型検証を実行"
    - "SQL Injection 防止のためパラメータ化クエリを使用"
    - "XSS 防止のため出力エスケープを実施"

- id: REQ-002
  type: event-driven
  priority: HIGH
  text: |
    WHEN ユーザーがログインボタンをクリックすると、
    IF メールアドレスとパスワードが有効なら、
    THEN JWT トークンを発行しダッシュボードにリダイレクトしなければならない
  acceptance_criteria:
    - given: "登録済みのユーザーアカウントがあり"
      when: "正しいメールアドレスとパスワードでログインすると"
      then: "200 レスポンスとともに JWT トークンを発行"
      and: "トークンの有効期限は 1 時間"

- id: REQ-003
  type: state-driven
  priority: MEDIUM
  text: |
    WHILE ユーザーがログイン状態の間、
    システムはセッションを 5 分ごとに更新しなければならない
  acceptance_criteria:
    - "最後のアクティビティから 5 分経過時に自動更新"
    - "セッション期限切れの 5 分前に通知を表示"
    - "30 分間無操作時に自動ログアウト"

- id: REQ-004
  type: unwanted
  priority: CRITICAL
  text: "システムはパスワードを平文で保存してはならない"
  acceptance_criteria:
    - "パスワードは bcrypt でハッシュ化 (cost factor 12)"
    - "ハッシュ化されていないパスワードがログに含まれないこと"
    - "データベースに平文パスワードを保存不可"
 
- id: REQ-005
  type: unwanted
  priority: CRITICAL
  text: "システムはハードコードされた秘密鍵を使用してはならない"
  acceptance_criteria:
    - "すべての秘密鍵は環境変数またはシークレットマネージャーを使用"
    - "コードに秘密鍵を含めないこと"
    - "Git コミットに秘密鍵が含まれることを防止"

- id: REQ-006
  type: optional
  priority: LOW
  text: "可能であれば、システムはログイン時にメール通知を送信すべきである"
  acceptance_criteria:
    - "メールサーバーが設定されている場合のみ動作"
    - "通知を無効にするオプションを提供"

---
id: SPEC-AUTH-001               # 一意識別子
title: ユーザー認証システム       # 明確で簡潔なタイトル
priority: HIGH                  # HIGH, MEDIUM, LOW
status: ACTIVE                  # DRAFT, ACTIVE, IN_PROGRESS, COMPLETED
created: 2025-01-12             # 作成日
updated: 2025-01-12             # 最終更新日
author: 開発チーム               # 作成者
version: 1.0.0                  # ドキュメントバージョン
---
 
# ユーザー認証システム
 
## 概要
JWT ベースのユーザー認証システムを実装
 
## 要件
### Ubiquitous
- システムはすべての API リクエストに認証を要求しなければならない
 
### Event-driven
- WHEN ユーザーがログインすると、THEN JWT を発行しなければならない
 
### Unwanted
- システムはパスワードを平文で保存してはならない
 
## 制約条件
- API レスポンス時間 500ms 以内
- パスワード bcrypt ハッシュ化 (cost factor 12)
 
## 依存関係
- Redis (セッション管理)
- PostgreSQL (ユーザーデータ)

# 実装計画
 
## タスク分解
1. ユーザーモデルおよびマイグレーション作成
2. JWT トークン発行/検証ユーティリティ実装
3. ログイン/会員登録 API エンドポイント実装
4. 認証ミドルウェア実装
5. Refresh Token 更新ロジック実装
 
## 技術スタック
- Go 1.23 + Fiber v2
- PostgreSQL 16 + GORM
- Redis 7 (セッション/トークン保存)
 
## リスク分析
| リスク | 影響 | 緩和戦略 |
| --- | --- | --- |
| トークン窃取 | HIGH | Refresh Token ローテーション、HttpOnly Cookie |
| ブルートフォース | MEDIUM | Rate Limiting、アカウントロック |

# 受入基準
 
## シナリオ
 
### AC-01: 正常ログイン
- **Given** 登録済みのユーザーアカウントがあり
- **When** 正しいメールアドレスとパスワードでログインすると
- **Then** 200 レスポンスと JWT トークンセットを返却
 
### AC-02: 不正な資格情報
- **Given** 登録済みのユーザーアカウントがあり
- **When** 間違ったパスワードでログインすると
- **Then** 401 レスポンスと一般的なエラーメッセージを返却
 
## エッジケース
- 期限切れの Refresh Token での更新時に 401 レスポンス
- 同時ログイン制限を超過した場合、最も古いセッションを期限切れにする
 
## 品質ゲート
- API レスポンス時間: 500ms 以内 (P95)
- テストカバレッジ: 85% 以上

# SPEC 作成コマンド
> /moai plan "ユーザー認証機能の実装"

.moai/
└── specs/
    ├── SPEC-AUTH-001/
    │   ├── spec.md          # EARS 要件
    │   ├── plan.md          # 実装計画
    │   └── acceptance.md    # 受入基準
    ├── SPEC-PAYMENT-001/
    │   ├── spec.md
    │   ├── plan.md
    │   └── acceptance.md
    └── SPEC-SEARCH-001/
        ├── spec.md
        ├── plan.md
        └── acceptance.md

# SPEC 作成
> /moai plan "JWT ベースのユーザー認証システム。ログイン、会員登録、トークン更新機能を含む"

---
id: SPEC-AUTH-001
title: JWT ベースのユーザー認証システム
priority: HIGH
status: ACTIVE
created: 2025-01-15
version: 1.0.0
---
 
# JWT ベースのユーザー認証システム
 
## 概要
JWT トークンを使用したユーザー認証システム。
ログイン、会員登録、トークン更新機能を実装する。
 
## 要件
 
### Ubiquitous
- REQ-U01: システムはすべての認証トークンを HTTPS でのみ送信しなければならない
- REQ-U02: システムはすべてのユーザー入力を検証しなければならない
 
### Event-driven
- REQ-E01: WHEN ユーザーが会員登録フォームを送信すると、
  IF メールアドレスが重複していなければ、
  THEN アカウントを作成しウェルカムメールを送信しなければならない
- REQ-E02: WHEN ユーザーがログインすると、
  IF 資格情報が有効なら、
  THEN Access Token (1 時間) と Refresh Token (7 日) を発行しなければならない
 
### Unwanted
- REQ-N01: システムはパスワードを平文で保存してはならない
- REQ-N02: システムは期限切れの Refresh Token で新しいトークンを発行してはならない
 
### Optional
- REQ-O01: 可能であれば、ソーシャルログイン (Google、GitHub) をサポートすべきである
 
## 制約条件
- パスワード: bcrypt (cost factor 12)
- Access Token 有効期限: 1 時間
- Refresh Token 有効期限: 7 日
- API レスポンス時間: 500ms 以内 (P95)

# 実装計画
 
## タスク分解
1. ユーザーモデルおよび DB マイグレーション作成
2. パスワードハッシュ化ユーティリティ実装
3. JWT トークン発行/検証ユーティリティ実装
4. 会員登録 API エンドポイント実装
5. ログイン API エンドポイント実装
6. 認証ミドルウェア実装
7. Refresh Token 更新ロジック実装
 
## 技術スタック
- Go 1.23 + Fiber v2
- PostgreSQL 16 + GORM
- Redis 7 (Refresh Token 保存)
 
## リスク分析
| リスク | 影響 | 緩和戦略 |
| --- | --- | --- |
| トークン窃取 | HIGH | Refresh Token ローテーション、HttpOnly Cookie |
| ブルートフォース | MEDIUM | Rate Limiting、アカウントロック |

# 受入基準
 
## シナリオ
 
### AC-01: 正常ログイン
- **Given** 登録済みのユーザーアカウントがあり
- **When** 正しいメールアドレスとパスワードでログインすると
- **Then** 200 レスポンスと JWT トークンセット (Access + Refresh) を返却
 
### AC-02: 不正なパスワード
- **Given** 登録済みのユーザーアカウントがあり
- **When** 間違ったパスワードでログインすると
- **Then** 401 レスポンス
 
### AC-03: 重複会員登録
- **Given** すでに登録済みのメールアドレスがあり
- **When** 同じメールアドレスで会員登録すると
- **Then** 409 レスポンス
 
### AC-04: トークン更新
- **Given** 有効な Refresh Token があり
- **When** トークン更新をリクエストすると
- **Then** 新しい Access Token を返却
 
## 品質ゲート
- API レスポンス時間: 500ms 以内 (P95)
- テストカバレッジ: 85% 以上

# SPEC 確認後に実装開始
> /moai run SPEC-AUTH-001