# inspection_lessons.md — 点検で学んだこと（点検モード専用ナレッジ・蓄積）

> **点検モード起動時に必ず読む点検専用ナレッジ。** jarvis起動（前進モード）では読み込む必要がないが、点検作業には効く知識をここに貯める。
> マニュアル本体（手順）＝[inspection_mode.md](inspection_mode.md)／本ファイル＝その手順を実行する時の「罠・コツ・誤検出パターン・環境の癖」。
>
> **ユーザー方針（2026-06-09 直接引用）：**
> > 「点検モード起動といったら点検に必要なマニュアルとか学んだこととかかな。これはjarvis起動で読み込ませる必要のない点検作業のみのもの。それも増やせるように」

## 使い方

- 点検モード起動シーケンスの「読込」段で inspection_mode.md と一緒に本ファイルを読む
- 点検中に新しい教訓（「ここ誤検出しやすい」「これは壊れてるように見えて正常」「この環境の癖」）を得たら**確認なし即追記**して育てる
- 1教訓 = 1ブロック（症状／正しい見方／根拠）。同種が増えたら §A〜§E のチェックリスト本体（inspection_mode.md）に昇格

---

## 📚 蓄積ログ

### L1 — dashboard の配信ルートは `jarvis-dashboard-root`（`/dashboard/` サブパス）
- **症状：** `~/jarvis-dashboard/` 直下を見て「dashboard フォルダが無い＝壊れてる」と誤検出しやすい
- **正しい見方：** 配信は `~/jarvis-dashboard-root/` を `--directory` 固定（2026-05-07セキュリティ修正）。正規URLは `http://localhost:8765/dashboard/`。404が出たら「死亡」と即断せず ①サーバ生存(ps) ②配信パス の順で切り分ける
- **根拠：** memory/feedback_localhost_serve_root.md / reflection_log 2026-05-14（同URL誤認で2回open失敗事故）

### L2 — 並列Jarvis稼働中はファイルが他者の手で変わる（「変わってた＝暴走」と決めつけない）
- **症状：** 点検中に「自分が触ってないファイルが変わってる」→「下請けAgentの暴走だ」と犯人断定して差し戻す
- **正しい見方：** 集合Jarvis前提で**常に別セッションが並走**している。まず session_id・mtime・対応する最新memory（後発優先）で裏取りしてから動く。並列の正規作業を壊すのが最悪
- **根拠：** reflection_log 2026-06-09 1345-A（effort_level_check.py を別セッションの正規変更と気づかず差し戻した事故）

### L3 — safety/設定ファイルを「直す」前に対応する最新memoryを読む（後発優先）
- **症状：** 古いCLAUDE.md/DNAだけ見て「これは異常」と判断し、最新方針で正規に変わったものを巻き戻す
- **正しい見方：** effort/burnrate/モデル選定/同期系は方針が更新されやすい。差し戻し前に該当memoryの「🔄 更新（後発優先・現行方針）」を必ず確認
- **根拠：** reflection_log 2026-06-09 1345-A / memory/feedback_effort_level.md（effortLevel=max は2026-06-09以降 現行方針でOK）

### L4 — 下請けAgent・Lv5監査の「犯人はX」式の断定は採用しない
- **症状：** Lv5/下請けが「本体がXした可能性が高い」と推測で犯人特定 → それを鵜呑みにして誤動作
- **正しい見方：** 監査の役割は反証と一次データ提示。変更主体の推測断定は無視し、mtime/diff/authoritative memory で本体が独立検証してから動く。Lv5が誤検出することもある（self_check.md §12 のLv6は実在する 等、監査側の未読による誤指摘に注意）
- **根拠：** reflection_log 2026-06-09 1345-A・1345直後のLv5誤検出（「Lv6が架空」＝実は self_check.md §12 に定義あり）

### L5 — 「動いてるはず」「あるはず」は点検では禁句
- **症状：** プロセス・成果物の生存を記憶や推測で「✅」にする
- **正しい見方：** 点検モードは全判定を実走コマンド・実ファイル確認の一次データで裏取り（feedback_self_check_visual_proof の非視覚版）。緑判定にも根拠データを紐付ける
- **根拠：** inspection_mode.md §0 エートス / feedback_one_shot_failure_5_causes

---

*作成：2026-06-09（点検モード専用ナレッジ層の新設）／ マニュアル本体：inspection_mode.md ／ モード概念：memory/project_mode_concept.md*

