Rubik's Cube · ling-3.1-flash

We need build index.html. Need use three.min.js local script. Need inspect file perhaps. Need develop robust interactive cube. Need no external. Need buttons U D L R F B and inverses likely U', etc. Animation queue/disable. Drag background orbit, bounded zoom. Scramble legal turns, reset solved and camera. Cubie state through moves. Need verify via browser. We have 15 min. Need write quality single file.

Need understand three.min.js version perhaps. ls/read head.

Need create. Design.

Three.js r? likely 0.137? Need API. We can use standard.

Cube representation:
27 cubies perhaps include internal? Visible 26. Each cubie object with position coordinates x,y,z in [-1,0,1], mesh group with box geometry and stickers. Need preserve state through moves. Build each cubie as Group at integer position; box black inner, six sticker planes slightly offset. Each sticker has color based on solved orientation: for cubie at x=+1 red/R, x=-1 orange/O, y=+1 white/U, y=-1 yellow/D, z=+1 green/F, z=-1 blue/B (standard maybe). Sticker mesh child of cubie at local face. Move rotates cubie group positions and orientations.

Animation: layer selection based on axis and value. Quarter turn direction. Need define move semantics consistent buttons and state. We can implement rotateGroup around axis by angle. Need determine sign for face turn. We can choose conventional but need inverse works. Buttons labels U, U', etc. State preserved.

Move queue: array moves, animate one at a time. Disable buttons during animation. Scramble enqueues maybe 20 moves. "queue or disable further moves until it completes" queue is okay. Could disable during each but allow queue. Better queue and show status. Buttons add moves if queue length < maybe 30. Animation duration 0.35 sec. For each move, create pivot Group at origin, attach selected cubie meshes (scene.attach? In three, pivot.attach(cubie) preserves world transform), rotate pivot, then on completion scene.attach(cubie), update cubie.position/rotation? scene.attach should update. Then remove pivot. Need ensure cube group? Could have cubeGroup containing cubies. pivot attach to cubeGroup perhaps. Use cubeGroup.attach(cubie), rotate cubeGroup? Let's reason.

Create cubeGroup at origin. Cubies children. For move:
const pivot = new THREE.Group(); cubeGroup.add(pivot);
selected.forEach(cubie => pivot.attach(cubie));
animate pivot.rotation[axis] += angle.
At end selected.forEach(cubie => cubeGroup.attach(cubie)); cubeGroup.remove(pivot).
This preserves positions and orientations. Good.

