Ornith 9B —
why the run failed

The Ornith 1.5 9B 8-bit build never gets past its own "Descending…" loading screen. No frame is ever rendered. This is the full post-mortem: what crashed, where, and why the smaller model's architecture choices both helped and doomed it.

An ambitious, modern Three.js build — that was never run.

The script crashes with an uncaught exception during initial scene construction, before the first frame. Because the loading overlay is only faded after the first successful render, the page sits on "Descending…" forever, with no error surfaced in the UI. Patching the first crash immediately reveals a second fatal crash in the animation loop. Two non-fatal logic bugs are hiding behind those.

deckWidth referenced out of scope

Console output when loading the file (headless Chrome, console piped to stderr):

Uncaught ReferenceError: deckWidth is not defined  (line 559)

deckWidth is declared as a const inside makeBridge():

function makeBridge() {
  // ...
  const deckWidth = 4.6;          // line 507 — function-scoped to makeBridge()
  // ...
  const lantern = makeLantern(z); // line 550 — calls a *separate* function
}

…but referenced inside makeLantern(), a different top-level function where it does not exist:

function makeLantern(z) {
  const g = new THREE.Group();
  const lx = rand(-deckWidth * 0.35, deckWidth * 0.35);  // line 559 — ✕ ReferenceError

makeBridge() is invoked at module top level (line 581), so execution dies right there. Everything after — kelp, coral, jellyfish, fish, bubbles, rays, the moon aperture, the composer, the animation loop — never runs.

Why the loader never clears: the "Descending…" overlay is only hidden after the first rendered frame:

// Fade out loading screen once the first frame renders.  (lines 973–978)
renderer.render(scene, camera);
requestAnimationFrame(() => {
  loadingEl.classList.add('hidden');
  animate();
});

Line 974 is never reached, so the overlay stays up indefinitely. A nice pattern — but it also means the failure is completely silent in the UI.

userData.path shape mismatch

With bug 01 patched in a scratch copy, the next error fires every frame:

Uncaught TypeError: Cannot read properties of undefined (reading 'speed')  (line 916)

makeFish() stores the swim-path object directly on userData:

const path = { cx, cz, radius, height, speed };
g.userData = path;                 // line 740 — userData IS the path

…but the animation loop reads it through a .path property that was never set:

fishes.forEach((f) => {
  const p = f.group.userData.path; // line 915 — undefined
  const a = t * p.speed + p.cx;    // line 916 — ✕ TypeError
});

Either g.userData.path = path (write side) or const p = f.group.userData (read side) would fix it. As shipped, the two sides of the data contract disagree.

Non-fatal bugs hiding behind the crashes

9B 8-bit vs. the working 35B 4-bit run

9B wrote the better blueprint; 35B shipped the working product. The prompt test measures shipped products.

The 9B output contains two independent fatal runtime errors that any single execution — even just opening the file once — would have exposed instantly. Neither bug is subtle; both throw on the very first code path. The 9B model produced a convincing looking program (good comments, sensible structure, considerate loading UX) without ever checking that it works. For a prompt test whose prompt says "actually generate the complete working HTML file," that's a failed task regardless of architectural taste.