コンプライアンスのためのPRレビュー（SOC2、HIPAA）

@kody remember: 私たちはSOC2準拠です。すべてのデータアクセスは、
誰が何を、いつ、どこからアクセスしたかを記録する必要があります。

@kody remember: PII（個人識別情報）はログ、エラーメッセージ、
またはAPIレスポンスに絶対に表示されてはなりません。PIIには以下が含まれます：
氏名、メールアドレス、電話番号、住所、SSN、生年月日、IPアドレス。

@kody remember: 保存されているすべてのデータは暗号化される必要があります。
PIIを含むデータベースフィールドはアプリケーションレベルの暗号化を使用する必要があります。

@kody remember: アクセス制御は最小権限の原則に従います。
新しいエンドポイントのデフォルトは「認証済み + 承認済み」であり、パブリックではありません。

Name: データの変更には監査ロギングが必要
Scope: File
Paths: src/services/**/*.ts, src/repositories/**/*.ts
Severity: Critical
Instructions:
  fileDiffにユーザーデータまたは機密レコードに対する
  作成、更新、または削除操作が含まれている場合、
  監査ログエントリが作成されていることを確認する。
  auditService.log()、AuditLogger、または @Audited デコレータへの
  呼び出しを探す。
  承認された監査パターンについては
  @file:src/shared/audit/audit.service.ts を参照する。

Name: ユーザーデータにはソフトデリートが必要
Scope: File
Paths: src/**/*.ts
Severity: Critical
Instructions:
  ユーザーデータを含むテーブル/コレクションに対する
  ハードデリート（DELETE FROM、.delete()、.destroy()）に
  フラグを立てる。
  ユーザーデータはデータ保持ポリシーに準拠するために
  ソフトデリート（deletedAtタイムスタンプ）を使用する必要がある。

Name: ログまたはエラーレスポンスにPIIは禁止
Scope: File
Paths: src/**/*.ts
Severity: Critical
Instructions:
  fileDiffでPIIフィールドを含む可能性があるロギングステートメント
  （logger.*、console.*）とエラーレスポンスビルダーを確認する：
  email、name、phone、address、ssn、dateOfBirth、ipAddress。
  これらはログ/レスポンス前にリダクションまたは除外される必要がある。

Name: PIIフィールドには暗号化ヘルパーが必要
Scope: File
Paths: src/entities/**/*.ts, src/models/**/*.ts
Severity: Critical
Instructions:
  fileDiffがPIIを含むエンティティ/モデルフィールドを
  追加または変更する場合（上記リスト参照）、
  @Encrypted デコレータまたは encryptionService ヘルパーを
  使用していることを確認する。
  @file:src/shared/encryption/encryption.service.ts を参照する。

Name: 新しいエンドポイントには認証ガードが必要
Scope: Pull Request
Severity: Critical
Instructions:
  pr_files_diffで新しいルート定義またはコントローラーメソッドを確認する。
  すべての新しいエンドポイントには以下が必要：
  1. 認証ガード（@UseGuards(AuthGuard)）
  2. 認可デコレータ（@Roles または @Permissions）
  3. レート制限（@Throttle または同等）
  エンドポイントが意図的にパブリックである場合は、
  明示的な @Public() デコレータと理由を説明するコードコメントが必要。

Name: コンプライアンスへの影響評価
Scope: Pull Request
Severity: High
Instructions:
  pr_files_diffが src/entities/、src/models/、
  またはデータベースマイグレーション内のファイルに触れる場合、
  以下を確認する：
  1. PIIを扱う新しいフィールドが文書化されているか
  2. データフローの変更がpr_descriptionに記載されているか
  3. プライバシーへの影響が考慮されているか
  PRが新しいデータ収集を追加する場合は、
  プライバシーレビューのためにフラグを立てる。