<!-- 司令塔/REMINDER.md の part2/3（行471-726・残り未対応エントリ）。前：司令塔/REMINDER.md / 次：司令塔/REMINDER_part3.md。 -->

# 司令塔/REMINDER.md part 2/3 — 残り未対応エントリ

---

### #23 学校アントレ TOP10事業案シート読了→TOP3絞り込み→TOP1深掘り→軸②本業始動

- **登録日：** 2026-05-11
- **ステータス：** 🟡 ユーザー読了待ち（「あとで読んどく」発話済・タスク溜まりでセッション閉じ）
- **🔒 出場大会名は凍結（大会名特定できず・2026-06-09時点で保留）：** ユーザー確認「NECが主催するやつらしいが、前調べた時もNECの該当大会が見つからなかった→よくわからん」。NEC主催説は維持だが**特定の大会名は不明のまま**。過去の調査メモ（NEC Future Creationプログラム本命説）は実体消失済（参照先ファイルは存在しないためリンク削除）。**大会名探索パートはこれ以上追わず凍結。** 本タスクは本体タスク（TOP10事業案読了→TOP3→TOP1本業始動）に一本化する。
- **作業内容（本体タスク）：**
  1. TOP10深掘りシート10本（計207KB・出典194件）を読む
  2. TOP3を選ぶ
  3. TOP1を軸②本業事業として正式始動
  4. 学校アントレ用ナラティブも同事業で固定（軸③共有）
- **アクセス手段：**
  - ビューアURL：http://localhost:8765/School/school_task/antre/top10/viewer.html
  - dashboardカード「🏆 学校アントレ TOP10 事業案」から起動可
  - 元実体：`起業フォルダー/School/学校課題在庫/アントレ授業/事業案100ブレスト/TOP10_DEEP/`
- **着手条件：** ユーザー読了発話 or 「TOP3決めた」発話
- **完了条件：** TOP1事業案確定・軸②本業事業として正式始動・学校アントレ全提出物の事業案がTOP1で固定
- **3軸主軸構造：** memory/project_three_pillars.md
- **毎ターン報告対象。**

---

### #22 時間割カレンダー移動（🔴学校Workspace管理者制限で共有経由不可・方針転換待ち）

- **🔴 2026-06-08 判明：** Playwright自動化で学校アカ(2023s0047)から時間割カレンダーを ritsuha1021 に共有試行→**学校Workspace管理者が組織外ドメインへのカレンダー共有を禁止**しており物理的に不可(送信完遂もサーバがサイレント拒否・共有リストに永続しない)。**ユーザー手動でも同じ管理者制限で不可。** 詳細→[memory/feedback_school_workspace_external_share_blocked.md](memory/feedback_school_workspace_external_share_blocked.md)。
- **➡ 代替案(要ユーザー判断)：** (C)共有経由をやめ ritsuha1021側に新カレンダー「時間割」を作り primaryの92件を移動(共有不要・Jarvis完結可) / (iCal)時間割をsecret addressで個人カレンダーに購読(閲覧のみ) / (管理者)学校ITに外部共有許可を依頼。
- 🔴 **92件のbulk move/delete は1件試験→確認→残り展開 必須**([memory/feedback_staged_rollout_before_bulk_destructive.md](memory/feedback_staged_rollout_before_bulk_destructive.md)・2026-05-11に92件削除事故あり)。実行前にユーザー判断に上げる。
- 以下は旧本文(履歴・共有前提の旧手順)。
- **登録日：** 2026-05-11
- **ステータス：** 🔴 共有経由不可確定・代替案(C)のユーザー判断待ち
- **詳細手順（ユーザー作業）：**
  a. PCのChromeまたはSafariで学校アカ（2023s0047@shiba-kokusai.ed.jp）にログイン
  b. calendar.google.com を開く
  c. 左サイドバー「マイカレンダー」→「時間割」→ 3点メニュー → 「設定と共有」
  d. 「特定のユーザーやグループと共有する」→「ユーザーやグループを追加」
  e. `ritsuha1021@gmail.com` を「予定の変更」権限で追加
  f. 「送信」ボタン押す
