# inspection_mode.md — 点検モード エンジン（確定シーケンス）

> 合言葉「点検モード」検出時に回す確定シーケンスの本体。
> CLAUDE.md「🎛 モード概念」から参照される。jarvis起動シーケンスと並ぶ第2のモード。
>
> **ユーザー方針（2026-06-09 直接引用）：**
> > 「モードにしよう、そのうちモード概念が欲しかったんだよね」
> > 「点検モードや。名前は決めてないけど絶対ミスしないようなモード、一発で成功させるモード」
> > 「全部かな、問題がないかの点検が最優先」

---

## 0. このモードの性格（エートス）

- **前進ではなく確認**：新規開発・実装をしに来たのではない。「過去にやったことが今も生きてるか」「散らかってないか」「やり残しが腐ってないか」を確かめに来た
- **🔴 問題検出が最優先**：全スコープやるが、優先度は ①問題がないかの点検 ＞ ②整理 ＞ ③振り返り
- **絶対ミスしない・一発成功**：「動いてるはず」「あるはず」を禁止。**全部 実測（コマンド実走・実ファイル確認）で裏取り**してから報告する。推測報告は本モードの存在意義に反する（feedback_self_check_visual_proof / feedback_one_shot_failure_5_causes 準拠）
- **検出した問題は壊さない**：点検は read-only が基本。直すのは「軽微・可逆・明白」なものだけ。構造変更や削除はユーザーに上げる（壊して回るモードではない）

---

## 1. 起動シーケンス（固定部＝毎回／可変部＝その時々で違う）

> **🔴 ユーザー方針（2026-06-09 直接引用）：「点検モードのあとはその時その時で違うと思う」**
> ＝読み込んだ後に**何を点検するかは毎回同じ固定シーケンスではない**。状況・ユーザー指示で変わる。
> 固定なのは「ナレッジを読む → 何を点検すべきか決める → 裏取り → 報告」の**枠だけ**。§A〜§E は毎回フル強制ではなく、状況で選ぶ**点検ツールボックス**。

合言葉「点検モード」（全角半角・大小問わず）を検出したら：

### ◆ 固定部（毎回必ず・省略禁止）
1. **点検専用ナレッジ読込**：本書（inspection_mode.md＝手順 §A〜§E）に従いつつ [inspection_lessons.md](inspection_lessons.md)（点検で学んだこと＝罠/コツ/誤検出パターン）を Read で読み込む。＝点検モードの「脳」（jarvis起動の記憶22ファイルに相当・前進用記憶DNA一式はロードしない）
2. **宣言＋日時** `🔍 点検モード起動` ＋ `date "+%Y-%m-%d %H:%M:%S %A"`（時系列ワード対策）
3. **状況判断**：その時 何を点検すべきか決める（下記「可変部の選び方」）
4. **実行**：選んだ § を回す
5. **裏取り**：🔴問題は Lv5（重要なら Lv6＝Codex・self_check.md §12）で独立検証してから確定（誤検出で騒がない）
6. **§E 点検レポート**を返す（3秒で読める形・🔴問題を最上段・問題ゼロなら「ゼロ✅」明示）

### ◆ 可変部の選び方（§A〜§E ＝ 点検ツールボックス・その時々で違う）
- **ユーザーが対象を指定**（「ちゃんと動いてるか見て」「フォルダ整理して」「やり残し棚卸しして」等）→ 該当する § を中心に回す
- **指定なし（ただ「点検モード」だけ）→ §A 健康診断をベースライン**（方針「問題がないかの点検が最優先」のため）＋ 気づいた範囲で §B〜§D
- 全部やる時もあれば1つだけの時もある。**毎回フルセット強制ではない**（それがこのモードの設計思想）

> 前進用記憶（DNA一式）のフルロードはしない。読むのは点検専用ナレッジ（手順＋学んだこと）。点検対象データ（REMINDER/MEMO/ファイル一覧）は §B/§C で都度読む。過去方針の確認が要るときは該当memoryを都度読む。
> **点検専用ナレッジは増やせる**：点検中に得た教訓は inspection_lessons.md に即追記して育てる（モード固有の知識が貯まる）。

---

## 📦 点検ツールボックス（§A〜§D・§F＝固定部の手順④で状況に応じ選ぶ ／ §E＝固定部で毎回返すレポート様式）

> §A〜§D・§F は「いつでも取り出せる点検の道具箱」。毎回全部使うのではなく、その時の状況で必要なものを選ぶ。
> **§F 動作回帰テスト（regression.py）は §A健康診断の動的版**＝指定なし起動時は §A に続けて回すのが基本。
> **§E だけは選択対象ではなく、固定部の最後で毎回返すレポート様式**（道具ではなく出力フォーマット）。

## §A 健康診断チェックリスト（実測必須・各項目 ✅/🔴/🟡 判定）

