smarter: factual-model routing (beh-10), fetch_url main-content extraction + 8k cap (url-08), get_weather via met.no (spec-016)

specs/SPEC-016-weather.md

@@ -0,0 +1,35 @@
+# SPEC-016 — Weather tool (get_weather)
+
+Both personas talk about weather (the sea over the skerries, rain on
+patch day) but had to guess it. `get_weather` grounds that in the
+free MET Norway Locationforecast API (api.met.no, User-Agent
+required, no key). Locations are host-configured coordinates — the
+model picks by name, it never supplies raw URLs, so there is no SSRF
+surface (one fixed API host).
+
+### WEA-01 — Tool offered only when configured (coverage: test)
+
+The chat call's tools include `get_weather` only when
+`enable-weather` is true AND `weather-locations` (a list of
+`[name, lat, lon]` entries) is non-empty. Otherwise it is absent.
+
+### WEA-02 — Compact sanitized forecast (coverage: test)
+
+The tool reduces the MET compact timeseries to: the named location,
+current conditions (temperature °C, wind m/s, symbol), and a small
+set of forecast points (next hours / tomorrow) with temperature,
+symbol and precipitation. Location names pass
+`sanitize_external_text`; numbers are numbers. Nothing else from the
+API response reaches the prompt.
+
+### WEA-03 — Location matched by name, defaults to first (coverage: test)
+
+The `location` argument matches configured entries
+case-insensitively by substring; no or unknown location = the first
+configured entry. Coordinates never come from the model.
+
+### WEA-04 — Errors return, never raise; calls are metered (coverage: test)
+
+API/network failures return an `{error}` dict (the responder keeps
+running). Each call counts against a per-user daily cap
+(`weather-daily-per-user`, default 30) like the other tools.