- **Jarvis側作業（権限付与後）：**
  g. primaryの時間割92件を「時間割」カレンダーへ移動（4 Agent並列）
  h. primary側は削除
- **カレンダーID：** `c_d548c64aac8eed76ec7aad857e79fe132c1f402a78230cfde32ce9e51dcf1bd4@group.calendar.google.com`
- **完了条件：** 時間割が「時間割」カレンダーに移動完了・primaryから削除完了・月表示で他予定が見えるようになる
- **着手条件：** ユーザーから「時間割共有した」発話
- **詳細：** `clone-jarvis/jarvis/handover/HANDOVER_timetable_move_2026-05-11.md`
- **毎ターン報告対象。**

---

### 🟡 #21 ロイロノート通知→カレンダー自動化（2026-06-08 転送確認リンク踏破→実転送待ち）

- **🔴 2026-06-29 真因確定＝Gmail→Gmail転送が550スパム拒否（転送設定じゃ直らない構造問題）：** 学校Gmailに「ritsuha1021へのメールはブロックされました」表示→Playwright実調査でバウンス全文取得 `550 5.7.1 ... likely unsolicited mail ... blocked`（mailer-daemon→学校アカへ返るDSN）。学校側設定は完全正常・管理者ブロックなし。真因＝Gmail→Gmail転送でSPF/DKIM/ARC認証が崩れ未認証扱い→個人側Gmailが受信前に550拒否（Lv5 WebSearch裏取り: indichosts/suped）。
  - **応急対応（実施済・効果薄）：** ritsuha1021側にフィルタ「from:(shiba-kokusai.ed.jp OR classroom.google.com OR loilonote.com OR loilo.tv)→迷惑メールにしない＋重要マーク」作成＋連絡先2023s0047登録。⚠️ 550は受信前拒否でフィルタは受信後適用＝ほぼ効かない見込み（数日観察するが期待薄）。
  - **🔴 POP代替は不可：** Gmailの「他アカウントPOP取得/Gmailify」は2026年1月廃止済（support.google.com/16604719）。プル型回避は使えない。
  - **✅ 本命解＝転送は諦め Jarvis集約に一本化：** Jarvisが起動毎に学校アカ(Playwright authuser=1)を直接読んで個人側に集約済＝実害メール取りこぼしゼロ。完全自律化したいなら学校アカのIMAP定期巡回常駐化が次の構造解（POP廃止の影響を受けないIMAPは生存）。
  - **✅ 2026-06-29 転送OFF実施済（Playwright・再読込で確証）：** 学校アカ(authuser=1)で「転送を無効にする」を選択保存・再読込後も維持を目視確認。転送先ritsuha1021は**削除せず無効化のみ＝可逆**。これで学校アカに戻ってたバウンス「ブロックされました」表示は停止。loiloラベルフィルタは存続（消してない）。
  - **🔴 #21の方針＝「転送修復」を放棄し「Jarvis学校アカ直読み集約」に置換してオープン継続。** 完全クローズ条件＝**学校アカIMAP定期巡回の常駐化**（未着手）。それまでは起動シーケンス手順5/6の学校アカ直読みが代替手段。「実転送待ち」「実着信確認」は今後追わない（転送破棄したため永遠に来ない＝追うのは誤り）。
  - **✅ 2026-06-29 loilo監査の参照元 付け替え済：** 起動シーケンス手順6のロイロ監査を**学校アカ(2023s0047)直読み(Playwright authuser=1)**に変更。実装＝`tools/playwright/loilo_school_read.py`（共用Profile・authuser=1・`tr.zA`スクレイプ）。feedback_loilo_submission_auto_calendar.md を全面書換（§1参照元/§2本文取得/§6-7重複防止/§9空振り/§10前提を学校アカ直読みベースに更新・転送経由MCP設計を廃止明記）。
    - **🔴 実測の重大発見（要ユーザー確認）：** 学校アカ直読みで `label:loilo` も `from:loilonote.com OR loilo.tv` も **newer_than:14d で0件**（"検索条件に一致するメール…"バナー）。提出物/課題通知は実際には **Classroom(no-reply@classroom.google.com)** で届いている（14d で24件）。ロイロ提出箱メールが学校アカに来ているか自体が不確実＝ロイロアプリのメール通知ON設定 or 提出箱通知の有無を要確認。loiloが恒常0件なら課題監査をClassroom経由(手順7 todo補足)へ一本化が実態的。
