検証の 4 層
変更を main に ship する前に、コンパイルが通ること以上の確認をします。Astar では検証を 4 つの層（L1〜L4）に分け、変更の種類に応じてどこまで検証するかを決めます。
ピラミッド
| 層 | 何を確認するか | 主な手段 |
|---|---|---|
| L1 | 静的チェック（typecheck・lint・compile） | bun run typecheck:modules / bun run lint:modules / ./gradlew compileKotlin |
| L2 | 対象を絞った単体テスト | bun run test:modules（変更 layer + downstream）/ backend unit test |
| L3 | コンポーネントの見た目 | /__preview 固定モックプレビュー |
| 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 |
判定は自分でします。入口は3つだけです（2026-08-27 に /verify・/frontend-verify・/system-verify を廃止）:
| 層 | 入口 |
|---|---|
| L1（frontend） | lane で変更 layer に対する scoped lint・typecheck の 2 本（lane はテストを回さない） |
| L1（backend） | lane で changed-module compile のみ（lane はテストを回さない） |
| L3（見た目） | /frontend-design（/__preview と visual-review-checklist） |
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 整合性など） |
main push の backend-ci guard は変更モジュールの compile だけを実行します。unit・guard・Testcontainers を使う integration はどれも PR や push では実行せず、夜間（と手動 dispatch）に全 project で回します（docs/decisions/2026-10-03-test-policy-lanes-compile-only.md）。lane はテストを一切回さず、compile だけの local check を済ませたら PR を Ready にし、CI の完了を待ちません。
main ブランチには既知の red（自分が触っていないなら直す対象ではないテスト失敗）があります。unit で 6 クラスにまたがる 27 件、integration で 8 クラスにまたがる 14 件（RLS 分離テスト含む）などです。自分の変更と無関係な失敗に遭遇したら、まず /backend-test-reports の結果とその変更範囲を見比べて、pre-existing red かどうかを確認してください。
L3 — 見た目の検証
ライブアプリを Playwright で操作するループ（ログイン → 画面遷移 → クリック → ドラッグ&ドロップ試行）は検証手段として使いません。 固定状態の面は /__preview の1本だけで、ケースはコンポーネントの隣に置く *.preview.ts が宣言します（書き方は frontend/app/shared/preview/README.md、全ケース×state の走査は bun run preview:sweep）。機能面の保証は L1/L2 が担い、操作感（ドラッグの手応え・リサイズ・hover）は人間が確認する領分です。
⚠ 実装後に確認用プレビュー面を作る義務はありません（施主指示 2026-08-23）。「新規・大改造した UI は固定状態プレビューを同梱する」という旧規約は廃止済みで、ケースの新規作成は「それが無いと確認できない」ときだけです。施主に見た目を見せる既定は実装前の Visual Proposal で、実装後に実物を見る必要が出たら /__preview の既存ケースか実アプリを開きます。SSoT は frontend/AGENTS.md。
frontend の lane 検証は、lint は変更ファイル、typecheck は変更 layer と downstream を回す組み合わせです（#3989）。lane はテストを一切回しません（docs/decisions/2026-10-03-test-policy-lanes-compile-only.md）。lane のローカル検証は compile 相当のこの 2 本だけです。app-wide typecheck/build と test:modules は main push の guard・nightly で非同期に実行します。
bun run typecheck:modules
bun run lint:modules
2本とも origin/main マージベース差分＋作業ツリーの変更から対象を自動検出します（frontend/scripts/module-scope.ts が判定ロジックの共有元）。typecheck:modules は対象 layer + その downstream、lint:modules は変更ファイルだけを回します。app/shared・app/foundation の変更は "foundation" 扱いになり、変更ファイル自身だけを対象にして他 layer への波及は CI に委ねます（--all-downstream で強制可能）。挙動だけ確認したいときは --dry-run を付けます。
bun run lint は eslint . --fix をリポジトリ全体に対して実行し、対象ファイル引数を無視します。検証目的では絶対に使わないでください — 無関係なファイルを黙って書き換えます。lane の local check には bun run lint:modules（変更ファイルのみ）と scoped typecheck を使います。bun run test / bun run test:modules（vitest）や app-wide bun run typecheck は lane のローカル検証では使いません。
⚠ /__dev と Storybook は 2026-08-24 に退役しました（施主指示「全部捨てよう」）。*.stories.ts と app/pages/__dev/** はリポジトリにゼロ件で、番人 preview-surface-is-single.guard.test.ts がそれを守っています。
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 のテスト規約 を参照してください。