上流 fujibee/agmsg v1.1.7 を fork main に取り込む

[orangewk]

背景

fork main は上流 v1.1.6 相当で止まっており、上流は v1.1.7(app v0.1.5)まで進んでいる。fork 側には remote sync(git-bus)関連の独自実装が main に載っているため、単純 fast-forward は不可でマージ作業が必要。

やること

1. git remote add upstream https://github.com/fujibee/agmsg.git && git fetch upstream
2. 上流 v1.1.7 タグ(なければ upstream/main の該当時点)を fork main にマージ
3. コンフリクト解消。fork 独自の remote sync 機能を必ず温存すること:
   • scripts/remote.sh, scripts/lib/sync.sh(git-bus 同期のコア)
   • scripts/check-inbox.sh / scripts/inbox.sh の pull フック + sync_mark_read / sync_push_best_effort 呼び出し
   • scripts/send.sh のバックグラウンド push、scripts/watch.sh の remote_pull_interval
   • tests/test_remote_sync.bats、docs/remote.md / docs/remote.ja.md
4. 上流 v1.1.7 の主な変更(role-to-session affinity、Windows 修正、app のターミナル注入配信)が壊れていないか確認
5. bats tests/ 全緑を確認して PR

注意

• fork main の直近履歴: feat(remote): git-backed bus transport for multi-environment messaging (ADR 0005 MVP) #14 → fix(remote): address PR #14 review — monitor-path pull, honest push failures, per-team bus namespace #18 → feat(remote): ephemeral-environment ops — history cutoff (#19), pinned env ids (#15), one-line bootstrap (#17) #20 → fix(remote): replicate read receipts across environments #21(read receipt replication, 841f60a)。これらのマージ後の状態が基準。
• 上流には remote sync 系の実装は存在しないので、scripts/lib/sync.sh などは「fork 側を残す」一択。競合しやすいのは check-inbox.sh / inbox.sh / send.sh / watch.sh のような両側で触っているファイル。

(このタスクは別ランナーへのハンドオフ用。上流リポジトリへのアクセス権があるランナーで実行すること)

[orangewk]

スコープ更新 (2026-07-15): 上流の現在地と追加タスク

上流の状況が動いたので、このハンドオフの内容を最新化する。

上流の現在地:

• 最新リリースは引き続き v1.1.7(2026-07-13)→ 本 Issue の本文どおりマージ対象。
• fujibee/agmsg PR Codex Desktop: add native Scheduled inbox monitor fujibee/agmsg#375「Codex Desktop: add native Scheduled inbox monitor」(head 681efdb) が open・未マージ。Codex Desktop: opt-in inbox monitor with thread wake and watchdog fujibee/agmsg#374 の可視 wake blocker を解決した実装で、マージされたら二次取り込みが発生する。

追加タスク 1 — v1.1.7 マージ(本文どおり、変更なし)

追加タスク 2 — PR fujibee#375 の実装確認(マージ待ち不要、コードを読むだけ)

