開発
コントリビューションガイド
BluePeriodへの開発参加に必要な情報。規約、フロー、レビュー体制、並列開発
コントリビューションガイド
本ドキュメントは、BluePeriodへの開発参加に必要な情報をまとめています。概要はリポジトリルートの CONTRIBUTING.md を参照してください。
アーキテクチャ概要
BluePeriodはモノレポ構成です:
next-app/— Next.js (App Router) Webアプリケーションtauri-app/— Tauri V2 デスクトップアプリ（Rust）astro/— ランディングページfumadocs/— ドキュメントサイト
詳細は 01_architecture と 02_technology_stack を参照してください。
コーディング規約
基本方針
- 提出前に
bun all:checkを実行してください（全サブプロジェクトのTypeScript型チェック + Biome） - 06_development_guidelines の規約に従ってください
- shadcn/ui コンポーネントをベースUIライブラリとして使用します
- 状態管理は Jotai を使用し、ドメインごとにAtomを分離します
- UI変更時は 09_design_system のセマンティックトークンを使用してください
命名規則
| 項目 | 規約 |
|---|---|
| 変数・関数 | camelCase |
| Reactコンポーネント | PascalCase |
| 型・インターフェース | PascalCase |
| コンポーネントファイル | PascalCase.tsx |
| それ以外のファイル | kebab-case.ts |
ブランチ戦略
GitHub Flowを採用しています:
devが主開発ブランチ（すべてのPRはdevをターゲットにする）- フィーチャーブランチ:
feat/short-description - 修正ブランチ:
fix/short-description - 定期的に
devからrebaseしてください
コミット規約
Conventional Commits に従います:
type(scope): descriptionTypes: feat, fix, docs, style, refactor, perf, test, chore, fuma
詳細は 08_git_commit_conventions を参照してください。
貢献フロー
小規模な変更（バグ修正・タイポ・ドキュメント修正）
- リポジトリをForkする
- ブランチを作成:
fix/short-descriptionまたはdocs/short-description - 変更を加える
- PRを提出（PRテンプレートに従う）
- CIが通ることを確認
- メンテナーがReview → Merge
大規模な変更（新機能・アーキテクチャ変更）
- 事前のGitHub Issueでの議論を推奨 — 実装後に方向転換が必要になるリスクを減らせます
- リポジトリをForkする
- ブランチを作成:
feat/short-description - 変更を加える
- PRを提出:
- Summaryで設計意図を明確に説明
- 関連Issueがあればリンク
- 大きな変更はインクリメンタルに分割することを推奨
- CIが通ることを確認
- メンテナーがReview → Merge
DDDドキュメント（推奨）
BluePeriodでは内部開発に Issue → Plan → 実装 → Report のDDDサイクルを採用しています。基本的には doc/log/ に設計ドキュメントを含めることを推奨します。
詳細は document_driven_development を参照してください。
レビュー体制
メンテナーによるReview
メンテナーはAIツール（Claude Code、Cursor等）を使ってPRをReviewします。gh pr diff で差分を取得し、プロジェクト規約・セキュリティ観点でReviewします。
レビュー観点
詳細は pr-review-guide を参照してください。主な観点:
- スコープの整合性: PRのSummaryに書かれていない実装が含まれていないか
- 規約への準拠: ガイドラインとデザインシステムに沿っているか
- セキュリティ: 不審なパターンがないか
- 品質: 型の使用、エラーハンドリング、ローディングUI
自己レビューの推奨
PR提出前にAIツール（Claude Code、Cursor等）による自己レビューを推奨します。
並列開発
複数のコントリビューターが feat/ ブランチで並列開発する際:
- スコープの宣言: PRのSummaryに変更対象ファイル・ディレクトリを明記してください
- インクリメンタルマージ: 大きな機能は独立して動く単位で分割してください
- ブランチ寿命の短縮: 実装開始から1週間以内にPRを出すことを目安にしてください
- 定期的なrebase:
devからのrebaseを推奨します