ProjectELU 憲章
コア原則
I. ドキュメントファースト開発
すべての機能は、実装コードが書かれる前に明確なドキュメントから始まる必要があります。
要件:
- 機能仕様はコーディングが始まる前に作成され承認される必要があります
- API 契約とデータモデルは設計成果物で文書化される必要があります
- ユーザー向けの変更には、成果物の一部として更新されたドキュメントが含まれる必要があります
- コードコメントは補足的です。主要なドキュメントは専用ファイルに存在します
根拠: ドキュメントファーストは共通理解を保証し、手戻りを減らし、意図が実装と共に保存される保守可能なシステムを作成します。
II. モジュラーアーキテクチャとシンプルさ
コードは、最小限の複雑性の原則に従う、結合度の低いモジュールに編成される必要があります。
要件:
- 各モジュールは単一の明確に定義された責任を持つ必要があります
- モジュール間の依存関係は明示的で最小限である必要があります
- 新しい抽象化は具体的なユースケースで複雑性を正当化する必要があります（YAGNI）
- 継承よりも合成を優先し、賢いソリューションよりもシンプルなソリューションを優先
根拠: モジュラー設計は独立したテスト、並列開発、そしてより簡単な保守を可能にします。シンプルさは認知負荷と欠陥率を減らします。
III. テストによる品質保証
コード品質は、適切なレベルでの自動テストによって検証される必要があります。
要件:
- 公開インターフェースには期待される動作を検証する契約テストが必要です
- 統合ポイントは正しいデータフローとエラーハンドリングのためにテストされる必要があります
- テストカバレッジはクリティカルパスとユーザー向け機能を優先する必要があります
- テストは決定論的で、独立していて、頻繁な実行に十分速い必要があります
根拠: 自動テストはリグレッションを早期に検出し、期待される動作を文書化し、自信を持ったリファクタリングを可能にします。
開発基準
ユーザー体験重視
すべての機能はエンドユーザーを念頭に置いて設計される必要があります。
要件:
- ユーザーシナリオは技術設計が始まる前に定義される必要があります
- エラーメッセージは実行可能でユーザーフレンドリーである必要があります
- パフォーマンスは対象ユースケースに対して受け入れ可能である必要があります
- アクセシビリティとユーザビリティは設計決定で考慮される必要があります
コード品質
すべてのコードはマージ前に最低品質基準を満たす必要があります。
要件:
- コードはプロジェクトのスタイルガイドラインに従い、Lint を通過する必要があります
- 関数は明確な入力、出力、副作用を持つ必要があります
- エラーハンドリングは明示的で一貫性がある必要があります
- マジックナンバーとハードコードされた値は避ける必要があります
品質ゲート
実装前ゲート
コーディングが始まる前に、以下が完了している必要があります:
マージ前ゲート
コードがマージされる前に、以下が合格する必要があります:
ガバナンス
改訂プロセス
- 提案された変更は根拠と共に文書化される必要があります
- 変更は既存のプラクティスへの影響がレビューされる必要があります
- バージョンはセマンティックバージョニングに従ってインクリメントされる必要があります:
- MAJOR: 原則の削除または非互換な再定義
- MINOR: 新しい原則または実質的な拡張
- PATCH: 明確化または非意味論的な改善
- すべての依存テンプレートは一貫性を維持するために更新される必要があります
コンプライアンス
- すべてのプルリクエストは適用可能な原則への準拠を検証する必要があります
- 違反は複雑性追跡セクションで文書化され正当化される必要があります
- 定期的なレビューは、プラクティスが述べられた原則と一致しているかを評価するべきです
バージョン: 1.0.0 | 承認日: 2026-02-05 | 最終改訂: 2026-02-05