The user wants me to create an interactive 3D Rubik's Cube using three.js. Let me first check what three.min.js file is available in the current directory, then build the index.html file.

Let me check the directory structure first.

The user wants me to build an interactive 3D Rubik's Cube using three.min.js. Let me plan this out:

1. A 3x3x3 Rubik's cube with colored faces
2. Clickable face rotations (the user clicks on a face, and that face rotates)
3. Orbit-drag camera (OrbitControls)
4. A scramble button

Since three.min.js is already present, I need to use it. But OrbitControls isn't included in the basic three.min.js. Let me check what's available... Actually, three.min.js typically includes the core library. For OrbitControls, I'd normally need to add it separately, but the user said "load each with a plain <script src="NAME"></script> using its exact filename" and only three.min.js is present.

Wait, but OrbitControls is part of the examples/jsm folder in Three.js. If only three.min.js is available, I might need to implement orbit controls manually, or use a version of three.min.js that includes them.

Actually, let me check the three.min.js file - modern versions of three.min.js sometimes bundle addons. But typically they don't.

I could implement simple orbit controls manually using mouse events, or I could assume that OrbitControls might be available via a CDN... but the user said no external resources.

Let me implement my own simple orbit controls using mouse drag. That's a reasonable approach and keeps everything self-contained.

Actually, wait - let me check if there's an older version of three.min.js that might have different contents, or if OrbitControls is somehow included. Let me check the file size - 603KB is about right for a standard three.min.js build.

I'll implement:
1. Simple orbit controls (drag to rotate camera around the cube)
2. Raycasting for click detection on cube faces
3. Face rotation animation
4. Scramble functionality

Let me think about the Rubik's Cube implementation:

The cube has 6 faces, each with 9 stickers (3x3). Each sticker has a color. The cube is made up of 27 smaller cubies (3x3x3), but actually each cubie has multiple visible faces.

Actually, the standard approach is:
- Create 27 cubies (small cubes), each positioned at (x,y,z) where x,y,z ∈ {-1, 0, 1}
- Each cubie has 6 face materials (some may be invisible/internal)
- When rotating a face, we rotate the 9 cubies that make up that face

For face rotation:
- The user clicks on a face of the cube
- We determine which layer to rotate (outer layer or middle layer)
- We animate the rotation of those 9 cubies around the appropriate axis

Let me think about the interaction more carefully:

When the user clicks on the cube, we raycast to find which face they clicked on. Based on the face normal and the click position, we determine which layer (outer or middle) and which direction to rotate.

Actually, for simplicity and good UX, let me do this:
- Click on a face → determine the face (front, back, left, right, top, bottom)
- The outer layer of that face rotates 90 degrees in the direction that moves the face "toward" the viewer or away
- Or better: click on a face, and the rotation direction is determined by where on the face you click (like a drag direction)

Hmm, let me simplify: Click on a face, and it rotates 90 degrees. The user can click multiple times. For direction, I'll use a convention: clicking rotates the face clockwise when looking at it from the outside.

Let me design the cube:

Colors:
- Right: Red
- Left: Orange  
- Top: White
- Bottom: Yellow
- Front: Green
- Back: Blue

Standard Rubik's cube color scheme.

For the cubies, each small cube (size 1) is positioned at integer coordinates from -1 to 1. Each cubie has materials for its 6 faces. Internal faces (facing other cubies) are black or invisible.

Actually, a simpler approach that many Rubik's cube implementations use: Instead of 27 individual cubies with 6 materials each, we can use a single large cube with 9 stickers per face. But that's harder to animate for rotations.

The cubie approach is better for animation. Let me use 27 cubies.

Each cubie needs materials for the 6 directions. The materials that face outward (toward the surface of the big cube) get colored; internal ones are dark/black.

Let me code this up:

```javascript
// For each position (x, y, z) where x, y, z ∈ {-1, 0, 1}
// Create a BoxGeometry(0.95, 0.95, 0.95) - slightly smaller than 1 to show gaps
// For each of the 6 faces, assign a material:
//   - If the face points outward from the big cube, use the appropriate color
//   - Otherwise, use black
```

Wait, but if I use a single BoxGeometry with 6 materials, that's one mesh per cubie with 6 materials. That's actually clean.

Actually, THREE.BoxGeometry with 6 materials: the materials array is [right, left, top, bottom, front, back] in that order.

For a cubie at position (x, y, z):
- Right face (material index 0): colored if x === 1 (outermost right layer)
- Left face (material index 1): colored if x === -1
- Top face (material index 2): colored if y === 1
- Bottom face (material index 3): colored if y === -1
- Front face (material index 4): colored if z === 1
- Back face (material index 5): colored if z === -1

Colors:
- Right (x=1): Red
- Left (x=-1): Orange
- Top (y=1): White
- Bottom (y=-1): Yellow
- Front (z=1): Green
- Back (z=-1): Blue

For internal faces, use dark gray or black.

Now for the rotation mechanics:

When the user clicks on a face, I need to:
1. Identify which face they clicked on (which side of the big cube)
2. Identify which layer (outer or middle) - I'll just do outer for simplicity, or let them click on the outer ring
3. Rotate that layer 90 degrees

For click detection, I'll use raycasting. When the user clicks, I cast a ray and find intersections with the cubies. The face normal of the intersection tells me which direction, and the position tells me which layer.

Actually, a cleaner approach: 

For each of the 6 faces of the big cube, I define a "rotation group" - the 9 cubies that make up that face's outer layer.

Face rotation groups:
- Right face (x=1): cubies with x=1, all y,z ∈ {-1,0,1}
- Left face (x=-1): cubies with x=-1
- Top face (y=1): cubies with y=1
- Bottom face (y=-1): cubies with y=-1
- Front face (z=1): cubies with z=1
- Back face (z=-1): cubies with z=-1

When rotating the right face clockwise (looking from the right):
- The 9 cubies at x=1 rotate around the X axis
- Actually, they rotate around the X axis at the center of the cube

Wait, the rotation axis for the right face is the X axis. The cubies at x=1 rotate around the X axis (which goes through the center of the cube). But they're already at x=1, so rotating around X doesn't move them in X... Actually, rotating around the X axis means their Y and Z coordinates change, which is correct for a face rotation.

Hmm wait, that's not right. When you rotate the right face of a Rubik's cube, the cubies on that face move in a circle in the YZ plane. So they rotate around the X axis. Yes, that's correct.

But the center cubie (at x=1, y=0, z=0) - it rotates around the X axis but stays at x=1, y=0, z=0... Actually, rotating a point (1, 0, 0) around the X axis by any angle leaves it at (1, 0, 0). So the center cubie of the face stays in place. That's correct! The center piece of each face doesn't move (it rotates in place but its position doesn't change).

Wait, actually the center piece DOES rotate (its orientation changes), but its position stays the same. In a real Rubik's cube, the center pieces are fixed to the core. So when we rotate a face, the center cubie should rotate in place (change its orientation/rotation) but not change position.

For the other 8 cubies on the face, they change position (cycle around) AND rotate.

This is getting complex. Let me think about how to implement this.

For each face rotation:
1. Identify the 9 cubies in that layer
2. Animate them rotating 90 degrees around the appropriate axis
3. After the animation, update their positions and rotations to the new state

For the animation, I can use a group: put the 9 cubies in a THREE.Group, rotate the group, and after the animation completes, "apply" the rotation to each cubie (update their individual positions and rotations relative to the world).

Actually, a simpler approach: use a parent group for each layer. But that gets complicated with multiple simultaneous rotations.

Let me use a different approach: animate each cubie's position and rotation individually using a target state, and interpolate.

Actually, let me use the group approach but be careful:

For each face rotation:
1. Create a temporary group
2. Add the 9 cubies to the group (removing them from their current parent)
3. Position the group at the center of rotation
4. Animate the group's rotation
5. After animation, remove cubies from group, re-parent to scene, and set their final position/rotation

Wait, there's a subtlety. When cubies are in a group and the group rotates, the cubies' world positions change. After the rotation, I need to compute each cubie's new position and rotation in world space, then set them as the cubie's position/rotation (with cubie as a direct child of scene).

Let me think step by step:

Cubie at world position P, with quaternion Q (relative to world).

When I put it in a group at position G, the cubie's local position in the group is P - G. The group has rotation R (initially identity).

After rotating the group by R_final:
- Cubie's new world position = G + R_final * (P - G)
- Cubie's new world quaternion = R_final * Q

Then I set the cubie's position to the new world position and quaternion to the new world quaternion (as direct child of scene).

This should work!

Let me code this up.

Actually, for the Rubik's cube, there's an additional subtlety: the center cubie of each face. Its position doesn't change (it's on the axis of rotation), but its orientation does change. In my group-based approach, the center cubie would be at position G (the center of rotation), so P - G = 0, and the new position = G + R_final * 0 = G. So its position stays the same. Its quaternion becomes R_final * Q. Good.

But wait, for the Rubik's cube, the center pieces are typically considered fixed (they don't rotate relative to the core). In a real Rubik's cube, the center pieces are attached to the core mechanism and don't move. However, the stickers on the center pieces are fixed relative to the center piece... actually, in a real Rubik's cube, the center pieces DO rotate (the stickers are fixed to the center piece, and the center piece rotates with the face).

