Earthquake Explorer

<challenge>
Design and build the best possible application for exploring live earthquake activity around the world. Aim for the strongest UI, UX, product thinking, visual design, interaction design, and implementation quality you are capable of producing.

This is a real data product, not a decorative dashboard. It should help a curious person, journalist, researcher, or traveler quickly understand what is happening, where it is happening, how significant it may be, and what deserves closer attention.

Build the complete experience in the current repository. Use the existing stack and conventions where they are sound. The finished application must be 100% functional with live USGS data. Every visible control, filter, interaction, map behavior, data view, state, and navigation path must work. Do not leave placeholders, mock controls, simulated interactions, unfinished sections, or TODOs.
</challenge>

<data>
Use the free USGS Earthquake APIs. They require no API key.

Recommended real-time GeoJSON feed:

https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_week.geojson

Other useful feeds:

- Past hour: https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_hour.geojson
- Past day: https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_day.geojson
- Past 30 days: https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/all_month.geojson
- Significant events this month: https://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/significant_month.geojson

For custom queries, use:

https://earthquake.usgs.gov/fdsnws/event/1/query?format=geojson

Useful fields include magnitude, place, event time, update time, coordinates, depth, felt reports, significance, alert level, tsunami flag, review status, event type, detail URL, and the official USGS page URL.

Use real returned values throughout the interface. Do not hardcode event counts, chart curves, locations, or summary statistics. Clearly attribute USGS as the data source and expose when the data was last refreshed.
</data>

<product-intent>
The experience should answer these questions immediately:

1. What is happening right now?
2. Where are the most significant recent earthquakes?
3. Is the current selection ordinary, notable, or potentially concerning?
4. How has activity changed over the selected period?
5. How can I move naturally between the global picture and one specific event?

The default view should be useful within five seconds, before the user configures anything.
</product-intent>

<design-direction>
Create a trustworthy, calm, precise seismic observatory with a strong sense of place, depth, and time.

Draw visual inspiration from topographic maps, geological survey instruments, contour lines, tectonic boundaries, seismograph traces, mineral surfaces, and field notebooks. Translate that world into a contemporary digital product rather than imitating an old scientific terminal.

Create one signature interaction that could only belong to this product. A strong direction is a connected seismic timeline: scrubbing or selecting activity in time should illuminate the corresponding events on the map and in the event stream, while selecting a location should reveal its position in time. You may invent a better signature if it makes exploration more intuitive.

Avoid the generic dashboard recipe of a sidebar, four equal KPI cards, an arbitrary chart grid, and a table placed underneath. Avoid decorative gradients, excessive glass effects, rainbow map markers, and motion without meaning. The interface should feel designed from earthquake data outward.

Use a restrained visual system with excellent typography, deliberate information density, subtle layering, and semantic color. Magnitude, depth, alert status, selection, and recency must be distinguishable without relying on color alone.
</design-direction>

<core-experience>
Create a cohesive experience that includes:

- A real interactive geographic map as the central product surface. The map is mandatory and may not be replaced by a static image, decorative illustration, abstract canvas, list, or chart.
- A proper geographic basemap with working pan, zoom, event markers, dense-event clustering or an equally effective overlap solution, selection, and responsive behavior.
- An event stream or data list synchronized with the map.
- Time controls for the past hour, day, 7 days, and 30 days.
- Useful filters for magnitude, depth, alert level, tsunami flag, review status, and geographic area.
- Search for places or regions when the available stack makes reliable geocoding possible.
- Clear sorting, active-filter visibility, one-action reset, and a meaningful result count.
- A focused event detail experience with magnitude, human-readable location and local time, depth, significance, felt reports, alert and tsunami information, review status, coordinates, and a link to the official USGS event page.
- A real activity timeline or distribution view derived from the loaded dataset.
- Shareable or bookmarkable state for meaningful filters and selected events.
- A visible refresh action and honest last-updated status.

Map, timeline, event stream, filters, and details should behave as one system. Hovering, focusing, or selecting an event in one representation should reveal the same event in the others without losing the user's context.
</core-experience>

<interaction-quality>
Make exploration feel immediate and controlled:

- Preserve zoom, filters, scroll position, and selection when moving between overview and detail.
- Use progressive disclosure so first-time users see a clear story while experienced users can reach powerful filters quickly.
- Provide obvious focus, hover, selected, disabled, and pressed states.
- Make map clusters, overlapping events, dense regions, and events at nearly identical coordinates understandable.
- Use short, purposeful transitions to preserve spatial context. Respect reduced-motion preferences.
- Use plain language and explain domain terms such as magnitude, depth, significance, and alert level at the point of need.
- Never imply that magnitude alone predicts damage.
</interaction-quality>

