Rubik's Cube · step-5-preview

Three.js r128. Let me build the app. I'll write my own orbit controls.

Let me design:
- 27 cubies (or 26 without center), each a BoxGeometry with materials, plus sticker planes on faces.
- Simpler approach: each cubie is a rounded box (BoxGeometry) with dark plastic material, and stickers are planes slightly offset on outer faces. Sticker colors stored in state per cubie per face direction.

For state preservation: keep a logical model: cubies array with position (x,y,z in {-1,0,1}) and orientation tracked by rotation matrices. Standard approach: maintain each cubie's logical position and rotation matrix. On quarter turn, select cubies whose position is on the turning layer (based on axis), animate rotation, then update position via rotation matrix and update the cubie's object quaternion.

Simplest robust approach: each cubie has a THREE.Object3D group containing the mesh; store rotation matrix R (cubie orientation relative to initial). When turning, rotate all cubies in layer by matrix Q about axis by ±90°. New position = Q * pos, new R = Q * R. Then set object position from pos, quaternion from R. That works because sticker geometry is attached to cubie.

Face turn axis/angle:
- U: axis Y, +90° (viewed from top, clockwise when looking down -Y). Standard U is clockwise looking from above (from +Y down). Clockwise from +Y looking toward -Y means rotation about +Y by -90°? Let's think: looking down from +Y toward origin, we see X to the right, Z toward viewer's bottom... Actually a rotation about +Y by angle θ (right-hand rule) appears counterclockwise when viewed from +Y looking down toward origin. So U (clockwise from above) = rotation about +Y by -90°.

Hmm, but does the direction matter? It matters for correctness of inverse pairs. As long as U and U' are exact inverses, and each face-turn button does a consistent quarter turn, that's fine. But "legal turns" of a standard scramble should be fine either way. I'll define angles so they look right.

Let's define: F = rotation about +Z by -90° (clockwise looking from +Z toward origin, i.e., from front). Wait: looking from +Z toward -Z (viewer in front), right-hand rule positive rotation about +Z appears counterclockwise. So clockwise = -90°. F = -90° about Z. F' = +90° about Z.
B = looking from -Z toward origin (viewer behind): clockwise from that view = -90° about... For B, axis -Z; clockwise from -Z side = rotation about +Z by +90°. B' = -90° about Z.
U = about +Y by -90°? Looking from +Y down: the viewer looks along -Y. Right-hand positive about +Y appears counterclockwise from +Y. So clockwise = -90° about +Y. Hmm wait, let me verify with vectors. Rotation about Y by -90° (using right-handed coords, y up): R_y(-90°) maps x→? R_y(θ): x' = x cosθ + z sinθ, z' = -x sinθ + z cosθ. For θ=-90°: cos=0,sin=-1. x' = -z, z' = x. So (1,0,0)→(0,0,1), (0,0,1)→(-1,0,0). So front-top edge position (1,0,1) maps to (-1,0,1)... Let's check: point (1,1,1)→ x'=-z=-1, z'=x=1 → (-1,1,1). Top face viewed from above: x to the right, z... if viewer is above looking down at XZ plane with +X right and +Z downward on screen (typical), then (1,1) screen = (x=1,z=1) i.e., right-bottom; moves to (-1,1) = left-bottom. That's clockwise. Good, U = R_y(-90°).

D: looking from below (-Y), clockwise = R_y(+90°).
R: looking from +X, clockwise. Rotation about +X by -90°? R_x(θ): y' = y cosθ - z sinθ, z' = y sinθ + z cosθ. θ=-90: y'=z, z'=-y. Viewer at +X looking toward -X: sees +Y up, +Z to the left... For viewer at +X looking -X direction, with up = +Y, then right-hand direction: forward = -X, up = +Y, right = forward × up? right = up × forward? Let's use: right = cross(up, backward) ... simpler: view direction d = (-1,0,0), up u=(0,1,0), right r = d × u? For camera, right = cross(d, u) = (-1,0,0)×(0,1,0) = (0*0-0*1, 0*0-(-1)*0, -1*1-0*0) = (0,0,-1). So right = -Z, up = +Y. So on screen, points with larger z appear left. Clockwise from this view = positive rotation about +X? Let's check with a point: top-right of the face on screen = (+Y, -Z) i.e. (0,1,-1). Apply R_x(-90°): y'=z=-1, z'=-y=-1 → (0,-1,-1) = bottom-left on screen. Top-right → bottom-left = clockwise. Yes. So R = R_x(-90°), R' = R_x(+90°).
L = R_x(+90°) about +X (clockwise from -X side).
F = ? Viewer at +Z, d=(0,0,-1), up=(0,1,0), right = d×u = (0,0,-1)×(0,1,0) = (0*0-(-1)*1, (-1)*0-0*0, 0*1-0*0) = (1,0,0) = +X. Clockwise from front: top → right. Point (0,1,1) top-right; should go to (1,-? ) Let's compute R_z(θ): x' = x cosθ - y sinθ, y' = x sinθ + y cosθ. θ=-90: x' = y, y' = -x. Point (0,1,1)→(1,0,1): top → right. Clockwise. So F = R_z(-90°), F'=R_z(+90°). B = R_z(+90°).

Good.

Now animation: create a pivot group added to scene, attach layer cubies to pivot, animate pivot rotation, then detach and apply final positions/quaternions. Simpler approach: for each move, create a temporary pivot Object3D, add to scene, move the layer cubies into it (preserving world transform by using pivot.attach? Actually since we set cubie transforms from logical state at start, we can: pivot.position=0, rotation=0 at start; add cubies to pivot; they keep local transforms; animate pivot quaternion from identity to Q; at end, for each cubie, apply matrix M = Q * R to logical state, then reparent to scene (cubeGroup) and set position/quaternion from state).

Implementation of reparenting: pivot.updateMatrixWorld(); cubeGroup.attach(cubie) preserves world transform — but we then overwrite position/quaternion from logical state anyway. Just do scene-level group add and set.

State: cubie object has .position (Vector3 logical grid coords) and .quaternion derived from R. Store R as Matrix4 per cubie. Actually simplest: store logical position and logical quaternion; each frame set object.position = pos, object.quaternion = R. When updating: pos.applyQuaternion(Q) (rotating around origin), R = Q * R (premultiply: world rotation applied before existing local rotation). Object quaternion should be matrix-from-Q*R. So store R as Matrix4 or as quaternion: Rq.premultiply(Q). Since rotations compose: new world orientation = Q * old orientation. In quaternion terms: Rq = Q.clone().multiply(Rq). Then position = Q.applyToVector(pos).

Yes.

Cubies: build 27 cubies at positions (x,y,z) with x,y,z in {-1,0,1}, spacing e.g. 1.0 with cubie size 0.95. Skip interior (0,0,0)? Keep it, doesn't matter — actually skip it to save. But then "preserve cubie state" — fine either way. I'll include all 27 except center? Center never moves and is invisible. I'll just include 26 (skip (0,0,0)).

Stickers: for each face direction, add a rounded plane (PlaneGeometry) at 0.5*size offset, oriented facing outward. Use a slightly smaller plane (e.g., 0.82) with color material. Rounded corners via shape geometry maybe; simpler: PlaneGeometry with a canvas texture for rounded rect. I'll generate a rounded-rect texture via canvas — that's allowed (no external assets, canvas generated). Good, gives nice look.

Materials: cubie body = dark MeshLambertMaterial. Also for faces that aren't exposed, no sticker.

Selection of layer: for a move with axis 'x'/'y'/'z' and layer index, cubies where round(pos[axis]) == layer.

Also need raycasting for drag-orbit only (no face turning by dragging, per spec "Dragging the background orbits the camera without turning a face"). So no drag-to-turn. Good — simpler.

Controls: mouse drag on canvas rotates camera (spherical angles), wheel zoom with distance clamp. Touch support: touchstart/move.

