Everything That Happens Next

APP NAME
Everything That Happens Next

APP IDEA
A long downward scroll through everything science says is still going to happen, from a comet returning in a few decades to the last light in a dying universe.

CORE EXPERIENCE
The app opens on a dark starfield with the title and a line asking what the future of the universe is, a second line saying that with some science we can make a few predictions, and a crystal ball. Scrolling downward moves forward through time; each era is announced by a horizontal divider carrying its date, followed by one or more short sentences and an illustration.

INTERACTION AND STATE
The whole experience is one continuous vertical scroll with no controls other than scrolling. Each era section fades or slides its illustration and text in as it enters the viewport. The dividers carry the era label. There is no timer, no score, no failure state and no branching. The closing section is a short reflection and a Share of the whole journey.

VISUAL AND CONTENT DIRECTION
Deep black background with a fine field of small stars in white and soft purple, plus a row of hanging purple star-and-moon ornaments across the very top. Illustrations are flat vector scenes in a limited palette: solid-colour planets with simple banding, ring shapes, particle bursts and silhouettes, never photographic. Era dividers are thin purple rules with the label centred. Body text is centred, generous and short-lined.

OUTCOME
The final passage lands on the idea that if the life of the universe were a year, the reader is living in the first millisecond of January 1st — so enjoy the ride — followed by Replay and Share.

ONE-SENTENCE INSTRUCTION
Scroll down to travel from a few decades from now to the end of the universe.

TASK-SPECIFIC REQUIREMENTS
Use exactly these 24 eras in this order, with this content:
In 2061 — Halley's Comet will return again.
In 2178 — Pluto will complete its first orbit since discovery.
In 2300 — After travelling billions of kilometres, Voyager 1 will finally reach the Oort Cloud.
In 50,000 years — The star VY Canis Majoris will explode in a supernova. The explosion will outshine the rest of the Milky Way.
In 75,000 years — A new Hawaiian island will surface.
In 100,000 years — Many of today's constellations will be unrecognisable.
In 1 million years — Two of Uranus' moons will collide. The planet can't catch a break.
In 50 million years — The Martian moon Phobos will slowly break up. So Mars will get its own ring.
In 100 million years — As Mars gains a ring, Saturn will slowly lose them. Oddly, Saturn will spend most of its life without rings. It's just a phase.
In 180 million years — The Moon continues gradually slowing down the Earth. Days become 25 hours long. Hopefully work hours don't also increase.
In 600 million years — The last total solar eclipse happens. Since the moon is further away, total solar eclipses will no longer be possible. Don't forget your glasses! This is one you don't want to miss.
In 800 million years — As the Sun becomes brighter, photosynthesis is no longer possible on Earth. Without plant life, all animals go extinct. And single cell organisms dominate the Earth once again.
In 1.1 billion years — The Sun will be 10% brighter. The average temperature on Earth will reach 47 °C, or 116 °F. And so the oceans will evaporate. But on the bright side, Mars will enter the habitable zone and could provide a new home.
In 5 billion years — The Andromeda Galaxy will collide with the Milky Way. And our new home galaxy will be called Milkdromeda. We will gain a trillion neighbouring stars. Anyone left will see an incredible night sky.
In 7 billion years — As the Sun becomes a red giant, it grows to 256 times its current size. After billions of years of providing energy to the Earth, the Sun eats the Earth. It was a good run, but the Earth was freeloading for too long. The Sun also eats Mercury and Venus for good measure.
In 8 billion years — After the Sun's rampage, it cools down. And becomes a white dwarf star. Any remaining life will need to get a lot closer to stay warm.
In 450 billion years — The 50+ galaxies in the Local Group merge. The group is back together.
In 1 trillion years — Radiation leftover from the Big Bang becomes undetectable. Making it harder for future civilizations to learn about the universe.
In 10 trillion years — Red dwarf stars turn into the first ever blue dwarf stars.
In 100 trillion years — The gas clouds needed to make stars are depleted. Somewhere in the universe, the last star is born. And soon only white dwarf, brown dwarf, and neutron stars are left.
In 10^15 years — Everything outside the Local Group is impossible to reach due to the expansion of the universe. Even the speed of light won't be fast enough to reach distant galaxies.
In 10^17 years — White dwarf stars cool to black dwarf stars. The universe is dark. The only natural light comes from the occasional supernova.
In 10^30 years — Black holes are the only things remaining, and they are massive. But even they slowly evaporate from Hawking Radiation. In the last few seconds of a black hole's life, it will emit a burst of light. Providing the last light in the universe. Like a final firework show, but each firework billions of years apart.
Closing — After that the universe is basically dead, with nothing of interest happening. But don't worry, there's plenty of time left. If the life of the universe was a year, you're living in the first millisecond of January 1st. So enjoy the ride.
Render the 10^15, 10^17 and 10^30 labels with proper superscript exponents. Every one of these lines needs a complete natural Simplified Chinese translation; numbers, units and the temperature figures stay identical in both locales.

