## 2026-06-14 Jarvis系グループ化 過剰置換→全リバート(backup-firstで完全復旧)

### 事象
Jarvis本体系8フォルダを Jarvis/ に移動＋mdリンク一括置換。'dashboard/'→'Jarvis/dashboard/' が外部パス ~/jarvis-dashboard とURL localhost:8765/dashboard/ の中の同綴りにマッチし96ファイル破壊(~/jarvis-Jarvis/dashboard 等)。システムのファイル変更差分通知で即発覚。

### 是正
ユーザー提案で先に取ってたバックアップ(CLAUDE.md/clone-jarvis CLAUDE.md/settings.json)＋ md一括リバート(Jarvis/<8名>/→<名>/ 97ファイル)＋フォルダを直下に戻す→16フォルダ消失ゼロ・壊れパターン0・起動22ファイル健全・People/Business/School無事 を実測確認。

### 真因/教訓
People/Business/School の固有名(Stack/倫翔/ボカロ部)は安全だったが、Jarvis系の汎用名(dashboard/memory/tools)は外部パス・URL・harnessパスの中に埋まってて単純置換で破壊。→ inspection_lessons L9。backup-first(ユーザー提案)が完全復旧を可能にした。

### 次の方針
Jarvis系グループ化は汎用名の文脈ガード or 1フォルダずつ手作業が必要。現状3箱(25→15)で十分綺麗なので、Jarvis箱は無理せずユーザー判断を仰ぐ。

## 2052-A セッション再開で5日分の時計ズレ・起動シーケンスを誤日付で実行（別セッション系）

### 事象
別のjarvis起動セッションが 6/09 22:33 開始 → 6/14 20:52 再開（「Continue from where you left off」を挟んだ）。起動時 `date` と systemContext currentDate が 6/09-6/10 のまま固着し、起動シーケンス（Gmail監査・self_check_log記録）を6/09基準で実行。父へのSSD相談iMessage送信の verify（chat.db timestamp 6/14 20:52）で5日ズレ発覚→date再実行で実時刻6/14確定。なお本日 20:03 には別の並列セッションが実時刻6/14を正しく認識して起動済（self_check_log 2003-01）＝固着したのは片方のセッションのみ。

### 真因
- セッション再開時に systemContext currentDate と Bash date が古い値で固着（並走する他セッションは正常＝セッション個別現象）
- 「時系列ワード検出時 date 必須」は守ったが date が6/09を返したため正しいと誤認・セッション再開自体を疑わなかった
- send.py verify の独立 timestamp が無ければ気づけなかった

### 是正
- Gmail監査を newer_than:6d で再クエリ→6/08-6/14の重要メール0件＝取りこぼしなし確認
- feedback_session_resume_clock_skew.md 新設＋MEMORY.md index追加
- 誤日付ログ(2026-06-09.md/2026-06-10.md)は書換えず6/14.mdに正記録

### 学習
- 🛡 セッション再開検出時は起動時dateを鵜呑みにせず複数ソース(date/chat.db/mtime/他セッションログ)で実時刻突合
- 🛡 「dateを打った=正しい時刻」ではない・再開でdate自体が古い値を返しうる