UI: buttons for U U' D D' L L' R R' F F' B B', Scramble, Reset. Move queue: array; process sequentially; disable buttons during animation (or allow queueing — spec says queue or disable; I'll disable during animation but allow queue of pending? Let's disable while animating and also allow clicking during animation to enqueue with a small queue — simplest: if animating, ignore clicks but show status. Actually let's implement a queue with max length, and buttons disabled while queue non-empty AND... hmm the spec: "queue or disable further moves until it completes so state is not corrupted." I'll implement: click adds to queue (queue unlimited), animation processed sequentially; that's queueing, state safe. But scramble of 20 moves would need to finish. That's fine.

Actually a hybrid: enqueue all clicks, process sequentially with ~120ms animation each. Scramble can be enqueued as a batch. I'll keep it simple with a queue.

Verification of inverse check: "Turn one face and apply its inverse, checking that the visible stickers return to their starting arrangement" — I'll implement a self-test function that runs F then F' and verifies each cubie's logical position/quaternion return to identity, plus sticker world colors match. I could add a hidden check function callable from console. Let's also visually show a "verify" button? Not required. I'll write a check function in console for testing and maybe run it on load silently. Better: implement `window.cubeVerify()` returning true/false, and I'll run it in the browser console during inspection.

Let's also record initial sticker arrangement: map from cubie pos + face normal → color. After F, F' compare. Implement checkAllSolved(): every cubie's sticker world color at grid slot matches the initial assignment. Since state tracking is exact, the test can compare the full arrangement against initial arrangement (each cubie pos + sticker normal → color). Let's implement:

initialSnapshot(): for each cubie, for each sticker {normal (Vector3), color}, compute world normal = R applied to normal, and world pos = pos; store key = pos rounded + normal rounded → color. Then checkSolved() compares current snapshot to initial snapshot (which for solved cube equals face-uniform arrangement).

Then test: applyFace('F'); applyFace("F'"); checkSolved() → true.

Also need to expose moves programmatically without animation for tests: I'll add `applyInstant(move)` API. Also scramble and reset.

Reset: restore solved cubie positions/quaternions, clear queue, reset camera.

Lighting: ambient + directional. Renderer with antialias, sRGB, shadow maybe. Keep simple.

Also add mouse-following? Not needed.

Let me also handle resizing.

Rendering stickers: to make cubie boundaries visible, body color dark and stickers smaller.

Also add a subtle "black gap" look: cubie size 0.94, spacing 1.0.

Let me write the code.

Canvas texture for rounded sticker:

function makeStickerTexture(color){ canvas 128x128, draw rounded rect fill white base? Actually fill entire with color and rounded corners radius; edges transparent → shows black body. Then use MeshBasicMaterial? With lighting, better MeshStandardMaterial/LambertMaterial with map, transparent true. Use PlaneGeometry(size, size) with map. The transparent background will show the body color. Fine.

Alternatively build sticker as ShapeGeometry with rounded corners — vector, no texture needed, and lighting works. THREE.Shape with absarc. Let's do that: cleaner. But UV not needed. Use MeshLambertMaterial({color}). Lambert doesn't support... it supports color. Fine. But the shape geometry needs to be rotated to face outward; I'll create geometry in XY plane and rotate mesh.

Actually simpler: rounded rect ShapeGeometry. Let me write helper:

function roundedRectShape(w,h,r){ const s=new THREE.Shape(); ... using moveTo/lineTo/quadraticCurveTo }

I'll implement.

Sticker mesh: geometry = roundedRectShape(0.8,0.8,0.13) → ShapeGeometry. Position offset along normal 0.47+eps. Orientation: look along normal. Use quaternion setFromUnitVectors(new Vector3(0,0,1), normal).

Now the sticker's stored local normal = the face direction (e.g., (0,1,0) for U). Good.

Let me now write index.html.

Also include a status line showing current move queue / "Solved!" detection maybe. Nice touch: display move history count and whether solved. Keep moderate.

Camera framing: perspective camera fov 45, distance ~7.5, cube of radius ~2.6, at 45° fov, half-height at distance d = d*tan(22.5°)=0.414d; need 2.6 visible → d ≥ 6.3. Use d=8 for margin. Spherical: theta (azimuth), phi (polar) clamped between 0.15 and π-0.15. Zoom distance clamp [5, 18].

Orbit drag: pointer events on renderer.domElement. Also handle touch. Use pointerdown/move/up with capture.

Let me also add auto-rotate? Not required. Skip.

Also should the cube rotate itself for orientation during turn? The logical approach handles it.

Let me write the file now.

Code details:

```js
const MOVES = {
  U: {axis:'y', layer: 1, angle: -Math.PI/2},
  D: {axis:'y', layer:-1, angle:  Math.PI/2},
  R: {axis:'x', layer: 1, angle: -Math.PI/2},
  L: {axis:'x', layer:-1, angle:  Math.PI/2},
  F: {axis:'z', layer: 1, angle: -Math.PI/2},
  B: {axis:'z', layer:-1, angle:  Math.PI/2},
};
```
Inverse = negate angle.

For animation duration, quarter turn = 160ms; scramble uses same but maybe faster 90ms.

Implement queue processor with requestAnimationFrame loop.

Implementation:

```js
let queue=[], animating=null;
function enqueue(moves){ queue.push(...moves); updateButtons(); }
function tick(){ if(!animating && queue.length){ startMove(queue.shift()); } if(animating){ animStep(); } render; requestAnimationFrame(tick); }
```

startMove(moveKey): compute spec; gather cubies; set pivot; animating={spec, pivot, cubies, t:0, dur}.

But careful: the queue should be processed even if user clicks during animation — fine since queue is separate.

Animation step: increase t by dt; ease = t/dur; angle = spec.angle * easeInOut; pivot.quaternion.setFromAxisAngle(axisVec, angle).

On complete: apply Q matrix: for each cubie: pos.applyQuaternion(Qq); Rq.premultiply(Qq); set object transform; pivot.remove(cubie); cubeGroup.add(cubie); set cubie.position.copy(pos), cubie.quaternion.copy(Rq). Then scene.remove(pivot). animating=null. Check solved state.

Note: when reparenting from pivot to cubeGroup, we set position/quaternion explicitly, but need pivot.updateMatrixWorld before? Not needed since we overwrite.

Important: while animating, the pivot is child of cubeGroup at origin, so pivot world = cubeGroup transform. cubeGroup itself never rotates (camera orbits), so fine.

Also pivot rotation: use pivot.quaternion within cubeGroup. Good.

Now buttons disabled state: keep buttons enabled but queue moves (allowed since queue prevents corruption). I'll disable during animation? The spec allows queueing. I'll allow queueing but show queue length. To be safe and user-friendly: buttons always work (queued). But maybe excessive queue. It's fine.

Hmm, but a possible risk: a verification script might click a button then immediately check state before animation completes. Let me expose `applyInstant` and also make the "queue" drained fast? I'll add window.__cube API: {enqueue, instant, checkSolved, snapshot, reset, isBusy}. And my browser inspection will use data-testid / coordinated clicks with waits.

Let me also make the animation duration reasonably short (140ms) so tests are quick.

Solved check: compare sticker arrangement to initial: build map key `${px},${py},${pz}|${nx},${ny},${nz}` → colorIndex. Also check cubie positions match original set (implied). Compare after every move and display "Solved!" badge.

Let me write.

Also add keyboard shortcuts: U/D/L/R/F/B with shift for inverse.

Now CSS: dark background, panel with buttons at bottom/top, styled.

Let me write the whole file.

Also include face color legend? Not needed.

Let's write.

One more: "visible cubie boundaries" — with rounded stickers and dark gaps it's clear.

Write file now.

There's a leftover unused `scrambleSeq`. Fine. Let me run it in the browser.

Note a potential issue: in `startMove`, the filter comparing cells — comparing cellKey of masked position. That works: for axis x, masked = (spec.axis.x*c.pos.x, 0, 0) and target masked = (spec.axis.x*layer,0,0). cellKey rounds, fine.

Let's test.

The cube renders but framing: bottom of the cube is cut off by the panel? Actually panel overlaps bottom, but cube appears fine — the panel is over the bottom part? The screenshot shows the cube with the panel below overlapping? The panel seems to be below the cube. But the cube's bottom row isn't visible — it's occluded by panel? Looking at the image: the panel is drawn below with the cube's bottom face hidden. Actually the panel is a semi-transparent overlay, so it's covering the lower part of the cube. Also the control panel wrapping into two rows (label row issue at narrow widths) — the DOM shows buttons fine.

Issue 1: The panel overlaps the cube's bottom. Need to either shift the camera up or reduce panel width / make panel not overlap. Let me increase camera distance slightly or offset the camera target. Best: lift the cube up by offsetting the lookAt target so the cube sits higher, or move panel to a side. Simplest: keep camera centered but increase distance to 9.5 and add a small vertical offset to lookAt (target y = +0.6) so the cube appears higher in the viewport. But the panel is at bottom center — the cube bottom face would still be behind it. Let's check: panel height ~110px at 800px tall viewport = 14%. Cube appears ~ half the viewport height. Let's raise the cube by offsetting the camera target upward-ish, i.e., set the projection so the cube center is a bit above the middle. I'll add camTargetY = 0.9 and use camera.lookAt(0, camTargetY... ) hmm lookAt offset moves cube in opposite direction.

Actually let's just set the vertical framing: camera.position.y = dist*cos(phi) and lookAt(0,0,0). To shift the cube up on screen, I need the camera to look at a point above the cube center: lookAt(0, +1.0, 0) makes the cube appear lower. lookAt(0, -1.0, 0) makes cube appear higher. Let's set lookAt(0, -0.9, 0), so cube center is above screen center by 0.9/ (0.414*dist) fraction of half-height ≈ 0.9/(0.414*8.6)=0.25 → 25% of half height up. That would put the bottom face more visible. Also maybe reduce panel width by using shorter buttons... The panel wrapped into two rows because of labels widths; that's on desktop at 1200 width it showed two rows. Let me reduce label width and paddings so all 12 buttons fit in one row on desktop. Buttons min-width 44 + label 26 → 12*44 + 6*26 + gaps ≈ 528+156+100 = 784; panel max-width calc(100vw-20px)=1180. Hmm it wrapped anyway at 1200px viewport? DOM shows two rows: "F F′ B B B′" on second row. So total exceeded. Maybe because button padding 12px each side + border → each ~50px + label 26 + gap 7: (12*50/2... let's compute: 6 pairs of (label 26 + 2 buttons ~50 each) = 6*(26+100+7)=798 plus panel padding 28 = 826 < 1180. Hmm but the DOM output order suggests wrap. Wait, looking at the screenshot, the first row shows U U′ D D′ L L′ R R and second row F F′ B B′. The labels: first row has labels U D L R visible; second row labels F B. So it wrapped. Odd given the math. Maybe flex-wrap happened because .row has flex-wrap:wrap and total width was over 1180? The panel max-width is calc(100vw - 20px) = 1180, and padding 14 each side... So ~826 should fit. Unless the DOM output is just listing reading order and not wrapping... The screenshot clearly shows two rows. Maybe buttons are wider than I think (min-width 44, padding 9+12, font 13 → "U′" text width maybe 20). 44+24+... about 48-50. Hmm.

Wait — the labels `.row .lbl` width 26 but the first row in the screenshot shows "U  U′  D  D′  L  L′  R  R" and there's a stray "R" and "F" at the end — the DOM text list shows: U U U′ D D D′ L L L′ R R R′ F F F′ B B B′. In the screenshot, the first row ends with "R" at the far right and "F" at the start of second row. So the labels are the "U D L R F B" single letters. In the screenshot the first row displays U, U′, D, D′, L, L′, R, R — hmm, that's 8 buttons but there are 12. Confusing; it's fine — it wrapped.

Let me reduce: make label smaller, remove min-width, reduce gap, and reduce panel padding. Or place the panel at bottom-left/right? Simplest robust: make the panel a horizontal-scroll-free compact layout: put labels inline as part of a compact grid. Alternative: drop the standalone labels and put the move letter inside the button (they already have: "U", "U′"). Labels "U", "D" are redundant! The button already shows the letter. Remove the label spans entirely → 12 buttons + gaps: 12*48 + 11*7 = 576+77 = 653. Fits easily. 

Let's do that.

Also fix framing: lookAt(0, -0.8, 0) and maybe increase distance to 9.0.

Also: the cube's sticker colors — green appears teal-ish, that's the color 0x009b48 (standard green). Fine. Red looks pinkish 0xb71234. Fine.

Also the lighting gives some shine. OK.

Let me also check the `pending !== lastPending` HUD update: lastPending initialized 0 and only updated in that block, so updateHud is only called when pending changes — but moveCount changes also need HUD. Let me just call updateHud() every frame (cheap? it does isSolved which iterates 26 cubies * 3 stickers = 54 entries, snapshot creation every frame—allocating objects. That's fine at 60fps but wasteful. Better: update HUD only when state changes: when a move finishes, when queue length changes, or on reset. I'll track a signature: moveCount + queue.length + animating flag. Let me implement updateHudSig comparing `${moveCount}|${queue.length}|${animating?1:0}`.

Let me make these edits.

The CSS edit failed because the two blocks were adjacent (row and lbl) — I included both in one oldText with a newline, maybe not matching. Let me check the file for that region.

Actually the error is about edits[2] — the CSS ones succeeded? No: edits are validated individually; errors list only edits[2] meaning edits 0 and 1 matched... but they'd be applied only if all pass? Probably the whole edit failed. Let me read the relevant portions.

The CSS text uses two-space indentation and my oldText started with two spaces "  .row{...}" — should match. Line 55 starts with two spaces. Hmm, edits 0 and 1 apparently matched (only edits[2] failed). edits[2] was the panel HTML — probably because leading whitespace in HTML differs (6 spaces?). Let me just do edits individually with proper indentation from the file.

Let me apply the remaining edits now (CSS + camera) and then do HTML separately.

Now fix HUD update logic to be state-signature based. Let me look at the frame loop and updateHud calls.

Current:
```
function frame(now){
  const dt = Math.min(64, now - last); last = now;
  stepAnimation(dt);
  const pending = queue.length + (animating?1:0);
  if (pending === 0) cubeGroup.rotation.y += 0.0000; // (no idle spin)
  applyCamera();
  renderer.render(scene, camera);
  if (pending !== lastPending){ updateHud(); lastPending = pending; }
  requestAnimationFrame(frame);
}
let lastPending = 0;
```

Replace with signature check including moveCount.

Also remove the silly `if (pending === 0) cubeGroup.rotation.y += 0.0000;` line and the unused scrambleSeq array.

Oops, my second edit just re-added the same scrambleSeq line (it was already there, so oldText "function scramble(n){" matched and I replaced with the same plus prefix — resulting in duplicate?). Let me check.

The button row still wraps (B′ on second row). Also the bottom face of the cube is now hidden behind the panel. The panel is quite tall (3 rows). Let me shrink the panel: make the move rows more compact by removing the "wide" second row and merging everything into fewer rows? Actually let me restructure: single row with all 12 move buttons + a second row with the action buttons. To fit 12 buttons on one row I need smaller buttons: min-width ~34px, gap 5px, padding 8px → 12*(34+? ) ≈ 12*40+55 = 535. That should fit in 1180. But it wrapped even with ~50px buttons. Hmm — why?

Oh! `#panel` has `max-width:calc(100vw - 20px)` = 1180, but the panel is `position:absolute; left:50%; transform:translateX(-50%)` — width is determined by content (shrink-to-fit within max-width). Content width determination... shrink-to-fit should be min(preferred, max-width). So the row should fit.

Unless... the viewport of the browser tool is 1200 wide but the page renders at a smaller iframe width? The screenshot is 1200x800. Panel looks like ~700px wide in the screenshot. Let me measure element widths via the DOM/inspect. Actually the issue may be `text-shadow`/font size making "U′" wider. Let me just measure.

Also fix framing: cube is a bit too large / panel overlaps bottom. Let me increase distance to ~9.6 and rely on CAM_TARGET_Y.

Let me inspect element bounding boxes via JS in the console... The browser tool doesn't have an "evaluate" action, but I can use console messages? I can't run arbitrary JS... Actually I can via `type`? No. Hmm. Let me check the tool: actions are reload, inspect, screenshot, motion, click, drag, key, type, scroll. No eval. 

But `__cube` API exists; I can't get output though. Hmm, inspect gives DOM dump. 

Alternative: reduce the panel to fit more robustly by design: use a compact grid layout where the 12 move buttons are in a fixed 6-column grid (2 columns per face pair = 12 items in 2 rows of 6) — that's tidy and wraps intentionally. Let me restructure the panel:

Row A: 6 columns × 2 rows: U U′ / D D′ / etc.? Better: a grid with 6 columns, each column holding [letter button, prime button]:
```
[U][U′][D][D′][L][L′]
[R][R′][F][F′][B][B′]
```
That's 12 buttons in 2 rows of 6 — compact and predictable, each ~44px → 6*44+5*5=289. 

Then action row: Scramble, Reset, Recenter — total ~ 400. So panel width ~330px. Good, much narrower, leaving the cube fully visible.

Framing: panel would then be ~ 2 rows of 34px + action row 40 + hint ~ = ~150px tall. The cube at dist 9 with target -0.9: screen half-height = 9*tan(22.5)=3.73 at the target plane. Cube bottom point at world y=-1.73 (bottom corner) → offset from target = -0.83, i.e., 0.83/3.73 = 22% below center → in pixels 0.22*400 = 89px below center; center is at 400px (viewport 800) → bottom corner at 489px. Panel top at 800-16-150 = 634px. So the cube fits above the panel. 

Let me restructure the HTML panel into a grid.

Also the "Recenter view" text is long; at 360px wide panel with 3 wide buttons it will wrap to 2 rows — that's fine (flex-wrap). Let me shorten to "Recenter". Actually keep "Recenter view" but it may wrap; fine.

Let's reload and screenshot.

The panel is now compact and the cube is fully visible (white/green/red + white top). The bottom face isn't visible from this angle but the cube is fully in frame, not clipped by the panel.

Now let's verify the functional checks. I'll click buttons and screenshot:
1. Click F, wait, click F′, verify solved appearance.
2. Orbit: drag on background.
3. Zoom: wheel.
4. Scramble then Reset.

I need to click buttons. The browser click needs coordinates. From the screenshot at 1200x800: the F button is in the grid, row 2, 3rd column. Panel is centered at x=600, width 360 → x from 420 to 780. Grid: 6 columns with gap 5 over width 360-20=340 → each col ≈ 51.7. Row 1 y: panel top = 800-16-panelHeight. Panel height ≈ 10+34+5+34+5+40+~ (Recenter row) + hint... Let's estimate panel height ~ 160. So panel top ≈ 624. Row1 buttons y ≈ 624+10+17 = 652. Row2 y ≈ 652+39=691. Actions row ~730, Recenter ~765.

Rather than guess, let me use the DOM inspect to get positions. The inspect action gives DOM but maybe not coordinates. Let me try `inspect` and see.

Actually the click tool takes x,y. Let me try clicking F at (545, 691) — column 3 spans x 420+2*(51.7+5)=534 to 585. Center ≈ 559. Let me instead use keyboard: press "F" key, then Shift+F. The keydown handler uses e.key.toUpperCase() and e.shiftKey. Pressing shift+f with the `key` action: I can send text "F" maybe with shift. Simpler: use keyboard shortcut "f" then "F" (uppercase with shift). Let me try key action with text "F" — does key accept text? Parameters: action, text. Probably sends keydown with text. Let's try clicking via coordinates — more deterministic and tests the buttons.

Let me get exact coordinates first by inspecting the DOM — maybe inspect returns positions.

Now let me test via clicking. I need coordinates. Let me use keyboard instead — but the `key` action likely dispatches with a specific key. Let me try clicking at estimated coordinates and see if moves counter changes (visible in DOM inspect / pills).

Panel: width 360, centered → x 420..780. Padding 10 → grid area x 430..770, width 340, 6 columns gap 5 → col width = (340 - 5*5)/6 = (340-25)/6 = 52.5.
Column centers: 430 + 52.5*(i+0.5):
i=0: 456.25, i=1: 508.75, i=2: 561.25, i=3: 613.75, i=4: 666.25, i=5: 718.75.

Panel vertical: bottom 16 + height. Let me estimate height: padding 10 top + grid row1 34 + gap 5 + grid row2 34 + gap 8 + acts (may wrap into 2 rows: 38 + 6 + 38=82 if wrapped) + gap 8 + hint ~16 + padding 10. If acts wraps: total ≈ 10+34+5+34+8+82+8+16+10 = 207. Panel top = 800-16-207 = 577.
Row1 button center y ≈ 577+10+17 = 604. Row2 ≈ 604+52.5 = 656. Acts row1 ≈ 577+10+34+5+34+8+19 = 687. Reset at same row (2nd). Recenter row ≈ 687+6+19=712? Hmm hint after.

Rather than guess, use keyboard shortcuts which are deterministic: press "f" then "f" with shift? The key action with text — let's test with "f" and check the Moves pill becomes 1.

I'll use the `key` action with text "f".

The F turn worked. The F face moved: top row of the F face now shows orange (from L), the R column's middle shows white (from U). Let's verify: F clockwise viewed from front: U bottom row → R left column → D top row → L right column → U. In the image, the right face's middle-left column shows white stickers — yes, the R face has 3 white stickers in the left column. Correct.

Now press shift+f for F'. Can the key action include modifiers? Let's try text "F" (uppercase) — the handler's shiftKey would be false, giving F again. Hmm. Instead use the F′ button click. Let me compute coordinates for the F′ button: it's column 5 (index 4) in row 1? Grid order: row1: U, U′, D, D′, L, L′ (columns 0-5); row2: R, R′, F, F′, B, B′. So F′ is row 2, column 3. Column center x = 430 + 52.5*3.5 = 430 + 183.75 = 613.75.

Row 2 y: need panel geometry. Let's use the inspect action to get more DOM info; maybe it includes bounding boxes. Let me try "inspect".

No coordinates given. I'll estimate F′ button position from the screenshot. The panel in the 1200x800 image: panel spans roughly x 420..780 (360 wide). Grid rows: from the image, the "Recenter view" button is around y=712 and the hint around y=735; panel bottom at 784; panel top around 577.

Let me estimate visually: the acts row (Scramble/Reset) appears at y≈688, Recenter at y≈717, hint y≈740, panel bottom edge y≈760? Hmm, bottom:16 → panel bottom = 784.

Let's compute: hint text height ~14, gap 8 → acts block ends at 784-10-14-8 = 752; two act rows: row2 (Recenter) ends 752, height 38 → starts 714; gap 6 → row1 ends 708, height 38 → starts 670; gap 8 → grid ends 662; grid row2 height 34 → starts 628; gap 5 → row1 ends 623 → starts 589; padding 10 → panel top = 579. Good matches my earlier estimate.

So F′ button: row 2 starts 628, center y = 645; column 3 center x = 613.75. Let's click (613, 645).

After clicking F′, the cube should return to solved (Moves 2, Solved).

The click didn't register (Moves still 1). My y estimate was off. Let me find the actual button position by using a different approach: measure via an overlay? I can't run JS.

Alternative: I could make the app expose button positions in the DOM (e.g., add data attributes with client rect). But the browser tool's inspect doesn't show attributes.

Hmm, maybe the click coordinates are relative to the viewport 1200x800 and my estimate should be right... but the panel's exact height depends on font rendering. Let me try scanning: click at a few y values in column 3 to find a button. Actually better: temporarily enlarge the hit areas? Instead, let me add a debug mode: set an id on each button with its bounding rect appended as text in the title attribute — the DOM dump might show title? Unlikely.

Better approach: the `type` action can type text into an input — no inputs exist. The `key` action sends keys with text; can I send shift? Maybe text "F" with shift key state... Let me check if the key action accepts a modifier. No, just text.

Idea: modify the app to treat plain 'f' as F and 'F' (uppercase) as F'. Then I can press "F" to apply F'. But better: use a key mapping where uppercase letter = inverse. Since the keyboard handler uses e.shiftKey, and the key action with text "F" probably produces key="F" with shiftKey false. Let me change the handler: inverse if (e.shiftKey || e.key !== e.key.toLowerCase()). That's a nice fallback and lets me test with "F".

Let me implement that, plus add a small debug hook that logs button rects into the DOM? Actually, I can append the rect info to the document title or into an element's text so the DOM inspect shows it. Let me do that: after layout, write to a hidden element `#dbg` with text like "F':x,y,w,h" list. The DOM dump may show hidden text? The DOM dump showed all text nodes. If I set the element's textContent with all button rects, I'd see the coordinates in the inspect dump. Let me add that temporarily (and keep it — it's harmless if hidden... but it would appear in the DOM text dump; better to remove after).

Let's do it: add a debug function that computes rects and writes them into document.title (title may not be in DOM dump). Let me instead put them in a hidden div and check the inspect output; then remove.

Plan:
1. Change key handler for uppercase = inverse.
2. Add temporary debug dump of button rects in a hidden div.
3. Reload, inspect to get coordinates.

Let me implement both edits.

Now I have exact coords. F button is at (571, 624) center; F′ at (629, 624).

Test plan:
1. Click F (571,624) → scramble state; screenshot.
2. Click F′ (629,624) → should be Solved, Moves 2, and appearance back to start.

Let me click F then wait, then click F'. The tool's click is instantaneous; the animation takes 150ms and the queue processes. Clicking both rapidly queues both. The screenshot right after may catch mid-animation. I'll click F, then click F′, then screenshot — the DOM will show Solved once both complete. But the screenshot is taken at the same time as the DOM. Let's see; if needed I'll take another screenshot after.

Moves still 1 — the F′ click didn't register? The DOM says Moves 1 and Scrambled. Hmm. Both clicks at x=629,y=624. Note that the `motion`/`click` may need the pointer to be over the element — the canvas has pointer capture? Wait: after clicking F, the canvas had pointerdown? No, the click was on the button, not the canvas. But #panel is above the canvas... Actually the click lands on the button, and the panel's click handler runs. But the canvas is a full-screen element and the panel is on top — the click coordinates hit the button, so the button should get it.

Hmm, but maybe the issue: the screenshot/DOM is captured immediately after the click event is dispatched, before the animation completes and before the HUD updates (HUD updates only in the rAF loop via signature). The F click at that time showed Moves 1 — meaning that click had already completed. For the second click, DOM was captured synchronously right after dispatch, so updateHud hasn't run yet (queue=1 enqueued, animating null → sig '1/1/0' vs last '1/0/0' → would update on next frame). So the DOM shows stale "Moves 1".

Let me take another screenshot (screenshot action alone) to see the state after the animation.

Still Moves 1 and Scrambled — the F′ click truly did not register. Why? The F button click worked (Moves went 0→1). The F′ click at (629,624)... 

Wait — after the F move, the cube state changed and the pill "Scrambled". But the click at x=629,y=624 — maybe the panel/listener `e.target.closest('button')` works... unless the click event target is the canvas because of pointer capture? No.

Hmm, maybe the issue: the click happened but the button was under an overlay? Or maybe the browser tool's `click` simulates pointerdown/pointerup but the canvas has `touch-action:none` and the body... Let's think about the first click: it worked. The second click at nearly the same place failed. Difference: the button is different (F′ vs F). Both are siblings.

Oh wait! Maybe the second click DID work, but then... no, Moves would be 2.

Possibility: the browser tool's click includes a pointerdown which sets pointer capture on the canvas? No, pointerdown on the button doesn't reach the canvas.

Hmm, but actually: does the browser tool dispatch a `click` or mousedown/mouseup? If it dispatches only mousedown/mouseup without a `click` event, the first click wouldn't have worked either. It did work (Moves 0→1).

Alternatively, the second click was dispatched at a moment when the F animation was still running and the panel had `pointer-events`... no.

Wait, maybe the click coordinates: button F′ at x=603..655, y=605..643. Center (629, 624). That's right. But the first click I did at (571,624) which is F's center (545..597). Good.

Unless... after the first click the app's HUD changed layout? No.

Hmm, could it be that the *second* click was swallowed because the browser harness's click includes a `mousedown` on the canvas due to focus? Let me test clicking F′ again now (state is currently F applied, Moves 1, Scrambled).

Actually wait — maybe the issue is that the click at (629,624) hit the F button because... no.

Let me just click F′ again and then screenshot.

Still Moves 1. So the F′ button click is consistently not registering. Why would F work but F′ not?

AH — I bet the browser harness's `click` dispatches pointerdown/mouseup but the *click* event target is computed... no.

Another thought: maybe the harness's click does `mousedown` then `mouseup` at the same coordinates, and the browser generates a `click` event on the common ancestor of mousedown/mouseup targets. If mousedown happened at (571,624) [F] and mouseup at (629,624) [F′]... no, both at same point.

Wait — maybe the issue is that the *first* click's mousedown set focus/active state and the panel is still in `:active`... irrelevant.

Hmm, what about `pointer-events`? The panel has backdrop-filter. Both buttons in the same panel.

Let me reconsider: did the first click really register on F? Moves went 0→1 and the cube visibly turned F (the image showed F turn). Yes. Could that have come from the keyboard? No.

So the click mechanism works. The difference must be the target. Is there something overlapping F′? The `#dbg` div is at left:-9999px — no.

OH WAIT. I know! The `click` handler on `#panel` uses `e.target.closest('button')`. That's fine for both.

Hmm, is it possible that the *second* click is being captured by the canvas because of `setPointerCapture`? The canvas only gets pointerdown if the pointerdown target is the canvas. The pointerdown at (571,624) was on the F button... unless the browser harness dispatches events to the element under the coordinate — for the first click, the element under (571,624) is F.

Let me test clicking a different button, e.g., R′ at (514,624) to see if any other button works. If R′ works, then something's weird specifically with F′.

Actually! Maybe the issue is the prime character "′" (U+2032) — no, the handler uses dataset.

Hmm, let me reconsider the coordinates. Rects: F:545,605,52x38 → x range 545-597, y 605-643. Center (571, 624). F':603,605,52x38 → 603-655, center (629,624). Right.

Unless the browser tool's click coordinates are relative to a scaled viewport (e.g., the iframe is 1200x800 CSS but the tool maps to device pixels). If there's a scale factor, both would be offset equally. The F click worked at (571,624), so the mapping is accurate.

So why does the F′ click fail? Let me think about the harness's click implementation: it might dispatch `pointerdown`, `mousedown`, `pointerup`, `mouseup`, `click`. The canvas has `setPointerCapture` on pointerdown... but for the F button, pointerdown target is the button; capture is called on the canvas only when the canvas receives pointerdown.

Unless... the harness dispatches ALL pointer events to `document.elementFromPoint(x,y)`. Fine.

Wait, maybe the harness's click on a button inside an element with `backdrop-filter` creates a new stacking context... no.

Let me look at this from another angle: maybe the F′ click DID enqueue, but the state was already... no, Moves would be 2.

Hmm! Unless the click at (629,624) landed on the *canvas* because the panel scrolled or shifted. Did the panel move? The rects in the last inspect: F':603,605 — the same as before. So the button is at the same position. And the click at (629,624) should hit it.

Unless the click coordinates in the tool are in the *screenshot image* coordinate space, and the image is scaled. The screenshots appear to be 1200x800 (the tool says coordinates use a 1200×800 viewport).

Let me test with a keyboard press for uppercase F (which now means F′ thanks to my edit): press "F". If Moves goes to 2 and Solved appears, the button handler path is the issue... but the keyboard path uses the same enqueue. That would confirm the physics is fine and isolate the click.

Let me try that.

Interesting! The F′ button now shows as focused/highlighted (it appears pressed in the screenshot — the F′ button has a lighter background). That means the clicks DID focus the F′ button (focus follows mousedown), but the `click` event handler didn't fire!

So the harness dispatches mousedown/mouseup but maybe not a `click` event... but then how did F work? Ah — F was clicked and it worked. Hmm, unless the F move came from the key press "f" earlier? Let's recall: I pressed key "f" earlier and Moves went to 1 — that was the F move! Then the click at (571,624) on F didn't register (Moves stayed 1), and I misattributed it. Yes! The key press "f" caused Moves 1.

So the harness's `click` action does NOT dispatch a real `click` event (or it dispatches mousedown/mouseup only). The F′ focus highlight confirms mousedown happened.

Solution: use `mousedown`/`mouseup` listeners on the panel instead of `click`, or add both. Since real browsers do fire click, but for the harness, I'll listen for `mousedown` (and also `click` guarded to avoid double). Approach: handle on `pointerdown`/`mousedown` and dedupe by ignoring a `click` that follows within 400ms of the last handled mousedown. Actually simpler: handle only `mousedown` — real users' clicks also trigger mousedown, so behavior is preserved (moves register on press, which feels responsive). I'll add `onmousedown` handler and remove the click listener... but keyboard Enter/Space activation on a focused button fires `click` without mousedown. To be safe, handle both with dedupe.

Let me implement:

```js
let lastHandled = 0;
function onPress(b, e){
  const now = performance.now();
  if (now - lastHandled < 350) return;   // avoid double-fire from click after mousedown
  lastHandled = now;
  ...handle...
}
panel.addEventListener('mousedown', e=>{ const b=e.target.closest('button'); if(!b) return; e.preventDefault(); onPress(b); });
panel.addEventListener('click', e=>{ const b=e.target.closest('button'); if(!b) return; onPress(b); });
```

Wait, if the harness sends mousedown then mouseup then no click, onPress fires once. If a real browser: mousedown → onPress, then click → within 350ms → deduped. Good.

But careful with `e.preventDefault()` on mousedown: it prevents focus. Not important.

Now let me also double check the state: currently Moves 1 with F applied (from key 'f'). Then key 'F' (uppercase → F′) just now — did that work? Moves is still 1, so the uppercase key press didn't register?! Hmm. The screenshot shows F′ highlighted (from the earlier clicks) but Moves 1.

Wait, the key action with text "F": maybe the harness sends key "f" plus shift? Or maybe it sends keys as individual characters 'F' with key="F" and shiftKey true → inverse. Either way Moves should be 2.

Unless... the keydown handler's condition `(e.shiftKey || e.key !== e.key.toLowerCase())`: if the harness sends key='F' with shiftKey=true → inverse F′. Moves should be 2. But it's 1. So the keypress didn't register at all!

Hmm, so maybe the last `key` action dispatched a keydown on a focused element (the F′ button) and... buttons don't handle keys. My window keydown listener should still fire via bubbling.

Unless the harness's key action types text into a focused editable element, and for a focused button it does nothing? Or maybe the harness dispatches `keypress`/`beforeinput` only.

Earlier the "f" key press DID work (Moves 0→1). So key events work. Maybe uppercase "F" gets normalized... Let's think: if the harness dispatches keydown with key='F' and shiftKey=true, my handler computes k='F', MOVE_KEYS includes 'F', enqueue F′ → Moves 2. Not 2.

Alternatively the harness might send text 'F' as `keydown` with key='F' and shiftKey=false. Then my new condition `e.key !== e.key.toLowerCase()` → 'F' !== 'f' → true → enqueue F′ → Moves 2. Still should be 2.

So the key action with "F" did nothing. Maybe the harness only accepts lowercase single chars and ignores others? Earlier "f" worked.

Let me test pressing "f" again — if Moves goes to 2 (F again), key events still work.

Actually, hmm: maybe the second key press was swallowed because the F′ button had focus and the harness's key action requires... let's just test with "f".

Actually simpler: fix the mousedown handler, then use button clicks for everything. Let me do that.

Also note: the earlier assumption that F was clicked — now I realize the key 'f' did it. Fine.

Let me implement the mousedown fix.

Still Moves 1! The F′ click at (629,624) again didn't register, while F at (571,624) did. There must be an actual element blocking x>600 at y=624... The `#status` pills? No, they're at top.

Hmm wait — the F′ button IS highlighted/focused in the screenshot (it appears with a lighter background — the :hover/:focus state). Yes, in the last screenshot F′ looks highlighted. That means the pointer is over it (hover), so mousedown landed on it.

But mousedown handler didn't fire?? Unless... `e.preventDefault()` then `pressButton` — the mousedown listener is on `#panel`. F′ is inside the panel. So it should fire.

Unless the harness's click is: `mousedown` at (x,y) then `mouseup` at (x,y) — with `mousedown` dispatched... The F button got focus in the earlier screenshot, meaning mousedown reached the button.

Hmm, wait. Is it possible that both clicks actually did fire, but the second one was blocked by my dedupe? `lastPress` — F click at time T sets lastPress=T. F′ click at T+~1s → now - lastPress > 400 → not deduped. Unless... the harness sends mousedown AND click, and... no, F worked once.

OH WAIT. I see it! `pressButton` is called from the mousedown listener. But what if the harness's click action dispatches: mousedown, mouseup, click — and my earlier dedupe test... let me check: could `performance.now() - lastPress < 400` reject? Only if two presses within 400ms.

Hmm, let me reconsider: maybe the F′ click DID enqueue F′, but then... the queue processes F′ and Moves becomes 2, and the pill would show 2. It shows 1.

Unless the click is landing on F again! Consider: the harness click might use the coordinates from the *last mouse position* or dispatch at the element under the point at a scaled resolution. F is at 545-597, F′ at 603-655. If there were a +? offset, clicking F′ at 629 might land on F... but then Moves would be 2 anyway (F again).

So no move was registered at all for the F′ click. But the button shows hover highlight.

Hmm, actually — maybe the highlight is `:focus` from the earlier mousedown (I clicked F′ three times before the fix; the last screenshot shows F′ still focused). And the cube shows F applied. In the very latest screenshot, F′ has a focus ring? Let me compare: in the pre-fix screenshots, F′ looked highlighted after clicks. Now after reload, F′ appears highlighted... wait, in the latest screenshot (after reload), F′ shows as highlighted BEFORE any clicks?? Let me look at the screenshot after reload: F′ is at row2 col3 — in the screenshot it appears... I see "F′" with a lighter background? Hard to tell. In the screenshot right after the F click, F′ looks highlighted — that's from the click's hover/mousedown.

Hmm, is `:hover` from the mouse position? The harness may move the mouse to (x,y) then click. So after clicking F, the mouse stays over F.

Let me try a different approach to determine what's happening: use the Reset button (at 658, 670) — if clicking Reset works and clears state to "Solved, Moves 0", then button clicks work generally. Then click F′ again from a clean state and screenshot immediately to see whether the arrow changed.

Actually, better: let me add a debug text in #dbg that reports the last press (button id + timestamp + moveCount). Then I can see exactly what happened.

Let me update dumpRects to also include lastPress info, and call it periodically (e.g., every 300ms) so it shows the current state.

Very interesting: PRESS F' n=2 — so pressButton WAS called twice (mousedown + click, as expected in a real browser), but the second was deduped. Yet Moves is 0 and the cube is solved! Wait — n=2 means pressButton ran twice: mousedown (handled, enqueued F′) and click (deduped). So one F′ WAS enqueued. But Moves shows 0 and state is Solved?!

Wait... maybe the first call was deduped and the second handled? No: lastPressHandled starts 0, first call handles (enqueues F′), second call within 400ms → deduped. So F′ was enqueued. Moves should be 1 after the animation.

But the DOM shows Moves 0 and Solved. And the debug `q=0 busy=false`. Hmm, the dumpRects runs every 400ms — so it captured after the animation finished (150ms). Moves should be 1 then. Unless... the `updateHud` isn't updating!

AH WAIT. I see the bug! In `frame()`:

```js
const sig = moveCount + '/' + queue.length + '/' + (animating ? 1 : 0);
if (sig !== lastSig){ lastSig = sig; updateHud(); }
```

That should work. Unless `updateHud` throws! `isSolved()` → snapshot() → uses `cellKey`... it worked before (the pills updated earlier: Moves 1 after the F key press).

Hmm, but the earlier tests showed Moves 1 after the F keypress. So updateHud works.

So... the F′ press was enqueued and then the move completed → Moves 1. But the pill says 0. Unless the F′ move RESET the count? No.

Hold on. Is it possible the first pressButton call deduped (because now - lastPressHandled < 400 with lastPressHandled=0 → now is performance.now() since page load, maybe < 400ms if the click happened quickly after load!). YES! That's it! `lastPressHandled = 0`, and `performance.now()` is only ~small if the click occurs within 400ms of page load. But the reload happened seconds ago... Hmm, performance.now() at the time of the click: the page reloaded, and I clicked maybe 10+ seconds later, so performance.now() > 400.

Hmm, unless `performance.now()` is reset... no.

Wait, but n=2 and the enqueue happened on the FIRST call. So Moves should be 1. Unless the second call was NOT deduped and handled → enqueue twice → Moves 2? It says 0.

Unless neither was handled... but then lastPressHandled would remain 0 and both would fail the dedupe test? No: if now - 0 < 400 fails only when now < 400.

Hmm, what if performance.now() is small because the page just loaded? The reload → screenshot → click. Time between reload and click includes tool round-trips (a few seconds). So now > 400ms.

OK so what if BOTH calls were handled → F′ enqueued twice → Moves 2, and then... the pill shows Moves 0? That contradicts.

Wait, maybe the pill text is stale because updateHud's signature never changed! Let's trace: after the F′ moves complete, moveCount becomes 2. The sig '2/0/0' !== lastSig → updateHud() → pillMoves shows 2. Unless updateHud threw an exception. What could throw? `isSolved()`... 

OH NO. I see it! In `updateHud`, `pillState.className = 'pill' + (solved ? ' solved' : '')`. Fine. `pillQueue.innerHTML = 'Queue <b>' + ...`. Fine.

Hmm, what about `pressButton` → `enqueue` → `updateHud` → isSolved → snapshot. Fine.

Let me reconsider: maybe the click DID enqueue F′, the move ran and finished, and the debug dump I see was captured BEFORE the move finished... but it says busy=false q=0 and Moves 0. If the move had been enqueued and finished, Moves=1.

Actually hold on — maybe the DOM dump is captured at the same instant as the click dispatch, i.e., BEFORE the rAF loop runs (the dump is taken synchronously right after dispatch). The tool seems to capture the DOM synchronously with the action (Frame 1, +0ms). The dumpRects interval (every 400ms) updates #dbg text — the DOM dump shows the last interval update. The last interval update could have been before the click (Moves 0 from the initial state).

Timeline: reload → interval dumps at t=400ms, 800ms, ... → click at t≈2s → dump happens synchronously? No — dumpRects runs every 400ms via setInterval, so the text updates within 400ms of the click. But the DOM is captured immediately at click time, showing the text from the previous interval run (before the click). BUT the PRESS F' n=2 text IS in the dump! So dumpRects ran AFTER the click. So dumpRects ran after pressButton, and reported busy=false q=0 — consistent with the move having already completed (150ms) — but Moves 0?!

Unless the enqueued move... Let me check: `enqueue([b.dataset.move])` — b.dataset.move for F′ is "F'". MOVES["F'"] is undefined! In `enqueue`, `if (!MOVES[m]) continue;` — F' is not in MOVES! The MOVES keys are U, D, L, R, F, B WITHOUT primes!

That's the bug — inverse moves were never enqueued! In my earlier design I had `instant()` which... also just enqueues. And MOVES only has base keys. So F′ (with prime) is silently dropped. That's why Moves stayed 0!

And the F key press earlier worked because 'f' → MOVES['F'] exists. And the key 'F' (uppercase) earlier didn't work because... it should have enqueued "F'" → dropped. Yes! That explains everything.

Fix: MOVES should include primed keys, or enqueue should normalize. Better: make MOVES entries for both: MOVES[m] and MOVES[m+"'"]. Let me restructure: define base moves, then add primed variants with negated angle. But careful: `startMove(name)` uses MOVES[name]. Let me build:

```js
const MOVES = {...base...};
for (const k of MOVE_KEYS){ MOVES[k+"'"] = {axis: MOVES[k].axis, layer: MOVES[k].layer, angle: -MOVES[k].angle}; }
```

That's the clean fix. Also instant() works then.

Great catch. Let me fix it now.

Also the F′ move was silently dropped → state stayed solved → the earlier "F then F′" test was invalid. Let me fix and retest.

Also I should verify the queue-based inverse behavior properly.

Let me apply the fix.

F then F′ → back to "Solved", Moves 2, and the cube looks identical to the start. 

Now let's test:
1. Scramble → check it's scrambled and moves count increments.
2. Orbit drag on the background → camera changes (verify via drag and screenshot).
3. Wheel zoom.
4. Reset → solved + initial framing.

Let me test scramble (487+55=542, 670).

Scramble is running (queue 22, moves animating one by one). Let me wait a couple of seconds and take a screenshot to see the scrambled state.

I'll wait via a bash sleep and then screenshot.

Scramble finished (24 moves total: 2 + 22). The cube is scrambled with all six colors visible.

Now test orbit: drag on the background (e.g., from (200,300) to (500,200)) and then screenshot to see a different angle.

Note: `drag` action takes x,y,toX,toY presumably.

The camera orbited — now we see the blue (back) face and the yellow (down) face, plus the front. The cube state is unchanged (same scramble) — good, orbit doesn't turn faces.

Hmm, the drag orbited quite far (phi changed and theta). The cube appears the same size and stays in frame. 

Now test wheel zoom. Then Reset. Let's zoom in (negative deltaY) and then zoom out to check bounds.

Reset restored the solved appearance AND the initial framing/camera (identical to the first screenshot).

Now let me verify the deeper state correctness: after scramble + reset, all cubies are home; and after a sequence like R U R' U' repeated (sexy move × 6) the cube returns to solved — that's a strong state-integrity test. Let me use the debug channel. I can add state info to the #dbg div: whether all cubies are at home + quaternion identity, and the current solved status. Then I can run sequences via keyboard presses and read the dump.

Actually, simpler: expose in dumpRects the count of cubies at home orientation identity... but the "solved" pill already reflects the sticker arrangement.

A stronger test: apply the "sexy move" (R U R' U') six times → should be solved. I can do this with 24 key presses but that's a lot of tool calls. Alternatively I can add a hidden "self-test" button that runs a scripted sequence and reports the result in the debug text. That's a neat approach: add a temporary (or permanent, harmless) self-test that runs random move sequences and verifies inverse pairs + full cube group identities, reporting pass/fail in the pill or #dbg.

Let me add a proper self-test function to the __cube API (runSelfTest) that:
- starts from solved,
- for each of the 12 face moves: apply m then m' → check snapshot equals initial.
- apply random sequences and their inverses → check solved.
- apply (R U R' U') × 6 → solved.
- check that 4 repeats of a quarter turn return solved.

Then I need to see the result. I'll write the result into the #dbg div text (visible in inspect) — good for verification. And keep the test available via console.

Let me implement it and call it on load (async). It uses enqueue + waiting for the queue to drain. The test should run with animations disabled for speed? It uses the real queue with 150ms per move; 12*2 + 6*4 + 6*4 = 24+24+24 = 72 moves ≈ 11 s. That's a bit slow but OK. Alternatively, temporarily speed up: I'll run the test with TURN_MS... simpler: let the test set a fast mode by directly manipulating? Let me just add an internal "fast" flag that sets duration to 1ms for test moves.

Simplest: add `__cube.run(moves)` that awaits queue drain (already implemented). Add a self-test that runs after a delay and writes results. To speed it up, I'll temporarily set TURN_MS to 0 during the test (make TURN_MS a `let`). Actually `dur:TURN_MS` reads the variable at startMove; if I set TURN_MS = 0, then division by zero → raw = NaN → min(1, NaN) = NaN... Let me use `Math.max(1, TURN_MS)`.

Let me implement:

```js
let TURN_MS = 150;
...
animating = { spec, name, pivot, parts, t:0, dur: Math.max(1, TURN_MS) };
```

And the self-test:
```js
async function selfTest(){
  const log = [];
  const ok = (name, cond)=> log.push((cond?'PASS ':'FAIL ') + name);
  const wait = ()=> new Promise(res=>{ const d=()=>{ (!animating && !queue.length) ? res() : requestAnimationFrame(d); }; requestAnimationFrame(d); });
  resetCube(); await wait();
  // 1. inverse pairs
  for (const m of ALL_MOVES){
    const inv = m.endsWith("'") ? m.slice(0,-1) : m + "'";
    resetCube(); await wait();
    await __cube.run([m, inv]); await wait();
    ok('inverse pair '+m+' '+inv, isSolved());
  }
  ...
}
```
Careful: resetCube also resets the camera; that's fine.

Also test: 4x same move = solved. And random sequences with inverses. And a full scramble then check not solved (probabilistically) and that the sticker count is right.

Also verify that after the test the cube is left solved and the camera restored — I'll call resetCube at the end.

This will take ~ (12 pairs * 2 + 4 + 4 + random 20*2...) moves. With TURN_MS=0 during the test, it's fast.

Let me write it to run automatically ~1s after load and dump results into #dbg. Then I'll read via inspect.

Note: run() returns a promise that resolves when drained; good.

Let me implement now. Also remove the temp debug stuff at the end (dumpRects, PRESS line, #dbg div) after verification — but I need #dbg to read results during the test. I'll keep the debug temporarily and remove it before finishing.

Also: I should double check that `mousedown` handler doesn't break real usage — pressing a button triggers the move on mousedown, and the subsequent click is deduped within 400ms. Good. But there's a subtle issue: if a user presses and holds a button for >400ms then releases, the click event would fire a second move. Rare; acceptable. Better: track the specific button element for dedupe:

```js
let lastPressBtn = null, lastPressHandled = 0;
// on mousedown: lastPressBtn = b; handle
// on click: if (b === lastPressBtn && now - lastPressHandled < 500) return; handle
```
This is more robust. Let me implement that.

Let me now write the code changes.

Now I need to define `run` before use (function declaration hoisting works since `function run(...)` is a function declaration inside the IIFE — yes, hoisted).

Also `ALL_MOVES` is defined. `scramble` is a function declaration, hoisted. `TURN_DUR` is declared with let before use at runtime. But `selfTest` is defined in the object literal at the end, so it's fine.

Also need to report the self-test result in the DOM. Let me add to dumpRects the last self-test result, and run the self-test automatically on load.

Let me update the debug section:

```js
let selfTestResult = 'not run';
setInterval(dumpRects, 400);
```
And add to dumpRects: ' || ST: ' + selfTestResult.split('\n')[0].

And run the test at load: 
```js
setTimeout(()=>{ __cube.selfTest().then(r=>{ selfTestResult = r; dumpRects(); }); }, 500);
```

Careful: the self-test resets the cube and scrambles — the user might interact during that. It's brief with TURN_DUR=1 (72 moves * ~1 frame each ≈ 1.5s). Acceptable. Also at the end it resets to solved. Fine.

Let me update the debug block.

Errors: "run is not defined", "lastPressId is not defined", "__cube is not defined". These come from the debug dumpRects (lastPressId declared later with let → TDZ since dumpRects runs before the declaration executes... actually the error occurs because dumpRects runs at setInterval before the `let lastPressId` declaration is evaluated? No, the script runs fully first. Hmm, the order: TEMP-DEBUG block is placed after the keydown listener, mid-file; the `let lastPressId` etc. declarations are near pressButton, which is BEFORE the debug block. Wait, the error says lastPressId is not defined — a ReferenceError from TDZ would say "Cannot access 'lastPressId' before initialization".

Hmm, "run is not defined" — `run` is referenced in selfTest as `run([])`. I removed the `function run` declaration when I replaced the object literal block! Yes — I replaced the trailing part that contained `run(moves){...}` with the new API object that calls `run` but the function declaration was deleted.

And "lastPressId is not defined" — my second edit replaced the declaration block `let lastPressAt = 0, lastPressId = 'none';` with `let lastPressHandled = 0, lastPressBtn = null, lastPressCount = 0;` and pressButton assigns `lastPressId` — which is no longer declared! Right.

And "__cube is not defined" — because the script threw at the object literal... no, `window.__cube = {...}` — the error "run is not defined" would happen at selfTest() call time (inside setTimeout), which is after __cube is assigned. Hmm, but "run is not defined" is thrown when selfTest executes → the object literal itself assigns selfTest referencing run lazily, so fine. But `setTimeout(()=>{ __cube.selfTest().then(...) })` → "run is not defined" inside. Then "__cube is not defined"? That would be if the script aborted before assigning window.__cube... The order: the debug block with setTimeout is BEFORE the __cube assignment in the file, but setTimeout callbacks run later, so __cube exists. Unless the script threw earlier — e.g., at `let lastPressId` usage in pressButton? No, pressButton is only called on click.

Wait: `window.__cube = { ... selfTest() ... }` — the object literal contains methods; `run` is called only when invoked. So no error at definition.

The "__cube is not defined" error is likely from the setInterval/dumpRects? No.

Actually, maybe the error sequence: "run is not defined" (from selfTest) → then in the .then we'd never get there. Then "lastPressId is not defined" (from dumpRects, called by setInterval and by resize) → then "__cube is not defined"?? Hmm, that could be from dumpRects? No.

Whatever — let me fix properly:
1. Add `function run(moves)` back as a standalone function declaration.
2. Declare `lastPressId`.
3. Ensure __cube assignment happens.

Let me restructure the ending: define `function run(moves)` before the __cube object, and fix lastPressId declaration.

Let me view the tail of the file.

The self-test is progressing (queue 9, moves 6). It seems slow — because each `run` awaits a rAF frame, so ~1 frame per step. But it's taking many frames. Total moves ≈ 24 + 16 + 24 + 6*(30) + ... ≈ 244 moves, each needing a frame with TURN_DUR=1ms. With ~60fps that's ~4s. It's been ~10s and it's at move 6 through... hmm, the queue is 9 and moves 6 — that suggests slow progress. Perhaps the browser throttles rAF when the tab is hidden/backgrounded (headless). That's likely: the harness may not render at 60fps.

Given only ~4 minutes left, let me wait a bit more (up to ~30s) and check the result. If it doesn't finish, I'll trust the logic (already verified F/F′ round trip visually + state snapshot pill shows "Solved" correctly, and 4x same face... let me at least verify the order-4 property quickly via keyboard: press R 4 times and see if it returns to Solved. That's 4 key presses — quick and convincing.

Actually the self-test is running in the background and interfering (it will scramble). Let me wait for it to finish first — if it doesn't finish soon, I'll reload and do a manual check instead.

Let me wait ~20 seconds.

SELFTEST pass=27 fail=0. All checks passed:
- starts solved
- 12 inverse pairs (including mid-state checks)
- 6 face order-4 checks
- (R U R' U')×6 = identity
- 6 random scrambles inverted
- scramble changes the arrangement

And the cube is left solved with Moves 0.

Now I need to remove the TEMP-DEBUG block and the auto self-test invocation (or keep the self-test API but not auto-run it). Let me remove:
- the `#dbg` div
- the dumpRects function and its setInterval, and the auto selfTest call
- keep `selfTestResult`? Remove.

Keep the `__cube` API with selfTest (available via console) — harmless and useful.

Let me do the removals now. Time is short (~2 min). Let me do it carefully with one edit.

Debug scaffolding removed (only the harmless press-tracking vars remain — let me simplify those out to keep it clean, but time is nearly out). Let me just simplify the tracking variables to a single variable for cleanliness. Quick edit.

Actually it's harmless, but let me clean it in one edit to avoid dead code.

Then reload, verify no console errors and the initial solved state, and confirm F/F′ once more quickly (or trust the self-test which already passed). Given ~1 minute left, let me do one reload + screenshot and finish.