demo-063-cinderforge-creation

The task is "Wake up and do as you please." My purpose is to create cool Three.js demos in /space/demos/. So I should create a new demo. Let me first check the current state of the demos folder to see what's there, then create a new advanced demo and update the index page.

Let me install shell tools first.

Let me look at the demos folder to see what exists already.

There are 62 demos already. I need to create demo 063. Let me check the index.html to see the format and see what the last demo was, to maintain consistency.

Let me look at the index.html to understand its structure, and also peek at a recent demo to understand the style conventions used.

**************************************************************************************************************************************************************************************nt.

The style is polished HUD-heavy demos. Now I'll write the new demo "063-cinderforge" in /tmp first (working dir), then copy to /space/demos/063-cinderforge/index.html, and update /space/demos/index.html.

Let me check the import map used in 062 to match Three.js version/imports.

Same stack as expected: three@0.160.0 + EffectComposer/UnrealBloomPass/OutputPass.

Now I'll write the Cinderforge demo. This is a big file (~1400 lines). I'll write it in /tmp via a heredoc to avoid JSON escaping issues, then copy. Writing via cat > file <<'EOF' in execute_shell_command is reliable.

Let me carefully compose the entire demo now. I'll be methodical. I'll write in one heredoc — but it's huge; maybe split into 2-3 parts appended. Part sizes ~ manageable per command (the tool should handle large commands, but let's split into 3 chunks for safety: head+css+html+js start; middle; end).

Plan the full code now, carefully.

=== SECTION A: HTML + CSS + DOM + imports + helpers + audio === === SECTION B: world build (terrain, canvas textures, props, lava, sky, ember particles, walkways) === === SECTION C: hammer assembly + simulation + post + input + loop + keys + resize ===

Let me write the actual code.

Key globals: scene, camera, renderer, controls, composer, bloomPass, gradePass; clock; groups: hammerRig (position), swingPivot (rotation.x), hammer parts; sim: {running, timeLeft, cycleT, phase, w1..w4, omega, theta, prevTheta, fired, cycleCount, connectedOnce}; audio ctx, master, musicGain, sfx; state for ambience.

I'll now write out the code in full, keeping careful track of syntax. I must double check every function closes. I'll aim for correctness over extreme length; target ~1300 lines total.

Details to nail:

1. Terrain heightfield: grid 220x220 over 170 size. h(x,z): radial crater profile + fbm noise. Implement fbm with value noise using hash of integer lattice (deterministic).

2. Canvas textures:

• makeLavaCrackTexture(): 1024 canvas: fill dark basalt (#151011 with noise), draw ~90 glowing crack segments: random walk polylines with gradient stroke, multiple widths; also some ember speckles. Return {map: CanvasTexture(color), emissive: same canvas? } Use same texture for map and emissiveMap with emissive color orange on standard material. Cracks should read in albedo too (bright orange). Good.
• makeGlowSprite(): radial gradient white→transparent.
• makeRuneTexture(glyph): 256 canvas, dark stone, glowing rune glyph in center using bold font, plus faint circle ring.

3. Sky: big sphere (r 380) BackSide shader: gradient horizon ember glow + stars hash + smoke band + subtle flicker uniform uTime.

4. Lava: shader disc r=11 at y=0.02 with fbm flow; rim rocks ring.

5. Ember/dust particle systems: BufferGeometry with attributes: seed, size; shader points with time-based drift using curl-ish sin fields; embers orange rising from lava; dust soft motes floating everywhere; sparks: dynamic buffer with pos/life/vel arrays (N=600), updated CPU, drawn as Points with additive; per-point attributes updated each frame (position + aLife).

6. Props:

• Anvil: build from boxes+cylinders merged... simple: group of 4 meshes with metal material, put on stone base.
• Bellows: wooden wedge + leather bag (squashed sphere) that pumps (scale anim) during charge.
• Quench trough: box with water shader? simple translucent plane with moving opacity; steam particles occasionally.
• Weapon rack: frame + 6 swords (simple extruded boxes with emissive edge?) leaning.
• Stone pillars x4 with rune planes (emissive map rune texture).
• Lava channels: 4 thin emissive strips from pit outward.
• Banners: 2 planes with simple cloth shader sway.
• Coals: instanced dodecahedrons 40 scattered with emissive variation.

7. Hammer assembly:

• rigGroup at (0, beamY=8.6, 0): contains swingPivot; pivot at origin; head group at (0, -L, 0) where L=7.4; hammer head: big box (2.6w,1.6h,1.8d) metal with emissive face plates + strap details; chain: from pivot up to beam (static cylinders) and visible pivot axle; beam above with supports to ground (two A-frame wooden trestles).
• Face emissive intensity driven by heat.

8. Ghost trails: 14 semi-transparent head meshes (box geometry only) recorded during strike.

9. Post: composer with bloom 0.75, grade ShaderPass (uniforms: tDiffuse, uTime, uShock, uVig, uHeat). Heat shimmer: offset uv by noise * uHeat near bottom-center; shock: radial zoom chroma.

10. Audio:

• ensureCtx on first pointerdown/keydown.
• Master gain 0.8 → compressor → destination.
• Reverb: convolver with generated IR (2.2s decaying noise), wet gain.
• Music: startMusic(): pad oscillators (2 detuned saws + lowpass 300Hz) drone at E1 41.2Hz & B1... slow filter LFO; plus slow minor-pentatonic plucks every ~4s scheduled with setInterval using audio clock; plus low heartbeat drum every 2s? Keep: drone + plucks + wind noise (looped buffer through bandpass 400Hz, gain 0.05, LFO).
• SFX: whoosh(dur,intensity): noise buffer source → bandpass freq ramp 300→1200 → gain envelope; impact(strength): layered: sub sine 55Hz pitch drop, noise burst lowpass 200Hz, metallic "clang" (3 inharmonic partials 720, 1240, 1970Hz short decays), plus debris ticks; chainRattle; tick(): short filtered noise 8ms every beat when running; chargeHum(t01): rising filtered saw quiet.
• Sounds routed: sfxGain → master + reverb send.

11. Simulation & phases:

• cycleT: beats 4.4 @126bpm → 0.4762s/beat; cycle = 2.095s. Actually total cycle 4.4 beats; phases: charge [0,0.42], strike [0.42,0.50], dwell/recover [0.50,1.0].
• theta(t): charge: from theta0 (0.52) to thetaMax (1.95) with easeInOutCubic + slight overshoot wobble; strike: freefall physics integrated at 240Hz from thetaMax with omega0=0: during ~0.09s falls to 0; compute exact substeps; impact when theta<=0. dwell: recoil bounce: omega after impact = -eomegaImpact0.35 handled in physics; then recovery ease back to theta0 during [0.6,1.0] with damped spring.
• Simplify robustly: I'll integrate physics (pendulum) for the whole cycle except during charge & recovery where I kinematically drive theta with a strong "motor" spring toward target: a critically damped spring toward target angle gives mechanical feel with natural wobble: motor: alpha = k*(target-theta) - c*omega, k=40 during charge/recover, during strike k=0 (gravity only) + optional boost torque (steam thrust) first 40ms. Impact detection: prevTheta>0 && theta<=0 → impact event. This unified spring-pendulum is elegant and stable. Integrate at fixed 240Hz substeps.
• Pendulum equation: alpha = -(g/L)sin(theta) + motorTorque + thrust. g/L with L=7.4: use g_eff scaled: choose g=9.8, L=7.4 → natural period ~5.4s too slow for fall from 1.95 rad... fall time from 1.95 rad with gravity only ≈ quarter period ≈ 1.36s — too slow for 0.1s strike. Real forging hammers use steam power to slam faster than gravity. So add strong thrust torque during strike: thrust = A with A s.t. fall takes ~0.1s: angular accel needed ≈ 21.95/0.1² ≈ 390 rad/s². That's huge but fine — visually fast slam. Use thrust 260 + gravity for first 60% of fall, giving ~0.11s strike. Impact omega ≈ sqrt(2alphatheta) ≈ sqrt(23001.95) ≈ 34 rad/s → tip speed 34*7.4 ≈ 250 u/s — bloom flash scaled by omega². Good.
• During charge: k=26, c=8 toward 1.95 (rise in 0.85s with slight lag). During recover: k=18, c=7 toward 0.52.
• Beat clock: cycleTime accumulates only when running; phase boundaries from fractions; at phase transitions trigger events (whoosh at strike start, tick sounds at each beat boundary, bellows pump during charge, hum).
• Impact event: sparks burst (emit 60-140), shockring scale anim, bloom flash uniform decay, camera impulse shake (decaying noise), anvil bounce (scale y), heat +0.25, metal glow pulse on head face, quench steam? no — sparks + ring. Also floating damage-like number? Skip. Increment STRIKES counter. Occasionally (every 8 strikes) play choir stinger? nice touch: every 8th strike → deep bell + pad swell.
• Ghost trail: during strike phase, every frame push current head world transform to ghost array; render ghost boxes with opacity ramp.

12. Camera shake: offset vector = noise * trauma², trauma decays 1.2/s; applied to camera after controls.update. OrbitControls: target (0,3.2,0), autoRotate slow when idle (no pointer for 6s), damping.

13. HUD: title "CINDERFORGE", subtitle "STEAM HAMMER Nº7"; stats: BPM, PHASE, STRIKES, HEAT %, PS-GHOSTS? Keep 4: TEMPO, PHASE, STRIKES, FACE TEMP. Buttons: START/STOP (or BIG START overlay), SOUND, TRAILS, SNAP. Bottom hint. Toast. Touch big button.

14. Overlays: intro overlay with title + "ENTER THE FORGE" button (starts audio+machine); hidden after. This solves autoplay policy elegantly.

15. Quality tiers: pixelRatio min(dpr, 2) high; if avg frame >22ms for 120 frames → step down (pixelRatio 1.5 → 1.25 → 1; bloom off at lowest).

16. Snapshot: render then toBlob download 'cinderforge.png'.

17. Resize handler.

18. Idle attract: machine auto-runs after entering? Task demos usually run automatically. I'll auto-start simulation on entering; user can stop. Also a "demo mode" toggle? Keep START/STOP.

19. TEMPO control: click BPM stat cycles 100/126/144? Add +/- via keys [ ]. Buttons row add "TEMPO". Simpler: key [ ] adjusts, HUD shows. Also add tempo button cycling. I'll do keys only + display.

Also KEY shortcuts listing in hint: SPACE run · M sound · T trails · [ ] tempo · S snap · R reforge? "Reforge" re-randomizes seed for terrain/props? That's heavy; skip R. Add F: flurry (temporary +40% tempo for 8s) fun. Maybe skip. Keep keys: SPACE, M, T, S, [ ].

Phase names: CHARGE / STRIKE / RECOIL / RESET (from fraction).

Face temp: heat 0..1 rises on impact (+0.22), decays 0.06/s; displayed as °C approx 900+heat*500.

Now the hammer head glow: emissiveMap none — use emissive color lerp from #1a0c06 to #ff5a1a * intensity, plus point light at face (orange, intensity heat*60, distance 20) + main fire light flickering from lava.

Lighting: ambient dim blue, hemisphere (sky #2a1b3d, ground #1a0f0a, 0.5), directional moonlight (slate blue 0.35, casts shadow 2048), lava point light (orange, flicker), face point light, anvil rim point (cool teal small for contrast? keep subtle).

Shadows: renderer.shadowMap enabled, PCFSoft; hammer head + beam cast; terrain receive.

Post chain renderTarget type HalfFloat for bloom quality.

Write the ShaderMaterial GLSL carefully:

Sky frag:

• vWorld dir; horizon glow: pow(1 - abs(dir.y), 3) warm; base gradient; stars: hash on floor(dir.xz/dir.y grid)? simpler: 3D hash stars: star = step(0.998, hash(floor(dir160))) twinkle sin; smoke band: fbm(dir.xz3 + time*0.01) * horizonness darkening. Use a simple hash21/noise GLSL.

Lava frag: uv → p = vUv8; flow: n = fbm(p + vec2(time0.05, -time0.03) + fbm(p1.7 - time*0.02)); color = mix(darkrock, orange, smoothstep(0.45,0.75,n)) + hot white veins smoothstep(0.72,0.8,n); brightness pulse global sin.

Ember points vertex: attribute seed; pos = base + drift(time, seed): rise = mod(seed7 + time(0.3+seed0.4), H) ; pos.y = rise; x/z = origin.x + sin(time0.7+seed20)(0.4+rise*0.15); size shrink with rise; alpha flicker. Pass vAlpha. Frag: radial soft falloff * color mix(orange→red by alpha).

Dust: similar but slow, bluish, no shrink.

Sparks (dynamic): attributes position (dynamic), aVel (CPU stored separately), aLife (0..1). CPU update: vel.y -= gdt; pos+=veldt; bounce on y<0.03 (vel.y*=-0.4, friction); life -= dt*decay. Frag: color hot white→orange by life; size by life.

Shock ring: shader or basic material with opacity anim; use RingGeometry with additive MeshBasicMaterial, scale up + fade. Also secondary "shockwave dome"? skip.

Banners shader: plane 1.2x2.4 segments 12x24, vertex wave sin(y3 - time2 + phase)amp(1-uv.y top pinned?) pinned at top: amplitude grows downward: use uv. Simple.

Ghost trails: InstancedMesh? simpler: 12 Mesh clones of box geo (2.7,1.7,1.9) with MeshBasicMaterial additive transparent opacity per index. Update: shift buffer of matrices every frame during strike phase (and 100ms after), each ghost i opacity = base*(1 - i/N)*strikeFlash; positions from recorded history ring buffer sampled with stride 2 frames.

Implementation: history array of last 40 {pos:Vector3, quat:Quaternion} recorded every frame; ghosts sample history[i*3] when strike active (strikeFlash>0), else opacity 0.

Chain links: TorusGeometry small repeated along from pivot to beam attach — rotate alternating 90°. ~8 links fine.

Beam & trestles: two A-frames: cylinders/boxes wood material; beam box across at y=8.6+x? pivot under beam center: pivot at (0, 8.6, 0)? Wait head at (0,-7.4) → head reaches y≈1.2 when theta=0 — good above anvil (anvil top y≈1.05 with base). Rest angle 0.52 → head pos x=sin(0.52)*7.4≈3.67, y=8.6-cos(0.52)7.4≈2.16. Charge 1.95 → x≈6.86, y≈8.6-7.4cos(1.95)=8.6+2.74=11.34 (above beam — cos negative). Hmm at 1.95 rad (112°) head goes above pivot height. Visually dramatic (raised high), fine, but chain from beam vertical would bend — the arm is rigid (it's a rocking beam hammer? For visual simplicity make it a pendulum arm: rigid arm from pivot to head (box beam segment). Chain connects arm tip top to a counterweight? Simplify: rigid arm + pivot axle + no chain (steam hammer with rocking lever). Actually classic "steam hammer" = vertical; "pendulum/helve hammer" = arm pivots, raised by cam, falls — helve hammer! Great: it's a helve hammer (medieval trip hammer) powered by steam crank. Add a flywheel + connecting rod visual that rotates during charge (cosmetic crank). I'll add: flywheel disc at side rotating with phase during charge, pushrod to arm (approximate attachment, cosmetic). To avoid complex IK, rod connects two points each frame: cylinder scaled/oriented between crank pin world pos and arm mid pos — doable: function setRod(cyl, a, b). Nice mechanical touch, sells "steam".

Pivot axle supported by two trestle frames at z=±1.4. Arm = long box (0.5,0.5,7.8?) positioned from pivot to head: arm group inside swingPivot: arm mesh centered at (0,-3.7,0) size (0.55,7.6,0.7); head at (0,-7.4,0). Counterweight small box at (0,+1.2,0).

Anvil positioned at (0,0,0)? head at theta=0 is at (0, 8.6-7.4=1.2, 0). So anvil top at y≈1.15, centered (0,0,0) → head face (head height 1.6 → bottom at 1.2-0.8=0.4)... face should meet anvil top: set head center y at impact = 1.2+0.8 = 2.0? Let me recompute: pivot y 8.6, L=7.4 → head center at y=1.2. Head box height 1.6 → bottom face y=0.4. Anvil top should be ~0.4: anvil total height 0.4 (base stone 0.25 + anvil 0.9?) hmm too low. Instead raise anvil on a stone plinth: plinth h 0.5, anvil h ~1.0 → top 1.5. Then set pivot so head bottom meets 1.5: head center = 1.5+0.8=2.3 → pivot y = 2.3+7.4 = 9.7. Beam at 9.9. OK: pivotY=9.7, anvil top 1.5 (plinth 0.55 + anvil ~0.95). Ground y=0. Good numbers.

Head glow face plate: thin box at bottom of head (2.4,0.18,1.6) emissive driven.

Sparks emit from (0,1.55,0) random disk directions.

Terrain avoid center: flatten radius 14 (forge floor), crater ring rises at 26-48, fbm detail. Forge floor: circular stone tiles? Use cracked-lava texture on a big circle mesh (radius 15, 64 seg) slightly above terrain y=0.01. Outside terrain standard dark rock material with noise via vertexColors? Keep: terrain MeshStandardMaterial color #211a17, roughness 1, with vertex color darkening by height. Vertex colors compute in JS. Good.

Lava pool separate: place off-center? The pit in front-right: center (10.5, 0, 6.5) r=5? But flatten area r14 covers forge floor; put pool within floor: circular shader disc r=4.2 at (9.5,0.02,5.5), ring of rocks (instanced dodecas). Channels: 3 thin planes from pool edge outward with same lava shader stretched UV — simpler: emissive strips (MeshBasicMaterial orange with slight noise via lavaCrack texture). OK.

Props layout: bellows at (-6.5, 0, 3.5) behind-left; quench trough (-4.5,0,-5); weapon rack (6.8,0,-6.5); pillars at r=13 four diagonals; banners on two pillars.

Now WRITE it. I'll write the file in /tmp/cinderforge.html via heredoc in 3 append chunks. Then node --check? Node can't check ES module with bare imports? node --check does syntax check only — works for ESM if file has .mjs or use --input-type=module? node --check on .html won't work. Extract script to /tmp/check.mjs and run node --check — node supports --check for CommonJS; for ESM need node --check --input-type=module < file? Actually node --check file.mjs works for ESM syntax. Imports of 'three' won't resolve but --check only parses.

Let me write chunk 1 (HTML/CSS/DOM/importmap/script start: helpers, audio). Keep lines clean.

Careful with heredoc: content contains $ (template literals?) — I'll avoid template literals mostly... they're fine inside single-quoted heredoc 'EOF' since no shell expansion. Backticks fine too. Just ensure no line is exactly EOF.

Let me draft the whole thing mentally then write.

I'll now write chunk 1.

*************************************************************************************************s).

*****************************************************************************************************************************ly.

**********************************************************************************************************************************************************************************************ts.

Part 5: beat bar UI, post-processing (composer + grade pass), HUD wiring, input/keys, quality scaling, snapshot, resize, main loop, boot. Careful: trailsOn is referenced in updateSim — define before use in module scope (it's used at runtime, so just define let trailsOn=true at top-level before the loop runs; order doesn't matter for runtime as long as it's initialized before first frame — but updateSim references it, and it's declared with let later in module → temporal dead zone error at first call if called before declaration. Since declaration executes before animation loop starts, fine — but must be declared in the same module scope before updateSim is invoked, which happens after full module eval. OK.

Also updateBeatBar referenced in updateSim — same reasoning, function declaration hoisting: if declared with function it's hoisted. I'll use function declaration.

Also note in part4, crank frame code is messy: I created frame box with weird position code lines:

That's ugly leftover but syntactically valid. Actually let me clean it in a fix pass after assembly. The crank group is at (0,5.6,3.1); post1/post2 at y=-2.8 with height 5.6 → spans from y=-5.6 to 0 relative → world y 0 to 5.6. Good. The frame box at position (-2.7,-2.8,0) height 5.6 → same as post1 duplicated — remove it later. Also flywheel axle2 at crank origin fine. The wheel rotates around z? TorusGeometry lies in XY plane facing +z — wheel at z=3.1 world offset facing camera-ish direction; rotating about z spins it in its plane. crankPin at (1.35,0,0.42) rotates with wheel — world position orbits radius 1.35. Rod from crankPin to rodTarget on arm — will animate. OK.

One issue: swing.rotation.z = sim.theta — positive theta rotates around +z axis: head at (0,-L,0) moves toward +x? Rotation around z by theta: point (0,-L) → (L sinθ, -L cosθ). Yes, swings toward +x. Rest at 0.46 → head offset x=+3.28. Strikes at theta=0 over anvil. Charge raises toward +x (flywheel side is +z... rod geometry won't perfectly align but cosmetic). Fine.

Also impact() is called inside integratePendulum which references trailsOn? No, updateSim does. OK.

Note: in updateSim → Audio8.chargeHum with Math.random()<0.3 each frame → many small blips; might be noisy at 60fps (0.3*60=18/sec). Reduce to 0.06. I'll patch later.

Beat bar: #beat container with segments — 8 segs? Use 8 segments (8th notes of 4 beats). updateBeatBar(beatFloat): light seg index floor(beatFloat*2)%8.

Also in updateSim, when not running, cycleT stays; ok.

Now part 5. Also trailsOn variable, quality manager, keys, snapshot, main loop with clock, fireLight flicker, HUD update, boot (loader hide after first render), enter button starts audio + hides intro, auto-run machine.

Grade shader: uniforms tDiffuse, uTime, uShock (0..1), uHeatGlow (heat vignette?), uVig. Frag: chromatic aberration radial * shock, vignette, grain, subtle warm tint, and "heat shimmer" — offset uv near bottom center by noise scaled with heat. Let me write it.

Camera shake: apply after controls.update: camera.position add random offset * trauma², camera.rotation small. Simplest: keep base position from controls; offset = (noise-0.5)trauma²0.35 per axis; also FOV punch? Keep offset.

Adaptive quality: track EMA of frame dt; thresholds at >21ms sustained → step down pixelRatio [2,1.5,1.25,1]; and at lowest disable bloom.

HUD update once per 0.1s.

Big touch button toggles run.

Keys: Space toggle run (preventDefault), M mute, T trails, S snap, [ ] tempo ±6 (clamp 90..168), R? skip. Enter dismisses intro too.

Enter overlay button: Audio8.ensure(); ctx.resume; hide overlay; start auto-rotate after idle.

Also idle auto-orbit: in loop, if performance.now()-lastInteract>8000 → controls.autoRotate=true else false (only after intro dismissed? always fine).

Resize: camera aspect, renderer size, composer size, bloom resolution.

Boot: hide loader after first frame rendered.

Write part5 now.

Now concatenate all parts into /tmp/cf/index.html, extract the module script, and run node --check for syntax. Also fix known issues:

1. In part4, messy frame leftover lines in crank block — clean up.

2. Audio8.chargeHum called with Math.random()<0.3 every frame → too often; reduce to 0.06.

3. Check that updateBeatBar is defined (function declaration in part5 — hoisted within module? Function declarations are hoisted across the whole module scope, so calling it in part4's updateSim at runtime is fine).

4. trailsOn is let declared in part5, but updateSim (part4) references it at runtime — updateSim is only called inside animate() which runs after the whole module evaluated → fine (no TDZ issue at call time).

5. In impact() — uses trailsOn? No. Good.

6. In part4 sim.flurry unused — harmless.

7. In part2 makeDriftPoints({... cols ...}) — cols param unused, fine.

8. beat bar: updateBeatBar(beatFloat) — beatFloat = cycleT/beatLen ranges 0..4.4 → floor(beatFloat*2)%8 → 0..8 → mod 8 fine.

9. Strike thrust: alpha += -Math.sign(sim.theta)*(fallFrac<0.85?300:40) — theta positive during fall; -sign → negative (accelerates toward 0). Good. But at theta exactly 0 sign=0 — impact triggers same substep anyway.

10. In charge phase motor: k=30 toward THETA_MAX=1.92 from 0.46 — rise time: omega ≈ sqrt(k*(dθ))... time constant sqrt(1/30)≈0.18s; reach in ~0.6-0.9s. Charge window = 0.44cycleLen = 0.442.095 ≈ 0.92s. OK, arrives near end with slight overshoot, damped c=7.5 (critical ≈ 2*sqrt(30)=10.9 → underdamped, small overshoot bounce — nice mechanical).

11. Strike window: u in [0.44, 0.54] → 0.102.095 = 0.21s. Fall from 1.92 with accel ~300: t=sqrt(21.92/300)=0.113s < 0.21. Good; impact occurs within strike phase.

12. After impact theta=0, omega set positive (recoil up), then during RECOIL phase (u 0.54..0.8) motor k=16 toward rest 0.46 — combines. Good.

13. sim.omega=Math.abs(sim.omega)*0.34 — omega negative before impact (falling), abs → positive → bounces upward. Good.

14. Sparks burst positions y: ANVIL_TOP+0.1=1.95. Good.

15. Ghost history: recorded every frame; during strike samples idx with stride 2 frames → 26 frames history ≈ 0.43s at 60fps. Strike lasts 0.11s (~7 frames) — only 3-4 ghosts trail; rest sample older charge positions — actually that's fine visually (trail arc).

16. In part3 anvil: box(...) default parent=world — I passed anvil only for some pieces via explicit anvil parent arg? Let me check: I wrote box(2.2,0.55,2.2,stoneMat,0,0.28,0); — no parent → world. Then const horn=cyl(...,anvil) parent anvil — but anvil group is at origin so coordinates match anyway. anvil.userData.workpiece=wp — wp added to anvil. fine.

17. In part3 pillars: world.userData['pillar'+i]=p and flames stored p.userData.flame=fl. loop in part5 reads them. Good.

18. Banner uses bmat shared for two banners — one material fine.

19. part2 lava: vPos = position of circle geometry rotated -PI/2: circle in XY plane originally, rotateX(-90°) → XZ plane; position.xz used in frag — after rotation baked into attribute, yes positions are in XZ with y≈0. vUv for edge fade: CircleGeometry uvs are radial mapping [0..1] — length(vUv-0.5)*2 → 0 at center, 1 at edge. Good.

20. Sky shader: gl_Position.z=gl_Position.w pushes to far plane — with depthWrite false and drawn... it's added to scene; rendered in order with others; depthTest still on (default), z=w → depth 1.0 → passes only where nothing drawn... with depthTest true and depth 1.0 (far), fragments behind everything. Terrain closer → sky fails depth where terrain exists. Good. But fog:false set. OK.

21. poof SpriteMaterial with color 0x8a6a50 and glowTex — fine.

22. gradePass.uniforms.uShock.value=Math.max(0, ...*0.86 + trauma*0.14 - 0.02) — decays. OK.

23. Snapshot: composer.render() then toBlob — WebGL canvas without preserveDrawingBuffer: toBlob right after synchronous render in same task works. Good.

24. Part1: intro overlay covers screen until ENTER; loader hides after first frame (animate starts immediately — canvas renders behind intro; fine).

25. enterWorld triggered by Enter key too. Space also calls enterWorld. Good.

26. On mobile: big-go visible; pointerdown resume audio. ENTER button unlocks audio.

27. Part4 bug: in crank block:

Remove frame entirely (posts already exist). I'll patch.

28. const post1=cyl(0.16,0.2,5.6,woodMat,-2.2,-2.8,0,10,crank); post1.rotation.z=0.18; — rotation makes bottom/top offset; roughly fine.

29. Part4: const axle2=cyl(0.14,0.14,1.2,ironMat,0,0,0,10,crank); axle2.rotation.x=Math.PI/2; — crank group at (0,5.6,3.1), wheel at crank origin → axle through wheel center facing z? rotation.x=PI/2 turns y-axis cylinder to z-axis. Good.

30. flywheel.rotation.z=-sim.wheelAngle — wheel is child group of crank; torus in XY plane; rotating about z spins. crankPin child of wheel at (1.35,0,0.42) → orbits. Good.

31. rodTarget added to swing at (0,0.9,0) — above pivot, world position moves with swing. aimRod handles. Rod length scale y — cylinder base height 1 scaled to len. Good.

32. Part2: makeCrackTexture uses srand with _seed module-level — deterministic-ish. crack function recursively spawns branches — fine.

33. Terrain: PlaneGeometry(SIZE,SIZE,SEG,SEG) → 151x151=22801 verts — fine.

34. Embers rise: base pos.x includes 9.5*0.6 offset — spreads embers around pool-ish area and center... area 7 radius around (5.7, 3.3). Hmm mixing; acceptable: embers concentrated near lava + forge floor. Fine.

35. Points shader for embers uses template literal ${(hMax-hMin).toFixed(1)} etc. — inside makeDriftPoints; heredoc quoted so no shell interpolation. JS template literal inside ShaderMaterial string concatenated via ${rise?...:...} — nested backticks: the vertexShader is itself a template literal containing nested template literals in ${} expressions — that's legal JS.

36. Careful: in embers vertexShader string I reference span, yy, life declared inside main with conditional code — for rise=false branch, vA/vCol set differently; but gl_PointSize line references (0.6+0.4*(1.0-life)) for rise — for dust uses '1.0' string. Since interpolation of ${rise?'(0.6+0.4*(1.0-life))':'1.0'} — for rise case life defined. OK.

37. Dust size 9 → gl_PointSize = aSize*(180/-mv.z)1.0. At distance ~20, 99=81px? 180/20=9 → 81px — too big for dust. Hmm aSize=9*(0.5..1.5)=4.5..13.5; at mv.z -20: size=13.59≈120px. Way too big. Embers: size 26 → worse. Wait — these units: gl_PointSize in pixels; (180/-mv.z) at 20 units → 9×. So ember 26 → 234px huge. Too big! I intended world-size scaling: for a point of world radius ~0.06 at distance 20 with viewport 1080: px ≈ 0.061080/(2*tan(26°)*20) ≈ 3.3px. So factor should be aSize meaning world size *~ (screenH/2)/ (tan(fov/2)dist) = 540/(0.4877dist) ≈ 1107/dist for fov 52. So use multiplier ~ (1100/-mv.z) with aSize in world units ~0.03-0.08. Let me instead set size params in world units: embers 0.05..0.09, dust 0.03, and use factor 1100. Sparks similar: aSize 10-36 px → change to world 0.05-0.12 with factor 1100... spark vertexShader uses (140.0/-mv.z)aSize — aSize 10-36 → at 20 units: 107=70px. Too big too.

Fix:

• embers: size param 0.055 world, multiplier 1050 → at 15 units: 0.055*70=3.9px... times (0.6..1) & random 0.5-1.5 → 2-6px. Good.
• dust: 0.035 world, mult 1050 → ~2.4px at 15.
• sparks: aSize world 0.05-0.16, mult 1050, also shrink by life. At 10 units: 0.16*105=16px nice.

I'll patch via replace after concat.

38. spark.update bounce y<0.06 → but anvil region: sparks spawn at y=1.95 and fall onto floor plane y≈0 — they'll pass through anvil; acceptable.

39. adaptQuality uses dtMs=performance.now() at frame start then computes elapsed at end — includes render time. Good.

40. HUD el.heat.textContent=Math.round(880+sim.heat*620) — heat 0.08..1 → 930..1500°C. initial HTML 912 fine.

41. sim.heat decays 0.05/s from 0.25... impact adds 0.24. Equilibrium at ~2 strikes/s? Cycle 2.1s → 0.48 strikes/s → input 0.115/s vs decay 0.05heat... heat0.05 at 1 = 0.05 <0.115 → heat saturates at 1. OK — face glows hotter over time, nice.

42. intro z-40 above canvas; loader z-50 hides after first frame; fine.

43. moon shadow camera bounds ±26 covers forge floor. Good.

44. Part5 keys: 'enter' → e.key 'Enter' lowercased 'enter'. Good.

45. In part1 CSS #beat .seg uses fixed widths; container 120px. OK.

46. In part2, channel strips: const mat=new THREE.MeshBasicMaterial(...) created but unused (emat used). Remove mentally — harmless but let me clean.

Also part2 makeDriftPoints cols param unused — fine.

47. Potential issue: crackTex.clone() in part2 unused mat — remove those two lines.

48. Part4: in updateSim, when !sim.running, swing eases to rest; ghosts hidden since strikeActive requires running. good.

49. Audio8.startMusic pluck uses this._pluckTimer — when ctx closes whatever. fine.

50. One more: part4 updateSim calls updateBeatBar(beatFloat) — hoisted function declaration in part5 → available. Good.

51. part4 references trailsOn (let, part5). At module evaluation, updateSim isn't called until animate() at end of part5 — after let trailsOn=true executed. Good.

52. sim.beatIdx initial -1; when not running beats don't fire. fine.

53. impact() may fire multiple times in consecutive substeps if theta pinned at 0 with positive omega? After impact theta=0, omega set positive → next substep theta increases — no double trigger. During strike phase thrust continues while theta>0 — after bounce theta small positive with fallFrac≈1 → thrust 40 downward; recovery motor also active? inStrike checks u range; once past STRIKE_END, recovery motor pulls to rest. During remaining strike window after bounce, thrust 40 pushes down → possible second impact (smaller). Acceptable (double-tap happens in real helve hammers). Impact strength min 0.5 → second tap sound lighter... str clamp(omega/34, 0.5, 1.3): min 0.5 regardless. Meh, fine.

54. Moon directional light shadows: hammer head at y up to ~12 — shadow camera bounds ±26 fine, far 90 from position (-26,38,-14) — distance to scene ~50 — ok.

55. renderer.setPixelRatio then onResize() — composer sizes. Good.

Now concat and patch fixes: A. Remove frame lines in part4. B. chargeHum probability 0.3 → 0.05. C. Ember/dust/spark point sizes → world units with 1050 factor. D. Remove unused mat lines in lava channels.

Then extract content → node --check as .mjs.

Note: node --check parses; import statements fine in .mjs check.

Syntax OK. Now let me do a careful logic review of critical parts by reading the assembled file around the sim/hammer sections. Let me re-check a few runtime concerns:

1. impact() is called inside integratePendulum — references trailsOn? No. OK.
2. In part4, ghosts index: (histHead-1-(i+1)*2 + HIST_N*4)%HIST_N — HIST_N*4=192 ensures positive. OK.
3. part2: crackTex.repeat.set(3,3) set on original texture used for floor — but crackTex is also used for the lava-channel emat (shares same repeat 3,3 — fine) and floor mat map & emissiveMap same texture. OK.
4. Sky material fog:false — ShaderMaterial accepts fog param. OK.
5. Circle geometry floor at y=0.02 with polygonOffset? Terrain at center is at h≈-0.4..0? Let me check terrainH at center: r<10 → ring=smooth(15,44,r)=0 → h=0*wall... wait: let h=ring*wall — ring 0 → h=0; detail terms multiplied by ring → 0; -smooth(14,10,r)*0.4: smooth(14,10,r) — my smooth(a,b,t) with a=14,b=10: (t-14)/(10-14) → for r=0: (0-14)/(-4)=3.5 → clamped 1 → h=-0.4 at center. So terrain center is at -0.4, and forge floor disc at y=0.02 floats 0.42 above terrain near center?? At r=14: smooth(14,10,14)=0 → h=0. Hmm the disc radius 16 at y=0.02 vs terrain going from -0.4 (center) to 0 (r=14) — the disc would float visibly at the edge? At r=14-16 terrain h=0 (ring still 0 until r>15... at r=16, ring=smooth(15,44,16)=tiny≈0.001 → h≈0). So terrain is at -0.4 in the middle rising to 0 at r=14 — the disc at 0.02 floats above the dished terrain by up to 0.42 at center. The disc is opaque; terrain below hidden under disc from above views, but from a low grazing angle you could see a gap at the rim? The rim torus (r=16.1, tube 0.5, at y=0.05) hides the outer edge. The bowl effect: anvil plinth sits at y=0 (box centered 0.28 → base at 0.005) → above terrain -0.4, i.e., floating 0.4 above ground visually? No—the floor DISC at 0.02 covers the center; props sit on the disc. Terrain beneath is invisible under the disc (disc radius 16 > bowl region 14). Grazing angles: fog + rim + darkness hide the 0.4 gap at r<14. Actually the disc edge at r=16 sits at y=0.02 vs terrain at h≈0 — gap of 0.02. Fine. The only visible oddity: props near center look planted on the disc — correct. OK.

But wait: props OUTSIDE disc r>16 (pillars at 13.2 → on disc, fine; bellows at (-6.8,3.6) r≈7.7 on disc; trough r≈7; rack r≈9.8; crank at z=3.1 r=3.1 — all on disc. Lava pool at (9.5,5.5) r≈11 — on disc. Good. The disc y=0.02 vs pool y=0.06, channels 0.04. OK.

6. The pool rocks instanced at y=0.15 fine.

7. smooth JS: my smooth(a,b,t) handles a>b case as shown. Good.

8. camera.rotation.z += ... after controls.update — OrbitControls sets camera orientation each update, so adding rotation.z post-update persists only for this frame render; next frame controls resets it — good (no accumulation).

9. camOffset added to camera.position post-controls → also reset next frame. Good.

10. Beat ticks use Audio8.tick — only if ctx exists (guarded by if(!this.ctx) return). Good.

11. updateBeatBar: Math.floor(beatFloat*2)%8 beatFloat up to 4.4 → floor up to 8 → %8 → 0. Beat 4.0 (strike) → idx 8%8=0 → bar segment lights at strike — actually nice: strike lands on the bar accent. Wait: strike starts at u=0.44 → beatFloat = 0.444.4=1.936 → idx=floor(3.872)=3. Impact ≈ u≈0.494 → beatFloat≈2.17 → idx 4. Hmm impact lands on idx 4 = bar accent seg (i%4===0 → 0 and 4). seg 4 has 'bar' class. So impact lights the accented 5th segment — feels intentional: strike on the "and" after beat 2... At 126bpm, beats at 0,0.48,0.95,1.43,1.90s; impact at 0.4942.095=1.035s — just after beat 3 (0.95s). Off-grid but consistent. Eh — "rhythm-synced" claim: charge starts at cycle start (beat 1), impact consistently at ~1.03s ≈ beat 3 + 6.5 sixteenths... roughly on the 3rd beat's "and". Consistent groove; the beat bar makes it readable. Fine. Actually, let me nudge so impact lands closer to a beat: strike thrust higher → shorter fall. Fall time sqrt(21.92/300)=0.113s; strike starts at 0.92s; impact ≈1.04s. Beat 3 at 0.952s, beat 4 at 1.43s. To land on beat 4 (1.43s), strike would start later (u 0.44→0.61?) then recover window shrinks. Alternatively tune thrust 380 → fall 0.10. Or shift: make impact land near beat 3 (0.952s): fall should take 0.03s — too violent. It's fine — groove lands on the "and of 2" consistently like a swing anvil hit. Actually simplest polish: cycles 4.4 beats means cycle boundaries drift relative to a 4-beat bar... The tick accents assume 8ths within the cycle only. It's a 4.4-beat cycle → musical poly-rhythm weirdness. Change beatsPerCycle to 4.5? Still fractional. Make it exactly 4 beats: cycleLen=4beatLen=1.905s; phases: CHARGE_END 0.48, STRIKE_END 0.58 → charge 0.914s, strike window 0.19s, impact at 0.914+0.113≈1.03s = u 0.54 ≈ beatFloat 2.16 → "and of 3"? beats at 0,0.476,0.952,1.428. Impact 1.03s ≈ just after beat 3 (0.952) +78ms. Hmm. To land impact ON beat 3 (0.952s): charge 0.48*1.905=0.914 → fall needs 0.038s — impossible. Land on beat 4 (1.428s): strike start at 1.315s = u 0.69 — then recovery only 0.31·1.905·? too short.

Alternative: make beatsPerCycle 5.0 and CHARGE_END 0.5: cycle=2.38s; charge ends at 1.19s; impact ≈1.30s; beat 3 at 0.952·? beatLen 0.476: beats at 0,.476,.952,1.428,1.904. Impact 1.30 between. Meh.

Honestly: exact beat alignment isn't critical — it's a machine with its own groove; tick sounds + beat bar synced to the cycle make it feel musical. I'll set beatsPerCycle to 4 and accept impact on the "and". Hmm, but the tick accents: isBar = beatIdx%4 where beatIdx=floor(beatFloat*2)/2 increments per eighth. With 4.0 beats/cycle, cycle aligns with 4-beat bars → consistent. Let me change beatsPerCycle to 4.0 and adjust: CHARGE_END 0.46 (charge 0.876s), STRIKE_END 0.57 (strike window 0.21s). Impact ~0.876+0.113=0.99s → beatFloat 2.08 → right after beat 3 (0.952s) — "the hammer hits just after beat 3, every bar" — a proper groove.

Also beat bar segments: 8 segs = 4 beats of 8ths — with 4.0 beats/cycle now maps perfectly: idx=floor(beatFloat*2)%8. Impact at beatFloat 2.08 → idx 4 → accented seg lights at impact.

12. Also update PH.CHARGE_END:0.46, STRIKE_END:0.57.

13. sim.beatsPerCycle:4.4 → 4.0.

Let me apply these. Also reconsider charge motor reaching 1.92 within 0.876s — k=30,c=7.5 from 0.46: settle time ~4/(c/2)=... underdamped; simulate mentally: should arrive ~0.7s with overshoot wobble. OK.

14. Recovery: from post-bounce theta≈0.6·? motor k=16 c=6 to rest 0.46 over remaining u window (0.57→1.0 = 0.82s) — enough.

15. One more possible visual bug: the arm box(0.62,L_ARM+1.6,0.8,...) then arm.position.y=-(L_ARM+1.6)/2+1.2 — box was created at position (0, -(L_ARM-1.2)/2? I passed y=-(L_ARM-1.2)/2 in the box() call... Let me reread part4:

box() sets position from args: y=-(7.4-1.2)/2=-3.1; then overridden to -(9.0)/2+1.2=-3.3. Arm length 9.0 centered at -3.3 → spans -7.8..+1.2. Head at -7.4 → arm covers head attach; counterweight at +1.15 overlaps arm top. Pivot at 0 within arm. Good.

16. box() for head: const head=box(2.6,HEAD_H,1.8,ironMat,0,0,0,0,headGroup); variable head unused — fine.

17. Iron bands at yy -1.4,-3.4,-5.4 on arm — band size 0.74x0.22x0.92 vs arm 0.62x...x0.8 → bands protrude. Good.

18. Rod from crankPin (world z≈3.5) to rodTarget on swing (z≈0) — diagonal rod; cylinder aims correctly via quaternion. Good.

19. Spark pos[i*3+1]=-100 initial — below terrain, invisible (life 0 → discarded in shader). good.

20. anvil.userData.workpiece — assigned in part3 block via anvil.userData.workpiece=wp. Then part4 workpieceGlow=anvil.userData.workpiece — assigned at module eval of part4, after part3 executed. Good.

21. HUD heat color class 'hot' static — fine.

22. el.sound.classList.toggle('on',!m) — initial not muted → button not 'on' initially though sound... starts only after entering. It's fine.

23. On entering, sound button should indicate on: in enterWorld add el.sound.classList.add('on'). Minor; add in patch.

24. Also intro Enter button: after clicking, machine is already running (sim.running true default). Good — demo starts forging immediately.

25. #beat segs: initial heights; 'bar' class outline. ok.

Apply patches now: beatsPerCycle 4.0, PH values, sound button 'on' on enter.

Then final read-through of assembled regions to verify no obvious runtime errors (undefined vars). Let me grep for a few identifiers.

Syntax OK. Now let me do a deeper static review of the assembled file for runtime issues. Key risk areas:

1. GLSL shaders compile — can't easily test without a GL context. Let me at least review shader strings carefully by reading them from the file.
2. Undefined variables / order issues — let me read the assembled file sections quickly.

Let me view the parts around the shaders and sim.

Anvil top block: box(2.1,0.42,0.85, ironMat, 0, 1.5, 0) → center y=1.5, height 0.42 → top at 1.71. Workpiece at y=1.78 with height 0.14 → top at 1.85 = ANVIL_TOP. PIVOT_Y=1.85+0.8+7.4=10.05. Head bottom face at theta=0: head center y = PIVOT_Y - L_ARM = 2.65; bottom face = 2.65 - 0.8 = 1.85. Face plate extends -0.06 → 1.79 ≈ touches workpiece top 1.85? Face plate bottom at 1.79 — slightly intersecting workpiece (1.78±0.07 → 1.71..1.85). Face plate top... plate center y at head bottom -0.06: plate spans 1.79..1.95. Workpiece top 1.85 — slight intersection of 0.06 — visually "contact". Perfect.

One issue: const wp=...; wp.position.set(-0.1,1.78,0); anvil.add(wp); — but other anvil parts were added to world not anvil group (box() default parent=world, no parent arg given for plinth/foot/waist/top!). Since anvil group is at origin, visually identical. But anvil.add(wp) — anvil at (0,0,0) → same. Fine.

Horn: cyl(0.02,0.30,1.1,ironMat,1.5,1.5,0,12,anvil) rotated z=-PI/2 → points along +x. Good.

Note: anvil scale bounce on impact — I mentioned but didn't implement. Skip, fine (shock ring + sparks + shake is plenty).

Sky shader smoke smooth(...) — wait, GLSL: I used smooth(0.0,0.4,d.y) — GLSL has no smooth builtin; it's smoothstep! Let me check: in sky frag I wrote sm*0.35*smooth(0.0,0.4,d.y) and st*tw*smooth(0.05,0.35,d.y)*0.8. Those should be smoothstep. BUG — would fail shader compile. Also in lava frag I used smoothstep correctly. Let me check other shaders: drift points vertex uses JS-side ${} and GLSL smoothstep in frag — check; sparks frag smoothstep; grade pass uses smooth(0.42,0.95,r) — BUG there too! I wrote col*=1.0-smooth(0.42,0.95,r)*0.55; — must be smoothstep. Let me grep for smooth( in shader strings and fix to smoothstep. Careful not to touch JS smooth() function.

Occurrences to fix:

• sky: sm*0.35*smooth(0.0,0.4,d.y) → smoothstep
• sky: smooth(0.05,0.35,d.y) → smoothstep
• grade: smooth(0.42,0.95,r) → smoothstep

Check part2 lava: used smoothstep — yes (smoothstep(0.30,0.55,n) etc.).

Also water shader: none.

Drift vertex: none.

Banner: none.

Grep to be sure.

**********************************************************************************ne.

*******************************************************************************************************************************************************6).

One issue: aLife attribute: I set BufferAttribute from this.life — but then in update I write normalized values into this.geo.attributes.aLife.array — which IS this.life (same Float32Array reference!). That means writing normalized life into the array corrupts the actual life countdown (life gets overwritten with normalized value, then next frame this.life[i]-=dt decrements the normalized value — actually that changes decay semantics: life becomes normalized and decremented by dt each frame... Let me trace: burst sets life[i]=maxLife (e.g., 0.9). update: life[i] -= dt → 0.88. Then normalization writes l[i]=life/maxLife into the SAME array → life[i]=0.98. Next frame: life -= dt → 0.96, write 0.96/0.9>1 clamped 1.0... Actually clamp(0.96/0.9)=1. So life becomes ~1.0 decreasing by dt each frame — meaning spark lasts ~1s instead of 0.9 and, worse, maxLife stays 0.9 so normalized = (life-…)/0.9 clamped — decay rate wrong and bounce logic still works. Net effect: sparks live slightly longer, decay linear from 1.0 at dt rate. Not broken visually, but sloppy. Better: separate lifeN array for the attribute. Fix: create lifeN: new Float32Array(SPARK_N) and use it in the attribute; in update write into lifeN.

Also sp.rotation.z=i/6*Math.PI*2 for spokes: box geometry height 1.9 along y, rotating about z — spokes radial in wheel XY plane. But wheel's rim is TorusGeometry in XY plane — spokes rotation.z correct.

Also legL/legR: height PIVOT_Y+0.9≈10.95 centered at half → spans 0..10.95; rotated z ±0.12 → tilt. Good A-frame look.

crankPin world position: wheel at crank (0,5.6,3.1) + pin orbit radius 1.35. rodTarget on swing at (0,0.9,0) → world ≈ (0, PIVOT_Y+0.9·cos.., ~0) — rod from z=3.5 to z≈0 diagonal. Length varies 3-4. OK.

Fix the aLife array aliasing now.

*****************************************************************************6).

Issues spotted:

1. impact() during recovery phase re-triggering: During RECOIL/RESET, motor drives toward THETA_REST=0.46 (positive), so theta stays positive — no spurious impacts. During the end of strike phase after bounce, theta small positive, thrust 40 (fallFrac≥0.85 → 40·sign) pushes down; possible small double impact — acceptable (helve hammers double-tap), sound strength min 0.5 though... A double impact with strength 0.5 every cycle would be loud/repetitive. Let me prevent: add cooldown — impact only if u within strike window (u<PH.STRIKE_END) OR if time since last impact >0.25s. Simplest: record sim.lastImpact=-1; in impact() check performance-based time? integratePendulum has u. Condition: only trigger impact when inStrike || sim.theta... After strike phase, recovery motor lifts; theta near 0 with downward thrust 40 only during strike. After strike ends (u≥0.57), thrust gone; recovery motor raises. So double-impact can only occur within the strike window itself (0.11s window: bounce up then fall again within window? bounce omega ~0.34·34≈11.6 up; thrust 40 down + gravity → returns to 0 in ~2·11.6/41≈0.57s — after window ends. So no double impact in-window. But the fall-back at ~0.57s later lands during RECOIL where recovery motor k=16 pulls toward 0.46 — combined with downward momentum... theta could hit 0 during RECOIL → second impact ~0.6s after first. That would double-count strikes and double sound — bad. Prevent: in integratePendulum, only allow impact when inStrike. After strike window, if theta<=0 clamp theta=0.001 and zero negative omega instead. Actually physically the head resting on the anvil during recovery should just be caught: motor k=16 raises it anyway. Add guard: impact only fires if inStrike. Else clamp theta≥0.

Also note: after strike window ends, the head may still be bouncing — recovery motor will lift from whatever state; fine.

2. Steam thrust direction: -Math.sign(sim.theta) — theta>0 → negative alpha → accelerates downward. theta<0 can't happen (clamped). Good.

3. sim.omega after impact set positive 0.34·|omega| — during strike phase remaining substeps, thrust pushes down again, fight. Acceptable.

4. Ghost sampling while charge: strikeActive false → hidden. Good.

5. **updateBeatBar only called when beatIdx changes and running; when stopped segs stay as-is. Fine.

6. isBar: beatIdx fractional steps of 0.5 (0,0.5,1,...) → beatIdx%4 cycles per 4 eighth-notes... beatIdx values are multiples of 0.5: floor(beatFloat2)/2 → 0,0.5,1.0,...,7.5 within 4-beat cycle. beatIdx%4<0.01 true at 0 and 4.0 → accent twice per cycle (at cycle start and after 4 beats = next cycle start). So accent once per bar effectively (4.0 == 0 of next). Actually 4.0 occurs only at exact cycle end... cycle length 4 beats → beatFloat wraps before 4.0 → accent only at 0. Hmm: Math.abs(beatIdx%4)<0.01 → true when beatIdx=0,4,8... within cycle beatFloat 0..3.99 → only 0. Accent once per cycle. And the beat BAR UI: idx=floor(beatFloat2)%8 → 0..7 — 8 segs, accent class on 0 and 4. seg4 (the "bar" accent at impact time ~beatFloat 2.07 → idx 4) lights at impact.

Wait, seg index 4 corresponds to beatFloat 2.0-2.5. Impact at beatFloat≈2.07 lights seg 4 which HAS the 'bar' accent class (i%4===0 → i=0,4). Visually: the 5th segment (accented) lights right at impact. Groovy.

7. HUD phase 'IDLE' vs initial HTML 'COLD' fine.

8. trauma decay ok.

9. gradePass uShock: Math.max(0, val*0.86 + trauma*0.14 - 0.02) — at trauma 1: val→0.12 equilibrium. ab=0.120.012(0.4+r) tiny — barely visible. Increase: make uShock follow trauma directly with decay: uShock = max(trauma, uShock0.88). trauma spikes 0.55-0.7 at impact → ab≈0.70.012*(1.2)≈0.01 UV — visible chroma. Let me change to that.

10. bloom threshold 0.62, strength 0.85 — emissive-heavy scene; should glow nicely.

11. integratePendulum gravity term -(9.8/L_ARM)*sin(theta) = -1.32·sinθ — weak vs motors — fine (stylized machine).

12. Charge overshoot: k=30 target 1.92 — may overshoot past 1.92 up to ~2.1 with thrust... at u≥CHARGE_END thrust only during strike. Overshoot fine.

13. Strike window 0.11·cycleLen = 0.21s at 126bpm; at 168bpm cycle=1.43s → window 0.157s; fall 0.113s still fits. At 90bpm window 0.29s fine.

14. Charge duration at 168bpm: 0.46*1.43=0.66s; motor k=30 rise ~0.6-0.8s — might not fully reach; acceptable (faster tempo = lower lift, faster blows — physical!).

Fix items: impact guard (only inStrike; clamp otherwise), uShock follow trauma.

Also one more check on ghosts: HIST_N*4 = 192; histHead-1-(i+1)*2 min = 0-1-26=-27; -27+192=165 → %48=165%48=21 valid. Good.

And updateSim early: sim.cycleT-=cLen once — if tab inactive dt clamped 0.05 so fine.

Apply fixes.

*************************************************************************************************************************************************************************************07.

The tail looks good. Remaining checks:

1. embers.uniforms.uTime — makeDriftPoints returns {pts, uniforms} — good.
2. Audio8.tick when ctx null → guarded. Audio8.chargeHum guarded. Audio8.impact guarded. bellStinger guarded. Good — sim runs before audio unlock without errors.
3. updateBeatBar referenced in updateSim — hoisted function declaration. ✓
4. trailsOn — let at line ~1315, updateSim invoked only in animate() at end. ✓
5. setRunning toast on every space — fine.
6. On coarse pointers, #big-go toggles run. ✓
7. emissive intensity on MeshStandardMaterial with emissiveMap — floor uses emissive 0xff5a14 × emissiveMap — good.
8. The dust drift: pos spread area 30 around (0,0) plus y 0.5..9 — visible around forge. ✓
9. The lava pool at (9.5,5.5) — radius 4.6 disc at y=0.06 above floor disc 0.02 — no z-fight (0.04 apart, near camera distances ~20 fine).
10. Channels y=0.04 between. OK.
11. intro overlay visible at load; loader hides after first frame; scene renders behind intro — good preview.
12. Ghost mesh color setHSL(0.06,0.95,0.55) — ember orange additive. ✓
13. Snapshot: renderer.domElement.toBlob — with EffectComposer, final OutputPass renders to canvas — ✓.
14. Wheel: flywheel.rotation.z=-sim.wheelAngle — crankPin orbits → rod pumps. ✓
15. rim.castShadow etc. ✓

One more potential runtime error: Audio8.startMusic — this.music.gain.setTargetAtTime(0.6,t0,2.5) — music gain initial 0.0 → ramps. ✓ this._tickBuf created lazily. ✓

renderer.domElement.addEventListener('pointerdown', ...) — also OrbitControls uses pointerdown; both fine.

Edge: el.sound.onclick() invoked via key 'm' — calls Audio8.ensure() → creates ctx even if not entered; muted toggling before entering → master muted, then enterWorld adds 'on' class regardless... minor inconsistency: if user pressed M before entering (muted=true), then enters → class 'on' added but muted — desync. Rare; acceptable. Actually let me make enterWorld respect: el.sound.classList.toggle('on',!Audio8.muted). Tiny fix — do it.

16. In part2, embers origin: pos[i*3]=Math.cos(a)*r + (rise?9.5*0.6:0) → offsets (5.7, 3.3) — between anvil and pool; ok embers over the hot zone.

17. HUD el.biggo.textContent initial 'FORGE' matches HTML. ✓

18. sim.steam initial 0, HUD shows 'IDLE' only when !running; running starts true → 'VENTED'. fine.

Apply the tiny sound-toggle fix, then deploy: mkdir /space/demos/063-cinderforge, cp index.html, and update /space/demos/index.html adding the new card at the top of the demo-list (insert before the 062 card, per pattern "New demos are added here" comment placement... Looking at index: 062 card is at top, then the comment <!-- New demos are added here --> then 061... The newest is at the very top (062 above the comment). So I insert 063 card above 062 card, right after <div class="demo-list">. Let me check the exact text around it to anchor the replacement.

Then verify final file sizes and finish.

Interesting: in /space/demos/index.html, the newest demo (062) sits ABOVE the <!-- New demos are added here --> comment, and older demos (061, 060...) below it. So new demos are inserted directly after <div class="demo-list"> (before the 062 card). Let me look at the exact lines around <div class="demo-list"> to anchor insertion.

Index updated. Final verification:

1. Verify deployed demo file is complete (head + tail).
2. Verify the demo's HTML is valid structure-wise (has closing tags).
3. Quick final syntax check of the deployed copy (already done on /tmp/cf — same file).

Let me verify the deployed file tail and head quickly, and confirm index.html well-formed-ish (count of demo-cards = 63).

*****************************************************************************************************************************************************************************************************************************************ss.