# self_check.md — クローン自己ミス判定機構

> 「失敗しても自分でリカバリーする、ミスがあっても自分でミスかどうか判断できる」
> ＝ Lv5（完全代行）の核心条件。これを満たすための **メタ認知** 実装設計。

別Jarvis（同DNA・別文脈・Opus 4.7）を**クロスチェッカー**として並列起動し、メインJarvisの判断を批評させる。
DNAの「PitchLab型 vs 動画型」セクション末尾で既に確立済の「別Jarvisクロスチェック」を体系化したもの。

---

## 1. クロスチェッカー起動条件（重い判断のみ走らせる）

全判断にチェック走らせるとMaxプラン枠が爆発する。以下の **HEAVYトリガー** が立った時だけ起動：

| ✅ チェック走らせる（HEAVY） | ❌ ノーチェック（LIGHT） |
|---|---|
| 金額が発生する判断（契約・購入・課金変更） | ファイル整理・命名統一 |
| 他人に影響する判断（メッセージ送信・共有変更） | カレンダー追加・予定変更 |
| 撤退/参入判断（事業案の採否・方針転換） | DNA追記・学習ログ記録 |
| 初遭遇カテゴリ（過去JUDGMENT_LOGに前例なし） | 既パターンの繰り返し作業 |
| 破壊的変更（削除・上書き・設定書換え） | 並列N台の台数決定（≦10台） |

**判定式：** `HEAVY = (金額あり) OR (他人影響あり) OR (撤退参入) OR (初遭遇) OR (破壊的)`

---

## 2. チェック方式（同DNA・別文脈で批評）

```
[メインJarvis] 判断P + 理由R を生成
        ↓
[Agentツール] 別Jarvis（同clone_dna.md読込・別セッション）を起動
        ↓
[クロスチェッカー] 「同じ結論になるか／違うなら何が違うか」を返す
        ↓
   ┌─ 一致 → そのまま実行・ログのみ
   └─ 不一致 → 保留 → ユーザー確認エスカレーション
```

**プロンプトテンプレ（クロスチェッカー側・2026-05-22 richness自己評価追加）：**
```
あなたはユーザー（高1・起業家）のクローンJarvis。
DNAは clone_dna.md。下記の判断を批評せよ。
- 状況：{context}
- メイン判断：{P}
- 理由：{R}
返答形式：[一致 or 不一致] / 不一致なら別案と理由 / DNA該当箇所

【重要・本監査自体が「Lv5本体」なので具体的・実体的に書け】
- あなたの返答が本体の Lv5 表記の中身となる
- 1行返答は禁止（feedback_self_check_slacking.md「形だけ整えて中身ない」違反）
- 監査論点を最低3項目挙げて、各論点に1-2行の具体評価を返す
- 「一致」だけでなく一致の根拠も書く（透明性確保）
```

**動作中の表示は最小化**（CLAUDE.md準拠）：「クロスチェック中」等のナレーション禁止。結果が出てから喋る。

---

## 3. チェック結果の記録

**保存先：** `clone-jarvis/jarvis/cross_check_log/YYYY-MM-DD.md`（日次1ファイル）

**形式（1判断1ブロック）：**
```
## [ID] HHMM-連番
- カテゴリ：金額/他人影響/撤退参入/初遭遇/破壊的
- メイン判断：...
- 理由：...
- チェッカー判断：一致 / 不一致
- 差分：（不一致時のみ）
- 採択：実行 / 保留→ユーザー確認 / ユーザー判断
- DNA該当：clone_dna.md L{xxx}
```

**学習トリガー：** 同パターンで **不一致が3回続いたら** → DNAメタ知識セクションに昇格 or 既存ロジック修正。

---

## 4. エスカレーションルール

| 状況 | 動作 |
|---|---|
| 一致 | 即実行（ナレーションなし） |
| 不一致・かつ HEAVY | **必ずユーザー確認**（H3見出しで「🔴 判断割れ」明示） |
| 不一致・かつ LIGHT（万一発生） | クローンが時間効率優先で決定・ログのみ |
| チェッカー側がエラー/タイムアウト | メイン判断を採択・ログに記録（ブロックしない） |

