Rubik's Cube · solar-pro4

Let me think about building a 3D Rubik's Cube with Three.js. I need to:

1. Create a 3x3x3 cube with 26 cubies (3x3x3 - 1 center), each with visible sticker faces
2. Implement face turns (U, D, L, R, F, B) and their inverses
3. Animate moves and queue them
4. Camera orbit with drag, bounded zoom with wheel
5. Scramble and Reset buttons
6. Preserve cubie and sticker state through moves

Let me think about the architecture:

- Each cubie is a small cube with 6 faces. Visible stickers (on the exterior) have colors. Internal faces are not visible.
- For a 3x3x3 cube: cubies at positions (-1,0,1) x (-1,0,1) x (-1,0,1), so 27 positions, minus the center (0,0,0) = 26 cubies.
- Each cubie has 6 stickers (one per face). A sticker is visible if the cubie is on the exterior face of the big cube (i.e., its position has x=±1, y=±1, or z=±1).
- For moves: group cubies by which face they belong to, rotate the group around the appropriate axis.

Wait, but the requirement says "preserve cubie and sticker state through moves; recoloring a static cube is not sufficient." This means I need to actually move the cubies (reposition and rotate them), not just recolor.

Let me think about the implementation:

Approach: Each cubie has a mesh group (or individual meshes for each face), and we track their positions and rotations. When doing a move, we move all cubies currently in the affected layer to new positions with appropriate rotations, and also update which face is exposed.

Actually, the cleanest approach: 
- Each cubie is a Group containing 6 plane meshes (stickers) at the 6 faces, positioned on the outer surface.
- Stickers are colored only if they're on the exterior.
- Each cubie has a position (where it currently is) and an orientation (quaternion).
- For a face turn, we find all cubies whose current position is in the affected layer (e.g., for U turn, cubies with y=1 in their position relative to center... actually need to think in terms of world position).

Hmm, this gets complex. Let me think again.

Actually, a simpler approach used in many rubik's cube implementations:

- Represent each cubie as having a position (idx_x, idx_y, idx_z) in {0,1,2}^3 for the 27 slots, with the cubie's "home" position.
- Each cubie also has an orientation (which face is where).
- When we do a move, we permute the cubies along with their orientations.

But this requires careful tracking. Let me think about what's simpler.

Alternative approach (visual): 
- Represent the cube as 26 cubie meshes arranged in 3x3x3.
- Each cubie is a small box with colored sticker faces.
- For a move, we rotate the entire layer of cubies about the appropriate axis by 90 degrees, and update their positions.

But rotating a layer means we need to find which cubies are in that layer and move them to new positions. If we just rotate the group mesh, they'd all rotate together but stay in place relative to each other.

Better: For each move, we:
1. Identify the set of cubies in the affected layer (by their current position)
2. For each cubie in the layer, compute its new position and rotation
3. Animate over time (interpolate position and rotation)

The trick: after rotation, the cubies need to "snap" to new grid positions. So we need to:
- For each cubie in the layer, determine which cubie it should become (its new grid position after the 90° rotation)
- Then animate each cubie from its current position/rotation to its new position/rotation

Actually, here's the cleanest approach:

Track each cubie's current grid position (i, j, k) ∈ {0,1,2}^3 and its current orientation. When doing a move on a face:
- The face is defined by which coordinate is at an extreme (0 or 2) and which axis.
- E.g., U face = top (y=2), rotating around Y axis. The cubies in the U layer are those with j=2.
- A U turn (clockwise from top) maps (i, 2, k) → (2-k, 2, i) ... wait let me think.

For U (top face, y=2, rotating around Y axis, clockwise when viewed from above):
- Looking from +Y down, clockwise rotation around Y.
- A point (x, y, z) rotated 90° clockwise around Y (viewed from +Y) → (z, y, -x)? Let me be careful.

Rotation around Y axis by +90° (right-hand rule, thumb pointing +Y, fingers curl): 
- x' = -z
- y' = y  
- z' = x

Hmm wait. Rotation by angle θ around Y axis:
- x' = x cos θ + z sin θ
- y' = y
- z' = -x sin θ + z cos θ

For θ = +90° (counterclockwise when viewed from +Y looking toward origin... actually depends on convention):
- cos 90 = 0, sin 90 = 1
- x' = z
- y' = y
- z' = -x

So a point (1,1,0) → (0, 1, -1) → after 90° rotation around Y.

For a U turn (top face), viewed from above (looking down from +Y toward -Y), clockwise rotation means: the front-right corner goes to back-right, etc. In standard Rubik's notation, U is clockwise when viewed from above.

Let me just adopt: U = rotate the top layer 90° clockwise when viewed from above. Using right-hand rule with thumb up (+Y), fingers curl... that's counterclockwise viewed from above. So U = -90° around Y (or +90° with opposite sign convention).

I'll just pick a convention and make sure inverses work. Let me define:
- U: rotate top layer (-90° around Y, clockwise viewed from above)
- D: rotate bottom layer (+90° around Y, clockwise viewed from below)
- F: rotate front layer (+90° around X, clockwise viewed from front)
- B: rotate back layer (-90° around X, clockwise viewed from back)
- R: rotate right layer (+90° around Z, clockwise viewed from right)
- L: rotate left layer (-90° around Z, clockwise viewed from left)

Actually this is getting complicated. Let me just think in terms of which cubies move where.

For U (top layer, y index = 2 in 0-indexed, or y=1 in -1,0,1 coords):

Using -1,0,1 coordinates (cubie positions):
- U layer: cubies with y = 1
- U turn (clockwise viewed from above): (x, 1, z) → (z, 1, -x)

Let's verify: (1,1,0) → (0,1,-1). Front-right top → back-right top. Yes that seems right for clockwise viewed from above? Let me think... If I look from above (bird's eye view), front is -Z, back is +Z, right is +X, left is -X. Clockwise rotation: front-right (1,1,0) should go to front-left... no wait.

Hmm, clockwise viewed from above: the front edge (y=1, z=-1) moves to the right edge (x=1). So (0,1,-1) → (1,1,0). And (1,1,0) → (0,1,1). And (0,1,1) → (-1,1,0). And (-1,1,0) → (0,1,-1).

So (x,1,z) → (-z, 1, x)? Let's check: (0,1,-1) → (1,1,0) ✓. (1,1,0) → (0,1,1) ✓. (0,1,1) → (-1,1,0) ✓. (-1,1,0) → (0,1,-1) ✓.

So U: (x,y,z) → (-z, y, x) for y=1 layer. Rotation matrix: 
- x' = -z
- y' = y
- z' = x

This is rotation around Y by -90°? Let's check: rotation around Y by -90°: 
- x' = x cos(-90) - z sin(-90) = 0 - z*(-1) = z... no that gives z.
- Wait, standard rotation around Y: [cos, 0, -sin; 0,1,0; sin, 0, cos] applied to (x,y,z).
- For -90°: cos=0, sin=-1. So x' = 0*x - (-1)*z = z. y'=y. z' = (-1)*x + 0*z = -x.
- So (x,y,z) → (z, y, -x). That's the opposite of what I want.

For +90° around Y: cos=0, sin=1. x' = 0*x - 1*z = -z. y'=y. z' = 1*x + 0*z = x. So (x,y,z) → (-z, y, x). That's what I want for U.

But +90° around Y (right-hand rule, thumb +Y) is counterclockwise when viewed from +Y (looking down). So U = clockwise viewed from above = -90° around Y by right-hand rule... but we computed +90° gives the clockwise mapping. There's a sign confusion.

Anyway, I'll just use these mappings and make sure inverses are correct:
- U: (x,y,z) → (-z, y, x) for y=1 layer. Inverse U': (x,y,z) → (z, y, -x).
- D: bottom layer y=-1. D turn clockwise viewed from below. Viewed from below (looking up from -Y), clockwise. Equivalent to U' on bottom. (x,y,z) → (z, y, -x) for y=-1? Let me think... Actually D is clockwise when viewed from below, which is the same as rotating the bottom layer in the same rotational direction as U but viewed from the other side. 

U' maps (x,1,z) → (z, 1, -x). For D (clockwise viewed from below), I want the bottom layer to rotate the same way relative to looking from below. If we look from below (from -Y toward +Y), clockwise looks like... 

Actually, the standard convention: D = clockwise when viewed from below. Since U clockwise viewed from above = +90° around Y (in our mapping), D clockwise viewed from below = also +90° around Y but applied to the bottom layer. Wait no.

Let me just think physically. The cube is on a table. U = top layer rotates clockwise (when you look down at it). D = bottom layer rotates clockwise (when you look up at it from below). 

If U rotates the top layer by +90° around Y (using our mapping (x,1,z)→(-z,1,x)), then to rotate the bottom layer "clockwise when viewed from below", we need to think about what that means from the top view. Looking from below clockwise = looking from above counterclockwise. So D = -90° around Y for the bottom layer = (x,-1,z) → (z, -1, -x).

Hmm, let me just verify with a physical example. Take the front-bottom edge cubie at (0,-1,-1) in -1,0,1 coords. After D (clockwise viewed from below), this should move to the right-bottom position (1,-1,0) (since from below, front goes to right). 

Using (x,-1,z) → (z, -1, -x): (0,-1,-1) → (-1, -1, 0). That's left-bottom, not right-bottom. So that's wrong.

Let me reconsider. D clockwise viewed from below: imagine you're under the cube looking up. Front (which is at -Z, the side facing you when cube is on table in front of you)... wait, if you're below looking up, the front of the cube (original -Z direction) is now behind you? No.

OK let me set up coordinates clearly. Cube on table, you're standing in front (looking at the front face, -Z side). 
- +X = right, -X = left
- +Y = up, -Y = down
- +Z = back (away from you), -Z = front (toward you)

U (top layer, y=1): clockwise viewed from above (bird's eye). From above, you see the top, with -Z (front) at the bottom of your view, +Z (back) at top, +X (right) on right, -X (left) on left. Clockwise: front → right → back → left → front. So:
- (0,1,-1) [front-top] → (1,1,0) [right-top]
- (1,1,0) → (0,1,1) [back-top]  
- (0,1,1) → (-1,1,0) [left-top]
- (-1,1,0) → (0,1,-1) [front-top]

Mapping: (x,1,z) → (-z, 1, x). Check: (0,1,-1) → (1,1,0) ✓.

D (bottom layer, y=-1): clockwise viewed from below. From below, you're looking up. The cube's front (-Z) is now at... if you're below looking up, and you tilt your head so the front of cube is away from you, then... this is confusing.

Standard Rubik's D move: clockwise when viewed from below. There's actually a known convention. Let me just use: D = U' applied to bottom layer but in same rotational sense. Actually no.

You know what, let me just go with the well-known mapping. In Rubik's cube group theory:

Using coordinates where cubie positions are (x,y,z) with each ∈ {-1,0,1}:

U (top, y=1, clockwise viewed from above):
- Positions: (x,1,z) → (-z,1,x)
- This is a 90° rotation. The cubies also need to be rotated so their stickers align. A cubie at (x,1,z) moving to (-z,1,x) needs its orientation adjusted.

For the cubie orientation: when a cubie moves from position P to position P', its local axes need to be rotated. For a U turn, the Y axis of the cubie stays the same (it's still upright), but the X and Z axes swap with a sign change.

Specifically, a cubie originally at (x,1,z) with its local +X pointing in world +X direction, after moving to (-z,1,x), should have its local +X now pointing in world +Z direction (because it moved to where the +Z side was). Hmm, actually the cubie's orientation: if we think of the cubie as having 6 face stickers (front, back, left, right, top, bottom), then after a U turn, the front sticker of a cubie that was on the front-top edge now points to the right.

This is getting complicated. Let me simplify by using a different representation.

Simpler approach: Each cubie is represented by its 6 face colors. The cubie has a position (which grid cell it's in) and an orientation (which of its 6 faces points in which of the 6 world directions). 

When we do a move, we:
1. Find all cubies in the affected layer.
2. For each such cubie, compute its new grid position (after the 90° rotation of the layer).
3. Also compute the new orientation: the cubie's faces get remapped according to the rotation.

For a U turn (90° around Y, clockwise viewed from above):
- A cubie at (x,1,z) goes to (-z,1,x).
- Its orientation: the face that was pointing in +X now points in +Z, the face pointing in +Z now points in -X, the face pointing in -X now points in -Z, the face pointing in -Z now points in +X. The top (+Y) and bottom (-Y) faces stay the same.

So if a cubie has colors [right, left, front, back, top, bottom] corresponding to world directions [+X, -X, -Z, +Z, +Y, -Y], after U turn:
- new_right = old_front (since +X → +Z... wait no)

Hmm, let me re-index. Let me say the cubie stores colors for its 6 faces: +x, -x, +y, -y, +z, -z (local directions). Initially, for a cubie at grid position (i,j,k) with i,j,k ∈ {-1,0,1}, the local +x face is on the +x side of the cubie, which in world space points in +x. So initially, local_directions = world_directions.

After a U turn, the cubie at (x,1,z) moves to (-z,1,x). In world space, the cubie has been rotated 90° around Y. So its local +x axis now aligns with world +z, local +z aligns with world -x, etc.

So the new local directions in terms of old:
- new_local_x = old_local_z (world +x is now occupied by what was +z)
- new_local_z = old_local_-x (world +z is now occupied by what was -x)

Wait, I need to be careful. The cubie physically rotates. If a cubie is at (1,1,0) with its +x face on the right side (world +x), after U turn it moves to (0,1,1). At this new position, the cubie should still have its +x face on the... well, it moved along with the rotation. Since the whole layer rotated 90° around Y (clockwise viewed from above), the cubie rotated 90° around its own Y axis (since it's in the layer, its center moves on a circle around the Y axis).

So the cubie's local +x (originally world +x) becomes world -z after the rotation? No wait. Rotation around Y by +90° (our U mapping): 
- A vector (1,0,0) (local +x) after rotation around Y by +90° becomes (0,0,-1)? Let me compute: rotation around Y +90°: (x,y,z) → (-z, y, x). So (1,0,0) → (0,0,1). So local +x → world +z.

Hmm so after U, the cubie at (1,1,0) which had its +x face pointing world +x, now has its +x face pointing world +z (since the cubie rotated 90° around Y). But the cubie is now at (0,1,1), and its +x face is on the +z side of the cubie, which in world space is... at position (0,1,1), the +z side of the cubie faces world +z. So the sticker that was on the +x face is now on the +z face (world +z direction). 

So to track colors: I'll represent each cubie's state as a 3x3 rotation matrix (or quaternion) that maps local face directions to world directions. Initially identity. After U, the cubie that was at (x,1,z) now has rotation = old_rotation * R_u, where R_u is the rotation matrix for +90° around Y.

Wait, the rotation is applied to the cubie itself (the cubie rotates with the layer). So if a cubie has current world rotation R (mapping local to world), and the layer rotates by R_layer, the new cubie rotation is R_layer * R (first apply R to get world, then... no).

If local vector v maps to world via R: world = R * v. After the layer rotation R_layer is applied to the cubie (the cubie is rigidly rotated by R_layer), the new mapping is: new_world = R_layer * (R * v) = (R_layer * R) * v. So new R = R_layer * R.

For U: R_layer = rotation around Y by +90° (in our convention where (x,y,z) → (-z, y, x)). 

Matrix for +90° around Y: [[0,0,1],[0,1,0],[-1,0,0]]? Let's verify: [[0,0,1],[0,1,0],[-1,0,0]] * (x,y,z) = (z, y, -x). But our U mapping is (x,y,z) → (-z, y, x). So that's not matching.

Let me recompute. Rotation around Y by angle θ (right-hand rule, thumb +Y):
- x' = x cos θ + z sin θ
- y' = y
- z' = -x sin θ + z cos θ

For θ = +90°: cos=0, sin=1.
- x' = z
- y' = y
- z' = -x

So (x,y,z) → (z, y, -x). Matrix: [[0,0,1],[0,1,0],[-1,0,0]].

For θ = -90°: cos=0, sin=-1.
- x' = -z
- y' = y  
- z' = x

So (x,y,z) → (-z, y, x). Matrix: [[0,-1,0],[0,0,1],[1,0,0]]? Let me verify: [[0,-1,0],[0,0,1],[1,0,0]] * (x,y,z) = (-y... no. 

Matrix multiplication: row1 · (x,y,z) = 0*x + (-1)*y + 0*z = -y. That's wrong.

Let me redo. The matrix should be such that (x,y,z) → (-z, y, x).
- new_x = -z = 0*x + 0*y + (-1)*z
- new_y = y = 0*x + 1*y + 0*z
- new_z = x = 1*x + 0*y + 0*z

So matrix = [[0,0,-1],[0,1,0],[1,0,0]]. Check: row1·(x,y,z) = -z ✓, row2 = y ✓, row3 = x ✓. 

So U (clockwise viewed from above) = rotation around Y by -90° = matrix [[0,0,-1],[0,1,0],[1,0,0]].

Wait, but earlier with θ=-90° I got (x,y,z)→(-z,y,x) which matches. And the matrix for that is [[0,0,-1],[0,1,0],[1,0,0]]. Let me double-check with the formula: for θ=-90°, cos=0, sin=-1:
- x' = x*0 + z*(-1) = -z ✓
- y' = y ✓
- z' = -x*(-1) + z*0 = x ✓

Great. So U = -90° around Y.

Now for the cubie orientation tracking: I'll use a 3x3 matrix per cubie, initially identity. After U turn, cubies in the U layer have their matrix multiplied on the left by R_u = [[0,0,-1],[0,1,0],[1,0,0]].

But wait, I need to also handle the position. The cubie at grid position (x,1,z) moves to (-z,1,x). But I also need to track which cubie is which. 

Here's the clean approach: I maintain an array of 26 cubies. Each cubie has:
- A unique ID (0-25)
- A current grid position (gx, gy, gz) ∈ {-1,0,1}^3
- A current orientation matrix (3x3) mapping local→world
- A mesh group (Three.js) representing the cubie visually

When doing a move:
1. Identify cubies in the affected layer (those with the relevant coordinate at ±1).
2. For each such cubie, compute its new grid position after the 90° rotation.
3. Also compute the new orientation (multiply by R_layer).
4. But multiple cubies might map to the same new grid position! That's the permutation aspect. Actually no—for a face turn, each cubie in the layer maps to a unique new position (it's a 4-cycle on the 8 corner cubies and two 4-cycles on the edge cubies, plus the center stays put).

Wait, the center cubie of the face (e.g., (0,1,0) for U) stays in place but rotates. So its position doesn't change but its orientation does.

For corner cubies: (1,1,1) → (-1,1,1) → (-1,1,-1) → (1,1,-1) → (1,1,1). That's a 4-cycle.
For edge cubies (non-center, non-corner): (1,1,0) → (0,1,1) → (-1,1,0) → (0,1,-1) → (1,1,0). Another 4-cycle.

So the positions form cycles. To animate, I need to move each cubie from its current position to its new position, and also rotate it.

The issue: after the first move, cubies are in new positions. The next move operates on the current positions. So I need to track cubies by their current grid position, not their original position.

Here's my plan:
- Maintain `cubies`: array of 26 cubie objects, each with {id, mesh, gridPos: {x,y,z}, orient: Matrix3, colorFaces: [color for +x, -x, +y, -y, +z, -z]}.
- Initially, cubie with id = idx is at grid position corresponding to its original slot, with identity orientation.
- For a move, find all cubies currently at grid positions in the affected layer. For each, compute new grid position and new orientation. Then animate.

But the problem with animation: if I just set each cubie's final position and orientation, I need to handle the fact that cubies swap places. So cubie A at position P1 moves to P2, and cubie B at P2 moves to P3, etc. During animation, I need cubie A to travel from P1 to P2, and cubie B from P2 to P3, etc. They don't collide because they're at different positions at the start.

Actually, the simplest animation: for each cubie in the layer, animate from its current (pos, orient) to its (newPos, newOrient) over the animation duration. Since the moves are cyclic, after the animation completes, assign each cubie its new gridPos and orient.

But there's a subtlety: two cubies might be heading to nearby positions and could visually overlap during animation. For a 90° face turn, the cubies in the layer rotate around the face axis. If I animate each cubie along a circular arc from its start to its end position (rotating around the face center), they won't collide because they all rotate together. This is the physically correct animation.

So for animation: for each cubie in the layer, its animation path is a rotation around the face axis. The cubie starts at its current position, rotates around the face center by the move angle (90°), and ends at its new position. The orientation also rotates by the same angle around the face axis.

So I don't even need to precompute the final positions—I just apply the rotation to each cubie's mesh (position and orientation) over time. But then after the animation, I need to update the cubie's gridPos and orient to reflect the new state.

Wait, but if I just rotate the meshes, then after the animation, the cubie's visual position is correct, but I need to update my data structures (gridPos, orient) to match. And I need to make sure that the data structures are updated correctly so the next move works.

Approach: during animation, I rotate the meshes. When animation completes, I "snap" the data: for each cubie in the layer, compute its new gridPos and orient based on applying the rotation, and update the cubie's data.

But actually, if I rotate the meshes during animation, the cubies end up at the right visual positions. Then I just need to update gridPos and orient to match.

To compute new gridPos: apply the rotation to the cubie's current gridPos. For U, a cubie at (x,1,z) rotates to (-z,1,x). For cubies not in the U layer, they don't move.

To compute new orient: multiply current orient by R_layer.

OK here's the thing though: I need to be careful about the order of applying the rotation to position vs. orientation.

The cubie's visual position is gridPos (scaled by cubie size). The cubie's visual orientation is orient. When the layer rotates by R_layer:
- New visual position = R_layer * (old visual position - faceCenter) + faceCenter... but actually for a cubie in the layer, its center is at gridPos * cubieSize, and the face center is at the center of the face. For U, face center is at (0, 1*cubieSize, 0) in world? No, the face center is at the center of the face of the big cube, which is at world position (0, cubieSize, 0) if the big cube center is at origin and cubies have size s.

Hmm, let me set up coordinates. Let the big cube be centered at origin, with side length 3 (cubie size = 1). Then cubie at grid position (gx, gy, gz) ∈ {-1,0,1} has its center at world position (gx, gy, gz). The U face is at y=1, face center at (0,1,0).

For a U turn, the layer (y=1) rotates around the Y axis through (0,1,0)? No, it rotates around the Y axis through the origin (0,0,0), because the whole layer rotates as a rigid body around the central Y axis.

Wait, is that right? If you hold the bottom 2 layers fixed and rotate the top layer, the top layer rotates around the Y axis through the center of the cube (origin), not through the center of the top face. Yes, because the rotation axis is the Y axis, and the top layer is at y=1, so each cubie in the top layer rotates around the Y axis at its own y-level.

So for U turn: each cubie in the top layer (y=1) rotates around the Y axis (through origin) by the move angle. The cubie's center, initially at (x, 1, z), after rotation by R around Y, goes to R*(x,1,z) = (-z, 1, x) (for -90° around Y).

For the cubie's orientation: the cubie rotates with the layer, so its orientation matrix is multiplied by R (on the left, since we apply the layer rotation to the cubie's current orientation).

Wait, I need to think about this more carefully. If the cubie's current orientation maps local→world via matrix M (world_vec = M * local_vec), and then the layer rotates by R, the cubie's new orientation should map local→world via R*M (first M takes local to old-world, then R takes old-world to new-world). So new M = R * M.

But hold on—I'm tracking gridPos separately from the mesh position. The mesh position is gridPos (scaled). When I apply the rotation R to the layer, both the mesh position and orientation get rotated. But gridPos is the "logical" position, and I want to update it to reflect the new logical position after the move.

For a cubie initially at gridPos (x,1,z), after U turn, its new gridPos is (-z,1,x). This is exactly R * (x,1,z) where R is the -90° around Y rotation. So new_gridPos = R * old_gridPos (as vectors). But only for cubies in the layer; cubies outside the layer don't change gridPos.

And new_orient = R * old_orient for cubies in the layer.

So the animation: for each cubie in the layer, animate its mesh position from old_gridPos to R*old_gridPos (which is new_gridPos), and animate its mesh rotation from old_orient to R*old_orient (which is new_orient). 

For the animation, I can interpolate using slerp for rotations and lerp for positions. But since the rotation is a simple 90° around a fixed axis, I can also just apply the rotation progressively: at time t (0 to 1), the cubie's mesh position = R(t) * old_gridPos, and mesh rotation = R(t) * old_orient, where R(t) is the partial rotation (t*90° around the axis).

This is cleaner: during animation, for each cubie in the layer, I set its mesh position to R(t) * old_gridPos and its mesh quaternion to R(t) * old_orient (applied as quaternions). At t=1, the cubie is at its final state, and I update gridPos and orient.

But wait, there's a subtlety with the mesh quaternion. The mesh has a quaternion that represents its orientation in world space. Initially, the mesh quaternion = orient (the cubie's logical orientation). During animation, I want the mesh quaternion to go from orient to R*orient. 

Using quaternions: if orient is a quaternion q, and R is a quaternion r (representing the layer rotation), then new orient = r * q (quaternion multiplication, where r is applied first... depends on convention). 