「動いてるはず」を実行結果に変える。各コマンドを実走し、出力で判定する。

### A-1 常駐プロセス／デーモン生存
```bash
ps aux | grep -iE "resource_guard|browser_cpu_guard|cloudflared|fleet_api|http.server 8765|anthropic_ratelimit" | grep -v grep
```
- 期待：resource_guard / browser_cpu_guard（安全装置）/ dashboard 8765 / fleet_api 8767 / cloudflared（トンネル）
- 1個でも落ちてたら 🔴（安全装置が落ちてるのは最優先問題）

### A-2 課金安全（最重要・claude -p / Agent SDK ゼロ）
```bash
bash clone-jarvis/jarvis/safety/claude_p_guard.sh
```
- [1]ガード済・[3]稼働中claude -pゼロ・[4]GitHub Actionsなし → ✅／ヒット→🔴即対処（feedback_no_claude_api_max_only / 6/15課金分割）

### A-3 effortLevel
```bash
bash clone-jarvis/jarvis/safety/effort_level_check.sh
```
- `OK: effortLevel={xhigh|max}` → ✅（max は 2026-06-09 以降 現行方針でOK・feedback_effort_level.md）／high以下→🟡

### A-4 dashboard / map.html
```bash
curl -sf -o /dev/null -w "%{http_code}" http://localhost:8765/dashboard/   # 200期待
curl -sf -o /dev/null -w "%{http_code}" http://localhost:8765/dashboard/map.html
```
- 200以外→🔴（dashboard死亡はユーザーの中央コクピット喪失・REMINDER #49 JARVIS_MANUAL の動機）
- ⚠️ 配信ルートは `~/jarvis-dashboard-root/`（`--directory`固定）で正規URLは `/dashboard/` サブパス（`~/jarvis-dashboard/` 直下ではない・feedback_localhost_serve_root.md / reflection_log 2026-05-14）。404が出たら「死亡」と即断せず A-1 のサーバ生存→配信パスの順で切り分ける

### A-5 Playwright 認証
```bash
cd tools/playwright && python3 auth_check.py
```
- 必要サービス（google / google_school / github / loilo 等）が LOGGED_IN → ✅／NOT_LOGGED_IN→🟡（使うものだけ・全8厳守ではない）

### A-6 fleet（並列システム）
```bash
cd ~/jarvis-dashboard/fleet_v2 && DRY_RUN=1 python3 tests/test_e2e_v2.py 2>&1 | tail -5
```
- ALL PASS → ✅／fail→🔴。v4(fleet/)側も必要なら確認

### A-7 主要成果物の生存（存在＋構文）
- `tools/send/send.py`（送信パイプライン）/ Stack mvp / news-calendar / ボカロ部HP 等、棚卸しで重要と判断したものを `python3 -m py_compile` / ファイル実在 で確認
- 「あるはず」を `ls`/実Read で確定

> **A-1〜A-7 は固定の最小セット**。点検のたびに「前回✅だったものが今回🔴」を差分で見ると劣化が早期に拾える。新しい常駐・成果物が増えたら本リストに追記して育てる。

---

## §B フォルダ棚卸し（散乱・肥大・重複・孤児）

1. **全体把握**：map.html（`http://localhost:8765/dashboard/map.html`）or `~/jarvis-dashboard/data/file_index.json` で起業フォルダー全ファイルを俯瞰
2. **直下肥大チェック**：起業フォルダー直下のMDファイル数（記憶/フォルダ運用ルールでは新規は `記憶/<sub>/` へ。直下17ファイル固定＝REMINDER #50 の移行対象）
3. **重複検出**：「起業フォルダー」と「起業フォルダー (1)」（REMINDER #36）/ 同名・類似ファイル
4. **孤児・陳腐化**：参照ゼロのMD・撤退プロジェクト残骸・`_archive_*`・`.bak`（過去資産は捨てない＝feedback_legacy_files_keep。**整理≠削除**。リスト化のみ・削除はユーザー明示指示時）
5. 出力：整理候補リスト（移動先・参照書換コスト・関連REMINDER番号を添える）

> 🔴 削除・移動は本モードでは**提案まで**。実行はユーザー承認後（DNA確認ルール：ファイル削除は確認必須）。

---

## §C やり残し棚卸し（REMINDER / MEMO 再分類）

1. 司令塔/REMINDER.md / part2 / part3 の全未対応エントリを走査
2. MEMO_sessions* の「📤 セッションやり残し」を走査
3. 各項目を3分類：
   - **✅ 生きてる**：まだ有効・着手すべき → 残す
   - **🟡 放置**：有効だが長期停滞 → 状況更新 or 着手提案
   - **🗑 陳腐化**：実態が変わって意味を失った / 実は完了済 → **クローズ提案**（feedback_reflection_log「クローズ忘れ」対策）