- **✅ 2026-06-08 転送確認リンク踏破完了（Jarvis自動）：** 個人アカ(ritsuha1021/authuser=0)の2026-05-01 forwarding-noreply 確認URLを Playwright(共用Profile)で開き「確認」ボタンクリック→「確認が完了しました／2023s0047@shiba-kokusai.ed.jp は ritsuha1021@gmail.com にメールを転送できます」表示をスクショ目視確認(visual_check_fwd_confirm_1/2.png・Read tool実画像照合済)。38日経過してもリンクは有効だった
  - これで宛先ritsuha1021の「未確認」状態が解消→転送が実効可能に
  - **🔴 残課題：** 実際にメールが転送されるのは**確認完了後の新着メールから**。過去メールは遡及転送されない。次回起動時に個人アカ受信箱を `from:shiba-kokusai OR Classroom OR loilo newer_than:2d` で再検索し、転送コピーが実着信するか最終確認すること。確認できたら本エントリ完全クローズ
  - スクリプト：tools/playwright/confirm_forwarding.py
- **🔴 2026-06-08 反証検証で「設定ON・実転送ゼロ」判明（上記で解消済の旧診断）：** 設定画面ON表示=実転送成功ではなかった。実証拠：
  - 個人アカ(ritsuha1021)受信箱を `from:forwarding-noreply` /Classroom/loilo/shiba-kokusai で newer_than:30d 検索 → **転送メール0通**。届いてる学校origin 2通(カレンダー共有/Drive共有リクエスト)はいずれも `toRecipients=ritsuha1021` の直送で転送ではない
  - 一方 学校inbox(u/1)実DOM確認 → 6/4〜6/7に文化祭注意事項【重要】/川角先生Classroom/飯塚先生連絡/課題「映画音楽」/物質と電流/Lesson2 Exit Ticket/単元テストリトライ 等が**毎日着信**。これらの転送コピーが個人側に1通も無い＝転送が実効してない確証
  - forwarding-noreply@google.com からのメールは **2026-05-01の確認リクエスト1通のみ**。「転送が有効になりました」確認完了メールも、6/8新設定の新確認リクエストも無い
- **原因濃厚：** 2026-05-01の転送確認リンクが未クリック → 宛先ritsuha1021が「未確認」状態のまま。Gmailは未確認宛先を転送ラジオで選択させる(UIはON表示)が、実際には未確認宛先へは転送しない仕様。だから「設定ON・実転送ゼロ」が成立
- **設定DOM実値(2026-06-08確認)：** u/1=2023s0047@shiba-kokusai.ed.jp で「受信メールを ritsuha1021@gmail.com に転送し受信トレイに残す」ラジオ選択+宛先入力にritsuha1021あり。loiloラベル(学校側サイドバー)実在OK。→ 設定要素は揃ってるが「確認」が抜けてる
- **要対応(ユーザー or Jarvis)：** ①個人アカ受信箱の2026-05-01確認メールの確認リンクを踏む(まだ有効なら) or ②学校側で転送宛先を再追加→新規確認メール発火→個人側でリンク確認、を完了させる。完了後に学校origin実メールが個人側に転送されるか再テスト必須
- **格下げ：** ✅完了 → 🔴 blocked/partial（設定は揃うが実転送未成立）
- 以下は旧「完了」記録(誤判定・履歴として残置)。
- **登録日：** 2026-05-11
- **ステータス：** 🟡 Phase 1（ユーザー手動・学校Gmail転送設定3分作業）待ち
- **Phase 1作業（ユーザー本人）：**
  1. 学校Gmail(2023s0047@shiba-kokusai.ed.jp)を開く
  2. 設定 → すべての設定を表示 → メール転送とPOP/IMAP → 転送先追加 `ritsuha1021@gmail.com` → 確認メールリンク踏む（Jarvis側で踏める）
  3. フィルタとブロック中のアドレス → 新しいフィルタ作成
  4. From: `*@loilonote.com OR *@loilo.tv OR loilo` を入れる
  5. ✅ 転送する: ritsuha1021@gmail.com / ✅ ラベル付ける: loilo（新規作成）
  6. ロイロアプリ → 設定 → 通知 → メール通知 ON / 送信先=学校Gmailを確認
