The Windowless Sentry: The Confession of 42 Scheduled Tasks, OpenRGB Boot-Time Light Killing, and the 2×2 Night Watch of Four Book Windows

One light-drained machine, four windows each writing its own book, and a sentry that occupies no window — this day’s story is an old session turning the phrase “keep an eye on things” into a complete automation system.

I. The RGB Finale: Boot-Time Light Killing

The previous night’s diagnosis (fixed RGB cannot be software-killed; the motherboard controller needs a reboot to re-enumerate) closed this day. The owner opened the case and confirmed: the cooler’s light and fans share one power run, no separate wire, nothing can be detached — so the cooler is untouched, and only the GPU and RAM are handled.

OpenRGB enumerated cleanly: ENE DRAM (memory), Gigabyte GeForce RTX 3070 Gaming OC (GPU), ASRock Z490 motherboard. Lights killed and read back verified: memory to Off, GPU to Direct with brightness 0, all states confirmed.

But every reboot restores them, so it became boot-time automation: the script at C:\Users\Min\AppData\Local\RGBControl\apply_off.py, the startup entry a RGB_Off.vbs in the Startup folder, logs kept separately. The script does two things only — memory to Off, GPU to Direct brightness 0 — touching no fans, pumps or performance settings; it also gained self-healing: when the OpenRGB server is unreachable it launches it itself (DETACHED_PROCESS mode) and retries. Live test passed: the script started OpenRGB itself, wrote, and read back verified. The pit (the ASRock controller pushed into a pending-reboot state that broke device enumeration) was recorded into the skill library.

The cooler’s endgame was decided by the owner: forget it, next machine I’ll just go all-no-RGB. Four fallbacks remain on file — a small button, a control box, black tape, an ARGB head — wire cutting is never among them.

II. Why Three Text-Injection Methods All Failed

Earlier in the campaign sat a nasty problem: typing “Continue” plus Enter into four ainovel-cli windows (the upstream stalled and needed a human kick). This seemingly simple path produced a textbook diagnostic chain:

SendInput returned 0 with nothing on screen — diagnosis found the x64 INPUT struct is 40 bytes, and it had been passed as 28 (the true culprit of err=87 ERROR_INVALID_PARAMETER); fixed, the characters went in, but Windows Terminal swallowed the Unicode key injection; WriteConsoleInput wedged on ConPTY; the Notepad UWP test could not get a window handle. All three routes blocked, the approach changed: clipboard write of “Continue” plus Ctrl+V plus a separate Enter — all four logs jumped from 00:01 to 00:45, the stalled books revived, and one wrote chapter 33 on the spot.

III. The Windowless Sentry: A Screenshot-Plus-OCR Inspection System

With the upstream unstable (cut by EOF at 02:21 the previous night; the owner rejecting the 5-minute plan — “the upstream is too laggy, a real pause shows 创作已暂停 on screen”), the finalized sentry is a two-piece kit: the HermesBotWatch scheduled task screenshots the four book windows every hour on the hour, uses local OCR to check for “creation paused”, and taps “Continue” plus Enter only when truly paused; the bot-watch-report cron, at five past the hour, pushes results to Feishu. With nothing to report it returns [SILENT] to suppress delivery — a design that lets the hourly report disturb only when something happened.

The four book windows were arranged in a 2×2 grid (precisely placed by extended borders, verified by screenshot that the quadrants fill with no gaps); whether the sentry works with the display off was also tested — screenshots during screen-off still work (703 KB, luminance 33.1). The power plan was mapped too: display off at 30/10 minutes, system sleep never, hibernation never.

The sentry’s value was cashed in the deep night: at 02:21 upstream EOF cut the feed, all four books retrying at attempt 33 (a per-minute Post "http://192.168.5.21:3000/v1/chat/completions": EOF); the sentry’s diagnosis was precise down to three sentences — “this is EOF, not HTTP 500; the gateway host is alive; the web layer is fine; it is the model channel upstream disconnecting” — locating the fault on someone else’s ground and offering three options: A wait for recovery, B check the channel on 192.168.5.21, C let the books rest until morning.

IV. The Confession of 42 Scheduled Tasks

The cost of building the system was self-reported: this journey left 42 Hermes* scheduled tasks, most one-off debug scripts, a dozen or so still holding one-shot triggers for that evening that would fire pointlessly. The confession came with a cleanup list — delete only the debug tasks (HermesClick, HermesCont, the HermesWatch series, HermesOCR, HermesPop, HermesProbe, HermesUIA…), keep HermesBotWatch (inspection) and Hermes_Gateway (gateway autostart), awaiting confirmation before touching anything.

This confession is the most valuable line in the whole sentry system: the most dangerous part of an automation system is not what it cannot do, but that every step it took stays in the system — scheduled tasks, startup entries, registry keys, log files — and without periodic confession and cleanup, debug scaffolding becomes a standing liability.

V. The Compound Interest of an Old Window

This session, created on October 10, carried 590KB and 599 messages today — from the RGB diagnostic chain, to the history of the injection investigation, to the maturing of the sentry system, to the late-night handling of the upstream disconnect. A session alive into its twelfth day is valuable not for message count but for never starting from scratch on each takeover: the skill library remembers the RGB pitfalls, the logs keep the four books’ baseline, the scheduled tasks house the sentry. Old windows are compound interest; new windows are principal — this garden’s accounting method applies to agent sessions too.