コード品質チェック
最近作成されたコードの包括的な品質検証。仕様準拠、クロスレイヤーの安全性、コミット前チェックを組み合わせます。
ステップ 1: 変更内容を特定
git diff --name-only HEAD
git status
ステップ 2: タスク成果物と該当仕様を読み込む
現在のタスク成果物を順に読み込みます：
prd.mddesign.md（存在する場合）implement.md（存在する場合）
python3 ./.trellis/scripts/get_context.py --mode packages
変更されたパッケージ/レイヤーごとに、仕様インデックスを読み込み、その品質チェックセクションに従います：
cat .trellis/spec/<package>/<layer>/index.md
参照されている特定のガイドラインファイルを読み込みます。インデックスは単なるポインタであり、目的そのものではありません。
ステップ 3: プロジェクトチェックを実行
プロジェクトのリンター、型チェック、テストコマンドを実行します。失敗箇所があれば修正してから先に進みます。
ステップ 4: チェックリストに照らして確認
コード品質
- リンターはパスするか？
- 型チェッカーはパスするか（該当する場合）？
- テストはパスするか？
- デバッグログが残っていないか？
- 抑制された警告や型安全性のバイパスはないか？
テストカバレッジ
- 新しい関数がある → 単体テストは追加されたか？
- バグ修正をした → 回帰テストは追加されたか？
- 動作を変更した → 既存のテストは更新されたか？
仕様同期
-
.trellis/spec/の更新が必要か？（新しいパターン、規約、学んだ教訓）
「バグを修正したり、自明でないことを発見した場合、将来同じ問題に直面しないように文書化すべきか？」→ YESの場合は、関連する仕様ドキュメントを更新します。
スコープ規律
- タスクで必要とされなかったコードの整理をしていないか？
- まだ存在しないユースケースのために抽象化、設定、拡張ポイントを追加していないか？
- 発生し得ない状態に対する推測によるフォールバックを追加していないか？
- 受け入れ基準に記載されていないファイルを変更していないか？
- 実際の動作が存在する場所ではなく、呼び出し元で回避策を追加していないか？
ステップ 5: クロスレイヤー次元（該当する場合）
変更が単一レイヤーに限定されている場合は、このステップをスキップします。
A. データフロー（変更が3つ以上のレイヤーにまたがる場合）
- 読み取りフローが正しくトレースされるか：ストレージ → サービス → API → UI
- 書き込みフローが正しくトレースされるか：UI → API → サービス → ストレージ
- 型/スキーマがレイヤー間で正しく受け渡されているか？
- エラーが呼び出し元に適切に伝播されているか？
B. コード再利用（定数の変更、ユーティリティの作成）
- 新しいコードを作成する前に、既存の類似コードを検索したか？
grep -r "pattern" src/ - 同じ値が繰り返される場合、それは呼び出し元が一緒に変更しなければならない安定した単一の概念を表しているか？その場合にのみ抽出します。単に今日たまたま一致している2つのリテラルは分離したままにすべきです。
- 一括変更後、すべての出現箇所が更新されたか？
C. インポート/依存（新しいファイルを作成する場合）
- インポートパスは正しいか（相対 vs 絶対）？
- 循環依存はないか？
D. 同一レイヤー内の一貫性
- 同じ概念を使用している他の場所と一貫性があるか？
ステップ 6: 報告と修正
見つけたすべての違反を報告します。その後：
- 機械的で局所的なもの（リントの細かい指摘、型の欠落、誤ったインポート、デッドブランチ、失敗するアサーション）→ その場で修正し、プロジェクトチェックを再実行します。
- 設計や判断に関するもの（共有概念の命名、モジュール境界の移動、パブリックインターフェースの変更、動作の割り当て場所の変更）→ 証拠と推奨事項を記録して停止します。黙って書き換えてはいけません。
修正が現在のタスクの範囲外のファイルに及ぶ場合は、その旨を伝えて、変更を広げずに停止します。