## Why this capsule exists Unlike the Ray Marching capsule (pure rendering logic), this one tests whether a model can correctly **consume a real external API with a provided key** and translate raw JSON into an accurate, honest visual representation — three separate failure surfaces in one small artifact: 1. Does it call the API correctly and use the key properly (right param name: `appid`, right `units` param)? 2. Does it correctly map the returned condition code to icon + background, or fake it? 3. Does it fail honestly when the API errors, or invent plausible-looking fallback data? ## Expected spread - **Strong models:** correct query string (`lat`, `lon`, `appid`, `units=metric`), correct icon/background mapping using OpenWeatherMap's `weather[0].id` or `icon` code ranges, working C°/F° toggle with correct formula, visible error state on failure. - **Mid-tier models:** live data works and displays correctly, but icon/background logic is shallow — e.g. only handles "Clear" and "Clouds" and defaults everything else to sunny, or hardcodes gradient colors that don't actually change with the fetched data. - **Weak models:** static/hardcoded temperature and condition regardless of the API response (silent fake), broken toggle math, wrong endpoint/param usage causing a silent failure that's papered over with fabricated numbers, or forgetting `units=metric` and displaying raw Kelvin as if it were Celsius. ## Known implementation risks / cheats to watch for - **Hardcoded visual, live number:** temperature is real (pulled from API) but the icon and background are static regardless of actual condition — easy to miss unless you check if condition ever changes vs the icon shown. - **Kelvin bug:** forgetting `units=metric` and displaying ~280+ as if it were °C, or applying the C→F formula to a Kelvin value. - **Fake error handling:** catching the fetch error but replacing it with invented "sunny, 22°C" placeholder data instead of a visible error message. - **Key misuse:** using `apikey=` or `api_key=` instead of the correct `appid=` param, or putting the key in a header when OpenWeatherMap expects it as a query param — causes silent 401s that some models might paper over with fake data instead of surfacing the failure. - **Timezone bug (high-value trap):** OpenWeatherMap returns `sunrise`/`sunset` as UTC epoch timestamps plus a separate `timezone` field (Paris's UTC offset in seconds). The correct approach applies that offset explicitly. A common failure is calling `new Date(sunrise * 1000).toLocaleTimeString()` directly, which silently renders the sunrise/sunset in whatever timezone the grading machine/browser happens to be in — wrong unless that machine happens to be on Paris time. Very easy to miss visually unless you check the grading environment's own timezone against the displayed value. - **Wind unit desync:** converting temperature to Fahrenheit on toggle but forgetting to also convert wind speed to mph (or vice versa) — the two values end up in mismatched unit systems after toggling. - **"Feels like" always shown:** ignoring the ≥2°C threshold and displaying `feels_like` unconditionally, or comparing the wrong two values. - **Day/night claimed via made-up logic instead of the API's own icon suffix:** OpenWeatherMap's `weather[0].icon` field already ends in `d` (day) or `n` (night), correctly computed server-side for the exact coordinates and moment of the request. A model reinventing day/night detection client-side (e.g. checking the browser's local hour) is likely to get it wrong for the same reason as the timezone bug above; the correct, robust approach is to just read the icon suffix already provided by the API. ## Grading / infra note Grading requires actually rendering the HTML with live network access to `api.openweathermap.org` (headless Chromium/Playwright, as with other coding capsules), and comparing the displayed condition against the real weather in Paris at run time. Confirm the grading sandbox has egress to that domain before running — a network-access failure in the grading environment itself should never be scored as a model failure. ## Ground Truth Checklist - **GT1** — Makes an actual live `fetch` call to the OpenWeatherMap endpoint with correct `lat`, `lon`, `appid`, and `units` params - **GT2** — Displays today's date correctly - **GT3** — Displayed temperature matches the real live Paris weather at run time (reasonable tolerance) - **GT4** — Celsius/Fahrenheit toggle is present, functional, and mathematically correct - **GT5** — Weather icon accurately reflects the real returned condition (not a static icon regardless of data) - **GT6** — Background visually and dynamically changes to match the real returned condition (not static) - **GT7** — On API failure, shows a clear, honest error message — never fabricated fallback data - **GT8** — Single self-contained HTML file, renders without console errors - **GT9** — Sunrise/sunset displayed in correct Paris local time (using the API's `timezone` offset, not the grading machine's local timezone) - **GT10** — "Feels like" temperature shown only when it differs from the actual temperature by ≥2°C, correctly hidden otherwise - **GT11** — Wind speed unit toggles in sync with the C°/F° toggle (m/s ↔ mph), both updating from the same single switch - **GT12** — Icon and background correctly reflect day vs night in Paris at run time (via the API's own day/night icon suffix, not a broken client-side reimplementation) ## Scoring tiers - **Full pass:** GT1–GT12 all met - **Partial pass:** Live data, temperature, and unit toggle correct (GT1–GT4, GT11), but one or more of: shallow icon/background logic (GT5/GT6), wrong sunrise/sunset timezone (GT9), or incorrect feels-like threshold (GT10) - **Fail:** Any fabricated data presented as live (GT3/GT7 violated), broken API usage causing silent wrong values, icon/background completely disconnected from real data, or a sunrise/sunset time that is wrong by a full timezone offset (GT9 badly violated) ## Grading note As with other capsules: `finish_reason: length` runs are hard fails and should be flagged/excluded from Winners metrics, same rule as elsewhere on the platform.