Work as a senior product engineer and finish the application in this specification. This is a real application, not a mockup. Create the complete source tree, configuration, migrations or schemas, working UI, persistence, error handling, and tests. Do not leave stub handlers, simulated production data, TODO features, inert buttons, or invented successful test results.
Start by inspecting the workspace and available tools. Choose compatible maintained dependency versions and pin them in a lockfile. Write a short implementation plan and an acceptance checklist, then implement and run the work without stopping after planning. Use stages to manage complexity, but carry every required stage to completion. If context runs low, save progress and remaining acceptance checks in a local handoff document and resume from it. Ask only about decisions that cannot safely be inferred.
Keep modules small and put domain logic outside presentation components. Validate inputs at trust boundaries, handle cancellation and failures, preserve user data, and provide clear recovery actions. Include keyboard access, labelled controls, visible focus, useful empty/loading/error states, sensible contrast, and reduced-motion support. No advertising, subscriptions, analytics, hidden cloud dependencies, or remote executable loading.
Before finishing, run the compiler/type checker, linting, unit/integration tests, and a production build. Add real workflow tests for the acceptance checklist and run them against the built application where possible. Fix failures and repeat affected checks. Report exact commands, actual results, any environment-blocked checks, setup instructions, and remaining limitations. Never call an unfinished or untested feature complete. Include a README explaining architecture, development, packaging, data locations, permissions, and recovery. Use clean generated sample data only in explicit tests and previews.
Build {{app_name}}, a GNOME Shell taskbar weather extension inspired by Animated Weather. Use GJS ES modules, St/Clutter, Soup3 asynchronous HTTP, optional GWeather location lookup, GTK4/libadwaita preferences and GSettings. Start with one explicitly tested GNOME Shell version; only list additional versions after checking their APIs and testing. Add a compact current-condition control at the far-left taskbar/panel edge, with a forecast popup and gentle condition animations. Keep contrast/size readable and use {{accent_colour}} sparingly.
Files: metadata.json with a developer-owned UUID, extension.js lifecycle, weather data client/parser, weather-icon renderer, prefs.js, stylesheet and validated GSettings schema. Keep pure parsing/formatting/condition mapping separate so tests run without a live Shell. No bundled private API keys, accounts, telemetry or remote executable loading.
Location and privacy: optionally use the first valid location already configured in GNOME Weather, otherwise accept a manually entered city label/latitude/longitude. Validate coordinates and explain that forecast requests send the selected coordinates and IP address to the weather provider. Never copy a developer's personal default location as private configuration; use a clear generic example. Show the active location source. Do not add continuous GPS tracking.
Fetch Open-Meteo current/hourly conditions through HTTPS. Check current provider terms at https://open-meteo.com/en/terms before claiming free or commercial use. Display attribution and document provider limitations. Use cancellable requests, timeouts, bounded response validation and a minimum 5-minute refresh interval; default to 15 minutes. Cache the last successful forecast and timestamp. Offline/timeouts/rate limits show stale data and a readable status, not invented temperatures. Changing location cancels/discards stale responses; disable cancels all requests and refresh timers. Never refresh data on every animation frame.
Show current temperature/condition and day/night icon. Popup has location, current details including humidity/wind as available, and 4–12 scrollable hourly cards, default eight. Parse actual timestamps in the provider timezone rather than label hourly slots using an arbitrary local index. Map WMO codes to clear/cloud/fog/drizzle/rain/heavy-rain/snow/storm with an honest unknown fallback. Handle missing values, invalid JSON, empty hourly arrays and mismatched lengths. Temperature units and refresh/forecast length are preferences persisted through GSettings.
Animations: small local vector/canvas effects for sun/cloud/rain/snow with bounded particles and frame scheduling. Honor reduced motion and pause when actors are not visible or menus are closed. Never keep high-frequency animation running across the whole desktop for a hidden control. Accessible text labels accompany icons and controls; preferences are keyboard usable.
Panel integration: prefer public panel APIs where possible. Make Zorin Taskbar positioning a guarded optional adapter that handles late startup, actor replacement, monitor/layout changes and unsupported versions. Restore all touched properties/hooks and remove timers/signals/actors on disable. A generic panel fallback must work when Zorin integration is absent; never replace the user's dock or edit its system files.
Acceptance: pure tests for every WMO mapping/day-night case, formatting, response validation, timezone edges and stale-response cancellation; schema and packaging checks. In a compatible Shell session test location change during fetch, offline cached display, bad JSON, rate-limited response, day/night, forecast scrolling, reduced motion and repeated enable/disable. Confirm all network requests stop on disable and refresh intervals are respected. Provide install/compile/discover/enable/preferences/disable instructions for the generated UUID, provider attribution and an explanation of data leaving the computer. Never log out/restart the desktop without the operator's consent.
Paste this into your preferred AI assistant. Review its output before running it.