4. §A健康診断の結果と突合（例：「#XX が動作前提だが A-4 で dashboard 🔴 → #XX も再検証要」）
5. 出力：クローズ候補リスト＋根拠（実態確認した一次データを添える）

---

## §D 歩みの振り返り

- MARK履歴（clone_dna.md「MARK履歴」/ 現在地）を時系列総覧
- 主要マイルストーン（dashboard・MARK Ⅵ常駐・fleet・Stack・点検モード新設…）
- 学習サイクル（clone_dna 第N サイクル）の流れ
- 「今どこにいて、何を積み上げてきたか」を1画面で

---

## §F 動作回帰テスト（regression.py）— §A健康診断の動的版

> **位置づけ：** §A健康診断が「実在・構文・プロセス生存」の**静的**点検なのに対し、§F は全機能を**実際に動かして期待結果と照合する動的・非破壊E2E**。「あるはず」「動いてるはず」を一段強く潰す。§A で生存だけ見たものを、§F で「実走させて期待値通りか」まで踏み込む。

### 呼び出し方（ワンコマンド・数十秒で完走）

```bash
# 全テスト実行（標準出力に ✅N/🟡M/🔴K サマリ）
python3 tools/inspection/regression.py

# 結果を history/ にJSON保存 ＋ 直近の前回結果と比較し「前回✅→今回🔴」を劣化として強調
python3 tools/inspection/regression.py --json

# 一部だけ高速確認
python3 tools/inspection/regression.py --only roster,fleet,billing_safety

# テスト一覧
python3 tools/inspection/regression.py --list
```

### いつ回すか

- **指定なしの「点検モード」起動時**：§A 健康診断のベースラインに**続けて §F を `--json` で回す**（前回比劣化の自動検出が点検モードの「劣化を見逃さない」を担保）
- ユーザーが「ちゃんと動いてるか全部見て」系を出したとき
- 大きめの改修・整理の後（リグレッション確認）
- §A で 🟡/🔴 が出た領域は §F の該当テスト（`--only`）で実走裏取り

### テスト項目（14件・各=実走して期待値照合・🔴FAIL/🟡WARN/✅PASS）

roster / dashboard / fleet / todo補足 / send(dry-run) / memory整合(死リンク) / 起動22ファイル / 課金安全(claude -p) / effortLevel / 安全装置デーモン / 認証 / hooks / 成果物 / file_index鮮度。詳細＝[../../tools/inspection/README.md](../../tools/inspection/README.md)。

### 🔴 絶対制約（副作用ゼロ）

read-only / dry-run / プロセス確認 / 構文チェック のみ。**実送信・カレンダー書込/削除・kill・ファイル削除・claude -p実行は絶対しない**。send は `--dry-run`＋`SEND_LOG_FILE`を捨てパスに逃がして実送信監査ログすら汚さない設計。書き込むのは `tools/inspection/history/*.json`（自分の結果履歴）のみ。

### 前回比較の使い方

`--json` で履歴保存すると、次回実行時に**前回PASS→今回FAIL**を `🔴🔴 前回比 劣化検出` としてレポート最上段に出す。点検レポート(§E)の「🔴 問題」セクションに、この劣化を最優先で転記する。鮮度系(🟡)や UNKNOWN は劣化扱いしない（誤検出で騒がない）。

---

## §E 点検レポート フォーマット（3秒で読める）

```
🔍 点検レポート（YYYY-MM-DD HH:MM）

🔴 問題 N件（最優先・要対応）
- [A-X] ○○が落ちてる → 影響 / 対処案
…（無ければ「🔴 問題ゼロ ✅」と明示）

🟡 要注意 M件
- …

🗂 整理候補 K件
- …（移動先・関連REMINDER）

🗑 クローズ候補 L件（REMINDER/MEMO）
- #XX … → 陳腐化理由

📈 歩み：現在 MARK Ⅵ / 直近マイルストーン …

次アクション提案：1〜3行
```

- **🔴問題ゼロなら「問題ゼロ ✅」と明示**（jarvis起動の「該当0件なら黙る」と違い、点検は"無事の確認"が成果なので明示する）
- 全判定に**実測の一次データ（コマンド出力・ファイル確認）が紐づく**こと。推測判定は禁止

---

## 自己チェック（点検モードでも全適用）

- 本モードでも self_check Lv1〜Lv5 全ターン強制（Lv5 は点検の「絶対ミスしない」を担保する核）
- 🔴問題と判定する前に**必ず実測で裏取り**（誤検出で騒ぐのは点検モードの信頼を壊す）
- 検出問題を「直した」と言う前に再実測（feedback_self_check_visual_proof の非視覚版）

---

*作成：2026-06-09（モード概念の確立・第1弾 点検モード）*
*関連：CLAUDE.md「🎛 モード概念」/ memory/project_mode_concept.md / REMINDER #36 #48 #50（フォルダ整理系）/ #49（JARVIS_MANUAL）*