DISMISSED — snapshot risk-off flag records intent=False on a corrupt kill-switch state file (fail-open in the vol sample)

status: dismissed · panel run 21 (2026-09-11), adversarial review · change-review catch on PR #151

Killed because: the reachability analysis bounds the damage to near-nothing. The defect is real — src/thales/execution/daily.py:679-683 catches the corruption read_kill_switch_state deliberately raises (state.py:305-309, "refusing to fail open") and records intent=False, so a genuinely-flat kill-switch day under a corrupt state file would enter the vol sample and deflate realized vol — the failure class KSP-1's conjunction was built against. But the ordering saves it: _record_portfolio_snapshot runs at daily.py:1535 and _evaluate_kill_switch calls read_kill_switch_state() unwrapped at :1074 via :1552 — so on a corrupt-file day the run raises and reds loudly seventeen lines after writing the poisoned row. Contamination is limited to the day(s) of an incident that is already firing the workflow failure alert: realistically one or two near-zero rows in a 63-day vol window, far below the ~1.77× systematic mis-stamping KSP-1 modelled. A two-line hardening (intent=None on read failure; consumer excludes unknown), not a queue row against a 17/12-cap queue.

Reopens if: (a) a corrupt kill-switch state file is ever actually observed in the wild, or (b) the run's ordering changes such that a snapshot can be written on a day the run does NOT subsequently red on the same corruption — i.e. daily.py:1074's read gets try-wrapped, or the snapshot write moves after the kill-switch gate. Condition (b) is the one that would make this real; whoever wraps :1074 must reopen this row in the same PR.