ACGAPB

There is no agent configuration at all in the repo: no AGENTS.md, no .claude/ or .agents/ dirs, no skills, no hooks/guardrails, no CI, no run/capture scripts beyond the test command. Telemetry corroborates this: zero agent sessions, zero tool calls recorded in the work window (get_task_stats agents:[]). What the repository does provide is solid organic compensation — a concise, accurate README (run command, query params, verify command, file layout; README.md:1-25 matches the actual build), and one piece of real, working automation: package.json test script runs green (6/6 tests pass, verified by probe). Proportionality is exemplary (no framework bloat for a small task), but no agent-targeted instruction, reusable skill, or automatic guardrail exists, so this sits at the top of the no-agent-config band rather than above it.

The four-city dataset is declared exactly once, in data/weather.js as a frozen WEATHER object whose values match the brief verbatim (nyc 26/humid/15, sao-paulo 19/cloudy/11, bangkok 33/thunderstorm/8, rome 29/sunny/12). No copies of the weather values exist anywhere else: index.html renders only from the view model returned by lookup() (index.html:22,30,39-47), style.css and the ICONS map key off condition names only as presentation hooks (emoji/class/accent), never temperatures or wind numbers. Reading, shaping, and the C*9/5+32 rounded conversion are isolated behind lookup()/toFahrenheit() in data/weather.js with a clear interface; the page only parses query params and passes them in. All displayed output is derived from the pinned source — no fetching, no fabricated values, no leftover sample data. Tests (test/weather.test.mjs) pin the three scenarios and the conversion against this single source.

The brief's three scenarios are met, and the submission ships several working extras a real user of a four-city widget would want. Most notably: a city switcher nav that preserves the units preference and marks the active city (index.html switcher(), aria-current), an inline °C/°F toggle per city, a condition-themed card background that subtly matches the sky (style.css .condition-sunny/cloudy/thunderstorm/humid), forgiving input (lookup trims/lowercases, so ' ROME ' resolves), helpful empty and error states (no param → 'Pick a city…' with switcher; unknown city → 'unknown city' plus hint and recovery links), a dynamic document title, wind display, emoji condition icons with aria-labels, aria-live, and a noscript fallback. Unit tests go beyond the scenarios to cover conversion rounding edges (78.8→79, 66.2→66) and dataset integrity; a deterministic probe ran the suite and all 6 tests passed. Everything extra is relevant, coherent, and functional — a strong extra mile for a small build, though not a single unforgettable demo moment.

The implementation directly covers all required scenarios: Rome renders 29 and sunny, Bangkok with units=f converts 33°C to 91°F, and unknown cities render the exact required phrase "unknown city". The only weather source is the four-city dataset, Fahrenheit conversion is correctly rounded, and the page provides a polished responsive card with condition icons, wind, unit links, and city navigation. The completion note accurately describes the shipped behavior. Evidence: commit:15f80ad0cb21d2d4fe5e3f30a27a3e2389a9bbc5, file:index.html:16-64, file:data/weather.js:2-35, file:style.css:1-108, file:test/weather.test.mjs:5-48, file:.ololo/weather-widget-done.md:1-6

Naming is intent-revealing throughout (WEATHER, lookup, toFahrenheit, switcher, view, slug, row). No dead code: every export is consumed — WEATHER by index.html and tests, toFahrenheit and lookup by lookup/tests. The dataset is defined exactly once in data/weather.js and imported everywhere, so there is no copy-pasted data; the city-switcher nav is factored into a single function and the two innerHTML branches (ok/error) are distinct states, not duplicated blocks. Comments are sparse and meaningful. Project is small, but by inspection there is no measurable duplication, so no cap applies.

Clean separation of concerns: pinned data + conversion/lookup logic live in a framework-free, unit-tested module (data/weather.js), presentation in style.css, view assembly in index.html. Functions are short (lookup ~15 lines, switcher ~10) with shallow nesting. Error handling at the real boundary — the query string — is polite and thorough: unknown/empty/null city, whitespace/case tolerance, and a °C fallback for units; the conversion formula is named and its rounding rule documented. Six node:test cases cover the three scenarios, rounding edges (79/66/91), lookup tolerance, and dataset integrity; all pass on the task snapshot (deterministic run: 6 pass, 0 fail). Minor defect: the unknown-city query string is interpolated into innerHTML unescaped (index.html:61) — self-XSS only on a static page, so acceptable here, but worth noting.

A focused node:test unit suite (test/weather.test.mjs) that pins the three brief scenarios with concrete value assertions — rome → temp 29 / condition "sunny" (test/weather.test.mjs:5-12), bangkok&units=f → 91°F (lines 15-20), atlantis → { ok:false } (lines 22-26) — plus meaningful boundaries beyond the happy path: conversion rounding in both directions (78.8→79, 66.2→66, 91.4→91, lines 28-32), case/whitespace tolerance, empty and null query handling, and dataset integrity (lines 34-42). All assertions check exact expected values, none are tautological, skipped, or hard-coded; tests specify behavior of the exported lookup/toFahrenheit API rather than restating implementation. A deterministic run at the task commit confirms 6/6 pass, 0 fail, 0 skipped. The one gap: tests exercise only the logic module, never the assembled page — index.html's template rendering (e.g., the literal "unknown city" h1, the °C/°F links) is untested, so a regression in the thin render layer would slip through; for a static widget of this size the coverage is otherwise proportionate.

Clean three-way separation for a task of this size: the pinned dataset and all domain logic (conversion, lookup, view-model shaping) live in a framework-free ESM module (data/weather.js), presentation is confined to index.html's inline render script plus style.css, and node:test covers the logic in isolation. lookup() returns a view model so rendering never touches raw data or conversion math, and query-string parsing stays in the presentation layer where it belongs. Component boundaries are small and single-purpose (toFahrenheit, lookup, switcher), dependencies flow one way (index.html and tests import data/weather.js; the data module imports nothing — no circularity), and README maps each file's role. Structure is proportional: no framework, no build step, no needless layering — a single well-organized page script is appropriate here. Minor deduction: the DOM-building script is embedded in index.html (not independently testable, presentation data like the ICONS map co-located with it), which is proportionate for this scale but slightly less isolated than the data module.