### L6 — auth_check の `UNKNOWN` は「ログイン切れ確定」ではない（🔴格上げ禁止）
- **症状：** §A-5 で `google_school UNKNOWN` `loilo UNKNOWN` が出ると「認証切れ＝🔴」と即断しがち
- **正しい見方：** `UNKNOWN` は `NOT_LOGGED_IN` と別物＝**判定不能**（ページ構造変化・リダイレクト途中等）。実際にログイン切れとは限らない。🟡どまりにし、学校系作業を実際にする直前に該当サービスを1回叩いて確認してから🔴判定する
- **根拠：** 2026-06-09 初回点検モード実走（#41では google_school/loilo LOGGED_IN だったが点検で UNKNOWN・但しslack/x/anthropic は NOT_LOGGED_IN で別表示）

### L7 — フォルダ整理の doc-link 一括置換は「会話履歴/を除外」＋「/はリスト区切りも有る」前提で
- **症状：** フォルダ移動後に `<name>/`→`People/<name>/` を全mdに一括sed → ①会話履歴/(過去ログ)の散文中の「A/B/C」リスト区切り"/"までパス扱いで誤置換 ②「倫翔/長森先生/飯塚先生」(送信者3人リスト)が `倫翔/長森先生/飯塚先生` に化けた
- **正しい見方：** (1)**会話履歴/ は一括置換対象から除外**（過去ログ・"/"が散文区切りで多用・そもそもリンク追わない）(2)置換後は必ず `People/<person>/<person>` や `先生/家族` 等「フォルダの中に人名/属性が来る」異常パターンをgrep監査して誤置換を炙り出す (3)live docだけ直し誤りは即リバート
- **根拠：** 2026-06-09 People/グループ化実証（102置換→監査で16ログファイル＋user_brother「倫翔/りんと」誤置換を発見→リバート＋個別修正）。実行ファイル/起動シーケンス参照は0なのでJarvisは無傷だった

### L8 — スクリプト入りフォルダの移動は「ハードコード絶対パス」も直す（mdリンクだけじゃない）
- **症状：** People/Business は実行ファイル参照0で楽勝だったが、School(学校課題在庫/ボカロ部)は中の .py/.sh が `…/起業フォルダー/学校課題在庫/…` や BASE_DIR を**絶対パスでハードコード**。フォルダ移動でこれが旧位置を指して壊れる
- **正しい見方：** (1)移動前に `grep -rn --include=*.py --include=*.sh "<folder>/"` で実行ファイル依存を必ず測る (2)移動後 `起業フォルダー/<name>/`→`起業フォルダー/School/<name>/` を py/sh/json にも適用 (3)**検証＝移動先に実ファイルが在るか ls ＋ py_compile** で裏取り (4)起動シーケンス(CLAUDE.md/settings.json)参照が0なら起動は無傷
- **根拠：** 2026-06-09 School/グループ化。絶対パス26箇所(22ファイル)修正・pptx到達+compile OK確認。起動シーケンス参照0で無傷

### L9 — フォルダ整理の一括置換：汎用名(dashboard/memory/tools)は外部パス・URL・harnessに化けて破壊する
- **症状：** Jarvis系の `dashboard/` を `Jarvis/dashboard/` に一括置換したら、①外部パス `~/jarvis-dashboard/` が `~/jarvis-Jarvis/dashboard/` に破壊 ②URL `localhost:8765/dashboard/` が `localhost:8765/Jarvis/dashboard/` に破壊（96ファイル）。People/Business/School の固有名(Stack/倫翔/ボカロ部)は安全だったが、Jarvis系の**汎用名は別文字列の中に埋まってる**
- **正しい見方：** (1)`dashboard`/`memory`/`tools` 等の汎用名は固有名と違い ~/jarvis-**dashboard**・`.claude/.../`**memory**`/`(harness)・URL `/dashboard/` の中に同綴りで出る→単純prefix置換は厳禁 (2)置換するなら「`(](|/|^)dashboard/`」等 word/文脈ガード必須＋外部パス(`jarvis-dashboard`)・URL(`8765/`)・harness(`.claude/projects`)を明示除外 (3)**置換後に必ず破壊シグネチャ(`jarvis-Jarvis`・`8765/Jarvis/`等)をgrep**して炙り出す (4)被害大なら fix-in-place より**バックアップから全リバート**が安全
- **根拠：** 2026-06-14 Jarvis系グループ化バッチ。dashboard置換で96ファイル破壊→システム差分通知で即発覚→`Jarvis/<名>/`→`<名>/` 全リバート＋CLAUDE.md/clone-jarvis CLAUDE.mdをバックアップ復元→16フォルダ消失ゼロ確認。**先にバックアップを取ってた(ユーザー提案)から完全復旧できた**＝backup-first の価値実証

