mirror of
https://github.com/okieselbach/AutopilotMonitor.git
synced 2026-10-25 13:10:13 +00:00
Oliver Kieselbach
821c41e2ba
* feat: tenant Hello wait timeout up to 1 hour The "Hello Wait Timeout" setting (30..300 s in the UI) had no effect in the V2 agent: its only consumer, HelloTracker.StartHelloWaitTimer, has no production caller, while the decision engine armed a fixed 300 s hello_safety deadline after the ESP exit and the tracker ran a fixed 300 s completion timer after the wizard start. The setting is now the real Hello budget, clamped to 300..3600 s (HelloWaitTimeout in AutopilotMonitor.Shared). Every value that was valid before (<= 300, including the old 30 s default) keeps today's 5 minutes. - Engine: the agent stamps helloWaitTimeoutSeconds on EnrollmentFactsObserved (only when > 300), recorded set-once in EnrollmentScenarioObservations. All six hello_safety arm sites share one builder with the tenant window; a fact that arrives after hello_safety was armed moves it out. The WDP backstop is never shorter than the tenant window; the signal census surfaces hello_wait_extended. - Agent: the Hello tracker's wizard completion timer uses the same budget; the stall probe skips session_stalled while hello_safety is pending. - Backend: ValidateModel rejects values outside 300..3600; stored rows are read as their effective value, so legacy 30 s rows never block unrelated saves or backup reverts. Default 30 -> 300; shared manifest and wire types regenerated. - Web: input 300..3600, bounds pinned against the C# constants. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S17pipjWqjZ8ULAu1JrFyG * fix: keep the Hello wait's 30 s minimum and default, raise only the maximum Product decision: the setting keeps its UI contract (30 s minimum and default, same description); only the maximum moves to 3600 s. Configured values up to 300 s keep the built-in 5-minute Hello window, larger values extend it. - HelloWaitTimeout: MinSeconds/DefaultSeconds 30; BuiltInSeconds 300 is the floor of EffectiveSeconds. - Backend validates only a changed value (30..3600), like the retention cap; the read-time normalization is gone again. - The agent stamps the tenant window only above BuiltInSeconds. - Web keeps the original text and default; only the maximum and its hint change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S17pipjWqjZ8ULAu1JrFyG * fix: Hello wait default 300 s, stale-fire guard, deferred stall report Product decision: default 300 s (what V2 has always waited), minimum 30 s still accepted, maximum 3600 s. Values up to 300 s keep the built-in 5-minute window, which the settings hint now says. Review follow-ups: - Engine: a hello_safety fire whose incarnation was replaced (armed due later than the fire's due time) is dead-ended, same guard as RealmJoin — a late tenant window could otherwise be undercut by the queued fire of the built-in deadline. The tenant fact is recorded only when it extends the built-in window. - Stall probe: session_stalled is held back while a tenant-extended Hello wait (hello_safety or the WDP backstop) is pending and emitted once it is over and the session is still idle; real activity drops it. Default tenants never hit the guard. - Comments: WDP backstop wording, 5-min reference, AgentConfiguration. - Web pins the default against the shared manifest; tracker constructor defaults use HelloWaitTimeout.DefaultSeconds. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S17pipjWqjZ8ULAu1JrFyG --------- Co-authored-by: Claude <noreply@anthropic.com>