- **Phase 2作業（Jarvis自動）：** サンプル1通来たらJarvis起動シーケンスにロイロ監査追加（仕様は memory/feedback_loilo_submission_auto_calendar.md）
- **着手条件：** ユーザーがPhase 1完了報告 or サンプルメールが ritsuha1021 に到達
- **完了条件：** ロイロ提出物期限が学校アカ側カレンダーにピーコック色で自動追加される状態
- **毎ターン報告対象。**

---

### #24 Slack通知→Jarvis経由カレンダー/集約処理（着手保留・大方針一部）

- **登録日：** 2026-05-11
- **ステータス：** 🟡 着手保留（ユーザーが「今は作業しない・メモだけ」発話・司令塔/MEMO.md中長期目標「外部通知集約」の構成要素）
- **構想：** Slackに来た通知（メンション・DM・チャンネル投稿・スレ返信等）をJarvis経由で取得→重要度判定→必要なら自分専用カレンダー/通知箱へ集約
- **既存資産：**
  - Claude.ai Slack MCP（slack_read_channel / slack_read_thread / slack_search_public_and_private / slack_send_message 等）が認証済・使える状態
  - 既にiMessage/Gmail/LINEの「送信」は統一CLI `tools/send/send.py` でチャネル抽象化済 → 受信側も同じ思想で抽象化したい
- **想定パイプライン（実装時）：**
  1. Jarvis起動シーケンスで slack_search_public_and_private で「未読 OR メンション含み OR 自分宛DM newer_than:1d」検索
  2. 重要度判定（ユーザー宛・期限ワード・人物優先度）
  3. 期限ワード含むものはGoogleカレンダーに `[Slack] 件名` で追加（自分専用カレンダー側）
  4. それ以外は「自分専用通知箱」（dashboard上の集約カード or 専用ファイル）に投入
- **着手条件：** ユーザーが「Slack通知集約着手」発話 / 司令塔/MEMO.md中長期目標「外部通知集約」が優先化された時
- **完了条件：** Slack通知が自分専用カレンダー or 集約箱に自動投入される状態
- **関連：** REMINDER #21（ロイロ・同じ集約思想の構成要素）/ 司令塔/MEMO.md「🌌 中長期目標：外部通知集約（Gmail/ロイロ/Slack→自分専用処理場所）」
- **毎ターン報告対象。**

---

### #11 🔒🔥 Burn rate ペナルティ仮説の検証（機密）

- **登録日：** 2026-05-05
- **ステータス：** 🟡 仮説段階・要検証（観測3回連続で同パターン出たら確定扱い）
- **🔒 機密扱い（2026-05-05ユーザー方針）：** 配布Jarvis・他人共有・SNS発信すべて禁止。「他Jarvisクローン・他人Jarvisと圧倒的差をつけられる技術」としてユーザーが内密化指示。詳細ルール：memory/project_burnrate_penalty_hypothesis.md 冒頭ブロック
- **仮説：** Maxプラン5h枠の真の上限値が消費ペース（burn rate）と逆相関する
- **観測根拠：**
  - 観測④（低ペース・Jarvis少）：上限逆算 270M tokens
  - 観測⑤（中ペース）：上限逆算 204M tokens
  - 観測⑥（並列3体ハイペース）：上限逆算 155M tokens
  - 単調減少。pure偶然なら確率低い
- **確定すれば重大含意：**
  - Jarvis並列ドクトリン（速度最優先）と真っ向対立
  - 「ゆっくり消費が結果的に多く働ける」可能性
  - 他Maxユーザーへの共有で競争優位
- **検証ステップ：**
  1. Jarvis 1体・低ペース運用で観測 → ダッシュ vs 本家ぴったり一致するか
  2. 並列止めて1h待機後、真の上限値が回復するか
  3. Anthropic Discord/GitHub issuesで rate-based throttling 言及調査
