2026-08-09 CIの導入(Issue #7)

• 課題: PRに対してテスト・型チェック・lint・buildが自動実行されておらず、READMEのコントリビューション手順が各自の自己申告に依存していた。
• 決定: GitHub Actions(.github/workflows/ci.yml)でPRとmainへのpush時に検証コマンドを実行する。
• job分割: 単体・静的チェック(build → tsc → lint → 単体テスト)と、ローカルSupabaseを起動する統合テストを別jobにする。Supabaseの起動時間が静的チェックの結果を待たせないため。
• 実行順: tsc --noEmit はNext.jsがbuildで生成する型に依存するため、buildを先に実行する(2026-08-07の判断と同じ理由)。
• Nodeバージョン: 22 のみで実行する。package.json の engines.node と README・AGENTS.md が >=22.0.0 に揃っており(2026-08-09 の判断)、@supabase/supabase-js と関連パッケージも同じ要求を持つため、下限を1つ回せば文書・lockfile・CIが一致する。20.9 は依存関係が満たせないため外した。24 は下限の検証にならないため入れていない。
• Supabaseの起動範囲: 統合テストはREST API経由でのみDBへアクセスするため、realtime / storage / studio 等は起動しない。ただし gotrue は除外しない(除外すると supabase status がキーを返さなくなるため)。
• キーの扱い: supabase start は起動時にservice-role keyを標準出力へ表示するため、標準出力をログへ流さない。エラー時の原因究明に必要な標準エラー出力は残す。supabase status -o env の出力も変数へ取り込み、::add-mask:: でマスクしてからjobの環境変数へ渡す。ローカルSupabaseの鍵は既知の開発用値だが、「キーの値をログに表示しない」方針(AGENTS.md)を CI でも同じ形で守る。::add-mask:: は既に出力された値を遡ってマスクできないため、出さないことが先で、マスクは後段の保険という順序になる。
• Supabase CLI のバージョン: latest のままとする。固定すれば再現性は上がるが、更新追従のPRを継続的に出す運用コストが先に立つ。出力形式の変更でCIが壊れた時点で、検証済みバージョンへの固定を別PRで導入する。
• シークレット設定: CIはローカルSupabaseのみを使い、本番環境へは接続しない。リポジトリのSecrets設定は不要。
• 含めないもの: デプロイの自動化(本番デプロイは延期中)、カバレッジ閾値の強制。