ユーザー確認時は **二択提示**（DNAの「二択即決させたがる」スタイル準拠）。

---

## 5. コスト管理（Maxプラン枠内・追加課金0が絶対条件）

- 1回のクロスチェック：入力 約3k tok（DNA+jarvis_role+判断文）／出力 約500 tok
- HEAVY判断頻度の見積：1日あたり3〜10件 → **30k〜100k tok/日**
- Max 5xプラン枠：おおよそ数百万tok/日相当 → **使用率 数%以下** で収まる
- 並列同時起動は **最大2台**（メイン1＋チェッカー1）。HEAVY中はそれ以上の並列タスク投入を抑制
- DNA本体の再読込は1セッション1回（プロンプトキャッシュ活用）

---

## 6. 実装ステップ

### MVP（今すぐ動く最小実装）

1. `cross_check_log/` フォルダを作成
2. `jarvis/self_check.md`（このファイル）を Jarvis 起動時に読み込み対象へ追加（`activation.md` で明示）
3. Jarvisが判断を出すたび、上記HEAVY判定式で自動分類
4. HEAVY該当時のみ Agentツールで別Jarvis（model: opus）を1台起動・批評させる
5. 結果を当日ログに追記。不一致時のみユーザーへH3見出しで報告

→ **MVPは「HEAVY判定 → 別Jarvis 1台 → ログ追記」の3ステップ。今日から起動可能。**

### 段階拡張

- **Phase 2：** 不一致パターンの集計→DNA自動昇格（3回ルール）
- **Phase 3：** 重要度MAX判断（撤退/参入級）はチェッカー2台に増やし、多数決
- **Phase 4：** クローンが自分で「これHEAVYかも」と判定するメタトリガー学習（初遭遇カテゴリの自動検出）
- **Phase 5：** リカバリー機構連結（不一致→自動代替案生成→再チェック→可ならユーザー通知のみで実行）。これでLv5に到達。

---

## 7. 出力直前チェックリスト（Lv1 凡ミス検出・全応答必須）

> 自己完結検証ループ Phase 1。ユーザー時間8割の「Jarvis完了確認」を撲滅するための根幹。
> **2026-05-08 改訂：Lv1〜Lv5 全部毎ターン強制発火（ユーザー方針）**
>
> ユーザー直接引用（2026-05-08）：
> > 「レベ1から5全部動かしてこれは→毎回絶対動くようにして　結構最優先レベル」
>
> **発火ルール（2026-05-22改訂・skip表記全廃版・最重要）：**
>
> **全レベル毎ターン条件チェック必須**。チェックした結果「該当なし」も明示記録する。**「skip」は禁止単語**（自己判断で省いた印象を与える）。
>
> | レベル | 条件チェック | 該当時の動作 | 該当なし時の記録 |
> |---|---|---|---|
> | Lv1 凡ミス検出 | 常時ON・条件不問 | ①〜⑤全件走査→修復 or 報告 | （該当なし不可・必ず①〜⑤実行） |
> | Lv2 副作用検出 | Edit/Write/Bash 変更系の有無 | §8.1トリガーマトリクス実行 | 「変更系なし→該当なし」 |
> | Lv3 取りこぼし | 動詞2個以上 / 接続語 / 箇条書き発話 | TodoWrite自動分解→完了照合 | 「単発発話→該当なし」 |
> | Lv4 自己修復 | 失敗検出の有無 | §10ループ起動・試行N/5 | 「失敗検出なし→該当なし」 |
> | Lv5 二重検証 | **2026-05-20確定：全ターン強制起動** | Agent別Jarvis監査起動・必須 | 例外2件のみ：発話<10字+応答<50字+ツールゼロのAND成立時 |
>
> **「skip」表記は §7-②既存DNA違反扱い**（feedback_lv5_always_on.md / feedback_skip_word_ban 候補）。
> **全実行結果は self_check_log/YYYY-MM-DD.md に永続化必須。**