- **着手条件：** 並列稼働が落ち着いたタイミング、または明日以降の通常運用時に低ペース観測
- **詳細：** memory/project_burnrate_penalty_hypothesis.md
- **毎ターン報告対象。**

---

### #16 🔴 MARK Ⅶ：能動型 Jarvis（A/B/C完了・base誤認識でD・Eブロック中・要small戻し）

- **登録日：** 2026-05-06
- **更新：** 2026-05-06夜 残A・B完了 / **2026-05-07 残C完了（軽量化）→base誤認識でwake_word拾えず実証→smallに戻す要修正**
- **ステータス：** 🟡 A・B・C完了・**base日本語認識弱でwake_word不発判明・smallに戻し作業必要**・その後D・E
- **完了済：**
  - ✅ silence trigger 完全廃止（intervention_filter/mode_controller/daemon 3ファイル）
  - ✅ resource_guard v1.1.0 whisper-cli厳密一致・whisper-stream除外（実証済）
  - ✅ バグA: 連打防止 hash→offset方式
  - ✅ バグB: output_dispatcher mirror Popen非同期化
  - ✅ バグC部分: 介入後bufferクリア＋ハルシネーション行除去拡張＋health計測ログ
  - ✅ バグD: wake_word検出直後の即時「はい」（macOS say・claude経由なし・0コスト）
  - ✅ MARK Ⅶ 音声化 実機初動作実証（2026-05-06 17:44）
  - ✅ **残A: question trigger 誤検知対策**（2026-05-06夜・`_QUESTION_*_RE` 3分割＋`_detect_question()` 新設・単独「？」「ん？」「うーん？」スルー・疑問詞共起のみ通す・テスト6件追加）
  - ✅ **残B: wake_word ハルシネーション除外**（2026-05-06夜・`_WAKE_WORD_HALLUCINATIONS` リスト新設・「ジャビスキョイター」等5語除外・テスト4件追加）
- **PC熱問題（実マイク再テスト中断の根本原因）：**
  - Load Avg 23.43（通常2〜4の6〜10倍）でCPU throttling発生
  - 「はい」即時応答が数秒遅延・claude応答も14秒級
  - 実装バグではなくハード負荷・ユーザー判断で全停止・数時間後再開
- **次セッション残作業（要 base→small 戻し → D → E）：**
  - ✅ A. question trigger 誤検知対策（2026-05-06夜 完了）
  - ✅ B. wake_word マッチ強化（2026-05-06夜 完了）
  - 🟡 **C. 軽量化**（2026-05-07 完了・ドクトリン「応答速度＞継続稼働＞精度」確定）：
      - ✅ whisper small→base（stream_transcriber.py L30）／🔴 **実マイクで「ジャービス」を「じゃ、ビス」「ジャビスキョイター」等にハルシ→wake_word不発判明**
      - ✅ daemon loop 1秒→2秒（jarvis_active_daemon.py LOOP_INTERVAL_SEC=2.0）
      - ✅ ggml-base.bin DL済（141M・配置：clone-jarvis/jarvis/live_session/models/ggml-base.bin）
      - ✅ sonnet継続
      - 🔴 **要修正：stream_transcriber.py を ggml-base.bin → ggml-small.bin に戻す**（既存small bin 465M保持中）
      - 残課題：base/medium で日本語認識精度不足の場合は Core ML 変換 or whisper-stream の `--step 500→1000` 検討（応答速度優先で頻度減らす）
  - **D. health.jsonl 分析**：再テストで蓄積データから「時間経過で反応しなくなる」真因特定
  - **E. 実マイク再テスト＋MARK Ⅶ正式昇格判定**：5分連続稼働でclaude介入10回以下確認後に昇格
- **🔴 着手手順（次セッション最初にやる）：**
  1. `stream_transcriber.py` の `ggml-base.bin` を `ggml-small.bin` に戻す（5分・Edit 1箇所）
  2. dry-run確認
  3. `bash live_run_v3.sh` で起動 → 「ジャービス、聞こえる？」発話 → 即時「はい」＋claude応答確認
  4. 5分連続稼働テスト（claude介入10回以下なら昇格判定）