### L10 — システムに深く配線されたファイル(MEMO/REMINDER)の移動は .md参照だけでなく「外部システム＋起動スパイン」も直す
- **症状：** MEMO/REMINDER を 司令塔/ へ移動。.md参照183件は更新したが、それだけでは ①CLAUDE.md起動シーケンス22パス ②dashboard mirror(~/.local/jarvis/mirror_to_dashboard.sh・stop_hook.sh のコピー元) ③timeline_monitor.py のDrive直読 ④effort_level_check.py の find_reminder(親探索) が旧rootを指して壊れる
- **正しい見方：** 移動対象が「毎ターン読み書き＋多数のシステムが依存する現役ファイル」の時は、(1).md参照 (2)起動シーケンス(CLAUDE.md)パス (3)**外部スクリプト**(dashboard/~/.local配下)のコピー元/直読パス (4)安全装置スクリプトの探索ロジック を全部洗う＝`grep --include=*.py --include=*.sh --include=*.js` をDrive＋~/jarvis-dashboard＋~/.local/jarvis に対して打つ。dashboardのJSは mirror コピー(`../X.md`)を読むだけなのでJS自体は不変・**直すのは mirror のコピー元パス**
- **根拠：** 2026-06-14 司令塔/化。MEMO.md(58参照)/REMINDER.md(60参照)移動。mirror/stop_hook/timeline_monitor/effort_check の4スクリプト修正→mirror実走でdashboard REMINDER.md(81KB)更新確認→起動22ファイル全実在・MEMORY.md誤爆0(MEMO.md≠MEMORYの部分一致を回避)

### L11 — 点検は逐次ファイル記録せよ（compact耐性）。会話だけに置くと compact で全消失
- **症状：** 大規模点検（ラウンド1+修正13領域+ラウンド2＝バグ30件超）の結果を会話の中だけに溜めると、会話 compact が走った瞬間に全消失する。incidents/2026-05-16『書く場所≠読込先』の再発（書いた知識が次に読まれない構造）。
- **正しい運用：** (1)点検開始時に `記憶/audit_reports/点検監査レポート_YYYY-MM-DD.md` を**先に作る** (2)各下請けが1領域終わるごとに**即追記**（会話に溜めない） (3)severity(🔴🟡)/領域/内容/一次実証/修正状況(✅直した/⏳未修正/🙋HEAVY) を構造化 (4)末尾に「🙋HEAVY残」「⏳未修正バグ」の一覧を持たせ次ラウンドの起点にする (5)self_check_log は断片で良いが、**統合レポートは必ず別ファイル**に置く。
- **根拠：** 2026-06-30 ユーザー指摘「会話がcompactされると消えるからファイル化せよ・最優先」。実際にラウンド2で『今日の修正の副作用バグ』が多数出た（cutoff昇格で兄に送れない・過去日付スキップで3/4を3月4日と誤parse・guard repo全体grep化で偽陽性9件＝オオカミ少年化）→これらを会話だけに置いていたら次セッションが副作用に気づけず再修正で潰す危険があった。レポート＝`記憶/audit_reports/点検監査レポート_2026-06-30.md`。

### L? — resource_guard / browser_cpu_guard の意図的停止（ゲーム用）は🔴異常でなく既知例外
- **症状：** 点検モード §A-1 常駐デーモン生存チェックで `com.jarvis.resourceguard` / `com.jarvis.browsercpuguard` が停止（launchctl disable）→「安全装置死亡＝🔴異常」と誤検出し、善意で `launchctl load`/`enable` で勝手に再起動しがち
- **正しい見方：** 2026-07-11 ユーザー指示「ゲーム中にalertが出て邪魔→消して」で**意図的に停止**した。ゲーム＝正当な高負荷でcritical dialogが誤発火するため。勝手に再起動するとユーザーのゲームにまたポップアップが出る＝DNA違反。停止中でも正常。再起動は「ガード戻して」等ユーザー明示指示があった時だけ（恒久解＝popup log-only化してから戻す）
- **根拠：** REMINDER #58 / memory/feedback_guard_alert_disabled_gaming.md / self_check_log 2026-07-11