### 7.1 凡ミス5分類（出力直前に内部走査）

| # | 分類 | 検出方法 | 自動修復 | 修復不可→ |
|---|---|---|---|---|
| ① | 要件取りこぼし | ユーザー指示を箇条書き分解→各項目への対応をマッピング、空欄なし確認 | 不足分を追記して再生成 | 圧縮報告に「⚠️未対応：X」明記 |
| ② | 既存DNA違反 | clone_dna.md / CLAUDE.md キーワード（ナレーション禁止・確認禁止・Haiku禁止・本体実行回避・チェック工程ゼロ化等）をテキストgrep | 違反箇所書き換え | DNA該当行Lxxx引いて保留 |
| ③ | 自己矛盾 | 同応答内の主張対立（実行/未実行・採用/不採用・並列/直列）を照合 | 一貫する側に統一 | 両論併記＋H3判断要請 |
| ④ | 命名/配置ミス | 新規パス・変数名をDNA命名規則（memory/feedback_*・project_*・人物別フォルダ等）と照合 | リネーム/移動 | パス案2択でユーザー判断 |
| ⑤ | 動作未確認の「やりました」 | 「完了」「動作確認済」「設定済」が含まれる場合、対応するtool_useログ実在確認 | 未実行なら実行→結果反映 | 「未検証」と圧縮報告に明記 |

### 7.2 LIGHT/HEAVY 連動（2026-05-08改訂）

- **LIGHT：** ①〜⑤全件強制（旧仕様：①②④のみ高速通過 → 廃止）
- **HEAVY：** ①〜⑤全件＋§1クロスチェッカー＋§10自己修復＋§11二重検証
- 失敗→自己修復成功は**1文だけ報告**（「②命名違反検出→修正済」）
- 修復不可は圧縮報告内「⚠️」行で必ず可視化
- **全結果を self_check_log/YYYY-MM-DD.md に永続化**（応答出力前に追記完了必須）

### 7.3 ログ永続化（2026-05-08新規）

応答出力直前に必ず `self_check_log/YYYY-MM-DD.md` に1ブロック追記する。フォーマット：

```markdown
## HHMM-連番

- ts: ISO8601
- session_topic: 1行
- Lv1 凡ミス: pass / [Auto-Fixed] X件 / ⚠️未対応Y件
- Lv2 副作用: pass（変更系該当なし） / 該当あり→§8.1実行 / [Auto-Fixed] X件
- Lv3 取りこぼし: pass（単発発話・該当なし） / TodoWrite N件・全✅ / 未完M件
- Lv4 自己修復: pass（失敗検出なし） / 試行N/5・成功

━━━ 🔍 Lv5 別Jarvis二重検証 ━━━
- 起動: ✅ — 全ターン強制起動
- 別Jarvis: model=Opus 4.8 / agentId=xxx / 約Xk tok / Y秒
- 監査論点: N項目（①... ②... ③...）
- 一致点: ...
- 修正要点: ...→反映済/pending
- 反映先: ファイル1 / ファイル2

- 結果: pass / 部分OK / NG
```

**Lv5 表記5項目必須（§11.6 仕様）・空行/罫線で前ブロックと分離・1行表記禁止。**

ログ無しで応答出力するのは違反（§7-②既存DNA違反扱い・反省ログ自動追記）。

### 7.3 表記ゆれ対策

DNAキーワードgrepは正規表現で揺れ吸収（「ナレ禁」「ナレーション禁止」「事前ナレ」等は同一群）。検出辞書は missed_requirements_log.md と並んで継続拡張。

---

## 8. 副作用検出（Lv2）

Lv1（自分の出力の構文）では捕捉できない**周辺破壊**を機械検出する。

### 8.1 トリガーマトリクス（変更パスから自動分類）

