@@ -48,18 +48,18 @@ root; adjust the path for a Debug build.
 | 22 | Boot-apply off | `--boot off`, then `schtasks /Query /TN GpuAutoOptimizer` | yes | `boot-apply off: task removed`; schtasks reports the task does not exist | Pass (2026-09-26). `--boot off`: `boot-apply off: task removed`; `schtasks /Query /TN GpuAutoOptimizer`: `ERROR: The system cannot find the file specified.`; `--status`: `boot-apply: off`. |
 | 23 | Memory search stops at the bandwidth peak | `--optimize best` (elevated) | yes | log shows `mem +N: bandwidth X GB/s` per step and `mem: bandwidth peak +N`; the peak is where bandwidth stops rising, not the top of the range | Pass (2026-09-27, driver 610.74): one `bandwidth` line per 50 MHz step. On this card bandwidth kept rising to the top of the range (454.3 GB/s at +0, 513.0 at +1500), so there was no peak inside it. The 1 % tie band picked +1400 (509.3 GB/s), the lowest offset within 1 % of the best. The earlier guess that +1050 was already past the peak was wrong. |
 | 24 | Edges are confirmed | same run as 23 | yes | `confirm core +N` and `confirm ... mem +N` lines with 30 s probes; `RESULT:` reports the confirmed values the margin was applied to | Pass (2026-09-27): `confirm core +195 / mem +0` STABLE, `confirm core +135 / mem +1400` STABLE. `RESULT: power 105 %, core +135 MHz (confirmed +195), mem +950 MHz (confirmed +1400)`. Soak STABLE, score 5764 -> 6008 it/s (+4.2 %). |