fork 側は通知層(ADR 0006, #24)で「空振りの監視チェックがセッション/スレッドのコンテキストを消費する」問題を踏んで externalize した経緯がある。上流の Scheduled monitor が同じ穴を回避できているか、head 681efdb のコードで以下を確認して結果をこの Issue に記録すること:

1. 空 inbox のとき、heartbeat の metadata check はモデルターンを消費するか? スクリプト層で完結する(モデル起動は未読時のみ)ならセーフ。可視スレッドが空振りごとにターンを得る構造なら、コンテキスト恒久消費+可視チャット汚染の問題を抱えている。
2. metadata check の実行主体(automation の実行環境、シェルか model か)と、high-water (max_id) の保存場所。
3. 確認結果は fork の ADR 0006 の wake.kind 統合判断の材料になる(Scheduled monitor を wake.kind: codex-scheduled-monitor として位置づけられるか)。

追加タスク 3 — PR fujibee#375 マージ後の二次取り込み(条件付き)

上流で fujibee#375 がマージされたら、その時点の upstream/main を再度 fork main へマージ。コンフリクト面は本文の注意事項と同じ(remote sync 系ファイルは fork 側温存)。

(このコメントはクラウドセッション側からの更新。実行は上流アクセスのあるランナーで)

---

Generated by Claude Code

[orangewk]

タスク2 実施報告: 上流 PR fujibee#375 (head 681efdb) 実装確認

fujibee#375「Codex Desktop: add native Scheduled inbox monitor」のコードを head 681efdb で読み、スコープ更新コメントの 3 点を確認した。

1. 空 inbox のとき、heartbeat はモデルターンを消費するか?

消費する。 スクリプト層では完結していない。

構造は「ChatGPT native Scheduled task(targetThreadId = 監視対象の可視 Codex タスク)が heartbeat ごとに発火 → そのモデルターン内でシェルツールとして codex-scheduled-monitor.sh check を実行 → 出力の status= を見て分岐」。metadata check 自体は純シェル(本文を読まない・既読化しない)だが、実行主体がモデルターンなので、空振り(status=idle|waiting|not_due)でも 1 発火 = 1 モデルターンが可視スレッドに積まれる。prompt の指示は「idle 等なら inbox.sh を実行しない・ユーザー通知しない」であり、ターン消費と履歴蓄積そのものは防げない。

上流はこれを アダプティブ間隔 + TTL で緩和している(codex-scheduled-monitor.sh の state machine):

• fast: 開始〜30 分は 2 分間隔 (FAST_INTERVAL=120)
• medium: 〜4 時間は 15 分間隔 (MEDIUM_INTERVAL=900)
• slow: 〜24 時間は 1 時間間隔 (SLOW_INTERVAL=3600)
• 24 時間 (TTL=86400) で status=expired schedule_action=pause → Scheduled task 自体を pause
• 新規未読を検知するとサイクルを 2 分間隔へリセット

つまり fork が ADR 0006 で externalize した動機(空振りチェックのコンテキスト恒久消費+可視チャット汚染)は構造的には解消されておらず、bounded(最大 24h/サイクル、逓減間隔)に抑え込む設計。完全放置なら 1 サイクルの空振りは概算 15 + 14 + 20 ≒ 50 ターンで打ち止め。

2. metadata check の実行主体と high-water の保存場所

• 実行主体: ChatGPT の native Scheduled automation(= モデル)。判定ロジックはシェル側 state machine(check → watch-once.sh --claim --timeout 0 → sqlite の未読 metadata から count/max_id のみ取得)で完結し、モデルは status 行を読んで inbox.sh を叩くか否かを分岐するだけ。automation ファイルの直接編集・cron/launchd/シェル heartbeat・Desktop relay・codex exec resume は明示的に禁止(template.md の invariant に明文化)。
• high-water の保存場所: skill の run dir 配下のフラットファイル
  run/codex-scheduled-monitor.<sha1(project,team,name,owner)>.state
  フィールド: last_seen_id / last_delivered_id / pending_id(+ cadence 状態 scheduled_interval, cycle_started_at, expires_at 等)。メッセージ DB とは分離。既読化は従来どおり可視タスクが実行する inbox.sh の責務で、成功後にモデルが delivered <max_id> を呼んで state に記録し、同一 high-water の重複 wake を抑止する。

3. ADR 0006 wake.kind 統合判断の材料

• check が status=wake count=N max_id=M を返す瞬間が fork の notification layer でいう wake イベントに正確に対応する。wake.kind: codex-scheduled-monitor として位置づけること自体は可能。shell state machine(アダプティブ間隔 / high-water / TTL / delivered ハンドシェイク)は wake 判定部品としてそのまま再利用できる。
• ただし fork の externalized チェック(モデル外でチェック、未読時のみモデル起動)と決定的に違うのは wake「判定」の実行キャリアまで ChatGPT Scheduled run(= モデルターン)に乗っている点。fork 側に取り込む場合、check の呼び出し元を外部 waker に差し替えれば「未読時のみモデル起動」に寄せられる構造にはなっている(check は引数と --now だけで動く純シェル)。
• 付記: 同 PR には可視 app-server bridge 用の codex-monitor-lease.sh(unread high-water の短期リース、本文非読)も入っており、wake.kind の別 variant(codex-app-monitor)候補になり得る。

経緯メモ

• PR 内で watch-once + Desktop relay 案は実装・実機検証まで行った上で revert 済み(e14c367, 4c62e8e)。最終形が native Scheduled monitor。
• 上流の実環境 E2E では追加ユーザー入力なしの wake → inbox.sh 可視実行 → delivered 記録まで確認済みと報告されている。
• 本 Issue 確認時点 (2026-07-16) で PR Codex Desktop: add native Scheduled inbox monitor fujibee/agmsg#375 は open・未マージのまま(head も 681efdb から変化なし)。タスク3(マージ後の二次取り込み)は条件未成立。

[orangewk]

タスク1 実施報告: 上流マージ PR 作成済み

• PR merge: 上流 v1.1.8 取り込み (#22 タスク1) #25 — 上流 v1.1.8 を fork main へマージ (Issue 記載時点は v1.1.7 が最新だったが、着手時に v1.1.8 リリース済みだったため orange 承認のもと v1.1.8 まで取り込み)
• コンフリクトは session-start.sh / spawn.sh の 2 件のみ (双方の source 行追加、両方残しで解消)。remote sync 系 fork 独自実装は全て温存 (fork 独自テスト 16 件緑)
• CI 全チェック pass (required の bats ubuntu/macos 含む)
• 付随修正: app ビルドが AGMSG_CORE_REF のタグを origin から fetch する設計のため、上流タグ v1.1.7 / v1.1.8 / app-v0.1.5 を fork へ push 済み (これが無いと app 系 CI が落ちる。今後のリリース追従時もタグ push を忘れないこと)
• 注意: ローカル Windows では bats フルスイートは環境起因で約 70 件落ちる (tmux / pid 解決 / cygpath 系、マージ前から同様)。全緑判定は CI (Linux/macOS) で行うこと

タスク3 (PR fujibee#375 マージ後の二次取り込み) は上流未マージのため未成立のまま。

🤖 Generated with Claude Code

[orangewk]

タスク2 補強: cache 経済の観点 (orange 指摘の取り込み)

上の PR fujibee#375 分析は「空振り 1 発火 = 1 モデルターン、逓減間隔 + TTL で bounded」というターン数の勘定だった。「キャッシュを壊す(跨ぐ)設計は高コスト」の原則を当てると、トークン単価の勘定で評価が一段厳しくなる:

• fast 段 (2 分間隔) は prompt cache の TTL 内に収まりやすく、空振り 1 回は比較的安い
• slow 段 (1 時間間隔) が最悪ケース: 毎回キャッシュ TTL を跨ぐため、空振りチェックのたびに監視スレッドの累積コンテキスト全量を cold 単価で再読込する。「何もしない確認」の単価がスレッドの年齢に比例して膨らむ
• つまり upstream の逓減設計は、ターン数を減らす代償に「1 ターンあたりの単価が最も高い帯」へ空振りを移しており、ターン勘定の合理性がトークン勘定では逆転しかねない

wake.kind 統合判断への含意:

• fork の externalized 方式 (モデル外でチェック、deliverable があるときのみ起床) は、コンテキスト消費ゼロに加えてキャッシュ経済でも空振りコストほぼゼロ。優位性の根拠が一本増える
• upstream の check/delivered/scheduled の shell state machine 部品は引き続き再利用可。ただし取り込むなら実行キャリアをモデルに乗せない(外部 waker から check を呼ぶ)形が前提
• この原則自体を ADR 0006 に amendment として明文化: PR docs(adr): 0006 amendment — wake 判定の cost principle を明文化 #26

[orangewk]

wake.kind 統合判断は #27 へ切り出した。方針転換あり: fujibee#375 の形式 (Scheduled task = モデルキャリア) は cost principle 抵触で不採用方向とし、wake.kind 設計は companion-waker 軸で fujibee#375 非依存に進める。本 Issue のタスク3 (マージ後の二次取り込み) は衛生作業として維持 — 取り込んでも Scheduled monitor は有効化しない。