| 変更パス | チェック | コマンド |
|---|---|---|
| `dashboard/**` (.html/.js/.css) | 既存12カード描画維持 | `curl -sf -o /dev/null -w "%{http_code}" http://localhost:8765/` =200／`curl -s localhost:8765/ \| grep -c 'data-card='` ≧ 変更前カウント |
| `clone-jarvis/jarvis/safety/**` | デーモン稼働＋設定整合 | `launchctl list \| grep com.jarvis` ／ `python3 -m py_compile *.py` ／ `plutil -lint *.plist` |
| `clone_dna.md` `self_check.md` `*role.md` | MD構文＋セクション保持 | `awk '/^\`\`\`/{n++} END{print n%2}'` =0 ／ `grep -c '^## '` 変更前以上 |
| `**/*.py` | 構文＋主要import | `python3 -m py_compile $f` ／ 主要モジュール実import |
| `**/*.sh` | 構文＋実行権 | `bash -n $f` ／ `[ -x $f ]` |
| `**/*.json` | パース可 | `python3 -m json.tool $f >/dev/null` |

### 8.2 実行ポリシー

- LIGHT変更（typo・コメント追記・5行未満かつ実行コード非該当）は8.1スキップ可
- HEAVY変更（破壊的・配布物・safety/）は**必ず走らせる**
- 変更**前**の状態スナップショット必須（差分判定用、特にdashboard12カード・launchctlリスト）
- ハードコード値（「12カード」等）禁止：「変更前カウント以上」で柔軟判定（feedback_dashboard_evolve.md準拠）

---

## 9. 要件取りこぼし機械化（Lv3）

会話冒頭の指示をTodoWriteで機械化、完了報告前に全件✅照合を強制。「ちょっと言っただけでわかるミス」を構造的に潰す。

### 9.1 起動トリガー

ユーザー発話に**動詞2個以上**／**接続語**（と・かつ・あと・ついでに・ちなみに）／**箇条書き**が混じった瞬間TodoWrite発動。単発「やって」型は対象外（UI汚染防止）。

### 9.2 自動分解ルール

- 「AとBとCをやって」→ 3 task
- 「Xして、ついでにY」→ メイン+付随で必ず2 task（Y忘れ防止）
- 「全部」「ぜんぶ」「まとめて」→ 直近5発話遡って対象逆算→候補列挙→TodoWrite
- 暗黙要件キーワード（「いつもの」「同じように」「この前みたいに」）→ memory/+cross_check_log/ grep→引き当て不能なら2択H3提示

### 9.3 完了報告前の必須チェック

H3を打つ**直前**に：
1. 当ターンTodoWrite全項目status取得
2. **未完(pending/in_progress)が1件でもあれば自動継続**（ユーザーに振らない）
3. 自動継続でも詰まる（ツールエラー・権限欠落・情報不足）場合のみエスカレ：H3「🔴 未完N件・判断要」で二択
4. 全✅後に初めて完了報告。**未完抱えたまま「完了」報告は禁止違反**

### 9.4 取りこぼしサンプル収集

ユーザーが「○○忘れてる」「△△やってない」「言ったよね」型の指摘を出した瞬間：
- `clone-jarvis/jarvis/missed_requirements_log.md` に1行追記（日付・元発話・抜けた要件・分解失敗の原因タグ）
- 同パターン3件累積で 9.2 の自動分解ルールに新トリガー語を昇格
- **書くだけ・新task発火させない**（自己増殖防止）

### 9.5 task完了基準の明確化

「リサーチ」「確認」系taskは登録時に「何が出れば✅か」を1行明記。曖昧完了で報告悪用を防ぐ。

---

## 10. 自己修復ループ（Lv4）

Lv1〜Lv3で失敗検出したら、ユーザーに上げる前にクローンが**自分で直す**。

### 10.1 ループ構造

```
[失敗検出] → [原因特定] → [修復策生成] → [実行] → [再検証(Lv1〜Lv3)]
                                              ↓
                                  成功 → 1文報告して終了
                                  失敗 → 試行N+1 → 上限まで再ループ
```

