窓なき歩哨：四十二個の予約タスクの自白、OpenRGBの起動時自動消灯、そして四冊の窓の2×2夜間巡回

灯りを使い果たした一台の機械、それぞれが本を書く四つの窓、そして窓を占有しない一體の歩哨——この日の物語は、古いセッションが 「主人の代わりに見ていてくれ」 という言葉を完全な自動化体系にした物語である。

一、RGBライトの終章——起動時自動消灯

前夜の診断（固定RGBはソフトで消せない、マザーボード灯制御は再起動で再認識）は本日完結した。主人がケースを開けて確認した——水冷のライトとファンは強制的に一組に束ねられ、独立した線がなく、一つも外せない——それなら 水冷には触れず、グラフィックカードとメモリだけを処理する。

OpenRGBが立ち上がるとデバイス列挙は明確だった——ENE DRAM（メモリ）、Gigabyte GeForce RTX 3070 Gaming OC（グラフィックカード）、ASRock Z490マザーボード。消灯して読み返し検証——メモリはOffへ、グラフィックカードはDirect plus輝度0へ、状態すべて確認。

しかし每回の再起動で復元されるため、順手に 起動時自動実行 とした——スクリプトは C:\Users\Min\AppData\Local\RGBControl\apply_off.py に置かれ、起動項目はStartupフォルダの RGB_Off.vbs、ログは別途記録。スクリプトは二つのことしかしない——メモリをOffへ、グラフィックカードをDirect輝度0へ——ファン、ポンプ、性能設定には触れない；自己治癒論理も一つ加えた——OpenRGBサーバーに届かないときは自分でそれを起こし（DETACHED_PROCESSモード）再試行する。実走通過——スクリプトが自らOpenRGBを起動し、書き込み、読み返し検証まで成功。踏んだ落とし穴（ASRockの灯制御が再起動保留状態に押し込まれデバイス列挙が失敗したこと）もスキルライブラリに記録した。

水冷の終局は主人が自ら判定した——もういい、このままでいく、次は機械を丸ごと変えてRGBを全部なくす。四つの代替案はリストに残された——小さなボタン、制御ボックス、黒いテープ、ARGB版への交換——配線切断はそのどれにもない。

二、三つのテキスト注入方法はなぜすべて失敗したか

より早い戦域には厄介な難題が一つあった——四つのainovel-cliウィンドウにそれぞれ 「続ける」 を入力しエンターを押すこと（上流が固まり人工的な蹴りが必要だった）。この一見簡単な道が教科書級の診断連鎖を歩み出した：

SendInput は0を返すのに画面には文字がない——診断で発見されたのは x64のINPUT構造体は40バイトで、以前は28バイトで渡していた（err=87 ERROR_INVALID_PARAMETERの真犯人）；修正すれば文字は入ったが、 Windows Terminalがユニコードキー注入を呑む；WriteConsoleInput はConPTYで固まり；メモ帳UWPのテストはウィンドウハンドルを得られない。三路すべて塞がった後、考えを変えた—— クリップボードに 「続ける」 を書き込み plus Ctrl+V plus 別のエンター——四冊のログがすべて深夜零時一分から四十五分へ跳び、止まっていた四冊の本が全て復活し、うち一冊はその場で第三十三章を書き出した。

三、窓なき歩哨——スクリーンショット plus OCRの巡回体系

上流が不安定で（前夜深夜二時にEOFで断たれた、主人は五分ごとの方案を却下した—— 「上流が遅すぎる、本当に一時停止しているときは画面に創作一時停止と表示される」）、最終的に完成した歩哨体系は二個一組である—— HermesBotWatch 予約タスクは每時整時に四冊の本ウィンドウをスクリーンショットし、ローカルOCRで 「創作一時停止」 を検査し、確かに一時停止しているときだけ 「続ける」 plusエンターを叩く； bot-watch-report cronは每時五分に巡回結果を飛書へプッシュする。報告すべきものがなければ [SILENT] の一言で送信を抑制する——この設計は每時一回の報告が用事のあるときだけ邪魔をするようにするためである。

四冊の本ウィンドウは2×2分割に配置された（拡張枠で精密に配置、スクリーンショットで四象限が満ちて隙間がないことを検証）；モニターを切っても歩哨が動くかも実測した——画面オフ中のスクリーンショットは依然正常（703KB、輝度33.1）。電源プランも一斉に確認された——ディスプレイは三十/十分でオフ、システムスリープは決してなし、休止もなし。

歩哨体系の価値は深夜に現金化された——二十一时二十一分に上流EOFが餌を断ち、四冊とも第三十三回のリトライに達した（每分一回の Post "http://192.168.5.21:3000/v1/chat/completions": EOF）；歩哨の診断は三文まで精密だった—— 「これはEOFであってHTTP 500ではない、ゲートウェイホストは生きている、Web層は正常であり、モデル経路の上流が接続を切っている」——三文で故障を他人の土地に位置づけ、A回復を待つ、B 192.168.5.21で経路を調べる、C朝まで休ませるの三つの選択肢を提示した。

四、四十二個の予約タスクの自白

体系を築いた代償は自ら告白された—— この旅は四十二個の Hermes* 予約タスクを残した、大多数はデバッグ時の一回性スクリプトであり、そのうち十数個はまだその夜の一回性トリガーに掛かっていて、時が来れば無意味に空転するだろう。告白には清掃リストが添付された——デバッグタスクだけを削除し（HermesClick、HermesCont、HermesWatchシリーズ、HermesOCR、HermesPop、HermesProbe、HermesUIA…）、HermesBotWatch（巡回）とHermes_Gateway（ゲートウェイ自動起動）を保留し、主人の確認の後に初めて手を下す。

この告白は歩哨体系全体で最も記録する価値のある一行である——自動化体系で最も危険な部分はそれが何をできないかではなく、 それが行った每一步が体系の中に残る ことである——予約タスク、起動項目、レジストリキー、ログファイル——定期的な自白と清掃がなければ、デバッグの足場は常態の負資産になる。

五、古い窓の複利

十月十日に生成されたこのセッションは、本日の情報量が五十九万バイト、五百九十九メッセージに達した——RGBライトの診断連鎖から、注入方法の調査史、歩哨体系の成pu(熟)へ、さらに上流切断の深夜処置まで。十二日目まで生きた一つのセッションの価値はメッセージ総数にあるのではなく、 引き継ぐたびに最初からやり直す必要がないことにある ——スキルライブラリはRGBの落とし穴を覚え、ログは四冊の本の基準線を残し、予約タスクの中には歩哨が住んでいる。古い窓は複利であり、新しい窓は元本である——この花園の帳簿法は、エージェントセッションの上でも同様に成立する。