症状（PM 実地検証 2026-08-10、Board handoff より）
enabled:true + autonomous_mode:true + has_launch_profile:true + queue 先頭 #3492 の状態で 15 分以上 scheduled scan が一度も走らず、launch が発生しない。issue.monitor.launch_now は priority 先頭化に成功するが scan_requested:false（daemon 不達で publish 失敗）。『next-scheduled-scan が拾う』前提のフォールバックも発火しない。
根本原因（コード調査で確定）
production の GUI-only トポロジには スケジュールスキャンの駆動が存在しない:
- スキャンループ（scan tick）は実 daemon（
gwtd daemon / crates/gwt/src/cli/daemon/server.rs）内にのみ実装されている（daemon 単一 driver 化の帰結）
- しかし production で実 daemon を起動する経路がどこにもない（GUI は
internal://gwt-front-door の placeholder endpoint を startup-cwd scope に書くのみ。DaemonBootstrapAction::Spawn を実際に spawn する caller は皆無）
- GUI 側の local drive（
IssueMonitorScanPolicy::Scan）は frontend event（Monitor UI 表示等）と control commit 時にしか走らず、周期 tick が無い（main.rs イベントループに monitor interval タイマー不在）
つまり「Monitor ON なら next-scheduled-scan が拾う」という全所の前提が production では恒久的に偽。
修正方針（最小・既存アーキテクチャ整合）
GUI に周期 scan tick を追加し、既存の local drive choke point（fence-aware・remote effect authority 判定込み）を周期起動する:
関連: #3492（endpoint scope 非対称）、#3432（gui_connected）、SPEC #3431 FR-108/T-201・Board handoff（session 1186ba69）
2026-08-10 受け入れ条件の補正（PR #3507 取り込み後の RED）
PR #3507 で周期 tick は追加されたが、Unix GUI の claim proposal / local effect driver は cfg(not(unix)) のままで、queue refresh 後に autonomous launch が進まないことを回帰テストで確認した。単純な cfg 解除は live daemon と二重 driver を作るため、以下を完了条件とする。
- daemon authority が無い GUI-only topology で、enabled + autonomous + launch profile + launchable candidate の scheduled tick が claim、pending delivery、launch request のいずれかへ進む。
- live daemon fence がある場合、GUI tick は remote scan / claim / launch effect を生成しない。worker 中に authority が出現しても commit 直前の再確認で fail closed にする。
- remote GitHub scan / effect I/O は tao event loop 外の project-scoped single-flight worker で実行し、重複 tick が worker backlog や UI freeze を作らない。
- queue-only、active launch、needs_human の monitor snapshot が quiet PM の periodic wake を再武装する。prefs から空 queue を再構築して standing work を失わない。
- scheduler / worker spawn failure と remote failure は観測可能である。
- Unix no-daemon / active-fence / duplicate-tick tests、Windows behavior/compile、full Rust verification を実行する。
Scope: SPEC #3431 FR-108(b) corrective task T-217。#3492 の endpoint scope・real daemon lifecycle、T-202、T-206 は対象外。
症状（PM 実地検証 2026-08-10、Board handoff より）
enabled:true+autonomous_mode:true+has_launch_profile:true+ queue 先頭 #3492 の状態で 15 分以上 scheduled scan が一度も走らず、launch が発生しない。issue.monitor.launch_nowは priority 先頭化に成功するがscan_requested:false（daemon 不達で publish 失敗）。『next-scheduled-scan が拾う』前提のフォールバックも発火しない。根本原因（コード調査で確定）
production の GUI-only トポロジには スケジュールスキャンの駆動が存在しない:
gwtd daemon/crates/gwt/src/cli/daemon/server.rs）内にのみ実装されている（daemon 単一 driver 化の帰結）internal://gwt-front-doorの placeholder endpoint を startup-cwd scope に書くのみ。DaemonBootstrapAction::Spawnを実際に spawn する caller は皆無）IssueMonitorScanPolicy::Scan）は frontend event（Monitor UI 表示等）と control commit 時にしか走らず、周期 tick が無い（main.rsイベントループに monitor interval タイマー不在）つまり「Monitor ON なら next-scheduled-scan が拾う」という全所の前提が production では恒久的に偽。
修正方針（最小・既存アーキテクチャ整合）
GUI に周期 scan tick を追加し、既存の local drive choke point（fence-aware・remote effect authority 判定込み）を周期起動する:
IssueMonitorScanPolicy::Scanの local drive を駆動関連: #3492（endpoint scope 非対称）、#3432（gui_connected）、SPEC #3431 FR-108/T-201・Board handoff（session 1186ba69）
2026-08-10 受け入れ条件の補正（PR #3507 取り込み後の RED）
PR #3507 で周期 tick は追加されたが、Unix GUI の claim proposal / local effect driver は
cfg(not(unix))のままで、queue refresh 後に autonomous launch が進まないことを回帰テストで確認した。単純な cfg 解除は live daemon と二重 driver を作るため、以下を完了条件とする。Scope: SPEC #3431 FR-108(b) corrective task T-217。#3492 の endpoint scope・real daemon lifecycle、T-202、T-206 は対象外。