開発
PRレビューガイド
メンテナー向けのPRレビュー観点・セキュリティチェック・ワークフロー
PRレビューガイド
本ドキュメントは、BluePeriodのメンテナーがPRをレビューする際の基準とワークフローを定義します。
レビューワークフロー
メンテナーはAIを使ってPRをReviewすることができます。
gh pr diff {番号}差分を取得し、プロジェクト規約・セキュリティ観点でReviewします。
レビュー観点
1. スコープの整合性
- PRのSummaryに書かれていない実装が含まれていないか
- 関連IssueやPlanがある場合、その範囲内に収まっているか
- スコープクリープ（関係ない修正の混入）がないか
2. 規約への準拠
- 06_development_guidelines のコーディング規約に従っているか
- 09_design_system のセマンティックトークンを使用しているか（ハードコードされた色やスペースがないか）
- 命名規則（
camelCase,PascalCase,kebab-case）が正しいか - Jotai Atomに
...Atom接尾辞がついているか - i18n対応が必要な箇所でハードコードされたテキストがないか
3. アーキテクチャの整合性
- 01_architecture のBFF/BYOKパターンに沿っているか
- Service Layerが適切に分離されているか（APIハンドラにビジネスロジックがないか）
- 状態管理（Jotai）のスコープが最小限か
4. セキュリティチェック
以下のパターンを確認:
| パターン | 確認内容 |
|---|---|
eval(), Function(), new Function() | 意図が不明な場合は拒否 |
| 文字列操作 | Unicodeエスケープ、ゼロ幅文字の不自然な使用がないか |
| 外部リクエスト | 不可解なドメインへのリクエストや依存の追加がないか |
| セキュリティ機構 | 既存の認証・認可の無効化がないか |
| 難読化 | コードが人間の目で読めるか |
| 機密情報 | APIキー、トークン、.envの内容が含まれていないか |
| 依存関係 | 新規パッケージが信頼できる出所か。GPL等のコピーレフトでないか |
5. 品質
- TypeScriptの型が適切に使われているか（
anyの乱用がないか） - エラーハンドリングが漏れていないか
- ローディング状態のUIが実装されているか（Skeleton推奨）
- 不要なコメントやデバッグコードが残っていないか
レビュー結果の分類
| 判定 | 条件 |
|---|---|
| Approve | CI通過 + レビュー観点を満たす |
| Request Changes | セキュリティ問題、規約違反、スコープ外の変更がある |
| Comment | 軽微な改善提案。マージをブロックしない |
CIの判定基準
CIはdorny/paths-filterによるpath-based条件付き実行を採用しています:
| 変更対象 | 実行されるCheck |
|---|---|
next-app/** | bun next:check → bun next:build |
fumadocs/** | bun fuma:check → bun fuma:build |
astro/** | bun astro:check |
tauri-app/** | bun tauri:check（cargo check） |
package.json / bun.lockb | 該当するすべてのCheck |
CIが通っていることを第一段階の品質判断に使い、その上で上記のレビュー観点で確認します。
貢献者へのフィードバック
- 具体的な指摘と改善案をセットで伝える
- セキュリティ上の指摘は理由を必ず添える
- 初回コントリビューターには歓迎のトーンを心がける