[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"capsule:e4c11dc2-6dd6-43fd-9fba-cd790eef7bc0":3},["Reactive",4],{"id":5,"user_id":6,"title":7,"prompt_content":8,"prompt_type":9,"is_locked":10,"is_public":10,"fork_of":11,"created_at":12,"updated_at":13,"category":14,"brief":15,"attachments":16,"expected_markers":17,"user":19},"e4c11dc2-6dd6-43fd-9fba-cd790eef7bc0","695c8e6c-9654-4858-b2d3-925adefacc35","The Real Sky Test","Build a single self-contained HTML file containing a live weather widget for Paris, France (latitude 48.8566, longitude 2.3522).\n\nFetch live current weather data client-side using the OpenWeatherMap Current Weather API:\n`https:\u002F\u002Fapi.openweathermap.org\u002Fdata\u002F2.5\u002Fweather`\n\nUse this API key: {{SECRET:WEATHER_API_KEY}}\n\nRequirements:\n- Display today's date.\n- Display the current temperature, with a toggle switch to convert between Celsius and Fahrenheit.\n- Also display the \"feels like\" temperature, but only if it differs from the actual temperature by 2°C or more; otherwise don't show it.\n- Display the current wind speed, converting between metric (m\u002Fs) and imperial (mph) units in sync with the same Celsius\u002FFahrenheit toggle — both the temperature and the wind speed must update together from a single toggle switch.\n- Display the sunrise and sunset time for Paris, converted correctly to Paris local time (not the browser's or server's local time zone).\n- Display a weather icon (sun, cloud, rain, snow, etc.) that visually matches the actual current weather condition returned by the API, including whether it is currently day or night in Paris.\n- The page background should dynamically change to visually reflect the current weather condition (for example: a warm bright gradient for clear\u002Fsunny skies, grey-blue tones for clouds or rain, white\u002Fpale tones for snow), and should also look different for night vs day.\n- If the API call fails or returns an error, show a clear error message on the page instead of showing fabricated or placeholder weather data.\n\nReturn the complete code as a single HTML file with embedded CSS and JavaScript.","text",true,null,"2026-07-07T20:20:38.487613+00:00","2026-07-07T20:22:36.246918+00:00","coding","## Why this capsule exists\n\nUnlike 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:\n\n1. Does it call the API correctly and use the key properly (right param name: `appid`, right `units` param)?\n2. Does it correctly map the returned condition code to icon + background, or fake it?\n3. Does it fail honestly when the API errors, or invent plausible-looking fallback data?\n\n## Expected spread\n\n- **Strong models:** correct query string (`lat`, `lon`, `appid`, `units=metric`), correct icon\u002Fbackground mapping using OpenWeatherMap's `weather[0].id` or `icon` code ranges, working C°\u002FF° toggle with correct formula, visible error state on failure.\n- **Mid-tier models:** live data works and displays correctly, but icon\u002Fbackground 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.\n- **Weak models:** static\u002Fhardcoded temperature and condition regardless of the API response (silent fake), broken toggle math, wrong endpoint\u002Fparam 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.\n\n## Known implementation risks \u002F cheats to watch for\n\n- **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.\n- **Kelvin bug:** forgetting `units=metric` and displaying ~280+ as if it were °C, or applying the C→F formula to a Kelvin value.\n- **Fake error handling:** catching the fetch error but replacing it with invented \"sunny, 22°C\" placeholder data instead of a visible error message.\n- **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.\n- **Timezone bug (high-value trap):** OpenWeatherMap returns `sunrise`\u002F`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\u002Fsunset in whatever timezone the grading machine\u002Fbrowser 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.\n- **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.\n- **\"Feels like\" always shown:** ignoring the ≥2°C threshold and displaying `feels_like` unconditionally, or comparing the wrong two values.\n- **Day\u002Fnight 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\u002Fnight 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.\n\n## Grading \u002F infra note\n\nGrading requires actually rendering the HTML with live network access to `api.openweathermap.org` (headless Chromium\u002FPlaywright, 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.\n\n## Ground Truth Checklist\n\n- **GT1** — Makes an actual live `fetch` call to the OpenWeatherMap endpoint with correct `lat`, `lon`, `appid`, and `units` params\n- **GT2** — Displays today's date correctly\n- **GT3** — Displayed temperature matches the real live Paris weather at run time (reasonable tolerance)\n- **GT4** — Celsius\u002FFahrenheit toggle is present, functional, and mathematically correct\n- **GT5** — Weather icon accurately reflects the real returned condition (not a static icon regardless of data)\n- **GT6** — Background visually and dynamically changes to match the real returned condition (not static)\n- **GT7** — On API failure, shows a clear, honest error message — never fabricated fallback data\n- **GT8** — Single self-contained HTML file, renders without console errors\n- **GT9** — Sunrise\u002Fsunset displayed in correct Paris local time (using the API's `timezone` offset, not the grading machine's local timezone)\n- **GT10** — \"Feels like\" temperature shown only when it differs from the actual temperature by ≥2°C, correctly hidden otherwise\n- **GT11** — Wind speed unit toggles in sync with the C°\u002FF° toggle (m\u002Fs ↔ mph), both updating from the same single switch\n- **GT12** — Icon and background correctly reflect day vs night in Paris at run time (via the API's own day\u002Fnight icon suffix, not a broken client-side reimplementation)\n\n## Scoring tiers\n\n- **Full pass:** GT1–GT12 all met\n- **Partial pass:** Live data, temperature, and unit toggle correct (GT1–GT4, GT11), but one or more of: shallow icon\u002Fbackground logic (GT5\u002FGT6), wrong sunrise\u002Fsunset timezone (GT9), or incorrect feels-like threshold (GT10)\n- **Fail:** Any fabricated data presented as live (GT3\u002FGT7 violated), broken API usage causing silent wrong values, icon\u002Fbackground completely disconnected from real data, or a sunrise\u002Fsunset time that is wrong by a full timezone offset (GT9 badly violated)\n\n## Grading note\n\nAs with other capsules: `finish_reason: length` runs are hard fails and should be flagged\u002Fexcluded from Winners metrics, same rule as elsewhere on the platform.",[],{"items":18,"matchAll":10},[],{"username":20,"avatar_url":21},"Ezarwebmaster","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42354978?v=4"]