Rubik's Cube · particle-1

Let me start by checking the directory and the three.min.js file.

Three.js r128. Let me build the cube.

Design:
- 27 cubies, each a RoundedBox-like mesh (just BoxGeometry) with 6 sticker planes on visible faces. Cubie body dark material, stickers colored with small gap.
- Each cubie positioned at (x,y,z) in {-1,0,1}, size ~0.94.
- Rotation logic: face turn around axis by 90°, select cubies whose coordinate on axis is 1 or -1.

Important: state preservation. Approach: keep a hierarchy. Use a pivot Object3D; for each layer, attach cubies to pivot, rotate pivot, then detach back to scene and bake transforms (update position and quaternion).

Better: keep cubies in a group. On move, create pivot (added to cubeGroup), attach selected cubies via THREE.Object3D.attach (preserves world transform) — r128 supports attach. Animate pivot rotation, then detach with attach back to cubeGroup (or scene) and normalize positions/quaternions to avoid drift.

Actually simpler and robust: since cubies are direct children of cubeGroup, use pivot as child of cubeGroup, attach cubies (their local transforms relative to cubeGroup become relative to pivot). Rotate pivot. On finish, detach using cubeGroup.attach(cubie), then round positions and snap quaternion.

Rounding: position components round to nearest integer. Quaternion: convert to matrix, round matrix elements to nearest integer (they'll be near-snapped since rotation is exact 90°). Let's do: after attach, cubie.position.set(Math.round(x), ...), and rebuild quaternion from rounded matrix.

Let me implement snapping:
```js
function snapCubie(c){
  c.position.set(Math.round(c.position.x),Math.round(c.position.y),Math.round(c.position.z));
  const m = new THREE.Matrix4().makeRotationFromQuaternion(c.quaternion);
  const e = m.elements;
  for(let i=0;i<16;i++) e[i]=Math.round(e[i]);
  // note translation part is zero from makeRotationFromQuaternion
  c.quaternion.setFromRotationMatrix(m);
}
```
Careful: m.elements includes indices 12,13,14 = 0. Fine. Rounding all elements works since they should be ~0,1,-1.

Face definitions: axis and layer value and direction.

Move definitions with rotation axis & angle sign:
- U: y=+1, rotate about +Y by -90° (clockwise looking from +Y). Standard: U turn clockwise viewed from above → rotation about Y axis by -90 degrees in right-handed coords (since looking down -Y direction... let's think). Right-handed: rotation about +Y by angle θ positive rotates +Z toward +X? Rotation matrix about Y: x' = x cosθ + z sinθ, z' = -x sinθ + z cosθ. So positive θ takes +Z to +X. Viewed from above (+Y looking down), +X is right, +Z is toward viewer (down on screen when looking down from above... hmm). Let me just define: for face with axis and layer sign, define angle = -90° * dir for U... Actually visual correctness of clockwise isn't strictly required to be verified, but let's be correct.

Standard convention: clockwise when looking at the face from outside.
Looking from +Y downward at the top face: screen right = +X, screen up = -Z (since viewer looks along -Y, with up being... ). Let's set camera above looking down: camera at (0, 5, 0) looking at origin, with up vector (0,0,-1). Then screen right = +X, screen up = -Z. A clockwise rotation on screen maps +X (right) → -Z (down on screen)... wait clockwise maps up→right, right→down, down→left, left→up. Screen up = -Z, screen right = +X. So clockwise maps -Z → +X. Rotation about +Y positive maps +Z→+X, which means -Z→-X. That's counterclockwise. So clockwise = negative θ about +Y. Good: U angle = -90° about Y.

For general face with outward normal n (e.g., +Y for U, -Y for D, +X for R, -X for L, +Z for F, -Z for B), clockwise viewed from outside = rotation by -90° about n.

So: angle = -π/2 * dir where dir=+1 for clockwise, -1 for prime, about axis vector n.

Moves: U: n=(0,1,0), layer y=1. D: n=(0,-1,0), layer y=-1. R: n=(1,0,0), x=1. L: n=(-1,0,0), x=-1. F: n=(0,0,1), z=1. B: n=(0,0,-1), z=-1.

Animation: animate pivot rotation from 0 to angle over ~300ms with easing.

Camera controls: custom orbit — mousedown on background (canvas), drag rotates spherical coords. Wheel zoom bounded between e.g. 6 and 16 distance.

Cube size: cubie at integer coords, size 0.94, spacing 1. So cube spans -1.47..1.47. Camera distance ~7.5 with fov 45. Let's set camera at spherical (r=7, theta=~35°, phi=~57°) giving a nice 3/4 view.

Use OrbitControls-less: 
- spherical: radius, theta (azimuth), phi (polar from +Y).
- camera.position from spherical target (0,0,0).

Buttons: U U' D D' L L' R R' F F' B B' + Scramble + Reset. Disable all during animation and while queued scramble sequence.

Scramble: generate 20 random moves from the 12, enqueue them.

Reset: cancel queue, reset cubie transforms to initial (store initial position/quaternion per cubie), reset camera, clear queue.

Stickers: for each cubie, for each of 6 directions, if cubie coordinate along that axis === layer value (i.e., it's on that face), add sticker plane. So centers get 1 sticker, edges 2, corners 3.

Sticker material colors:
- +X: red (R), -X: orange (L), +Y: white (U), -Y: yellow (D), +Z: green (F), -Z: blue (B).

Sticker as PlaneGeometry(0.8,0.8) positioned at n*0.478 with rotation facing outward. Or use RoundedBox not available. Use small planes with slight offset.

Alternatively make cubie body a BoxGeometry(0.95) with dark material, and 6 plane stickers at ±0.478.

For picking faces of the box, the sticker planes must be oriented. Use lookAt: mesh.position.copy(n.multiplyScalar(0.478)); mesh.lookAt(n * 2) — plane's +Z faces the target.

Lighting: use MeshLambertMaterial or MeshStandardMaterial? r128 supports MeshStandardMaterial. Use ambient + directional. Set renderer.outputEncoding maybe. Keep simple: MeshLambertMaterial with hemisphere + directional lights.

Let me also add slight bevel? Not needed.

Also add face rotation with shadow? Skip.

Now the animation loop with requestAnimationFrame.

Move queue: array of move strings. `busy` flag. On each frame if !busy and queue.length, start next.

Let me write the code.

```js
const COLORS = {
  right:0xC41E3A, left:0xFF5800, up:0xFFFFFF, down:0xFFD500, front:0x009E60, back:0x0051BA
};
```

Directions array with axis vector and layer.

Cubie creation:
```js
const cubeGroup = new THREE.Group();
scene.add(cubeGroup);
const cubies = [];
for x,y,z in -1..1:
  if all zero -> skip (hidden center, but include? include for completeness, invisible; skip is fine but core center not visible anyway. Include it, harmless.)
```

Actually skip the center for perf, but then Reset etc. fine. Include it anyway, simpler.

Body: BoxGeometry(0.96,0.96,0.96) with MeshLambertMaterial color 0x111111. Add stickers with polygonOffset or slightly raised.

Sticker plane size 0.82, offset 0.482.

Rounded corners are nicer but skip; boundaries visible via gaps.

Also add tiny edge lines? The gaps between cubies (1.0 spacing, 0.96 size) give visible seams; stickers 0.82 give borders. Good.

Now camera controls:

```js
let camTheta = Math.PI*0.25, camPhi = Math.PI*0.32, camDist = 7.2;
```
phi from +Y axis: 0.32π ≈ 57.6° so slightly above equator. Good.

updateCamera(): 
x = r*sin(phi)*sin(theta), y=r*cos(phi), z=r*sin(phi)*cos(theta). With theta=45°: x=z → viewing corner. Good. camera.lookAt(0,0,0).

Initial state stored: camTheta0 etc.

Drag: pointerdown → dragging=true if target is canvas (not button). pointermove: theta -= dx*0.008; phi -= dy*0.008; clamp phi to [0.12, π-0.12]. pointerup ends.

Wheel: camDist *= 1 + deltaY*0.001, clamp 5.2..14.

Prevent context menu maybe.

Event listeners on renderer.domElement.

Resize handler.

UI: HTML overlay with buttons styled. Panel at bottom or right. Include title/instructions.

Buttons disabled during busy? Requirement: "queue or disable further moves until it completes". I'll queue moves: clicking during animation appends to queue, and set visual disabled state? Simpler: queue all moves and add .busy class styling. But disabling looks like "disable further moves". I'll queue, and mark buttons with a "queued" state? Let's just queue and disable buttons while busy... if disabled, cannot queue. Either is fine. I'll queue (feels responsive) and show a status text. Let's do queueing, and scramble enqueues.

Actually there's a nuance: "Animate each move and queue or disable further moves until it completes so state is not corrupted." Queueing satisfies it.

Let me handle reset while animation running: set a `cancelToken` — set busy=false, pivot cleanup. Simpler: store current pivot; on reset, if animating, immediately complete it (finishMove) then reset all transforms. Let's implement finishMove() that detaches pivot and removes it.

Implementation of startMove:

```js
function startMove(move){
  const def = MOVES[move]; // {axis: 'y', layer:1, normal: Vector3, dir:1}
  const n = def.normal;
  const pivot = new THREE.Group();
  cubeGroup.add(pivot);
  const axisVec = new THREE.Vector3(n.x,n.y,n.z);
  const sel = cubies.filter(c => Math.round(c.position[def.axis]) === def.layer);
  sel.forEach(c => pivot.attach(c));
  const angle = -Math.PI/2 * def.dir;  // clockwise = negative about outward normal
  current = {pivot, axis:n, angle, elapsed:0, duration:0.32, cubies: sel};
  busy = true;
}
```

Wait: pivot is child of cubeGroup; cubies are children of cubeGroup. pivot.attach(c) preserves world transform, computing local relative to pivot which is identity initially → same local coords. Good since pivot at origin with identity rotation.

During animation: pivot.quaternion.setFromAxisAngle(axisVec, angle*eased).

On finish: set pivot rotation to exact final, pivot.updateMatrixWorld(true), then for each cubie cubeGroup.attach(c) (preserves world transform), snap. Then cubeGroup.remove(pivot).

Note attach requires updateMatrixWorld on the objects' parents. THREE.Object3D.attach calls updateWorldMatrix internally? In r128, attach: 
```js
attach(object) {
  this.updateWorldMatrix(true, false);
  _m1.copy(this.matrixWorld).invert();
  if (object.parent !== null) { object.parent.updateWorldMatrix(true,false); _m1.multiply(object.parent.matrixWorld); }
  object.applyMatrix4(_m1);
  ...
}
```
It updates world matrices, so fine.

Snap: rounding positions works if positions are exactly integers after rotation — they will be near-integers. Quaternion rounding via matrix works.

Also the cubeGroup itself is not rotated (camera orbits instead), so positions stay integers. Good.

Timing: use clock delta.

Easing: easeInOutQuad or a smoothstep.

Let's write the whole file.

Also add a small "move counter" or status text? Optional. Add status showing last move / queue length.

Buttons layout: two rows? 12 buttons plus scramble/reset. Use grid.

Let's write:

```html
<div id="ui">
  <div class="group">
    <button data-move="U">U</button>
    <button data-move="U'">U'</button>
    ...
  </div>
  <div class="group">
    <button id="scramble">Scramble</button>
    <button id="reset">Reset</button>
  </div>
</div>
```

Add keyboard support maybe (u, shift+u for prime). Nice extra, cheap.

Styling: dark gradient background, glassmorphism panel, rounded buttons with hover.

Careful: overlay must not block dragging except on buttons. Use pointer-events:none on container, auto on buttons. Also drag on canvas area — attach pointer handlers to window but ignore if event target is a button. Or attach to canvas only. Canvas is behind overlay with pointer-events none → events hit canvas. Good.

Also for touch, use pointer events, set touch-action none on canvas.

Let me write the code now.

Sticker rendering with Lambert + lighting: the white sticker needs enough ambient. Use MeshLambertMaterial with emissive? Lambert has emissive. Set emissive to color*0.15? Actually simpler: MeshBasicMaterial gives flat colors, always visible but no shading. Better look: MeshStandardMaterial with roughness 0.45, metalness 0.05, ambient 0.6 + directional. Let's do standard with lights.

Use renderer.outputEncoding = THREE.sRGBEncoding and physicallyCorrectLights false. Colors defined in hex; with sRGB encoding they'll look correct-ish. Let's keep outputEncoding default for simplicity.

Lights: HemisphereLight(0xffffff, 0x333333, 0.9), DirectionalLight(0xffffff, 0.7) at (5,8,6), another at (-6,-4,-7) intensity 0.35.

Body material: MeshStandardMaterial({color:0x1a1a1a, roughness:0.8}).

Stickers: MeshStandardMaterial({color, roughness:0.35, metalness:0.0}) plus emissive same color at low intensity to avoid dark faces: emissive: color, emissiveIntensity: 0.12.

Now code:

```js
const DIRS = [
 {axis:'x', layer:1, normal:new THREE.Vector3(1,0,0), color:0xC41E3A},
 {axis:'x', layer:-1, normal:new THREE.Vector3(-1,0,0), color:0xFF5800},
 {axis:'y', layer:1, normal:new THREE.Vector3(0,1,0), color:0xFFFFFF},
 {axis:'y', layer:-1, normal:new THREE.Vector3(0,-1,0), color:0xFFD500},
 {axis:'z', layer:1, normal:new THREE.Vector3(0,0,1), color:0x009E60},
 {axis:'z', layer:-1, normal:new THREE.Vector3(0,0,-1), color:0x0051BA},
];
```

Sticker orientation: use quaternion from lookAt. For normal (0,1,0), lookAt with up (0,1,0) is degenerate. Use explicit rotations per direction instead:

- +X: rotateY(90°) → plane normal +Z becomes +X. rotation.y = Math.PI/2.
- -X: rotation.y = -Math.PI/2.
- +Y: rotation.x = -Math.PI/2 (plane normal +Z → +Y? rotating about X by -90°: +Z → ... Rotation about X by angle θ: y' = y cosθ - z sinθ, z' = y sinθ + z cosθ. Vector (0,0,1) with θ=-90: y' = -1*sin(-90)*1? compute: y' = 0*cos - 1*sin(-90) = +1, z' = 0*sin + 1*cos(-90) = 0. So +Z → +Y. Yes rotation.x = -π/2.
- -Y: rotation.x = π/2.
- +Z: no rotation.
- -Z: rotation.y = π.

Set positions accordingly at 0.485 (half body 0.48 + eps).

Let me code the sticker creation inside cubie loop:

For each dir: if (x===dir.layer for axis x etc.) → add sticker.

Implementation:
```js
for each dir:
  const v = dir.normal;
  const onFace = (dir.axis==='x'? x : dir.axis==='y'? y : z) === dir.layer;
```

Now write file.

Animation timing: duration 340ms.

Queue: `const queue = []`. Button click: if move animation in progress, queue push; max queue maybe 32.

Also disable scramble/reset appropriately? Reset clears queue.

Let me write everything.

Also the reset should restore initial camera framing and solved cube.

Initial transforms: store `initial = cubies.map(c => ({p:c.position.clone(), q:c.quaternion.clone()}))` after creation (identity rotations).

Reset: if (current) finishImmediately(); then queue.length=0; restore.

Actually careful with finishing: on reset, simply call completeMove() which detaches and snaps, then restore each cubie to initial. Then pivot removal.

Code for completeMove(immediate):

```js
function completeMove(){
  if(!current) return;
  const {pivot, angle, axis, cubies: sel} = current;
  pivot.quaternion.setFromAxisAngle(axis, angle);
  pivot.updateMatrixWorld(true);
  for(const c of sel){ cubeGroup.attach(c); snap(c); }
  cubeGroup.remove(pivot);
  current = null; busy = false;
}
```

Then startNext() checks queue.

Loop:
```js
function animate(){
  requestAnimationFrame(animate);
  const dt = Math.min(clock.getDelta(), 0.05);
  if(current){
    current.t += dt;
    const p = Math.min(current.t/current.duration,1);
    const e = easeInOut(p);
    current.pivot.quaternion.setFromAxisAngle(current.axis, current.angle*e);
    if(p>=1) completeMove();
  } else if(queue.length){
    startMove(queue.shift());
  }
  renderer.render(scene,camera);
}
```

Hmm, startMove sets busy. And queued moves start immediately in next frame. Good.

Also for the inverse-return verification, exact snapping ensures sticker arrangement returns.

Now check: pivot.attach(c) — pivot is at origin inside cubeGroup; since cubeGroup transform is identity relative to scene here (position 0), positions remain integer. Good.

Potential issue: `cubeGroup.attach(c)` when cubeGroup has identity transform — fine.

Let's also update status text: show count of moves / "Solved" detection? Could display a small hint. Not required; skip solved detection or implement simple check comparing each cubie's matrix to initial. Could be a nice touch: show "Solved" badge. Let's add subtle status: number of queued moves. Keep simple: status line "Ready" / "Scrambling…" / "Turning…". Meh, optional. I'll add move counter.

Let's write the file.

HTML structure:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Rubik's Cube — Three.js</title>
<style>...</style>
</head>
<body>
<div id="app"></div>  <!-- renderer canvas appended here -->
<header id="hud">
  <h1>Rubik's Cube</h1>
  <p>Drag to orbit · scroll to zoom</p>
</header>
<div id="panel">
  <div class="moves">
    <div class="row">
      <button class="mv" data-move="U">U</button>
      <button class="mv" data-move="U'">U′</button>
      ...
```

Data-move uses plain ASCII "U'" or "Up"? Use e.g. data-move="U" and data-move="U'" — apostrophe inside double quotes is fine. But for keyboard, define move names.

Let me define moves map with keys 'U',"U'",'D',"D'",'L',"L'",'R',"R'",'F',"F'",'B',"B'".

Grid layout: 6 rows? Better: two columns of face pair? Design: a grid 3x4? Let's do rows of face: each row has label + two buttons: U U′ / D D′ etc. 6 rows × small buttons. Plus action row.

Panel at bottom center, translucent.

CSS:
```css
*{box-sizing:border-box}
html,body{margin:0;height:100%;overflow:hidden;font-family:...}
body{background:radial-gradient(1200px 800px at 50% 20%, #1b2434, #070a10 70%);color:#e8eefc}
canvas{display:block;touch-action:none}
#hud{position:fixed;top:18px;left:22px;pointer-events:none}
h1{font-size:15px;letter-spacing:.18em;text-transform:uppercase;margin:0 0 6px;font-weight:600;color:#cfd8ea}
#hud p{margin:0;font-size:12px;color:#7f8ca6}
#panel{position:fixed;left:50%;bottom:18px;transform:translateX(-50%);display:flex;gap:14px;align-items:stretch;padding:12px 14px;border-radius:16px;background:rgba(18,24,36,.72);border:1px solid rgba(120,150,200,.18);backdrop-filter:blur(10px);box-shadow:0 18px 40px rgba(0,0,0,.45)}
.grid{display:grid;grid-template-columns:repeat(6,minmax(0,1fr));gap:6px} -- hmm
```

Maybe better: moves grid with 6 columns: each column is a face with two stacked buttons (name label above?). Simpler: 6 columns × 2 rows of buttons where columns labeled. Let's do:

```html
<div class="faces">
  <div class="face"><span>U</span><button data-move="U">↻</button><button data-move="U'">↺</button></div>
  ...
```
Hmm arrows might be confusing. Keep letters.

Design: grid-template-columns repeat(6, 1fr), rows: label row (U, D, L, R, F, B), then clockwise button, then counter button:

Row1: labels
Row2: buttons with "↻"? Or use "U" and "U′" directly in buttons and no labels.

I'll go with 6 columns; each column has two buttons: label top button "U" (clockwise) and below "U′"? Actually the label is in the button. So:

```html
<div class="grid">
  <button class="mv" data-move="U">U</button>
  <button class="mv" data-move="U'">U′</button>
  ...
```
With 6 columns and 4 rows it reads as U U′ / D D′ / L L′ / R R′ / F F′ / B B′ filling row-major — confusing.

Better: two rows × 12? Too wide.

Use a grid with columns for faces:
```html
<div class="faces">
  <div class="face">
    <button data-move="U">U</button>
    <button data-move="U'">U′</button>
  </div>
  ... 6 of these
</div>
.faces{display:flex;gap:8px}
.face{display:flex;flex-direction:column;gap:6px}
```
Each face column: clockwise on top, prime below. Add small label above indicating face letter? Buttons already have letters. Good.

Then action buttons column: Scramble / Reset stacked.

Style buttons: width 46px, height 36px, border-radius 9px, monospace-ish.

Prime button dimmer + smaller? Same size fine; prime uses lighter text.

Also add press animation.

Status: small text under panel? Add `<div id="status">` at top right maybe. Let's include a status pill in hud: "Solved" / "Turning…". Skip to reduce complexity? It's fine—I'll add a simple move-count status in the top right.

Now write.

One more consideration: window resize.

Also to keep cube fully visible initially: with fov 45, distance 7.2, cube diagonal radius ~1.5 * sqrt(3) ≈ 2.6. Vertical half-extent = tan(22.5°)*7.2 ≈ 2.98 > 2.6. Fine. But with panel at bottom, cube might be covered on small screens. Camera at distance 7.6 and lookAt slightly? Keep target at origin; panel is only ~90px tall. Cube's projected radius ~ 2.6/ (7.6 * tan22.5) * 400 ≈ 2.6/3.15 * 400 = 330px in half-height terms... wait half-height = 7.6*tan(22.5°)=3.15 world units maps to 400px (800/2). Cube half extent 2.6 → 330px, so spans y from 70 to 730 in a 800px viewport. Bottom panel height ~ 100px from y=690. Slight overlap. Let's set distance 8.6 and reduce fov to 42? Let's use fov 45, distance 8.4 → half-height 3.48 → cube 299px half → 101..699. Panel top at ~ y=800-18-100=682. Slight overlap of 17px corner. Acceptable-ish; but let's shift camera target slightly up? Better: put panel on the right side or a compact bar. Or offset the look target so the cube sits a bit higher: camera.lookAt(0, 0.25, 0)? That shifts cube down on screen. Hmm we want cube up: look at target above origin? If target is above origin, the cube appears lower. To raise cube on screen, target should be below origin (camera aims below center → cube appears above center). Actually if camera looks at a point below origin, the origin appears above the screen center. Yes so target y = -0.2 raises the cube by ~23px. Do that: lookTarget = (0,-0.15,0)? Wait careful: camera.lookAt(0, -0.15, 0) means center of screen is that point; origin is above it → cube shifted up. Right.

Hmm but then drag orbit should rotate around origin. I'll rotate camera position around origin, then lookAt(0,-0.1,0)... a slight tilt is fine, no visual distortion noticeable.

Simpler: keep lookAt origin, use distance 8.8. Cube half 286px → 114..686. Panel top ~682. Fine, essentially no overlap. Use camDist = 8.6 and fov 45. Zoom clamp [5.5, 15].

Hmm, on a small viewport (e.g., 500px tall) overlap could occur, but panel is responsive — fine.

Let's write it.

Also add a subtle ground shadow? Skip.

Let me write final code carefully.

```js
const container = document.getElementById('app');
const renderer = new THREE.WebGLRenderer({antialias:true, alpha:true});
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
renderer.setSize(innerWidth, innerHeight);
container.appendChild(renderer.domElement);

const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(45, innerWidth/innerHeight, 0.1, 100);
```

Camera position function.

Let me now produce the file.

For keyboard: keydown, map letters u,d,l,r,f,b (case-insensitive) → move; shift → prime. Ignore if ctrl/meta. Also 's' for scramble? Might conflict... use 'z' scramble? Let's support 'z' for scramble and 'Backspace'/'0' for reset? Just add space? Keep: r is a move (R face), so Reset only via button. Keyboard: u,d,l,r,f,b; shift = prime. Fine.

Now writing.

Also solved-state detection to show badge — compute by checking each cubie's position equals initial and quaternion equals initial (within eps). Easier: compare position key & rotation matrix rounded key. I'll compute after each move completes. Show "SOLVED" pill when solved else "SCRAMBLED"? Nice touch. Implement:

```js
function isSolved(){
  for(let i=0;i<cubies.length;i++){
    const c=cubies[i], s=initial[i];
    if(c.position.distanceToSquared(s.p) > 1e-4) return false;
    if(Math.abs(c.quaternion.dot(s.q)) < 0.9999) return false;
  }
  return true;
}
```
Note quaternion dot with -q same rotation but dot negative; use Math.abs. Good.

Careful: for the identity-rotation of cubies with only symmetric stickers... position check handles it.

Update DOM status text.

Write file now.

Now write index.html.

Clean up that weird phi clamping line (leftover). Let me fix it.

The cube looks good. The bottom of the cube slightly overlaps the panel region? Cube bottom at y≈735, panel top ~690 but panel is centered horizontally at x 380-820 while the cube's bottom corner is at x~590 which is within the panel range... Actually the cube's bottom tip is hidden behind the panel? Looking at the image, cube bottom tip at ~y=735 and panel starts at y=690 and spans x 380-820. The cube tip at x~590, y~735 - it's hidden behind the panel! Yes the panel overlaps the cube's bottom vertex.

Need to move camera farther or shift the cube up. Let's reduce camera FOV effect by increasing distance to ~9.6 and/or offset lookAt upward. Let me compute: half-height at dist 8.7 = 8.7*tan(22.5)=3.6 world → 400px. Cube vertical extent: from image, top ~160 to bottom ~735 = 575px, half 287. Hmm cube's projected extent is large because the corner view. To fit within y range [say 120, 670], we need scale ~ 550/575 → distance increase of ~5%? That's not enough: center of cube is at 447 while panel top is 690; we need bottom at ~665, so shift up ~70px and shrink slightly.

Simplest: camera.lookAt(0, -0.18, 0)? That would shift the cube up... wait, looking at a point below origin makes origin appear above screen center → cube moves up. Let's use a look target y=-0.25 with dist 9.4. But orbit rotation center is still origin; the camera position is computed relative to origin then lookAt a shifted point - fine, minor.

Hmm, but shifting the look target down means the camera aims below cube center, cube appears higher on screen. Also with orbit, this shifts consistently.

Alternatively set camera target lookAt(0,0,0) and just set dist 9.8: cube half 287*(8.7/9.8)=255 → center 400 → range 145..655. That fits above panel (690). Good and simpler. Cube would be a bit smaller but still large and fully visible.

Let's set dist 9.8, keep min 5.6 max 15. Actually min 5.6 would clip into the cube? Cube corner radius 2.6; at distance 5.6 with near 0.1, the cube could be partly outside view but that's the user's zoom choice. Bounded zoom fine. Maybe min 6.2.

Let me update CAM_START.dist to 9.8 and min to 6.0.

Also I should test moves and inverse. Let me update, reload, screenshot, then test via browser evaluate? The browser tool doesn't have eval; but I can use `browser type` for keys? There's click and type and key. I can click buttons and inspect via screenshots. Also window.__rubik exists but I can't run arbitrary JS... Maybe I can use browser "inspect" only. Alternatively test logic with node? Hard.

I can verify visually: click R, screenshot, click R', screenshot, compare sticker arrangement visually. Also check console for errors.

Let's do it.

Cube fully visible above the panel. Now test R then R' via clicks. R button is at approximately x=566, y=573. Then check the resulting image, then click R' at x=568,y=587? Wait R' is third column second row: x=568, y=587. Hmm the layout: columns U,D,L,R,F,B; second row primes. So R' is at x≈568, y≈587.

Let's click R first.

The screenshot appears unchanged and status still "SOLVED". Maybe the click didn't register (screenshot taken immediately after click, before animation? the frame is at +0ms). Or the click missed the button. Let me click and then take a screenshot after a delay. The browser tool doesn't have a wait action, but I can use bash sleep then screenshot... Actually browser actions run separately; a screenshot action after click would be a new call, some time later.

Let me check DOM state: inspect might show the status text. Let's click then inspect status via screenshot again.

Actually the returned frame is the same moment. Let me do screenshot now (next call).

Still solved. So the click did not trigger the move. Possibly the click didn't hit the button, or JS error. Let me check console errors — console only shows warnings. Hmm, maybe pointerdown on canvas prevented? No, button click should work.

Maybe the browser click at (566,573) hit the R button... The buttons row 1 y center 573. x for R is 566. It looks right.

Maybe the issue: my `window.addEventListener('pointerup', endDrag)` etc. is fine. But the click handler... Perhaps the button click is being processed but the animation completes and returns to solved? No—R wouldn't return to solved.

Possibility: `enqueue` pushes into queue, startMove runs in next frame... but does the render loop run? The screenshot after reload showed the cube, so rendering works.

Wait — maybe the click happened before my click? Let me check whether the issue is `pointerdown` on the button triggering a drag and preventing click? pointerdown listener is on canvas only, so no.

Hmm, maybe the browser click coordinate mapping differs (device pixel ratio). The tool says coordinates use 1200x800 viewport. Screenshot is 1200x800. Should be 1:1.

Let me test by evaluating JS... The browser tool has no eval. But I could add a temporary test harness: create a page that loads index.html in an iframe? Simpler: use the "key" action to press "r" and see if the cube turns. That tests keyboard path.

Actually maybe the click did work but then... the status shows SOLVED even though it just turned? Status is refreshed in completeMove. Hmm.

Wait — maybe my click happened but `refreshStatus` ran and `isSolved()` returned true incorrectly? No, R turn moves cubies; positions change.

Let me try pressing key 'r'.

The keyboard works: R turn happened correctly (right face clockwise: white top row went to back? let's check: R clockwise viewed from +X: the top row of the right face should move toward the back (+Z? no). Anyway the image shows green on right-top, yellow on right-front column, and red remains on the front-right. Looks physically consistent.

But the state badge in the image still says "SOLVED" while DOM says "MIXED". The screenshot may be stale (frame captured earlier?). Odd. The DOM text says MIXED. The screenshot shows the turn applied but badge SOLVED — probably screenshot rendered from a slightly earlier frame? Actually the badge is DOM, drawn in same composite... Weird. Maybe the screenshot is a bit older than the DOM snapshot. Fine.

Now why did the button click not work? Possibly because the mouse pointerdown at button triggers... hmm. Actually maybe the click did work but the earlier screenshot was taken at a moment before the frame? Both clicked and screenshot showed solved, twice. And DOM still showed SOLVED. So the click didn't register at all.

Possibility: The click went to the button but pointer events... maybe the panel is beneath? No.

Maybe the browser tool's click does mousedown/mouseup on the canvas coordinates but hit testing uses different element (e.g., CSS viewport scaling due to the browser's own device pixel ratio 1?). Screenshot 1200x800 matches viewport.

Hmm, maybe my `window.addEventListener('pointerdown')` on canvas prevents default on pointerdown, and since the click target is the button, nothing.

Wait, maybe there's an issue: `buttons` collection is queried before... no, the script is at end of body, panel defined before. The buttons have class "mv prime" for primes; querySelectorAll('button.mv') matches both. Fine.

Let me use inspect to see if a JS error happened during the click. Console only shows warnings. Let me test by clicking "Scramble" button to see whether button clicks work at all.

Scramble at (766, 718).

Button clicks work (scramble started). So earlier the R click maybe landed... hmm, it should be fine. Perhaps the earlier screenshot was captured before the move and the DOM later updated—but the DOM text after the R click said SOLVED, meaning no move was queued. Possibly the click at (566,573) hit the gap between R button and R'? The R button spans x 546-586 roughly, y 556-590. Center (566,573) should hit.

Wait — maybe it did hit but the click was consumed by the earlier pointerdown on the canvas? Hmm, the first click I made on R happened right after reload; the panel... whatever. Scramble works.

Mid-animation screenshot shows a partial turn (D face), looks fine — layers rotating correctly as a group.

Now wait for the scramble to finish, then check state and reset. Also verify R then R' returns solved via a scripted check. Since I can't eval JS, I can rely on isSolved badge: press R twice with shift = R'? Use key 'r', then 'R' with shift... the key action might not support shift modifier. I can check the badge: after scramble, press Reset and check SOLVED badge.

Also I could verify inverse visually: after scramble completes, click a move then its prime? My earlier keyboard R follow-up: the cube shows mixed. Let me do: press 'r' then... shift would need modifier support. Alternative: click buttons now (they work for scramble).

Let me wait for scramble to finish by sleeping and screenshotting.

Hmm, after 8 seconds the scramble (20 moves * 0.3s = 6s) should be done, but it still shows TURNING… and a partial turn. Possibly the animation is slow because of throttled rAF in headless or screenshots. Or the queue drains but something stuck. Note screenshot shows a slight rotation on bottom layer — mid-move.

Maybe rAF in this headless environment runs slowly (frames captured only on demand?). The requestAnimationFrame may only tick when screenshots are taken. That would make moves extremely slow in this environment. In a real browser it's fine.

Wait, timing: dt from clock.getDelta capped at 0.05. If rAF runs rarely (say one frame per screenshot), each frame advances 50ms max, so moves take ~6 frames each. The first screenshot after the click showed partial D turn at maybe 30%.

Since screenshots advance the loop, this may be throttled. Let me take multiple screenshots quickly to advance.

Actually, the frames returned show "Frame 1, +0ms" each time. Hmm.

Alternative: keep and test with a deterministic script using jsdom? Not possible for WebGL.

Let's just take several screenshots to advance frames and observe. Better: use motion action to get frames over time? "motion" gives motion frames. Let's try that.

The cube is scrambled and stable, fully visible. But wait — something's odd: each cubie's stickers look right. However I notice the cube looks compressed? No, it's a corner view.

Hmm, an issue: looking at the top face, there's a white sticker and the top face shows yellow/white/blue — normal for scrambled.

But wait: the sticker colors seem misplaced? E.g., top face center white — fine.

One concern: the cube's scrambling seems to have produced a valid state. Good.

Also note the cubie bodies appear gray-ish edges, fine.

Now test Reset and check it returns solved with initial framing. Then verify R then R' returns solved (state check). Because I can't easily script, I'll click R then R' with delays and watch the badge return to SOLVED and visually compare.

But there's the earlier issue that my first button click (R) didn't register. Let me retest button clicks now: click R at (566,712)? Wait the current panel: row1 buttons y=712, row2 y=753. R is 4th column: x=566. So R at (566,712), R' at (566,753).

Click R, wait, screenshot, then click R', wait, screenshot. Then verify badge shows MIXED after R and SOLVED after R'.

Careful: after scramble, cube is mixed, so badge stays MIXED regardless. So do Reset first.

Reset works: solved cube, initial framing. Note the visible faces are white (U), green (F), red (R). Good.

Now click R and check that the R face actually turns (the red face should rotate clockwise). Then R' and confirm solved badge.

Badge in DOM says MIXED (screenshot stale). The R layer is mid-turn.

Hmm wait: the R face rotation looks wrong direction? The right layer is rotating; front-right column of green stickers appeared on the front right... it's rotating correctly as a layer (the R face stickers are turning). But notice: the white top stickers of the R layer have moved to the right side and green appeared on top — that's a clockwise R turn viewed from the right: top row → back? Let's verify: R clockwise (viewed from +X, looking in -X direction with up +Y and right on screen = -Z?...). For cw viewed from +X: screen up +Y, screen right -Z? Camera at +X looking toward origin (-X direction), up +Y: right = up × forward? right = forward × up? For a right-handed system, screen right = cross(up, forward)? Let's just trust: my formula angle = -90° about +X for R. Rotation about +X by -90°: y'= y cos(-90) - z sin(-90)= z; z' = y sin(-90) + z cos(-90) = -y. So a point at top (+Y) goes to +Z (front) — wait y=1,z=0 → y'=0, z'=-1 → that's back. Hmm: y'=y cosθ - z sinθ, with θ=-90: cos=0, sin=-1 → y' = z*1 = z? y' = 0*... let me recompute for point (0,1,0): y'=1*0 - 0*(-1)=0; z'=1*(-1)+0*0=-1. So top → back (-Z). So the top layer sticker on the right face moves to the back. In the image, the top-right white stickers moved right/back. Good enough.

The animation is correct.

Now click R' (566,753) and confirm returns to solved.

The DOM says SOLVED, so R then R' returned to solved state (isSolved() confirmed algorithmically). The screenshot shows the animation slightly in progress (the inverse turn). 

Wait — the screenshot shows the R layer mostly back but slightly offset? Actually it looks like it's mid-inverse animation, with the R layer nearly aligned. The DOM says SOLVED which means the animation had completed by the time DOM snapshot was taken (screenshot frame is from slightly earlier). Fine.

Now test drag-orbit and wheel zoom. Drag from background: e.g. from (150,200) to (300,260). Then screenshot. Then check the cube rotated but faces not turned (badge still SOLVED).

Orbit works: camera moved, cube still solved. But note the cube now appears tilted because phi decreased such that we're above and rotated. Fine.

However, the orbit rotated a lot for a 240px drag; theta changed by 240*0.0075 = 1.8 rad = 103°. Hmm, drag direction: moving right → theta decreased. Fine.

Now test wheel zoom bounds. Use scroll action with delta.

Also verify Reset restores initial camera after orbit. Let's do wheel zoom in, screenshot, then Reset.

Zoom in worked (distance went from 9.8 toward min 6.1). Note the cube extends beyond the top of the screen when zoomed fully in — that's acceptable since zoom-in is user-controlled, and bounded.

Now Reset to restore initial framing.

Reset restored initial camera and solved cube. Fully visible, panel doesn't overlap.

Let me additionally test a few different moves for correctness (U, F, L) and check that D/B function (they're on hidden sides—verify by orbiting). Also test that cubes don't drift after many moves (scramble then solve-by-inverse not easy). Since snapping exists, ok.

Test a sequence: U, then U' via keyboard shift? I can click U' button at (409,753). Do U then U' and check solved badge.

Also test F and B: B turns the back layer — verify visually from behind by orbiting. Let me do one quick combined test: click U, U', then orbit to see back with B turn.

Actually the badge check is algorithmic and reliable. Let's do U then U'.

U turn is animating (mid-turn at ~60°): top layer rotated counter-? It shows the top layer rotating; white stickers on the top layer moved... the front-top-right corner shows blue on the right face top corner and the top layer appears rotated clockwise when viewed from above? In the image the top layer's front row (was red on the R face? hmm). The top layer has rotated such that the red on the front top row has moved to the left... 

Wait: it looks like the top layer rotated but the top face still shows white — that's because the U face is all white, so the top looks unchanged; only side stickers moved. Correct.

Direction check: U clockwise viewed from above should move the front stickers to the left face. In the image, the front top row is red (red was on R face originally, at front-right?). Initially front was green. After U clockwise viewed from above: front row goes to left. The image shows the top layer front row red, top layer right column blue... Let's see: original arrangement: U=white top, F=green, R=red. After U cw viewed from above (front→left): F top row → L, L→B, B→R, R→F. So the front top row should become red (from R). Image shows front top row red. ✓ Correct clockwise.

Now the U' button.

DOM says SOLVED after U+U'. Good. Screenshot lags one frame (shows U' mid-animation). The status badge lag confirms screenshot is earlier than DOM snapshot.

I notice a rendering artifact: there's a thin diagonal line on the green sticker of the top-front-left corner and the middle-left. Looks like z-fighting between sticker plates of stacked cubies? At mid-animation the rotated layer's stickers intersect neighbors' stickers, producing interpenetration. That's expected during rotation due to interpenetration of coincident planes. The diagonal line is probably a coplanar overlap artifact at the seam. Not a big deal, and once settled it looks fine.

However, the initial screenshot after the R/R' / solved state looked clean. Fine.

Now, check performance/settling after many moves and the B face. Let's do: scramble, wait, orbit around to view the back and confirm blue face exists and layers are all intact. Also confirm no drift after many moves by resetting then applying a known identity sequence: e.g., R U R' U' × 2? That's not identity. Use (R U R' U')^6 = identity for a cube? Actually the "sexy move" has order 6. That would validate no drift. 24 moves at 0.3s = 7.2s but headless throttling makes frames slow. Hmm, screenshots advance frames; motion gives 4 frames per call at ~1s intervals.

Alternative: verify state logic separately in node by extracting the move math? The snap logic is straightforward. I'll trust it but do a moderate test: apply R,U,R',U' twice (8 moves) and check it's mixed, then... that doesn't give identity.

Better drift test: R R R R = identity. 4 clicks of R gives solved if no drift. Badge check would confirm. And F F F F similarly. Let's do R×4 and check badge SOLVED.

Given headless throttling, each move may need multiple frames. Clicking 4 times quickly queues them. Then wait via motion calls.

Let's do it.

This is R mid-turn (~60°) — looks correct, right layer rotating about X.

Now click R three more times quickly, then wait.

Second R applied (now top row of R face yellow, this is the 180° state complete). Note the sticker faces show yellow coming from the bottom (D yellow) — for R cw by 180°, the D yellow goes to top. ✓ Consistent.

Click R twice more.

Now third R applied (blue = back face color on top row, silver-ish is the white sticker in shadow... hmm the bottom-front column is now light gray/white). After 3 R turns, the front-right column should be white (from U). It displays grayish — that's the white sticker in shade. Wait, it's in front-bottom, x=right column, shaded by lighting. Actually white emissive 0.14, hemisphere light... it appears gray but that's fine—it's the white face at a grazing angle? The R face is lit from (6,9,7) which should light it well. Hmm, that face is the front-facing column of the R face; the light comes from +z... should be lit.

Hmm, wait — after 3 cw R turns, the U(white) stickers land on the front column of R? Let's see: R cw maps U→? Earlier computed rotation about +X by -90 maps (0,1,0)→(0,0,-1) i.e. U→B. So after 1: R gets U? No: stickers move with cubie. The face normal +Y maps to -Z (back). So the white stickers go to the back, and after 1 turn the R face receives stickers from +Z (front green→? ). Let's map: +Z → (0,0,1) → y'=z=1, z'=-y=0 → +Y. So front face → top. Thus after 1 turn the top row of the R face is green (front color). But image after 1st turn showed... let me look at first R screenshot: top row of right face was green (yes, the mint green). ✓. Second turn: top row = yellow? After two turns, front→top→back... top row should come from D? Hmm, after turn2 the top row of R = color that was previously on... The mapping after 2 turns: +Y→-Z? no: after 2 turns +Z→+Y→-Z... Let's compute the source of the top face after 2 turns: inverse map: top (+Y) came from +Z after 1 turn, which came from... source of +Z after 1 turn is -Y (since -Y →? (0,-1,0): y'=z=0? compute (0,-1,0): y'=y cosθ - z sinθ = -1*0 - 0 = 0; z' = y sinθ + z cosθ = (-1)(-1)=1 → +Z. So -Y→+Z.) So after 2 turns top row = yellow (D). Image 2 showed yellow ✓. Third turn: top = +Z source from -Y... top comes from -X (left/orange)? Let's see: image 3 top row = blue (back). Back = -Z. Indeed after 3 turns: top ← source chain: after 3, +Y comes from +Z (2 turns ago)... whatever, the sequence U→B (blue) is consistent with 3 turns since 1 turn gives green(F), 2 gives yellow(D), 3 gives blue(B), 4 gives red(R)... Wait that ordering F,D,B,U? Hmm 2nd showed yellow (D) and 3rd blue (B). 4th should be white (U)? The chain seems F→D→B→? Hmm we computed 1st: F(green); 2nd: D(yellow)? That skips. Whatever, the 4th turn should return to red (original) which is the solved check.

Also the front column bottom-white in image 3: that's white on the front face? The white is on R face front column, shaded → looks gray. After 3 turns the sticker facing +Z (front) came from U (white)? Chain: +Z ← -Y (1), ←-X? hmm whatever.

Line artifact: I see a thin gray diagonal line on the green sticker front-bottom-left. That is a z-fighting artifact between the rotated layer's sticker and the adjacent sticker plane during animation. It's transient.

Let's click R a fourth time and check SOLVED.

The 4th R is executing (mid-animation) and the DOM already reports SOLVED — so R×4 = identity. That confirms no state drift and the snap logic works.

Now test B and D via orbit view. Let me orbit to see the back and bottom. Then apply B, and D.

Actually the badge-based check suffices for correctness of each move's inverse property, but I want a visual check that B moves the back layer (not the front) and D the bottom. Let's orbit: drag to rotate ~180° azimuth and slightly up to see the bottom? To see the back, drag right by ~420px (theta -3.15 ≈ 180°). Let's drag from (300,300) to (720,300).

Then click B and screenshot mid-animation to make sure it's the back layer.

Also check D from a bottom view: phi near π-... drag downward to go under. Let's do a general check of B.

Now viewing from near-top directly down: white U face, blue B face, orange L face. The camera phi got small (looking nearly straight down) because I dragged down 80px → phi decreased 0.52 → phi ≈ 0.47 rad = 27° from +Y. Cube visible fully and no clipping (phi clamp 0.09 works). Six colors exist: we've seen white, green, red, blue, orange, and yellow earlier. ✓

Now test B from here: B is the blue face on the left. Click B (x=666,y=712) and screenshot mid-animation.

Interesting: this is the B turn mid-animation, but the visible motion is on the near/right layer?? Wait, the layer being rotated is the one currently in the front-right of the view... Hmm, at this camera angle, we're viewing from above with theta rotated ~180°+? Let's see: the previous view showed blue (B) on the left front, orange (L) on the right. Hmm, orange = L face, so the left of the screen is -X? Blue B is -Z facing the viewer-left.

The rotating layer in this screenshot: the front-right vertical layer (white stickers turning) is rotating about Z axis... rotating layer changes appear on the front-right sliver. Given the camera is at theta+~ (we rotated 420*0.0075=3.15 rad ≈ 180°), so the camera is now on the -Z/-X side. The near faces are B (blue) and L (orange). Wait, if camera is at azimuth ~180° from initial (which was +X,+Z octant), it's now at -X,-Z. So near faces are B(-Z) and L(-X). In the screenshot, blue is on the left half and orange on the right half — so -X (orange) appears on the right, -Z (blue) on the left.

The rotating layer is about Z (B face), which is at z=-1 → that's the face toward the camera-left. In the image, the vertical strip of white stickers on the right of the blue face is rotating — hmm, the strip spans the front-right which is the boundary... 

Actually the rotating strip appears to be the layer nearest the camera in the -Z direction, which is the "front" of this view. Hmm, but I see blue face on the left rotating? The blue face's right column shows movement with white stickers appearing. Wait, the turning layer is the z=-1 layer, which is the entire blue B face plus the adjacent strip on the left face (orange) and top face (white).

Look at the image: The orange face on the right shows a vertical column turning (the white strip at its left edge is tilted). The blue face on the left shows the rightmost column with white stickers (turned in). Both consistent with the z=-1 layer rotating about Z.

But hold on: the blue face on the left of the screen appears to be at the *near-left*, and the white strip is between blue and orange — those are the top face stickers rotated down? Hmm.

Rotation about the Z axis with camera near -Z: B face (z=-1) is nearest the camera. B cw = -90° about (0,0,-1) = +90° about +Z. Rotation about +Z by +90 maps +X→+Y: so the orange (L, -X) column adjacent... The strip between the blue and orange going from top-left to bottom-right... 

Actually let's just check plausibility: the picture shows a layer rotating about the axis pointing toward the upper-right (Z axis in this view points toward camera-left-ish?). Hmm, hard to judge. The key check is the badge: after B then B' the state returns to solved. Also B ×4 = identity.

Honest assessment: the geometry code for B is symmetric with U/R which I've validated (U and R produce correct clockwise results and exact inverses), and the layer selection is by the plane coordinate which correctly picks the z=-1 layer. The screenshot shows only one layer rotating, edges match up. It's very likely correct.

Wait — there's actually a visual problem: the white strip inside the rotating layer appears detached from the blue face — the turning layer is at the *middle*? Let me look more carefully: the natural reading is that the layer holding the blue face is rotating (blue face plus the white stickers rotated onto it). At ~45° rotation, we see blue still mostly in place, red on top of the turning layer... Hmm, the red on the top-left is weird: red is R (+X). Top face stickers on the z=-1 row would be part of the turning layer. But the top face shows a red row on its left side which is part of the turning layer? 

I'm getting confused about which faces are where. Let me just verify the badge returns to SOLVED after B then B', plus Bx4. Given the symmetric implementation and the snapping result, that's a strong correctness signal.

Actually, better: rather than agonizing, verify sticker arrangement return with a scripted check via the exposed window.__rubik? I can't eval.

Hmm, but I can add a test route: create a temporary test HTML file that loads index.html in an iframe? Not accessible cross-frame in sandbox with file://... maybe same-origin file access is restricted.

Alternative: run headless verification in node with three.js? The moves logic depends on three's Object3D attach; I could replicate in node by loading three.min.js (needs no DOM for math/Object3D). Actually I can build a pure-logic test in node using THREE from three.min.js: create the cube exactly as the page does (without renderer), then test all 12 moves and their inverses by checking cubie world transforms. That validates the math. But the page code is embedded; duplicating risks divergence, though the transformation part is identical logic.

Simpler: visualize B from a straight-on back view and compare with expectation. Let's orbit to look at the back face nearly straight. Then apply B and look at the result. Determining "clockwise" for B from the image should be easy: e.g. if the top row of the back face becomes orange (L color) for B cw? B cw viewed from -Z: rotation +90° about +Z: +Y→-X. So the top row of the back face goes to the left face... source of top row of back face after 1 B: inverse: from -X? Rotation +90 about Z: -X→-Y. So the source of +Y (top) is... solve R(+90): (x,y)→(-y,x). Source of (0,1) is (1,0)=+X. So the top row of B comes from +X = red. So after B cw, the back face top row should be red.

In the screenshot, after clicking B mid-turn, the top-left row is red — but that's the top face. Hmm at this angle the top face's left row shows red: those are +X stickers? no, top face is +Y stickers (white)...

Hmm wait: the red row in the screenshot lies on the top-left area which is the top face's front row? Actually looking again: The top face (white 3x3) has a red strip on its left/front edge... that's the *B face top row* seen nearly edge-on! Because the camera is nearly overhead, the vertical back face appears as a thin strip at the bottom-left. Yes! The blue on the lower-left is partly the B face and partly the underside? Ugh.

Given time constraints (used maybe 6 min), I'll accept the implementation: B uses layer z=-1 with normal -Z and dir +1, structurally identical to the validated U and R moves. The inverse test via badge is the strongest accessible check.

Let me do B then B' and check badge; and also D then D'.

Hmm, the image looks identical to the previous frame (B mid-turn), and the badge in the screenshot is MIXED while DOM says MIXED. Did the B' click queue after B finished? The DOM says MIXED, so either B or B' still pending, or B+B' not completed yet.

Wait, the image shows exactly the same 45° rotation state — the screenshot might be frozen at the same intermediate frame because rAF is throttled and the screenshot is captured from the same last painted frame? But it shows my click highlight? The B' button is highlighted (flash class), suggesting the click registered.

Since the screenshots appear to lag, I need to advance several frames and then read status. Let's call motion to advance frames and check the DOM status afterward.

Now the view is nearly top-down (white top, blue B left, orange L right) and solved. B + B' returned to SOLVED ✓ (badge). Also visible: 3 faces, no connection artifacts.

Note the earlier screenshots were mislabeled frames—the "B" turn screenshots (previous 2 calls) actually showed stale images. This explains the confusion: screenshots lag ~1-2 frames.

But wait — this current view is nearly straight down (white face appears square, sides thin). Hmm, the camera phi is small (looking down). Actually the white face looks like a diamond occupying most of the cube, with blue and orange strips at left and right of equal width — phi ≈ 45°? It's fine: fully visible, no clipping.

Notice the sticker widths on the sides look narrow relative to expectation but that's perspective from high angle. Fine.

Now, sanity check on the "SOLVED" state: since the view is from above and cube is solved, all faces same color. ✓

Let's do one more: rotate camera back to initial via Reset and check final framing + verify scramble button then reset again quickly. Already did reset earlier and it worked.

One more concern: the orbit in the initial view is from the +X/+Z octant giving white on top, green front-left?, red right, etc. Good.

Also verify D and L function (badge test D followed by D'). Quick: click D (x=460,y=712), then D' (x=460,y=753), then check badge. Let's do that and advance frames.

The D turn is animating — the bottom layer rotating about Y, visible at the bottom edge (blue/yellow glimpses). Fine.

Now click D' and advance frames to check solved.

The DOM says SOLVED (D then D' returned). The image shows a mid-animation bottom-layer rotation with a weird gap (bottom layer visibly separated from the cube!) — wait, that's because we're viewing nearly straight down and the bottom layer rotated makes some stickers visible... but there is a visible gap/floating appearance: the bottom layer appears displaced downward-left with a black gap.

Hmm, that gap is concerning. Looking closely: bottom-left area shows a blue sticker slab detached. Actually this is just the bottom layer rotating while viewed from above at a steep angle: since the visible silhouette of the rotating layer differs, and the stickers face different directions mid-rotation, we see them nearly edge-on with dark body between. The "gap" is the dark cubie body edge, not a real separation. Positions can't drift because attach preserves world transform.

Actually wait, there IS something off: the rotating bottom layer appears offset relative to the cube, closer to the camera at bottom-left. That's normal for a rotating layer viewed with strong perspective — the corners of the layer swing outside the cube silhouette.

OK. Verified enough. Both D/D' return to solved.

Remaining concern: sticker z-fighting while animating (visible thin diagonal line). Minor.

One improvement: the cube looks good, but the sticker borders are visible via gaps. Fine.

Let me reset to the initial view and take a final screenshot to confirm the deliverable state. Also check console has no errors (only GL performance warnings).

Also cleanup: remove `window.__rubik` debug hook? It's harmless and useful. I'll keep it but it exposes internals—fine.

Let me do final reset and screenshot.

Reset restored the initial framing (white top, green front-left, red right) and solved state. 

Everything works. A couple of polish items I could add, but the required behavior is verified. One thing: the initial view is a bit "flat" — camera phi 0.315π=56.7° gives a good 3/4 look. Fine.

Minor: during rotation, transient z-fighting lines. Could fix by giving stickers a slight polygonOffset or increasing the sticker offset delta between neighboring plates... They're flush because all stickers are at their own cubie surfaces, and during rotation they sweep through neighbors' planes. Adding polygonOffset won't fix interpenetration. It's fine.

Let me do a final check of file contents for cleanliness (no external refs) and confirm the HTML has no leftovers. Also check for `http` references.

Everything in place. Final summary of what was checked and what remains unverified.

Checked:
- Initial load: solved cube, six colors, visible seams, no console errors (only WebGL performance warnings).
- R turn (visual + status), R×4 = solved (state check), U then U' = solved, B then B' = solved, D then D' = solved; R' returns to solved (state check via isSolved comparing positions and quaternions).
- Queueing: clicks during animation queue and run sequentially.
- Scramble: applies 20 random legal moves sequentially, result mixed, cube intact.
- Drag on background orbits camera (no face turns, status remains solved).
- Wheel zoom bounded (min 6.1, max 15); zoom-in keeps bounds.
- Reset restores solved state and initial camera framing.

Unverified/known minor:
- F and L turns not individually clicked (same generic code path validated with U/D/R/B), though F/L keyboard works? Not tested. I should quickly test F and L to be thorough — cheap: press 'f' then 'F' with shift not available; use buttons. Click F, then F', check badge. Click L, L'. 4 clicks + a couple motion calls. Let's spend ~30s.

F turn animating: front (green) layer rotating clockwise — left column shows yellow coming in from the top (U→L? For F cw, U row goes to R, not L). Hmm: F cw viewed from +Z: +Y→+X. So the top row of F goes to the right column. And the left column gets from -Y? Inverse: source of left (-X) is -Y (D). Wait rotation about +Z by -90 (F cw = -90 about +Z): (x,y) → (y, -x). +X→-Y, +Y→+X, -X→+Y, -Y→-X.

In the image, the front-green face's left column is being replaced by yellow (which comes from D? no — the yellow stickers are on the upper-left, appearing at the top-left, coming from the top-left moving down the left column). A yellow row at the top-left of the turning layer — that's the D face (yellow) moving to the left column (-Y → -X). ✓ Consistent with F clockwise.

Also note: as F rotates, white stickers (U) rotate to the right column ✓ visible.

Now click F' and check solved.

Hmm — this screenshot (lagging one frame, during F') shows the front layer partly rotated, and I see the front face's right column with the white stickers nearly about to align. The status shows MIXED (stale). But the DOM snapshot in the same call said SOLVED — meaning by the time the DOM was read, the F' had completed and it was solved. Good.

Hmm wait, there's an oddity: the turning layer appears to be the *right* column of the front face plus more — the wedge shape. During animation the layer is rotated about Z; we see the front-left green face intact 3 columns, and the rotating layer (front z=1) is hard to distinguish because the green is uniformly colored. The near-vertical dark gap and the white stickers on the front right... Looking at it: the whole front layer appears rotated by ~65°. The left face (green) is on the left; the front face is green; the right face is red. Since both L and F are... wait no, L should be orange and F green. The left visible face is green?? That means the camera moved? We reset the camera to initial: white top, green front-LEFT, red right. Oh! Right: at the initial view theta=45°, the two visible side faces are F (green, left of screen) and R (red, right). So the green face on the left is F, and the rotating layer of F is the one closest to the camera — the diagonal wedge in the middle. Yes, that's the front layer rotated, showing white U stickers rotated to the... 

Wait, but if the green face on the left IS the front face, then the front layer includes that whole green face and the layer in front of it. The wedge between green and red is the F layer at ~60° with the white (U) stickers appearing on it. Fine, consistent.

So F+F' = SOLVED confirmed by isSolved. 

All 6 face turns validated in terms of exact inverse (which is the requirement's check). L not directly tested but identical code path; I'll note it.

I'm done. Final summary. Time used ~9 min.