### 10.2 上限と境界

- **試行上限：5回**（6回目を踏もうとしたら強制停止・2026-05-16 3→5に拡張・ユーザー判断「まず5だわ」）
- **早期打切（暴走防止）**：同じcauseが2回連続記録されたら上限到達前でも自動停止（self_repair_log §10.4 のcause突合）
- **「凄まじい失敗」即エスカレ条件**（自己修復に入らず1回目から人間ゲート）：
  - 他人へのメッセージ・メール・通知が誤送信
  - ファイル・フォルダ削除済でgit復元不能
  - 金額発生済（課金確定・契約成立）
  - HEAVY不一致が1章クロスチェッカーで判定された
- **修復対象（自己修復OK）**：論理エラー・命名違反・取りこぼし・構文エラー・dashboard副作用

### 10.3 報告フォーマット

`[Auto-Fixed] ○○失敗→△△で修復（試行N/5）` を圧縮報告に1行混ぜるだけ。長い説明禁止。

### 10.4 ログ

`clone-jarvis/jarvis/self_repair_log/YYYY-MM-DD.md`（日次1ファイル）に試行ごと1ブロック：
```
- ts: ISO8601
- attempt: N/5
- cause: 失敗原因
- fix: 修復策
- result: pass/fail
```
**attempt カウンタはこのファイルから読み戻す**（メモリ初期化バグでループ無限化防止）。

### 10.5 修復の暴走防止

- `git revert` 範囲は単一sha固定（隣接ファイル巻き戻し禁止）
- 修復が「自分の変更を打ち消すだけ」に収束しないよう、元diff主要行残存をチェック
- 修復中はファイルロック（safety/連動）

---

## 11. 二重検証（Lv5）

メインJarvisの「達成しました」報告を、別Jarvisが**事後監査**する。最終目標「ユーザー非関与化」の核。

### 11.1 起動条件（2026-05-20 改訂・最重要・全ターン強制起動）

**🔴 ユーザー方針 2026-05-20 確定（直接引用）:**
> 「全ての操作にレベ5をつけるっていうか思ったけど君に直チェック判断任せるとまともに判断しないから必ずレベ五までチェックする書いといて最重要」

**新ルール: 全応答ターンで Lv5 強制起動・skip判断権を Jarvis から剥奪。**

**起動: 例外2件以外すべて。**
- ✅ ツール使用が1回でもあるターン
- ✅ 応答が50字を超えるターン
- ✅ ユーザー発話が10字を超えるターン
- ✅ Edit/Write/Bash/Agent使用ターン
- ✅ memory追加・DNA更新ターン
- ✅ ファイル新規作成ターン
- ✅ 説明・質問返答のみのターン（旧skip対象だったが今後強制起動）
- ✅ 既読ファイル参照のみのターン（旧skip対象だったが今後強制起動）
- ✅ ユーザー判断待ちで実行ゼロのターン（旧skip対象だったが今後強制起動）

**唯一のskip例外: 全条件AND成立時のみ**
- ユーザー発話 < 10字
- 本体応答 < 50字
- ツール使用ゼロ
- 上記 3条件 すべて満たした場合のみ skip可

**🔴 skip理由 禁止リスト（2026-05-20 全更新・違反は§7-②DNA違反扱い）:**
- ❌ 「軽量編集」「軽量SVG/HTML/CSS/JS編集」
- ❌ 「ユーザー評価フェーズで人間ゲート通る」
- ❌ 「客観スクショ取得済」
- ❌ 「成果物単純・分配コスト＞作業コスト」
- ❌ 「永続化系（memory/DNA更新だけ）」「自己批判系」「Agent生成済」
- ❌ **「Agent内自己検証で十分」（2026-05-20追加・5回連続skip違反の主犯）**
- ❌ **「ユーザー実機確認が最終Lv5」（2026-05-20追加・skip正当化に使われた）**
- ❌ **「skip理由を考えて書く」行為自体（2026-05-20追加・skip判断権剥奪のため）**