<states>
Treat every state as part of the design:

- Initial loading with a stable, informative skeleton.
- Background refresh without blanking the existing data.
- Empty results with the active constraints explained and a direct recovery action.
- Network or API failure with retry and preserved filters.
- Offline or stale-data state with the age of the displayed data clearly shown.
- Partial or missing fields without broken labels, empty badges, or misleading zero values.
- One event, thousands of events, long place names, and rapidly updated events.

Never silently replace failed live data with fictional data. If development fixtures are used, label them unmistakably as sample data.
</states>

<accessibility>
The primary experience must work without a mouse.

- Use semantic HTML and accessible primitives.
- Provide a complete keyboard path through filters, the event stream, details, and a non-map alternative for every map-only action.
- Maintain visible focus and logical focus order.
- Announce loading, refresh, result-count, selection, and error changes appropriately.
- Ensure charts and map insights have textual equivalents.
- Meet WCAG AA contrast, support 200% zoom, and use touch targets of at least 44 by 44 pixels.
- Do not encode severity, selection, or status with color alone.
</accessibility>

<responsive-experience>
Design desktop and mobile as intentionally different compositions of the same product.

On desktop, use the available space to support comparison between geography, time, and event details. On mobile, prioritize one-handed exploration, readable event summaries, reachable controls, and smooth movement between map and list. Do not merely stack the desktop dashboard into a long page.

The core tasks must remain fast and understandable at approximately 390 pixels wide, on tablets, and on large desktop screens.
</responsive-experience>

<trust-and-safety>
This is an exploration and public-information product, not an emergency alert service.

- State that data comes from USGS and may be revised.
- Never claim to predict earthquakes or guarantee safety.
- Do not invent evacuation guidance, damage estimates, or emergency recommendations.
- When relevant, direct users to official local authorities and the linked USGS event page for authoritative information.
- Display times and time zones unambiguously.
</trust-and-safety>

<creative-freedom>
You have creative freedom over the layout, visual language, typography, map treatment, data visualizations, components, and motion.

First understand the domain, the human using the product, and the decision each screen supports. Then make bold but defensible design decisions. Prefer one memorable, deeply integrated interaction over many superficial effects.

Do not explain the design before building it. Make the decisions yourself and implement the complete experience. The objective is not to produce a quick prototype; it is to create the best complete application you can produce within the current repository.
</creative-freedom>

<execution-constraints>
Implement the application directly and completely, but do not execute it or test it.

You are strictly forbidden from:

- Running automated or manual tests.
- Running test, typecheck, lint, build, preview, or development-server commands.
- Starting, opening, or launching a browser.
- Using browser automation, browser developer tools, screenshots, visual inspection tools, or external preview tools.
- Starting a local server or making HTTP requests to verify the application.

These restrictions do not reduce the quality bar. You remain responsible for producing a 100% functional application using careful implementation and static reasoning. Do not omit features merely because you cannot execute them.

When implementation is complete, verify the work only through a static review of the source files. Confirm from the code that the real map, live USGS integration, interactions, responsive states, accessibility behavior, and error states have all been implemented and that no placeholders, dead controls, TODOs, or unfinished sections remain.
</execution-constraints>

<final-response>
After the static verification is complete, do not provide an explanation, summary, test report, caveat, or list of files.

Your entire final response must be exactly these two lines:

acknowledge
terminer
</final-response>

<success-criteria>
The result succeeds when:

- A real interactive map is the central experience and its basemap, navigation, markers, overlap handling, selection, and synchronization are fully implemented.
- A first-time visitor can identify the strongest recent event and understand where and when it occurred within seconds.
- A user can filter to magnitude 4.5 or greater, inspect an event, return to the overview, and retain their context.
- The product communicates geography, time, magnitude, depth, and uncertainty without overwhelming the user.
- Every important map insight is available through an accessible non-map path.
- Empty, loading, failure, stale, and partial-data states feel intentional and recoverable.
- Mobile feels purpose-built rather than compressed.
- The interface is distinctive enough that it could not be mistaken for a generic analytics template.
- The implementation is polished, responsive, accessible, and genuinely useful with live data.
</success-criteria>