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 a session tracks code health, every check scores it as one composite:
duplication, complexity and dead code in the code you commit, plus your
tests (the share failing) and their coverage once ololo can run them. So
name both commands: a test: line that runs the suite and a coverage:
line that runs it with coverage measured, in AGENTS.md or README.md (or
test and coverage scripts in package.json). The task's health bonus is
paid on that score.

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.