Move definitions:
axis and layer coordinate. U: y=+1. D y=-1. L x=-1, R x=+1, F z=+1, B z=-1.
Angle sign conventional:
Looking from outside face toward center, clockwise quarter turn. Need derive rotations in right-handed coordinates.
- R face (x=+1), viewed from +x toward origin (looking direction -x). Clockwise rotation around +x? Coordinate y up, z toward viewer? If viewer at +x looking -x, screen up +y, screen right? Need cross. Rotation around +x by +90 maps y->z, z->-y. From +x looking toward origin, axes screen maybe right = -z? Let's calculate. Camera at +x looking origin, up +y. Camera right =? right = cross(dir, up) maybe (-x cross y = -z), so screen right -z. Clockwise from up to right means +y -> -z. That's rotation around x by -90 (y -> -z). So R = -pi/2 around x. R' +pi/2.
- L viewed from -x looking +x, up y, right = cross(+x,+y)=+z. Clockwise y->+z = rotation x +pi/2. So L +pi/2, L' -pi/2.
- U viewed from +y looking down -y, screen up maybe -z? Camera up vector choose? Need conventional. Looking from top down, screen up typically -z (if front is +z toward normal viewer? Let's establish standard cube front +z, top +y. Viewer front at +z sees x right? Camera at +z looking -z, up y, right = cross(dir(-z), up(y)) = +x. Top face viewed from above, if orient camera looking down with screen up perhaps -z (back direction), then screen right +x. Clockwise from screen up (-z) to right (+x): -z -> +x. Rotation around y: +? R_y(+90): z->x, x->-z. Specifically vector -z -> -x, not. R_y(-90): z->-x, x->z; -z -> +x. So U = -pi/2 around y. Common formula U is rotation y +? Depends coordinate. Let's verify with physical: top face, viewed from above with front edge nearest bottom of screen (+z), back edge top (-z), right +x. Clockwise turn moves front edge to left? On top, clockwise viewed from above: front edge (bottom screen) moves right? Imagine clock face: at 6 o'clock, clockwise motion toward 9? Wait clock hands at 6 moving clockwise go to 7,8,9 (left), so front edge moves left (-x). A point at +z should map to -x under U. R_y(+90): z -> x, R_y(-90): z -> -x. Thus U = -pi/2. Good.
- D viewed from below. Clockwise from below. Point at +z (front) moves? Looking from bottom, screen orientation maybe +z bottom? Physical D clockwise (viewed from bottom) corresponds from top counterclockwise. Top CCW maps +z -> +x (R_y +90). So D = +pi/2 around y. D' -pi/2.
- F viewed from +z looking -z, screen right +x, up +y. Clockwise +y -> +x. Rotation around z: +? R_z(+90): x->y, y->-x. R_z(-90): x->-y, y->x. So F = -pi/2. F' +.
- B viewed from -z looking +z, screen right? Camera at -z looking +z, up y, right = cross(dir(+z), up(y)) = -x. Clockwise from up y to right -x. R_z(+90): y->-x. So B = +pi/2. B' -.
Thus angles: R -, L +, U -, D +, F -, B +. Inverses opposite.

Need state perhaps stickers remain. Each cubie mesh has stickers. Move group transforms. Scramble sequence legal turns avoiding same face consecutive maybe random. Reset: easiest remove all cubies and rebuild solved. Also clear queue, animation, camera reset. That's fine and preserves requirement. But "Preserve cubie and sticker state through moves" yes.

Need controls without OrbitControls. Implement custom pointer drag:
- canvas pointerdown. Need distinguish drag background vs perhaps cube? Requirement dragging background orbits camera without turning a face. No face dragging required. Any drag orbit. Use pointer capture, track dx dy, update spherical theta/phi. On pointerdown record. pointermove if dragging, theta -= dx*0.005? phi clamp [0.15, pi-0.15] maybe. No click action.
- wheel zoom: camera distance clamp 6 to 14, factor. Use event.preventDefault, passive false.
- initial camera framing fully visible. Cube size 3 plus gaps. Camera at distance maybe 9, fov 40, position spherical theta 0.8? Need fully visible. Camera (6,5,7) distance 10.5, lookAt origin. FOV 40 enough. At aspect maybe. Use fit? initial distance 10.5. Cube bounding radius sqrt(3)*1.5=2.6, with stickers. FOV vertical 38, distance 9 gives visible height 6.2, width based aspect. Fine.
- renderer resize.
- maybe antialias.

UI: header, canvas container, controls panel. Buttons with data-move. Include U, U', D, D', L, L', R, R', F, F', B, B'. Scramble, Reset. Status queue. Maybe keyboard? Not required. Could add.
- Buttons disabled while animation? If queue allowed, don't disable all; requirement "queue or disable further moves until it completes". We'll queue and show. Maybe disable Scramble/Reset? Reset should work perhaps clear queue. We can allow reset anytime. Buttons remain enabled to queue, but status says animating. This satisfies queue. To be safe disable move buttons while animating? But then queue not used. Requirement says queue or disable. We can disable during animation and re-enable after. Scramble can enqueue sequence and disable until done. But if user clicks scramble while queue, maybe ignore. Simpler robust: moveQueue; buttons enqueue; during animation buttons disabled? If disabled immediately, queue never >1 except scramble. We can implement queue and allow click, but disable buttons while busy? Contradiction. Better: buttons always add to queue, but if queue length >= 24 ignore. Status shows queue. "queue or disable further moves until it completes" queue is explicit. Good.
- Animation completion via clock in render loop rather than setTimeout to ensure. Could use animation object with start time and duration. In render, update. Need handle reset while animating: clear animation, rebuild.
- Scramble: generate 20 random moves, avoid same axis? "sequence of legal turns". Could random from 12. Avoid same face consecutive and avoid inverse immediately maybe. Push all. If queue empty, animation starts next frame. During scramble, buttons can queue more maybe. Could disable scramble while queue. Reset clears.
- Move names and angle. Move object {name, axis, layer, angle}. Inverse button name with apostrophe. For display.
- Animation easing: easeInOutCubic. Angle = targetAngle * eased. Since pivot initial rotation zero, set. At end exact.
- Need maybe layer includes center cubie at coordinate 0? Face turns only outer layer coordinate ±1. Good.
- Cubie geometry: BoxGeometry(0.95,0.95,0.95), black material. Sticker PlaneGeometry(0.82,0.82) with color, perhaps MeshStandardMaterial. Position at ±0.481. Need visible cubie boundaries: gaps and black body. Add subtle bevel? Box with black. Sticker planes. Use polygonOffset? offset enough 0.481 vs box half .475, good.
- Each cubie group position set coords*1.0? If cubie size .95 and positions -1,0,1, gap .05. Good.
- Face colors distinct: U white #f8f8f8, D yellow #ffd500, L orange #ff5800, R red #009e60? Wait standard Rubik: white opposite yellow, green opposite blue, red opposite orange. Use U white, D yellow, F green, B blue, L orange, R red. Distinct.
- Maybe add colored face labels? Not needed.
- Lighting: ambient + directional.
- Background.

Need test with browser. We can write file. Need be careful three.min version maybe WebGL. Use renderer.outputEncoding? Could avoid version-specific. Use `renderer.setPixelRatio`. Use `THREE.sRGBEncoding` maybe exists. Not necessary.

Need perhaps no external assets. Fonts system.

Need implement reset camera function. Initial camera state constants. Reset cube:
while cubeGroup.children remove? Cubies are children except pivot. Clear animation and queue. Remove cubeGroup from scene and create new? Easiest `scene.remove(cubeGroup); cubeGroup = createCube(); scene.add(cubeGroup);` But if pivot child, removed with group. Good. Set status.
Need ensure event references cubeGroup variable updated.

Potential issue `Group.attach` in old three exists. Yes Object3D.attach introduced long ago.

Need maybe state verification programmatically. We can expose `window.cube`? For testing via browser evaluate? Browser tool only actions, no evaluate? It has inspect maybe returns DOM/console. We can use `inspect` action likely. Could add debug status showing cubie positions? Not required. To verify visually, screenshot. Turn U then U' via click and screenshot. Orbit drag. Reset. Need maybe use browser inspect. We'll do.

Let's write index.html. Need inline script src three.min.js then own script. "load each with plain script src NAME exact filename" include `<script src="three.min.js"></script>`. No other external.

CSS. Canvas container position relative. UI top. Buttons.

JS details:
```
const MOVES = {
 U: {axis:'y', layer:1, angle:-Math.PI/2},
 "U'": ...
}
```
Button order maybe U U' D D' etc.
State:
```
let cubeGroup, cubies=[], moveQueue=[], activeAnimation=null, isAnimating...
```
createCubie:
```
const group = new THREE.Group();
const body = new THREE.Mesh(new THREE.BoxGeometry(...), bodyMaterial.clone()?);
```
Materials can share. Sticker material per color shared. But if same material all stickers okay. Need each sticker orientation. For each face:
```
const sticker = new THREE.Mesh(stickerGeometry, stickerMaterials[color]);
sticker.position.set(...);
sticker.rotation.y = ...
```
Plane default normal +z. For +z no rotation. -z rotation y pi. +x rotation y pi/2? Plane normal +z rotated y +pi/2 maps normal to +x (z->x), yes. -x rotation y -pi/2. +y rotation x -pi/2? Normal +z rotated x -90: z->? R_x(-90): z->y, yes. -y rotation x +pi/2: z->-y.
Position:
+x (.481,0,0), -x etc.
Set `sticker.userData.solvedColor = color` maybe.
Cubie `userData = {coords: new THREE.Vector3(x,y,z)}` but after moves coords change. Could compute from position rounded. Not needed.
Add to cubeGroup.
Maybe include all 27 including internal invisible? Internal body would occlude? If all 27, internal cubie hidden but can affect? It is inside and not visible, but when layer rotates internal center? Face turn outer only, no issue. But 27 includes center at 0,0,0 never moves. Use 26 excluding (0,0,0) to avoid hidden geometry and potential z-fighting? Exclude.
Move selection `cubie.position[axis] === layer` but after transforms positions are exact floats maybe rounded. Use `Math.round(cubie.position[axis]) === layer`. Since positions remain integers. Good.
Animation:
```
function enqueueMove(name) {
 if (moveQueue.length >= 30) return;
 moveQueue.push(MOVES[name]);
 updateStatus();
}
function startNextMove() {
 if (activeAnimation || !moveQueue.length) return;
 const move=...
 const pivot = new THREE.Group();
 pivot.name...
 cubeGroup.add(pivot);
 const selected = cubies.filter...
 selected.forEach(c => pivot.attach(c));
 activeAnimation = {move,pivot,selected,start:performance.now(),duration:350};
}
```
But `cubies` array remains and attach changes parent. Good.
In render:
```
if (activeAnimation) {
 let t=(now-start)/duration;
 if t>=1 { pivot.rotation[axis]=angle; finish;}
 else pivot.rotation[axis]=angle*ease;
}
```
At finish:
```
selected.forEach(c => cubeGroup.attach(c));
cubeGroup.remove(pivot);
activeAnimation=null;
startNextMove();
```
Potential `cubeGroup.attach` while pivot is child of cubeGroup. Works.
Need if reset during active: remove cubeGroup and pivot; activeAnimation null.
Queue status. Buttons disabled? We can leave. Maybe add class `busy` and disable scramble if queue length >0. But move buttons can queue. Requirement visible buttons. Good.
Scramble:
```
function scramble() {
 if (moveQueue.length || activeAnimation) return; // maybe allow if no queue
 const names=...
 let prev=null;
 for i 0..19:
   do name random; while name[0]===prevFace || inverse? 
 push
 prev=name[0]
 update
}
```
If activeAnimation but queue empty, could still enqueue; no issue. But to avoid complexity if `activeAnimation || moveQueue.length` return. Status.
Reset:
```
moveQueue=[]; activeAnimation=null; scene.remove(cubeGroup); dispose? not necessary; cubeGroup=createCube(); scene.add; resetCamera(); updateStatus('Solved');
```
If active pivot removed with old group. Good.
Need maybe dispose old geometries? Not necessary but repeated resets could memory. Could dispose traverse. Implement disposeObject maybe. But not needed. Could.
Initial camera:
```
const CAMERA_HOME = {theta: 0.65, phi: 1.05, distance: 9.5};
```
Position:
```
camera.position.set(
 dist*Math.sin(phi)*Math.sin(theta),
 dist*Math.cos(phi),
 dist*Math.sin(phi)*Math.cos(theta)
)
```
theta 0.65 gives x 4.3, z 6.4, y 4.2. Nice.
`phi` from y axis, clamp 0.25 to 2.8. Need fully visible. distance 9.5.
Zoom wheel:
```
window.addEventListener('wheel', e => { if (e.target !== renderer.domElement) return; ...}, {passive:false})
```
Since canvas fills maybe. `distance *= (1 + e.deltaY*0.001)` clamp 6.5,14. Update.
Pointer events:
```
let dragging=false, lastX...
canvas.addEventListener('pointerdown', e => {dragging=true; canvas.setPointerCapture(e.pointerId);});
canvas.addEventListener('pointermove', e => {if(!dragging)return; const dx=...; theta -= dx*0.006; phi -= dy*0.006; clamp; updateCamera();});
pointerup/cancel false.
```
Need orbit without turning face. Yes.
Maybe distinguish click? no.
Cursor grab.
Prevent context menu? not needed.
Touch action none.

Renderer:
```
const renderer = new THREE.WebGLRenderer({antialias:true});
renderer.setSize(container.clientWidth, container.clientHeight);
container.appendChild(renderer.domElement);
```
Scene background maybe CSS gradient; renderer alpha true and setClearColor(0x000000,0). Or scene color. Use CSS.
Camera aspect update.
Add `scene.add(new THREE.AmbientLight(0xffffff, 0.7)); const dir = ...`
Maybe add hemisphere.
Add subtle floor? Not needed.
Cube edges: each cubie black boundaries visible. Could add `EdgesGeometry` lines? Black box gaps enough. But visible cubie boundaries maybe add line segments per cubie with dark gray. Body black and gaps. Add edge lines maybe nice:
```
const edges = new THREE.LineSegments(new THREE.EdgesGeometry(bodyGeo), edgeMat);
group.add(edges)
```
But line on outer boundary. Good. However each cubie black box with edge. Use body material color #111, roughness.
Sticker material `MeshStandardMaterial({color, roughness:0.35, metalness:0.05})`.
Maybe sticker slightly smaller and rounded? Plane. Fine.

Status and move log:
```
<div id=status>Solved</div>
<div id=queueStatus>Move queue: 0</div>
```
Maybe show last move.
Button `title`.
Add keyboard mapping? Not required but nice. Could add keys u,d,l,r,f,b with shift for inverse. But avoid accidental. Not necessary.

Need ensure `U'` in HTML data attribute. Use `data-move="U'"`.
Button text `U′` maybe use prime character. Data exact `U'`. Use `U&prime;`? Button text `U′`. Fine.
Need labels maybe "quarter turn". 

Potential issue with `performance.now()` and render loop. Fine.

Need test. Write.

Need test browser. Use browser action screenshot initial.

Screenshot says model does not support images, but DOM. Need interact click. Need know coordinates. Buttons in HUD. Could click by coordinates maybe need inspect to get positions? Browser inspect action maybe.

Need click buttons. Viewport 1200x800. HUD at x16 y16 width min360. Button grid after header/status. Need approximate coordinates. Let's calculate layout:
HUD padding 14/16. h1 20 line 24, margin bottom4, subtitle 12 line maybe 14 margin12 => ~54. status row height maybe 34 margin12 => ~100. button grid 2 rows (6 columns on width 360) each 38 gap7 margin10 => 83. So first row buttons y around 16+100+19=135. U x: grid width 328? HUD width 360, padding 16 each => 328. 6 columns gap 7*5=35, each 48.75. U center x 16+16+24=56. U' center +55.75=112. D 168, D'224, L280, L'336. But HUD width maybe 360. Second row y 180. R etc. We can click U at (56,135), U' at (112,135). Need wait animation 360ms. Browser tool calls maybe sequential with no delay? We can use bash sleep? Better browser click then maybe screenshot after tool call likely enough? Could use action click then action screenshot but no explicit wait. Could use `key`? No. We can call bash sleep 0.5 between? Browser state persists. Do click U, then bash sleep, then click U', sleep, screenshot. But browser tool maybe separate. Let's do.

It says Solved queue1 because updateStatus called before render. Need wait.

Need inspect DOM after wait.

Interesting DOM still queue1 after 0.5 sec. Maybe render loop not running? Browser screenshot maybe static and no rAF? Or click enqueued but startNextMove only called? We never call startNextMove in enqueue! Indeed enqueueMove pushes but doesn't call startNextMove. Render updateAnimation only activeAnimation null. Need fix: after enqueue, call startNextMove. But if activeAnimation, startNextMove returns. Good. Also updateStatus. Need edit.

Need reload. Browser action reload. Then test.

Now click U, wait, inspect.

Again status immediate. Wait.

Good. Click U' at x112.

Wait and inspect.

Status says Mixed 2 moves though physically solved. Requirement inverse returns starting arrangement, not status necessarily. Could improve status to detect solved state? Not required but nice. We can compute solved by each cubie position and sticker orientation. But status "Mixed (2 moves)" after inverse might be misleading. We can implement isSolved and status accordingly. Need verify visible stickers return. We can add solved detection. But not necessary. Better to have status reflect solved after inverse. Need implement robust.

Solved detection: For each cubie, position equals one of solved coords? After moves, cubie positions permute but set same. Each sticker's world normal and position? Easier use cubie.userData.solvedPosition and sticker.userData.solvedFace. A cubie is solved if its current position equals solvedPosition (rounded) and each sticker's local normal? Since cubie group rotation may be identity if returned. But after U U', yes cubie positions and rotations identity. Could check each cubie:
```
const p = cubie.position;
const sp = cubie.userData.solvedPosition;
if (Math.round(p.x)!==sp.x...) return false;
for sticker of cubie.children where userData.solvedFace:
  normal = new THREE.Vector3(0,0,1).applyQuaternion(sticker.getWorldQuaternion? or cubie quaternion)
```
Since sticker local orientation relative cubie and cubie rotation. Solved if sticker normal corresponds to face and position? If cubie at correct position and cubie quaternion identity, all good. But some cubies can be in correct position with twisted orientation; detect. Use cubie.quaternion angle to identity < epsilon. However after legal moves, a cubie can be in solved position but rotated (twist), so check quaternion. `cubie.quaternion.angleTo(new THREE.Quaternion()) < 1e-3`. But after U U' exact? Floating point from attach maybe exact? likely. Use 1e-3.
```
function isSolved() {
 for cubie:
   sp...
   if rounded mismatch return false;
   if cubie.quaternion.angleTo(identity) > 0.001 return false;
 return true;
}
```
But after reset, yes. After U U' maybe floating errors < .001. Update status uses isSolved. moveCounter maybe still 2 but status Solved. Good.
Need add identity quaternion const maybe inside function.
Also moveCounter maybe count moves. Fine.
Need edit updateStatus.

Need reload and test orbit drag, reset. Also potential issue status after active animation: updateStatus("Turning U") overrides; after finish updateStatus() uses isSolved. Good.

Need test orbit. Drag from background coordinates maybe (900,400) to (700,400). Browser drag action has x,y,toX,toY. Use drag. Then screenshot/inspect. Need ensure pointer events on container; HUD may intercept but background at x900. Do drag.

Now click U and U' again maybe after reload. Then orbit.

Wait inspect.

Great. Orbit drag now.

Need verify camera changed. Browser tool doesn't expose JS state. Could use wheel? Not. We can trust. But maybe drag coordinates not on canvas due HUD? x950 background yes. Need maybe use browser screenshot unavailable. Could add a debug readout of camera angle? Not required. But to verify, perhaps expose state in DOM? Could add `data-camera`? Not necessary. We can use browser action inspect only DOM. Could add hidden or visible small "view" status? Not required. But for verification, maybe use `window`? Browser tool doesn't provide evaluate. Could use console.log and inspect console? It only shows warnings, maybe console logs? Could add console.log on pointer move, but not needed. We can inspect via `browser` action maybe `inspect` includes console logs? It might. Could temporarily add console.log? Not necessary. But we need verify reset initial framing. Click Reset after orbit and status. Camera reset function. Good.

Potential issue: `disposeObject` traverses and disposes geometries not shared, but body/edge/sticker shared. It doesn't dispose materials, okay. It also traverses cubies and sticker geometries shared, no dispose. Good.

Potential issue: `resetCube` sets activeAnimation null but if pivot currently animating, then removes cubeGroup from scene including pivot. Good.

Potential issue: move queue and active animation count. `updateStatus` called during active animation with text, queue status includes active + queue. Good.

Potential issue: `startNextMove` called from enqueue while activeAnimation; returns, queue remains. Render finish calls startNextMove. Good.

Potential issue: Scramble button while activeAnimation but queue empty: returns "Wait". If queue >0 returns. Good.

Potential issue: Reset during active animation: `activeAnimation=null`, but old pivot remains in old cubeGroup removed. Fine.

Potential issue: `moveCounter` increments after each move, so after scramble 20. Fine.

Potential issue: `isSolved` checks quaternion identity. After a full sequence that returns cubies to solved positions but rotations maybe identity. Good. After U U' exact? yes.

Potential issue: move semantics maybe U angle sign. Inverse works regardless. Face turn clockwise convention maybe not critical. But let's verify signs maybe. We can reason. Standard cube with F +z, U +y, R +x. For U, rotation about y -90. Does top face turn clockwise viewed from top? We reasoned yes. Let's double-check with right-hand rule. Camera above looking down (direction -y). To define screen, if camera up vector? In our orbit camera at theta .68, phi 1.03, not directly. But viewed from +y with screen up = -z (back), right = +x. Clockwise rotation on screen maps top (screen up = -z) to right (+x). Rotation about y by -90: R_y(-90) matrix: x' = -z? Let's derive standard R_y(theta): x' = cosθ x + sinθ z; z' = -sinθ x + cosθ z. For theta=-90: x' = -z; z' = x. Vector -z (0,0,-1) -> x'=1, z'=0 = +x. Yes. So U clockwise. Good.
F: camera at +z looking -z, screen right +x, up +y. Clockwise maps up (+y) to right (+x). R_z(-90): x' = cos x - sin y = y? Standard R_z(theta): x'=cos x - sin y; y'=sin x + cos y. theta=-90: x'=y, y'=-x. +y -> +x. Good.
R: camera at +x looking -x, screen up +y, right? Camera right = cross(dir, up) = (-x) cross y = -z. Clockwise maps up +y to right -z. R_x(-90): y'=cos y - sin z = z? Standard R_x(theta): y'=cos y - sin z; z'=sin y + cos z. theta=-90: y'=z, z'=-y. +y -> z'=-1 = -z. Good.
D: camera at -y looking +y. Need screen orientation. If screen up maybe +z? Looking from bottom, to keep front? Physical D clockwise viewed from bottom. Our angle +90. Check: viewer at -y looking +y. Choose screen up = +z? Camera right = cross(dir(+y), up(+z)) = +x? Actually y cross z = x. Clockwise maps screen up (+z) to right (+x). R_y(+90): z -> x? Standard theta=+90: x'=z, z'=-x. +z -> +x. Good. So D clockwise from bottom. Good.
L: viewer at -x looking +x, up +y, right = cross(+x,+y)=+z. Clockwise maps +y -> +z. R_x(+90): y'= -z? Standard theta=+90: y'=-z, z'=y. +y -> z'=+z. Good.
B: viewer at -z looking +z, up +y, right = cross(+z,+y) = -x. Clockwise maps +y -> -x. R_z(+90): x'=-y, y'=x. +y -> x'=-1 = -x. Good. Great.

Need maybe test scramble and reset. But before, perhaps need check initial framing fully visible. Camera distance 9.6, fov 38. Cube radius ~2.6. Vertical extent visible at distance 9.6: 2*9.6*tan(19°)=6.6, cube vertical 3.0. Horizontal at aspect 1.5: 9.9, cube horizontal 3.0. Good. On mobile aspect maybe width small, horizontal visible = vertical*aspect; at 0.5 aspect, width 3.3, cube 3.0 plus perspective maybe okay. HUD overlays but cube centered. Good.

Need maybe wheel zoom bounded. We can test via browser action? Browser tool lacks wheel action. Could use drag only. Not necessary.

Need test reset button click. Coordinates for reset button: action row below grid. Grid two rows: y around 176? Let's calculate more accurately. HUD top 16, padding top14 => content y30. h1 height maybe 24 + margin4 => y58. subtitle height 18? margin-bottom12 => y88. status row padding8 top/bottom, font12 line maybe 16 => height32, margin-bottom12 => y132. button grid first row height38, gap7, second row38, margin-bottom10 => total93 => y225. action row buttons height40. So reset center y245. x: HUD left16 width360, action row two columns each ~160, reset right center x16+16+80+7+80? First column center 16+16+80=112, second center 112+7+80=199. So reset at (199,245). Scramble at (112,245). Let's click reset after orbit.

Good. Need test scramble maybe click scramble, wait, inspect. But if we scramble, then reset again. Do.

Queue status 20 includes active? It says Move queue 20 though 20 pushed and active one shifted, so queue length 19 + active =20. Good. Wait 20*0.36=7.2 sec. Need maybe sleep 8 sec.

Inspect.

Scramble works. Reset again.

Need maybe final file present. But before final, consider if any hidden issues. Let's inspect file around code to ensure no syntax errors (browser ran). Good.

Need maybe requirement "Preserve cubie and sticker state through moves; recoloring a static cube is not sufficient." We have cubie groups with stickers and transforms. Good.

"Provide visible buttons for U, D, L, R, F, B quarter turns and their inverses." Yes 12 buttons.

"Animate each move and queue or disable further moves until it completes so state is not corrupted." Queue. Good.

"Dragging the background orbits the camera without turning a face." Yes pointer events on container, not cube-specific. But note HUD is above container and pointer events on HUD don't orbit. Good.

"Keep cube fully visible initially and support bounded wheel zoom." Yes.

"Provide Scramble, applying a sequence of legal turns, and Reset to restore solved cube and initial camera." Yes.

"Only core global THREE is provided; implement camera controls without importing unavailable addons." Yes.

Need maybe no external resources. We use no CDN. Fonts system. Good.

Need maybe `three.min.js` script tag plain local. Yes.

Potential issue: The runner will inline three.min.js into final artifact. Our file references it. Good.

Potential issue: "Write it to index.html in current working directory" yes.

Need maybe report checked behaviors and unverified. We should mention no image screenshots due model, but DOM status and interactions. We checked U then U' returns solved status via isSolved; orbit drag (though no visual image, camera update executed); reset; scramble; queue. Wheel zoom not actually exercised because browser tool lacks wheel; code bounded 6.2–14.5. Need mention. Could maybe simulate wheel via bash? Browser tool doesn't have wheel action. Could dispatch event via script? No evaluate. Could perhaps use `key`? No. We can state unverified. But maybe we can add a temporary debug or use browser action `scroll`? Browser tool actions include scroll, not wheel. `scroll` likely scroll page, not wheel event on canvas. Could use action scroll with delta maybe it dispatches wheel? Let's see tool schema: action scroll, delta. It may scroll viewport, not necessarily wheel event. Could try on canvas after reset; but page doesn't scroll, our wheel handler prevents default. Browser tool `scroll` might synthesize wheel at current mouse? It has no x/y, only delta. Might not target canvas. Not necessary.

Could test bounded zoom by exposing distance in DOM? Not needed. But maybe we can add a small camera view readout to HUD? Not required and could clutter. Better not.

Need maybe check initial output and console per addendum. We did. Console only warnings, no errors. Good.

Need maybe use `browser` screenshot initial output; model doesn't support images. We did screenshot and inspect. Fine.

Need maybe ensure file size and final.

Need final concise. But before final, perhaps consider whether `disposeObject` could dispose `EdgesGeometry`? It checks object.geometry !== edgeGeometry. EdgeGeometry is shared, so no. Good.

Potential issue: `bodyGeometry` and `stickerGeometry` shared across cubies. When reset, disposeObject doesn't dispose them. Good.

Potential issue: `stickerMaterials` shared. Good.

Potential issue: `resetCube` after active animation: `activeAnimation=null` but `cubeGroup` removed; `cubies` still references old cubies until createCube assigns. Fine.

Potential issue: `startNextMove` uses `cubeGroup` global. If enqueue called before initial resetCube? Buttons only after resetCube called at script bottom. Good.

Potential issue: `onPointerDown` uses `dragging` declared later with `let` after functions. In JS, function hoisted but variable temporal dead zone until execution reaches declaration. The functions are defined before `let dragging`, but not invoked until after event listeners and resetCube; by then declaration executed. Good.

Potential issue: `onWheel` uses event.deltaY; okay.

Potential issue: `container.setPointerCapture` on pointerdown; pointermove on container receives. Good.

Potential issue: `renderer.setSize(width,height,false)` with canvas CSS width/height 100%. Good.

Potential issue: `camera.lookAt` after updateProjectionMatrix. Good.

Potential issue: `scene` alpha true and CSS gradient. Good.

Potential issue: `THREE.sRGBEncoding` not used. Colors may appear slightly dark but fine.

Potential issue: `MeshStandardMaterial` with ambient/directional. Good.

Potential issue: Face colors distinct: white, yellow, orange, red, green, blue. Yes.

Potential issue: visible cubie boundaries: black boxes with 0.05 gaps and edge lines. Yes.

Potential issue: Animation queue: If user clicks many moves, queue up to 32. Each move uses pivot attach/detach. Good.

Potential issue: If user clicks Reset while queue, moveQueue set new array; old moves discarded. Good.

Potential issue: Scramble avoids same face consecutive but can have e.g. U then U? no. It avoids same face entirely, so legal and no immediate inverse. Good.

Potential issue: "applying a sequence of legal turns" yes.

Potential issue: "Reset to restore solved cube and initial camera" yes.

Potential issue: "Start solved" yes.

Need maybe mention verified U/U' inverse via solved detector, orbit drag, reset, scramble. Wheel zoom code bounded but not exercised due tool. Also visual screenshot unavailable. We can report.

Need final with no extra.