/check [システム名] — システム退化チェック

引数: [system-name] （省略可。例: scale-base, scale-lead, scale-fs, scale-pm）

過去FB対応済み機能が消えてないか・本番がちゃんと動いてるか・退化してないかを機械的に検証する。

実行手順

Step 0: システム自動判定（引数省略時）

引数なしの場合、直近の会話から検証対象を自動判定:

判定の手がかり:
1. 直近の編集ファイルパス
2. 言及されたシステム名・本番URL
3. 直前のBashコマンドのcwd
4. デプロイ実施済みシステム

判定したら:

🎯 自動判定: scale-lead （理由: 直近で deploy.sh を実行）

判定不能時のみ「どのシステム？」と聞く。

Step 1: システム特定 → ローカルパス特定

Step 2: 自動チェックスクリプト実行（あれば）

# scripts/check-current-state.sh が存在すれば実行
~/Obsidian/scripts/check_deployment.sh <システム名>

Step 3: マニュアル退化チェック5項目

① 最新基準点ファイル一致確認

# Vault最新基準点ノートの「最新changelogスタンプ」を読む
cat ~/Obsidian/SCALE-Brain/31_システム開発部/_SCALE_<システム>_最新基準点.md | grep "最新changelog"

# ローカルchangelog.tsの最上段と比較
grep -m 1 "id: 'ce-" <ローカルパス>/lib/changelog.ts
grep -m 1 "date: " <ローカルパス>/lib/changelog.ts

→ Vault stamp とローカル date が一致 = OK
→ ローカル date が古い = 退化検知

② 必須ファイル存在確認

Vault の「保護資産リスト」を読み、すべて存在するか確認:

ls <ローカルパス>/<必須ファイル1>
ls <ローカルパス>/<必須ファイル2>
...

③ 関数grep確認

保護資産リストの「絶対消さない関数」リストを grep:

grep -l "function <重要関数1>" <ローカルパス>/
grep -l "<重要パターン>" <ローカルパス>/

④ 本番URL HTTP 200 確認

curl -I -s -o /dev/null -w "%{http_code}\n" <本番URL>

→ 200 = OK / 404 or 5xx = 退化

⑤ ローカル → 本番 デプロイ差分確認

git status / git log で最近のデプロイ状況確認

Step 4: 結果レポート

🔍 退化チェック結果: <システム名>

✅ 最新基準点一致
   - Vault: ce-2026-MM-DD-XX
   - ローカル: ce-2026-MM-DD-XX (一致)

✅ 必須ファイル: 12/12 存在
   - lib/changelog.ts ✓
   - src/components/Header.tsx ✓
   - ...

✅ 関数grep: 8/8 存在
   - handleSubmit ✓
   - validateInput ✓
   - ...

✅ 本番URL: HTTP 200
   - https://scale-base.pages.dev/home/

✅ デプロイ状況: 最新コミット 2026-MM-DD HH:MM

🟢 退化なし。安全に作業継続可能。

Step 5: 退化検知時のアクション

🔴 退化検知！

❌ 最新基準点不一致
   - Vault: ce-2026-MM-DD-XX
   - ローカル: ce-2026-MM-DD-YY (古い)

⚠️ 復元コマンド推奨:
bash scripts/snapshot.sh --restore=2026-MM-DD_HHMMSS

⚠️ 編集前に必ず復元してください！

注意事項

• チェック実行時は読み取り専用（変更しない）
• 退化検知時は警告・復元コマンド提示のみ（自動復元はしない）
• グローバルCLAUDE.md の「退化禁止フロー」に準拠
• 各システム別の「保護資産リスト」を必ず参照