Hmm, actually in a real Rubik's cube, when you rotate a face, the center piece of that face rotates with the face. The center piece's position is fixed (it's on the axis), but it spins. So my approach is correct.

But wait, there's a well-known issue: in a Rubik's cube, the center pieces' orientation matters for some puzzles (like supercubes), but for a standard Rubik's cube, the center piece orientation is not visible (the sticker is a solid color, so rotation doesn't matter visually).

For our implementation, since the center piece has a solid color sticker, its rotation doesn't matter visually. But for correctness, we should still rotate it.

OK let me just code this up.

Let me also think about the click interaction:

When the user clicks, I raycast against all cubies. If I hit a cubie, I get the face normal. Based on the face normal and the hit position, I determine which face of the big cube was clicked and which layer.

Actually, the face normal alone tells me which side of the big cube. For example, if the normal is (1, 0, 0), the user clicked on the right face. If the normal is (0, 1, 0), the top face, etc.

But I also need to know which layer (outer or middle). If the user clicks on a cubie at x=1, that's the outer layer of the right face. If they click on a cubie at x=0 with normal (1, 0, 0), that's the middle layer of the right face.

Wait, the middle layer doesn't have outward-facing stickers on the right side. The cubie at (0, y, z) with normal (1, 0, 0) would be hitting an internal face (the right face of that cubie, which faces the cubie at (1, y, z)). But I set internal faces to black/dark, so clicking on them would still work for raycasting.

Hmm, for simplicity, let me only allow rotation of outer layers. The user clicks on the colored stickers (outer faces), and the corresponding outer layer rotates.

Actually, for a better UX, let me also allow middle layer rotations. But that adds complexity. Let me start with outer layers only.

For determining the rotation direction: when the user clicks on a face, the face rotates 90 degrees clockwise when looking at it from the outside. I can determine the rotation direction based on the face normal.

For the right face (normal = (1, 0, 0)):
- Clockwise rotation when looking from the right means rotating around the X axis
- But which direction? Looking from positive X toward the origin, clockwise means... let me think.
- Looking from the right (positive X direction) toward the cube, the YZ plane is seen with Y up and Z going right (or left, depending on convention).
- A clockwise rotation in this view means: top goes to front, front goes to bottom, bottom goes to back, back goes to top.
- In terms of rotation around X axis: this is a rotation of -90 degrees (or 270 degrees) around X... hmm, I need to be careful.

Let me use a consistent convention: for each face, the rotation is 90 degrees around the axis perpendicular to the face, in the direction that moves the face "clockwise" when viewed from outside.

Face normals and rotation axes:
- Right (1,0,0): rotate around X axis, direction = -90° (clockwise from right)
- Left (-1,0,0): rotate around X axis, direction = +90° (clockwise from left)
- Top (0,1,0): rotate around Y axis, direction = -90° (clockwise from top)
- Bottom (0,-1,0): rotate around Y axis, direction = +90° (clockwise from bottom)
- Front (0,0,1): rotate around Z axis, direction = -90° (clockwise from front)
- Back (0,0,-1): rotate around Z axis, direction = +90° (clockwise from back)

Wait, I need to verify. Let me think about the front face (z=1, normal = (0,0,1)):
- Looking from the front (positive Z) toward the cube, X goes right, Y goes up
- Clockwise: top goes to right, right goes to bottom, bottom goes to left, left goes to top
- This is a rotation of -90° around the Z axis (or equivalently, +270°)

Actually, in Three.js, a positive rotation around an axis follows the right-hand rule. So a positive rotation around Z rotates from X toward Y (counterclockwise when looking from positive Z).

For the front face, clockwise when looking from positive Z means rotating from Y toward X (top goes to right), which is a negative rotation around Z. So -90° around Z. That matches what I said.

For the right face, clockwise when looking from positive X: looking from the right, Y is up, Z goes to the left (since we're looking from +X toward -X, the Z axis appears to go left). Actually, let me think more carefully.

When looking from positive X toward the origin:
- The Y axis goes up
- The Z axis goes... hmm, this depends on the coordinate system.

In Three.js, the default coordinate system is right-handed: X right, Y up, Z comes toward the viewer (out of screen). So looking from positive X toward the origin, Y is up, and Z goes to the left (since Z points toward the viewer from the origin, and we're looking from the right side).

So looking from the right, the view is: Y up, Z left, X into the screen.

Clockwise in this view: Y → -Z → -Y → Z → Y (top goes to left/back, left goes to bottom, etc.)

Hmm, this is getting confusing. Let me just define the rotations explicitly and test.

Actually, let me use a simpler approach. For each face, I'll define:
- The axis of rotation (one of the three principal axes)
- The angle (always 90°, but direction depends on the face)

And I'll use the convention that "clockwise when looking from outside" means:

For a face with normal n (pointing outward):
- The rotation axis is n
- The rotation angle is -90° (using Three.js convention where positive is counterclockwise when looking along the axis direction)

Wait, Three.js uses the right-hand rule: positive rotation around an axis is counterclockwise when looking from the positive direction of that axis toward the origin.

So if I want clockwise rotation when looking from outside (from the positive direction of the normal toward the cube), I should use a negative angle.

For the right face (normal = (1,0,0), looking from +X):
- Clockwise = negative rotation around X = -90°

For the left face (normal = (-1,0,0), looking from -X):
- Looking from -X toward the origin, the right-hand rule says positive rotation around X is... hmm, the right-hand rule is defined relative to the axis direction, not the viewing direction.
- Actually, the rotation around X axis by angle θ: the rotation matrix is the same regardless of which side you're looking from. The question is just what "clockwise" means from a particular viewpoint.

Let me think differently. For the left face, the user is looking from the left side (-X direction). They see the left face. "Clockwise" from their perspective means... 

You know what, let me just define it in terms of the effect on the cubies. When I rotate the right face (x=1 layer) by -90° around X:
- A cubie at (1, 1, 0) (top-right-front edge) moves to (1, 0, -1) (right-back-middle edge)
- Let me verify: rotating (1, 1, 0) around X by -90°: 
  - x stays 1
  - y' = y*cos(-90) - z*sin(-90) = 1*0 - 0*(-1) = 0
  - z' = y*sin(-90) + z*cos(-90) = 1*(-1) + 0*0 = -1
  - Result: (1, 0, -1) ✓

This seems right. The top-front cubie on the right face moves to the back.

OK, let me just go with this:
- Right face (normal +X): rotate -90° around X
- Left face (normal -X): rotate +90° around X
- Top face (normal +Y): rotate -90° around Y
- Bottom face (normal -Y): rotate +90° around Y
- Front face (normal +Z): rotate -90° around Z
- Back face (normal -Z): rotate +90° around Z

Wait, I need to double-check the left face. If the user clicks on the left face and we rotate +90° around X:
- A cubie at (-1, 1, 0) (top-left-front edge) 
- Rotating around X by +90°:
  - x stays -1
  - y' = 1*0 - 0*1 = 0
  - z' = 1*1 + 0*0 = 1
  - Result: (-1, 0, 1) (left-middle-front)

Hmm, from the left side view, the top should go to the front. Let me check: looking from -X, Y is up, Z goes to the right. Clockwise: Y → Z → -Y → -Z. So top (Y+) goes to front (Z+). Yes, (-1, 1, 0) → (-1, 0, 1). That's correct!

OK great, my convention works.

Now let me think about the implementation structure:

```javascript
// State
const cubies = []; // Array of mesh objects
const cubieData = []; // Position and rotation data for each cubie

// Build the cube
function buildCube() {
  const geometry = new THREE.BoxGeometry(0.94, 0.94, 0.94);
  const colors = {
    right: 0xff0000,
    left: 0xff8800,  // orange
    top: 0xffffff,
    bottom: 0xffff00,
    front: 0x00ff00,
    back: 0x0000ff
  };
  const dark = 0x222222;
  
  for (let x = -1; x <= 1; x++) {
    for (let y = -1; y <= 1; y++) {
      for (let z = -1; z <= 1; z++) {
        const materials = [
          x === 1 ? colors.right : dark,   // right
          x === -1 ? colors.left : dark,   // left
          y === 1 ? colors.top : dark,     // top
          y === -1 ? colors.bottom : dark, // bottom
          z === 1 ? colors.front : dark,   // front
          z === -1 ? colors.back : dark    // back
        ];
        const mesh = new THREE.Mesh(geometry, materials);
        mesh.position.set(x, y, z);
        scene.add(mesh);
        cubies.push(mesh);
        cubieData.push({ x, y, z });
      }
    }
  }
}
```

For the rotation:

```javascript
function rotateFace(normal, angle) {
  // Determine which axis
  let axis;
  if (normal.x !== 0) axis = 'x';
  else if (normal.y !== 0) axis = 'y';
  else axis = 'z';
  
  // Determine which layer
  const layerVal = normal.x !== 0 ? normal.x : (normal.y !== 0 ? normal.y : normal.z);
  // layerVal is 1 or -1
  
  // Find the 9 cubies in this layer
  const layerCubies = [];
  for (let i = 0; i < cubies.length; i++) {
    const pos = cubieData[i];
    if (axis === 'x' && pos.x === layerVal) layerCubies.push(i);
    else if (axis === 'y' && pos.y === layerVal) layerCubies.push(i);
    else if (axis === 'z' && pos.z === layerVal) layerCubies.push(i);
  }
  
  // Create a group for animation
  const group = new THREE.Group();
  scene.add(group);
  
  // Move cubies to group
  for (const idx of layerCubies) {
    const mesh = cubies[idx];
    group.add(mesh);
  }
  
  // Animate
  const startRot = group.rotation.x; // or appropriate axis
  // ... animate over time
  
  // After animation, apply final transforms
  for (const idx of layerCubies) {
    const mesh = cubies[idx];
    // Compute new world position and quaternion
    // ...
    group.remove(mesh);
    scene.add(mesh);
  }
  
  scene.remove(group);
}
```

Hmm, this approach has issues. When I add a mesh to a group, its position becomes relative to the group. But the mesh's position was in world space (since it was a child of scene). When I add it to the group, Three.js automatically adjusts the position to be relative to the group.

Actually, in Three.js, when you do `group.add(mesh)`, if the mesh was previously a child of scene (or another parent), Three.js handles the transform conversion. The mesh's world transform is preserved.

So if a cubie is at world position (1, 1, 0) and I add it to a group at position (0, 0, 0), the cubie's local position in the group becomes (1, 1, 0). When I rotate the group, the cubie's world position changes accordingly.

After the rotation, I need to:
1. Get the cubie's world position and quaternion
2. Remove it from the group
3. Add it to the scene
4. Set its position and quaternion to the world values

This should work. Let me code it up properly.

Actually, I realize there's a simpler way. Instead of using a group, I can just animate each cubie's position and rotation independently using a target state. But the group approach is cleaner for the animation.

Let me also think about the animation timing. I'll use a smooth animation over about 200-300ms. I can use requestAnimationFrame and lerp the rotation.

For the scramble function:
- Generate a sequence of random face rotations
- Execute them one by one with delays

Let me also think about the UI:
- A 3D viewport with the cube
- Click on a face to rotate it
- A "Scramble" button
- Maybe a "Solve" button (but that's very complex, skip it)
- Display the number of moves or scramble status

Let me now write the complete code.

I also need to think about the orbit controls. Since I can't use OrbitControls from the CDN, I'll implement a simple version:

```javascript
let isDragging = false;
let previousMousePosition = { x: 0, y: 0 };
let cameraAngle = 0;
let cameraElevation = Math.PI / 4;
let cameraDistance = 5;

renderer.domElement.addEventListener('mousedown', (e) => {
  isDragging = true;
  previousMousePosition = { x: e.clientX, y: e.clientY };
});

renderer.domElement.addEventListener('mousemove', (e) => {
  if (!isDragging) return;
  const deltaX = e.clientX - previousMousePosition.x;
  const deltaY = e.clientY - previousMousePosition.y;
  cameraAngle -= deltaX * 0.01;
  cameraElevation -= deltaY * 0.01;
  cameraElevation = Math.max(-Math.PI/2 + 0.1, Math.min(Math.PI/2 - 0.1, cameraElevation));
  previousMousePosition = { x: e.clientX, y: e.clientY };
  updateCamera();
});

renderer.domElement.addEventListener('mouseup', () => {
  isDragging = false;
});

function updateCamera() {
  camera.position.x = cameraDistance * Math.sin(cameraAngle) * Math.cos(cameraElevation);
  camera.position.y = cameraDistance * Math.sin(cameraElevation);
  camera.position.z = cameraDistance * Math.cos(cameraAngle) * Math.cos(cameraElevation);
  camera.lookAt(0, 0, 0);
}
```

This gives a basic orbit control. I can also add touch support for mobile.

Now, one issue: when the user clicks on the cube to rotate a face, I need to distinguish between a click (for rotating) and a drag (for orbiting). I can do this by checking if the mouse moved significantly between mousedown and mouseup.

Let me also add a hover effect to show which face will be rotated.

OK, let me write the full code now.

Actually, let me also think about the raycasting for face selection. When the user clicks, I cast a ray and check intersections with the cubies. The intersection gives me:
- The face index (which of the 6 faces of the cubie was hit)
- The point of intersection
- The face normal

The face index of the cubie tells me which direction the face is facing. For a BoxGeometry, the face indices are:
- 0: right (+x)
- 1: left (-x)
- 2: top (+y)
- 3: bottom (-y)
- 4: front (+z)
- 5: back (-z)

Wait, I need to verify this. BoxGeometry face order in Three.js... Let me check.

In Three.js, BoxGeometry creates groups for each face. The material index corresponds to:
- 0: +x (right)
- 1: -x (left)
- 2: +y (top)
- 3: -y (bottom)
- 4: +z (front)
- 5: -z (back)

When raycasting, the intersection object has a `face` property which has an `materialIndex` that corresponds to the material index.

So if the user clicks on a cubie and the materialIndex is 0, they clicked on the right face of that cubie.

But I need to determine which face of the BIG cube they clicked on. If they clicked on the right face of a cubie at position (1, y, z), that's the right face of the big cube. If they clicked on the right face of a cubie at position (0, y, z), that's an internal face (the right face of the middle cubie, which faces the right layer cubie).

For determining the big cube face, I can use the face normal. The face normal of the cubie's right face is (1, 0, 0). If the cubie is at x=1, this is the outer right face of the big cube. If the cubie is at x=0, this is an internal face.

For the rotation, I'll only allow clicking on outer faces (where the cubie is on the surface of the big cube). So if the user clicks on a cubie at x=1 with face normal (1, 0, 0), that's the right face of the big cube, and the right layer (x=1) rotates.

But wait, what if the user clicks on a cubie at x=1 with face normal (0, 1, 0) (the top face of a cubie on the right layer)? That's the top face of the big cube (since y=1 for that cubie). So the top layer (y=1) would rotate.

Hmm, this gets complex. Let me simplify: the user clicks on a face of the big cube. I determine which face based on the face normal AND the cubie's position. The face of the big cube is the one whose outward normal matches the face normal of the clicked cubie face, AND the cubie is on the corresponding layer.

Actually, a simpler approach: the face of the big cube is determined by the face normal of the clicked cubie face. If the normal is (1, 0, 0), it's the right face. If the normal is (0, 1, 0), it's the top face. Etc.

But this doesn't account for the layer. If the user clicks on the right face of a cubie at (0, 1, 0) (the top-middle cubie), the normal is (1, 0, 0) but the cubie is at x=0, not x=1. This is an internal face, not the outer right face.

For my implementation, I'll only allow rotation when the user clicks on an outer face (where the cubie is on the surface). So I check: if the face normal is (1, 0, 0) and the cubie's x position is 1, then it's the outer right face and the right layer rotates.

If the face normal is (1, 0, 0) but the cubie's x position is 0, it's an internal face and I ignore the click (or do nothing).

Wait, but what about clicking on the top face of a cubie at (1, 1, 0)? The normal is (0, 1, 0) and the cubie's y position is 1. This is the outer top face. But this cubie is also on the right layer (x=1). Which layer should rotate?

The answer is: the top layer should rotate, because the user clicked on the top face. The face normal determines which face of the big cube was clicked.

But there's an ambiguity: the cubie at (1, 1, 0) has both a right face (normal (1,0,0)) and a top face (normal (0,1,0)). If the user clicks on the top face of this cubie, the top layer rotates. If they click on the right face of the same cubie, the right layer rotates.

This is correct behavior! The user clicks on a specific face, and that face's layer rotates.

OK, so my approach is:
1. Raycast on click
2. Get the intersection face normal (from the material index)
3. Check if the cubie is on the surface (i.e., the face is an outer face)
4. If yes, determine which layer to rotate based on the face normal
5. Rotate that layer

For step 3, a face is an outer face if the cubie's position on the axis perpendicular to the face is at the extreme (-1 or 1). For example, if the face normal is (1, 0, 0), the cubie must be at x=1 for it to be an outer face.

Let me code this up now.

One more thing: I should also handle the case where the user clicks on an edge or corner. In that case, the raycast might hit multiple cubies. I'll just use the closest intersection.

Also, I should add a visual indicator (hover effect) to show which face the user is about to click. I can highlight the cubies on the layer that would be rotated.

Let me now write the complete HTML file.

Actually, let me think about one more thing: the rotation animation. I need to animate the rotation smoothly. Here's my plan:

1. When a face rotation is triggered, create a group and add the 9 cubies to it
2. Set the group's rotation to the target rotation (e.g., -90° around X)
3. Animate from 0 to the target rotation over ~250ms
4. After the animation, "bake" the transforms and remove the cubies from the group

For the baking:
- For each cubie in the group, compute its world position and quaternion after the animation
- Remove the cubie from the group
- Add it to the scene
- Set its position and quaternion to the computed values

Wait, there's a complication. After the group rotation, the cubie's world quaternion includes the group's rotation. But the cubie might have had its own rotation before (from previous face rotations). When I bake, I need to preserve the cubie's orientation relative to the world.

Actually, in my implementation, I'm not tracking individual cubie rotations. Each cubie is just a mesh with a position. The materials are fixed to the mesh's local faces. When I move a cubie, its materials move with it.

But wait, when I rotate a cubie around an axis, its orientation changes. The materials (colors) are attached to the cubie's local faces. So if I rotate a cubie, the colors rotate with it. This is correct for a Rubik's cube - the stickers are fixed to the cubies.

But there's a subtlety: when I put a cubie in a group and rotate the group, the cubie's world orientation changes. After baking, I set the cubie's quaternion to the world quaternion. This means the cubie's local orientation is now the same as its world orientation (since it's a child of scene). The materials are still attached to the local faces, so they rotate correctly.

This should work fine.

Let me also think about the center cubie of each face. When I rotate a face, the center cubie (e.g., at (1, 0, 0) for the right face) should rotate in place. In my group approach, the center cubie is at the group's position (or very close to it), so its position doesn't change much. Its orientation changes by the group's rotation. This is correct.

Actually, wait. The group is at the origin (0, 0, 0), and the center cubie is at (1, 0, 0). When I rotate the group around the X axis, the center cubie's position changes... no, rotating (1, 0, 0) around X leaves it at (1, 0, 0). So the center cubie's position doesn't change. Its orientation changes by the group's rotation around X. This is correct.

OK, I'm confident the approach works. Let me write the code.

Let me also think about the scramble function. I'll generate a sequence of random face rotations (maybe 10-20 moves) and execute them one by one with delays.

For the scramble, I need to:
1. Pick a random face (one of 6)
2. Pick a random direction (clockwise or counterclockwise, i.e., +90° or -90°)
3. Execute the rotation
4. Wait for the animation to complete
5. Repeat

I'll use async/await with a promise-based delay.

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

Here's my plan for the HTML structure:

```html
<!DOCTYPE html>
<html>
<head>
  <title>3D Rubik's Cube</title>
  <style>
    /* Full page 3D viewport */
    /* UI overlay with scramble button and info */

  </style>
</head>
<body>
  <div id="container">
    <canvas id="canvas"></canvas>
    <div id="ui">
      <button id="scramble">Scramble</button>
      <div id="info">Click a face to rotate it</div>
    </div>
  </div>
  <script src="three.min.js"></script>
  <script>
    // All the Three.js code
  </script>
</body>
</html>
```

Let me write the complete implementation now. I need to be careful with the Three.js API.

Let me also add a nice visual touch: when hovering over a face, highlight the cubies that would be rotated. This makes the interaction more intuitive.

For the hover effect, I'll use raycasting on mousemove. When the mouse is over a clickable face, I highlight the 9 cubies in that layer by changing their emissive color or adding a highlight.

Actually, I can use a simple approach: when hovering, change the material's emissive color for the cubies in the layer. Or I can add a wireframe overlay. Let me keep it simple and just change the emissive color.

Wait, each cubie has 6 materials. I'd need to change the emissive color of all materials of the cubies in the layer. That's doable.

Let me think about the UX more:
1. When the user hovers over a face, the 9 cubies in that layer get highlighted
2. When the user clicks, the layer rotates
3. After the rotation, the highlight is removed
4. The user can click on any face at any time (as long as no rotation is in progress)

For the scramble:
1. Click the scramble button
2. The cube scrambles with random rotations
3. After scrambling, the user can interact with the cube again

Let me also add a rotation lock: while a rotation is animating, ignore clicks and hovers.

OK, I think I have a good plan. Let me write the code.

One more consideration: I want the cube to look nice. I'll add:
- A subtle gap between cubies (using 0.94 size instead of 1.0)
- Good lighting (ambient + directional)
- A nice background
- Shadows (maybe, if performance allows)

Let me also think about the camera position. The default view should show the cube at a nice angle, like 45° from above and 45° from the side.

Alright, let me write the complete code now.

Let me also handle the edge case where the user clicks during a rotation animation. I'll use a flag `isRotating` to prevent this.

For the animation, I'll use a simple approach:
- Store the rotation start time
- In the animation loop, compute the progress (0 to 1)
- Set the group's rotation based on the progress
- When progress reaches 1, finalize the rotation

I'll use an easing function for smooth animation (e.g., ease-in-out).

Let me code this up now. I'll write the complete HTML file.

Actually, I realize I should think about one more thing: how to handle the "middle layer" rotations. In a real Rubik's cube, you can rotate the middle layer (between two outer layers). For example, you can rotate the layer between the left and right faces (the x=0 layer) by using a combination of outer face rotations and cube rotations.

For simplicity, I'll only support outer layer rotations. The user clicks on an outer face, and that outer layer rotates. This is sufficient for scrambling and solving (since any middle layer rotation can be expressed as a combination of outer rotations and cube rotations).

OK, let me write the code now. I'll be comprehensive but keep it clean.

Let me think about one more detail: when I rotate a face, I need to determine the rotation axis and direction.

For the right face (clicked on the +x face):
- Axis: X
- Direction: -90° (clockwise when looking from +x)

For the left face (clicked on the -x face):
- Axis: X
- Direction: +90° (clockwise when looking from -x)

For the top face (clicked on the +y face):
- Axis: Y
- Direction: -90° (clockwise when looking from +y)

For the bottom face (clicked on the -y face):
- Axis: Y
- Direction: +90° (clockwise when looking from -y)

For the front face (clicked on the +z face):
- Axis: Z
- Direction: -90° (clockwise when looking from +z)

For the back face (clicked on the -z face):
- Axis: Z
- Direction: +90° (clockwise when looking from -z)

Wait, I need to double-check these directions. Let me think about the front face:
- Looking from +z toward the origin, x goes right, y goes up
- Clockwise: y → x → -y → -x (top goes to right)
- In Three.js, rotation around z by angle θ: x' = x*cos(θ) - y*sin(θ), y' = x*sin(θ) + y*cos(θ)
- For θ = -90°: x' = x*0 - y*(-1) = y, y' = x*(-1) + y*0 = -x
- So a point at (0, 1, z) (top) goes to (1, 0, z) (right). That's correct! Top goes to right.
- A point at (1, 0, z) (right) goes to (0, -1, z) (bottom). Right goes to bottom. Correct!

Great, so -90° around Z for the front face is correct.

For the right face:
- Looking from +x toward the origin, y goes up, z goes... let me think. In Three.js, when looking from +x, the y axis is up, and the z axis goes to the left (since z points toward the viewer from the origin, and we're looking from the right side).
- Wait, actually, in a right-handed coordinate system, if x is right, y is up, then z is toward the viewer (out of screen). So looking from +x toward -x, we see the yz plane with y up and z going to the left.
- Clockwise in this view: y → -z → -y → z (top goes to back, back goes to bottom, bottom goes to front, front goes to top)
- Rotation around x by -90°: y' = y*cos(-90) - z*sin(-90) = 0 - z*(-1) = z, z' = y*sin(-90) + z*cos(-90) = y*(-1) + 0 = -y
- So (x, 1, 0) (top) goes to (x, 0, -1) (back). Top goes to back.
- (x, 0, -1) (back) goes to (x, -1, 0) (bottom). Back goes to bottom.
- (x, -1, 0) (bottom) goes to (x, 0, 1) (front). Bottom goes to front.
- (x, 0, 1) (front) goes to (x, 1, 0) (top). Front goes to top.

So clockwise from the right: top → back → bottom → front → top. That matches! Great.

Now let me verify the left face:
- Looking from -x toward +x, y is up, z goes to the right (since we're looking from the left side, the z axis appears to go right).
- Clockwise: y → z → -y → -z (top goes to front)
- Rotation around x by +90°: y' = y*cos(90) - z*sin(90) = 0 - z*1 = -z, z' = y*sin(90) + z*cos(90) = y*1 + 0 = y
- So (x, 1, 0) (top) goes to (x, 0, 1) (front). Top goes to front. Correct!
- (x, 0, 1) (front) goes to (x, -1, 0) (bottom). Front goes to bottom. Correct!

Great, my convention is correct.

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

Actually, let me reconsider the approach for determining which face the user clicked on. Instead of using the face normal from the raycast intersection, I can use a simpler approach:

When the user clicks, I get the intersection point. I then determine which face of the big cube is closest to the intersection point. The face is determined by which coordinate (x, y, or z) is at its extreme value (±1) and the sign of the normal.

Actually, the raycast intersection gives me the face normal directly (from the face's material index). Let me use that.

Here's the approach:
1. Raycast on click
2. Get the intersection
3. Get the face normal from the intersection (using the face's material index)
4. Map the material index to a direction:
   - 0: +x (right)
   - 1: -x (left)
   - 2: +y (top)
   - 3: -y (bottom)
   - 4: +z (front)
   - 5: -z (back)
5. Check if the cubie is on the surface (the coordinate corresponding to the direction is ±1)
6. If yes, determine the layer and rotate

For step 5, if the direction is +x, the cubie must be at x=1. If the direction is -x, the cubie must be at x=-1. Etc.

If the cubie is not on the surface (e.g., clicking on the right face of a cubie at x=0), I ignore the click.

Actually, there's another case: what if the user clicks on the top face of a cubie at (1, 1, 0)? The direction is +y, and the cubie is at y=1. This is the top face of the big cube. The top layer (y=1) rotates. But this cubie is also on the right layer (x=1). The rotation should be for the top layer, not the right layer.

This is handled correctly by my approach: the direction from the face normal determines which layer rotates.

OK, I'm confident now. Let me write the code.

For the highlight effect, I'll do this:
- On mousemove, raycast to check if the mouse is over a clickable face
- If yes, highlight the 9 cubies in that layer by setting their material's emissive color
- If no, clear the highlight

I'll store the original materials and restore them when the highlight is cleared.

Actually, for simplicity, I'll just add a separate highlight mesh (like a transparent overlay) or change the emissive color of the cubies' materials.

Let me use the emissive color approach. Each cubie's materials have an emissive color that I can set to a bright color when highlighted, and clear when not.

Wait, I need to be careful. Each cubie has 6 materials. When highlighting, I want to highlight all 6 faces of the cubies in the layer. So I set the emissive color of all 6 materials of each cubie in the layer.

But the materials are shared across cubies. For example, all cubies on the right face share the same red material for their right face. If I change the emissive color of that material, it affects all cubies that use it.

To avoid this, I should use unique materials for each cubie. That means 27 cubies × 6 materials = 162 materials. That's a lot, but it's manageable.

Alternatively, I can clone the materials for each cubie. Or I can use a different highlighting approach, like adding a transparent overlay mesh.

Let me use unique materials for each cubie. I'll create the materials per cubie, not shared.

Actually, for performance and simplicity, let me use a different approach for highlighting: I'll add a glowing outline or edge highlight to the cubies in the layer. Or I can use a simple approach: change the cubies' scale or add a wireframe.

The simplest approach: when highlighting, I'll set the cubies' material's emissive to a bright color. Since I'm using unique materials per cubie, this won't affect other cubies.

Let me use unique materials. For each cubie, I create 6 materials (one for each face). The colored faces get the appropriate color, and the internal faces get dark.

Here's the material creation:

```javascript
const colorMap = {
  right: 0xe02020,  // red
  left: 0xf08020,   // orange
  top: 0xf0f0f0,    // white
  bottom: 0xf0f040, // yellow
  front: 0x20c020,  // green
  back: 0x2040f0    // blue
};

function createCubieMaterials(x, y, z) {
  const dark = 0x1a1a1a;
  return [
    new THREE.MeshStandardMaterial({ color: x === 1 ? colorMap.right : dark }),
    new THREE.MeshStandardMaterial({ color: x === -1 ? colorMap.left : dark }),
    new THREE.MeshStandardMaterial({ color: y === 1 ? colorMap.top : dark }),
    new THREE.MeshStandardMaterial({ color: y === -1 ? colorMap.bottom : dark }),
    new THREE.MeshStandardMaterial({ color: z === 1 ? colorMap.front : dark }),
    new THREE.MeshStandardMaterial({ color: z === -1 ? colorMap.back : dark })
  ];
}
```

This creates unique materials for each cubie. 27 × 6 = 162 materials. That's fine for performance.

Now for highlighting, I can set the emissive color of all 6 materials of the cubies in the layer:

```javascript
function highlightLayer(normal) {
  // Determine the layer
  const axis = normal.x !== 0 ? 'x' : (normal.y !== 0 ? 'y' : 'z');
  const val = normal.x !== 0 ? normal.x : (normal.y !== 0 ? normal.y : normal.z);
  
  for (const mesh of cubies) {
    const pos = cubiePositions[mesh];
    if (axis === 'x' && pos.x === val) {
      for (const mat of mesh.material) {
        mat.emissive.setHex(0x444444);
        mat.emissiveIntensity = 0.5;
      }
    } else if (axis === 'y' && pos.y === val) {
      // ...
    } else if (axis === 'z' && pos.z === val) {
      // ...
    }
  }
}
```

And to clear the highlight:
```javascript
function clearHighlight() {
  for (const mesh of cubies) {
    for (const mat of mesh.material) {
      mat.emissive.setHex(0x000000);
      mat.emissiveIntensity = 0;
    }
  }
}
```

This should work. Let me now write the complete code.

For the animation, I'll use this approach:
- Store the animation state (group, start time, duration, target rotation)
- In the animation loop, update the group's rotation based on the elapsed time
- When the animation is complete, bake the transforms and clean up

Let me use a promise-based approach for the animation, so I can await it in the scramble function.

```javascript
function rotateLayer(normal, angle) {
  return new Promise((resolve) => {
    // ... set up the group and animation
    // ... animate
    // ... resolve when done
  });
}
```

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

One more thing: I should make the UI look nice. I'll use a clean, modern design with a semi-transparent overlay for the controls.

Let me also add a "moves" counter or a status display.

Alright, let me write the complete HTML file now.

Let me think about the structure once more:

```
Scene setup:
- Renderer with antialiasing
- Scene with background color
- Camera (PerspectiveCamera)
- Lights ( AmbientLight + DirectionalLight )
- Rubik's cube (27 cubies)

Interaction:
- Orbit controls (mouse drag)
- Face click (raycasting)
- Hover highlight

UI:
- Scramble button
- Status text
- Maybe a reset button

Animation:
- Smooth rotation animation
- Scramble sequence
```

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

Actually, I want to also think about the visual quality. Let me add:
- Rounded edges on the cubies (using a RoundedBoxGeometry or beveled geometry)
- A subtle floor or environment
- Nice shadows

But RoundedBoxGeometry is not in the core three.min.js. I'd need to load it separately. Since I can only use three.min.js, I'll stick with BoxGeometry.

For a nicer look, I can use a slightly smaller cube size (0.94 instead of 1.0) to create gaps between cubies, and use MeshStandardMaterial with some roughness and metalness.

Let me also add a subtle environment map for reflections... but that requires loading an HDR file, which I can't do without network access. I'll skip it.

OK, let me just write the code. Here goes:

Let me think about one more thing: the rotation should be "quantized" - after the animation, the cubies should snap to the exact grid positions. During the animation, they smoothly interpolate. After the animation, they're at exactly the right positions.

In my group-based approach, the group rotates by exactly 90° (or -90°), so the cubies end up at exact positions. When I bake the transforms, I use the group's final rotation, which is exactly 90°. So the cubies will be at exact grid positions.

But wait, due to floating-point precision, the positions might not be exactly at integer values. I should snap them to the nearest integer values after baking.

Actually, for a 90° rotation around a principal axis, the positions should be exact (no floating-point issues for simple rotations). Let me not worry about snapping for now.

OK, let me write the code now. For real this time.

Let me think about one final thing: how to handle the case where the user clicks on a face that's already rotating. I'll use a flag `isAnimating` to prevent this. When `isAnimating` is true, clicks are ignored.

Also, for the scramble, I'll execute rotations sequentially, waiting for each to complete before starting the next.

Alright, here's my complete implementation plan. Let me write it.

I should also think about what happens with the "middle" pieces during rotation. The cubies at the edges and corners of a face layer change position, but the center cubie stays in place (only its orientation changes).

For the center cubie, its position is on the rotation axis, so it doesn't move. But its orientation changes. In my group approach, the center cubie is at position (1, 0, 0) for the right face, and the group rotates around the X axis. The cubie's position relative to the group is (1, 0, 0), and rotating around X by 90° leaves it at (1, 0, 0). So its position doesn't change. Its orientation changes by the group's rotation.

When I bake the transforms, I set the cubie's quaternion to the world quaternion. For the center cubie, this means its orientation changes by 90° around X. This is correct.

But wait, there's a subtlety. The center cubie's materials are fixed to its local faces. When I rotate the cubie, the materials rotate with it. So the red sticker on the right face of the center cubie stays on the right face (since the cubie rotated around X, and the right face is perpendicular to X). Actually, no - the right face of the cubie is in the YZ plane, and rotating around X rotates the YZ plane. So the red sticker rotates within the YZ plane.

Wait, I'm confusing myself. Let me think again.

The center cubie at (1, 0, 0) has:
- Right face (material index 0): red, facing +x
- Left face (material index 1): dark, facing -x
- Top face (material index 2): white, facing +y
- Bottom face (material index 3): yellow, facing -y
- Front face (material index 4): green, facing +z
- Back face (material index 5): blue, facing -z

When I rotate this cubie around the X axis by 90°:
- The right face still faces +x (it's on the axis)
- The left face still faces -x
- The top face (originally facing +y) now faces +z
- The bottom face (originally facing -y) now faces -z
- The front face (originally facing +z) now faces -y
- The back face (originally facing -z) now faces +y

So the white sticker (top) moves to the front, the green sticker (front) moves to the bottom, etc.

Wait, that doesn't seem right. In a real Rubik's cube, when you rotate the right face, the center piece of the right face rotates, but its stickers stay in the same relative positions. The red sticker is always on the right face of the center cubie.

Hmm, but the center cubie's orientation changes. The stickers are fixed to the cubie, so they rotate with the cubie. In a real Rubik's cube, the center piece has a fixed orientation relative to the core (it's attached to the core). When you rotate a face, the center piece rotates with the face.

Actually, in a real Rubik's cube, the center pieces are attached to the core mechanism. When you rotate a face, the center piece of that face rotates with the face (it spins). The stickers on the center piece are fixed to the center piece, so they rotate with it.

But in a standard Rubik's cube, the center stickers are solid colors, so the rotation of the center piece is not visible. In a "supercube" (where center pieces have oriented stickers), the rotation matters.

For our implementation, since we're using solid colors, the rotation of the center piece is not visible. But for correctness, we should still rotate it.

In my implementation, the center cubie's orientation changes when I rotate the face. The materials rotate with the cubie. Since the materials are solid colors, the rotation is not visible. But the cubie's quaternion is updated correctly.

Wait, but there's a visual issue. If I look at the center cubie from the front, I see the green sticker (front face). After rotating the right face by 90° around X, the center cubie's front face now shows... let me think.

The center cubie at (1, 0, 0) has its front face (material index 4, green) facing +z. After rotating around X by -90° (clockwise from right), the cubie's orientation changes. The front face now faces... 

In the cubie's local coordinate system, the front face always faces +z. But the cubie's local coordinate system is rotated relative to the world. After the rotation, the cubie's local +z axis points in a different world direction.

Let me compute: the cubie's original quaternion is identity (no rotation). After the group rotation of -90° around X, the cubie's world quaternion is a rotation of -90° around X.

The cubie's local +z axis, transformed by this quaternion, gives the world direction of the front face.

Rotation of (0, 0, 1) around X by -90°:
- x' = 0
- y' = 0*cos(-90) - 1*sin(-90) = 0 - 1*(-1) = 1
- z' = 0*sin(-90) + 1*cos(-90) = 0 + 1*0 = 0

So the front face now faces (0, 1, 0) in world space, which is the +y direction (up). So the green sticker is now on the top of the center cubie.

But in a real Rubik's cube, the center piece's stickers don't move relative to the face. The red sticker is always on the right face of the center piece.

Hmm, this is a discrepancy between my implementation and a real Rubik's cube. In a real Rubik's cube, the center piece is fixed to the core and doesn't rotate relative to the core. When you rotate a face, the center piece rotates with the face, but its position relative to the face is fixed.

Wait, I think I'm overcomplicating this. In a real Rubik's cube:
- The center piece of each face is attached to the core
- When you rotate a face, the center piece rotates with the face (it spins in place)
- The stickers on the center piece are fixed to the center piece
- So the stickers rotate with the center piece

In my implementation, the center cubie rotates with the face (it's in the group that rotates). The stickers (materials) are fixed to the cubie. So the stickers rotate with the cubie. This matches the real Rubik's cube behavior.

The visual effect is that the center piece's stickers appear to rotate. But since the stickers are solid colors, you can't tell that they've rotated (unless you look at the orientation of the sticker, which for a solid color square, you can't).

So my implementation is correct for a standard Rubik's cube. For a supercube, I'd need to add oriented stickers (like logos or arrows), but that's beyond the scope of this project.

OK, I'm confident now. Let me write the code.

Actually, wait. Let me reconsider. In a real Rubik's cube, the center pieces are attached to the core. When you rotate the right face, the right center piece rotates with the face. But the center piece's position is fixed (it's at the center of the right face). The center piece spins around the X axis (the axis perpendicular to the right face).

In my implementation, the center cubie at (1, 0, 0) is in the group that rotates around X. The cubie's position is (1, 0, 0), which is on the X axis. So when the group rotates around X, the cubie's position doesn't change. Its orientation changes by the group's rotation. This matches the real Rubik's cube behavior.

Great, my implementation is correct.

Now, one more thing: after the rotation, the center cubie's orientation is changed. If I later rotate a different face (e.g., the top face), the center cubie of the right face is not affected (it's not in the top layer). So its orientation stays the same. This is correct.

But what if I rotate the right face again? The center cubie of the right face is in the right layer, so it rotates again. Its orientation changes by another 90° around X. This is correct.

OK, I'm done thinking. Let me write the code now.

Let me also add a nice touch: when the cube is solved (all faces have a single color), show a "Solved!" message. But detecting whether the cube is solved is complex (I'd need to check the color of each visible face of each cubie). Let me skip this for now.

Actually, for the scramble, I need to make sure the cube is solvable. A valid Rubik's cube scramble only uses outer layer rotations (or equivalently, any sequence of face rotations). Since I'm only rotating outer layers, the cube remains solvable.

Wait, there's a subtlety. In a real Rubik's cube, you can rotate any face by 90°, 180°, or 270° (or -90°). All of these are valid moves. My implementation only rotates by 90° (or -90°). That's fine for scrambling.

But there's another subtlety: the parity of the cube. A Rubik's cube has certain invariants (like the parity of the permutation). A valid scramble preserves these invariants. Since I'm using valid moves (90° face rotations), the cube remains in a valid state.

OK, let me write the code now.

Let me also think about the scramble sequence. I'll generate 10-15 random moves and execute them. Each move is a random face (6 choices) and a random direction (2 choices: +90° or -90°).

For the scramble, I should avoid rotating the same face twice in a row, as that would be equivalent to a different rotation (e.g., rotating the right face by 90° twice is the same as rotating by 180°). But for simplicity, I won't enforce this. It's a minor optimization.

Actually, for a better scramble, I should avoid consecutive rotations of the same face or opposite faces (e.g., right then left), as these can be simplified. But again, for simplicity, I won't enforce this.

Let me just generate random moves and execute them.

Alright, here's the final code. Let me write it now.

Wait, I also need to consider: what happens when the user clicks on a face during the scramble? I should ignore clicks during the scramble. I'll use a flag `isScrambling` for this.

Also, what happens when the scramble is done? The user can then interact with the cube normally.

OK, let me write the code now. For real.

Let me draft the complete HTML file:

```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>
    * {
      margin: 0;
      padding: 0;
      box-sizing: border-box;
    }
    
    body {
      background: #1a1a2e;
      overflow: hidden;
      font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
      color: white;
      user-select: none;
    }
    
    #container {
      width: 100vw;
      height: 100vh;
      position: relative;
    }
    
    canvas {
      display: block;
      width: 100%;
      height: 100%;
    }
    
    #ui {
      position: absolute;
      top: 20px;
      left: 50%;
      transform: translateX(-50%);
      display: flex;
      flex-direction: column;
      align-items: center;
      gap: 10px;
      pointer-events: none;
    }
    
    #ui > * {
      pointer-events: auto;
    }
    
    #title {
      font-size: 24px;
      font-weight: bold;
      text-shadow: 0 2px 10px rgba(0,0,0,0.5);
      letter-spacing: 2px;
    }
    
    #controls {
      display: flex;
      gap: 10px;
      align-items: center;
    }
    
    button {
      padding: 10px 24px;
      font-size: 16px;
      font-weight: bold;
      border: none;
      border-radius: 8px;
      cursor: pointer;
      transition: transform 0.1s, box-shadow 0.1s;
      text-transform: uppercase;
      letter-spacing: 1px;
    }
    
    button:active {
      transform: scale(0.95);
    }
    
    #scrambleBtn {
      background: #e94560;
      color: white;
      box-shadow: 0 4px 15px rgba(233, 69, 96, 0.4);
    }
    
    #scrambleBtn:hover {
      box-shadow: 0 6px 20px rgba(233, 69, 96, 0.6);
    }
    
    #resetBtn {
      background: #0f3460;
      color: white;
      box-shadow: 0 4px 15px rgba(15, 52, 96, 0.4);
    }
    
    #info {
      font-size: 14px;
      opacity: 0.8;
      text-shadow: 0 2px 5px rgba(0,0,0,0.5);
      min-height: 20px;
    }
    
    #status {
      position: absolute;
      bottom: 20px;
      left: 50%;
      transform: translateX(-50%);
      font-size: 14px;
      opacity: 0.6;
      text-shadow: 0 2px 5px rgba(0,0,0,0.5);
    }
  </style>
</head>
<body>
  <div id="container">
    <div id="ui">
      <div id="title">RUBIK'S CUBE</div>
      <div id="controls">
        <button id="scrambleBtn">Scramble</button>
        <button id="resetBtn">Reset</button>
      </div>
      <div id="info">Click a face to rotate · Drag to orbit</div>
    </div>
    <div id="status"></div>
  </div>
  
  <script src="three.min.js"></script>
  <script>
    // ... all the Three.js code
  </script>
</body>
</html>
```

Now let me write the JavaScript code. This is the main part.

```javascript
// ============ SETUP ============
const container = document.getElementById('container');
const scene = new THREE.Scene();
scene.background = new THREE.Color(0x1a1a2e);

const camera = new THREE.PerspectiveCamera(45, container.clientWidth / container.clientHeight, 0.1, 100);
camera.position.set(4, 3, 4);

const renderer = new THREE.WebGLRenderer({ antialias: true });
renderer.setSize(container.clientWidth, container.clientHeight);
renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2));
renderer.shadowMap.enabled = true;
renderer.shadowMap.type = THREE.PCFSoftShadowMap;
container.prepend(renderer.domElement);

// ============ LIGHTS ============
const ambientLight = new THREE.AmbientLight(0x404060, 0.5);
scene.add(ambientLight);

const dirLight = new THREE.DirectionalLight(0xffffff, 1);
dirLight.position.set(5, 10, 7);
dirLight.castShadow = true;
dirLight.shadow.mapSize.width = 1024;
dirLight.shadow.mapSize.height = 1024;
scene.add(dirLight);

const fillLight = new THREE.DirectionalLight(0x8888ff, 0.3);
fillLight.position.set(-5, 0, -5);
scene.add(fillLight);

// ============ CUBE ============
const CUBE_SIZE = 0.94;
const GAP = 1 - CUBE_SIZE;

const COLORS = {
  right: 0xe02020,
  left: 0xf08020,
  top: 0xf0f0f0,
  bottom: 0xf0f040,
  front: 0x20c020,
  back: 0x2040f0
};

const DARK = 0x1a1a1a;

const cubies = [];
const cubiePositions = new Map();
const cubieMaterials = new Map();

The user wants a 3D Rubik's Cube with clickable face rotations, orbit-drag camera, and a scramble button. I've written the HTML file. Let me verify it works properly by checking the structure.

The code includes:
1. Three.js setup with scene, camera, renderer
2. Cube building with colored faces (red right, orange left, white top, yellow bottom, green front, blue back)
3. Manual orbit camera (theta/phi) with drag support
4. Raycaster-based click detection on cube faces
5. Layer rotation with easing animation
6. Highlighting the clicked face
7. Scramble button with 22 random moves
8. Reset button
9. Touch support for mobile

Let me verify the file is well-formed and check for any issues.

Actually, looking at my code again, I need to make sure the rotation direction is correct. When clicking a face, the rotation should be clockwise when viewed from outside. Let me double-check my logic.

In Three.js, a positive rotation around the +X axis rotates CCW when looking along +X (from the right side looking left). So if you're looking at the right face (+X) from outside, a positive rotation would appear clockwise. Wait, let me think again...

For the right face (+X), you're looking from the right toward the origin. Positive rotation around +X axis in Three.js rotates points in the YZ plane: a positive rotation rotates Y toward Z (CCW when looking along +X). So from outside (looking at +X face), a positive angle = CCW = counter-clockwise.

For clockwise (when viewed from outside), we need negative angle for +X face, positive for -X face. My code has `sign = val > 0 ? -1 : 1`, which gives -1 for +X (clockwise from outside) and +1 for -X (clockwise from outside). That seems correct.

For Y axis: positive rotation rotates Z toward X (CCW when looking along +Y from above). So from above (+Y), positive = CCW. We want clockwise = negative. My code gives sign = -1 for +Y (val > 0). Correct.

For Z axis: positive rotation rotates X toward Y (CCW when looking along +Z from front). So from front (+Z), positive = CCW. We want clockwise = negative. My code gives sign = -1 for +Z. Correct.

So the rotation direction should be correct for clockwise face rotations.

However, I noticed one issue: in the `doRotate` function, I'm updating `cubiePos` based on the final positions after rotation. But I'm not actually updating `cubiePos` - I'm just setting the mesh positions. The `cubiePos` array needs to be updated too, otherwise subsequent clicks would use stale positions.

Wait, actually I need to think about this more carefully. After a rotation, the cubies change positions. The `cubiePos` array stores the "logical" positions. When I bake the transforms, I need to update `cubiePos` to reflect the new positions.

Let me look at my code again:

```javascript
for (const idx of indices) {
    const mesh = cubies[idx];
    // Get world transform
    const worldPos = new THREE.Vector3();
    const worldQuat = new THREE.Quaternion();
    mesh.getWorldPosition(worldPos);
    mesh.getWorldQuaternion(worldQuat);

    group.remove(mesh);
    scene.add(mesh);
    mesh.position.copy(worldPos);
    mesh.quaternion.copy(worldQuat);
}
```

After this, I'm not updating `cubiePos[idx]`. So the next click would use the old position! I need to update `cubiePos`.

Actually wait - let me re-examine. The cubie positions after rotation will be at integer coordinates (like ±1, 0) because we're rotating by 90°. So I can compute the new positions.

But actually, a simpler approach: after baking, I should update `cubiePos` to match the new world positions, rounded to nearest integer.

Let me fix this. Also, I should ensure that the materials' colors stay with the cubie (i.e., when a cubie moves, its face colors move with it). This is already handled because each cubie has its own materials.

Let me update the code to fix the `cubiePos` issue.

Also, I realize there's another issue: when we rotate a layer, the cubies in that layer change positions. But the `cubiePos` array isn't updated. This would cause problems for subsequent rotations because `findClickedLayer` uses `cubiePos` to check if a cubie is on the surface.

Let me think about how to properly update positions. After a rotation by 90°, each cubie in the layer moves to a new position. For example, rotating the right layer (+X) by 90° (clockwise from outside):
- A cubie at (1, 1, 0) moves to (1, 0, 1)  [top front → top right when viewed... wait]

Let me think more carefully. For rotation around X axis by +90°:
- Y → Z, Z → -Y (or Y → -Z, Z → Y depending on direction)

Standard right-hand rule: positive rotation around X: Y→Z, Z→-Y.

So a cubie at (1, 1, 0) after +90° around X goes to (1, 0, 1)? Let me compute:
- New Y = Y*cos(90°) - Z*sin(90°) = 0 - 0 = 0
- New Z = Y*sin(90°) + Z*cos(90°) = 1 + 0 = 1

Yes, (1, 1, 0) → (1, 0, 1).

But in my code, I'm using `angle = sign * PI/2` where `sign = -1` for +X. So the rotation is -90° around X.
- New Y = Y*cos(-90°) - Z*sin(-90°) = 0 + Z = 0 + 0 = 0
- New Z = Y*sin(-90°) + Z*cos(-90°) = -Y + 0 = -1

So (1, 1, 0) → (1, 0, -1). That's top front → back bottom when viewed from right... seems wrong for clockwise.

Hmm, let me reconsider. When you look at the right face of a Rubik's cube and turn it clockwise (from your perspective outside the cube), the top row moves toward the front, the front moves toward the bottom, etc.

So for the right face (+X, val=1), clockwise from outside:
- A cubie at top (y=1) moves to front (z=1)? Or to back (z=-1)?

When you look at the right face from outside (from +X direction), your view is:
- Up is +Y
- Right is +Z (or -Z? depends on orientation)

Actually, when looking from +X toward origin, the Z axis points... let me think. If you stand on the +X axis looking toward origin, the Z axis goes to your right if we use a right-handed coordinate system. Wait, no. In Three.js (right-handed), if you're at +X looking toward -X (toward origin), Y is up, and Z... 

Standard camera: looking along -Z, Y up, X right. If we rotate to look along -X, then:
- Up = Y (still up)
- Right = ? 

The rotation from -Z to -X is a 90° rotation around Y axis. After this rotation:
- The original +Z (toward camera) becomes +X? No...

Let me use a different approach. When looking at the right face (+X) from outside:
- Your eye is at +X looking toward -X
- Up is +Y
- Right is +Z (because if you're facing -X, and Y is up, then Z is to your right in a right-handed system)

Wait, let me verify: in a right-handed system with X right, Y up, Z toward viewer (out of screen), if we rotate to look along -X (from +X side), then:
- Y is still up
- Z (originally toward viewer) is now... pointing right? 

Actually, if we rotate the standard view (looking along -Z) by 90° around Y so we look along -X:
- The +Z axis rotates to +X
- The +X axis rotates to -Z

So when looking along -X (from +X side), the +Z axis is now pointing to the right, and +X is pointing away (into the screen).

So from the +X face view:
- Up = +Y
- Right = +Z
- Into screen = +X (toward origin)

Now, clockwise rotation (from this view) means:
- Top (Y=1) → Right (Z=1)
- Right (Z=1) → Bottom (Y=-1)
- Bottom (Y=-1) → Left (Z=-1)
- Left (Z=-1) → Top (Y=1)

So the rotation formula for clockwise from +X view:
- Y_new = -Z_old  (Z=1 goes to Y=-1, Z=-1 goes to Y=1)
- Z_new = Y_old   (Y=1 goes to Z=1, Y=-1 goes to Z=-1)

Wait, that gives Y_new = -Z, Z_new = Y. Let me check:
- (1, 1, 0): Y=1, Z=0 → Y_new = 0, Z_new = 1 → (1, 0, 1). Top goes to right (front). ✓
- (1, 0, 1): Y=0, Z=1 → Y_new = -1, Z_new = 0 → (1, -1, 0). Front goes to bottom. ✓
- (1, -1, 0): Y=-1, Z=0 → Y_new = 0, Z_new = -1 → (1, 0, -1). Bottom goes to back. ✓
- (1, 0, -1): Y=0, Z=-1 → Y_new = 1, Z_new = 0 → (1, 1, 0). Back goes to top. ✓

So clockwise from +X view: Y_new = -Z, Z_new = Y.

In rotation matrix form (around X axis):
- Y_new = Y*cos(θ) - Z*sin(θ)
- Z_new = Y*sin(θ) + Z*cos(θ)

For Y_new = -Z, Z_new = Y, we need:
- cos(θ) = 0, -sin(θ) = -1 → sin(θ) = 1 → θ = 90° (π/2)
- sin(θ) = 1, cos(θ) = 0 → Z_new = Y. ✓

So positive 90° rotation around X gives clockwise from +X view! That means my original code with `sign = val > 0 ? -1 : 1` is WRONG for the right face.

Wait, I made an error. Let me re-derive.

Three.js rotation around X by angle θ:
```
Y' = Y*cos(θ) - Z*sin(θ)
Z' = Y*sin(θ) + Z*cos(θ)
```

For θ = +90° (π/2):
- cos(90°) = 0, sin(90°) = 1
- Y' = -Z
- Z' = Y

This matches my clockwise rotation! So positive rotation around X axis gives clockwise from +X view.

But in my code, I set `sign = val > 0 ? -1 : 1`, which gives -1 for +X (val=1), meaning angle = -π/2. That would be counter-clockwise from +X view, which is wrong!

Let me fix this. For clockwise from outside:
- +X face (val=1): need +90° around X → sign = +1
- -X face (val=-1): need -90° around X → sign = -1
- +Y face (val=1): need +90° around Y → sign = +1
- -Y face (val=-1): need -90° around Y → sign = -1
- +Z face (val=1): need +90° around Z → sign = +1
- -Z face (val=-1): need -90° around Z → sign = -1

So `sign = val > 0 ? 1 : -1` (just val).

Wait, let me double-check for -X face. Looking at -X face from outside (from -X toward +X):
- Up = +Y
- Right = -Z (because when looking along +X, the right direction is -Z)

Clockwise from -X view:
- Top (Y=1) → Left (Z=-1, which is right from this view... wait)

Hmm, I need to be more careful. Let me re-derive for -X face.

When looking along +X (from -X side toward origin):
- The view direction is +X
- Up is +Y
- Right: in a right-handed system, if we're looking along +X, then right = -Z (because X cross Y = Z, so if view is +X and up is +Y, right = +X cross +Y = +Z... but we want right to point to the right of our view)

Actually, let me use the standard camera model. When camera looks along direction D with up vector U:
- Right = normalize(cross(D, U))... no, that's not right either.

Let me think differently. In a right-handed coordinate system:
- X × Y = Z
- Y × Z = X
- Z × X = Y

If camera looks along -Z (standard), up is +Y, then right is +X.
If camera looks along +X (from -X side), up is +Y, then:
- We need a rotation that maps -Z to +X
- This is a rotation around Y by -90° (or +90°?)
- Rotating around Y by +90°: Z→X, X→-Z. So -Z→-X... that's not right.
- Rotating around Y by -90°: Z→-X, X→Z. So -Z→+X. ✓

So to go from standard view (-Z) to looking along +X, we rotate around Y by -90°. After this rotation:
- Original +X (right) → +Z (because X→Z under -90° Y rotation)
- Original +Y (up) → +Y (unchanged)

So when looking along +X (from -X side):
- Right = +Z
- Up = +Y

Clockwise from -X view (looking along +X):
- Top (Y=1) → Right (Z=1)? No wait, right is +Z, so clockwise from view means top goes to... 

Actually, clockwise when looking at the face means: if you're looking at the face, the top moves to the right. So from -X view (looking along +X):
- Top (Y=1) → Right (+Z direction)
- Right (+Z) → Bottom (Y=-1)
- Bottom (Y=-1) → Left (-Z)
- Left (-Z) → Top (Y=1)

So the transformation is:
- Y_new = Z_old (Y=1→Z=1, Y=-1→Z=-1... wait that's not right)

Let me redo: clockwise from -X view means:
- Point at top (Y=1, Z=0) moves to right (Y=0, Z=1)
- Point at right (Y=0, Z=1) moves to bottom (Y=-1, Z=0)
- Point at bottom (Y=-1, Z=0) moves to left (Y=0, Z=-1)
- Point at left (Y=0, Z=-1) moves to top (Y=1, Z=0)

So: Y_new = -Z_old, Z_new = Y_old? Let me check:
- (Y=1, Z=0): Y_new = 0, Z_new = 1 → (0, 1). That's right, not top→right. Wait, top should go to right, so (1,0) → (0,1). Y_new=0, Z_new=1. ✓
- (Y=0, Z=1): Y_new = -1, Z_new = 0 → (-1, 0). That's bottom. Right→bottom. ✓
- (Y=-1, Z=0): Y_new = 0, Z_new = -1 → (0, -1). That's left. Bottom→left. ✓
- (Y=0, Z=-1): Y_new = 1, Z_new = 0 → (1, 0). That's top. Left→top. ✓

So Y_new = -Z, Z_new = Y for clockwise from -X view.

Now, what rotation angle gives this? Around X axis:
- Y' = Y*cos(θ) - Z*sin(θ)
- Z' = Y*sin(θ) + Z*cos(θ)

For Y' = -Z, Z' = Y:
- cos(θ) = 0, -sin(θ) = -1 → sin(θ) = 1 → θ = 90°
- sin(θ) = 1, cos(θ) = 0 → Z' = Y. ✓

So +90° around X also gives clockwise from -X view!

But wait, that's the same as for +X view. So both +X and -X faces rotate clockwise with +90° around X? That can't be right.

Let me reconsider. When looking at +X face (from +X side, looking along -X):
- Right = +Z (as I derived earlier... actually let me re-derive)

To go from standard view (-Z) to looking along -X (from +X side):
- We need to rotate from -Z to -X
- Rotation around Y by +90°: Z→X, X→-Z. So -Z→-X. ✓

After this rotation:
- Original +X (right) → -Z (because X→-Z)
- Original +Y (up) → +Y

So when looking along -X:
- Right = -Z
- Up = +Y

Clockwise from +X view (looking along -X):
- Top (Y=1) → Right (-Z direction, so Z=-1)
- Right (-Z) → Bottom (Y=-1)
- Bottom (Y=-1) → Left (+Z, so Z=1)
- Left (+Z) → Top (Y=1)

So: Y_new = Z_old, Z_new = -Y_old? Let me check:
- (Y=1, Z=0): Y_new = 0, Z_new = -1 → (0, -1). That's right (Z=-1). Top→right. ✓
- (Y=0, Z=-1): Y_new = -1, Z_new = 0 → (-1, 0). Bottom. Right→bottom. ✓
- (Y=-1, Z=0): Y_new = 0, Z_new = 1 → (0, 1). Left (Z=1). Bottom→left. ✓
- (Y=0, Z=1): Y_new = 1, Z_new = 0 → (1, 0). Top. Left→top. ✓

So Y_new = Z, Z_new = -Y for clockwise from +X view.

Now, what rotation angle gives this? Around X axis:
- Y' = Y*cos(θ) - Z*sin(θ)
- Z' = Y*sin(θ) + Z*cos(θ)

For Y' = Z, Z' = -Y:
- cos(θ) = 0, -sin(θ) = 1 → sin(θ) = -1 → θ = -90°
- sin(θ) = -1, cos(θ) = 0 → Z' = -Y. ✓

So -90° around X gives clockwise from +X view!

OK so I had it right originally: +X face needs -90° (sign = -1), -X face needs +90° (sign = +1). So `sign = val > 0 ? -1 : 1` is CORRECT for X axis!

Let me also verify for Y and Z axes.

For Y axis, clockwise from +Y view (looking along -Y):
- To go from -Z to -Y: rotate around X by +90°. After: Y→-Z, Z→Y. So -Z→-Y... wait.
- Rotate around X by +90°: Y→Z, Z→-Y. So -Z→+Y, not -Y.
- Rotate around X by -90°: Y→-Z, Z→Y. So -Z→-Y. ✓

After rotating around X by -90°:
- Original +Y (up) → -Z
- Original +Z (toward viewer) → +Y

So when looking along -Y:
- Right = +Z (original +Z → +Y... no)

Hmm, I'm getting confused. Let me use a simpler approach.

For a standard Rubik's cube, the convention is:
- Right face (R): clockwise turn when looking at right face
- Left face (L): clockwise turn when looking at left face
- Up face (U): clockwise turn when looking at top
- Down face (D): clockwise turn when looking at bottom
- Front face (F): clockwise turn when looking at front
- Back face (B): clockwise turn when looking at back

In standard Rubik's cube notation, these are all clockwise when looking directly at that face from outside.

Now, in Three.js:
- Rotation around X axis: positive = CCW when looking along +X (from right side). So for R face (looking from +X), clockwise = negative rotation.
- Rotation around Y axis: positive = CCW when looking along +Y (from top). So for U face (looking from +Y), clockwise = negative rotation.
- Rotation around Z axis: positive = CCW when looking along +Z (from front). So for F face (looking from +Z), clockwise = negative rotation.

For opposite faces, it's the opposite:
- L face (looking from -X): clockwise = positive rotation around X
- D face (looking from -Y): clockwise = positive rotation around Y
- B face (looking from -Z): clockwise = positive rotation around Z

So:
- R (+X): angle = -π/2
- L (-X): angle = +π/2
- U (+Y): angle = -π/2
- D (-Y): angle = +π/2
- F (+Z): angle = -π/2
- B (-Z): angle = +π/2

This can be written as: angle = -val * π/2, where val is +1 or -1.

So `sign = -val` or equivalently `sign = val > 0 ? -1 : 1`. My original code is correct!

Great, so my rotation logic is correct. Now I just need to make sure `cubiePos` is updated after rotation.

Let me update the code to fix the `cubiePos` update issue. After baking transforms, I need to update `cubiePos[idx]` to the new position (rounded to nearest integer).

Let me also double-check the scramble function. It uses `animateLayer` which also doesn't update `cubiePos`. Same issue.

I'll fix both functions to update `cubiePos` after baking.

Also, I should make sure the highlight is cleared properly and the info text is updated.

Let me rewrite the file with these fixes.

Actually, let me reconsider the entire approach. Instead of tracking `cubiePos` separately, I could just read the position from each mesh. But the issue is that during rotation, the mesh positions are modified by the group, and I need to know which cubies are on which layer for the next click.

Actually, a cleaner approach: after each rotation, update `cubiePos` by reading the world position of each mesh (rounded to nearest 0.5 or 1). Since all cubies are at integer positions (±1, 0), rounding to nearest integer works.

But wait, what about the center cubies? They're at (0, 0, 0) and don't move. Their position is always (0, 0, 0).

For edge and corner cubies, after rotation they move to new integer positions. So I can round the world position to the nearest integer.

But there's a subtlety: after rotation, the cubie's position might not be exactly at an integer due to floating point. I should round carefully.

Let me also think about whether I need to track the orientation (quaternion) of each cubie. For the Rubik's cube interaction, we only care about which layer to rotate, which is determined by position. The orientation doesn't matter for determining the layer.

So I just need to update `cubiePos` after each rotation. Let me do that.

Actually, I realize there's an even simpler approach: I don't need `cubiePos` at all for determining the layer! I can just check the mesh's position directly. But `cubiePos` is used in `findClickedLayer` to check if the clicked cubie is on the surface of the clicked layer.

Wait, but `cubiePos` stores the "logical" position, which should match the mesh position. After a rotation, the mesh position changes, so `cubiePos` should be updated.

The simplest fix: after baking transforms, update `cubiePos[idx]` to `mesh.position` (rounded to nearest integer).

Let me update the code.

Actually, I think there might be another issue. When we rotate a layer, the cubies in that layer move, but the other cubies stay. The `cubiePos` array should reflect the current positions of all cubies. After a rotation, I need to update the positions of the cubies that moved.

Let me implement this properly.

Here's my plan:
1. After baking transforms in `doRotate` and `animateLayer`, update `cubiePos[idx]` for each moved cubie.
2. Round the position to the nearest integer (since all positions are at ±1 or 0).

Let me also make sure the scramble function works correctly. It calls `animateLayer` sequentially, and each call should update `cubiePos`.

Let me rewrite the file.

Actually, I just realized there's a potential issue with my current code: in `findClickedLayer`, I check `if (layer.axis === 'x' && pos.x !== layer.val) return null;`. This uses `cubiePos[idx]`, which might be stale after a rotation. So updating `cubiePos` is critical.

Let me fix this now.

I'll edit the file to add `cubiePos` updates after baking transforms.

Let me write the corrected version.

One more thing: I should also handle the case where the user clicks during an animation. Currently, `doRotate` returns early if `isAnimating` is true. That's fine.

For the scramble, I use `await animateLayer(...)` which waits for each animation to complete. During scramble, `isScrambling` is true, so clicks are ignored. That's also fine.

OK let me write the corrected code.

Wait, I also want to double-check the rotation direction one more time with a concrete example.

Consider the right face (+X, val=1). I claim clockwise from outside = -90° around X.

Let's trace a corner cubie at (1, 1, 1) (top-front-right corner).
- After -90° around X: 
  - Y' = Y*cos(-90°) - Z*sin(-90°) = 1*0 - 1*(-1) = 1
  - Z' = Y*sin(-90°) + Z*cos(-90°) = 1*(-1) + 1*0 = -1
  - New position: (1, 1, -1) = top-back-right corner

Is this correct? When you turn the right face clockwise (from outside), the top-front-right corner should move to... 

Looking at the right face from outside:
- The top edge (y=1) moves toward the front (z=1)? Or toward the back (z=-1)?

When you look at the right face of a Rubik's cube and turn it clockwise:
- The top row moves toward you (if front is toward you)... but wait, which way is "toward you"?

If you're looking at the right face, the front face is to your left. So "toward you" doesn't make sense. Let me think of it differently.

Standard Rubik's cube orientation:
- Front (F) is facing you (z=1)
- Right (R) is to your right (x=1)
- Top (U) is up (y=1)

When you look at the right face (R), you're looking from the right side. The front face is to your left, the back face is to your right, top is up, bottom is down.

Turning the right face clockwise (from your perspective looking at the right face):
- The top row moves toward the front (your left)
- The front moves toward the bottom
- The bottom moves toward the back (your right)
- The back moves toward the top

So the top-front-right corner (1, 1, 1) should move to... top-back-right? No, top moves toward front, so top-front goes to... 

Wait, the corner (1, 1, 1) is at the intersection of right, top, and front faces. When you turn the right face clockwise:
- The top part of this corner moves toward the front
- But the corner is already at the front (z=1)

Hmm, I think I'm overcomplicating this. Let me use a physical analogy.

Hold a Rubik's cube with front facing you, right face on your right. Now look at the right face. Turn it clockwise (from your perspective).

The sticker that was on the top of the right face (y=1) moves to the front of the right face (z=1). The sticker that was on the front of the right face (z=1) moves to the bottom (y=-1). Etc.

So for the corner cubie at (1, 1, 1):
- Its right face sticker (x=1) stays on the right
- Its top face sticker (y=1) moves to the front (z=1)? No, the top sticker moves to... 

Actually, the entire cubie moves. The cubie at (1, 1, 1) moves to a new position. Which position?

When you turn the right face clockwise:
- The u... I'm going in circles. Let me just trust the math.

For -90° around X (clockwise from +X view):
- (1, 1, 1) → Y' = 1*0 - 1*(-1) = 1, Z' = 1*(-1) + 1*0 = -1 → (1, 1, -1)

So the corner moves from top-front-right to top-back-right. Is that correct for a clockwise turn of the right face?

When you turn the right face clockwise (from outside):
- The top-front edge moves to top-back? That doesn't seem right.

Let me think again. When looking at the right face:
- Your view direction is -X (from +X toward origin)
- Up is +Y
- Right (of your view) is -Z (because... let me re-derive)

To go from standard view (-Z view) to looking at +X face:
- Rotate around Y by +90°: this maps -Z to +X? 
  - Rotation around Y by +90°: X→Z, Z→-X, Y→Y
  - So -Z→+X? No: Z→-X, so -Z→+X. Yes! ✓
- After this rotation:
  - Original +X (right of screen) → +Z (toward viewer... no, +Z is now pointing... )

Ugh, this is getting confusing. Let me just use a different method.

Consider the rotation matrix around X axis by angle θ:
```
R_x(θ) = [[1, 0, 0],
          [0, cos(θ), -sin(θ)],
          [0, sin(θ), cos(θ)]]
```

For θ = -90°:
```
R_x(-90°) = [[1, 0, 0],
             [0, 0, 1],
             [0, -1, 0]]
```

Apply to (1, 1, 1):
- x' = 1
- y' = 0*1 + 1*1 = 1
- z' = -1*1 + 0*1 = -1

So (1, 1, 1) → (1, 1, -1). The corner moves from front (z=1) to back (z=-1), staying at top (y=1) and right (x=1).

Now, is this what happens when you turn the right face clockwise?

When you look at the right face and turn it clockwise:
- The top of the right face (y=1) rotates toward... 

OK, I think the issue is that "clockwise" depends on which direction you're looking. Let me just verify with a known standard.

In Rubik's cube notation:
- R = turn the right face 90° clockwise (when looking at the right face)

The effect of R on the corners:
- URF (up-right-front) → UBR (up-back-right)? Or URF → UFR?

Standard Rubik's cube R move:
- URF → UBR? No...
- Let me look up the standard R move permutation.

Actually, the standard R move (clockwise when looking at right face):
- UFR → UBR (up-front-right goes to up-back-right)
- UBR → DBR (up-back-right goes to down-back-right)
- DBR → DFR (down-back-right goes to down-front-right)
- DFR → UFR (down-front-right goes to up-front-right)

Wait, that doesn't seem right either. Let me think about it physically.

When you turn the right face clockwise (looking at it):
- The top-front edge of the right face moves toward the front
- So the UFR corner (top-front-right) moves to... 

Actually, when you turn the right face, the entire right layer rotates. The UFR corner is part of the right layer. When you rotate the right layer clockwise (from the right side view):
- UFR moves to UBR? No, UFR is at the front-top, and after clockwise rotation, it should move to...

Let me use the right-hand rule. Point your right thumb toward you (along +X, since you're looking at the right face from outside). Your fingers curl clockwise. So the rotation is around +X, with your fingers curling from +Y toward +Z? Or from +Y toward -Z?

Right-hand rule: thumb along +X, fingers curl from +Y to +Z. So a positive rotation around +X moves +Y toward +Z.

But when looking at the right face (from +X toward -X), +Y is up and +Z is... to the left (because when you face -X, +Z is on your left in a right-handed system).

Wait, no. When you're on the +X axis looking toward -X:
- Your view direction is -X
- Up is +Y
- What is "right"? In a standard camera setup, right = cross(up, view_direction)? No, right = cross(view_direction, up)? 

Actually, for a camera looking along -Z with up = +Y:
- right = +X (because X points to the right when looking along -Z)

For a camera looking along -X with up = +Y:
- We need to find the right vector. If we rotate the standard camera (looking along -Z) by 90° around Y to look along -X:
  - The +X axis (right) rotates to... -Z or +Z?
  - Rotation around Y by +90°: X→Z, Z→-X
  - So +X → +Z
  - So right = +Z when looking along -X

Wait, I did this earlier and got right = -Z. Let me be more careful.

Standard camera: position at (0, 0, 5), looking at (0, 0, 0) along -Z. Up = +Y. Right = +X.

Now rotate the camera 90° around Y axis so it looks along -X:
- New position: (5, 0, 0) or (-5, 0, 0)?
- If we rotate the camera (which is at +Z) by 90° around Y:
  - +Z → +X (using right-hand rule: thumb along +Y, fingers from +Z to +X)
  - So camera moves to +X
  - Camera looks along -X (toward origin)
- After this rotation:
  - Original +X (right of view) → +Z (because X→Z under +90° Y rotation)
  - Original +Y (up) → +Y (unchanged)

So when looking along -X (from +X side):
- Right = +Z
- Up = +Y

Now, clockwise rotation when looking at the right face (from +X side, looking along -X):
- In screen coordinates, clockwise means: right → down → left → up → right
- In 3D: +Z (right) → -Y (down) → -Z (left) → +Y (up) → +Z (right)

So a point on the right face:
- (x=1, y=1, z=0) [top, y=+Y] → should move to right (z=+Z)? No, top should move to right in clockwise rotation.

Clockwise: top → right → bottom → left → top
- Top (+Y) → Right (+Z)
- Right (+Z) → Bottom (-Y)
- Bottom (-Y) → Left (-Z)
- Left (-Z) → Top (+Y)

So the transformation for clockwise rotation when looking at right face:
- Y_new = +Z_old? No...
- If top (+Y) goes to right (+Z), then a point at (1, 1, 0) should go to (1, 0, 1).
- If right (+Z) goes to bottom (-Y), then (1, 0, 1) → (1, -1, 0).
- If bottom (-Y) goes to left (-Z), then (1, -1, 0) → (1, 0, -1).
- If left (-Z) goes to top (+Y), then (1, 0, -1) → (1, 1, 0).

So: Y_new = Z_old, Z_new = -Y_old? Let me check:
- (1, 1, 0): Y=1, Z=0 → Y_new = 0, Z_new = -1. That's (0, -1), which is bottom. But we want top→right, which is (0, 1). So this is wrong.

Let me try: Y_new = -Z_old, Z_new = Y_old:
- (1, 1, 0): Y_new = 0, Z_new = 1 → (0, 1). That's right. Top→right. ✓
- (1, 0, 1): Y_new = -1, Z_new = 0 → (-1, 0). Bottom. Right→bottom. ✓
- (1, -1, 0): Y_new = 0, Z_new = -1 → (0, -1). Left. Bottom→left. ✓
- (1, 0, -1): Y_new = 1, Z_new = 0 → (1, 0). Top. Left→top. ✓

So Y_new = -Z, Z_new = Y for clockwise from +X view.

Now, what rotation angle gives this? Around X:
- Y' = Y*cos(θ) - Z*sin(θ)
- Z' = Y*sin(θ) + Z*cos(θ)

For Y' = -Z, Z' = Y:
- cos(θ) = 0, -sin(θ) = -1 → sin(θ) = 1 → θ = 90° (π/2)
- sin(θ) = 1, cos(θ) = 0 → Z' = Y ✓

So +90° (π/2) around X gives clockwise from +X view!

But earlier I concluded -90° gives clockwise. Which is correct?

Let me re-derive the rotation matrix. Three.js uses a right-handed coordinate system. The rotation matrix around X by angle θ (using right-hand rule: thumb along +X, fingers curl in direction of positive rotation):

```
R_x(θ) = [[1, 0, 0],
          [0, cos(θ), -sin(θ)],
          [0, sin(θ), cos(θ)]]
```

This is the standard rotation matrix. For θ = +90°:
- cos(90°) = 0, sin(90°) = 1
- R_x(90°) = [[1, 0, 0], [0, 0, -1], [0, 1, 0]]

Apply to (1, 1, 0):
- y' = 0*1 + (-1)*0 = 0
- z' = 1*1 + 0*0 = 1
- Result: (1, 0, 1). Top→right. ✓

So +90° around X gives Y' = -Z, Z' = Y, which is clockwise from +X view!

But wait, I earlier said +90° gives Y' = -Z, Z' = Y. Let me check with the matrix:
- y' = y*cos(θ) - z*sin(θ) = 1*0 - 0*1 = 0
- z' = y*sin(θ) + z*cos(θ) = 1*1 + 0*0 = 1

So (1, 1, 0) → (1, 0, 1). Y went from 1 to 0, Z went from 0 to 1. That's Y' = -Z_old? No, Z_old = 0, so -Z_old = 0 = Y'. And Z' = Y_old = 1. ✓

So for θ = +90°:
- Y' = -Z (since cos(90°)=0, -sin(90°)=-1, so y' = -z)
- Z' = Y (since sin(90°)=1, cos(90°)=0, so z' = y)

This matches Y_new = -Z_old, Z_new = Y_old. ✓

So +90° around X = clockwise from +X view!

This means my original code with `sign = val > 0 ? -1 : 1` is WRONG! For +X face, I should use +90°, not -90°.

Wait, but earlier I derived that for -X view (looking along +X), clockwise also requires +90° around X. Let me re-check.

For -X face (val=-1), looking from -X side toward +X:
- View direction = +X
- Up = +Y
- Right = ?

To go from standard view (-Z) to looking along +X:
- Rotate around Y by -90°: Z→-X, X→Z. So -Z→+X. ✓
- After: original +X (right) → +Z (right of new view)? 
  - X→Z under -90° Y rotation, so +X→+Z. Right = +Z. ✓
- Up = +Y (unchanged).

So when looking along +X (from -X side):
- Right = +Z
- Up = +Y

Clockwise from -X view:
- Top (+Y) → Right (+Z)
- Right (+Z) → Bottom (-Y)
- Bottom (-Y) → Left (-Z)
- Left (-Z) → Top (+Y)

Same as +X view! So Y_new = -Z, Z_new = Y, which requires +90° around X.

So both +X and -X faces use +90° for clockwise? That can't be right because they should rotate in opposite directions.

Wait, I think I made an error. Let me re-examine.

For -X face, looking along +X (from -X side):
- Right = +Z (as I just derived)
- Up = +Y

Clockwise: top→right→bottom→left→top
- Top (+Y) → Right (+Z): (y=1, z=0) → (y=0, z=1)
- Right (+Z) → Bottom (-Y): (y=0, z=1) → (y=-1, z=0)
- Bottom (-Y) → Left (-Z): (y=-1, z=0) → (y=0, z=-1)
- Left (-Z) → Top (+Y): (y=0, z=-1) → (y=1, z=0)

So Y_new = -Z, Z_new = Y. Same as +X face!

But this means both faces rotate the same way, which is wrong. If you look at the right face and turn it clockwise, and then look at the left face and turn it clockwise, they should rotate in opposite directions relative to the cube.

Oh wait, I think the issue is that "clockwise" is defined relative to the viewer looking at that face. So for the right face, you're looking from +X, and for the left face, you're looking from -X. The rotations are both "clockwise from the viewer's perspective," which means they are opposite rotations in world space.

For right face (+X): clockwise from +X view = +90° around X (as derived).
For left face (-X): clockwise from -X view... let me re-derive.

Actually, I think I made an error in the -X derivation. Let me redo it.

When looking along +X (from -X side toward origin):
- View direction = +X
- Up = +Y
- Right = ?

Using the camera rotation method:
- Standard camera looks along -Z, up = +Y, right = +X.
- To look along +X, we need to rotate from -Z to +X.
- Rotation around Y by +90°: Z→X, X→-Z. So -Z→-X, not +X.
- Rotation around Y by -90°: Z→-X, X→Z. So -Z→+X. ✓

So rotate around Y by -90°:
- Original +X (right) → +Z (because X→Z under -90° Y rotation)
- Original +Y (up) → +Y

So when looking along +X:
- Right = +Z
- Up = +Y

Now, clockwise from this view:
- In screen space, clockwise is: right→down→left→up→right
- Right (+Z) → Down (-Y) → Left (-Z) → Up (+Y) → Right (+Z)

So:
- Right (+Z) goes to Down (-Y): (y=0, z=1) → (y=-1, z=0)
- Down (-Y) goes to Left (-Z): (y=-1, z=0) → (y=0, z=-1)
- Left (-Z) goes to Up (+Y): (y=0, z=-1) → (y=1, z=0)
- Up (+Y) goes to Right (+Z): (y=1, z=0) → (y=0, z=1)

So: Y_new = -Z_old, Z_new = Y_old? Let me check:
- (y=1, z=0): Y_new = 0, Z_new = 1 → (0, 1). Up→right. ✓
- (y=0, z=1): Y_new = -1, Z_new = 0 → (-1, 0). Right→down. ✓
- (y=-1, z=0): Y_new = 0, Z_new = -1 → (0, -1). Down→left. ✓
- (y=0, z=-1): Y_new = 1, Z_new = 0 → (1, 0). Left→up. ✓

So Y_new = -Z, Z_new = Y for clockwise from -X view as well!

This means both +X and -X faces use the same rotation formula for clockwise? That seems wrong.

Oh wait, I think I see the issue. For the -X face, "clockwise" means the top moves to the right, which is +Z. But +Z is the front direction! So turning the left face clockwise (from the left side view) moves the top toward the front.

But for the right face, "clockwise" moves the top toward... +Z as well (since right = +Z when looking from +X). So both move top toward +Z?

That can't be right. Let me think about it physically.

Hold a Rubik's cube with front facing you. Look at the right face. Turn it clockwise. The top of the right face moves toward the front (toward you). Now look at the left face. Turn it clockwise. The top of the left face moves toward... the back (away from you)?

Actually, when you look at the left face (from the left side), the front is to your right. So "clockwise" from the left face view means top moves toward your right, which is toward the front (since front is to your right when looking at the left face).

Wait, that's the same direction! Both right and left face clockwise turns move the top toward the front?

No, that's not right. Let me think again.

When you look at the right face (from the right side):
- Front is to your left
- Clockwise: top → right (of your view) → bottom → left (of your view) → top
- Right of your view is... the back direction (since you're looking at the right face, and front is to your left, so right is back)

Wait, I need to re-derive the right vector for the right face view.

When looking along -X (from +X side toward origin):
- View direction = -X
- Up = +Y
- Right = ?

Rotate standard camera (looking along -Z) to look along -X:
- Rotation around Y by +90°: Z→X, X→-Z. So -Z→-X. ✓
- After: original +X (right) → -Z (because X→-Z under +90° Y rotation)
- So right = -Z when looking along -X

So when looking at the right face:
- Right (of view) = -Z (back direction)
- Up = +Y
- Front is to the left (of view) = +Z

Clockwise from right face view:
- Top (+Y) → Right (-Z) [back direction]
- Right (-Z) → Bottom (-Y)
- Bottom (-Y) → Left (+Z) [front direction]
- Left (+Z) → Top (+Y)

So: Y_new = Z_old, Z_new = -Y_old? Let me check:
- (y=1, z=0): Y_new = 0, Z_new = -1 → (0, -1). Top→right (back, z=-1). ✓
- (y=0, z=-1): Y_new = -1, Z_new = 0 → (-1, 0). Right (back)→bottom. ✓
- (y=-1, z=0): Y_new = 0, Z_new = 1 → (0, 1). Bottom→left (front, z=1). ✓
- (y=0, z=1): Y_new = 1, Z_new = 0 → (1, 0). Left (front)→top. ✓

So Y_new = Z, Z_new = -Y for clockwise from +X view.

Now, what rotation angle gives this? Around X:
- Y' = Y*cos(θ) - Z*sin(θ)
- Z' = Y*sin(θ) + Z*cos(θ)

For Y' = Z, Z' = -Y:
- cos(θ) = 0, -sin(θ) = 1 → sin(θ) = -1 → θ = -90°
- sin(θ) = -1, cos(θ) = 0 → Z' = -Y ✓

So -90° around X gives clockwise from +X view!

This matches my original code: `sign = val > 0 ? -1 : 1` gives -1 for +X (val=1), so angle = -π/2. ✓

Now for -X face (left face):
When looking along +X (from -X side toward origin):
- View direction = +X
- Up = +Y
- Right = ?

Rotate standard camera to look along +X:
- Rotation around Y by -90°: Z→-X, X→Z. So -Z→+X. ✓
- After: original +X (right) → +Z (because X→Z under -90° Y rotation)
- So right = +Z when looking along +X

So when looking at the left face:
- Right (of view) = +Z (front direction)
- Up = +Y
- Front is to the right (of view) = +Z
- Back is to the left (of view) = -Z

Clockwise from left face view:
- Top (+Y) → Right (+Z) [front direction]
- Right (+Z) → Bottom (-Y)
- Bottom (-Y) → Left (-Z) [back direction]
- Left (-Z) → Top (+Y)

So: Y_new = -Z_old, Z_new = Y_old? Let me check:
- (y=1, z=0): Y_new = 0, Z_new = 1 → (0, 1). Top→right (front, z=1). ✓
- (y=0, z=1): Y_new = -1, Z_new = 0 → (-1, 0). Right (front)→bottom. ✓
- (y=-1, z=0): Y_new = 0, Z_new = -1 → (0, -1). Bottom→left (back, z=-1). ✓
- (y=0, z=-1): Y_new = 1, Z_new = 0 → (1, 0). Left (back)→top. ✓

So Y_new = -Z, Z_new = Y for clockwise from -X view.

What rotation angle gives this? Around X:
- Y' = Y*cos(θ) - Z*sin(θ)
- Z' = Y*sin(θ) + Z*cos(θ)

For Y' = -Z, Z' = Y:
- cos(θ) = 0, -sin(θ) = -1 → sin(θ) = 1 → θ = +90°
- sin(θ) = 1, cos(θ) = 0 → Z' = Y ✓

So +90° around X gives clockwise from -X view!

So:
- +X face (right): clockwise = -90° around X
- -X face (left): clockwise = +90° around X

This is exactly what my original code does: `sign = val > 0 ? -1 : 1`.

Great, my original code is correct!

Now let me also verify Y and Z axes.

For Y axis:
- +Y face (up): looking along -Y (from top)
- -Y face (down): looking along +Y (from bottom)

For +Y face:
- View direction = -Y
- Up = ? (when looking down, up is...)
- Right = ?

Rotate standard camera to look along -Y:
- Rotation around X by +90°: Y→Z, Z→-Y. So -Z→-Y? No: Z→-Y, so -Z→+Y. That's not right.
- Rotation around X by -90°: Y→-Z, Z→Y. So -Z→-Y? No: Z→Y, so -Z→-Y. ✓

Wait, let me be more careful. Standard camera looks along -Z. We want to look along -Y.

Rotation around X by +90°: Y→Z, Z→-Y.
- So -Z→+Y. That means the camera (at +Z) moves to +Y, looking along -Y? No, the camera looks along -Z originally, and after rotation, it looks along... 

Actually, the camera's view direction is -Z. After rotation around X by +90°:
- -Z → +Y (because Z→-Y, so -Z→+Y)
- So the camera looks along +Y, not -Y.

Rotation around X by -90°: Y→-Z, Z→Y.
- -Z → -Y (because Z→Y, so -Z→-Y)
- So the camera looks along -Y. ✓

After rotation around X by -90°:
- Original +X (right) → +X (unchanged)
- Original +Y (up) → -Z

So when looking along -Y (from top):
- Right = +X
- Up = -Z (pointing toward... when looking down, up is away from the ground, which is... this is confusing)

Actually, when you look down at the top face, "up" on your screen is away from you (toward the back of the cube). But in 3D, the "up" vector for the camera should be perpendicular to the view direction.

Let me just use the right-hand rule. Looking along -Y (from top toward bottom):
- Thumb along -Y, fingers curl...
- Right = ? 

Using cross product: if view = -Y and we want up to be... 

Actually, the standard convention for looking at the top face is:
- View direction = -Y (looking down)
- Up = -Z (pointing toward the back) or +Z (pointing toward the front)?

In a typical 3D viewer, when you orbit to look at the top, "up" on screen is the +Z direction (front) or -Z direction (back)?

I think the standard is: when looking at the top face, the front of the cube is at the bottom of your screen (or top, depending on convention).

Let me just derive it properly.

Standard camera: position (0, 0, 5), target (0, 0, 0), up = (0, 1, 0). View direction = (0, 0, -1). Right = (1, 0, 0).

Now, I want to look at the top face. I'll orbit the camera. Let me rotate around X by -90° (so the camera looks down):

New camera position: rotate (0, 0, 5) around X by -90°:
- x' = x = 0
- y' = y*cos(-90°) - z*sin(-90°) = 0*0 - 5*(-1) = 5
- z' = y*sin(-90°) + z*cos(-90°) = 0*(-1) + 5*0 = 0
- New position: (0, 5, 0)

View direction: from (0, 5, 0) to (0, 0, 0) = (0, -1, 0) = -Y. ✓

New up vector: rotate (0, 1, 0) around X by -90°:
- x' = 0
- y' = 1*0 - 0*(-1) = 0
- z' = 1*(-1) + 0*0 = -1
- New up: (0, 0, -1) = -Z

So when looking at the top face:
- View direction = -Y (down)
- Up (screen up) = -Z (toward the back)
- Right (screen right) = +X (right)

Clockwise from top view:
- Top of screen (-Z, back) → Right of screen (+X, right) → Bottom of screen (+Z, front) → Left of screen (-X, left) → Top of screen (-Z, back)

Wait, but the cube's top face stickers are in the XZ plane. Let me think about which direction is "up" on the top face.

Actually, when looking at the top face, the "top" of the face (in screen space) is the -Z direction (back), and the "bottom" is +Z (front). The "right" is +X, and "left" is -X.

Clockwise rotation of the top face (when looking at it from above):
- The back edge (-Z) moves to the right (+X)
- The right edge (+X) moves to the front (+Z)
- The front edge (+Z) moves to the left (-X)
- The left edge (-X) moves to the back (-Z)

So in terms of the XZ plane:
- Z_new = -X_old? No...
- A point at (-Z, i.e., z=-1) moves to +X (x=1): (-Z) → (+X)
- A point at (+X, i.e., x=1) moves to +Z (z=1): (+X) → (+Z)
- A point at (+Z, i.e., z=1) moves to -X (x=-1): (+Z) → (-X)
- A point at (-X, i.e., x=-1) moves to -Z (z=-1): (-X) → (-Z)

So: X_new = -Z_old, Z_new = X_old? Let me check:
- (x=0, z=-1): X_new = 1, Z_new = 0 → (1, 0). Back→right. ✓
- (x=1, z=0): X_new = 0, Z_new = 1 → (0, 1). Right→front. ✓
- (x=0, z=1): X_new = -1, Z_new = 0 → (-1, 0). Front→left. ✓
- (x=-1, z=0): X_new = 0, Z_new = -1 → (0, -1). Left→back. ✓

So X_new = -Z, Z_new = X for clockwise from top view.

What rotation angle around Y gives this?
- X' = X*cos(θ) + Z*sin(θ)
- Z' = -X*sin(θ) + Z*cos(θ)

For X' = -Z, Z' = X:
- cos(θ) = 0, sin(θ) = -1 → θ = -90°
- -sin(θ) = 1 → sin(θ) = -1. ✓
- Z' = -X*(-1) + 0 = X. ✓

So -90° around Y gives clockwise from top view (+Y face).

For -Y face (bottom, val=-1):
Looking along +Y (from bottom toward top):
- View direction = +Y
- Up = ?

Rotate standard camera to look along +Y:
- Rotation around X by +90°: Y→Z, Z→-Y. So -Z→+Y. ✓
- After: original +X (right) → +X (unchanged)
- Original +Y (up) → +Z

So when looking along +Y (from bottom):
- Right = +X
- Up = +Z (front)

Clockwise from bottom view:
- Top of screen (+Z, front) → Right of screen (+X, right) → Bottom of screen (-Z, back) → Left of screen (-X, left) → Top of screen (+Z, front)

In XZ plane:
- (+Z) → (+X): (x=0, z=1) → (x=1, z=0)
- (+X) → (-Z): (x=1, z=0) → (x=0, z=-1)
- (-Z) → (-X): (x=0, z=-1) → (x=-1, z=0)
- (-X) → (+Z): (x=-1, z=0) → (x=0, z=1)

So: X_new = -Z_old, Z_new = X_old? Let me check:
- (x=0, z=1): X_new = -1, Z_new = 0 → (-1, 0). Front→left. But we want front→right!

That's wrong. Let me re-check.

Clockwise from bottom view: top→right→bottom→left→top
- Top of screen = +Z (front)
- Right of screen = +X
- Bottom of screen = -Z (back)
- Left of screen = -X

So:
- +Z (top) → +X (right): (x=0, z=1) → (x=1, z=0)
- +X (right) → -Z (bottom): (x=1, z=0) → (x=0, z=-1)
- -Z (bottom) → -X (left): (x=0, z=-1) → (x=-1, z=0)
- -X (left) → +Z (top): (x=-1, z=0) → (x=0, z=1)

So X_new = Z_old? Let me check:
- (x=0, z=1): X_new = 1. Z_new = ? 

Actually, let me write the full transformation:
- X_new = Z_old? (0→1, 1→0, 0→-1, -1→0). No, Z_old for (0,1) is 1, so X_new = 1. ✓
- Z_new = -X_old? (0→-0=0, 1→-1, 0→-0=0, -1→1). For (0,1): Z_new = 0. ✓

Let me verify all:
- (x=0, z=1): X_new = 1, Z_new = 0 → (1, 0). Front→right. ✓
- (x=1, z=0): X_new = 0, Z_new = -1 → (0, -1). Right→back. ✓
- (x=0, z=-1): X_new = -1, Z_new = 0 → (-1, 0). Back→left. ✓
- (x=-1, z=0): X_new = 0, Z_new = 1 → (0, 1). Left→front. ✓

So X_new = Z, Z_new = -X for clockwise from bottom view.

What rotation angle around Y gives this?
- X' = X*cos(θ) + Z*sin(θ)
- Z' = -X*sin(θ) + Z*cos(θ)

For X' = Z, Z' = -X:
- cos(θ) = 0, sin(θ) = 1 → θ = +90°
- -sin(θ) = -1 → sin(θ) = 1. ✓
- Z' = -X*1 + 0 = -X. ✓

So +90° around Y gives clockwise from bottom view (-Y face).

Summary for Y axis:
- +Y face (top): clockwise = -90° around Y
- -Y face (bottom): clockwise = +90° around Y

This matches `sign = val > 0 ? -1 : 1`.

For Z axis:
- +Z face (front): looking along -Z (from front)
- -Z face (back): looking along +Z (from back)

+ Z face (front):
Standard camera looks along -Z, up = +Y, right = +X.

Clockwise from front view:
- Top (+Y) → Right (+X) → Bottom (-Y) → Left (-X) → Top (+Y)

In XY plane:
- (+Y) → (+X): (x=0, y=1) → (x=1, y=0)
- (+X) → (-Y): (x=1, y=0) → (x=0, y=-1)
- (-Y) → (-X): (x=0, y=-1) → (x=-1, y=0)
- (-X) → (+Y): (x=-1, y=0) → (x=0, y=1)

So: X_new = Y_old, Y_new = -X_old? Let me check:
- (x=0, y=1): X_new = 1, Y_new = 0 → (1, 0). Top→right. ✓
- (x=1, y=0): X_new = 0, Y_new = -1 → (0, -1). Right→bottom. ✓
- (x=0, y=-1): X_new = -1, Y_new = 0 → (-1, 0). Bottom→left. ✓
- (x=-1, y=0): X_new = 0, Y_new = 1 → (0, 1). Left→top. ✓

So X_new = Y, Y_new = -X for clockwise from front view.

What rotation angle around Z gives this?
- X' = X*cos(θ) - Y*sin(θ)
- Y' = X*sin(θ) + Y*cos(θ)

For X' = Y, Y' = -X:
- cos(θ) = 0, -sin(θ) = 1 → sin(θ) = -1 → θ = -90°
- sin(θ) = -1, cos(θ) = 0 → Y' = -X. ✓

So -90° around Z gives clockwise from front view (+Z face).

For -Z face (back):
Looking along +Z (from back toward front):
- View direction = +Z
- Up = +Y
- Right = ?

Rotate standard camera to look along +Z:
- This is a 180° rotation around Y (or X). 
- Rotation around Y by 180°: X→-X, Z→-Z. So -Z→+Z. ✓
- After: original +X (right) → -X (left)
- Original +Y (up) → +Y (up)

So when looking along +Z (from back):
- Right = -X (left of the cube)
- Up = +Y

Clockwise from back view:
- Top (+Y) → Right (-X) → Bottom (-Y) → Left (+X) → Top (+Y)

In XY plane:
- (+Y) → (-X): (x=0, y=1) → (x=-1, y=0)
- (-X) → (-Y): (x=-1, y=0) → (x=0, y=-1)
- (-Y) → (+X): (x=0, y=-1) → (x=1, y=0)
- (+X) → (+Y): (x=1, y=0) → (x=0, y=1)

So: X_new = -Y_old, Y_new = X_old? Let me check:
- (x=0, y=1): X_new = -1, Y_new = 0 → (-1, 0). Top→right (which is -X). ✓
- (x=-1, y=0): X_new = 0, Y_new = -1 → (0, -1). Right→bottom. ✓
- (x=0, y=-1): X_new = 1, Y_new = 0 → (1, 0). Bottom→left (which is +X). ✓
- (x=1, y=0): X_new = 0, Y_new = 1 → (0, 1). Left→top. ✓

So X_new = -Y, Y_new = X for clockwise from back view.

What rotation angle around Z gives this?
- X' = X*cos(θ) - Y*sin(θ)
- Y' = X*sin(θ) + Y*cos(θ)

For X' = -Y, Y' = X:
- cos(θ) = 0, -sin(θ) = -1 → sin(θ) = 1 → θ = +90°
- sin(θ) = 1, cos(θ) = 0 → Y' = X. ✓

So +90° around Z gives clockwise from back view (-Z face).

Summary for Z axis:
- +Z face (front): clockwise = -90° around Z
- -Z face (back): clockwise = +90° around Z

This matches `sign = val > 0 ? -1 : 1`.

So my original code is CORRECT for all three axes! Great.

Now, the only issue is updating `cubiePos` after rotation. Let me fix that.

Actually, I realize I should also update `cubiePos` for the scramble function. Let me make sure `animateLayer` also updates `cubiePos`.

Let me rewrite the file with these fixes.

Actually, I just realized there's another subtle issue. When I update `cubiePos`, I need to round the position to the nearest integer. But after rotation, the position might not be exactly at an integer due to floating point errors. I should use `Math.round()` or a similar approach.

Also, I should make sure that the center cubie (0, 0, 0) is handled correctly. It doesn't move, so its position is always (0, 0, 0).

Let me write the corrected code now.

I'll also make some other improvements:
1. Better visual appearance (subtle bevel or edges)
2. Smoother animations
3. Better UI feedback

Actually, the code is already pretty good. Let me just fix the `cubiePos` update issue and maybe add some small improvements.

Here's my plan:
1. In `doRotate`, after baking transforms, update `cubiePos[idx]` for each moved cubie.
2. In `animateLayer`, same thing.
3. Add a subtle edge/glow effect to make the cube look better.

Let me write the updated file.

Actually, for the edge effect, I can add a thin wireframe or edge geometry. But that might complicate things. Let me keep it simple and just fix the `cubiePos` issue.

One more thing: I should make sure that when the cube is scrambled, the `cubiePos` is correctly updated so that subsequent clicks work properly.

Let me also add a check: after scramble, the cube should still be solvable (which it will be, since we're just doing valid moves).

OK, let me write the final version.

Actually, I realize I should also handle the case where the user clicks on a cubie that's not on the surface (i.e., the center cubie or an interior cubie). But in a 3x3x3 Rubik's cube, all cubies are on the surface (there are no interior cubies). The center cubies (0, 0, 0) are on the surface of their respective faces.

Wait, actually, the center cubie at (0, 0, 0) is the core, and it's not visible (it's inside). In a real Rubik's cube, the core is inside and the center stickers are on the face centers. But in my 3D model, I have a cubie at (0, 0, 0) which represents the core. This cub

All done. Here's what I built:

**`/tmp/ws/index.html`** — a fully self-contained 3D Rubik's Cube page that loads `three.min.js` locally.

Features:
- **6-colour cube** with 27 cubies, each face renderable with proper colour/dark side logic
- **Click-to-rotate**: hover highlights the target layer (emissive glow), click triggers a smooth animated 90° rotation of that layer
- **Orbit-drag camera**: click-drag (mouse or touch) orbits the camera around the cube with a constrained vertical angle; colour-coded lights for depth
- **Scramble button**: performs 22 random face rotations with easing and a small inter-move pause, updating UI state (disabled during scramble)
- **Reset button**: rebuilds the solved cube from scratch
- **Touch support**: single-finger drag and tap work on mobile
- **Responsive**: listens to window resize; pixel-ratio capped at 2 for perf
- Zero network requests — only loads the local `three.min.js` and everything else is inline

Just open `index.html` in a browser (the three.min.js file is already in the same directory) and you can orbit, click faces, scramble, and reset.