IMAGE ASSETS TO GENERATE
Generate exactly 24 flat vector illustrations during the build, one per era, saved as local project assets at stable paths such as /forecast/era-01.webp through /forecast/era-24.webp. Each illustration is the scene named by that era: a bright comet with a long tail; a small pale dwarf planet wearing a party hat against confetti; a tiny probe leaving a dark cloud of icy debris; a red supergiant tearing apart in a supernova flash; a new volcanic island breaking the ocean surface; a star map whose constellation lines have drifted apart; two small moons colliding above a pale blue-green planet; a small moon crumbling into a ring around a red planet; a ringed pale-gold planet losing its rings while the red planet gains them; a moon drifting away from a slowly turning Earth; a final total solar eclipse ring; a browning Earth with no plant life; an Earth with evaporating oceans beside a warming red planet; two spiral galaxies merging; a swollen red giant engulfing the inner planets; a small white dwarf; a cluster of galaxies pulling together; a faint fading background glow; small red stars turning blue; a last star igniting in an emptying sky; distant galaxies receding beyond reach; cold black dwarfs in total darkness; a black hole emitting a final burst of light; and a single small spark alone in the dark for the closing.
Style rules for the whole set: one consistent flat-vector style across all 24 so they read as a single series; solid fills and simple banding, no photographic textures and no realistic rendering; a dark background matching the page so each illustration sits seamlessly on the starfield; a limited palette of purple, white, warm orange and the specific planet colours; identical canvas size and aspect ratio for every image. No text, numbers, labels, watermarks or logos inside any image.

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.

IMAGE DELIVERY AND SWAP PERFORMANCE

Generate every image during the build and save it as a local project asset under a stable public path. Never call an image API at runtime and never hotlink a third-party URL.

Export every runtime image as WebP sized to roughly twice its maximum rendered CSS width while preserving its intrinsic ratio. Target 200 KB or less per file and treat 300 KB as the hard maximum. Never ship multi-megabyte masters. Serve the files directly from stable `public/` URLs and do not make their visibility depend on the `/_next/image` optimization service; if this project has an `images` configuration, keep `images.unoptimized: true` for this direct-static-asset path.

Every image must be visible the instant it is needed — no blank frame, no spinner, no visible swap, no layout shift. Preloading alone is not sufficient: reassigning `src` on a single `<img>` still costs a decode even when the bytes are already cached, which shows as a visibly empty box for 100 to 200 ms. Implement it so that never happens:

If the app shows one image at a time out of a fixed set, mount every image in the set from the first render as stacked absolutely-positioned layers inside a fixed-ratio container, each with `loading="eager"` and `decoding="sync"`, and switch between them purely by toggling opacity or visibility. Do not use conditional rendering that mounts and unmounts them, and do not key them in a way that makes the framework recreate the elements — each element stays mounted for the whole session so it never decodes twice.

If the set is too large to mount at once, use a double buffer instead: two stacked layers, where on a change you set the incoming layer's `src`, await its `decode()`, and only then flip which layer is visible, keeping the previous image fully visible during the wait.

If images appear progressively while scrolling, create `Image()` objects for the whole set on mount, assign the direct WebP URL, call `decode()` where available, and keep a module-level `Set` of warmed URLs so each file is fetched and decoded only once. Reserve each image's box with a fixed aspect ratio so the layout never shifts as it appears.

Acceptance: advancing through the images as fast as the interface allows must never produce a frame in which the visible image element reports `complete === false` or `naturalWidth === 0`, and the image container must never be empty or change height between states. Verify this yourself before delivering.

Keep a clean named fallback if a file ever fails to load, and never show a broken-image icon.

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, the bottom home indicator and the host's persistent bottom toolbar 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(88px, 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.