# 反省ログ 2026-06-29

## 1341-A セッション再開の時計ズレ再発（bash date が5日古い 2026-06-24 を返した）

### 事象
jarvis起動シーケンスの bash `date` が `2026-06-24` を返したが、実際の今日は `2026-06-29` だった。systemContext の currentDate＝2026-06-29、iMessage 送信 verify の実時刻が 6/29 13:41 だったことで発覚。この結果、起動シーケンス記録（self_check_log/2026-06-24.md 1332-05 等）が5日古い日付で書かれていた。

### 真因
1. **セッション再開時の環境時計ズレ**：マシンスリープ/再開・Drive同期・ホスト時刻の遅延等で bash `date` が古い値を返すことがある。[[feedback_session_resume_clock_skew]] の再演。
2. **date の単一ソース鵜呑み**：起動シーケンス手順が bash `date` 1本に依存しており、systemContext currentDate との突合を怠った。
3. **過去に同種事案があるのに照合運用が定着していなかった**（再発＝仕組み化不足）。

### 是正（本ターン）
- 本反省で経緯保全。古い日付で書かれた self_check_log は履歴改竄禁止のため非改変。
- セッション再開兆候時は date を鵜呑みにせず、複数ソース（systemContext currentDate・chat.db の最新メッセージ時刻・iMessage 送信 verify の実時刻）で突合してから確定する。

### 教訓（恒久ルール）
- 🛡 起動時は **systemContext currentDate と bash `date` の両方を照合**する運用を強化。食い違ったら systemContext currentDate（および一次データの実時刻）を正とし、bash date を疑う。
- 🛡 「予定」「今日」「これから」等の時系列ワード検出時の date 取得（親CLAUDE.md 起動シーケンス前提ルール）も、bash date 単体ではなく複数ソース突合を前提にする。
- 🛡 [[feedback_session_resume_clock_skew]] の再演＝同種事案は仕組みで止める。記憶に依存した「気をつける」式は不可。

---

## 1341-B 父課金依頼の初動チャネルを「メール」と断定したミス（実際はiMessage送信済）

### 事象
Codex Plus 課金依頼が父（貴浩）に送られたか確認する際、HANDOVER_session_2026-06-24.md に「Gmail下書き」とメール前提で書かれていたため、Gmail 送信箱だけを見て「未送信」と誤報告した。ユーザー「メッセージで送ってる」の訂正で iMessage(chat.db) に切替え、実際は **6/24 に父へ iMessage で送信済み＆父 OK 返信** を確認した。

### 真因
1. **HANDOVER 記載を実績として鵜呑み**：HANDOVER は「メール依頼」と仮説で書かれていたが、それを確定事実扱いして単一チャネル（Gmail）だけ確認した。
2. **「誰かに伝えたか確認」を単一チャネル断定で実施**：家族・近しい相手は iMessage/LINE/電話を日常使いするのに、メールに限定して見た。
3. **一次データでの裏取り不足**：chat.db（iMessage実体）を最初から当てていれば一発で分かった。

### 是正（本ターン）
- HANDOVER_session_2026-06-24.md の課金依頼チャネルを「メール」→「iMessage」に訂正。実態（6/24送信済・父OK・支払い手段が論点）を反映。
- chat.db の送信/受信実績を一次データとして確認し、実績ベースで報告し直した。

### 教訓（恒久ルール）
- 🛡 「誰かに伝えたか/送ったか確認」系タスクは**単一チャネル断定を禁止**。家族・近しい相手は iMessage/LINE/電話を含め**複数チャネルを並行確認**する。
- 🛡 **HANDOVER/申し送りの記載は仮説扱い**。実績は一次データ（chat.db・Gmail送信箱・通話履歴等）で裏取りしてから確定報告する。
- 🛡 父への連絡デフォルトチャネルは iMessage（contacts.json 父=+819026461158）。メール前提で動かない。

## 学校Gmail転送ブロック調査・修正（Lv5 Opusが代替案の致命的誤りを訂正）

### 事象
学校Gmail「ritsuha1021へのメールはブロックされました」→下請けOpusがPlaywrightで550バウンス全文実取得→真因=Gmail→Gmail転送の550スパム拒否（判定C）確定。個人側にフィルタ＋連絡先で応急対応。

### 反省（本体の見落とし2件・Lv5 Opusが捕捉）
1. **🔴 POP取得切替を「効かない場合の構造解」として提示したが、Gmailの他アカウントPOP取得/Gmailifyは2026年1月廃止済（今日6/29は廃止後）＝実行不能だった**。外部機能の代替案を「現在も使えるか」確認せず提示＝[[feedback_check_official_docs_first]]違反。Lv5 OpusのWebSearchで発覚・救われた。
2. **フィルタ「迷惑メールにしない」の効力を楽観報告**。550は受信前拒否でフィルタは受信後適用＝ほぼ効かない。「数日観察すれば」は楽観的すぎた。正直には「効果薄・観察は念のため」。

### 学習
- 🛡 外部サービスの代替案は提示前にWebSearchで現行可否を確認（特に「廃止」リスクのある古い機能=POP/Gmailify/旧API）。
- 🛡 SMTP 550=受信前拒否。受信後適用のフィルタ/ラベル/振り分けでは直らない。レイヤーを取り違えない。
- 🛡 Lv5は**Opusでメリット最大**（WebSearch裏取りで本体の事実誤認を訂正）＝[[feedback_subagent_always_opus]]の生きた傍証2例目。

### 下請けの自己反省（記録）
- 修正スクリプトで `time.sleep=None`/`=5` と time.sleep をローカル代入で誤上書きするタイポを1セッション3回。Playwrightスクリプトで time.sleep を変数代入しないルール徹底。