Letting execution policy recover after a rejection cluster

Different checks need different history#

Execution policy checks parity, slippage, fill latency and clusters of rejected or cancelled orders. A recent burst of failures asks a different question from a longer record of execution quality. Using one lookback for both can keep an old cluster influencing a decision intended to describe recent failures.

The recorded “Fix sticky execution degradation window” change gives clusters their own shorter summary. Latency and slippage retain the longer window. The returned result includes both time ranges and summaries, so the events behind each check remain visible.

Recovery must change what the planner reads#

A passing return value isn't enough if later planning still sees an active degradation mode. On a pass, evaluate clears any active incident, saves an inactive NORMAL state and records a cleared event when the previous state was active. Warnings and failures save the active incident and mode instead.

That saved state reaches the order-adaptation path. Clearing it matters because an old active mode could continue reducing or removing new entry intents even after the current checks have recovered.

Disabling actions doesn't make evaluation read-only#

apply_actions=false skips the optional operational actions. Policy, incident and history updates still happen, changing the state later planning consumes. Diagnostic tooling needs to distinguish that write from a read-only inspection.

The regression definitions cover old clusters, fresh warnings, recovery from active degradation and both windows in the result. They weren't rerun for this review. A full recovery test should follow the persisted state into order adaptation, not stop at the two timestamp fields or a passing evaluator result.