mirror of
https://github.com/okieselbach/AutopilotMonitor.git
synced 2026-10-25 13:10:13 +00:00
Oliver Kieselbach
b0f7e0fcd6
Session 1ec8f4c6 exposed the third completion-dead-end variant: Windows closed the ESP page NORMALLY (Shell-Core 62407, errorCode=0) while the AccountSetup Apps subcategory was still in_progress (a user-targeted app never started). No EspTerminalFailure ever fired, so the AdvisoryCompletion arming site from the 8bc1180f fix never ran - yet the dead-end is identical: the registry gate can never open, the IME settle probe is starved, Hello is disabled, and the session idles to the max-lifetime watchdog although the full completion conjunction (real-user desktop + Hello disabled + genuine IME user-session completion) was satisfied minutes in. HandleEspExitingV1 now arms the shared AdvisoryCompletion resolution window when a guard-blocked esp_exiting lands AFTER AccountSetup entry (fire-once; pre-AccountSetup handoff exits stay arm-free; a later advisory deliberately re-bases the window). The deadline handler accepts the new anchor (final exit at-or-after AccountSetup entry) alongside the advisory anchor and fails the no-evidence case with its own semantics: reason esp_exit_without_completion_evidence and LastFailureTrigger=DeadlineFired - NOT esp_terminal_failure, and the likely-stuck app promotion stays off, because the ESP never reported a failure. Updated the two tests that pinned "guard-blocked exit arms nothing" to the new contract - notably the caa6cf50 gate-starvation shape now carries the resolution window as a 30-min backstop underneath the synthesis fast path. DecisionCore 387/387, V2.Core 1335/1335 green; solution builds. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>