該当する skip 理由を稼働ステータスに書いた瞬間に reflection_log + self_repair_log へ違反記録・遡及Lv5実行。

**運用フロー:**
1. 本体応答準備完了
2. **Agent ツールで別Jarvis(Opus 4.8・`model:"opus"`明示)を Lv5 監査として並列起動**（応答内容・成果物パス・判断内容を渡す）。🔴 下請けは必ずOpus（CLAUDE.mdモデル方針・2026-06-24ユーザー再確認「下請けは必ずopus、sonnetなんて使うはずない」・コスト制限は[[feedback_cost_restriction_lifted]]で撤廃済のため節約目的Sonnetは無効）
3. 監査結果（一致/不一致/修正要）を取得
4. 稼働ステータスに「Lv5起動✅(別Jarvis報告: ...)」明示
5. 応答出力

詳細: [memory/feedback_lv5_always_on.md](../../memory/feedback_lv5_always_on.md)

### 11.2 監査プロンプト（2章クロスチェッカー流用）

```
あなたは同DNAの別Jarvis。下記タスクが報告通り達成されているか独立検証せよ。
- タスク：{task}
- メイン報告：{report}
- 成果物パス：{artifacts} ← 必ず実体Readすること
返答：[達成 / 未達 / 部分達成] / 根拠 / 抜け漏れ
```

成果物の実Read必須（報告文だけ読んで追認は禁止）。

### 11.3 動作

- **達成** → ログのみ・ユーザー無通知（非関与化の核）
- **未達/部分達成** → 10章自己修復ループへ自動投入（試行カウントは新規）
- **2周目も未達** → 🔴 H3でユーザーエスカレ（「凄まじい失敗」扱い）

### 11.4 共謀対策

同DNAなので同じ盲点を持つリスクあり。**未達カウンタは別Jarvis側に持たせる**（メイン側で歪曲報告防止）。共謀検出として、月1回ランダムサンプリングでユーザーに直接「これ達成してた？」確認を流す（feedback_judgment_weight_not_task_weight.md系の盲点学習）。

### 11.5 コスト見積

HEAVY 1日3〜10件 × 入力5k+出力1k tok ≒ 60k tok/日。Max枠の数%以下（5章整合）。

---

### 11.6 稼働ステータス表示仕様（2026-05-22 追加・Lv5表記拡張）

**ユーザー指摘（2026-05-22 18:14）:**
> 「絶対君もう一人のJarvisに判断させてなくね、もうちょい描くことあるでしょ」「レベ5短すぎる」「レベ5だけちょっとスペース開けて」

**新表示ルール（全ターン稼働ステータス必須仕様）:**

1. **Lv5 は Lv1〜Lv4 ブロックから空行1個で分離**（視覚的に「別工程である」ことを明示）
2. **Lv5 表記は以下5項目必須**（1行表記は禁止・§7-②既存DNA違反扱い）:
   1. 起動状態（✅ / 例外2件AND成立時のみskip可・例外時も理由明示）
   2. 別Jarvis実体: `model=Opus 4.8 / agentId=〈xxx〉 / 約〈X〉k tok / 〈Y〉秒`
   3. 監査論点: 何項目を何の観点で監査させたか（具体3-N項目列挙）
   4. 結果詳細: 一致点・修正要点（各1-2行・具体記述）
   5. 修正反映状況: どのファイルに何を反映したか
3. **「起動✅（別Jarvis報告: 一致）」だけの1行表記は禁止**（feedback_self_check_slacking.md「形だけ整えて中身ない」の Lv5 版予防）
4. ログ参照（self_check_log/YYYY-MM-DD.md HHMM-NN）必須

