kv

WEATHER KV

Read and manage the WEATHER KV namespace. Run from the repo root so wrangler resolves --binding WEATHER from wrangler.jsonc (namespace id da96de7daed84b69b32778058b374d5f is the fallback via --namespace-id).

The one rule: always --remote

wrangler kv key ... defaults to local miniflare state. Without --remote, a get reports "Value not found" even though production has the key. Every command below passes --remote — keep it.

And local state PERSISTS across runs. It lives in .wrangler/state/v3/kv/ (gitignored) and survives wrangler dev restarts, reboots, and days of elapsed time — so "a fresh local dev server" is not a cold cache. A local run cold-warms KV once and every later run reads that same snapshot back, however old it is.

This is not academic: a wrangler dev session on 2026-08-05 was served a weather value written on 2026-08-01, whose 48 hourly periods had all elapsed two days earlier — and it was briefly misread as an empty cache, because "local dev must be cold" is the intuitive assumption and it is wrong. To get a genuinely cold local cache, delete the state:

rm -rf .wrangler/state          # next `wrangler dev` starts truly empty

The nine content keys (different owners, different risk)

• weather — NWS forecast + active alerts, shape { updated, place, periods, hourly, alerts } (hourly is the array loadWeather() checks to decide the cache is fresh). Written by the cron (*/15 * * * *) and warmed by loadWeather() on a cold cache. Inspecting is safe; a bad or deleted value self-heals within 15 min (or on the next request). Low risk.
• calendar — Crosby ISD school calendar, shape { updated, events: [{ summary, location, start, allDay, end }] } (events is the array loadCalendar() checks for freshness). Written by the same cron (throttled to ~24h — Crosby ISD's calendar changes rarely) and warmed by loadCalendar() on a cold cache. Like weather, a bad/deleted value self-heals on the next cron or request. Low risk.
• water — river/bayou gauges, shape { updated, gauges: [...] } (gauges is what loadWater() checks). Written by the same cron every tick; cold-warms on read. Self-heals like weather. Low risk.
• fishing — USGS real-time water conditions for the waters people fish, shape { updated, stations: [{ id, params:{tempC,do,ph,turb,gageFt}, observed }] } (stations is what loadFishing() checks). Written by the same cron every tick; cold-warms on read. Self-heals like water. Low risk.
• tropics — Atlantic tropical outlook from two NHC products, shape { updated, storms: [...], disturbances: [...] | null, outlookIssued }. storms is NHC CurrentStorms.json (named cyclones only); disturbances is the Tropical Weather Outlook (areas being watched, with formation chances). loadTropics() checks BOTH are arrays and cold-warms otherwise, which is what migrates pre-2026-08 entries that carry no disturbances. An empty storms is the normal quiet-basin state, NOT an error — but on its own it is not an all-clear, which is the bug this shape exists to prevent. disturbances: null means the outlook could not be read and is NOT the same as [] (nothing being watched); hand-editing one into the other makes the page assert a quiet basin nobody confirmed. Written by the same cron, throttled ~1h June-November (Atlantic hurricane season, Central time) and ~24h the rest of the year; cold-warms on read. Self-heals. Low risk.
• pollen — the Houston Health Department's measured daily pollen & mold count, shape { updated, countDate, url, groups: {tree,weed,grass,mold}, species } (loadPollen() checks groups + countDate; countDate is the CT calendar day the count is for — weekends carry Friday's, that's normal). Written by the same cron, skipped entirely on Sat/Sun (Central time) and on weekdays only when the cached countDate isn't today's date yet — HHD publishes one count per weekday morning, so this is "have we got today's count" rather than a flat age throttle; cold-warms on read. Self-heals. Low risk.
• burnban — Harris County outdoor-burning ban status from the Texas A&M Forest Service, shape { updated, status, startDate, statusSince, trackingSince } (loadBurnBan() checks status is "Yes" or "No"; startDate is ISO or null). Don't hand-write statusSince / trackingSince — trackingSince is the first observation ever and never moves, statusSince moves only on a real status flip, and when they are EQUAL the page says "unchanged since we began tracking" rather than claiming a transition. Faking them makes /burn-ban assert a ban ended on a day it did not. Deleting the key is safe: the next cron reseeds both to now, which reads honestly as "no observed history yet". Written by the same cron, throttled ~4h (TFS's feed updates roughly daily, on a county judge's order rather than a schedule); cold-warms on read. Self-heals. Low risk.
• traffic — Crosby-corridor road incidents + lane closures from Houston TranStar's public RSS feeds, shape { updated, incidents, closures } (loadTraffic() checks that incidents is PRESENT — either side is null when that feed was unreachable at the last refresh, vs [] = quiet roads, the normal state). Written by the same cron every tick; cold-warms on read. Self-heals. Low risk.
• news — local news, shape { updated, items: [...], source }. Written ONLY out-of-band by scripts/fetch-news.mjs (a Claude routine); the Worker just renders it. Overwriting or deleting news loses the snapshot until the next routine run (up to ~a day). Treat writes/deletes here as destructive.