In Three.js, quaternion multiplication q1 * q2 applies q2 first then q1 (or the other way around—I need to check). Actually, in Three.js, `q.multiply(r)` means q = q * r, and the rotation represented is: first apply r, then apply q (when transforming vectors: v' = q * (r * v) = (q*r) * v... no, quaternion rotation is v' = q v q*, and (q*r) v (q*r)* = q (r v r*) q*, so r is applied first, then q. So q*r means: apply r first, then q.

Hmm, I need to be careful with the convention. Let me just use matrices for the logic and convert to quaternions for Three.js.

Actually, let me simplify. I'll track each cubie's orientation as a Three.js Quaternion. Initially identity. For a move, I compute the layer rotation quaternion r. For each cubie in the layer, its new orientation quaternion = r * old_orientation (in Three.js convention, this applies old_orientation first, then r? or r first then old_orientation?).

Let me just test with a simple case. If a cubie has orientation q = identity, and I apply r (90° around Y), the new orientation should be r. So new_q = r * q = r * identity = r. That works if multiplication is r*q.

If the cubie has orientation q (some rotation), and I apply r, the new orientation should represent: first apply q (to get to the cubie's current world orientation), then apply r (the layer rotation). In terms of transforming a local vector v to world: world = q * v (using Three.js quaternion-vector rotation). After the layer rotation, the world vector should be r * (q * v) = (r * q) * v. So new_q = r * q. So in Three.js, `new_q = r.multiply(q)` or `new_q = r * q` (Three.js supports quaternion multiplication via `multiply` or `*`).

Wait, Three.js Quaternion: `q1.multiply(q2)` sets q1 = q1 * q2. And the rotation applied by q1*q2 to a vector is: (q1*q2) * v * (q1*q2)* = q1 * (q2 * v * q2*) * q1* = q1 applied to (q2 applied to v). So q2 is applied first, then q1. So `r * q` (i.e., r.multiply(q)) applies q first, then r. That's what I want: q (current cubie orientation) first, then r (layer rotation). 

So new_orient = r * old_orient, i.e., `orient.copy(r).multiply(old_orient)` or `orient = r * old_orient`.

Hmm wait, that's not right either. Let me reconsider. If `r * q` applies q first then r, and I want to apply the layer rotation r to the cubie's current orientation q, then the new orientation should be r * q (apply q to get current world, then apply r for the layer rotation). Yes.

But actually, I realize the order might be the opposite depending on how I think about it. Let me think again.

The cubie's current orientation q maps local frame to world frame. A local vector v is at world position q*v (quaternion rotation). Now the layer rotates by r (around the world axis). After the layer rotation, the cubie's local frame is now at world position r*(q*v) = (r*q)*v. So the new orientation is r*q. Yes, new_q = r * q.

OK so I'll use: for each cubie in the layer, new_orient = r * old_orient.

Now for the animation: I'll use a progress t from 0 to 1. At progress t, the layer has rotated by t * angle around the axis. So the partial rotation quaternion is r_t = r^t (quaternion power), or equivalently, the rotation by t*angle around the same axis.

In Three.js, I can create r_t as a quaternion from axis-angle: `new THREE.Quaternion().setFromAxisAngle(axis, t * angle)`.

Then at progress t, each cubie in the layer has:
- mesh.position = r_t applied to old_gridPos (as a vector)
- mesh.quaternion = r_t * old_orient

And at t=1, I update gridPos = r * old_gridPos (for cubies in the layer) and orient = r * old_orient.

Wait, but gridPos is a logical position (in grid coordinates), not a world position. For a cubie at gridPos (x,1,z) in the U layer, after U turn, its new gridPos is (-z,1,x). This is R * (x,1,z) where R is the rotation matrix. But gridPos is in grid units, and the rotation is around the origin. So yes, new_gridPos = R * old_gridPos (as a vector in grid space).

For cubies not in the layer, gridPos doesn't change.

OK now, there's another subtlety. After the U turn, the cubie that was at (1,1,1) is now at (-1,1,1). Its new gridPos is (-1,1,1). But the cubie that was at (-1,1,1) is now at (-1,1,-1). So the cubies have swapped grid positions. My data structure needs to handle this: each cubie object has its own gridPos, and after the move, I update each cubie's gridPos to its new value. The cubies don't swap objects; each cubie just updates its own gridPos.

So my data structure: array of 26 cubie objects, each with {id, mesh, gridPos: Vector3, orient: Quaternion, colors: [6 colors]}. After a move, for each cubie in the layer, I update gridPos and orient. The cubie objects persist; only their gridPos and orient change.

This is clean. Let me now think about the visual representation.

Each cubie is a Group containing 6 plane meshes (sticker faces), positioned on the 6 faces of the cubie. The sticker planes are at distance 0.5 from the cubie center (on each face), with size slightly less than 1 (to show boundaries). Each sticker is colored if it's on the exterior of the big cube.

Wait, but the cubie's stickers should always show the correct colors based on the cubie's current orientation and position. A sticker on the +x face of the cubie is visible if the cubie is on the +x side of the big cube (i.e., its gridPos.x = 1). But as the cubie moves and rotates, the sticker that's on the +x face of the cubie might now be on a different side of the big cube.

Hmm, actually, the stickers are fixed on the cubie. The cubie has 6 faces, each with a sticker of a certain color. When the cubie is at a certain position and orientation, some of its stickers are visible (on the exterior of the big cube) and some are hidden (internal).

For a solved cube, each cubie's stickers match the face colors: a cubie at (1,1,1) (top-right-front corner) has stickers: +x=red (right face), +y=white (top face), -z=green (front face), and the other 3 faces are internal (no sticker or black).

When the cube is scrambled, a cubie might be at a different position with a different orientation. Its stickers (which are fixed on the cubie) now show different colors on different faces of the big cube.

So the sticker colors are fixed per cubie (they're properties of the cubie, not the position). The visibility of a sticker depends on whether the cubie's face is on the exterior of the big cube at its current position.

Wait, but that's not quite right either. Let me think again.

A cubie has 6 faces. Each face has a sticker. The sticker color is fixed (e.g., the +x face of the cubie always has the same color). When the cubie is at grid position (gx, gy, gz) with orientation M, the sticker on the cubie's +x face is at world position (gx, gy, gz) + M*(0.5, 0, 0) (approximately), and it's visible if that world position is on the exterior of the big cube.

But the exterior of the big cube is at |wx|=1.5, |wy|=1.5, |wz|=1.5 (if the big cube has side 3 and cubies have size 1, centered at origin). A cubie at (1,1,1) has its +x face at world x = 1 + 0.5 = 1.5, which is on the exterior. A cubie at (0,1,1) has its +x face at world x = 0 + 0.5 = 0.5, which is internal.

So a sticker is visible if the cubie's face is on the exterior of the big cube at the cubie's current grid position. The cubie's grid position determines which faces are exterior: if gx=1, the +x face is exterior; if gx=-1, the -x face is exterior; similarly for y and z.

So for a cubie at gridPos (gx, gy, gz):
- +x sticker visible iff gx = 1
- -x sticker visible iff gx = -1
- +y sticker visible iff gy = 1
- -y sticker visible iff gy = -1
- +z sticker visible iff gz = 1
- -z sticker visible iff gz = -1

And the sticker colors are fixed per cubie (the colors on each of the cubie's 6 faces).

For a solved cube, the cubie at (1,1,1) has colors: +x=red, +y=white, -z=green (and the other 3 faces have no visible sticker, or we can give them a default color). Wait, but which colors? Let me define the standard Rubik's cube colors:
- Right (+x): red
- Left (-x): orange
- Top (+y): white
- Bottom (-y): yellow
- Front (-z): green
- Back (+z): blue

For a solved cube, the cubie at grid position (gx, gy, gz) has:
- +x color = red if gx=1, else none
- -x color = orange if gx=-1, else none
- +y color = white if gy=1, else none
- -y color = yellow if gy=-1, else none
- +z color = blue if gz=1, else none
- -z color = green if gz=-1, else none

But these colors are properties of the cubie, fixed at initialization based on the cubie's initial position. When the cubie moves, its colors stay the same (they're fixed on the cubie). The visibility of each color depends on the cubie's current grid position.

So at initialization, for each of the 27 positions (minus center), I create a cubie with the appropriate colors based on its initial grid position. Then, as the cube is scrambled, the cubies move and rotate, and their stickers show different colors on different faces of the big cube.

This is the correct model. Let me implement it.

Now, for the visual representation, I need to create 6 sticker planes per cubie, one for each face. The stickers are colored based on the cubie's colors array. A sticker is visible (shown) if the corresponding face is on the exterior of the big cube at the cubie's current grid position.

But wait, the visibility changes as the cubie moves. So I need to update the visibility of each sticker based on the cubie's current grid position. I can do this after each move (or during animation, but it's simpler to update at the end).

Actually, during animation, the cubie's grid position changes continuously (if I animate by rotating the mesh). But I'm tracking gridPos separately. So I should update sticker visibility based on the cubie's logical gridPos, which I update at the end of the animation.

Hmm, but during animation, the cubie's visual position moves, and the stickers should be visible/hidden based on the visual position, not the logical gridPos. Otherwise, during animation, stickers might appear/disappear incorrectly.

This is a complication. Let me think about how to handle it.

Option 1: During animation, update sticker visibility based on the visual position (interpolated). This requires computing, at each frame, which faces of the cubie are on the exterior based on its current visual position.

Option 2: Just update sticker visibility at the end of the animation based on the final gridPos. During animation, stickers might be slightly wrong, but it's a brief moment.

Option 3: Don't animate sticker visibility at all; keep all 6 stickers visible always (even internal ones). This would show internal stickers, which is not realistic but might be acceptable for a simple demo.

Option 4: Make the cubies slightly smaller with a gap between them, so internal faces are never visible. Then I don't need to worry about sticker visibility; all stickers are always visible (since there are gaps). But this changes the look of the cube.

Actually, the simplest approach: make each sticker a plane that's always rendered, but use the cubie's current grid position to determine visibility. During animation, I can update the grid position continuously (treating it as the visual position). But grid positions are discrete (-1, 0, 1), so I can't interpolate them.

Alternatively, I can compute visibility based on the visual position during animation. The visual position is `mesh.position`, which I'm animating. At each frame, I check which faces of the cubie are on the exterior based on `mesh.position`.

For a cubie with visual position (px, py, pz) and size 1, the +x face is at px + 0.5, and it's on the exterior if px + 0.5 >= 1.5 - epsilon (i.e., px >= 1.0 - epsilon). Similarly for other faces.

But during animation, the cubie's visual position moves continuously, so the visibility would change at specific moments. This could cause flickering.

Hmm, let me think of a simpler approach. What if I make the cubies with a small gap (e.g., cubie size 0.98 with gap 0.02), so there's a small black gap between cubies? Then internal faces are never visible (they're hidden in the gap), and I always show all 6 stickers. The gap gives the appearance of boundaries.

Wait, but if I show all 6 stickers always, then for a cubie in the center of a face (e.g., (1,0,0) on the right face), the -x sticker (orange) would be visible on the left side of the cubie, but it's internal (facing the center of the big cube). With a gap, the -x sticker would be visible in the gap, which is wrong.

Hmm. Actually, with a gap, the internal stickers would be hidden because they face into the gap, and the gap is between cubies. Wait, no. If I have cubies with a gap, and I show all 6 stickers on each cubie, then for a cubie at (1,0,0), its -x sticker is on the left side, facing the gap between it and the cubie at (0,0,0). The sticker would be visible in the gap (you can see it through the gap). That's not correct.

OK so I do need to handle visibility. Let me go with: update sticker visibility at the end of each animation based on the final gridPos. During animation, keep the visibility as it was at the start (or update it continuously based on visual position, accepting some imperfection).

Actually, the cleanest approach: during animation, I update the sticker visibility based on the visual position at each frame. Since the animation is a smooth rotation, the visibility changes only when a face crosses the boundary, which happens at specific moments. For a 90° rotation, each face crosses the boundary at most once. So there might be a brief moment where visibility is wrong, but it's acceptable.

Alternatively, I can just make the cubies opaque and not worry about internal stickers being visible, by making the cubies slightly smaller and using a dark material for internal faces. But that's more complex.

Let me go with a simpler approach: each cubie has 6 sticker meshes. Each sticker has a `visible` property. Initially, based on the cubie's initial grid position, I set the visibility of each sticker. After each move (at the end of animation), I update the visibility based on the new grid position. During animation, the visibility doesn't change (it stays as it was at the start of the animation). This means during animation, some stickers might be visible that should be hidden, or vice versa, but it's a brief moment and the visual effect is acceptable.

Wait, actually, there's a better approach. Since I'm animating the mesh position and rotation, I can compute the visibility based on the visual position at each frame. The visual position is `mesh.position`, which is interpolated during animation. At each frame, I check: for each face of the cubie, is it on the exterior? I can compute this by transforming the face direction by the cubie's current rotation and checking if the resulting world position is on the exterior.

But this is complex. Let me simplify: I'll update sticker visibility at the end of each animation. During animation, I'll keep the stickers as they are. The visual artifact is minimal (a 0.5-second animation where a sticker might be slightly off).

Actually, you know what, let me think about this differently. The standard way to render a Rubik's cube in 3D:

Each cubie is a box with colored faces. The box has 6 faces, each with a color. The colors are fixed per cubie. When rendering, all 6 faces are visible (the box is opaque, so you only see the outer faces). But with a box geometry, the internal faces are not rendered (back-face culling). So if I use a BoxGeometry with different colors per face, the internal faces are automatically hidden.

But wait, with a single BoxGeometry per cubie, I can't have different colors per face (well, I can with an array of materials, but the faces are fixed to the geometry). And the cubie rotates, so the face colors rotate with it. But the issue is: when a cubie is at a certain position, some of its faces are external and some are internal. The internal faces are hidden by the cube's structure (adjacent cubies). But if I render each cubie as a separate box, the internal faces of one cubie might be visible if there's a gap or if the adjacent cubie is moved away.

Hmm, actually, for a Rubik's cube, the standard visual representation is: each cubie is a small box with colored stickers on the outer faces. The stickers are on the surface of the big cube. When the cube is solved, the stickers form 6 solid-colored faces. When scrambled, the stickers are in different positions.

The key insight: the stickers are on the cubie's faces, and they rotate with the cubie. The visibility of a sticker depends on whether the cubie's face is on the exterior of the big cube.

For rendering, I can use a BoxGeometry for each cubie, with 6 materials (one per face). The materials are colored based on the cubie's sticker colors. But the issue is: the box geometry's faces are in local space, and they rotate with the cubie. When the cubie is at a position where a face is internal, that face is still rendered (it's part of the box), but it's hidden by the adjacent cubies (if they're in place).

But if adjacent cubies are moved away (during a turn), the internal face becomes visible. This is actually correct for a Rubik's cube: when you turn a face, you can see the internal structure briefly.

Wait, no. In a real Rubik's cube, the internal mechanism is hidden. The stickers are only on the outer faces. When you turn a face, the cubies move, but the stickers stay on the outer faces of the cubies. You never see "internal" stickers.

So the correct model is: each cubie has 6 stickers, but only the stickers on the exterior faces are visible. The interior stickers are not rendered (or are hidden).

For rendering, I can use 6 separate plane meshes per cubie, one for each face, and set their visibility based on whether the face is on the exterior. This is the approach I outlined earlier.

OK let me just go with this approach and handle the visibility update at the end of each animation. During animation, the visibility might be slightly off, but it's acceptable.

Actually, wait. Let me reconsider. During a face turn animation, the cubies in the layer rotate around the face axis. Their visual positions change continuously. The stickers that are on the exterior at the start of the animation might become internal during the animation (and vice versa). But if I don't update visibility during animation, the stickers will be visible/hidden based on the start position, which is wrong during the animation.

For example, consider a U turn. A cubie at (1,1,1) (top-right-front corner) has stickers on +x, +y, -z faces (exterior). After the U turn, it's at (-1,1,1), and its stickers are on -x, +y, -z faces (exterior). During the animation, the cubie rotates, and at some point, the +x sticker (which was on the exterior) becomes internal, and the -x sticker (which was internal) becomes external.

If I don't update visibility during animation, the +x sticker remains visible throughout the animation, even when it's internal. This looks wrong.

To handle this correctly, I need to update visibility during animation. At each frame, I compute which faces are exterior based on the visual position.

Let me implement this. At each frame during animation:
- For each cubie in the layer, compute its visual position (mesh.position).
- For each of the 6 faces, check if it's on the exterior:
  - +x face: exterior if visual_x + 0.5 >= 1.5 (i.e., visual_x >= 1.0)
  - -x face: exterior if visual_x - 0.5 <= -1.5 (i.e., visual_x <= -1.0)
  - Similarly for y and z.
- Set the visibility of each sticker based on this.

But this uses the visual position, which is interpolated during animation. At the start of animation, visual_x = grid_x (which is ±1 or 0). At the end, visual_x = new_grid_x. During animation, visual_x is interpolated, so it might be 0.5 or -0.5, which is not at the boundary. So the visibility check would be incorrect during animation.

Hmm, this is tricky. The issue is that the visual position is interpolated, but the visibility should be based on the logical grid position, which is discrete.

Actually, during a face turn, the cubies in the layer rotate around the face axis. For a U turn, the cubies rotate around the Y axis. Their Y position stays the same (y=1), but their X and Z positions change. At any point during the animation, the cubie's X and Z positions are on the circle of radius sqrt(x^2 + z^2) around the Y axis. For a cubie at (1,1,1), the radius is sqrt(2), and during the animation, its position is on this circle. So its X and Z positions are never 0 during the animation (unless the cubie is on the axis, like (0,1,0)).

For a cubie at (1,1,1), during the U turn animation, its position goes from (1,1,1) to (-1,1,1) along a circular arc. At the midpoint, its position is (0,1,sqrt(2)) or something like that (depending on the rotation axis). Wait, no. The rotation is around the Y axis through the origin. So the cubie at (1,1,1) rotates to (-1,1,1) along a circle in the X-Z plane at Y=1. The circle has radius sqrt(1^2 + 1^2) = sqrt(2). At the midpoint (45°), the position is (0, 1, sqrt(2)) ≈ (0, 1, 1.414). But the big cube only extends to Z=±1.5, so the cubie is still within the cube at the midpoint. But its X position is 0, which is internal.

So during the animation, the cubie's X position goes from 1 to 0 to -1. At X=1, the +x face is exterior. At X=0, the +x face is internal (it's at X=0.5, which is inside the cube). At X=-1, the -x face is exterior.

So the visibility of the +x sticker changes during the animation: it's visible at the start, becomes hidden when X < 1, and the -x sticker becomes visible when X < -1... wait, at X=-1, the -x face is at X=-1.5, which is on the exterior.

So during the animation, the +x sticker should become hidden when the cubie's X position drops below 1, and the -x sticker should become visible when the cubie's X position drops below -1.

But this happens at specific moments during the animation. If I update visibility at each frame based on the visual position, the transition would be smooth (the sticker fades out as the cubie crosses the boundary). But with discrete visibility (visible/hidden), there would be a sudden change at the boundary.

Actually, for a 90° rotation, the cubie's X position goes from 1 to -1 continuously. The +x face is exterior when X >= 1, and internal when X < 1. So the +x sticker should be hidden as soon as X < 1 (which is immediately after the animation starts, since X decreases from 1). Similarly, the -x sticker should be visible when X <= -1, which is at the end of the animation.

So during the animation, the +x sticker is hidden (except at the very start), and the -x sticker is hidden (except at the very end). This means for most of the animation, both the +x and -x stickers are hidden, which is correct (the cubie is in the interior of the X range).

But wait, the cubie also has +y and -z stickers (for the cubie at (1,1,1)). The +y sticker is always exterior (Y=1 throughout the animation). The -z sticker: the cubie's Z position goes from 1 to 1 (wait, for (1,1,1) → (-1,1,1), Z goes from 1 to 1? No, let me recompute.

U turn: (x,y,z) → (-z, y, x). So (1,1,1) → (-1,1,1). Z goes from 1 to 1? No, the new Z is the old X, which is 1. So Z stays at 1. Wait, that's not right. Let me recompute: (1,1,1) → (-1, 1, 1). So X goes from 1 to -1, Y stays at 1, Z stays at 1.

Hmm, that doesn't seem right. Let me re-examine. U turn maps (x,1,z) → (-z, 1, x). So (1,1,1) → (-1, 1, 1). Yes, Z goes from 1 to 1 (unchanged). And X goes from 1 to -1.

But that means the cubie at (1,1,1) only moves in X, not in Z. That's because (1,1,1) is on the corner, and the U turn rotates it around the Y axis. The distance from the Y axis is sqrt(1^2 + 1^2) = sqrt(2), and after rotation, it's still sqrt(2) but in a different direction.

Wait, (1,1,1) → (-1,1,1): the distance from Y axis is sqrt(1^2 + 1^2) = sqrt(2) before and sqrt((-1)^2 + 1^2) = sqrt(2) after. Yes, consistent.

But the path: from (1,1,1) to (-1,1,1) along a 90° rotation around Y. The rotation is in the X-Z plane. Starting at (1,1) in X-Z, rotating 90° around the origin gives (-1, 1) in X-Z? Let me check: rotation by -90° around Y (our U convention): (x,z) → (-z, x). So (1,1) → (-1, 1). Yes.

So the path in X-Z is from (1,1) to (-1,1) along a 90° arc. The midpoint is at 45°: (1*cos45 - 1*sin45, 1*sin45 + 1*cos45) = (0, sqrt(2)) ≈ (0, 1.414). Wait, that's using +90° rotation. For -90° (our U), the midpoint is at -45°: (1*cos(-45) - 1*sin(-45), 1*sin(-45) + 1*cos(-45)) = (cos45 + sin45, -sin45 + cos45) = (sqrt(2), 0) ≈ (1.414, 0).

Hmm, let me just compute the parametric path. For rotation by angle θ around Y (where θ goes from 0 to -90° for U):
- x(t) = x*cos(θ(t)) + z*sin(θ(t))... wait, I need to use the correct formula.

Rotation around Y by angle θ (right-hand rule):
- x' = x*cos(θ) + z*sin(θ)
- z' = -x*sin(θ) + z*cos(θ)

For θ = -90° (our U): cos(-90)=0, sin(-90)=-1.
- x' = x*0 + z*(-1) = -z
- z' = -x*(-1) + z*0 = x

So (x,z) → (-z, x). For (1,1) → (-1, 1). Correct.

For the animation, θ goes from 0 to -90°. At time t (0 to 1), θ = -90° * t.
- x(t) = x*cos(-90t) + z*sin(-90t) = x*cos(90t) - z*sin(90t)
- z(t) = -x*sin(-90t) + z*cos(-90t) = x*sin(90t) + z*cos(90t)

For (1,1):
- x(t) = cos(90t) - sin(90t)
- z(t) = sin(90t) + cos(90t)

At t=0: (1,1). At t=1: (cos90 - sin90, sin90 + cos90) = (0-1, 1+0) = (-1, 1). Correct.
At t=0.5: (cos45 - sin45, sin45 + cos45) = (0.707 - 0.707, 0.707 + 0.707) = (0, 1.414). 

So at t=0.5, the cubie is at (0, 1, 1.414). The X position is 0, which is internal. The Z position is 1.414, which is... the big cube extends to Z=±1.5, so Z=1.414 is within the cube (the +z face of the cubie is at Z=1.414+0.5=1.914, which is outside the cube). Wait, that means the +z sticker is exterior at t=0.5?

Hmm, the big cube has side length 3 (cubie size 1, 3 cubies across). The exterior is at |X|=1.5, |Y|=1.5, |Z|=1.5. A cubie at position (px, py, pz) has its +z face at pz+0.5. This is on the exterior if pz+0.5 >= 1.5, i.e., pz >= 1.0.

At t=0.5, the cubie is at (0, 1, 1.414). Its +z face is at 1.414+0.5 = 1.914 > 1.5, so the +z sticker is exterior. Its -z face is at 1.414-0.5 = 0.914 < 1.5, so the -z sticker is internal.

But at t=0, the cubie is at (1, 1, 1). Its +z face is at 1.5, which is on the exterior. Its -z face is at 0.5, internal.

At t=1, the cubie is at (-1, 1, 1). Its +z face is at 1.5, exterior. Its -z face is at 0.5, internal.

So the +z sticker is always exterior during the animation (pz goes from 1 to 1.414 to 1, always >= 1). Good.

The +x sticker: at t=0, px=1, +x face at 1.5, exterior. At t=0.5, px=0, +x face at 0.5, internal. At t=1, px=-1, +x face at -0.5, internal.

So the +x sticker transitions from exterior to internal during the animation, around t=0 (immediately). Similarly, the -x sticker transitions from internal to exterior around t=1.

If I update visibility at each frame based on the visual position, the +x sticker would become hidden at t≈0 (when px drops below 1), and the -x sticker would become visible at t≈1 (when px drops to -1).

But this means for most of the animation, the +x and -x stickers are hidden. Only at the very start and end are they visible. This is correct behavior.

OK so updating visibility at each frame based on visual position is the right approach. Let me implement it.

At each frame during animation:
1. For each cubie in the layer, compute its visual position (mesh.position).
2. For each of the 6 faces, check if it's on the exterior:
   - +x: visible if mesh.position.x + 0.5 >= 1.5 - epsilon
   - -x: visible if mesh.position.x - 0.5 <= -1.5 + epsilon
   - +y: visible if mesh.position.y + 0.5 >= 1.5 - epsilon
   - -y: visible if mesh.position.y - 0.5 <= -1.5 + epsilon
   - +z: visible if mesh.position.z + 0.5 >= 1.5 - epsilon
   - -z: visible if mesh.position.z - 0.5 <= -1.5 + epsilon
3. Set the visibility of each sticker mesh accordingly.

But there's a subtlety: the sticker meshes are children of the cubie group, so they rotate with the cubie. The sticker on the +x face of the cubie is at local position (0.5, 0, 0) relative to the cubie center. When the cubie rotates, the sticker moves to a different world position. But the visibility check should be based on the world position of the sticker, not the cubie center.

Hmm, but actually, for a cubie at visual position (px, py, pz) with rotation R, the +x sticker is at world position (px, py, pz) + R*(0.5, 0, 0). The visibility depends on whether this world position is on the exterior.

But for simplicity, I can approximate: the +x sticker is on the exterior if the cubie's +x face is on the exterior, which is approximately when px + 0.5 >= 1.5 (if the cubie's +x axis is aligned with the world +x axis). But if the cubie is rotated, the +x sticker might be on a different face of the big cube.

Wait, this is the key issue. The cubie's stickers are in local space, and they rotate with the cubie. The visibility of a sticker depends on its world position, which depends on both the cubie's position and rotation.

For a cubie at (1,1,1) with identity rotation, the +x sticker is at world position (1.5, 1, 1), which is on the +x face of the big cube (exterior). After a U turn, the cubie is at (-1,1,1) with rotation R (90° around Y). The +x sticker is now at world position (-1,1,1) + R*(0.5,0,0) = (-1,1,1) + (0,0,0.5) = (-1,1,1.5), which is on the +z face of the big cube (exterior). So the +x sticker is still visible, but now on a different face of the big cube.

So the visibility of a sticker depends on its world position, which is (cubie_position + R * sticker_local_position). I need to compute this for each sticker and check if it's on the exterior.

This is more complex but doable. At each frame, for each cubie, for each of the 6 stickers:
1. Compute the sticker's world position: cubie.mesh.position + cubie.mesh.quaternion * sticker_local_position.
2. Check if it's on the exterior: |world_pos.x| >= 1.5 - epsilon (for x-face stickers), etc.

But actually, the sticker local positions are (±0.5, 0, 0), (0, ±0.5, 0), (0, 0, ±0.5). So the world position is cubie_pos + R * (±0.5, 0, 0) etc.

For the +x sticker: world_x = cubie_pos.x + R[0][0]*0.5 + R[0][1]*0 + R[0][2]*0 = cubie_pos.x + R[0][0]*0.5. This is on the exterior if |world_x| >= 1.5 - epsilon, and specifically world_x >= 1.5 - epsilon for the +x face of the big cube.

Wait, but the sticker should be on the exterior of the big cube, which means world_x >= 1.5 (for +x face) or world_x <= -1.5 (for -x face). But the sticker is on the +x face of the cubie, so its world_x = cubie_pos.x + R[0][0]*0.5. For this to be >= 1.5, we need cubie_pos.x + R[0][0]*0.5 >= 1.5.

Hmm, this is getting complicated. Let me simplify by using a different approach.

Alternative: Instead of tracking sticker visibility based on world position, I can track it based on the cubie's orientation and grid position. For a cubie at grid position (gx, gy, gz) with rotation

Let me think through the architecture before writing code.

I need to build a 3D Rubik's Cube (3x3x3) using Three.js. Let me plan:

1. **Cube state**: Represent the 3x3x3 cube with cubies. Each cubie has 6 stickers (faces) with colors. For a solved cube, the 6 faces have 6 distinct colors.

2. **Cubie representation**: Each of the 27 positions (3x3x3) has a cubie. Internal cubies (the center one at position (1,1,1) in 0-indexed) is hidden. Actually, in a real Rubik's cube, the center pieces are fixed and the corners and edges move. But for simplicity in 3D, I'll model all 27 cubies, with the center one (at position 1,1,1) being completely internal and not visible.

Wait, actually a real Rubik's cube has:
- 8 corner pieces (3 visible faces)
- 12 edge pieces (2 visible faces)
- 6 center pieces (1 visible face)
- 1 internal core (0 visible faces)

But for the 3D visual, I can model it as 26 visible cubies (all except the very center). Each cubie has 6 faces but only the ones on the exterior have colored stickers.

Let me think about this more carefully. For a clean implementation:

- Each cubie is a small box (size ~0.9 to leave gaps between cubies for boundaries)
- Each cubie has 6 colored faces (using 6 materials)
- For the solved state, assign colors based on position:
  - Right face (x=2): Red
  - Left face (x=0): Orange
  - Top face (y=2): White
  - Bottom face (y=0): Yellow
  - Front face (z=2): Green
  - Back face (z=0): Blue

- For interior faces (not on the exterior of the big cube), use a dark color or make them invisible.

Actually, the standard approach: each cubie has 6 sticker meshes. The stickers that face outward on the solved cube get the face color; interior-facing stickers get a dark color (or we just don't render them).

Let me think about the movement:

When we do a U (up) turn, we rotate the top layer (y=2 row) 90 degrees around the Y axis. The cubies in that layer get their positions rotated AND their orientations rotated.

The key challenge: each cubie has stickers on specific faces. When a cubie moves to a new position, its stickers maintain their relative orientation to the cubie. So we need to track each cubie's orientation.

Approach: Represent each cubie as a group with 6 child meshes (one per face). Each mesh has a material with the sticker color. The cubie group has a position and quaternion.

For moves:
1. Identify which cubies are in the layer being turned
2. Animate them rotating around the appropriate axis by 90 degrees
3. Update their positions and quaternions after the animation

Actually, a cleaner approach for animation: use a parent group for each layer. When turning a layer, put the cubies in that layer under a pivot group, animate the pivot, then after animation, update each cubie's actual position and quaternion.

Let me think about the data model:

```
cubies = [] // 27 cubies, each with:
  - position: {x, y, z} in {0,1,2}
  - quaternion: representing orientation
  - stickers: array of 6 colors (one per face direction)
```

Actually, let me simplify. I'll represent each cubie as a Three.js Group containing 6 plane meshes (stickers) positioned on the 6 faces. The group's position and rotation represent the cubie's location and orientation in the big cube.

For the solved state:
- Position (i,j,k) where i,j,k ∈ {0,1,2}
- The sticker on the +x face gets the "right" color if i=2, else dark
- The sticker on the -x face gets the "left" color if i=0, else dark
- Similarly for y (top/bottom) and z (front/back)

When we rotate a layer, we rotate all cubies in that layer around the appropriate axis. Their positions change and their orientations change.

Let me code this up.

For the rotation of a face:
- U (up): rotate the y=2 layer around +Y axis by 90° (clockwise when viewed from above)
- U': rotate -90°
- D (down): rotate the y=0 layer around +Y axis by 90° (but from below, so it's actually -90° from above perspective... need to think about this)

Actually, standard Rubik's cube notation:
- U: top face rotates 90° clockwise (looking from top)
- U': top face rotates 90° counter-clockwise
- D: bottom face rotates 90° clockwise (looking from bottom)
- D': bottom face rotates 90° counter-clockwise (from bottom)
- R: right face rotates 90° clockwise (looking from right)
- L: left face rotates 90° clockwise (looking from left)
- F: front face rotates 90° clockwise (looking from front)
- B: back face rotates 90° clockwise (looking from back)

For the 3D coordinate system (Three.js: Y up, Z toward viewer, X right):
- U: rotate y=2 layer around Y axis by +90° (clockwise from top)
- D: rotate y=0 layer around Y axis by -90° (clockwise from bottom = counter-clockwise from top)
- R: rotate x=2 layer around X axis by -90° (clockwise from right)
- L: rotate x=0 layer around X axis by +90° (clockwise from left)
- F: rotate z=2 layer around Z axis by +90° (clockwise from front)
- B: rotate z=0 layer around Z axis by -90° (clockwise from back)

Wait, let me be more careful. When looking at the right face from the right side, clockwise rotation means the top moves toward the front. In Three.js coordinates (Y up, Z toward viewer):
- Looking from +X direction toward origin, clockwise rotation around X axis: top (Y+) moves toward -Z (front)... hmm.

Let me think about this differently. I'll define rotations as quaternions and just make sure the inverses work.

For a U turn (top layer, looking from above):
- Axis: (0, 1, 0)
- Angle: +π/2 (clockwise when looking down from +Y)

For U' (inverse):
- Axis: (0, 1, 0)  
- Angle: -π/2

For D turn (bottom layer, looking from below):
- Axis: (0, 1, 0)
- Angle: -π/2 (clockwise when looking up from -Y, which is -π/2 from +Y perspective)

Wait, I need to be consistent. Let me define all rotations from the perspective of looking at the face from outside the cube.

For U (look from top, +Y direction):
- Rotate around Y axis by +π/2

For D (look from bottom, -Y direction):
- Rotate around Y axis by -π/2 (because clockwise from below = counter-clockwise from above)

For R (look from right, +X direction):
- Rotate around X axis by -π/2 (clockwise from right side)

For L (look from left, -X direction):
- Rotate around X axis by +π/2

For F (look from front, +Z direction):
- Rotate around Z axis by +π/2

For B (look from back, -Z direction):
- Rotate around Z axis by -π/2

Hmm, I need to verify these. Let me think about the right-hand rule.

For U: Looking from above (from +Y down), clockwise rotation. Right-hand rule: thumb points in +Y, fingers curl in the direction of positive rotation. So positive rotation around Y is counter-clockwise when looking from +Y toward origin. So clockwise from above = -π/2 around Y.

Wait no. Right-hand rule: if thumb points along axis (+Y), fingers curl from +X toward +Z. Looking from +Y down toward origin, +X is to the right, +Z is... in Three.js, if Y is up and we're looking from above, we see the XZ plane. +X is right, +Z is... it depends on convention. In Three.js default, +Z comes toward the viewer. So looking from above (down the Y axis), +X is right, +Z is up (toward top of screen). Positive rotation around Y: from +X toward +Z, which is counter-clockwise when looking from above.

So:
- U (clockwise from above) = -π/2 around Y axis
- U' = +π/2 around Y axis

Hmm, but the standard is U = clockwise from top. Let me just go with:
- U: rotate top layer by -π/2 around Y
- U': rotate top layer by +π/2 around Y

For D: Looking from below (from -Y up toward origin), clockwise. From below, +X is still right, but +Z is now pointing away (toward back). So clockwise from below: from +X toward -Z... that's... let me think. Actually, it's easier to think: D clockwise from below = U' clockwise from above = +π/2 around Y (from above perspective, the bottom layer rotates in the same direction as U' would).

Actually, let me reconsider. D move: hold the cube with top away from you, look at the bottom. Clockwise rotation of the bottom layer. This is equivalent to rotating the bottom layer by +π/2 around Y (from the standard perspective where we look at the front).

Let me just test by thinking about what happens to a cubie at position (1, 0, 1) (bottom center-front) under D:
- D rotates the bottom layer (y=0) clockwise when viewed from below
- From below, clockwise means: front goes to right, right goes to back, back goes to left, left goes to front
- So (1,0,1) [front-center-bottom] goes to (2,0,1) [right-center-bottom]
- In terms of rotation: this is +π/2 around Y axis? Let's see: rotating (1,0,1) by +π/2 around Y: x' = x*cos(π/2) - z*sin(π/2) = 0 - 1 = -1, z' = x*sin(π/2) + z*cos(π/2) = 1 + 0 = 1. So (1,0,1) → (-1,0,1). That's not right.

Let me recalculate. Rotation by angle θ around Y axis:
- x' = x*cos(θ) + z*sin(θ)
- z' = -x*sin(θ) + z*cos(θ)

Wait, I need to be careful about the convention. In Three.js, Quaternion.setFromAxisAngle uses the right-hand rule.

Rotation by θ around Y axis (right-hand rule, thumb in +Y):
- This rotates +X toward +Z
- x' = x*cos(θ) - z*sin(θ)
- z' = x*sin(θ) + z*cos(θ)

For θ = π/2: x' = -z, z' = x

So (1, 0, 1) → (-1, 0, 1) for θ=π/2. That moves front to left.

For D (clockwise from below), I want front to go to right. So (1,0,1) → (2,0,1)? No wait, position is in {0,1,2}. (1,0,1) is the center-bottom-front. After D (clockwise from below), front-center goes to... 

Let me think about this more carefully with a physical cube. Hold the cube with front facing you. The bottom layer (D) rotated clockwise when looking from below means: the front-bottom edge goes to the right-bottom, right-bottom goes to back-bottom, etc.

So position (1, 0, 2) [bottom, front-center] → (2, 0, 1) [bottom, right-center] → (1, 0, 0) [bottom, back-center] → (0, 0, 1) [bottom, left-center] → (1, 0, 2).

In terms of coordinates, for the bottom layer (y=0):
- (x, 0, z) → (z, 0, 2-x) ? Let's check:
  - (1, 0, 2) → (2, 0, 1) ✓
  - (2, 0, 1) → (1, 0, 0) ✓
  - (1, 0, 0) → (0, 0, 1) ✓
  - (0, 0, 1) → (1, 0, 2) ✓

So D maps (x, 0, z) → (z, 0, 2-x). 

What rotation is this? Let's see: this is a rotation around the Y axis. A point (x, 0, z) rotated by θ around Y:
- x' = x*cos(θ) - z*sin(θ)
- z' = x*sin(θ) + z*cos(θ)

For (1, 0, 2) → (2, 0, 1):
- 2 = 1*cos(θ) - 2*sin(θ)
- 1 = 1*sin(θ) + 2*cos(θ)

From the second: sin(θ) = 1 - 2*cos(θ)
Sub into first: 2 = cos(θ) - 2(1 - 2*cos(θ)) = cos(θ) - 2 + 4*cos(θ) = 5*cos(θ) - 2
So 5*cos(θ) = 4, cos(θ) = 4/5. That's not a standard angle. Hmm.

Wait, I think I'm confusing myself. The cubie positions are discrete (0, 1, 2), and the rotation maps them to new discrete positions. The rotation angle is π/2 (90°), but the mapping depends on the center of rotation.

For D, the bottom layer rotates around the Y axis through the center of the cube (y=0 plane, centered at x=1, z=1). So the rotation is around the point (1, 0, 1), not around the origin.

Let me redefine. For a D turn:
1. Translate so that (1, 0, 1) is at origin: (x-1, 0, z-1)
2. Rotate by θ around Y
3. Translate back: (x'+1, 0, z'+1)

For (1, 0, 2): translated to (0, 0, 1). After rotation by θ around Y:
- x' = 0*cos(θ) - 1*sin(θ) = -sin(θ)
- z' = 0*sin(θ) + 1*cos(θ) = cos(θ)

Translated back: (1-sin(θ), 0, 1+cos(θ))

For this to equal (2, 0, 1): 1-sin(θ) = 2 → sin(θ) = -1 → θ = -π/2.
Check: 1+cos(-π/2) = 1+0 = 1 ✓

So D = rotation by -π/2 around Y axis (through center of cube).

Let me verify with another point: (2, 0, 1) → (1, 0, 0)
Translated: (1, 0, 0). After rotation by -π/2: x' = 1*cos(-π/2) - 0*sin(-π/2) = 0, z' = 1*sin(-π/2) + 0*cos(-π/2) = -1. Translated back: (1, 0, 0) → (1, 0, 0). Wait that gives (1, 0, 0) but I expected (1, 0, 0). Let me recheck: (1, 0, 0) translated back from (0, 0, -1) is (1, 0, 0). Yes! ✓

So D = -π/2 around Y (through center).

Now for U (top layer, y=2, rotating around center (1, 2, 1)):
- U clockwise from above: front-top → right-top
- (1, 2, 2) → (2, 2, 1)
- Translated: (0, 0, 1). After rotation: want (1, 0, 0) → translated back (2, 2, 1). 
- x' = -sin(θ) = 1 → sin(θ) = -1 → θ = -π/2
- Check: z' = cos(θ) = 0 → 1+0 = 1 ✓

So U = -π/2 around Y as well? That doesn't seem right. U and D should be different.

Wait, U clockwise from above: looking down from above, the top layer rotates clockwise. Front-top edge goes to right-top. So (1, 2, 2) → (2, 2, 1).

But for D, clockwise from below: looking up from below, the bottom layer rotates clockwise. Front-bottom goes to right-bottom. So (1, 0, 2) → (2, 0, 1).

Both seem to be -π/2 around Y through their respective centers. But that can't be right because they'd rotate in the same direction.

Let me reconsider. When looking from above (from +Y), clockwise rotation means the front goes to the left, not the right. 

Imagine looking down at a clock on the floor. The clock's 12 is away from you (north), 3 is to your right (east), 6 is near you (south), 9 is to your left (west). Clockwise: 12→3→6→9→12. So north→east→south→west.

In our coordinate system, looking from above (+Y down toward origin):
- Front is +Z (south, near us at 6 o'clock)
- Right is +X (east, at 3 o'clock)
- Back is -Z (north, at 12 o'clock)
- Left is -X (west, at 9 o'clock)

Clockwise from above: front(+Z) → right(+X) → back(-Z) → left(-X) → front(+Z)

So (0, 2, 1) [top, center-back] → (1, 2, 2) [top, center-front]? No wait, back(-Z) → left(-X): (0, 2, 1) → should go to (-X direction)...

Hmm, let me reconsider the positions. In my coordinate system:
- x: 0=left, 1=center, 2=right
- y: 0=bottom, 1=center, 2=top
- z: 0=back, 1=center, 2=front

Looking from above (+Y toward -Y), we see the XZ plane with:
- +X = right
- +Z = front (toward viewer)

Wait, in Three.js, the default camera looks from (0,0,1) toward origin, so +Z is toward the camera (front). But if we're looking from above (from +Y), we're looking down, and the question is what does "clockwise" mean.

OK let me just be very explicit. I'll define the rotations in terms of the right-hand rule around the axis, applied to the layer centered at the face center.

For U (top face, y=2): The layer center is (1, 2, 1). Looking from above (from high Y toward the cube), clockwise rotation.
- In right-hand rule, "clockwise when looking from +Y" means rotation by -π/2 around Y (because positive rotation is counter-clockwise from +Y).

Wait, I think I had it right. Positive rotation around Y (right-hand rule, thumb in +Y) rotates +X toward +Z. Looking from +Y toward origin, +X is to the right, +Z is... let me think about the standard view. In Three.js, with the default camera at (0, 0, 1) looking at origin, +X goes right, +Y goes up, and +Z goes... toward the camera, so it comes out of the screen.

If I'm looking from above (camera at (0, 10, 0) looking down), I see the XZ plane. +X goes right, +Z goes... up? Or down? It depends on the camera orientation. In Three.js, if the camera is at (0, 10, 0) looking at (0, 0, 0), the camera's up vector is typically (0, 1, 0) by default, but since the camera is looking down, the up vector would be reoriented. Actually, Three.js OrbitControls handles this.

Let me not worry about the visual clockwise/counterclockwise and just define the moves mathematically, then verify that U followed by U' returns to solved state.

I'll define:
- U: rotate y=2 layer around Y axis by angle α through center (1, 2, 1)
- U': rotate y=2 layer around Y axis by -α through center (1, 2, 1)

Similarly for other faces. The key is that the inverse of each move restores the state.

Let me define the moves as follows (using right-hand rule rotations):

For a face rotation, I need to:
1. Find all cubies in that layer
2. For each cubie, compute its new position and new orientation after the rotation

The rotation is around the axis perpendicular to the face, through the center of the face.

For U (top face, y=2):
- Axis: (0, 1, 0), through point (1, 2, 1)
- Angle: -π/2 (clockwise from above, using right-hand rule)

For D (bottom face, y=0):
- Axis: (0, 1, 0), through point (1, 0, 1)  
- Angle: +π/2 (clockwise from below = counter-clockwise from above)

Wait, I need to be consistent. Let me define "clockwise from outside" for each face:
- U: clockwise from above (+Y side) → -π/2 around Y
- D: clockwise from below (-Y side) → +π/2 around Y (from above perspective, this is counter-clockwise, but from below it's clockwise)

Hmm, actually clockwise from below is the same rotational direction as counter-clockwise from above. So if U = -π/2 (clockwise from above), then D = +π/2 (clockwise from below).

But wait, U and D should rotate the layers in the same physical direction (both clockwise when viewed from their respective sides). When you do a U turn, the top layer rotates clockwise (from above). When you do a D turn, the bottom layer rotates clockwise (from below). These are actually the SAME rotational direction in 3D space (both are -π/2 around Y if we use the right-hand rule, because clockwise from below = clockwise from above in terms of the right-hand rule... no wait).

OK I think I'm overcomplicating this. Let me just define:

U: rotate top layer (y=2) by -π/2 around Y axis through (1,2,1)
D: rotate bottom layer (y=0) by +π/2 around Y axis through (1,0,1)

And verify that U followed by U' works.

Actually, for the purpose of this demo, what matters is:
1. Each move is a 90° rotation of a layer
2. The inverse move undoes it
3. The animation looks correct

Let me just pick reasonable angles and verify the inverse property.

Let me define:
- U: top layer, -π/2 around Y
- U': top layer, +π/2 around Y
- D: bottom layer, +π/2 around Y
- D': bottom layer, -π/2 around Y
- R: right layer, +π/2 around X
- R': right layer, -π/2 around X
- L: left layer, -π/2 around X
- L': left layer, +π/2 around X
- F: front layer, -π/2 around Z
- F': front layer, +π/2 around Z
- B: back layer, +π/2 around Z
- B': back layer, -π/2 around Z

Wait, I need to be more careful with R, L, F, B. Let me think about each:

R (right face, x=2): Looking from the right side (+X direction toward origin), clockwise.
- Right-hand rule: thumb in +X, fingers curl from +Y toward +Z (or -Z?).
- Positive rotation around X: +Y → +Z (right-hand rule with thumb in +X: fingers curl from +Y to +Z... actually, right-hand rule: x cross y = z, so rotation from y to z is positive around x).
- Looking from +X toward origin: +Y is up, +Z is... to the left? Let me think. If I'm standing on the +X side looking toward the origin, the Y axis goes up and the Z axis goes... I need to figure out the orientation.

In Three.js, with the default view (camera at (0,0,1) looking at origin):
- +X is to the right
- +Y is up
- +Z is toward the camera (out of screen)

If I move the camera to (10, 0, 0) looking at origin:
- The camera is on the +X side
- +Y is still up
- +Z is now... to the left? Or right?

The camera at (10, 0, 0) looking at (0, 0, 0) has its view direction as (-1, 0, 0). The up vector is (0, 1, 0) by default. The "right" direction of the camera is up × viewDirection = (0,1,0) × (-1,0,0) = (0*0 - 0*0, 0*(-1) - 0*0, 0*0 - 1*(-1)) = (0, 0, 1). So +Z is to the right of the camera.

So looking from +X toward origin:
- Up = +Y
- Right = +Z
- Clockwise rotation: up → right → down → left → up, i.e., +Y → +Z → -Y → -Z → +Y

For R (clockwise from right side): +Y → +Z, which is positive rotation around X (right-hand rule).

So R = +π/2 around X.

R' = -π/2 around X.

L (left face, x=0): Looking from -X toward origin, clockwise.
- From -X side, up = +Y, right = -Z (mirror of the right side view)
- Clockwise: +Y → -Z → -Y → +Z → +Y
- This is negative rotation around X (right-hand rule: +Y → -Z is -π/2)

So L = -π/2 around X.
L' = +π/2 around X.

F (front face, z=2): Looking from +Z toward origin, clockwise.
- From +Z side (camera at (0, 0, 10) looking at origin): view direction is (0, 0, -1), up is (0, 1, 0), right = up × viewDir = (0,1,0) × (0,0,-1) = (-1, 0, 0). So right = -X.
- Clockwise: +Y → -X → -Y → +X → +Y
- This is... rotation around Z. Positive rotation around Z (right-hand rule): +X → +Y. So +Y → -X is... let me compute. Rotation by θ around Z: x' = x*cos(θ) - y*sin(θ), y' = x*sin(θ) + y*cos(θ). For (0, 1, 0) [pointing in +Y] rotated to ( -1, 0, 0) [pointing in -X]: cos(θ) = 0, sin(θ) = -1? Let me check: x' = 0*cos(θ) - 1*sin(θ) = -sin(θ) = -1 → sin(θ) = 1. y' = 0*sin(θ) + 1*cos(θ) = cos(θ) = 0. So θ = π/2. But +Y → -X for θ=π/2... let me recheck.

Rotation by π/2 around Z: 
- x' = x*cos(π/2) - y*sin(π/2) = -y
- y' = x*sin(π/2) + y*cos(π/2) = x

So (0, 1, 0) → (-1, 0, 0). Yes! +Y → -X for +π/2 around Z.

So F = +π/2 around Z (clockwise from front).
F' = -π/2 around Z.

B (back face, z=0): Looking from -Z toward origin, clockwise.
- From -Z side: right = +X (mirror of front)
- Clockwise: +Y → +X → -Y → -X → +Y
- This is -π/2 around Z (since +Y → +X is -π/2: x' = -sin(θ) = 1 → sin(θ) = -1 → θ = -π/2)

So B = -π/2 around Z.
B' = +π/2 around Z.

Now let me summarize:
- U: top layer (y=2), -π/2 around Y, center (1, 2, 1)
- D: bottom layer (y=0), +π/2 around Y, center (1, 0, 1)
- R: right layer (x=2), +π/2 around X, center (2, 1, 1)
- L: left layer (x=0), -π/2 around X, center (0, 1, 1)
- F: front layer (z=2), +π/2 around Z, center (1, 1, 2)
- B: back layer (z=0), -π/2 around Z, center (1, 1, 0)

And inverses are the opposite angles.

Now, for the implementation:

Each cubie is a Three.js Group with 6 child meshes (one per face). The group has a position (in cube coordinates, scaled) and a quaternion.

For the solved state, the 27 cubies are at positions (i, j, k) where i, j, k ∈ {0, 1, 2}, scaled by some factor (e.g., cubie size = 1, gap = 0.05, so spacing = 1.05).

Each cubie's 6 stickers:
- +x face: colored if i=2 (right face of big cube), else dark
- -x face: colored if i=0 (left face), else dark
- +y face: colored if j=2 (top face), else dark
- -y face: colored if j=0 (bottom face), else dark
- +z face: colored if k=2 (front face), else dark
- -z face: colored if k=0 (back face), else dark

The 6 colors:
- Right (x+): Red
- Left (x-): Orange
- Top (y+): White
- Bottom (y-): Yellow
- Front (z+): Green
- Back (z-): Blue

For each move, I need to:
1. Identify cubies in the layer
2. For each cubie, compute new position and new quaternion after rotation
3. Animate the transition

For the animation, I'll use a TWEEN-like approach (manual animation with requestAnimationFrame). Since we can't import external libraries, I'll implement a simple animation system.

Actually, I can use Three.js's built-in animation or just manually interpolate.

Let me think about the animation approach:

When a move is triggered:
1. Queue the move (if no animation is in progress)
2. For each cubie in the layer, compute the target position and quaternion
3. Animate from current to target over ~300ms
4. During animation, disable further moves
5. After animation, update the cubie state

For computing the new position and quaternion:

Given a cubie at position pos (Vector3) and quaternion q, and a rotation defined by axis, angle, and center:

New position = center + R * (pos - center)
New quaternion = R * q (where R is the rotation quaternion)

Where R = Quaternion.setFromAxisAngle(axis, angle).

Let me implement this.

For the camera controls (orbit without turning faces):
- On mousedown on the background (not on the cube), start orbiting
- On mousemove, rotate the camera around the cube
- On wheel, zoom in/out (bounded)

Actually, the requirement says "Dragging the background orbits the camera without turning a face." So I need to distinguish between dragging on the cube (which might trigger a face turn) and dragging on the background (which orbits).

Hmm, but the requirement also says to provide buttons for the moves. So maybe dragging is only for orbiting, and moves are only through buttons. Let me re-read: "Dragging the background orbits the camera without turning a face." So dragging anywhere orbits, and moves are via buttons only. That simplifies things.

Actually, I think the intent is: drag to orbit (like OrbitControls), and use buttons for cube moves. No face-turning by dragging.

Let me implement orbit controls manually:
- Mouse drag: rotate camera around the cube center
- Wheel: zoom in/out with bounds

For the camera, I'll use a spherical coordinate system:
- radius: distance from cube center
- theta: azimuthal angle (around Y axis)
- phi: polar angle (from Y axis)

On drag, change theta and phi. On wheel, change radius (bounded).

Now let me code this up.

```html
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>3D Rubik's Cube</title>
  <style>
    /* styles */

  </style>
</head>
<body>
  <div id="container">
    <canvas id="canvas"></canvas>
    <div id="controls">
      <!-- buttons -->
    </div>
  </div>
  <script src="three.min.js"></script>
  <script>
    // main code
  </script>
</body>
</html>
```

Let me write the full implementation now.

Key design decisions:
1. Cubie size: 0.9 (with 0.1 gap between cubies, so spacing = 1.0)
   Actually, let me use cubie size 0.92 with spacing 1.0 (0.08 gap on each side... no, 0.04 gap on each side). Let me use size 0.9, spacing 1.0, so 0.05 gap on each side.

2. The cube center is at origin. Cubie positions range from -1.5 to 1.5 (for spacing 1.0, centered).

Wait, let me center it. If cubie positions are (i, j, k) with i,j,k ∈ {0,1,2}, and spacing = 1.0, then the world position is (i - 1, j - 1, k - 1). So positions range from -1 to 1.

3. Stickers: Each cubie has 6 plane meshes, one on each face. The planes are sized slightly smaller than the cubie face (e.g., 0.85 x 0.85) to show the cubie boundary.

4. Colors:
   - Right: #ff0000 (Red)
   - Left: #ff8c00 (Orange)  
   - Top: #ffffff (White)
   - Bottom: #ffff00 (Yellow)
   - Front: #00ff00 (Green)
   - Back: #0000ff (Blue)
   - Internal: #333333 (Dark gray)

Let me now write the code.

Actually, I realize I need to be careful about the sticker orientation. Each sticker is a plane that should face outward from the cubie. For a cubie at position (i, j, k) with orientation quaternion q, the stickers need to be rotated correctly.

Initially (solved state), all cubies have identity quaternion. The stickers are:
- +x sticker: plane at (0.5, 0, 0) relative to cubie center, facing +x
- -x sticker: plane at (-0.5, 0, 0), facing -x
- etc.

When the cubie rotates, the stickers rotate with it (since they're children of the cubie group).

For the animation, I'll rotate the cubie group's position and quaternion.

Let me think about the data structure:

```javascript
const CUBIE_SIZE = 0.9;
const SPACING = 1.0;
const COLORS = {
  right: 0xff0000,
  left: 0xff8c00,
  top: 0xffffff,
  bottom: 0xffff00,
  front: 0x00cc00,
  back: 0x0000ff,
  internal: 0x333333
};

// Each cubie:
// {
//   group: THREE.Group,
//   pos: {i, j, k},  // grid position
//   stickers: [color_r, color_l, color_u, color_d, color_f, color_b]  // sticker colors
// }

// Initially, create 27 cubies at grid positions (i,j,k) ∈ {0,1,2}^3
// For the center cubie (1,1,1), all stickers are internal (dark)
// For others, stickers on exterior faces get the face color

// When a move happens:
// 1. Find cubies in the layer
// 2. For each, compute new grid position and new quaternion
// 3. Animate
```

Wait, I need to track the cubie's orientation (quaternion) as well, because after multiple moves, a cubie might be rotated.

Let me define the cubie state as:
- gridPos: {i, j, k} - the current grid position
- quaternion: THREE.Quaternion - the current orientation relative to the solved state

Initially, all cubies have identity quaternion and their grid position is their initial position.

When a move happens:
1. For each cubie in the layer, compute:
   - newGridPos: the new grid position after rotation
   - newQuat: the new quaternion after rotation (R * oldQuat)
2. Animate the cubie group from current position/quat to new position/quat

After animation completes, update the cubie's gridPos and quaternion.

For the grid position computation, I need to apply the rotation to the grid position (centered at the face center).

Let me define the rotation function:

```javascript
function rotatePos(pos, axis, angle, center) {
  // Rotate pos around axis by angle, centered at center
  const v = new THREE.Vector3(pos.x - center.x, pos.y - center.y, pos.z - center.z);
  // Apply rotation
  const q = new THREE.Quaternion().setFromAxisAngle(axis, angle);
  v.applyQuaternion(q);
  return new THREE.Vector3(v.x + center.x, v.y + center.y, v.z + center.z);
}
```

But the grid positions are discrete (0, 1, 2). After rotation, they should still be in {0, 1, 2}. Due to floating point, I need to round.

Let me also think about the sticker colors. The sticker colors are fixed to the cubie (they don't change when the cubie moves). The sticker on the +x face of the cubie always has the same color, regardless of where the cubie is. This is what "preserve cubie and sticker state through moves" means.

So each cubie has 6 sticker colors that are assigned at creation time based on the cubie's initial position. When the cubie moves, the stickers move with it.

For the solved state:
- Cubie at (2, 1, 1) (right center): +x sticker is red, others are dark
- Cubie at (0, 1, 1) (left center): -x sticker is orange, others are dark
- etc.

When the cube is scrambled, a cubie that started at (2, 1, 1) might be at (1, 2, 2) with a rotated orientation, and its +x sticker (red) might now be facing up or front or whatever.

This is correct Rubik's cube behavior.

Now let me implement this.

For the animation, I'll use a simple approach:
- When a move is triggered, set an `isAnimating` flag
- Compute target positions and quaternions for all cubies in the layer
- Use requestAnimationFrame to interpolate over ~300ms
- After animation, update the state and clear the flag

For queuing: if a move is triggered while animating, queue it. After the current animation completes, start the next one.

Let me write the code now.

Actually, let me think about one more thing: the cubie boundaries. The requirement says "visible cubie boundaries." This means I should render the cubies with a slight gap between them, and perhaps a dark border/outline.

I'll use a dark material for the cubie body (the edges) and colored materials for the stickers. The cubie body can be a box with a dark material, and the stickers are planes on the faces.

Actually, a simpler approach: each cubie is a box with a dark/border material, and the stickers are slightly smaller planes on each face. The gap between cubies (0.1) shows the dark background, creating visible boundaries.

Let me also add a subtle border to each sticker by using a slightly larger dark plane behind it, or by using a texture. But since we can't use external assets, I'll use a simple approach: the cubie body is a box with a dark material, and stickers are planes on the faces.

Actually, the simplest approach that looks good:
1. Each cubie is a THREE.BoxGeometry with a dark material (the "body")
2. On each face, add a slightly smaller plane with the sticker color
3. The gap between cubies (0.1 spacing - 0.9 size = 0.1 total gap, 0.05 per side) shows the dark background

Wait, but the box body would cover the stickers. Let me think...

Better approach:
1. Each cubie is a Group
2. The group has a BoxGeometry mesh with dark material (slightly smaller than the full cubie, e.g., 0.88) - this creates the border effect
3. On each of the 6 faces, a plane mesh with the sticker color (0.85 x 0.85) positioned on the face

The dark box shows through the gaps, creating boundaries.

Actually, even simpler: just use the gap between cubies. If cubies are 0.9 and spacing is 1.0, there's a 0.1 gap between adjacent cubies. The background (scene background) shows through, creating visible boundaries. I don't need a dark box body.

But to make the cubie edges more visible, I can add a thin border. Let me use a slightly different approach:
- Each cubie has a box mesh with a dark gray material (size 0.9)
- On each face, a sticker plane (size 0.82) with the face color
- The dark gray box edges show as boundaries

Hmm, but the box would be solid and cover the stickers. I need the stickers to be on top.

OK, let me use this approach:
- Each cubie group contains:
  - 6 plane meshes (stickers), one on each face, each with the sticker color
  - The planes are positioned at ±0.45 on each axis (half of 0.9)
  - Each plane is 0.82 x 0.82 (slightly smaller than the cubie face)
  - The planes have a small gap from the cubie edge, creating a border effect

The background color (light gray or dark) shows through the gaps between cubies, creating boundaries.

Let me go with this. I'll use a dark scene background and light-colored stickers.

Now let me also think about the visual quality:
- Add some lighting (directional light + ambient light) to make the cube look 3D
- Use MeshStandardMaterial or MeshPhongMaterial for the stickers
- The cubie edges can be highlighted by the gap between cubies

Let me write the code now. I'll be comprehensive.

Actually, I realize I should also handle the case where the center cubie (1,1,1) is completely internal and has no visible stickers. In a real Rubik's cube, this cubie doesn't exist (it's the core). But for our 3D model, we can either:
1. Not create it (only 26 cubies)
2. Create it with all dark stickers (invisible)

I'll go with option 1: only create 26 cubies (skip the center one).

Wait, but when we rotate a layer, the center cubie of that layer stays in place (it's the center of the face). For example, in a U turn, the cubie at (1, 2, 1) (top center) stays at (1, 2, 1) but rotates. Actually, in a real Rubik's cube, the center pieces are fixed to the core and don't move relative to the core. But the face centers do rotate (their orientation changes).

For our model, I'll treat all 26 cubies as movable. The face centers (like (1,2,1) for the top face) will stay in their grid position but their orientation (quaternion) will change during a face turn.

Actually, for the face center cubies, their position doesn't change during a face turn (they're at the center of the face), but their orientation does. For corner and edge cubies, both position and orientation change.

Let me verify: in a U turn (top layer, y=2):
- Cubie at (1, 2, 1) (top center): stays at (1, 2, 1), but rotates by -π/2 around Y
- Cubie at (0, 2, 0) (top-back-left corner): moves to (0, 2, 2) (top-front-left corner)? Let me compute.

U: rotate around Y by -π/2, centered at (1, 2, 1).
Position (0, 2, 0) relative to center: (-1, 0, -1).
After rotation by -π/2 around Y: 
- x' = x*cos(-π/2) - z*sin(-π/2) = 0 - (-1)*(-1) = -1... wait, let me recalculate.
- cos(-π/2) = 0, sin(-π/2) = -1
- x' = x*0 - z*(-1) = z = -1
- z' = x*(-1) + z*0 = -x = 1

So relative position: (-1, 0, -1) → (-1, 0, 1). Absolute: (0, 2, 2).

So (0, 2, 0) → (0, 2, 2). That's top-back-left → top-front-left. Let me verify: looking from above, back-left should go to front-left? Clockwise from above: back → left → front → right → back. So back-left → left-front? No, back-left corner goes to left-front corner. In coordinates: (0, 2, 0) [back-left] → (0, 2, 2) [front-left]. Yes, that's correct!

Let me verify another: (2, 2, 0) [top-back-right] → ?
Relative: (1, 0, -1). After rotation: x' = -1, z' = -1. Absolute: (0, 2, 0). So (2, 2, 0) → (0, 2, 0). Back-right → back-left. Clockwise from above: back → left, so back-right → left-right? No, back-right corner goes to left-back corner. In coordinates: (2, 2, 0) → (0, 2, 0). Yes, right-back → left-back. ✓

Great, the rotation seems correct.

Now let me code the full solution.

Here's my plan for the code structure:

```javascript
// 1. Scene setup (scene, camera, renderer, lights)
// 2. Camera controls (orbit with drag, zoom with wheel)
// 3. Cube state management
//    - Create 26 cubies
//    - Each cubie has a group with 6 sticker meshes
//    - Track grid position and quaternion for each cubie
// 4. Move execution
//    - Define moves (U, D, L, R, F, B and inverses)
//    - For each move, find affected cubies, compute new positions/quaternions
//    - Animate
// 5. Animation system
//    - Queue moves
//    - Animate one at a time
// 6. UI controls
//    - Buttons for each move
//    - Scramble button
//    - Reset button
// 7. Render loop
```

Let me write this now.

For the scramble: generate a sequence of random moves (at least 10-20), execute them one by one with animation.

For reset: restore all cubies to their initial positions and orientations, and reset the camera.

Let me also think about the camera initial position. I want the cube fully visible initially. A good position would be at a 45° angle, about 5 units away.

Camera at (4, 3, 4) looking at origin, or use spherical coordinates: radius=5, theta=π/4, phi=π/4.

OK, let me write the code.

One more thing: the "internal" stickers. For cubies that have faces not on the exterior of the big cube, those stickers should be dark/invisible. I'll use a dark gray color (0x333333) for internal stickers.

But actually, for a more realistic look, I could make internal stickers invisible (not render them). But that complicates things because when a cubie moves, a sticker that was internal might become external. So I need to keep all 6 stickers and just change their visibility/color based on whether they're on the exterior.

Wait, no. The sticker colors are fixed to the cubie. A sticker that's red (because it started on the right face) is always red, even when the cubie is in the interior. But when the cubie is in the interior, that sticker is not visible (it's facing inward).

So I need to track which stickers are visible based on the cubie's current position. A sticker on the +x face of a cubie is visible if the cubie's grid position has i=2 (right face of big cube).

But wait, the sticker's visibility depends on the cubie's orientation too. If the cubie is rotated, a sticker that was on the +x face might now be facing a different direction.

Actually, in a Rubik's cube, the stickers are physically attached to the cubie. When the cubie moves, the stickers move with it. A sticker is visible if it's on the exterior of the big cube, which depends on both the cubie's position and orientation.

For a cubie at grid position (i, j, k) with orientation quaternion q:
- The +x sticker is visible if the cubie's +x direction (after rotation by q) points to the exterior of the big cube in the +x direction, AND the cubie is at i=2.

Hmm, this is getting complicated. Let me think about it differently.

In a real Rubik's cube, each cubie has stickers on specific faces. When the cubie is in its solved position, the stickers that are on the exterior are the ones facing outward. When the cubie moves, the stickers move with it, and some stickers that were interior become exterior and vice versa.

For our 3D model, I'll make all 6 stickers visible always (they're rendered as planes on the cubie faces). But I'll only color the stickers that should be visible based on the cubie's initial position. The internal stickers will be dark.

Wait, but that's not right either. When a cubie moves to a new position, its stickers should show the correct colors based on the cubie's identity, not its position.

OK, I think the correct approach is:
1. Each cubie has 6 stickers with fixed colors (assigned at creation based on initial position)
2. All 6 stickers are always rendered
3. The "internal" stickers (those not on the exterior of the big cube in the solved state) are dark
4. When the cube is scrambled, the stickers maintain their colors, and the visual result is correct

For example, a corner cubie at (2, 2, 2) [top-right-front] has 3 colored stickers (right=red, top=white, front=green) and 3 dark stickers (left, bottom, back). When this cubie moves to a different position, the 3 colored stickers move with it, and the 3 dark stickers are hidden in the interior.

But wait, when the cubie is at a new position, some of its dark stickers might become exterior (facing outward). In a real Rubik's cube, those faces don't have stickers (they're internal faces of the cubie). So they should appear as the cubie's body color (dark/black).

So the approach is correct: colored stickers for exterior faces (in solved state), dark for interior faces. The dark stickers represent the unstickered faces of the cubie.

This is exactly how a real Rubik's cube looks. The internal faces of the cubies are black/dark, and only the exterior faces have colored stickers.

Great, so my approach is correct. Let me implement it.

Now, one more consideration: when a cubie is in the interior of the big cube (not on any face), all its stickers are dark and it's essentially invisible. But in a real Rubik's cube, the interior cubies (edges and corners when scrambled) can be in the interior, and you can't see them. But for our 3D model, the cubies are always visible (they're 3D objects with gaps between them).

Actually, in a 3D Rubik's cube visualization, all cubies are visible regardless of their position, because there are gaps between them. The "internal" stickers are just dark, but the cubie itself is visible as a dark cube.

This is fine. The visual result will look like a Rubik's cube with visible cubie boundaries.

Let me now write the code.

Let me also think about the cubie geometry more carefully. I want:
- Each cubie to be a small box with visible edges
- Stickers on the 6 faces

I'll create each cubie as a Group with:
- 6 plane meshes for stickers (one per face)
- Each plane is a PlaneGeometry(0.82, 0.82) positioned at ±0.45 on the appropriate axis

The gap between cubies (0.05 on each side, since spacing=1.0 and cubie size=0.9) will show the background, creating boundaries.

Actually, I want the cubie to have a visible "body" too, not just stickers floating in space. Let me add a box mesh with a dark material as the cubie body, slightly smaller than the sticker planes.

Wait, if I add a box body, it would be behind the stickers. The stickers are planes at the faces, and the box is the cubie body. The box should be slightly smaller than the spacing (e.g., 0.88) so there's a gap between cubies. The stickers are on the faces of the box.

Actually, let me simplify: just use the sticker planes. The gap between cubies (0.05) shows the background, and the sticker planes (0.82 x 0.82) are positioned at the face centers. The "body" of the cubie is implied by the sticker planes forming a cube.

But this looks weird because you can see through the cubie (there's no body, just 6 planes). To fix this, I can:
1. Add a box body with a dark material
2. Make the stickers slightly raised (positioned slightly outside the box)

Let me go with option 1: each cubie has a box body (dark gray) and 6 sticker planes on the faces.

The box body: BoxGeometry(0.88, 0.88, 0.88), MeshStandardMaterial({color: 0x222222, roughness: 0.8})
The stickers: PlaneGeometry(0.82, 0.82), positioned at ±0.44 on each axis, with the sticker color

Wait, the sticker planes need to face outward. I'll use Quaternion to rotate them.

For the +x sticker: position (0.44, 0, 0), rotation such that it faces +x (default plane faces +Z, so rotate -π/2 around Y)
For the -x sticker: position (-0.44, 0, 0), facing -x
etc.

Actually, in Three.js, PlaneGeometry creates a plane in the XY plane, facing +Z. To make it face +X, I rotate it -π/2 around Y. To face -X, rotate +π/2 around Y. To face +Y, rotate -π/2 around X. To face -Y, rotate +π/2 around X. To face -Z, rotate π around Z (or just scale by -1 on Z).

Let me define a helper:

```javascript
function createSticker(color, position, rotation) {
  const geo = new THREE.PlaneGeometry(0.82, 0.82);
  const mat = new THREE.MeshStandardMaterial({color, roughness: 0.3, metalness: 0.1});
  const mesh = new THREE.Mesh(geo, mat);
  mesh.position.set(position.x, position.y, position.z);
  mesh.quaternion.setFromAxisAngle(rotation.axis, rotation.angle);
  return mesh;
}
```

For the 6 faces:
- +x: pos (0.44, 0, 0), rot (-π/2 around Y)
- -x: pos (-0.44, 0, 0), rot (π/2 around Y)
- +y: pos (0, 0.44, 0), rot (-π/2 around X)
- -y: pos (0, -0.44, 0), rot (π/2 around X)
- +z: pos (0, 0, 0.44), rot (0, identity)
- -z: pos (0, 0, -0.44), rot (π around Z)

OK let me just write the full code now. I've thought about this enough.

Let me also think about the move definitions more carefully.

For each move, I need:
1. Which layer (which grid coordinate and value)
2. Rotation axis
3. Rotation angle
4. Center of rotation

Here are the moves:

```javascript
const MOVES = {
  U:  { layer: 'y', value: 2, axis: (0,1,0), angle: -Math.PI/2, center: (1, 2, 1) },
  U1: { layer: 'y', value: 2, axis: (0,1,0), angle: Math.PI/2, center: (1, 2, 1) },
  D:  { layer: 'y', value: 0, axis: (0,1,0), angle: Math.PI/2, center: (1, 0, 1) },
  D1: { layer: 'y', value: 0, axis: (0,1,0), angle: -Math.PI/2, center: (1, 0, 1) },
  R:  { layer: 'x', value: 2, axis: (1,0,0), angle: Math.PI/2, center: (2, 1, 1) },
  R1: { layer: 'x', value: 2, axis: (1,0,0), angle: -Math.PI/2, center: (2, 1, 1) },
  L:  { layer: 'x', value: 0, axis: (1,0,0), angle: -Math.PI/2, center: (0, 1, 1) },
  L1: { layer: 'x', value: 0, axis: (1,0,0), angle: Math.PI/2, center: (0, 1, 1) },
  F:  { layer: 'z', value: 2, axis: (0,0,1), angle: Math.PI/2, center: (1, 1, 2) },
  F1: { layer: 'z', value: 2, axis: (0,0,1), angle: -Math.PI/2, center: (1, 1, 2) },
  B:  { layer: 'z', value: 0, axis: (0,0,1), angle: -Math.PI/2, center: (1, 1, 0) },
  B1: { layer: 'z', value: 0, axis: (0,0,1), angle: Math.PI/2, center: (1, 1, 0) },
};
```

Wait, I need to double-check the D move. D is clockwise from below. From below (looking up from -Y), clockwise means... let me think. If I'm below the cube looking up, the front is still +Z (toward me if I'm in front of the cube, but now I'm below). Actually, "from below" means I'm on the -Y side looking toward +Y. From this perspective, +Z is to my left or right?

If I'm at (0, -10, 0) looking at (0, 0, 0), my view direction is (0, 1, 0). My up vector is... typically (0, 0, 1) or (0, 0, -1) depending on convention. In Three.js, the default up is (0, 1, 0), but since I'm looking along Y, the up vector would be reoriented.

Actually, let me just define D as the inverse of U' (or equivalently, D should rotate the bottom layer in the same physical direction as U rotates the top layer, when viewed from outside).

U: top layer rotates clockwise from above → -π/2 around Y
D: bottom layer rotates clockwise from below → also -π/2 around Y? 

No, clockwise from below is the opposite direction from clockwise from above. If you look at a clock from behind, the hands move counter-clockwise. Similarly, clockwise from below = counter-clockwise from above = +π/2 around Y.

So D = +π/2 around Y, and D' = -π/2 around Y.

But wait, that means U and D' are the same rotation direction, and U' and D are the same. Is that correct?

Let me think about it physically. Hold a cube with the top facing up and front facing you. Do a U turn (top layer clockwise from above). Then do a D turn (bottom layer clockwise from below). The bottom layer, when viewed from above, rotates counter-clockwise. So U and D rotate in opposite directions (from above perspective).

From the right-hand rule perspective:
- U: -π/2 around Y (clockwise from above)
- D: +π/2 around Y (clockwise from below = counter-clockwise from above)

Yes, that's correct.

Now let me verify: U followed by U' should return to solved state.
- U: top layer rotated by -π/2 around Y
- U': top layer rotated by +π/2 around Y
- Net: 0 rotation ✓

D followed by D':
- D: bottom layer rotated by +π/2 around Y
- D': bottom layer rotated by -π/2 around Y
- Net: 0 rotation ✓

Now let me verify the R, L, F, B moves.

R: right layer (x=2), clockwise from right side.
- From right side (+X), looking toward origin: up = +Y, right = +Z (as computed earlier)
- Clockwise: +Y → +Z → -Y → -Z → +Y
- This is +π/2 around X (right-hand rule: +Y → +Z is positive rotation around X)

R' = -π/2 around X.

L: left layer (x=0), clockwise from left side.
- From left side (-X), looking toward origin: up = +Y, right = -Z
- Clockwise: +Y → -Z → -Y → +Z → +Y
- This is -π/2 around X (right-hand rule: +Y → -Z is negative rotation around X)

L' = +π/2 around X.

F: front layer (z=2), clockwise from front.
- From front (+Z), looking toward origin: up = +Y, right = -X
- Clockwise: +Y → -X → -Y → +X → +Y
- This is +π/2 around Z (right-hand rule: +X → +Y is positive around Z, so +Y → -X is also +π/2? Let me check: rotation by π/2 around Z: (0,1,0) → (-1,0,0). Yes, +Y → -X for +π/2 around Z.)

F' = -π/2 around Z.

B: back layer (z=0), clockwise from back.
- From back (-Z), looking toward origin: up = +Y, right = +X
- Clockwise: +Y → +X → -Y → -X → +Y
- This is -π/2 around Z (right-hand rule: +Y → +X is -π/2 around Z? Rotation by -π/2 around Z: (0,1,0) → (1,0,0). Yes, +Y → +X for -π/2 around Z.)

B' = +π/2 around Z.

Great, my move definitions are consistent.

Now let me write the complete code. I'll be thorough.

Let me think about the structure once more:

```
Scene setup:
- Scene with dark background
- PerspectiveCamera
- WebGLRenderer
- AmbientLight + DirectionalLight

Cube:
- 26 cubies, each a Group with:
  - Box body (dark)
  - 6 sticker planes
- Stored in an array with metadata (gridPos, quaternion)

Camera controls:
- Mouse drag: orbit
- Wheel: zoom (bounded)

Move system:
- Move definitions (U, D, L, R, F, B, U', D', L', R', F', B')
- Execute move: find cubies in layer, compute new pos/quat, animate
- Animation queue

UI:
- Buttons for each move
- Scramble button
- Reset button
- Display current scramble moves (optional)
```

Let me write it now. I'll aim for clean, well-organized code.

For the button layout, I'll arrange them in a 3x4 grid (U, D, L, R, F, B and their inverses) plus Scramble and Reset.

Actually, let me lay them out like a Rubik's cube face notation:
```
        U   U'
      L   R   F   B
        D   D'
```
Plus Scramble and Reset.

Or I can do a simpler grid layout. Let me do:
```
[U] [U'] [L] [L'] [R] [R'] [F] [F'] [B] [B'] [D] [D']
[Scramble] [Reset]
```

Let me write the code now.

Actually, for the button labels, I'll use standard notation:
- U, U', D, D', R, R', L, L', F, F', B, B'

In HTML, I'll use U¹ for U' (or just U' if the font supports it).

Let me use U' for simplicity.

Now, let me think about one more thing: the cubie body. I said I'd use a box with dark material. But the stickers are planes on the faces. The box body would be behind the stickers. But if the box is 0.88 and the stickers are at 0.44 (half of 0.88), the stickers would be on the surface of the box. That works.

Actually, let me use a slightly different approach. Instead of a box body + sticker planes, I'll use:
- A box body with a dark material (size 0.9)
- Sticker planes (size 0.82) positioned slightly outside the box (at 0.46 instead of 0.45)

Wait, that would make the stickers float outside the box. Let me just put them at the surface.

Let me use:
- Box body: 0.88 x 0.88 x 0.88, dark gray
- Stickers: 0.82 x 0.82, positioned at ±0.44 on each axis (surface of the box)

The stickers are slightly smaller than the box face, creating a dark border around each sticker. This looks like a real Rubik's cube.

OK, let me write the code now. I've been planning for too long.

Let me also think about the initial camera position. I want the cube to be fully visible and nicely angled. I'll use:
- Camera at (3.5, 2.5, 3.5) looking at origin
- This gives a nice 3/4 view

For the orbit controls, I'll use spherical coordinates:
- radius: distance from origin
- theta: azimuth (around Y axis)
- phi: polar angle (from Y axis)

Initial: radius = sqrt(3.5² + 2.5² + 3.5²) ≈ 5.32, theta = atan2(3.5, 3.5) = π/4, phi = acos(2.5/5.32) ≈ 1.14

On drag, I'll update theta and phi. On wheel, I'll update radius (bounded between 3 and 10).

Let me write the code now.

One more thing: the requirement says "Animate each move and queue or disable further moves until it completes so state is not corrupted." So I need to either queue moves or disable buttons during animation. I'll disable the move buttons during animation and queue scramble moves.

For scramble, I'll generate a sequence of random moves and execute them one by one, waiting for each animation to complete before starting the next.

For reset, I'll immediately reset the cube state (no animation needed, or a quick animation).

Let me write the code.

Actually, for reset, I should animate it too for consistency. But the requirement says "Reset to restore the solved cube and initial camera." So I need to reset both the cube and the camera. I'll do this instantly (or with a quick animation).

Let me go with instant reset for simplicity.

OK, writing the code now.

Let me think about the file structure. It's a single HTML file with inline CSS and JS. The three.min.js is loaded from a local script tag.

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>3D Rubik's Cube</title>
  <style>
    /* CSS */

  </style>
</head>
<body>
  <div id="app">
    <div id="canvas-container"></div>
    <div id="controls">
      <!-- buttons -->
    </div>
  </div>
  <script src="three.min.js"></script>
  <script>
    // All the JS
  </script>
</body>
</html>
```

Let me write the full code now. I'll be comprehensive and handle all the requirements.

Here's the full implementation:

Actually, let me think about one more edge case. When animating a move, I need to animate all cubies in the layer simultaneously. Each cubie has a starting position/quat and an ending position/quat. I'll interpolate between them.

For position interpolation: linear interpolation (lerp)
For quaternion interpolation: spherical linear interpolation (slerp)

Three.js provides Quaternion.slerp for this.

For the animation, I'll use requestAnimationFrame and track the elapsed time.

```javascript
function animateMove(moveDef, duration = 300) {
  return new Promise(resolve => {
    const cubiesInLayer = cubies.filter(c => c.gridPos[moveDef.layer] === moveDef.value);
    
    // Compute target positions and quaternions
    const targets = cubiesInLayer.map(cubie => {
      const startPos = cubie.group.position.clone();
      const startQuat = cubie.group.quaternion.clone();
      
      // Compute new grid position
      const newGridPos = RotateGridPosition(
        cubie.gridPos, 
        moveDef.layer, 
        moveDef.value, 
        moveDef.axis, 
        moveDef.angle, 
        moveDef.center
      );
      
      // Compute new world position
      const newPos = new THREE.Vector3(
        (newGridPos.x - 1) * SPACING,
        (newGridPos.y - 1) * SPACING,
        (newGridPos.z - 1) * SPACING
      );
      
      // Compute new quaternion
      const rot

The file is large. Let me check if THREE is available as a global. Let me now write the full index.html. I'll design the Rubik's Cube carefully.

Key design decisions:
1. Use 27 cubies (3x3x3), each is a small box with colored faces
2. Track cubie positions and orientations with a data structure
3. For moves, animate cubies by rotating them around the appropriate axis
4. Camera orbit with drag, zoom with wheel

Let me think about the cubie representation more carefully.

Each cubie has a position in the 3x3x3 grid: (i, j, k) where i, j, k ∈ {0, 1, 2} or {-1, 0, 1}.

For a solved cube:
- Corner cubies (8): have 3 colored faces
- Edge cubies (12): have 2 colored faces
- Center cubies (6): have 1 colored face
- Core cubie (1): has 0 colored faces (hidden)

For the 3D model, I'll create each cubie as a box with 6 faces. Each face has a color. For faces that are on the exterior of the big cube, the color is the face color. For interior faces, the color is dark/black.

Wait, but the requirement says "visible cubie boundaries." This means I should show the gaps between cubies so you can see the individual cubies. I'll use a small gap between cubies.

Let me use:
- Cubie size: 0.9 (with 0.1 gap between cubies, so spacing = 1.0)
- Actually, let me use size 0.95 with spacing 1.0, giving 0.05 gap on each side

Or better: size 0.9, spacing 1.0, giving 0.05 gap on each side (0.1 total between adjacent cubies).

For the colors, I'll use the standard Rubik's cube colors:
- Right: Red (#ff0000)
- Left: Orange (#ff8c00 or #ff6600)
- Top: White (#ffffff)
- Bottom: Yellow (#ffff00)
- Front: Green (#00cc00)
- Back: Blue (#0044ff)

For the cubie body (the visible edges), I'll use a dark gray or black material.

Wait, if I use a box with different materials per face, I can use an array of 6 materials. But when the cubie rotates, the materials rotate with it (since they're applied to the geometry faces in local space).

Actually, in Three.js, when you create a BoxGeometry and pass an array of 6 materials, the materials are applied to the 6 faces in the order: +x, -x, +y, -y, +z, -z. When the mesh rotates, the materials rotate with it (they're in local space).

So for each cubie, I create a BoxGeometry with 6 materials. The materials are:
- +x: colored if the cubie is on the right face of the big cube (i=2), else dark
- -x: colored if on the left face (i=0), else dark
- +y: colored if on the top face (j=2), else dark
- -y: colored if on the bottom face (j=0), else dark
- +z: colored if on the front face (k=2), else dark
- -z: colored if on the back face (k=0), else dark

Wait, but when the cubie moves, its materials should stay the same (they're fixed to the cubie). The cubie's orientation changes, so the materials appear on different sides of the big cube.

This is exactly what I want. The materials are fixed to the cubie, and when the cubie rotates, the materials rotate with it.

But there's a subtlety: the BoxGeometry materials are in local space. When the mesh rotates, the materials rotate with it. So if I create a cubie with a red material on the +x face, and then rotate the cubie 90° around Y, the red material will now be on the +z face (in world space).

This is correct Rubik's cube behavior.

So my approach:
1. Create 27 cubies, each with a BoxGeometry and 6 materials
2. The materials are assigned based on the cubie's initial position
3. Each cubie is a Mesh with position and quaternion
4. For moves, update the position and quaternion of cubies in the affected layer

For the animation, I'll interpolate the position and quaternion.

Let me now think about the data structure for tracking cubie state.

I'll use an array of 27 cubie objects:
```javascript
cubies = [
  {
    mesh: THREE.Mesh,
    gridPos: { i, j, k },  // current grid position
    quat: THREE.Quaternion,  // current orientation (relative to solved state)
  },
  ...
]
```

Initially, cubie at index (i*9 + j*3 + k) is at grid position (i, j, k) with identity quaternion.

Wait, I need to be more careful. Let me use 0-indexed grid positions: i, j, k ∈ {0, 1, 2}.

The world position of a cubie at grid position (i, j, k) is:
- x = (i - 1) * spacing
- y = (j - 1) * spacing
- z = (k - 1) * spacing

Where spacing = 1.0 (or whatever).

For the solved state, the cubie at grid position (i, j, k) has identity quaternion, and its materials are:
- +x: color if i=2, else dark
- -x: color if i=0, else dark
- +y: color if j=2, else dark
- -y: color if j=0, else dark
- +z: color if k=2, else dark
- -z: color if k=0, else dark

Now, when a move happens, cubies in the affected layer get their grid position and quaternion updated.

For example, a U move (top layer, j=2):
- All cubies with j=2 get their grid position and quaternion updated
- The rotation is -π/2 around Y, centered at (1, 2, 1) in grid coords

Wait, I need to think about how to compute the new grid position after a rotation.

The rotation is around the center of the face. For U, the center is at grid position (1, 2, 1). In world coords, this is (0, spacing, 0) (if spacing=1 and centered at origin).

To compute the new grid position of a cubie at (i, j, k) after a U move:
1. Translate to origin: (i-1, j-2, k-1) ... wait, the center is at (1, 2, 1) in grid coords.
   Actually, let me use world coords for the rotation computation.

The cubie's world position is (i-1, j-1, k-1) * spacing.
The center of rotation for U is (1-1, 2-1, 1-1) * spacing = (0, 1, 0) * spacing.

To rotate the cubie around the center:
1. Translate cubie position relative to center: (i-1 - 0, j-1 - 1, k-1 - 0) * spacing = (i-1, j-2, k-1) * spacing
2. Apply rotation (around Y axis by angle θ)
3. Translate back: add center position

Then convert back to grid position by dividing by spacing and adding 1.

But this gives floating-point positions. I need to round to the nearest integer grid position.

For a 90° rotation, the new grid positions should be exact integers (since we're rotating by 90° around the center of a 3x3 grid).

Let me verify with the U move:
- Center: (0, 1, 0) in world coords (spacing=1)
- Cubie at (0, 2, 0) [top-back-left corner, grid position (0, 2, 0), world position (-1, 1, -1)]
  - Relative to center: (-1, 0, -1)
  - After rotation by -π/2 around Y: x' = -z = 1, z' = x = -1. So (1, 0, -1)
  - Absolute: (1, 1, -1)
  - Grid position: (2, 2, 0) [top-right-back corner]

Hmm, that doesn't match my earlier calculation. Let me recheck.

Earlier I said U maps (0, 2, 0) → (0, 2, 2). But now I'm getting (0, 2, 0) → (2, 2, 0).

Let me reconsider. The U move rotates the top layer clockwise when viewed from above. Let me think about what "clockwise from above" means.

Looking from above (from +Y toward -Y), we see the top face. The top face has:
- Front: +Z (toward the viewer if the viewer is in front)
- Right: +X
- Back: -Z
- Left: -X

Clockwise rotation (from above): front → right → back → left → front
So +Z → +X → -Z → -X → +Z

In terms of grid positions (for the top layer, j=2):
- A cubie at (1, 2, 2) [front-center-top] should go to (2, 2, 1) [right-center-top]
- A cubie at (2, 2, 1) [right-center-top] should go to (1, 2, 0) [back-center-top]
- etc.

So (1, 2, 2) → (2, 2, 1). Let me verify with the rotation:
- World position: (0, 1, 1)
- Center: (0, 1, 0)
- Relative: (0, 0, 1)
- After rotation by θ around Y: x' = x*cos(θ) - z*sin(θ), z' = x*sin(θ) + z*cos(θ)
  For (0, 0, 1): x' = 0 - 1*sin(θ) = -sin(θ), z' = 0 + 1*cos(θ) = cos(θ)
- For this to give (1, 0, 0) [which translates to world (1, 1, 0), grid (2, 2, 1)]:
  -sin(θ) = 1 → sin(θ) = -1 → θ = -π/2
  cos(θ) = 0 ✓
  
So U = -π/2 around Y. Good.

Now for (0, 2, 0) [back-left-top]:
- World: (-1, 1, -1)
- Center: (0, 1, 0)
- Relative: (-1, 0, -1)
- After rotation by -π/2: x' = (-1)*0 - (-1)*(-1) = -1, z' = (-1)*(-1) + (-1)*0 = 1
  So (-1, 0, 1)
- Absolute: (-1, 1, 1)
- Grid: (0, 2, 2) [front-left-top]

So (0, 2, 0) → (0, 2, 2). That matches my earlier calculation!

But with the center at (0, 1, 0) and the rotation, I got (0, 2, 0) → (0, 2, 2). Let me re-verify with the direct computation:

Relative position: (-1, 0, -1)
Rotation by -π/2 around Y:
x' = x*cos(-π/2) - z*sin(-π/2) = (-1)*0 - (-1)*(-1) = -1
z' = x*sin(-π/2) + z*cos(-π/2) = (-1)*(-1) + (-1)*0 = 1

So relative after rotation: (-1, 0, 1)
Absolute: (-1, 1, 1)
Grid: (0, 2, 2)

Yes, (0, 2, 0) → (0, 2, 2). ✓

Now back to the cubie at (0, 2, 0) with the center at (1, 2, 1) in grid coords (which is (0, 1, 0) in world coords with spacing=1). I had the center right.

OK so my rotation computation is correct. Let me now code it up.

For the rotation of a grid position (i, j, k) by angle θ around an axis through center (ci, cj, ck):

```javascript
function rotateGridPosition(i, j, k, axis, angle, ci, cj, ck) {
  // Convert to world coords (spacing = 1, centered at origin)
  const x = i - 1;
  const y = j - 1;
  const z = k - 1;
  
  // Center in world coords
  const cx = ci - 1;
  const cy = cj - 1;
  const cz = ck - 1;
  
  // Relative position
  const rx = x - cx;
  const ry = y - cy;
  const rz = z - cz;
  
  // Apply rotation
  const vec = new THREE.Vector3(rx, ry, rz);
  const q = new THREE.Quaternion().setFromAxisAngle(axis, angle);
  vec.applyQuaternion(q);
  
  // Translate back
  const nx = vec.x + cx;
  const ny = vec.y + cy;
  const nz = vec.z + cz;
  
  // Convert back to grid position (round to nearest integer)
  return {
    i: Math.round(nx + 1),
    j: Math.round(ny + 1),
    k: Math.round(nz + 1)
  };
}
```

And for the quaternion of the cubie:

```javascript
function rotateQuaternion(q, axis, angle) {
  const rot = new THREE.Quaternion().setFromAxisAngle(axis, angle);
  return rot.multiply(q);
  // Or: q.clone().premultiply(rot) depending on convention
}
```

Wait, I need to be careful about the quaternion multiplication order. If the cubie has current quaternion q (representing its orientation relative to the solved state), and we apply a rotation R to it, the new quaternion is:

new_q = R * q (if we use the convention that q transforms from local to world, and R is applied in world space)

Or:

new_q = q * R (if R is applied in local space)

For a face turn, the rotation is applied in world space (the layer rotates around a world axis). So new_q = R * q.

In Three.js, quaternion multiplication: q1.multiply(q2) sets q1 = q1 * q2. The rotation represented by q1 * q2 is: first apply q2, then apply q1 (when rotating a vector: (q1*q2) * v * (q1*q2)^-1 = q1 * (q2 * v * q2^-1) * q1^-1).

Wait, I need to be more careful. In Three.js, the quaternion rotation of a vector is: v' = q * v * q^-1 (using quaternion multiplication). And (q1 * q2) * v * (q1 * q2)^-1 = q1 * (q2 * v * q2^-1) * q1^-1. So q2 is applied first, then q1.

So if I want to apply rotation R first, then the cubie's existing rotation q, I use: new_q = q * R (q.multiply(R)).

But wait, that's not right either. Let me think about it differently.

The cubie's quaternion q represents the rotation from the cubie's local frame to the world frame. When the cubie is solved, q = identity.

When we apply a face turn, we rotate the cubie in world space. The new orientation is: first apply the cubie's current orientation q (to get from local to current world), then apply the face turn rotation R (to get from current world to new world).

So: new_world = R * current_world = R * (q * local) = (R * q) * local

So new_q = R * q (where R is applied first, then q... wait, no).

Hmm, let me think about it more carefully with vectors.

Let v be a vector in the cubie's local frame. The cubie's current orientation q maps v to world space: v_world = q * v * q^-1.

Now we apply a face turn rotation R (in world space). The new world position of the vector is: v_world' = R * v_world = R * (q * v * q^-1).

We want to find new_q such that v_world' = new_q * v * new_q^-1.

So: new_q * v * new_q^-1 = R * q * v * q^-1 * R^-1 = (R * q) * v * (R * q)^-1

Therefore: new_q = R * q (in the sense of quaternion multiplication where R is applied first, then q).

Wait, but (R * q) * v * (R * q)^-1 = R * (q * v * q^-1) * R^-1. Is that equal to R * q * v * q^-1 * R^-1?

Quaternion multiplication is associative, so (R * q) * v * (R * q)^-1 = (R * q) * v * (q^-1 * R^-1) = R * (q * v * q^-1) * R^-1.

And R * (q * v * q^-1) * R^-1 is the rotation of (q * v * q^-1) by R. Since q * v * q^-1 is the world-space vector, rotating it by R gives the new world-space vector. ✓

So new_q = R * q. In Three.js, this is: `new_q = new Quaternion().copy(R).multiply(q)` or `new_q = R.clone().multiply(q)`.

Wait, Three.js's `multiply` function: `q1.multiply(q2)` sets q1 = q1 * q2 (quaternion product). So if I want new_q = R * q, I do: `new_q = R.clone(); new_q.multiply(q)`.

Hmm, but I need to verify the convention. In Three.js, the quaternion product q1 * q2 represents the rotation obtained by applying q2 first, then q1. So `q1.multiply(q2)` gives q1 * q2, which applies q2 first, then q1.

So if I want new_q = R * q (apply q first, then R... no, R * q applies q first, then R).

Wait, I'm getting confused. Let me re-read: in Three.js, `q1.multiply(q2)` computes q1 * q2. The rotation applied by q1 * q2 to a vector v is: (q1 * q2) * v * (q1 * q2)^-1 = q1 * (q2 * v * q2^-1) * q1^-1. So q2 is applied first, then q1.

So `R.multiply(q)` gives R * q, which applies q first, then R. That's what I want: first apply the cubie's current orientation q (to get to world space), then apply the face turn R (to rotate in world space).

Wait, no. The cubie's orientation q maps local to world. The face turn R rotates in world space. So the sequence is:
1. Start with local vector v
2. Apply q: v_world = q * v * q^-1
3. Apply R: v_world' = R * v_world * R^-1 = R * (q * v * q^-1) * R^-1

So the combined rotation is: v_world' = (R * q) * v * (R * q)^-1.

So new_q = R * q. In Three.js: `new_q = R.clone().multiply(q)`.

But wait, I need to double-check. `R.clone().multiply(q)` computes R * q. And R * q applies q first, then R. So:
- v → (apply q) → q * v * q^-1 → (apply R) → R * (q * v * q^-1) * R^-1

Yes, that's correct. The cubie's local vector v is first rotated by q to get to world space, then rotated by R to get the new world space position.

So `new_q = R.clone().multiply(q)` is correct.

But actually, I realize there might be a simpler way to think about it. The cubie's mesh already has a quaternion (the mesh.quaternion). When I apply a face turn, I want to rotate the mesh by R. In Three.js, I can just do `mesh.quaternion.premultiply(R)` or `mesh.quaternion.multiply(R)`.

`premultiply(R)` sets q = R * q.
`multiply(R)` sets q = q * R.

I want new_q = R * q, so I use `premultiply(R)`.

Wait, but that's rotating the mesh in its current orientation. Let me think...

If the mesh has quaternion q, and I do `mesh.quaternion.premultiply(R)`, the new quaternion is R * q. This represents: first apply q (current orientation), then apply R. But R is defined in world space (the face turn axis is a world axis).

Hmm, actually, when I use `setFromAxisAngle(axis, angle)`, the axis is in the quaternion's local space or world space?

In Three.js, `Quaternion.setFromAxisAngle(axis, angle)` creates a quaternion representing a rotation around the given axis. The axis is expected to be in the local space of the quaternion... actually, no. The axis is just a direction; the quaternion represents a rotation around that axis.

When I multiply quaternions, the resulting quaternion represents the combined rotation. The axis of the second quaternion is interpreted in the frame of the first quaternion.

So `R * q` (where R is setFromAxisAngle(worldAxis, angle)) represents: first apply q, then apply R around worldAxis (because R's axis is in world space, and q is applied first, so R's axis is in the world frame after q is applied... no, that's not right).

OK, I think I'm overcomplicating this. Let me just think about it practically.

The cubie mesh has a position and quaternion. Initially, position = grid position (in world coords), quaternion = identity.

When I do a U turn:
1. For each cubie in the top layer (j=2), I want to rotate it around the Y axis by -π/2, centered at the face center.

I can do this by:
1. Computing the new position: rotate the current position around the Y axis by -π/2, centered at the face center.
2. Computing the new quaternion: rotate the current quaternion by -π/2 around the Y axis.

For the quaternion, I use: `newQuat = new Quaternion().setFromAxisAngle(new Vector3(0, 1, 0), -Math.PI/2).multiply(currentQuat)`.

Wait, but is this correct? Let me think about a cubie that's already rotated.

Say a cubie at (2, 2, 2) [top-right-front corner] has been rotated by a previous move. Its current quaternion is q. Now I do a U turn. The cubie is in the top layer (j=2), so it gets rotated.

The U turn rotates the top layer around the Y axis by -π/2. This is a world-space rotation. The cubie's new orientation should be: R * q, where R is the rotation around Y by -π/2.

In Three.js: `newQuat = new Quaternion().setFromAxisAngle(new Vector3(0, 1, 0), -Math.PI/2).multiply(q)`.

This gives R * q. Is this correct?

Let me verify with a simple case. Say the cubie is at (2, 2, 2) with identity quaternion (solved state). After U turn, the cubie moves to (2, 2, 0) [top-right-back corner]. Its new orientation should be such that its +x face (which was facing right) now faces... let me think.

In the solved state, the cubie at (2, 2, 2) has:
- +x face: red (right face of big cube)
- +y face: white (top face)
- +z face: green (front face)
- Other faces: dark

After U turn (rotate around Y by -π/2), the cubie moves to (2, 2, 0). Its new orientation:
- The cubie has been rotated by -π/2 around Y.
- The +x face (red) now faces... +z? Let me compute.
- Rotation by -π/2 around Y: +x → +z, +z → -x, -x → -z, -z → +x.
- Wait, that's for the coordinate axes. Let me verify: a vector (1, 0, 0) rotated by -π/2 around Y becomes (0, 0, 1). Yes, +x → +z.
- So the red sticker (originally on +x face) is now on the +z face (in world space).
- But the cubie is at (2, 2, 0), which is the top-right-back position. The +z face of the cubie is now the front face of the big cube... wait, no. The cubie is at the back (k=0), so its +z face is facing the interior of the big cube, not the exterior.

Hmm, this is getting confusing. Let me think about it differently.

After the U turn, the cubie is at grid position (2, 2, 0). Its orientation is rotated by -π/2 around Y. The cubie's +x face (red sticker) is now facing +z in world space. But the cubie is at k=0 (back), so its +z face is facing the interior (toward k=1). So the red sticker is now on the interior face of the cubie, not visible from the outside.

Wait, that can't be right. In a real Rubik's cube, after a U turn, the corner cubie that was at top-right-front moves to top-right-back. Its red sticker (which was on the right face) should now be on the right face of the big cube (since the cubie is still on the right side). And its green sticker (which was on the front face) should now be on the top face of the big cube (since the cubie rotated).

Let me reconsider. The cubie at (2, 2, 2) has stickers on +x (red), +y (white), +z (green). After U turn, it moves to (2, 2, 0). The cubie has rotated by -π/2 around Y.

The cubie's local +x axis (where the red sticker is) was pointing in world +x. After rotation by -π/2 around Y, it points in world +z.

But the cubie is now at (2, 2, 0), which is the top-right-back position. In this position:
- The right face of the big cube is at i=2 (x+). The cubie's +x face is at the right side of the cubie, which is at world x = 2. So the cubie's +x face is on the right face of the big cube. But wait, the cubie has rotated, so its +x face is now pointing in world +z, not world +x.

Hmm, I think I'm confusing the cubie's local axes with the cubie's position.

Let me clarify. The cubie is a box. It has 6 faces: +x, -x, +y, -y, +z, -z (in local space). Each face has a sticker (material). The stickers are fixed to the cubie's local faces.

When the cubie is at grid position (2, 2, 2) with identity quaternion:
- The cubie's local +x face is at world position (2.5, 2, 2) (approximately, considering the cubie size). This is on the right face of the big cube (x = 2.5 is outside the cube). The red sticker is visible on the right face.
- The cubie's local +y face is at world position (2, 2.5, 2). This is on the top face. The white sticker is visible.
- The cubie's local +z face is at world position (2, 2, 2.5). This is on the front face. The green sticker is visible.

After U turn, the cubie moves to grid position (2, 2, 0) with quaternion R (rotation by -π/2 around Y):
- The cubie's local +x face is at world position... let me compute.
  - The cubie's center is at world position (1, 1, -1) (grid (2, 2, 0) → world (1, 1, -1) with spacing 1).
  - The cubie's local +x direction is R * (1, 0, 1) = ... wait, R is the rotation by -π/2 around Y.
  - A vector (1, 0, 0) rotated by -π/2 around Y becomes (0, 0, 1). So the cubie's local +x direction is now world +z.
  - The cubie's local +x face is at world position (1, 1, -1) + 0.5 * (0, 0, 1) = (1, 1, -0.5).
  - Is this on the exterior of the big cube? The big cube extends from -1.5 to 1.5 in each axis (with spacing 1, cubie size 0.9, the exterior is at ±1.5). World z = -0.5 is not on the exterior (it's inside the cube). So the red sticker is not visible on the exterior.

Hmm, that doesn't seem right. Let me reconsider.

Wait, I think the issue is that the cubie at (2, 2, 0) has its local +x face pointing in world +z, but the cubie is at the back of the cube (k=0). The cubie's local +x face is now pointing toward the interior of the cube (toward positive z, which is toward the front). So the red sticker is on the face of the cubie that points toward the front, but since the cubie is at the back, this face is interior.

But in a real Rubik's cube, after a U turn, the corner cubie at top-right-front moves to top-right-back. The red sticker (right face) should still be on the right face of the big cube, and the green sticker (front face) should now be on the top face.

Let me re-examine. In a real Rubik's cube:
- The cubie at top-right-front has 3 stickers: right (red), top (white), front (green).
- After a U turn (clockwise from above), this cubie moves to top-right-back.
- The cubie has rotated 90° clockwise (from above).
- The right sticker (red) is now on the... let me think. The cubie rotated 90° clockwise from above. If you look at the cubie from above, it rotated 90° clockwise. The right face of the cubie (red) was on the right side. After rotating 90° clockwise from above, the right face is now on the... back side? No, that's not right.

Actually, let me think about it physically. Hold a Rubik's cube with the top facing up and front facing you. The top-right-front corner cubie has stickers on the right, top, and front faces. Now do a U turn (rotate the top layer clockwise from above). The top-right-front corner cubie moves to the top-right-back position. 

After the move, the cubie is at the top-right-back position. Its stickers:
- The sticker that was on the right face is still on the right face of the cubie (the cubie didn't flip; it just moved). But the cubie's orientation changed. The cubie rotated 90° around the vertical axis (Y axis).

Wait, the cubie is a physical object. When it moves from top-right-front to top-right-back, it rotates 90° around the Y axis. The sticker that was on the right face of the cubie (red) is now on the... let me think.

If the cubie rotates 90° clockwise around the Y axis (from above), then:
- The face that was pointing right (+x) now points toward the back (-z)? No, clockwise from above: +x → -z? Let me check.

Clockwise from above: +x (right) → -z (back) → -x (left) → +z (front) → +x (right).

Wait, that's counter-clockwise. Let me re-examine.

Looking from above (bird's eye view), the axes are:
- +x: right
- +z: up (on the screen, since we're looking down)

Wait, no. If I'm looking from above (from +Y toward -Y), I see the XZ plane. +X is to the right, +Z is... it depends on the convention. In Three.js, if I look from above, +Z is typically toward the top of the screen (or bottom, depending on the camera orientation).

Let me use a different approach. I'll use the right-hand rule. With the right hand, thumb pointing in the +Y direction (up), the fingers curl from +X to +Z. So positive rotation around Y rotates +X toward +Z.

So a positive rotation around Y: +X → +Z → -X → -Z → +X.

A negative rotation around Y (which is what I defined for U): +X → -Z → -X → +Z → +X.

So for U (negative rotation around Y):
- +X (right) → -Z (back)
- -Z (back) → -X (left)
- -X (left) → +Z (front)
- +Z (front) → +X (right)

So the cubie's +x face (red) rotates to face -z (back). The cubie's +z face (green) rotates to face +x (right).

After the U turn, the cubie is at (2, 2, 0) [top-right-back]. Its:
- +x face (red) now faces -z (back). But the cubie is at the back (k=0), so the -z face of the cubie is on the exterior (back face of big cube). Wait, the cubie's +x face is now pointing in the -z direction. So the red sticker is on the face of the cubie that points toward the back. Since the cubie is at the back of the cube, this face is on the exterior (back face of the big cube).

Hmm, but in a real Rubik's cube, after a U turn, the red sticker should be on the right face of the big cube, not the back face.

Let me reconsider. I think the issue is with my understanding of the U move.

In a real Rubik's cube, when you do a U turn (clockwise from above), the top layer rotates. The corner cubie at top-right-front moves to top-right-back. But the cubie's stickers don't change which face of the cubie they're on. The red sticker is still on the right face of the cubie (the cubie's local +x face). What changes is the cubie's position and orientation in the big cube.

After the U turn:
- The cubie is at top-right-back (grid position (2, 2, 0)).
- The cubie's local +x face (red) is now pointing in world -z direction (because the cubie rotated 90° around Y).
- The cubie's local +z face (green) is now pointing in world +x direction.
- The cubie's local +y face (white) is still pointing in world +y direction (since the rotation is around Y).

Now, the cubie is at (2, 2, 0). The big cube's faces are:
- Right: x = 1.5 (world), which is at grid i=2.
- Top: y = 1.5, grid j=2.
- Back: z = -1.5, grid k=0.

The cubie's local +x face (red) is pointing in world -z. At grid position (2, 2, 0), the cubie's local +x face is at world position (1.5, 1.5, -1.5) + offset. The cubie's local +x face is on the side of the cubie that points in the +x direction of the cubie's local frame. Since the cubie rotated, this face is now pointing in world -z.

Wait, I need to be more precise. The cubie's local +x face is the face of the cubie that is in the +x direction of the cubie's local frame. After rotation by -π/2 around Y, this face points in the world -z direction.

The cubie is at grid position (2, 2, 0), which is world position (1, 1, -1) (with spacing 1). The cubie's local +x face is at world position (1, 1, -1) + 0.5 * (0, 0, -1) = (1, 1, -1.5). 

World z = -1.5 is on the back face of the big cube (exterior). So the red sticker is on the back face of the big cube.

But in a real Rubik's cube, after a U turn, the red sticker should be on the right face of the big cube, not the back face.

I think I'm making an error. Let me re-examine the U move.

Actually, I think the issue is that in a real Rubik's cube, the cubie doesn't just translate; it also rotates. And the rotation is such that the stickers maintain their relative positions on the cubie.

Let me think about it more carefully. In a real Rubik's cube:
- The cubie at top-right-front has stickers on the right, top, and front faces of the cubie.
- After a U turn, the cubie moves to top-right-back.
- The cubie has rotated 90° around the Y axis (the vertical axis).
- The sticker that was on the right face of the cubie is now on the back face of the cubie (because the cubie rotated 90° clockwise from above, so the right face becomes the back face).
- The sticker that was on the front face of the cubie is now on the right face of the cubie.

Wait, that's what I computed. The red sticker (right face of cubie) is now on the back face of the cubie (pointing in world -z). And the green sticker (front face of cubie) is now on the right face of the cubie (pointing in world +x).

So after the U turn, at the top-right-back position:
- The red sticker is on the back face of the big cube (since the cubie's local +x face is now pointing in world -z, and the cubie is at the back of the cube).
- The green sticker is on the right face of the big cube (since the cubie's local +z face is now pointing in world +x, and the cubie is at the right of the cube).
- The white sticker is on the top face of the big cube (unchanged).

Is this correct for a real Rubik's cube? Let me verify by thinking about a physical cube.

Hold a Rubik's cube with:
- White on top
- Green on front
- Red on right

The top-right-front corner has white (top), red (right), green (front).

Do a U turn (clockwise from above). The top layer rotates. The top-right-front corner moves to the top-right-back position.

Now, at the top-right-back position:
- The cubie's white sticker is still on top (it didn't move from the top face).
- The cubie's red sticker: was on the right face. After the U turn, the cubie rotated 90° clockwise from above. The right face of the cubie is now facing... the back? Or the right?

Let me think about this physically. I'm looking at the cube from the front. The top-right-front corner is at the top-right of the front face. I do a U turn (the top layer rotates clockwise, so the front-top edge moves to the right-top).

After the U turn:
- The front-top edge (green-white) moves to the right-top position. So the green sticker is now on the right face, and the white sticker is still on top.
- The right-top-front corner (red-white-green) moves to the right-top-back position. So the red sticker is now on the... back face? Or the right face?

Hmm, let me think. The corner cubie at top-right-front has 3 stickers: red (right), white (top), green (front). After the U turn, it moves to top-right-back. The cubie has rotated 90° around the vertical axis.

If I look at the cubie from above, it rotated 90° clockwise. The face that was pointing right (red) now points toward the back. The face that was pointing front (green) now points toward the right.

So at the top-right-back position:
- The red sticker is on the back face of the cubie, which is now on the back face of the big cube (since the cubie is at the back).
- The green sticker is on the right face of the cubie, which is now on the right face of the big cube (since the cubie is at the right).
- The white sticker is on the top face of the cubie, which is now on the top face of the big cube.

Wait, but that means the red sticker is on the back face of the big cube, and the green sticker is on the right face. Is that correct?

Let me verify by looking at a real Rubik's cube. After a U turn:
- The top face is still white (the top center didn't move).
- The right face: the top-right edge used to be red-white (right-top). After U, it's green-white (front-top moved to right-top). So the right face now has green at the top-right edge. ✓
- The back face: the top-right corner used to be... let me think. The back face's top-right corner is the top-right-back cubie. Before U, this was the top-left-back cubie (since the top layer hadn't moved yet... wait, no).

Actually, I think I need to be more careful. Let me label the cubies by their initial positions.

Initial state (solved):
- Top face (y=2): all white
- Bottom face (y=0): all yellow
- Front face (z=2): all green
- Back face (z=0): all blue
- Right face (x=2): all red
- Left face (x=0): all orange

The corner cubie at (2, 2, 2) [top-right-front] has stickers: red (x+), white (y+), green (z+).

After U turn (top layer rotates -π/2 around Y, centered at (1, 2, 1)):
- The cubie at (2, 2, 2) moves to (2, 2, 0) [top-right-back].
- The cubie's orientation changes: it rotates by -π/2 around Y.

At the new position (2, 2, 0):
- The cubie's local +x face (red) now points in world -z direction.
- The cubie's local +z face (green) now points in world +x direction.
- The cubie's local +y face (white) still points in world +y direction.

The big cube's faces at this position:
- Right face: x = 2 (grid), world x = 1.5. The cubie's local +z face (green) points in world +x, which is toward the right face. So the green sticker is on the right face of the big cube.
- Back face: z = 0 (grid), world z = -1.5. The cubie's local +x face (red) points in world -z, which is toward the back face. So the red sticker is on the back face of the big cube.
- Top face: y = 2 (grid), world y = 1.5. The cubie's local +y face (white) points in world +y, which is toward the top face. So the white sticker is on the top face.

So after the U turn, at the top-right-back position, we have:
- Green sticker on the right face
- Red sticker on the back face
- White sticker on the top face

Is this correct? Let me verify by checking the right face. Before the U turn, the right face at the top-right position had the red-white edge (cubie at (2, 2, 1)). After the U turn, the cubie at (2, 2, 1) moves to (1, 2, 0) [top-center-back]. So the right face at the top-right position now has... the cubie that was at (2, 2, 2) [top-right-front] moved to (2, 2, 0) [top-right-back]. But (2, 2, 0) is the top-right-back position, which is at the intersection of the right face, top face, and back face. So the right face at the top-right position now has the cubie that was at top-right-front, which has a green sticker on its right-facing side (since the cubie's local +z face now points in world +x).

So the right face at the top-right position now shows green (instead of red before the U turn). This is correct! After a U turn, the right face's top-right corner should show the color that was on the front face's top-right corner (green).

Let me verify the back face. Before the U turn, the back face at the top-right position had the blue-red edge (cubie at (2, 2, 0) - wait, (2, 2, 0) is top-right-back, which has blue (back), red (right), white (top)). After the U turn, the cubie at (2, 2, 0) moves to (0, 2, 0) [top-left-back]. So the back face at the top-right position now has... the cubie that was at (2, 2, 2) [top-right-front] moved to (2, 2, 0) [top-right-back]. This cubie has a red sticker on its back-facing side. So the back face at the top-right position now shows red (instead of blue before the U turn).

Is this correct? After a U turn, the back face's top-right corner should show the color that was on the right face's top-right corner (red). Yes, that's correct!

Great, so my rotation computation is correct. The cubie's stickers maintain their relative positions on the cubie, and the cubie's orientation changes correctly.

OK so now I'm confident in the math. Let me code it up.

Actually, wait. I realize there might be an issue with the center cubie of each face. In a real Rubik's cube, the center pieces are fixed to the core and don't move (they only rotate in place). But in my model, I'm treating all 27 cubies as movable. The center cubie of a face (e.g., (1, 2, 1) for the top face) should stay in place but rotate when the face is turned.

In my model, the center cubie of the top face is at grid position (1, 2, 1). When I do a U turn, this cubie is in the top layer (j=2), so it gets rotated. Its position stays the same (since it's at the center of the rotation), but its orientation changes.

Let me verify: the cubie at (1, 2, 1) [top-center] has its +y face (white) on the top face of the big cube. After a U turn (rotation by -π/2 around Y), the cubie's orientation changes. The +y face still points in world +y (since the rotation is around Y), so the white sticker is still on the top face. ✓ But the cubie's other faces (which are dark/internal) rotate. This is fine since they're not visible.

Actually, for the center cubies, only one face is visible (the one on the exterior of the big cube). The other 5 faces are internal and dark. When the center cubie rotates, the visible face stays on the exterior (since the rotation is around the axis perpendicular to that face). So the center cubie's visible sticker stays in place. ✓

But wait, for the U move, the center cubie of the top face (1, 2, 1) rotates around the Y axis. Its +y face (white) stays pointing in world +y. So the white sticker stays on the top face. ✓ But the cubie's other faces rotate. Since they're internal and dark, this doesn't matter visually.

However, there's a subtlety: the center cubie's orientation matters for the overall cube state. In a real Rubik's cube, the center pieces can rotate (their orientation matters for supercubes). But for a standard Rubik's cube, the center piece orientation is not visible (since only one face is visible). So for our purposes, we can ignore the center cubie's orientation.

Actually, for our 3D model, the center cubie's orientation does matter visually, because the cubie's dark faces might become visible if the cubie rotates. But since the dark faces are all the same color (dark gray), this doesn't matter.

OK, I think I've thought about this enough. Let me code it up.

One more thing: the requirement says "Preserve cubie and sticker state through moves; recoloring a static cube is not sufficient." This means I need to actually move the cubies (change their positions and orientations), not just recolor the faces. My approach of moving the cubie meshes satisfies this.

Also, "visible cubie boundaries" means I should show the gaps between cubies. I'll use a small gap (0.05 on each side) and a dark background color to make the boundaries visible.

Let me now write the code.

For the cubie size and spacing:
- Spacing: 1.0 (distance between cubie centers)
- Cubie size: 0.9 (so there's a 0.05 gap on each side)
- The big cube extends from -1.5 to 1.5 in each axis (with spacing 1.0, the centers are at -1, 0, 1, and the cubie edges are at ±1.5)

Actually, let me use:
- Spacing: 1.0
- Cubie size: 0.92 (slightly larger gap for better visibility)
- Gap: 0.04 on each side (0.08 total between adjacent cubies)

For the cubie body (edges), I'll use a dark material. The cubie is a box with 6 materials (one per face). The materials are:
- For exterior faces: the face color (bright)
- For interior faces: dark gray (0x333333 or similar)

This creates the appearance of individual cubies with colored stickers on the exterior.

Let me also add a slight border/outline to the cubies for better visibility. I can do this by:
1. Using a slightly larger dark box behind each cubie (like a socket)
2. Or using EdgesGeometry to show the edges
3. Or using a material with a wireframe overlay

I think option 2 (EdgesGeometry) is simplest. I'll add edges to each cubie group.

Actually, let me think about this differently. I'll create each cubie as a Group containing:
1. A Box mesh with 6 materials (the cubie body with colored faces)
2. An Edges mesh (the cubie boundaries)

This way, the cubie has colored faces and visible edges.

OK let me code this up now.

For the animation, I'll use a simple approach:
- When a move is triggered, compute the target positions and quaternions for all cubies in the layer.
- Animate from current to target over ~300ms using requestAnimationFrame.
- During animation, disable further moves (set a flag).
- After animation, update the cubie state.

For the animation, I'll interpolate:
- Position: linear interpolation (lerp)
- Quaternion: spherical linear interpolation (slerp)

Three.js provides Quaternion.slerp for this.

Let me also handle the move queue. If a move is triggered while animating, queue it. After the current animation completes, start the next one.

Actually, the requirement says "queue or disable further moves until it completes." I'll disable the move buttons during animation and queue scramble moves.

Let me now write the complete code.

For the camera controls:
- Orbit: on mousedown, record the mouse position. On mousemove, rotate the camera around the cube center.
- Zoom: on wheel, change the camera distance (bounded).

I'll use spherical coordinates for the camera:
- radius: distance from cube center
- theta: azimuthal angle (around Y axis)
- phi: polar angle (from Y axis)

On drag, update theta and phi. On wheel, update radius.

Initial camera position: (3.5, 2.5, 3.5) looking at origin. This gives a nice 3/4 view.

Let me convert to spherical:
- radius = sqrt(3.5² + 2.5² + 3.5²) ≈ 5.32
- theta = atan2(3.5, 3.5) = π/4
- phi = acos(2.5/5.32) ≈ 1.14

OK let me write the code now. I'll be comprehensive.

Let me structure the code:

1. Scene, camera, renderer setup
2. Lighting
3. Cube creation (26 cubies)
4. Camera controls (orbit, zoom)
5. Move definitions and execution
6. Animation system
7. UI controls (buttons)
8. Render loop

Let me write it now.

Actually, one more consideration. For the cubie's box geometry, I need to use 6 materials. In Three.js, when you create a Mesh with a BoxGeometry and an array of 6 materials, the materials are applied to the faces in the order: +x, -x, +y, -y, +z, -z.

But when the mesh rotates, the materials rotate with it (they're in local space). So if I create a cubie with a red material on the +x face, and then rotate the mesh, the red material will appear on a different face in world space.

This is exactly what I want for the Rubik's cube.

Let me now write the code. I'll create a comprehensive implementation.

For the colors, I'll use:
```javascript
const FACE_COLORS = {
  right: 0xff0000,   // Red
  left: 0xff6600,    // Orange
  top: 0xffffff,     // White
  bottom: 0xffff00,  // Yellow
  front: 0x00cc00,   // Green
  back: 0x2244ff,    // Blue
  internal: 0x333333 // Dark gray
};
```

For each cubie at grid position (i, j, k) in the solved state:
- +x material: FACE_COLORS.right if i === 2, else FACE_COLORS.internal
- -x material: FACE_COLORS.left if i === 0, else FACE_COLORS.internal
- +y material: FACE_COLORS.top if j === 2, else FACE_COLORS.internal
- -y material: FACE_COLORS.bottom if j === 0, else FACE_COLORS.internal
- +z material: FACE_COLORS.front if k === 2, else FACE_COLORS.internal
- -z material: FACE_COLORS.back if k === 0, else FACE_COLORS.internal

Now let me code the full solution.

I'll also need to handle the cubie's position and quaternion tracking. I'll use a data structure like:
```javascript
const cubieData = [];
// For each cubie:
// {
//   mesh: THREE.Mesh,       // The box mesh
//   edges: THREE.LineSegments, // The edges
//   group: THREE.Group,     // The group containing mesh and edges
//   gridPos: { i, j, k },  // Current grid position
//   quat: THREE.Quaternion  // Current orientation
// }
```

Wait, I can just use the group's position and quaternion directly, and track the grid position separately.

Actually, for the animation, I need to interpolate the position and quaternion. I'll store the start and end values and interpolate in the animation loop.

Let me think about the animation system:

```javascript
let isAnimating = false;
let animationQueue = [];
let currentAnimation = null;

function queueMove(moveDef) {
  if (isAnimating) {
    animationQueue.push(moveDef);
  } else {
    startMove(moveDef);
  }
}

function startMove(moveDef) {
  isAnimating = true;
  // Compute target positions and quaternions for cubies in the layer
  // Start animation
  currentAnimation = {
    moveDef,
    startTime: performance.now(),
    duration: 300,
    cubies: [...],  // cubies in the layer
    startPositions: [...],
    endPositions: [...],
    startQuats: [...],
    endQuats: [...]
  };
}

function updateAnimation() {
  if (!currentAnimation) return;
  
  const elapsed = performance.now() - currentAnimation.startTime;
  const t = Math.min(elapsed / currentAnimation.duration, 1);
  
  // Interpolate positions and quaternions
  for (let i = 0; i < currentAnimation.cubies.length; i++) {
    const cubie = currentAnimation.cubies[i];
    cubie.group.position.lerpVectors(currentAnimation.startPositions[i], currentAnimation.endPositions[i], t);
    cubie.group.quaternion.slerp(currentAnimation.startQuats[i], currentAnimation.endQuats[i], t);
  }
  
  if (t >= 1) {
    // Animation complete
    isAnimating = false;
    currentAnimation = null;
    // Update grid positions and quaternions
    // Process next animation in queue
    if (animationQueue.length > 0) {
      startMove(animationQueue.shift());
    }
  }
}
```

This is a good structure. Let me now write the full code.

For the move definitions, I'll use:
```javascript
const MOVES = {
  U:  { layer: 'j', value: 2, axis: [0, 1, 0], angle: -Math.PI/2, center: [1, 2, 1] },
  U1: { layer: 'j', value: 2, axis: [0, 1, 0], angle: Math.PI/2, center: [1, 2, 1] },
  D:  { layer: 'j', value: 0, axis: [0, 1, 0], angle: Math.PI/2, center: [1, 0, 1] },
  D1: { layer: 'j', value: 0, axis: [0, 1, 0], angle: -Math.PI/2, center: [1, 0, 1] },
  R:  { layer: 'i', value: 2, axis: [1, 0, 0], angle: Math.PI/2, center: [2, 1, 1] },
  R1: { layer: 'i', value: 2, axis: [1, 0, 0], angle: -Math.PI/2, center: [2, 1, 1] },
  L:  { layer: 'i', value: 0, axis: [1, 0, 0], angle: -Math.PI/2, center: [0, 1, 1] },
  L1: { layer: 'i', value: 0, axis: [1, 0, 0], angle: Math.PI/2, center: [0, 1, 1] },
  F:  { layer: 'k', value: 2, axis: [0, 0, 1], angle: Math.PI/2, center: [1, 1, 2] },
  F1: { layer: 'k', value: 2, axis: [0, 0, 1], angle: -Math.PI/2, center: [1, 1, 2] },
  B:  { layer: 'k', value: 0, axis: [0, 0, 1], angle: -Math.PI/2, center: [1, 1, 0] },
  B1: { layer: 'k', value: 0, axis: [0, 0, 1], angle: Math.PI/2, center: [1, 1, 0] }
};
```

Where i, j, k correspond to x, y, z grid coordinates (0, 1, 2).

For each move, I need to:
1. Find all cubies with the given layer value (e.g., for U, all cubies with j=2)
2. For each such cubie, compute the new grid position and new quaternion
3. Animate from current to new

The new grid position is computed by rotating the current grid position around the move's center by the move's angle.

The new quaternion is computed by multiplying the current quaternion by the rotation quaternion.

Let me now write the complete HTML file.

Actually, I realize I should double-check one thing. The cubie at the center of a face (e.g., (1, 2, 1) for the top face) stays at the same grid position after a U turn (since it's at the center of rotation). But its quaternion changes (it rotates by -π/2 around Y).

In my animation, I need to handle this case. The cubie's position doesn't change, but its quaternion does. So I need to animate the quaternion even if the position stays the same.

For the animation, I'll interpolate both position and quaternion for all cubies in the layer, regardless of whether the position changes.

OK, let me now write the code.

One more thing: for the scramble, I'll generate a random sequence of moves (at least 10-20 moves) and execute them one by one with animation.

For the reset, I'll:
1. Remove all cubies from the scene
2. Recreate the solved cube
3. Reset the camera to the initial position

Or alternatively:
1. For each cubie, reset its grid position to the initial position and quaternion to identity
2. Animate to the initial state
3. Reset the camera

I'll go with option 1 (recreate the cube) for simplicity.

Actually, recreating the cube is cleaner. I'll remove all cubie groups from the scene and create new ones.

Let me now write the code.

For the UI layout, I'll have:
- The 3D canvas taking most of the screen
- A control panel at the bottom or side with buttons

Let me use a layout with the canvas on the left and controls on the right, or the canvas taking the full screen with controls overlaid.

I'll use a full-screen canvas with controls overlaid at the bottom.

Let me write the code now.

Here's my plan for the HTML structure:
```html
<div id="container">
  <canvas id="canvas"></canvas>
  <div id="controls">
    <div class="button-row">
      <button data-move="U">U</button>
      <button data-move="U1">U'</button>
      ...
    </div>
    <div class="button-row">
      <button data-move="Scramble">Scramble</button>
      <button data-move="Reset">Reset</button>
    </div>
  </div>
</div>

```

For the CSS, I'll use a dark theme with the controls at the bottom.

Let me now write the complete code.

Wait, I need to handle one more thing. The requirement says "Dragging the background orbits the camera without turning a face." This means I need to distinguish between dragging on the cube (which might trigger a face turn) and dragging on the background (which orbits).

But since I'm providing buttons for moves, I don't need to handle face turns by dragging. All moves are done via buttons. So dragging always orbits.

Actually, re-reading the requirement: "Dragging the background orbits the camera without turning a face." This implies that dragging on the cube might turn a face, but dragging on the background orbits. But since I'm using buttons for moves, I can just make all dragging orbit.

Let me re-read: "Provide visible buttons for U, D, L, R, F, B quarter turns and their inverses. Animate each move and queue or disable further moves until it completes so state is not corrupted. Dragging the background orbits the camera without turning a face."

So the moves are via buttons, and dragging (on the background) orbits. There's no face-turning by dragging. Good.

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

So I need to:
1. Initialize the camera so the cube is fully visible
2. Support wheel zoom with bounds (min and max zoom)

OK, let me now write the code.

For the initial camera position, I want the cube to be fully visible. The cube extends from -1.5 to 1.5 in each axis (with spacing 1.0 and cubie size 0.92, the actual extent is about -1.46 to 1.46). To show the cube fully, I need the camera to be far enough away.

A good initial position is at a 45° angle, about 5 units away. Let me use (4, 3, 4) looking at origin.

Actually, let me use a standard isometric-like view: (3, 2, 3) looking at origin. This gives a nice view of the cube.

Let me compute the camera parameters:
- Position: (3, 2, 3)
- LookAt: (0, 0, 0)
- Distance: sqrt(9 + 4 + 9) = sqrt(22) ≈ 4.69
- theta = atan2(3, 3) = π/4
- phi = acos(2/4.69) ≈ 1.11 radians ≈ 63.6°

Zoom bounds: min distance 3, max distance 10.

OK, let me write the code now. I'll aim for a clean, complete implementation.

Let me think about the edges. To show cubie boundaries, I'll add EdgesGeometry to each cubie. This creates a wireframe outline around each cubie.

```javascript
const edgesGeo = new THREE.EdgesGeometry(new THREE.BoxGeometry(0.92, 0.92, 0.92));
const edgesMat = new THREE.LineBasicMaterial({ color: 0x000000 });
const edges = new THREE.LineSegments(edgesGeo, edgesMat);
```

I'll add this to each cubie group.

Actually, I want the edges to be visible but not too prominent. I'll use a dark gray color for the edges.

Let me also think about the cubie body material. I'll use MeshStandardMaterial with:
- color: the face color (or dark for internal faces)
- roughness: 0.7
- metalness: 0.1

This gives a nice matte look.

For lighting:
- Ambient light: 0.4 intensity
- Directional light: 0.8 intensity, from above-right

OK, let me write the code now. I'll be comprehensive and handle all the requirements.

Let me also think about the cubie creation. I'll create 26 cubies (skipping the center one at (1, 1, 1)).

For each cubie at grid position (i, j, k) (excluding (1, 1, 1)):
1. Create a BoxGeometry(0.92, 0.92, 0.92)
2. Create 6 materials based on the cubie's position
3. Create a Mesh with the geometry and materials
4. Create EdgesGeometry and LineSegments for the boundaries
5. Create a Group containing the mesh and edges
6. Position the group at the world position corresponding to (i, j, k)
7. Add the group to the scene

I'll store the cubie data in an array for later manipulation.

Let me now write the full code. I'll aim for about 300-400 lines of JavaScript.

Here's the structure:
1. HTML with controls
2. CSS for styling
3. JavaScript:
   a. Scene setup
   b. Cube creation
   c. Camera controls
   d. Move system
   e. Animation system
   f. UI event handlers
   g. Render loop
   h. Scramble and Reset

Let me write it now.

Actually, let me reconsider the cubie size. I want the cubie boundaries to be clearly visible. Let me use:
- Cubie size: 0.9 (so the gap between cubies is 0.05 on each side, 0.1 total)
- This should be enough to see the boundaries

For the edges, I'll use EdgesGeometry with a dark color. The edges will be visible in the gaps between cubies.

Let me also add a subtle background color to the scene (dark gray) to make the cube stand out.

OK, writing the code now.

Let me think about one more thing: the "visible cubie boundaries" requirement. This means I should be able to see the individual cubies, not just a solid cube with colored faces. The gaps between cubies and the edges should make this clear.

I'll use:
1. Gaps between cubies (0.05 on each side)
2. Dark edges (EdgesGeometry) around each cubie
3. A dark background color

This should make the cubie boundaries clearly visible.

Now let me write the code.

For the quaternion computation in moves, I need to be careful. The cubie's quaternion represents its orientation relative to the solved state. When I apply a move, I need to compute the new quaternion.

The move's rotation is defined by an axis and angle. The rotation quaternion is:
```javascript
const rotQuat = new THREE.Quaternion().setFromAxisAngle(new THREE.Vector3(axis[0], axis[1], axis[2]), angle);
```

The new cubie quaternion is:
```javascript
newQuat = rotQuat * oldQuat
```

In Three.js:
```javascript
const newQuat = rotQuat.clone().multiply(oldQuat);
```

Wait, I need to verify this. `rotQuat.clone().multiply(oldQuat)` computes rotQuat * oldQuat. In Three.js, quaternion multiplication q1 * q2 applies q2 first, then q1. So rotQuat * oldQuat applies oldQuat first, then rotQuat.

But I want to apply the move's rotation (rotQuat) to the cubie's current orientation (oldQuat). The move rotation is in world space. So the sequence is:
1. Start with the cubie's local frame
2. Apply oldQuat to get to the current world orientation
3. Apply rotQuat to rotate in world space

So the new orientation is rotQuat * oldQuat (apply oldQuat first, then rotQuat). This is what `rotQuat.clone().multiply(oldQuat)` computes.

Wait, but I need to think about this more carefully. The cubie's quaternion oldQuat maps from the cubie's local frame to the world frame. The move rotation rotQuat is a rotation in world space.

When I apply rotQuat to the cubie, I'm rotating the cubie in world space. The new orientation should be: first apply oldQuat (to get from local to current world), then apply rotQuat (to rotate in world space).

So: newQuat = rotQuat * oldQuat.

In Three.js, `q1.multiply(q2)` sets q1 = q1 * q2. And q1 * q2 applies q2 first, then q1. So `rotQuat.multiply(oldQuat)` sets rotQuat = rotQuat * oldQuat, which applies oldQuat first, then rotQuat.

So `newQuat = rotQuat.clone().multiply(oldQuat)` gives rotQuat * oldQuat, which is what I want.

But wait, I need to double-check. In Three.js, the quaternion multiplication convention might be different. Let me check.

In Three.js, `Quaternion.multiply(q)` multiplies the quaternion by q. The result is this * q. The rotation represented by this * q is: first apply q, then apply this.

So if I have rotQuat and oldQuat, and I do `rotQuat.multiply(oldQuat)`, the result is rotQuat * oldQuat, which applies oldQuat first, then rotQuat.

This is what I want: first apply the cubie's current orientation (oldQuat), then apply the move rotation (rotQuat).

So `newQuat = rotQuat.clone().multiply(oldQuat)` is correct.

Actually, let me verify this with a simple example. Suppose a cubie has oldQuat = identity (solved state). I apply a U move (rotQuat = rotation by -π/2 around Y). The new quaternion should be rotQuat * identity = rotQuat. So the cubie's new orientation is a rotation by -π/2 around Y. This is correct.

Now suppose the cub

Let me review my implementation for potential issues before testing:

1. The `buildSolvedCube` function creates cubies at grid positions (i,j,k). The center cubie at (1,1,1) is skipped and `solvedGrid` gets `null` for it. But `solvedGrid` is indexed by cubie index, and we skip the center. This could cause index misalignment. Let me trace through:

- i=0, j=0, k=0: idx=0, solvedGrid[0] = {i:0,j:0,k:0}
- i=0, j=0, k=1: idx=1, solvedGrid[1] = {i:0,j:0,k:1}
- ...
- When we reach i=1, j=1, k=1, we skip and push null to solvedGrid, but idx is NOT incremented.

Wait, let me re-read my code:

```javascript
let idx = 0;
for (let i = 0; i < 3; i++) {
  for (let j = 0; j < 3; j++) {
    for (let k = 0; k < 3; k++) {
      if (i === 1 && j === 1 && k === 1) {
        solvedGrid.push(null);
        continue;
      }
      // ... create cubie ...
      cubies.push(cubie);
      grid[gridKey(i, j, k)] = idx;
      solvedGrid.push({ i, j, k });
      idx++;
    }
  }
}
```

So `solvedGrid` has 27 entries (one per grid position), with `null` at the center. And `cubies` has 26 entries. `idx` goes from 0 to 25.

But in `buildSolvedCube`, I use `solvedGrid.push({ i, j, k })` for each cubie. The index in `solvedGrid` matches the `idx` of the cubie (since we push null for the center but don't increment idx, and push the real entry for non-center and do increment idx).

Wait, that's not right. Let me trace more carefully:

- i=0,j=0,k=0: not center. push {0,0,0} to solvedGrid at index 0. idx becomes 1.
- i=0,j=0,k=1: not center. push {0,0,1} to solvedGrid at index 1. idx becomes 2.
- ...
- i=1,j=1,k=0: not center. push {1,1,0} to solvedGrid at index... let me count. Before this, we've done i=0 (9 cubies, idx 0-8), i=1,j=0 (3 cubies, idx 9-11), i=1,j=1,k=0 (idx 12). So solvedGrid[12] = {1,1,0}. idx becomes 13.
- i=1,j=1,k=1: CENTER. push null to solvedGrid at index 13. idx stays 13.
- i=1,j=1,k=2: not center. push {1,1,2} to solvedGrid at index 14. idx becomes 14.

So solvedGrid has entries 0-26 (27 entries), with index 13 being null. But cubies has 26 entries (idx 0-25). 

The issue: `solvedGrid[cubie.idx]` gives the solved grid position for that cubie. Since cubie.idx goes from 0 to 25, and solvedGrid has entries 0-26 with index 13 being null... 

For cubie with idx=12 (which is at grid position {1,1,0}), solvedGrid[12] = {1,1,0}. ✓
For cubie with idx=13 (which is at grid position {1,1,2}), solvedGrid[13] = null. ✗

This is a bug! The idx doesn't match the solvedGrid index because we pushed null for the center but didn't skip the solvedGrid index.

Actually wait, let me re-trace. The issue is that `solvedGrid` is pushed for every grid position (including the center with null), but `cubies` only has entries for non-center positions. So `solvedGrid[cubie.idx]` will be wrong for cubies after the center.

Let me fix this. I'll make `solvedGrid` only contain entries for actual cubies (no null for center).

Actually, I don't even use `solvedGrid` anywhere in my code! Let me check... No, I don't use it. I only use `cubies` array and `grid` mapping. So the `solvedGrid` array is unused. I can remove it or fix it, but it doesn't affect functionality.

Actually, I should remove it to avoid confusion. But it's not causing bugs. Let me focus on testing the actual functionality.

Let me also check: in `buildSolvedCube`, when I create the cubie, I set `c.gridI = i, c.gridJ = j, c.gridK = k`. These are the initial grid positions. Good.

The `grid` mapping: `grid[gridKey(i, j, k)] = idx`. This maps grid positions to cubie indices. Good.

Now, in `finishAnimation`, I rebuild the `grid` mapping from current cubie positions:
```javascript
grid = {};
for (const c of cubies) {
  grid[gridKey(c.gridI, c.gridJ, c.gridK)] = c.idx;
}
```
This is correct.

Now let me check the move computation. In `computeNewGridPos`, I convert the cubie's current grid position to world, rotate around the move center, and convert back. This should give the new grid position.

But there's a subtlety: the cubie's current grid position is tracked in `c.gridI, c.gridJ, c.gridK`. After a move, I update these in `finishAnimation`. But during the animation, the cubie's visual position is interpolated, while the grid position is not updated until the end. This is correct because the grid position is a discrete value that only changes at the end of the move.

Now, for the `computeNewQuat` function:
```javascript
function computeNewQuat(ci, moveDef) {
  const c = cubies[ci];
  const q = new THREE.Quaternion().setFromAxisAngle(
    new THREE.Vector3(moveDef.axis[0], moveDef.axis[1], moveDef.axis[2]),
    moveDef.angle
  );
  return q.clone().multiply(c.quat);
}
```

This computes `moveQuat * oldQuat`. In Three.js, `q1.multiply(q2)` sets `q1 = q1 * q2`. And `q1 * q2` applies `q2` first, then `q1`. So `moveQuat * oldQuat` applies `oldQuat` first, then `moveQuat`.

Is this correct? The cubie's current orientation is `oldQuat` (mapping from local to world). The move rotation `moveQuat` is applied in world space. So the new orientation should be: first apply `oldQuat` (to get to current world), then apply `moveQuat` (to rotate in world space). So `newQuat = moveQuat * oldQuat`. ✓

Now let me check the animation. In `updateAnimation`, I use `slerpQuaternions` to interpolate between start and end quaternions. This should give a smooth rotation. ✓

Let me also check the camera orbit. The `camTheta` and `camPhi` are updated on drag, and `updateCamera` computes the new camera position. This should work.

One issue: when I do `updateCamera()` in the mousemove handler, I'm calling it every frame during drag. This should be fine.

Another issue: the wheel zoom listens on `renderer.domElement`. But the event listener is set with `{ passive: false }` and calls `e.preventDefault()`. This should prevent page scroll. ✓

Let me also check the button states. When animating, buttons are disabled. When the animation queue is processing, buttons remain disabled. ✓

Now let me think about potential issues with the move definitions:

For U (top layer, j=2), the rotation is -π/2 around Y, centered at (1, 2, 1). Let me verify this is clockwise from above.

Looking from above (+Y toward -Y), a negative rotation around Y (right-hand rule) rotates +X toward -Z. So the front (+Z) goes to the right (+X). That's clockwise from above. ✓

For D (bottom layer, j=0), the rotation is +π/2 around Y, centered at (1, 0, 1). Looking from below (-Y toward +Y), a positive rotation around Y rotates +X toward +Z. So from below, the front (+Z) goes to the left (-X)... wait, that doesn't sound right.

Let me reconsider. For D, I want clockwise from below. Looking from below (-Y toward +Y), the axes are:
- +X is to the right (same as from above)
- +Z is... to the left? Or to the back?

If I'm standing below the cube looking up, the front of the cube (which is +Z from the standard view) is now away from me (since I'm looking up from below). So +Z is toward the back from my perspective.

Clockwise from below: from my perspective, clockwise means... let me think. If I'm looking up at a clock on the ceiling, the hands move clockwise from my perspective. The 12 is away from me (north), 3 is to my left (west), 6 is near me (south), 9 is to my right (east).

In our coordinate system, from below:
- +Z (front of cube) is north (away from me)
- -Z (back of cube) is south (toward me)
- +X (right of cube) is east (to my right)
- -X (left of cube) is west (to my left)

Wait, that doesn't seem right. If I'm below looking up, and the cube's front is +Z, then from my perspective, the front is... let me think about the orientation.

If I'm at (0, -10, 0) looking at (0, 0, 0), my view direction is (0, 1, 0). The camera's up vector is (0, 1, 0) by default, but since I'm looking along Y, the up vector would be reoriented.

Actually, in Three.js, if I place the camera at (0, -10, 0) looking at (0, 0, 0), the camera's default up vector is (0, 1, 0). But the camera is looking along +Y, so the up vector (0, 1, 0) is parallel to the view direction. Three.js would reorient the camera to keep the up vector perpendicular to the view direction.

This is getting complicated. Let me just trust my move definitions and verify them by testing (U followed by U' should return to solved state).

Actually, let me reconsider the D move. I defined D as +π/2 around Y, centered at (1, 0, 1). Let me verify this is clockwise from below by checking where a cubie goes.

Cubie at (1, 0, 2) [bottom-front-center]:
- World position: (0, -1, 1)
- Center: (0, -1, 0)
- Relative: (0, 0, 1)
- After rotation by +π/2 around Y: x' = -sin(π/2) = -1, z' = cos(π/2) = 0. So (-1, 0, 0).
- Absolute: (-1, -1, 0)
- Grid: (0, 0, 1) [bottom-left-center]

So (1, 0, 2) → (0, 0, 1). From below, the front-bottom-center goes to the left-bottom-center.

From below, looking up: front is away from me (north), left is to my left (west). So front → left is clockwise from below. ✓

Great, the D move is correct.

Now let me verify R. R is +π/2 around X, centered at (2, 1, 1). Clockwise from right.

From the right side (+X toward -X), looking at the cube:
- +Y is up
- +Z is... to the left? Or right?

If I'm at (10, 0, 0) looking at (0, 0, 0), view direction is (-1, 0, 0). The camera's right vector is up × viewDir = (0,1,0) × (-1,0,0) = (0, 0, 1). So +Z is to the right.

Clockwise from right: up → right → down → left → up, i.e., +Y → +Z → -Y → -Z → +Y.

For R (+π/2 around X): +Y → +Z. ✓ (Positive rotation around X rotates +Y toward +Z.)

Let me verify with a cubie. Cubie at (2, 2, 1) [right-top-center]:
- World: (1, 1, 0)
- Center: (1, 0, 0)
- Relative: (0, 1, 0)
- After +π/2 around X: y' = cos(π/2) = 0, z' = sin(π/2) = 1. So (0, 0, 1).
- Absolute: (1, 0, 1)
- Grid: (2, 1, 2) [right-front-center]

So (2, 2, 1) → (2, 1, 2). Right-top-center → right-front-center. Clockwise from right: top → front. ✓

Now let me verify F. F is +π/2 around Z, centered at (1, 1, 2). Clockwise from front.

From the front (+Z toward -Z), looking at the cube:
- +Y is up
- +X is... to the left? 

If I'm at (0, 0, 10) looking at (0, 0, 0), view direction is (0, 0, -1). The camera's right vector is up × viewDir = (0,1,0) × (0,0,-1) = (-1, 0, 0). So +X is to the left (since right = -X).

Wait, that means from the front, +X is to the left and -X is to the right.

Clockwise from front: up → right → down → left → up, i.e., +Y → -X → -Y → +X → +Y.

For F (+π/2 around Z): let me check. Rotation by +π/2 around Z:
- x' = x*cos(π/2) - y*sin(π/2) = -y
- y' = x*sin(π/2) + y*cos(π/2) = x

So (0, 1, 0) → (-1, 0, 0). That's +Y → -X. ✓ (Clockwise from front: up → right, and right is -X from this view.)

Let me verify with a cubie. Cubie at (1, 2, 2) [front-top-center]:
- World: (0, 1, 1)
- Center: (0, 0, 1)
- Relative: (0, 1, 0)
- After +π/2 around Z: (-1, 0, 0)
- Absolute: (-1, 0, 1)
- Grid: (0, 1, 2) [front-left-center]

So (1, 2, 2) → (0, 1, 2). Front-top-center → front-left-center. Clockwise from front: top → left. ✓

Now let me verify B. B is -π/2 around Z, centered at (1, 1, 0). Clockwise from back.

From the back (-Z toward +Z), looking at the cube:
- +Y is up
- +X is to the right (mirror of front view)

Clockwise from back: +Y → +X → -Y → -X → +Y.

For B (-π/2 around Z):
- x' = x*cos(-π/2) - y*sin(-π/2) = y
- y' = x*sin(-π/2) + y*cos(-π/2) = -x

So (0, 1, 0) → (1, 0, 0). That's +Y → +X. ✓ (Clockwise from back: up → right, and right is +X from this view.)

Let me verify with a cubie. Cubie at (1, 2, 0) [back-top-center]:
- World: (0, 1, -1)
- Center: (0, 0, 0)
- Relative: (0, 1, -1)
- After -π/2 around Z: x' = y = 1, y' = -x = 0. So (1, 0, -1).
- Absolute: (1, 0, -1)
- Grid: (2, 1, 0) [back-right-center]

So (1, 2, 0) → (2, 1, 0). Back-top-center → back-right-center. Clockwise from back: top → right. ✓

All move definitions are correct.

Now let me check the inverses:
- U' should be the inverse of U. U = -π/2 around Y. U' = +π/2 around Y. ✓
- D' should be the inverse of D. D = +π/2 around Y. D' = -π/2 around Y. ✓
- R' should be the inverse of R. R = +π/2 around X. R' = -π/2 around X. ✓
- L' should be the inverse of L. L = -π/2 around X. L' = +π/2 around X. ✓
- F' should be the inverse of F. F = +π/2 around Z. F' = -π/2 around Z. ✓
- B' should be the inverse of B. B = -π/2 around Z. B' = +π/2 around Z. ✓

All inverses are correct.

Now let me think about the animation. When I do a U move followed by U', the cubies should return to their original positions and orientations.

For the position: U moves cubies in the top layer by -π/2 around Y. U' moves them by +π/2 around Y. The net rotation is 0. So positions return to original. ✓

For the orientation: U applies `R_u * oldQuat` where `R_u` is -π/2 around Y. U' applies `R_u' * newQuat` where `R_u'` is +π/2 around Y. The net quaternion is `R_u' * R_u * oldQuat = identity * oldQuat = oldQuat`. ✓

Wait, but I need to check the order. After U, the cubie's quaternion is `R_u * oldQuat`. After U', the cubie's quaternion is `R_u' * (R_u * oldQuat) = (R_u' * R_u) * oldQuat`. Since `R_u' = R_u^-1`, we have `R_u' * R_u = identity`. So the final quaternion is `oldQuat`. ✓

Great, the math checks out.

Now let me think about the scramble function. I generate 22 random moves, avoiding consecutive same-face moves. Then I execute them one by one. The first move is executed immediately, and the rest are queued.

Wait, there's an issue with my scramble implementation. Let me re-read it:

```javascript
function scramble() {
  if (isAnimating) return;
  const moves = [];
  // ... generate 22 moves ...
  let idx = 0;
  function nextScrambleMove() {
    if (idx >= moves.length) {
      setStatus('Scrambled');
      return;
    }
    if (isAnimating) {
      setTimeout(nextScrambleMove, 50);
      return;
    }
    const m = moves[idx];
    setStatus(`Scramble: ${m}`);
    startAnimation(MOVE_DEFS[m]);
    idx++;
    if (idx < moves.length) {
      for (let j = idx; j < moves.length; j++) {
        animQueue.push(MOVE_DEFS[moves[j]]);
      }
      idx = moves.length;
    }
  }
  nextScrambleMove();
}
```

The issue: I call `startAnimation` for the first move, which sets `isAnimating = true`. Then I push the remaining moves to `animQueue`. The queue is processed in `finishAnimation`. So the moves should play sequentially.

But there's a race condition: if `startAnimation` is called and immediately sets `isAnimating = true`, but the animation hasn't started yet (it starts in the next render frame), the `animQueue` might not be processed correctly.

Actually, looking at `startAnimation`:
```javascript
function startAnimation(moveDef) {
  if (isAnimating) {
    animQueue.push(moveDef);
    return;
  }
  isAnimating = true;
  // ...
  currentAnim = { ... };
}
```

And `finishAnimation`:
```javascript
function finishAnimation() {
  // ...
  isAnimating = false;
  if (animQueue.length > 0) {
    const next = animQueue.shift();
    startAnimation(next);
  }
  // ...
}
```

So when the first move's animation finishes, `finishAnimation` is called, which pops the next move from the queue and starts it. This should work correctly.

But in my scramble function, I push all remaining moves to the queue at once:
```javascript
for (let j = idx; j < moves.length; j++) {
  animQueue.push(MOVE_DEFS[moves[j]]);
}
```

This is fine. The queue will be processed one at a time.

However, there's a potential issue: the scramble function checks `isAnimating` and waits if true. But after the first move is started, `isAnimating` is true, so the function returns. The remaining moves are queued. When the first move finishes, `finishAnimation` pops the next move and starts it. This continues until all moves are done.

But wait, I set `idx = moves.length` after pushing to the queue. So the `nextScrambleMove` function won't be called again (since `idx >= moves.length`). The queue processing handles the rest.

Actually, there's a subtle issue. The `nextScrambleMove` function is called recursively via `setTimeout` if `isAnimating`. But I set `idx = moves.length` after the first call, so the function won't be called again. The queue handles the rest.

Hmm, but what if the queue processing is slower than the `setTimeout`? Let me trace:

1. `nextScrambleMove()` is called.
2. `idx = 0`, `isAnimating = false`.
3. We call `startAnimation(MOVE_DEFS[moves[0]])`. This sets `isAnimating = true`.
4. We push moves[1..21] to `animQueue`.
5. We set `idx = 22`.
6. The function returns.
7. In the render loop, `updateAnimation` is called, which animates the first move.
8. When the first move finishes, `finishAnimation` is called, which pops moves[1] from the queue and calls `startAnimation(moves[1])`.
9. This continues until all moves are done.

This should work correctly. ✓

But there's one issue: in step 3, I call `startAnimation`, which sets `isAnimating = true`. But the function `nextScrambleMove` continues to step 4 and 5, pushing to the queue and setting `idx = 22`. This is fine because the queue is processed asynchronously.

However, there's a potential issue with the `setTimeout` retry. If `isAnimating` is true when `nextScrambleMove` is called (e.g., if scramble is called while another animation is in progress), the function waits 50ms and retries. But I also check `isAnimating` at the start of `scramble()` and return if true. So this shouldn't happen.

Actually, wait. The check at the start of `scramble()` is:
```javascript
if (isAnimating) return;
```

So if scramble is called while animating, it returns immediately. But the user might click scramble while an animation is in progress. In that case, the scramble is ignored. This might be confusing. Let me change it to queue the scramble.

Actually, for simplicity, let me keep it as is. If the user clicks scramble while animating, nothing happens. They can click again after the animation finishes.

Hmm, but this might be frustrating. Let me change it to queue the scramble. I'll add a `scrambleQueue` or just use the move queue.

Actually, let me think about this differently. The scramble generates a sequence of moves. If I queue the entire scramble, I need to ensure the moves are executed in order. The current queue system handles this.

Let me modify the scramble function to queue the entire sequence:

```javascript
function scramble() {
  if (isAnimating) {
    // Queue the scramble to run after current animation
    animQueue.push({ type: 'scramble' });
    return;
  }
  // ... generate moves ...
  // Push all moves to queue
  for (const m of moves) {
    animQueue.push(MOVE_DEFS[m]);
  }
  // Start the first move
  if (!isAnimating) {
    startAnimation(MOVE_DEFS[moves[0]]);
  }
}
```

Wait, but this is essentially what I have, except I handle the `isAnimating` case differently.

Let me simplify. I'll modify the scramble to always queue the moves, and start the first one if not animating:

```javascript
function scramble() {
  const moves = [];
  // ... generate 22 moves ...
  if (isAnimating) {
    // Queue all moves; they'll be processed after current animation
    for (const m of moves) {
      animQueue.push(MOVE_DEFS[m]);
    }
    setStatus('Scramble queued');
    updateButtons();
    return;
  }
  // Start first move, queue rest
  startAnimation(MOVE_DEFS[moves[0]]);
  for (let j = 1; j < moves.length; j++) {
    animQueue.push(MOVE_DEFS[moves[j]]);
  }
  setStatus('Scrambling...');
  updateButtons();
}
```

This is cleaner. Let me update the code.

Actually, I realize there might be an issue with the current code. Let me re-examine the `scramble` function:

```javascript
function scramble() {
  if (isAnimating) return;
  const moves = [];
  const faces = ['U','D','R','L','F','B'];
  let lastFace = '';
  for (let i = 0; i < 22; i++) {
    let face;
    do {
      face = faces[Math.floor(Math.random() * faces.length)];
    } while (face === lastFace);
    lastFace = face;
    const prime = Math.random() < 0.5;
    moves.push(prime ? `${face}'` : face);
  }
  let idx = 0;
  function nextScrambleMove() {
    if (idx >= moves.length) {
      setStatus('Scrambled');
      return;
    }
    if (isAnimating) {
      setTimeout(nextScrambleMove, 50);
      return;
    }
    const m = moves[idx];
    setStatus(`Scramble: ${m}`);
    startAnimation(MOVE_DEFS[m]);
    idx++;
    if (idx < moves.length) {
      for (let j = idx; j < moves.length; j++) {
        animQueue.push(MOVE_DEFS[moves[j]]);
      }
      idx = moves.length;
    }
  }
  nextScrambleMove();
}
```

The issue: after calling `startAnimation`, `isAnimating` is true. Then I push the rest to the queue. But the `nextScrambleMove` function is not called again (since `idx = moves.length`). The queue is processed in `finishAnimation`.

But what if `isAnimating` is true when `nextScrambleMove` is called the first time? The check `if (isAnimating) return;` at the start of `scramble()` prevents this. So the first call to `nextScrambleMove` always has `isAnimating = false`.

After `startAnimation`, `isAnimating = true`. The function pushes the rest to the queue and sets `idx = moves.length`. The function returns. The queue is processed in `finishAnimation`.

This should work. But there's a subtle issue: the `setTimeout` in `nextScrambleMove` is only called if `isAnimating` is true. But after the first call, `isAnimating` is always true (until the first move finishes). So if `nextScrambleMove` were called again, it would wait via `setTimeout`. But it's not called again because `idx = moves.length`.

OK, the scramble function should work. Let me also handle the case where scramble is clicked while animating. Currently, it returns immediately. Let me change it to queue the scramble.

Actually, let me just test the current implementation and see if it works. If there are issues, I'll fix them.

Let me also think about the reset function. Currently:
```javascript
function resetCube() {
  if (isAnimating) {
    animQueue = [];
    const checkReset = () => {
      if (isAnimating) {
        setTimeout(checkReset, 100);
        return;
      }
      doReset();
    };
    checkReset();
    return;
  }
  doReset();
}
```

This waits for the current animation to finish, then resets. But it also clears the queue. This might be unexpected if the user has a scramble in progress. Let me change it to wait for the current animation and queue to finish.

Actually, for the reset, I think it's fine to clear the queue and reset immediately after the current animation. The user explicitly clicked reset, so they want to reset now.

But there's an issue: if I clear the queue and then wait for the current animation, the queue is already cleared. So when the current animation finishes, `finishAnimation` will check the queue, find it empty, and set `isAnimating = false`. Then `checkReset` will call `doReset()`.

Wait, but `checkReset` is polling every 100ms. When `isAnimating` becomes false, `checkReset` calls `doReset()`. But `finishAnimation` might set `isAnimating = false` and then process the queue (which is empty). So `isAnimating` becomes false, and `checkReset` calls `doReset()`.

But there's a race condition: `checkReset` might call `doReset()` while `finishAnimation` is still running. Let me trace:

1. `resetCube()` is called while animating.
2. `animQueue = []` (clear queue).
3. `checkReset()` is called.
4. `isAnimating = true`, so `setTimeout(checkReset, 100)`.
5. ... time passes ...
6. Current animation finishes. `finishAnimation()` is called.
7. `finishAnimation` commits the state, sets `isAnimating = false`.
8. `finishAnimation` checks the queue (empty), so it doesn't start a new animation.
9. `finishAnimation` calls `updateButtons()` and `setStatus('Ready')`.
10. `checkReset()` is called (from the setTimeout).
11. `isAnimating = false`, so `doReset()` is called.
12. `doReset()` rebuilds the cube and resets the camera.

This should work. But there's a potential issue: between steps 7 and 11, `isAnimating` is false, but the animation might not be fully committed (step 7 commits the state, so it should be fine).

Actually, step 7 commits the state (updates cubie positions and grid mapping). So by the time `checkReset` calls `doReset()`, the cube is in a consistent state. ✓

OK, I think the implementation is correct. Let me now test it by running the browser.

But first, let me fix a few issues I noticed:

1. The `solvedGrid` array is unused and has a bug (index mismatch). I'll remove it.
2. The scramble function should queue the scramble if called while animating.
3. The reset function should be more robust.

Let me update the code.

Actually, let me first test the current implementation to see if it works. Then I'll fix any issues.

Let me also add a visual indicator for the move buttons (highlight the button being animated).

OK let me test first.

Wait, I realize there's another issue. In my `buildSolvedCube` function, I dispose of the old geometries and materials, but I also need to dispose of the old cubie groups. Let me check:

```javascript
function buildSolvedCube() {
  for (const c of cubies) {
    scene.remove(c.group);
    c.mesh.geometry.dispose();
    c.mesh.material.forEach(m => m.dispose());
    c.edges.geometry.dispose();
    c.edges.material.dispose();
  }
  cubies = [];
  grid = {};
  solvedGrid = [];
  // ... create new cubies ...
}
```

I remove the group from the scene and dispose of the geometries and materials. But I don't dispose of the group itself. In Three.js, removing a group from the scene doesn't dispose of it; it just removes it from the scene graph. The group and its children are still in memory. But since I'm creating new objects and the old ones are no longer referenced (except by the disposed geometries/materials), the old objects will be garbage collected.

Actually, there's a potential issue: the old `mesh.geometry` is disposed, but the `mesh` itself is still referenced by the old `group`. When I create new cubies, I create new meshes with new geometries. The old meshes are no longer used, but they're still in memory (referenced by the old groups, which are no longer in the scene).

But since I set `cubies = []`, the old cubie objects are no longer referenced by my code. The old groups are no longer in the scene. So the old objects should be garbage collected.

However, there's a subtlety: the `mesh.material` array contains references to the materials. I dispose of the materials, but the materials might still be referenced by the mesh. When the mesh is garbage collected, the materials will be garbage collected too (since they're no longer referenced elsewhere).

Actually, disposing of a material in Three.js removes it from the renderer's internal list and frees GPU resources. But the JavaScript object is still in memory until it's garbage collected. Since I dispose of the materials and remove the meshes from the scene, the materials should be garbage collected eventually.

OK, I think the memory management is fine for a single-page app that doesn't repeatedly build and destroy the cube. The reset function is called occasionally, not in a loop.

Let me now test the implementation.

Actually, let me also think about one more thing: the cubie's edges. I use `EdgesGeometry` to create the edges. The edges are a `LineSegments` object. When the cubie rotates, the edges rotate with it (since they're children of the cubie's group). ✓

And the edges should be visible in the gaps between cubies, showing the cubie boundaries. ✓

Let me now run the browser test.

One more thing: I should make sure the cube is fully visible initially. The camera is at (4.2, 3.0, 4.2), looking at the origin. The cube extends from -1.46 to 1.46 in each axis (approximately). The camera distance is about 6.7. With a 45° field of view, the visible height at distance 6.7 is about 2 * 6.7 * tan(22.5°) ≈ 5.5. So the cube (height 2.92) should fit comfortably in the view. ✓

Let me now test.

Actually, I want to double-check one thing about the cubie creation. In `createCubieMaterials`, I create 6 materials for the 6 faces. The order for `BoxGeometry` is: +x, -x, +y, -y, +z, -z. Let me verify this is the correct order for Three.js.

In Three.js, `BoxGeometry` applies materials in the order: +x, -x, +y, -y, +z, -z. This is documented in the Three.js docs. ✓

So my `faceMap` array is in the correct order:
1. +x (right)
2. -x (left)
3. +y (top)
4. -y (bottom)
5. +z (front)
6. -z (back)

✓

Now let me test the implementation in the browser.

Actually, I realize I should also handle the case where the cubie's materials need to be updated when the cubie moves. But in my implementation, the materials are fixed to the cubie (they don't change when the cubie moves). This is correct for a Rubik's cube: the stickers are fixed to the cubie, and they move with the cubie.

But there's a visual issue: when a cubie is in the interior of the big cube (not on any face), all its faces are internal (dark). But the cubie is still visible as a dark box. This is correct for a Rubik's cube: the interior cubies are visible as dark boxes when the cube is disassembled, but in a assembled cube, they're hidden by the exterior cubies.

In my 3D model, the cubies have gaps between them, so the interior cubies are visible as dark boxes. This is actually a nice visual effect: you can see the internal structure of the cube.

But wait, in a real Rubik's cube, the interior cubies are not visible (they're hidden by the exterior cubies and the internal mechanism). In my 3D model, the gaps between cubies make the interior visible. This might look odd.

To fix this, I could make the cubies larger (no gaps), so the interior is hidden. But then the cubie boundaries wouldn't be visible.

Alternatively, I could use a different approach: render the cube as a solid with colored faces, and use a wireframe to show the cubie boundaries. But this is more complex.

For now, let me keep the gaps and accept that the interior cubies are visible as dark boxes. This is a common approach in 3D Rubik's cube visualizations.

Actually, looking at my code, I skip the center cubie (1,1,1). So there are 26 cubies, not 27. The center cubie is the core, which is never visible. The other 26 cubies include:
- 8 corner cubies (3 exterior faces)
- 12 edge cubies (2 exterior faces)
- 6 center cubies (1 exterior face)

All 26 cubies have at least one exterior face (in the solved state). So all 26 cubies have at least one colored face. The interior faces are dark.

When the cube is scrambled, a cubie might be in a position where all its faces are interior. For example, a corner cubie scrambled to the center of a face would have 3 colored faces (which are now interior) and 3 dark faces (which are now exterior). Wait, no. The cubie's colored faces are fixed to the cubie. If the cubie is in a position where its colored faces are interior, those faces are dark (not visible). The cubie's dark faces might be exterior, but they're dark (not colored).

Hmm, this is the correct behavior for a Rubik's cube. The stickers are fixed to the cubie, and they're only visible when the cubie's face is on the exterior of the big cube.

But in my 3D model, the cubie's dark faces are always dark (0x2a2a3a). When a dark face is on the exterior, it appears as a dark face. This is correct: in a real Rubik's cube, the unstickered faces are black/dark.

OK, I think the implementation is correct. Let me now test it.

Let me also add a small improvement: when a cubie is in a position where all its faces are interior, it should be less visible (or invisible). But this is complex to implement, and it's not required by the task. Let me skip it.

Let me now run the browser test.

Actually, I want to reconsider the gap size. With `CUBIE_SIZE = 0.92` and `SPACING = 1.0`, the gap is 0.04 on each side (0.08 total between adjacent cubies). This might be too small to see the boundaries clearly.

Let me increase the gap to 0.06 on each side (0.12 total). So `CUBIE_SIZE = 0.88`.

Actually, let me think about this. The cubie boundaries should be visible but not too prominent. A gap of 0.04 on each side (0.08 total) should be visible with the dark edges. Let me keep `CUBIE_SIZE = 0.92` for now and adjust if needed.

Hmm, actually, I realize that the edges (LineSegments) are rendered on top of the cubie faces. The edges have a dark color (0x0a0a15). So even with a small gap, the edges should be visible.

But the edges are inside the cubie group, so they rotate with the cubie. The edges are at the boundary of the cubie (0.92/2 = 0.46 from center). The gap between cubies is 0.04 on each side. So the edges are 0.04 away from the gap. The edges should be visible in the gap.

Wait, the edges are at the cubie boundary (0.46 from center). The gap is between cubies (0.04 from each cubie's boundary). So the edges are at the edge of the gap. The edges should be visible.

Actually, the edges are rendered as lines at the cubie boundary. The lines have a dark color. In the gap between cubies, the dark background (0x16162a) is visible. The edges (0x0a0a15) are darker than the background. So the edges should be visible as dark lines in the gap.

Hmm, but the edges might be hard to see against the dark background. Let me use a lighter color for the edges, like 0x3a3a4a or 0x4a4a5a.

Actually, let me use a slightly lighter dark color for the edges: 0x1a1a2a. This should be visible against the background (0x16162a) and the cubie faces.

Wait, the background is 0x16162a and the edges are 0x0a0a15. The edges are darker than the background. So the edges should be visible as darker lines.

But actually, the edges are at the cubie boundary, which is adjacent to the cubie face. The cubie face has a color (e.g., red). The edge is dark. So the edge creates a dark border around the colored face. This is the "visible cubie boundary" effect.

OK, I think the edges will be visible. Let me test.

Let me now run the browser test. I'll use the `browser` tool to load the page and inspect it.

Actually, let me first make a few improvements to the code:

1. Increase the gap slightly for better visibility.
2. Use a slightly lighter edge color.
3. Fix the scramble to queue properly.
4. Remove the unused `solvedGrid` array.

Let me update the code.

Actually, let me first test the current implementation to see if it works. Then I'll make improvements.

Let me run the browser.

The cube is rendering. Let me do a quick verification: turn a face and its inverse, then orbit and reset. Let me check the visual first with a screenshot, then run the verification.

Good, the page is loaded. Let me verify the functionality:

1. Click U then U' - should return to solved state
2. Orbit the camera
3. Reset

Let me click U first.

U button clicked, status changed to "Animating...". Let me wait for the animation to complete, then click U'.

Hmm, the U' button is right next to U. Let me check the positions. The buttons are in a row: U, U′, D, D′. The U button was at x=550, y=720. The U' button should be at x=550+44+8 = 602, y=720. I clicked at 600, 720 which should be U'. But the status still shows "Animating..." which means either the animation is still running or the click didn't register.

Wait, the animation duration is 320ms. Let me wait a bit and check the status.

Actually, looking at the DOM output, it still shows "Animating..." which means the first animation (U) is still running or the U' click didn't register because buttons are disabled during animation.

Let me check: in my code, `updateButtons()` disables all buttons when `isAnimating` is true. So the U' button should be disabled during the U animation. The click on U' should have no effect.

Let me wait for the animation to complete and then check.

Actually, I should just wait and then check the state via the console. Let me use the __rubiks API to check the state.

But first, let me wait a bit.

Let me check the state via the console now.

Status is "Ready" now. The U animation completed. Now let me click U' to undo it.

Good, U' clicked, status shows "Animating...". Let me wait for it to complete and then check the state.

Let me check the state via console now.

Still "Animating...". The animation duration is 320ms. Let me wait a bit more.

Let me check the state via the console by evaluating JavaScript.

Status is "Ready" now. U' animation completed. Now let me check the state via the console to verify that the cube returned to solved state.

Let me evaluate `window.__rubiks.getState()` to check the cubie positions.

The console didn't show the output. Let me try a different approach - use the evaluate action or check via a different method.

Actually, the `type` action types into the page, but the output might not be shown. Let me try to evaluate the JavaScript directly.

Wait, I don't have an "evaluate" action. Let me try typing a simpler command and check the console log.

Actually, looking at the tools, I have `browser` with actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. None of these evaluate JavaScript.

But I can type JavaScript into the page's console or a text field. But there's no console visible in the page.

Let me try a different approach: I'll add a test button to the page that shows the state, or I'll modify the page to log the state.

Actually, the console logs are shown in the browser output. Let me type something that will log to the console.

Wait, I can type into the page. If I type `javascript:...` it might execute. But that's for the URL bar, not for typing.

Let me try typing into a hidden textarea or using the key action to press Enter after typing.

Actually, the simplest approach: I'll modify the page to add a debug button that shows the state, or I'll just trust that the implementation is correct based on the math I verified.

But the task requires verification. Let me add a small debug feature to the page.

Actually, let me just add a console.log statement that I can trigger. Let me modify the page to add a "Verify" button that logs the state.

Wait, I should just verify via the screenshot. Let me check the visual state.

Actually, let me think about this differently. The task says to verify that:
1. Turn one face and apply its inverse, checking that the visible stickers return to their starting arrangement.
2. Orbit the camera to inspect the cube from another angle.
3. Use Reset and check the solved appearance and initial framing.

For verification #1, I need to check that after U then U', the stickers are in the same positions as before. Visually, I can check this by looking at the screenshot. But I need a before and after comparison.

For verification #2, I can orbit the camera and check the screenshot.

For verification #3, I can click Reset and check the screenshot.

Let me do these verifications visually.

First, let me get a screenshot of the current state (after U, U' - should be solved).

I can't see the screenshot visually (the images field says "model does not support images"). But I can check the DOM and console.

Let me try a different approach. I'll modify the page to add a "debug" output that shows the cube state. Or I'll use the console log to verify.

Actually, looking at the browser tool more carefully, it seems like the screenshot is taken but the image isn't returned to me (the "images" field says "model does not support images"). This is a limitation of the tool.

Let me try to verify via the console. I'll type a JavaScript command that logs the state to the console.

Actually, I can use the `type` action to type into the page, and if there's a console, the output should appear. But the page doesn't have a visible console.

Let me try a different approach: I'll modify the page to show the cube state in a visible element. I'll add a debug div that shows the state.

Actually, the simplest approach is to add a "Verify" button that compares the current state to the solved state and shows a message.

Let me modify the page to add this feature. But I need to be quick since I only have 5 minutes left.

Let me add a simple verification: after U and U', the cube should be solved. I'll check this by comparing the current grid positions to the solved grid positions.

Let me modify the page to add a debug output.

Actually, let me just verify via the console by typing a command that logs the state. I'll type `console.log(JSON.stringify(window.__rubiks.getState()))` and check the console output.

Wait, the `type` action types into the page, not into the console. I need to find a way to execute JavaScript in the page.

Let me try using the `key` action to press F12 (to open the developer console) and then type into the console. But this might not work in the iframe.

Actually, let me just add a visible debug element to the page. I'll modify the HTML to add a "State" display.

Let me do this quickly.

Let me add a state verification display. I'll add it to the #info area or create a new element. Let me modify the page to add a small state display.

Actually, let me just add a console.log verification. I'll modify the page to log the state when a specific button is clicked.

Let me add a "Check State" button that logs the state to the console. Or better, I'll add a small display that shows whether the cube is solved.

Let me modify the page quickly.

Now let me add the verification logic. I'll add a function that checks if the cube is solved and displays it.

Now I need to modify `buildSolvedCube` to store the solved grid positions for each cubie. Let me update that function.

Let me read the file to see the exact content.

Let me find the buildSolvedCube function to see its exact content.

Now I can see the exact content. Let me update the buildSolvedCube function to return the solved positions and store them globally.

Now I need to update the code that calls buildSolvedCube to store the solved positions. Let me find where it's called.

Wait, I called buildSolvedCube twice. Let me fix that.

Now I need to update the doReset function to use the solvedGridPositions. Let me find and update it.

Let me read the current state of the file around the doReset function.

Let me find the doReset and checkSolvedState functions.

Now I can see the doReset function. Let me read more to see the checkSolvedState function.

I see the issue. The `checkSolvedState` function references `solvedGrid` which no longer exists (I renamed it to `solvedGridPositions` in the buildSolvedCube function, but didn't update the reference). Also, the `doReset` function doesn't store the solved positions.

Let me fix these issues.

Let me read the exact content around doReset.

I see the issue - there's a comment line `// Check if all cubies are in their solved positions with identity quat` that I need to match exactly. Let me try a different approach - use sed to make the changes.

The sed command is failing because of the special characters. Let me use a different approach - write a Python script to make the changes.

Python3 is not available. Let me try node.js.

Now let me reload the page and test.

Hmm, it shows "✗ Scrambled" initially. This is wrong - it should be "✓ Solved" when the cube is first built. Let me check the issue.

The problem might be that `solvedGridPositions` is not being set correctly. Let me check the init code.

Actually, looking at my edits, I changed the init code to:
```javascript
let solvedGridPositions = buildSolvedCube();
```

But then I also have `checkSolvedState()` which uses `solvedGridPositions`. The issue might be that `solvedGridPositions` is not in scope when `checkSolvedState` is called.

Wait, I defined `let solvedGridPositions = buildSolvedCube();` in the init section. But `checkSolvedState` is defined later. Since JavaScript has function scope for `var` but block scope for `let`, and I'm using `let`, the `solvedGridPositions` should be available in the scope where `checkSolvedState` is defined (since they're both at the top level).

Actually, the issue might be that I'm calling `checkSolvedState()` before `solvedGridPositions` is defined. Let me check the order.

Looking at my edit:
```javascript
// ─── Init ──────────────────────────────────────────────────────────
let solvedGridPositions = buildSolvedCube();
updateCamera();
updateButtons();
setStatus('Solved');
checkSolvedState();
animate();
```

This should work. `solvedGridPositions` is defined before `checkSolvedState()` is called.

But wait, the `checkSolvedState` function is defined later in the file (after the `doReset` function). In JavaScript, function declarations are hoisted, so `checkSolvedState` should be available.

Let me check if there's an error in the console. The console shows "Rubik's Cube ready." which means the script ran without errors.

But the verify element shows "✗ Scrambled". Let me check if `checkSolvedState` is actually being called and if `solvedGridPositions` has the correct values.

Actually, let me check the init code more carefully. The issue might be that I'm defining `solvedGridPositions` with `let` inside a block, and it's not accessible outside.

Wait, looking at the file structure, the init code is at the top level (not inside a block). So `let solvedGridPositions` should be a global variable.

Let me check the actual init code in the file.

I see the issue! On line 638, in `doReset`, I have `solvedGridPositions = buildSolvedCube();` but this is missing the `let` or `var` declaration. And on line 741, I have `let solvedGridPositions = buildSolvedCube();` in the init.

But the issue is that in `doReset`, I'm assigning to `solvedGridPositions` without declaring it. Since `solvedGridPositions` is declared with `let` on line 741 (which is after line 638), the assignment on line 638 might be creating a global variable (if not in strict mode) or throwing an error.

Wait, actually, the order is:
1. Line 638: `doReset` function definition (which references `solvedGridPositions`)
2. Line 741: `let solvedGridPositions = buildSolvedCube();` (init code)

When `doReset` is called (e.g., from reset button), it assigns to `solvedGridPositions`. But `solvedGridPositions` is declared with `let` later in the code. In JavaScript, `let` declarations are not hoisted like `var`, but they are in the "temporal dead zone" until the initialization. However, since `doReset` is a function that's only called later (after the init code has run), the `solvedGridPositions` should be available.

Actually, the issue is different. The `doReset` function assigns to `solvedGridPositions` without declaring it. If `solvedGridPositions` is declared with `let` in the same scope (top level), the assignment should work. But if `doReset` is in a different scope, it might create a new variable.

Wait, looking at the code structure, both `doReset` and the init code are at the top level. So `solvedGridPositions` declared with `let` on line 741 should be accessible in `doReset` on line 638.

But actually, line 638 is inside the `doReset` function, which is defined before line 741. When `doReset` is called (after the init code has run), `solvedGridPositions` should be available.

Hmm, let me check if there's a scoping issue. Actually, I think the issue is that `checkSolvedState` is being called during init, and at that point `solvedGridPositions` should be set. Let me verify by checking the console.

Actually, let me just check if there's an error by looking at the console output more carefully. The console shows "Rubik's Cube ready." which means the script ran without errors. But the verify element shows "✗ Scrambled".

Let me check the `checkSolvedState` function more carefully. The issue might be that the cubies are not in the correct positions.

Wait, I think I see the issue. In the `buildSolvedCube` function, I create cubies with `gridI`, `gridJ`, `gridK` set to the initial grid positions. But in `checkSolvedState`, I compare `c.gridI` with `solved.i`. The `solved` object comes from `solvedGridPositions[c.idx]`, which is the initial grid position.

So for a newly created cubie, `c.gridI === solved.i` should be true. And `c.quat` should be identity.

Let me check if the cubies are being created correctly. Actually, let me just add some debug logging.

Wait, I think I see the issue. In the `checkSolvedState` function, I'm iterating over `cubies` and checking `c.gridI !== solved.i`. But for the center cubie (which is skipped in `buildSolvedCube`), `solvedGridPositions[c.idx]` might be `null` (since I push `null` for the center position).

Actually, no. In my updated `buildSolvedCube`, I push `null` for the center position in `solvedPositions`. But the center cubie is not created (it's skipped). So `cubies` has 26 entries (indices 0-25), and `solvedGridPositions` has 27 entries (indices 0-26, with index 13 being `null` for the center).

Wait, let me trace through the logic:
- `idx` starts at 0.
- For each grid position (i, j, k), if it's not the center, we create a cubie with `idx` and push `{i, j, k}` to `solvedPositions`. Then `idx++`.
- If it's the center, we push `null` to `solvedPositions` and don't increment `idx`.

So for grid position (0, 0, 0): cubie created with idx=0, solvedPositions[0] = {0, 0, 0}, idx becomes 1.
For grid position (0, 0, 1): cubie created with idx=1, solvedPositions[1] = {0, 0, 1}, idx becomes 2.
...
For grid position (1, 1, 0): cubie created with idx=12, solvedPositions[12] = {1, 1, 0}, idx becomes 13.
For grid position (1, 1, 1): center, solvedPositions[13] = null, idx stays 13.
For grid position (1, 1, 2): cubie created with idx=13, solvedPositions[14] = {1, 1, 2}, idx becomes 14.

Wait, that's wrong! The cubie at grid position (1, 1, 2) has idx=13, but solvedPositions[13] is null (for the center). So `solvedGridPositions[c.idx]` for this cubie would be `solvedGridPositions[13]` which is `null`.

This is the bug! The `solvedPositions` array has a `null` entry at index 13 (for the center), but the cubie at grid position (1, 1, 2) also has idx=13. So when I look up `solvedGridPositions[13]`, I get `null` instead of `{1, 1, 2}`.

The fix is to not push `null` for the center position. Instead, I should only push entries for actual cubies.

Let me fix this.

Now let me reload and test.

Now it shows "✓ Solved" initially. Let me test the U then U' sequence.

U clicked, status is "Animating...". Let me wait for it to complete, then click U'.

Now let me click U'.

U' clicked. Let me wait for the animation to complete.

Let me check the state now.

After U then U', the status is "Ready" and the verify shows "✓ Solved". This confirms that U followed by U' returns the cube to the solved state.

Now let me test the orbit and reset functionality.

The drag didn't seem to do anything visible in the DOM (which is expected - orbit doesn't change the DOM). Let me now click Reset to verify it restores the initial camera position and solved state.

Reset clicked. Let me check the state after reset.

After Reset, the status is "Ready" and the verify shows "✓ Solved". This confirms that Reset restores the solved state.

Let me also test the Scramble functionality.

Scramble clicked. The status shows "Solved" (which is the initial state before scramble starts). Wait, it should show "Scrambling..." or similar. Let me check the scramble function.

Looking at my scramble function:
```javascript
function scramble() {
  if (isAnimating) return;
  const moves = [];
  // ... generate moves ...
  let idx = 0;
  function nextScrambleMove() {
    if (idx >= moves.length) {
      setStatus('Scrambled');
      return;
    }
    if (isAnimating) {
      setTimeout(nextScrambleMove, 50);
      return;
    }
    const m = moves[idx];
    setStatus(`Scramble: ${m}`);
    startAnimation(MOVE_DEFS[m]);
    idx++;
    if (idx < moves.length) {
      for (let j = idx; j < moves.length; j++) {
        animQueue.push(MOVE_DEFS[moves[j]]);
      }
      idx = moves.length;
    }
  }
  nextScrambleMove();
}
```

When scramble is clicked, it calls `nextScrambleMove()`, which calls `startAnimation` for the first move. This sets `isAnimating = true` and the status to `Scramble: U` (or whatever the first move is).

But the DOM shows "Solved" which is the status before the scramble starts. Wait, the DOM might be showing the state before the click was processed.

Let me wait a bit and check again.

Let me check the state now.