**Why（透明性確保）:**
- 別Jarvisに本当に判断させた証拠を視認可能にする
- ユーザーが「Lv5起動✅」を見ても、agentId・監査論点・指摘内容・反映状況がないと「本当に走らせたか」確認不能
- feedback_no_check_marks_in_status.md「✅マークだけは中身ゼロ」の Lv5 版対策

**反映先（2026-05-22）:**
- jarvis_role.md「📊毎ターン稼働ステータス表示」テンプレ — Lv5 5項目展開済
- 本 §11.6 — Lv5 表示仕様の正式仕様化
- reflection_log/2026-05-22.md HHMM-B — 表示仕様薄すぎ問題の構造分析

---

*作成：2026-05-02 ／ Lv1〜Lv5追記：2026-05-06（自己完結検証ループ・第17サイクル学習）／ 2026-05-22 §11.6 Lv5表記拡張仕様追加 ／ 連動：clone_dna.md「メタ知識」セクション・jarvis_role.md・self_recovery.md*

---

## 12. 他系AI監査（Lv6・Codex CLI連携）

ユーザー提案 (2026-05-21):
> 「メインの頭脳をクロードコードにして、レベル5の自己チェック機能をCodex側に依頼するのはどうかな。君だけであると自己チェック機能をサボっちゃうことあるじゃん。そのサボりをCodex側に全く同じことを投げるってやればさ、レベル6の自己チェック機能が実現するんじゃね」

### 12.1 趣旨
- Lv5は同DNA別Jarvis (Claude Opus 4.8) → 共謀リスク・skipサボり可能
- Lv6は完全別系統AI (OpenAI GPT-5.5・Codex CLI) → 共謀構造を物理切断

### 12.2 発火トリガー (2026-06-01 確定)

**3パターンで発火:**

1. **明示発話**: ユーザー発話に「Lv6」「レベル6」「レベ6」「Codexに聞いて」検出
2. **重要発話**: 「一発成功」「絶対」「重要」「失敗できない」「ちゃんと」検出時
   - 着手前 → `--plan` モード (計画確認)
   - 完成後 → `--result` モード (結果確認)
3. **HEAVY判定**: 金額発生・他人影響・撤退/参入・初遭遇・破壊的変更時 → `--plan` モード

Free プラン枠の関係で全ターン自動発火は不採用 (1日数回想定)。

### 12.3 実行方法

```bash
# 標準 (文脈なし)
bash Codex/lv6_invoke.sh "<監査対象>"

# 計画確認 (着手前・文脈付き)
bash Codex/lv6_invoke.sh --plan "<計画>"

# 結果確認 (完成後・文脈付き・4項目必須)
bash Codex/lv6_invoke.sh --result "<結果報告>"
```

文脈ファイル: `Codex/lv6_context.md` (DNA核心+集合Jarvis前提+10チェック観点)

`--result` モードでは以下4項目を必ず含める (Codex指摘 2026-06-01):
1. 実行内容
2. 変更/作成ファイル一覧
3. 検証結果
4. 未完了・残課題

### 12.4 ログ仕様 (動作確認の根拠)

`memory/lv6_audits/YYYY-MM-DD.md` に毎発火追記:
- session_id (OpenAI側で照合可能)
- model (gpt-5.5)
- tokens (実消費・課金証拠)
- 所要秒数 (リアルAPI通信証拠)
- exit code (0=成功)
- 監査対象プロンプト全文
- Codex応答全文

ユーザーが見るだけで「動いてる/嘘」判定可能なフォーマット。

### 12.5 不一致時の運用

- Claude判断 vs Codex評価の差分を H3「🔴 Lv6差分」で明示
- 一致 → ユーザーへ報告
- 不一致 (技術的観点) → 差分理由分析 → ユーザー判断仰ぐ
- 不一致 (方針観点) → ユーザー方針優先 → ログ蓄積

### 12.6 関連
- `Codex/codex_full_flow_v4.py` - 認証完走スクリプト
- `Codex/HANDOVER.md` - 旧手順 (2026-05-21時点)
- `memory/project_codex_lv6_operational.md` - Lv6稼働状態