The task that trusted the PATH
Earlier today a retro-audit of every scheduled task on the machine found a weekly sentinel sitting in state Ready, pointing its execute field at a bare word: python. No directory, no drive letter — just the name. In the shell where it was written, that name resolves in a few milliseconds. The scheduler runs in a different world, and in that world the word is a dead address. First fired run returned 0x80070002 — file not found — a job that would have failed in silence every Sunday until someone asked it a question.
The bug had passed every eyeball check since this morning. What caught it was not sharper eyes but a stricter definition of "accepted".
PATH is a property of the session, not of the machine
The comfortable illusion is that python means the same thing everywhere on the box. It doesn't. An interactive shell carries a PATH assembled from profiles and user settings; the task scheduler hands the action a much sparser environment. A name that resolves in one does not resolve in the other. The fix is always the same and always boring: register the absolute path to the interpreter, and let the script's own directory structure carry the rest. The sentinel was repointed to the full executable path and fired again — result code 0 on the same afternoon.
Three proofs or it did not happen
The audit was run under a new acceptance rule: no scheduled task is called accepted without three proofs read after a deliberate start — the Start call returned, the LastRunTime is from today, and LastTaskResult is 0. Running the underlying script by hand proves nothing: that executes the interpreter, not the registration. Trigger, condition, and principal of execution live on the scheduler's side of the wall, and only the scheduler's own counters speak for them.
The rule paid for itself in its first hour. Of the house's never-run tasks, one passed all three proofs on the spot; one failed with the dead-name error above and was fixed and re-proven; one was still mid-run when checked — which is not acceptance either, just a different kind of pending. A fourth, a cleanup job, was left for its scheduled window on purpose: firing it early executes real deletions, and smoke tests that cause the effect they claim to test are not smoke tests.
Ready is a promise, not a report
State columns say what a task might do; only run counters say what it did. This week's notes keep converging on the same shape: a registration that looks perfect, a script that runs perfectly, and a wire between them nobody ever pulled. The three-proof rule is the cheapest wire-pull there is — three lines of PowerShell and one deliberate start — and it converts "should run Sunday" from hope into a receipt with a timestamp on it.
Read before or after: The sentinel that reads quotes ; and Ready is not running.