Omaha Beach, in 3D

Build an interactive 3D reconstruction of **Omaha Beach on D-Day — 06:00 to 13:00, June 6th 1944** — for a student who wants to understand not just what happened but why it happened that way. It runs in the browser, and it has to be good enough that someone learns the battle from it.

You are running headless. Do not ask me any questions, do not stop for approval, and do not wait for input. Make every decision yourself and finish the whole thing in one pass. Bring your own headless browser (Playwright or Puppeteer) for testing.

### Deliverable

A single deployable web app in `./omaha`, built with Three.js. It must run from a static build with no server-side dependency, and it must hold 60fps on an M-series Mac at 1920×1080. Document the build and run commands in `RUN.md`.

### The terrain — this is the part I will judge hardest

Reconstruct the ~8 km of coast from Vierville-sur-Mer in the west to Colleville-sur-Mer in the east, from 1 km offshore to 1 km inland. Build it from real elevation data, not from imagination — source a DEM for the Calvados coast and drape it. The single most important feature is the **bluff**: a 30–45 m rise running the length of the beach, cut by five draws — **D-1 Vierville, D-3 Les Moulins, E-1 Saint-Laurent, E-3 Colleville, F-1** — which were the only vehicle exits off the sand and therefore the entire objective of the morning. Label the beach sectors too, west to east: Charlie, Dog Green, Dog White, Dog Red, Easy Green, Easy Red, Fox Green, Fox Red. A student needs those names to understand that the waves came ashore well east of where they were meant to. If your terrain does not make it visually obvious why an army had to take those five gaps, the build has failed at its main job.

The terrain must carry, in the right places: the shingle bank, the seawall along the western half, the tidal flat, the beach obstacles (Belgian gates, hedgehogs, stakes) in the band where they actually sat, the German strongpoints (the WN-numbered positions) sited on the bluff with their real fields of fire, and the draw exits. Ground textures should read as sand, shingle, marram grass and cultivated field, not as one tiled noise.

**The tide is a mechanic, not decoration.** Model the real tidal curve for that morning. At H-Hour the water is low and the obstacle belt is exposed with several hundred metres of open sand to cross; by mid-morning the water has risen over the obstacles and the beach has narrowed. The water level must move with the timeline, and the app must let the student see that the tide is what changed the problem.

Light it for early morning under overcast — low sun, soft directional light, haze offshore, no warm golden-hour treatment. Smoke from the grass fires on the bluff should build across the morning, since it genuinely changed what the naval gunners could see.

### How it has to look

It has to look real. Not stylized, not a diagram with some 3D on it — like footage. Everyone watching this has the opening of Saving Private Ryan in their head, and that is the bar: cold overcast light, smoke and haze thickening down the beach through the morning, sand and water that read as sand and water.

Work out how to get there yourself, and use whatever assets, techniques and libraries get you closest — you do not have to model everything from scratch.

What it cannot be: men who read as capsules, blobs or untextured shapes; flat-shaded ground; a scene that looks lit by default lighting. If you cannot make something hold up at a given camera distance, do not put the camera there.

### The timeline — 06:00 to 13:00, minute resolution

A scrubbable timeline is the primary control: play, pause, scrub, and a speed control from real-time up to 60× . As it runs, the units move on the terrain and the state of the battle changes with it.

Represent, as they actually moved: the assault waves by boat section, the DD tanks (including the ones launched too far out), the engineer demolition teams working the obstacle belt against the rising tide, the German defensive positions and their arcs, the destroyers that closed to point-blank range late in the morning, and the small ad-hoc groups that got up the bluff between the draws rather than through them. Units are legible markers with unit identifiers — not toy soldiers, and not featureless dots.

Every unit and event on the timeline must be clickable, and clicking it explains itself.

### The teaching layer — the actual point of this

A student should come away understanding the *decisions*, not just the sequence. Build in:

- **Six to nine decision points** on the timeline, each of which stops and explains: what the commander knew at that moment, what options were on the table, what was chosen, and what it cost. The bombardment falling long, the DD tanks being launched into the sea state, the current pushing the landing east of the marked sectors, the shift from taking the draws to climbing between them, the destroyers coming in close, and the exits finally opening.
- A **"why here" mode** that overlays the terrain reasoning: the fields of fire from the strongpoints, the dead ground, the draws as the only vehicle exits, and the reason a plan built on the bombardment working fell apart when it didn't.
- A **compare-the-plan-to-what-happened** view — the intended landing sector for each unit against the sector it actually came ashore in.
- Casualty and strength figures shown as they change through the morning, with their sourcing visible.

### Sourcing rules — non-negotiable

Every timestamped event, every unit designation, every casualty figure and every strength number must be traceable to a real source, and each one carries an inline citation the student can open. Use the US Army Center of Military History's official history, the after-action reports, and other primary documentation. Where sources disagree, say so in the app rather than picking one silently. Where you do not know something, say you do not know. **Do not invent a single number, unit, time or name.** A confident fabrication is worse than a gap, and I will check them.

Keep a `SOURCES.md` listing every source you used and what you took from each.

### Acceptance criteria — verify each of these yourself before you finish

1. It deploys and loads to an interactive state in under 5 seconds on a cold load.
2. Scrubbing the timeline moves units and the tide together, and running it at 60× holds framerate.
3. The five draws are individually identifiable on the terrain and each is labelled.
4. Every decision point opens, and every one of them cites its source.
5. Take screenshots at 06:30, 08:00, 10:00 and 13:00 from a camera position offshore, plus one from the bluff looking down at the beach, and save them to `qa/`. Look at them. If the bluff does not read as commanding ground, or the beach reads flat, fix the terrain and shoot again.
6. Look at your own screenshots and ask whether they could pass for footage. If the figures read as blobs or the beach reads flat, fix it and shoot again.
7. Pick three claims from your own timeline at random and re-verify them against your sources. Note the result in `BUILD_NOTES.md`.

Write `BUILD_NOTES.md` covering where your terrain data came from, how you built the tide model, which events you could not source and therefore left out, and anything you could not get to.