-| 25 | Boot-apply runs the installed copy | `--boot on`, `schtasks /Query /TN \GpuAutoOptimizer\BootApply /XML`, log off and on, `--status` | yes | exe in `%ProgramFiles%\GpuAutoOptimizer\`; XML shows `DisallowStartIfOnBatteries false`, `ExecutionTimeLimit PT0S`, `Priority 5`, `--tray`, `IgnoreNew`, the Program Files path; `last boot: ... applied`; `boot copy: up to date` | Failed (2026-09-27): `could not create the task (schtasks exit 1)`. The old task `\GpuAutoOptimizer` is a file in the task root, and it blocks creating the `\GpuAutoOptimizer\` folder. Fixed: `--boot on` now removes the old task first. Both executables were copied to Program Files correctly. Re-run pending. |
+| 25 | Boot-apply runs the installed copy | `--boot on`, `schtasks /Query /TN \GpuAutoOptimizer\BootApply /XML`, log off and on, `--status` | yes | exe in `%ProgramFiles%\GpuAutoOptimizer\`; XML shows `DisallowStartIfOnBatteries false`, `ExecutionTimeLimit PT0S`, `Priority 5`, `--tray`, `IgnoreNew`, the Program Files path; `last boot: ... applied`; `boot copy: up to date` | Failed (2026-09-27): `could not create the task (schtasks exit 1)`. The old task `\GpuAutoOptimizer` is a file in the task root, and it blocks creating the `\GpuAutoOptimizer\` folder. Fixed: `--boot on` now removes the old task first. Both executables were copied to Program Files correctly. Re-run pass (2026-09-27, after 96e61bc): `boot-apply on`; the old task is gone; the XML has `PT0S`, `Priority 5`, `IgnoreNew`, no battery limits, and `GpuAutoOptimizer.exe --tray` from Program Files; `boot copy: up to date`; `boot.log` `applied` from the tray; strikes 0 of 3 after the grace period. |
 | 26 | State folder is admin-only | `icacls "%ProgramData%\GpuAutoOptimizer"`; `--status` unelevated; a user-created folder is refused | no / yes | SYSTEM and Administrators full, Users read & execute, no inherited entries; `--status` works; a folder created by the user before the first elevated run makes `--optimize` refuse | Pass (2026-09-27): a folder the user created (owner `Gebruiker`) is refused (`not owned by Administrators or SYSTEM`); a junction is refused (`is a link or not a folder`) and its target's ACL is unchanged. The folder gao created: SYSTEM and Administrators `(OI)(CI)(F)`, Users `(OI)(CI)(RX)`, no inherited entries. |
 | 27 | No DLL planting | copy `C:\Windows\System32\version.dll` next to the exe as `d3d11.dll`, `dxgi.dll`, `d3dcompiler_47.dll`, `msvcp140.dll`, `vcruntime140.dll` and `vcruntime140_1.dll`; run `--stress 5`, `--bandwidth`, `--status`; delete the copies | no | all three work normally (a loaded fake would break the import) | Pass (2026-09-27, driver 610.74). `--stress 5` `STABLE` (5768 it/s), `--bandwidth` 491.8 GB/s, `--status` normal. `dumpbin /dependents`: static imports only `KERNEL32`, `ADVAPI32`, `SHELL32`, `ole32` (KnownDLLs; the CRT is linked statically); `d3d11`, `dxgi`, `D3DCOMPILER_47` delay-loaded after `SetDefaultDllDirectories`. |
 | 28 | Old journal is not imported | first elevated run after the move | yes | the new journal starts empty; nothing under `%LOCALAPPDATA%` is read by the elevated process | Dropped as a migration on 2026-09-27: reading a user-writable file from the elevated process could be redirected to disclose other files (P4b review). The old journal on the reference machine had no open entries (136 lines, 0 freezes), so no ceiling was lost. |
 | 29 | The window renders and idles | start `GpuAutoOptimizer.exe` unelevated | no | GPU name, driver, telemetry, saved/applied tune and presets shown; under 1 % of one CPU core while idle | Pass (2026-09-27): all shown (screenshot); 0.05 CPU-seconds over 5 s idle (~1 %); 0.02 after the P5 fix pass. |
 | 30 | Optimize from the window | Restart as administrator, pick Best, Optimize | yes | run screen with live temperature/power and the probe log; results screen with before/after | |
 | 31 | Abort from the window | Abort during the core search | yes | the run ends with `aborted`, card at stock | |
-| 32 | Tray app at logon | apply at logon on, log off and on | yes (task) | tray icon present, tune applied, `boot.log` `applied`, strike cleared after 2 min | |
-| 33 | Watchdog re-applies after a TDR | tray running, `dxcap -forcetdr`, wait 45 s, `gao --status` | yes | `applied:` equals the saved tune again; `boot.log` has `watchdog: ... re-applied`; a balloon said so | Failed (2026-09-27): the tray crashed on the forced TDR. It hit an access violation inside `nvml.dll`, called from the 1 s telemetry tick (crash dump in the state folder), so nothing re-applied the tune. Fixed: the tray's periodic hardware work is now guarded. After a reset (UI device removed, a failed read-back, or a fault) NVML and NVAPI are re-created 5 s later. A build with an injected access violation recovered and kept running. Re-run pending. |
+| 32 | Tray app at logon | apply at logon on, log off and on | yes (task) | tray icon present, tune applied, `boot.log` `applied`, strike cleared after 2 min | Pass for the tray start (2026-09-27): the task-style start `--tray` applied the tune (`boot.log` `applied ... strike 1 clears in 2 minutes`) and the strike was cleared (0 of 3) after 2 minutes. A real logoff and logon with the new task is still to be checked. |
+| 33 | Watchdog re-applies after a TDR | tray running, `dxcap -forcetdr`, wait 45 s, `gao --status` | yes | `applied:` equals the saved tune again; `boot.log` has `watchdog: ... re-applied`; a balloon said so | Failed (2026-09-27): the tray crashed on the forced TDR. It hit an access violation inside `nvml.dll`, called from the 1 s telemetry tick (crash dump in the state folder), so nothing re-applied the tune. Fixed: the tray's periodic hardware work is now guarded. After a reset (UI device removed, a failed read-back, or a fault) NVML and NVAPI are re-created 5 s later. A build with an injected access violation recovered and kept running. Re-run pass (2026-09-27, after 96e61bc): the tray was still running after `dxcap -forcetdr`; `boot.log` `watchdog: the tune had been reset (driver reset or TDR); re-applied`; `applied:` equals the saved tune; no new crash dump. |
 | 34 | Watchdog backs off from another tool | tray running, set an offset in MSI Afterburner and Apply | no | a balloon says another program changed the settings; the watchdog does not fight it | |
 | 35 | One instance | start the app twice | no | the second start brings the first window forward and exits | Pass (2026-09-27, after the P5 fix pass): the second start exits with code 0, the first keeps running. |
-| 36 | CLI and tray side by side | tray running with the tune kept applied; `gao --reset`, wait 45 s, `gao --status`; then `gao --optimize` from a shell while the window runs an optimize | yes | after `--reset` the card stays at stock (the tray notes it and does not re-apply); after `gao --apply` the tray keeps the tune applied again; the second optimize refuses with `another optimize is already running` | |
+| 36 | CLI and tray side by side | tray running with the tune kept applied; `gao --reset`, wait 45 s, `gao --status`; then `gao --optimize` from a shell while the window runs an optimize | yes | after `--reset` the card stays at stock (the tray notes it and does not re-apply); after `gao --apply` the tray keeps the tune applied again; the second optimize refuses with `another optimize is already running` | Pass for reset and apply (2026-09-27): after `gao --reset` the card stayed at stock for 45 s with the tray running (no watchdog line); `gao --apply` applied the tune again. Two optimizes at once not yet tried. |
 | 37 | Closing the window | close the window with no tune applied, then again with a tune kept applied | no / yes | without a tune the app exits; with one it hides to the tray | Pass without a tune (2026-09-27): the app exits on close. |
 
 ## Notes