All The Countdowns

APP NAME
All The Countdowns

APP IDEA
A single scrolling page of live progress bars, each showing how far along something currently is, from the next minute all the way out to the heat death of the universe.

CORE EXPERIENCE
The app opens directly on the list of bars. Each row is a label with an emoji, a right-aligned "N left" readout, and a horizontal bar filled to the current progress. Everything updates live without any interaction.

INTERACTION AND STATE
All values are computed from the device clock and pure formulas; nothing is fetched. Short-period bars tick every second, long-period bars can update every minute. Moon phase rows are computed from a standard synodic-month calculation. One row is self-referential: it reports how many pixels of this page are left below the current scroll position and fills as the user scrolls. There is no input beyond scrolling.

VISUAL AND CONTENT DIRECTION
A light page, one card holding all rows, each row with the emoji and label on the left in medium weight, the remaining-time readout right-aligned in a tabular figure style, and a rounded green fill bar underneath on a light track. Rows are evenly spaced with thin separators.

OUTCOME
A live, continuously updating snapshot of thirty things in progress right now, shareable as an image of the current state.

ONE-SENTENCE INSTRUCTION
Scroll down to watch thirty different things tick along in real time.

TASK-SPECIFIC REQUIREMENTS
Include exactly these thirty rows in this order, with these emoji and labels:
🕑 Next minute / 🕑 Next hour / 🌅 Next day / 📅 Next month / 🎆 Next year / 💑 Next Valentine's Day / 🍀 Next Saint Patrick's Day / 🐇 Next Easter / 👩 Next Mother's Day / 👨 Next Father's Day / 👻 Next Halloween / 🦃 Next Thanksgiving / 🎅 Next Christmas / 💻 End of this page / 🌑 Next New Moon / 🌒 Next Waxing Crescent / 🌓 Next Quarter Moon / 🌔 Next Waxing Gibbous / 🌕 Next Full Moon / 🌖 Next Waning Gibbous / 🌗 Next Last Quarter Moon / 🌘 Next Waning Crescent / 📅 Next decade / 📅 Next century / 📅 Next millennium / ☄️ Halley's Comet returns / 🏭 Chernobyl is fully safe again / 🛰️ Voyager 1 reaches the Oort Cloud / 🌌 Milky Way collides with Andromeda / ☀️ The Sun dies / ❄️ Heat Death of the Universe
Use these long-horizon anchor dates: Halley's Comet 2061, Chernobyl fully safe in the year 2200, Voyager 1 reaching the Oort Cloud in about 300 years, Milky Way–Andromeda collision in 4 billion years, the Sun dying in 5 billion years, and heat death expressed as 10^100 years. Easter must be computed, not hard-coded. All initial rendering must be deterministic: do not call Date.now() during first render, put every clock read inside a client effect.

Server-render determinism: do not call Date.now(), new Date() or Math.random() during initial render. Read the clock and generate randomness only inside client effects, and hard-code the default locale to English rather than detecting navigator.language, so first paint is identical on server and client and never produces a hydration mismatch.

REPLICATION SCOPE

This specification is a faithful rebuild of an existing reference experience, described here in full. Reproduce it as closely as the platform allows.

Must be reproduced exactly: the complete content inventory listed above with its exact ordering and wording, the mechanic and its state transitions, the copy voice, the visual structure and the overall pacing. Do not add levels, items, scoring, achievements, timers, onboarding or extra features that are not described here. Do not drop or abbreviate any listed content.

Acceptable platform adaptations, and only these: touch input in place of mouse input; layout reflow for a phone-sized portrait host; the bilingual layer, the one-sentence instruction and the result/Replay/Share affordances required below; and host safe-area insets. Everything else stays as specified.

All content must be self-contained. Do not call any external API, data service, map, media or image service at runtime; every dataset, table, constant and asset this app needs must live inside the project.

IMPLEMENTATION INSTRUCTIONS

Treat this specification as the final implementation brief and build the complete app now.

Open directly into the live app experience. Do not add a splash screen, opening cover, welcome page or separate onboarding flow.

Include exactly one concise sentence that explains how to play or use the app. Use the sentence provided under ONE-SENTENCE INSTRUCTION. Show it inside the live app interface, not on a separate opening screen.

Internationalization is required. Implement a lightweight built-in i18n layer supporting exactly two locales: English (en) and Simplified Chinese (zh). The app must always open in English and must never auto-detect or follow the browser, device or system language. Provide one clear EN / 中文 language toggle. Every user-facing string, including the one-sentence instruction and all loading, empty, success, error and result states, must have complete English and Chinese versions. Switching languages must update the entire interface without mixed-language text or untranslated fallback strings.

Let Eazo adapt the app to its actual host and available viewport. Do not hard-code or target a particular browser size, device size, viewport width or height, App frame size, root-height formula, or host-container CSS implementation. In the live preview, keep the current primary action easy to discover and usable without requiring an initial downward scroll; avoid horizontal overflow and avoid decorative layers blocking required controls. Optional detail may scroll. Keep active media and secondary copy compact enough that the next action remains visible. In result states, show the summary plus Replay and Share before optional detail. Do not eagerly render a large collection of full-size result images in one long page; use a compact summary, carousel, pagination, expansion, or virtualization. Use accessible touch targets.

Respect the host safe areas for iPhone notches, Dynamic Island, the status bar and the bottom home indicator in the initial implementation, before the first preview. Apply the safe-area treatment to the App's entire usable content region across the live flow, result, modal, empty and error states, not only to the first header. Keep the header, language toggle, primary controls and result actions entirely inside the usable safe area. In the standard Eazo mobile host, use `padding-top: max(56px, env(safe-area-inset-top, 0px))` and `padding-bottom: max(34px, env(safe-area-inset-bottom, 0px))`, or Eazo's current official safe-area equivalent. If the header or action footer is sticky or fixed, include the matching inset in that region and reserve content clearance so it does not overlap the scrollable body. These are safe-area insets only, not fixed viewport or App-frame dimensions; continue to let Eazo adapt the overall width and height. Make sure flex children can shrink inside the remaining usable area and that required controls are not covered or pushed off screen.

Use Eazo's built-in defaults and official platform capabilities. Do not add unrelated features or expand the scope beyond this specification.

When implementation is complete, provide a working preview for QA.