検証の 4 層
変更を main に ship する前に、コンパイルが通ること以上の確認をします。Astar では検証を 4 つの層（L1〜L4）に分け、変更の種類に応じてどこまで検証するかを決めます。
ピラミッド
| 層 | 何を確認するか | 主な手段 |
|---|---|---|
| L1 | 静的チェック（typecheck・lint・compile） | nuxt typecheck / eslint / ./gradlew compileKotlin |
| L2 | 対象を絞った単体テスト | vitest（変更ファイル関連のみ）/ backend unit test |
| L3 | コンポーネントの見た目 | /__dev/* 固定モックプレビュー |
| L4 | 結合（API・E2E） | backend integration test / 実際の API 疎通確認 |
すべての変更で全層を回す必要はありません。変更の種類ごとの目安:
| 変更の種類 | 必要な層 |
|---|---|
.vue ファイル | L1 + L2 + L3 |
frontend .ts（コンポーネント以外） | L1 + L2 |
| backend service / model | L1 + L2 |
| backend controller / DTO / migration | L1 + L2 + L4 |
| フルスタックの変更 | L1 + L2 + L3 + L4 |
/verify skill がこの判定と実行を助けます。.claude/skills/verify/verify.sh が変更ファイルを検出し、L1・L2 を自動実行、L3・L4 が必要かどうかと実行方法を提示します。
backend テストは /backend-test-reports skill 経由だけ
./gradlew test を直接叩くことはできません（settings.json で deny）。 backend のテストを実行・確認する唯一の経路は /backend-test-reports skill です。
.claude/skills/backend-test-reports/test.sh run --unit
.claude/skills/backend-test-reports/test.sh run --integration --module table
.claude/skills/backend-test-reports/test.sh run --tests "*RoleControllerAuthorizationTest*"
backend のテストにはクラス名のサフィックスによる区分があります。
| タスク | 対象 |
|---|---|
unitTest | @Tag("unit") かつ *ArchitectureTest|*GuardTest|*BoundaryTest|*SnapshotTest|*CoverageTest|*ContractTest|*ParityTest 以外 |
guardTest | 上記 7 サフィックスちょうど（ArchUnit ベース。共有 import cache のため 4g heap が必要） |
integrationTest | IntegrationTestBase を継承する結合テスト |
prTest | PR フィードバックを 10 分以内に収めるための厳選サブセット（DB 不要の安全ガード・wire contract・i18n 整合性など） |
PR は prTest + integrationGuardTest（RLS/authz の DB レベルパリティゲート）を実行します。unitTest / guardTest / integrationTest のフルセットは main push 時・夜間・手動実行のタイミングです。
main ブランチには既知の red（自分が触っていないなら直す対象ではないテスト失敗）があります。unit で 6 クラスにまたがる 27 件、integration で 8 クラスにまたがる 14 件（RLS 分離テスト含む）などです。自分の変更と無関係な失敗に遭遇したら、まず /backend-test-reports の結果とその変更範囲を見比べて、pre-existing red かどうかを確認してください。
L3 — 見た目の検証は /__dev/* 固定プレビューのみ
ライブアプリを Playwright で操作するループ（ログイン → 画面遷移 → クリック → ドラッグ&ドロップ試行）は検証手段として使いません。 対象コンポーネントを state ごと（空・データあり・編集不可・エラーなど）に固定モックで /__dev/* route に並べ、各 state をスクリーンショットして目視確認します。機能面の保証は L1/L2 が担い、操作感（ドラッグの手応え・リサイズ・hover）は人間が確認する領分です。新規コンポーネントや大きく手を入れたコンポーネントは実装と同時に /__dev プレビューページも用意します。
frontend の静的検証コマンドは次の組み合わせです。
bun run typecheck
npx eslint --no-fix <changed-paths>
bun run test
bun run lint は eslint . --fix をリポジトリ全体に対して実行し、対象ファイル引数を無視します。検証目的では絶対に使わないでください — 無関係なファイルを黙って書き換えます。検証には npx eslint --no-fix <対象パス> を使います。
Storybook（既存 25 story）は後方互換のためだけに残っています。新規コンポーネントに新しい story を追加することはありません — /__dev プレビューが標準です。
L4 — 結合検証
API やマイグレーションを変更した場合は、backend integration test に加えて、実際に動いている backend/frontend に対して API 疎通を確認します。TestContainers が DB を自動で用意するので、integration test 自体は並行セッションと衝突しません。
検証結果の書式
検証が終わったら、次の形式で結果を残します（コミットメッセージに含めるのが慣習です）。
Verified: L1(pass) L2(unit:12/12,backend:5/5) L3(visual:pass) L4(integration:8/8)
次は backend/frontend それぞれの規約へ
このページはリポジトリ横断の検証の仕組みを扱いました。backend 固有のテストの書き方（命名規則・IntegrationTestBase の使い方・RLS テストパターンなど）は backend のテスト規約 を参照してください。