Build a weather widget: a web page that shows the current weather for a
requested city. You decide when it is done; a judge panel scores the
result — product fit, code craft, and how the page looks in a browser.

The widget knows exactly four cities — this dataset is its weather:

Scenarios:

Scenario: A city's weather card
When a visitor opens /?city=rome
Then the page shows the temperature 29 and the condition "sunny"

Scenario: Fahrenheit on request
When a visitor opens /?city=bangkok&units=f
Then the temperature reads 91 — Celsius converted as C*9/5+32, rounded

Scenario: An unknown city fails politely
When a visitor opens /?city=atlantis
Then the page says "unknown city"

Everything beyond the scenarios is yours: layout, wind, colors, a
forecast row. Keep the code clean — structure and duplication are part
of the score.

Before anything else, write an AGENTS.md (or README.md) documenting the
project: the stack you chose (language, framework, how the code is laid
out) and the commands the platform keeps in session memory - a run:
line with the command that runs the app and a test: line with the
command that runs its tests. Memory is re-read after every completed
task, and the done-check requires both lines.

When you are done, write .ololo/weather-widget-done.md with a short
description of the implemented solution (at least 10 words).

Grow the weather widget: a visitor moves between cities without
touching the address bar, and every city opens into a full forecast.
You decide when it is done; the judge panel scores the result.

The forecast dataset — the widget's only source for it:

Scenarios:

Scenario: Switching cities
When a visitor is on any city's card
Then visible controls take them to every other city's card
And the card they land on shows that city's weather

Scenario: Opening the full forecast
When a visitor opens the forecast from a city's card
Then they see all three days for that city — day, temperature, condition
And they can return to the card they came from

Scenario: The forecast matches the dataset
When the forecast for rome is open
Then day 2 reads 26 and "cloudy"

Switching and the forecast are living flows — the judges verify them
from a screencast of the real widget in motion, so keep it running.

When you are done, write .ololo/weather-widget-forecast-done.md with a
short description of the implemented solution (at least 10 words).

Take the weather widget live: a visitor types any city's name and sees
its real weather, fetched from an actual weather service. Which service
powers it is the builder's call — pick one and say so in your completion
note. You decide when it is done; the judge panel scores the result.

The four familiar cities (nyc, sao-paulo, bangkok, rome) stay as quick
picks, but their numbers go live too — the built-in tables are no longer
the source of truth.

Scenarios:

Scenario: Typing a city name
When a visitor enters "Berlin" and submits
Then the card shows Berlin with its current temperature and condition
And the values come from the live service, not a built-in table

Scenario: Quick picks go live
When a visitor lands on a pinned city's card
Then its temperature and condition are the service's current values

Scenario: An unknown city fails politely
When a visitor enters a name no city has
Then the page says it cannot find that city and the widget stays usable

Scenario: Honest data
When any city's card is open
Then the temperature is plausible for that city, the units match the
°C/°F toggle, and the condition reads as human language

Searching and live values are living flows — the judges verify them from
a screencast of the real widget in motion, and they weigh the data's
quality: plausible values, correct units, coherent conditions.

When you are done, write .ololo/weather-widget-live-done.md with a short
description of the implemented solution (at least 10 words), naming the
weather service you chose.