Remix

Make your own version of Actually See

Edit the prompt below and GenMB builds your own version in a few minutes.

Original by Renu Jain

Describe your app

We are starting a new browser-based puzzle website. This is the FOUNDATION phase only.

IMPORTANT:

* Do not build the puzzle gameplay yet.
* Do not create Impossible or Observe gameplay yet.
* Do not add authentication.
* Do not add AI APIs or paid services.
* Do not add unnecessary backend infrastructure.
* Keep the architecture clean and easy to extend in later prompts.
* Do not over-engineer anything.
* Make all current work stable before finishing.
* Use the existing GenMB project structure and conventions rather than introducing unnecessary dependencies.

PRODUCT CONCEPT:

The website is an observation-focused puzzle experience with two future modes:

1. IMPOSSIBLE
   Players inspect a realistic scene and find something that violates reality, logic, physics, time, perspective, or context.

2. OBSERVE
   Players briefly study a realistic scene, then the scene disappears and they answer questions about what they saw.

Do NOT implement those modes yet. This prompt only creates the foundation they will use.

BUILD THE FOLLOWING:

1. APP SHELL

Create the basic application shell and routing for:

/
/impossible
/observe
/daily
/progress

The Impossible, Observe, Daily, and Progress pages can initially be placeholder states that clearly indicate the feature will be built in a later phase.

Do not create fake gameplay inside these pages.

2. HOMEPAGE

Create a polished landing page for the product.

Use a clean, cinematic, modern puzzle aesthetic rather than a school/quiz/dashboard aesthetic.

The homepage should contain:

* A strong hero section
* Main headline:
  "How well do you actually see?"
* Supporting text explaining that the website contains two observation-based puzzle modes.
* Two large mode cards:

IMPOSSIBLE
"Something isn't right.
Find what breaks the scene."

Button: "Play Impossible"

OBSERVE
"Look carefully. You won't have long.
Remember what you see."

Button: "Play Observe"

* A small Daily Puzzle section
* A small Progress section
* Clear navigation to Impossible, Observe, Daily, and Progress

The homepage should already feel like a real finished product even though the actual gameplay is not implemented yet.

3. VISUAL SYSTEM

Establish a consistent visual design system that can be reused across all future pages.

Direction:

* Cinematic
* Minimal
* Sophisticated
* Slightly mysterious
* High visual contrast
* Generous spacing
* Strong typography
* Subtle motion
* No childish/cartoon styling
* No generic SaaS dashboard appearance

The puzzle scenes will eventually be realistic/cinematic, so the surrounding interface should complement that.

Make the design responsive from the beginning.

Desktop, tablet, and mobile layouts must all work properly.

4. NAVIGATION

Create a simple persistent navigation system.

Navigation items:

Home
Impossible
Observe
Daily
Progress

The current page should have a clear active state.

On mobile, use an appropriate compact navigation pattern.

5. FOUNDATION DATA STRUCTURE

Create clean TypeScript data types/interfaces for the future puzzle system, but do not populate the app with full gameplay yet.

Create conceptual types for:

ImpossiblePuzzle
ObservePuzzle
ObserveQuestion

The structures should support:

ImpossiblePuzzle:

* id
* scene
* category
* difficulty
* anomaly location
* anomaly tolerance
* explanation

ObservePuzzle:

* id
* scene
* observation duration
* difficulty
* questions

ObserveQuestion:

* id
* type
* question
* options
* correct answer
* explanation

Keep these types easy to expand later.

6. SCENE ARCHITECTURE

Prepare a reusable scene container/component that future puzzle scenes can use.

It should support:

* responsive sizing
* image/background scene
* positioned interactive details
* overlay layers
* future click/touch coordinates
* future countdown UI

Do not implement actual puzzle interactions yet.

The important goal is to make it possible for later prompts to add realistic scenes without restructuring the application.

7. LOCAL PROGRESS FOUNDATION

Prepare a very small local persistence layer for future progress.

For now it only needs to establish the structure for storing:

* completed puzzles
* solved puzzles
* Impossible stats
* Observe stats
* daily puzzle completion
* best streak

Do not build a large account system.

Use local persistence appropriate for the current app.

8. ERROR/EMPTY STATES

Create polished reusable states for:

* no puzzle available
* page loading
* invalid puzzle
* missing scene
* generic error

They should match the visual identity rather than looking like default browser errors.

9. QUALITY REQUIREMENTS

Before finishing:

* Check every route.
* Check desktop and mobile layouts.
* Make sure there is no horizontal overflow.
* Make sure navigation works.
* Make sure buttons and links do not lead to broken routes.
* Make sure there are no console errors.
* Make sure the foundation does not contain fake gameplay.
* Make sure the architecture is ready for the next implementation prompts.

Do not change or add features outside this scope.

At the end, briefly report:

1. files/components created or modified
2. routes created
3. data types created
4. persistence foundation created
5. any issues found during verification

Free to use. No credit card required.