- **着手条件：** ユーザーが「MARK Ⅶ再開」発話
- **完了条件：** 5分連続稼働で claude -p 介入が10回以下＋音声で複数回往復会話成立＋即時「はい」が毎回0.5秒以内
- **🔴 完全引継ぎ資料：** `clone-jarvis/jarvis/handover/HANDOVER_mark7_resume.md` ＋ 司令塔/MEMO.md「現セッション（MARK Ⅶ silence暴走修正…2026-05-06夕方）」セクション
- **毎ターン報告対象。**

---

### ✅ #17 dashboard アプリ化リトライ（Safari Web App 真っ黒問題・PWA化要検討）（2026-06-08完了）

- **✅ 2026-06-08 クローズ（status=done・Lv5 confirmed・Lv6 OK）：** dashboard PWA化完了(目次L72)。manifest.json + sw.js(Service Worker)追加・既存13カード非破壊維持。Safari Web App真っ黒問題(manifest/SW不在が原因)の根本解消。以下は旧本文(履歴保管)。
- **登録日：** 2026-05-07
- **ステータス：** 🟡 当面 Safari 通常タブ運用で済ませる方針・将来余裕がある時に Web App 化リトライ
- **背景：**
  - 2026-05-07 Chrome dashboardタブが 2.03GB 占有していた問題に対処
  - Safari Web App 化を試みた → `~/Applications/J.A.R.V.I.S DASHBOARD.app` 生成成功・181MB起動
  - **だが Web App ウインドウが真っ黒で固まる**（kill→cache削除→再起動でも復活せず）
  - 原因推定：dashboardが PWA未対応（manifest.json無し・HTTPS無し・Service Worker無し）→ Web App が空白で固まる
- **当面の運用（決定）：** Safari 通常タブで `http://localhost:8765/dashboard/index.html` を開く・タブ固定（メニュー：表示→タブを固定）
- **副次成果（記録）：**
  - Chrome 完全終了で **約1.91GB メモリ解放** 達成（Load avg 2.30→2.06）
  - dashboard 配信ルート修正（`--directory` 明示・ホーム公開セキュリティ事故修正）→ memory `feedback_localhost_serve_root.md`
  - agent_fleet_monitor.py 2重起動修正（launchd unload + start.sh一本化）
- **着手条件（リトライ時）：**
  - 余裕があるタイミング・現在 .app は ~/Applications/J.A.R.V.I.S DASHBOARD.app に残してある
- **手順案（次回リトライ時）：**
  1. dashboard の PWA化（manifest.json 追加・Service Worker 追加・「中央コクピット」用途的にHTTPS不要なのでlocalhostのまま）
  2. `~/Applications/J.A.R.V.I.S DASHBOARD.app` を一旦削除
  3. Safari → dashboard開く → 「Webアプリとして追加」で再生成
  4. 真っ黒問題が解消するか検証
- **完了条件：** Web App が dashboard を正常表示・Chrome 完全脱却維持・体感軽量
- **毎ターン報告対象。**

---

### #19 🔴 チャットJarvis構築（実装保留中・MARK Ⅹ世代の最終目標）

- **登録日：** 2026-05-10
- **ステータス：** 🟢 構想確定・🟡 実装保留中（MARK Ⅶ/Ⅷ完成後に着手）
- **構想：** 単一会話Jarvis（チャットJarvis）が複数作業Jarvisにタスク分配する非同期常時会話システム
- **最終構成：** iPhone+AirPods+ゲーミングPC（Linux化）の3点セット
- **MacBook位置付け：** MARK Ⅶ/Ⅷ開発期限定の足場・MARK Ⅹで不要化
- **詳細：** memory/project_chat_jarvis_architecture.md
- **着手保留の理由：**
  - MARK Ⅶ/Ⅷ未完成（base→small戻し・D・E残り）
  - ユーザーキャパ律速（プロンプト供給が追いつかない）
  - Linux化の物理作業時間確保困難
  - 大型案件で構成検討に時間かけるべき
- **着手条件：** MARK Ⅶ/Ⅷ昇格判定完了 ＋ ユーザーが「チャットJarvis着手」を明示
- **着手時の最初の作業：**
  1. ゲーミングPC実スペック確認
  2. Windowsデータバックアップ計画（残したいもの列挙）
  3. 学校Windows必須ソフト確認
  4. 貴浩相談（必要な周辺機器あれば）
  5. Ubuntu LTS インストール
- **毎ターン報告対象（着手目安が立つまで永続表示）。**

---

### #20 統一送信パイプライン稼働確認

- **登録日：** 2026-05-10
- **ステータス：** 🟡 実装完了後に実証テスト必要（テスト送信は本人宛 or 父宛で1通やる）
- **着手条件：** `tools/send/` 実装完了 ＋ ユーザーが「テスト送って」発話
- **完了条件：** 父宛 iMessage / 暦宛 Gmail / 暦宛 LINE の3チャネル全部 `send.py` 経由で疎通確認
- **背景：** 並走Agentが `tools/send/send.py`（統一CLI）・`contacts.json`（宛先テーブル）・`line_send.py`+`line_send.applescript`（LINE UI制御）を実装中（2026-05-10）
- **毎ターン報告対象（実証テスト完了まで）。**

---

### #18 倫翔 self_check.md 配布フィードバック待ち

- **登録日：** 2026-05-10
- **ステータス：** 🟡 倫翔からのフィードバック待ち（送信済 15:44）
- **送信内容：** Gmail下書き → ユーザー手動送信完了。本文 + self_check.md フル344行埋込
- **倫翔に伝えた限界：**
  - Lv2 Windows非対応（launchctl/plutil/awk/bash構文）→ 手動確認 or PowerShell書換え必要
  - Lv5 判断ベース未育成で再現度7〜8割
  - Lv1/Lv3/Lv4 は環境依存ゼロでそのまま動く
- **想定フィードバック：**
  - 動かない/エラー/Windows対応版が欲しい → §8.1 PowerShell代替版を作って追送
  - 「自分の判断ベース」って何？ → 倫翔向けクローンDNAテンプレ作って追送（Mk Ⅱ相当へ昇格）
  - 反応なし → 1週間後に自分から「使ってみた？」確認
- **着手条件：** 倫翔から返信 or 1週間（2026-05-17）経過
- **完了条件：** 倫翔が実際にself_checkを動かせる状態 or 倫翔判断で「不要」回答
- **毎ターン報告対象。**

---

### #14 合言葉「ジャービス会議開始」でlive_run.sh起動の仕組み

- **登録日：** 2026-05-06
- **ステータス：** 🟡 設計検討中・優先度低
- **背景：**
  - Phase 1 Whisper常駐レイヤー完成（2026-05-06）
  - 現状：dashboardボタン or `live_run.sh` 直叩きで起動
  - ユーザー方針（2026-05-06発言）：「録音機能だけの時とそれじゃない時で使い分けたい・絵をやる心構えがまだ」
  - → 当面は手動起動でOK・将来Jarvis経由音声起動を追加
- **仕様（着手時）：**
  - Jarvisセッション中に「ジャービス会議開始」「ジャービス録音開始」発話 → Claude側が live_run.sh を起動
  - 「ジャービス録音終了」で停止
  - dashboardボタンと並走可能（どちらでも操作OK）
- **着手条件：** ユーザーが「録音操作を全部Jarvisに任せたい」「合言葉化したい」等を発話した時
- **完了条件：** 合言葉発話で live_run.sh が起動・停止できる
- **毎ターン報告対象。**

### ✅ #15 resource_guard.py Python 3.9 構文エラー修正（2026-05-06 完了）

- **完了：** v1.1.0 リリース時にOptional化＋Dict化で同時修正
- **動作確認：** sync.sh 実行で v1.1.0 起動成功・pid 46862 で稼働中・MARK Ⅶ 実走時に whisper_long kill 0回（whisper-stream除外も同時に効いてる）
- **下記完了済セクションへ。次回 REMINDER 整理時に削除可。**


---

## ⏭ 続き

- 前：[司令塔/REMINDER.md](司令塔/REMINDER.md)
- 次：[司令塔/REMINDER_part3.md](司令塔/REMINDER_part3.md)