The user wants me to build an interactive 3D Rubik's Cube using three.min.js which is already present in the current directory. Let me first check what's available in the directory and then build the app.

Key features needed:
1. 3D Rubik's Cube rendered with Three.js
2. Clickable face rotations (click on faces to rotate them)
3. Orbit-drag camera control
4. Scramble button

Let me check if three.min.js exists first, then build the complete single-file app.

The user wants me to create a single-page web app with an interactive 3D Rubik's Cube using three.min.js. Let me plan this out:

1. **3D Rubik's Cube**: A 3x3x3 cube with colored faces
2. **Clickable face rotations**: Click on a face to rotate that layer
3. **Orbit-drag camera**: Click and drag to orbit the camera around the cube
4. **Scramble button**: A button that randomly scrambles the cube

Let me think about the implementation:

- The Rubik's Cube consists of 27 cubies (3x3x3). Each cubie is a box with colored faces.
- For rotations, I need to group cubies that belong to a face/layer and rotate them together.
- For clickable face rotations, I'll use raycasting to detect which cubie and which face was clicked.
- Orbit controls need to be implemented manually since we can't use external files. I'll implement a simple orbit control.
- The scramble button will perform random rotations.

Let me think about the color scheme:
- Standard Rubik's Cube: White (top), Yellow (bottom), Red (front), Orange (back), Blue (right), Green (left)

For the cube representation:
- Each cubie is a mesh positioned at integer coordinates from -1 to 1
- I'll use BoxGeometry with slightly smaller than 1 size to show gaps between cubies

For rotations:
- I'll use THREE.Object3D as a pivot, attach the relevant cubies to it, rotate, then re-attach to scene
- This is the standard approach for Rubik's cube rotation in 3D

For clickable face rotations:
- Raycast to find which cubie and face normal was clicked
- Determine which layer that face belongs to
- Rotate that layer 90 degrees in the direction indicated by the face normal

For orbit camera:
- Track mouse down position, track drag
- Rotate camera around the cube center based on drag delta
- Use spherical coordinates for the camera position

Let me implement this step by step.

For the click rotation, I need to think carefully:
- When user clicks on a cubie face, I need to determine:
  1. Which cubie was clicked
  2. Which face of that cubie was clicked (the normal)
  3. Which layer to rotate (based on the cubie position and the clicked face)
  4. Which direction to rotate

Actually, for a simpler and more intuitive approach:
- Click on a face/sticker → rotate that face 90 degrees clockwise (when looking at that face)
- Or: the axis of rotation is perpendicular to the clicked face, and the direction is determined by some convention

Let me think about this differently. When you click on a sticker:
- The clicked face has a normal direction (e.g., +Y for top face)
- The rotation axis is that normal direction
- The direction: clockwise when looking from the positive side of the axis

For a 3x3 cube, if I click on the top face of a cubie at position (x, y, z):
- The rotation is around the Y axis
- Which layer? All cubies with y = 1 (the top layer)
- Direction: clockwise from top = -90 degrees around Y (or +90, need to check)

Actually, let me simplify: clicking any sticker on a face rotates that entire face 90 degrees clockwise (when looking at that face from the outside).

Let me code this up. I'll create the full implementation now.

For the face colors on each cubie, I'll use BoxGeometry with an array of 6 materials (one for each face: +X, -X, +Y, -Y, +Z, -Z).

Cubie positions range from -1 to 1 in each axis. A cubie at (1, 1, 1) would have:
- +X face (index 0): Red
- -X face (index 1): Orange
- +Y face (index 2): White
- -Y face (index 3): Yellow
- +Z face (index 4): Blue
- -Z face (index 5): Green

Wait, let me reconsider. I'll use:
- +X (right): Red
- -X (left): Orange
- +Y (top): White
- -Y (bottom): Yellow
- +Z (front): Blue
- -Z (back): Green

When rendering, only the outer faces of the cube need to be colored. Inner faces should be black.

For the rotation mechanism:
1. Create a pivot Object3D
2. Find all cubies in the target layer
3. Attach them to the pivot (preserving world transforms)
4. Animate the pivot rotation
5. Detach cubies back to scene (preserving world transforms)
6. Snap cubie positions to integer grid

For orbit controls, I'll implement manually:
- mousedown on background: start orbit
- mousemove: rotate camera around cube center
- mouseup: end orbit

Let me now write the full code.

I need to think about how to distinguish between a click for rotation vs. drag for orbit:
- If mouse is pressed and released quickly without much movement → click (rotate)
- If mouse is pressed and moved significantly → orbit

Let me implement this now. I'll make the cube visually appealing with a dark background and nice lighting.

Let me also think about the UI:
- A scramble button at the top
- Maybe some instructions

Let me write the complete code now:

```html
<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Interactive 3D Rubik's Cube</title>
    <style>
        /* styles */
    </style>
</head>
<body>
    <div id="ui">
        <button id="scramble">Scramble</button>
    </div>
    <script src="three.min.js"></script>
    <script>
        // all the JS
    </script>
</body>
</html>
```

Now let me think about the detailed implementation.

For the cubie geometry, I'll use a slightly rounded box or just a regular box with black edges. I'll use a scale slightly less than 1 so there are gaps.

Actually, let me use a simpler approach: create each cubie as a rounded-looking box. I can use BoxGeometry with scale 0.93 or so, and put black inner material.

For face detection on raycast, I'll use the face normal to determine which face was clicked.

Let me think about the rotation direction. When clicking on a face:
- The face normal tells us the axis (X, Y, or Z)
- The rotation should be 90° clockwise when looking at that face from outside

For example, clicking the +Y face (top):
- Rotate around Y axis
- Clockwise from top view = rotate -90° around Y (in right-handed coords, +Y up, this is clockwise from above)

Wait, in THREE.js (right-handed system):
- +X is right, -X is left
- +Y is up, -Y is down  
- +Z is toward camera (out of screen), -Z is away

Rotation direction for clockwise when looking at face from outside:
- Looking at +X face from +X direction: clockwise = rotation around +X axis
- Looking at -X face from -X direction: clockwise = rotation around -X axis = -rotation around +X
- Looking at +Y face from +Y direction: clockwise = rotation around +Y axis
- etc.

Actually, the standard convention: a positive rotation around an axis in THREE.js follows the right-hand rule. So:
- +90° around +Y means rotating from +Z toward +X (looking from +Y down)

For "clockwise when looking at the face from outside":
- Top face (+Y): looking from +Y down, clockwise = -90° around Y (because in THREE.js, +rotation goes counter-clockwise from the viewer's perspective looking along the axis)

Hmm, let me think again. In THREE.js:
- Positive rotation around Y axis follows right-hand rule: fingers curl from +Z to +X
- Looking from +Y toward origin, +Z is "forward" (away from viewer if Y is up), +X is "right"
- So +Y rotation goes from +Z toward +X (counter-clockwise from top view)

So clockwise from top = -90° around Y.

Let me just use a lookup table for the rotation angles:
- Click +X face: rotate +90° around X
- Click -X face: rotate -90° around X  
- Click +Y face: rotate -90° around Y
- Click -Y face: rotate +90° around Y
- Click +Z face: rotate -90° around Z
- Click -Z face: rotate +90° around Z

Actually, I realize I need to be more careful. The "layer" to rotate is determined by which cubie was clicked and which face. For example, clicking the +X face of a cubie at (1, 0, 0) means rotating the +X layer (all cubies with x ≈ 1). But clicking the +X face of a cubie at (0, 0, 0) would mean rotating the middle layer along X? That seems odd for a Rubik's cube.

I think the intuitive behavior is:
- Click on an OUTER face (a face that's on the surface of the cube) → rotate that outer layer
- Clicking an inner face doesn't make sense because inner faces aren't visible

So I'll only allow clicking on visible outer faces. The layer to rotate is determined by the cubie's position along the clicked face's normal axis.

For the layer: if I click a face with normal +X on a cubie at position (x, y, z), I rotate the layer at x (which should be ±1 or 0). Since only outer faces are visible, x would be 1 (for +X normal).

Let me now write the full code. I'll be careful with the implementation.

For the animation of rotations, I'll use a simple animation queue:
- When a rotation is triggered, add it to a queue
- If no rotation is in progress, start animating the first one
- Use lerp/easing for smooth animation
- After animation completes, snap positions and update the queue

Here's my plan for the cubie structure:
- Each cubie is a THREE.Mesh with BoxGeometry(0.93, 0.93, 0.93)
- Materials array: [right(+X), left(-X), top(+Y), bottom(-Y), front(+Z), back(-Z)]
- Outer faces get their color, inner faces get black (0x1a1a1a)

For determining if a face is outer:
- A cubie at (x, y, z) has outer +X face if x > 0
- Has outer -X face if x < 0
- Has outer +Y face if y > 0
- etc.

Actually, I said range is -1 to 1. So:
- x = 1: outer +X face
- x = -1: outer -X face
- x = 0: no outer X faces
- y = 1: outer +Y face
- y = -1: outer -Y face
- z = 1: outer +Z face
- z = -1: outer -Z face

Let me use a slightly different range. The cubie positions should be at -1, 0, 1 (in world units, with spacing of 1). So the positions are at integers -1, 0, 1.

OK, I think I have enough to write the code now. Let me be thorough and write a clean implementation.

One more consideration: for the orbit controls, I need to make sure clicks on the cube (for rotation) don't accidentally trigger orbit. I'll use a small movement threshold.

Let me also add some nice visual touches:
- Dark background
- Ambient + directional lighting for nice shadows on the cube faces
- Maybe a subtle shadow/reflection effect
- The scramble button should look good

Let me write the complete code now. I'll aim for clean, well-structured code.

For the rotation animation, I'll use:
```
let animationProgress = 0;
const ANIMATION_SPEED = 0.05; // adjust for speed

// In animation loop:
if (isAnimating) {
    animationProgress += ANIMATION_SPEED;
    if (animationProgress >= 1) {
        animationProgress = 1;
        isAnimating = false;
        // finalize rotation
    }
    const angle = targetAngle * easeInOut(animationProgress);
    pivot.rotation[axis] = angle;
}
```

Let me now write everything in one go.

Actually, for the face normal from raycast, I need to get the face normal in world space. I can use the intersect info's face.normal and transform it by the object's world matrix.

Here's the approach for determining rotation from a click:
1. Raycast to find clicked cubie and face
2. Get the face normal in world space
3. Determine the rotation axis from the face normal (which axis has the largest absolute value)
4. Determine the layer from the cubie's position along that axis
5. Determine the rotation direction based on the face normal sign

For the rotation direction lookup:
```
const rotationMap = {
    '1,0,0': { axis: 'x', angle: -Math.PI/2 },   // clicking +X face → rotate X layer
    '-1,0,0': { axis: 'x', angle: Math.PI/2 },    // clicking -X face
    '0,1,0': { axis: 'y', angle: Math.PI/2 },     // clicking +Y face
    '0,-1,0': { axis: 'y', angle: -Math.PI/2 },   // clicking -Y face
    '0,0,1': { axis: 'z', angle: -Math.PI/2 },    // clicking +Z face
    '0,0,-1': { axis: 'z', angle: Math.PI/2 },    // clicking -Z face
};
```

Wait, I need to double-check the rotation directions. Let me think about this more carefully.

Standard Rubik's Cube notation (when looking at a face):
- R (right face, +X): clockwise = +90° around X (right-hand rule, thumb points in +X direction, fingers curl from +Y to +Z... no wait)

Hmm, in right-hand rule:
- Thumb points in +X direction
- Fingers curl from +Y toward +Z

So +90° around X rotates +Y toward +Z.

For a Rubik's cube with +X as the right face:
- Looking at the right face from outside (+X direction toward origin)
- +Y is up, +Z is... toward the front (away from viewer if we look from +X)
- Wait, this is getting confusing. Let me think of it differently.

If I look at the right face (+X) from the outside:
- Up = +Y
- Right (from my perspective) = -Z (because +Z is forward, and I'm looking from +X, so +Z is to my left)
- No wait, I need to set up a proper coordinate system for the viewer.

Viewer looking at +X face (from positive X toward origin):
- Viewer's up = +Y (world up)
- Viewer's right = +Z... or -Z?

The viewer is at +X looking toward -X. The world +Y is up. Using cross product:
- Forward = -X (looking direction)
- Up = +Y
- Right = Forward × Up = (-X) × (+Y) = -Z (since X × Y = Z, so (-X) × Y = -Z)

Hmm, wait. In a right-handed system:
- X × Y = Z
- Y × Z = X
- Z × X = Y

So (-X) × Y = -(X × Y) = -Z

So the viewer's right = -Z. That means:
- Looking at +X face: right = -Z, up = +Y
- Clockwise rotation = from up toward right = from +Y toward -Z = that's a -90° rotation around X (because +X rotation goes from +Y toward +Z)

So clicking +X face → clockwise = -90° around X. Let me update:

```
'1,0,0': { axis: 'x', angle: -Math.PI/2 },
```

For -X face (looking from -X toward origin):
- Forward = +X
- Up = +Y
- Right = (+X) × (+Y) = +Z
- Clockwise = from +Y toward +Z = that's a +90° rotation around X

```
'-1,0,0': { axis: 'x', angle: Math.PI/2 },
```

For +Y face (looking from +Y toward origin):
- Forward = -Y
- Up = +Z
- Right = (-Y) × (+Z) = -(Y × Z) = -X
- Wait, the "up" for the viewer looking at the top face... This is tricky because the camera orientation changes.

Actually, let me use a different approach. Let me define what "clockwise" means for each face and then verify visually.

Standard Rubik's cube (with white on top, green in front, red on right):
- R (right face clockwise): +X rotation? Let me check. Right face has +X normal. Clockwise when looking at it. +Y is up, and clockwise means top goes to right. So the top edge (+Y) moves toward the "right" of the viewer, which is -Z. So it's a rotation that moves +Y toward -Z. In right-hand rule around X: +rotation goes from +Y toward +Z. So -rotation goes from +Y toward -Z. That's -90° around X.

OK so:
- Click +X face: rotate -90° around X (R move)
- Click -X face: rotate +90° around X (L' which is L inverse, or L move depends on convention)

Hmm, for L (left face clockwise): the left face has -X normal. Looking at it from -X:
- +Y is up, +Z is... to the right (as computed earlier, right = +Z when looking from -X)
- Clockwise: top goes right, so +Y toward +Z
- +90° around X goes from +Y toward +Z ✓

So:
- Click -X face: rotate +90° around X (L move)

For U (top face clockwise, +Y face):
Looking from +Y down:
- +Z is "forward" (toward front of cube)
- +X is "right"
- Clockwise: front goes right, +Z toward +X
- +90° around Y: goes from +Z toward +X ✓

Wait, let me check: +Y rotation, right-hand rule, thumb along +Y, fingers curl from +Z toward +X. So +90° around Y = +Z → +X. 

Looking at top face from +Y:
- +Z is toward the front
- +X is toward the right
- Clockwise: the front edge moves right = +Z → +X = +90° around Y ✓

So:
- Click +Y face: rotate +90° around Y (U move)

For D (bottom face clockwise, -Y face):
Looking from -Y up:
- +Z is "forward" 
- -X is "right" (need to verify: forward = +Y, up = +Z, right = +Y × +Z = +X... wait)

Viewer at -Y looking toward origin (+Y direction):
- Forward = +Y
- What's "up" for this viewer? In standard viewing, if you look at the bottom of the cube, "up" would be... well, the viewer's orientation matters.

Let me use a more systematic approach. I'll define a helper that computes the clockwise rotation direction based on the face normal.

Actually, for simplicity, let me just hardcode the directions and make sure they look right visually. I can adjust if needed.

Let me define:
- Clicking any outer face rotates that face 90° clockwise (when looking at it from outside)

For each axis and sign:
- X+, Y+, Z+, X-, Y-, Z-

Using the right-hand rule and the viewer perspective approach:

Axis X, sign +1 (right face):
- Looking from +X: viewer up = +Y, viewer right = -Z
- Clockwise = from up toward right = from +Y toward -Z
- Rotation around X that does +Y → -Z: this is -90° (since +90° does +Y → +Z)
- Angle: -π/2

Axis X, sign -1 (left face):
- Looking from -X: viewer up = +Y, viewer right = +Z
- Clockwise = +Y → +Z
- Rotation around X that does +Y → +Z: +90°
- Angle: +π/2

Axis Y, sign +1 (top face):
- Looking from +Y: I need to figure out viewer up and right
- The viewer is at +Y looking toward -Y
- Standard view: up = +Z? No, that doesn't make sense for a typical view.
- Actually, in 3D graphics, when looking along -Y, the "up" is typically +Z or depends on the camera's up vector.
- For determining clockwise, I'll use: when looking from +Y toward origin, +Z is "up" for the viewer, and +X is "right"
  - Wait, that gives: Forward = -Y, Up = +Z, Right = (-Y) × (+Z) = -(Y × Z) = -X
  - Hmm, that means +X is to the left, not right.
  
Let me try Up = -Z (which makes more sense for viewing the top face, since +Z is the front of the cube):
  - Forward = -Y, Up = -Z (pointing toward the back of the cube, which looks "up" when viewing from top)
  - Right = (-Y) × (-Z) = Y × Z = X
  - So right = +X. Good.
  - Clockwise = from -Z toward +X
  - Rotation around Y: +90° goes from +Z toward +X (right-hand rule). That's from +Z toward +X, not from -Z toward +X.
  - -90° goes from +X toward +Z, which is the opposite of what I want.
  
Hmm, this is getting complicated. Let me try yet another approach.

For the top face (+Y normal), looking from above:
- The cube's +Z face is the "front" (closest to the viewer when the cube is in standard orientation)
- The cube's +X face is the "right" side
- Clockwise when looking at the top: the front edge (+Z face's top edge) moves to the right (+X direction)
- So +Z edge moves toward +X
- In terms of rotation: this is +90° around Y (right-hand rule: thumb along +Y, fingers curl from +Z toward +X) ✓

So clicking +Y face → +90° around Y.

For the bottom face (-Y normal), looking from below:
- The viewer is below the cube looking up
- The front is still +Z, but from below, the front appears "reversed"
- Actually, let me think of it as: the bottom face's clockwise means the +Z face's bottom edge moves... 

OK, I think the standard convention is:
- D (bottom face clockwise when looking at it from below): looking from -Y toward +Y
  - The front (+Z) bottom edge should move right from the viewer's perspective
  - From below, +X is to the right, +Z is forward
  - Wait, let me reconsider the viewer orientation.
  
  Viewer at -Y looking toward origin:
  - Forward = +Y
  - If we keep "up" as +Z (the front of the cube), then:
  - Right = (+Y) × (+Z) = +X
  - So from below: up = +Z (front), right = +X
  - Clockwise = from +Z toward +X
  - Rotation that does +Z → +X: +90° around Y
  
  Hmm, but that's the same as the top face? That can't be right for a Rubik's cube.

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

When looking at the BOTTOM of the cube from below:
- The cube's +Z face is the front
- But from below, the front of the cube appears at the TOP of your view
- The +Z direction points upward in your view
- The +X direction points to the RIGHT in your view
- So clockwise rotation: top of your view (+Z) moves right (+X)
- That's +Z → +X around Y = +90° around Y

But when looking at the TOP of the cube from above:
- The front of the cube (+Z) is at the BOTTOM of your view
- Wait, this depends on how the viewer is oriented.

I think the issue is that "up" for the viewer changes depending on whether you're looking from above or below. Let me be more careful.

From above (+Y looking toward origin):
- The viewer's head is at +Y
- "Up" for the viewer... well, the viewer is looking down, so their up would be... hmm, this is getting weird.

Let me just use a mathematical approach. The clockwise rotation angle for a face with normal n is:
- angle = π/2 (90°) in the direction that follows the right-hand rule with the normal as the axis

So if the face normal is +Y, the clockwise rotation (from the outside looking in) is +90° around +Y.
If the face normal is -Y, the clockwise rotation is +90° around -Y = -90° around +Y.

Let me verify:
- +Y face: +90° around Y → from +Z toward +X ✓ (front edge moves right)
- -Y face: -90° around Y → from +X toward +Z → from +Z toward -X

For the bottom face, looking from -Y:
- Front (+Z) bottom edge moves... from the bottom view, what's clockwise?
- If the front edge moves toward -X (left), that would be clockwise from the bottom view
- -90° around Y: +Z → -X ✓

That seems right. Let me go with this convention:
- Clockwise around axis = positive angle around that axis (right-hand rule)
- The rotation angle is determined by the face normal direction

So:
- Normal (1,0,0) → rotate +90° around X
- Normal (-1,0,0) → rotate +90° around (-X) = -90° around X
- Normal (0,1,0) → rotate +90° around Y
- Normal (0,-1,0) → rotate +90° around (-Y) = -90° around Y
- Normal (0,0,1) → rotate +90° around Z
- Normal (0,0,-1) → rotate +90° around (-Z) = -90° around Z

Wait, but I need to verify this makes sense for a Rubik's cube.

R move (right face, +X, clockwise from right):
- The right face rotates clockwise when looking at it from the right
- From right: up = +Y, the face's top edge moves right
- In 3D, from the right, +Y is up and -Z is rightward
- So top (+Y) moves toward -Z
- +90° around X: from +Y toward +Z... that's the OPPOSITE direction

So +90° around X is NOT clockwise for the right face. It's counter-clockwise!

Let me reconsider. Right-hand rule: thumb along +X, fingers curl from +Y toward +Z.
From the right (+X) looking at the cube:
- +Y is up
- +Z is... to the left (because I'm looking from +X, and +Z is the front)

So +90° around X rotates +Y (up) toward +Z (left), which is COUNTER-clockwise from the right view.

Therefore, clockwise from the right = -90° around X.

OK so my earlier analysis was right. Let me redo:

- Click +X face (right): -90° around X (R move, clockwise)
- Click -X face (left): +90° around X (L move, clockwise from left)
- Click +Y face (top): Let me redo...
  - From top: +Z is front, +X is right
  - +90° around Y: from +Z toward +X (front → right)
  - This IS clockwise from top ✓
  - So +Y: +90° around Y ✓
  
Wait, I think I made an error earlier. Let me verify again.

Right-hand rule for Y axis: thumb along +Y, fingers curl from +Z toward +X.
- Looking from +Y (top) toward origin
- +Z is in the direction away from me (front of cube)
- +X is to my right
- Rotation +Z → +X: the front moves right → that IS clockwise ✓

So +Y → +90° around Y is correct.

- Click -Y face (bottom):
  - From bottom (-Y looking toward origin)
  - +Z is the front of the cube
  - But from below, the front is "above" in my field of view
  - Actually let me think about it differently.
  - Thumb along -Y, fingers curl from +X toward +Z
  - So +90° around (-Y) = -90° around Y = +X → +Z
  - From bottom view: +X is right, +Z is front (which is "up" in the view from below)
  - So right moves to front/up: that's counter-clockwise from bottom view
  
  Hmm, I need to think about this more carefully. From below:
  - The viewer is at -Y looking up at the cube
  - "Up" in the viewer's field of view = the direction of +Z (front of cube)
  - "Right" in the viewer's field of view = +X (since right-hand system: looking along +Y, +X is right)
  - Wait, I said "looking from -Y toward origin" which means looking along +Y direction
  - Up = +Z (front of cube), Right = +X
  - Clockwise = from +Z toward +X (front → right)
  - Rotation +Z → +X: +90° around Y
  
  But earlier I said -Y face → -90° around Y... Let me reconsider.

  Actually wait, from the BOTTOM of the cube, what does "clockwise" mean?
  - Standard Rubik's cube notation: D (down face clockwise) = looking at the bottom face from below
  - The front edge of the bottom face moves to the RIGHT
  - From below: front = +Z, right = +X
  - So +Z → +X
  - +90° around Y: +Z → +X ✓
  
  So D (bottom clockwise) = +90° around Y.
  
  But wait, that means both U (top clockwise) and D (bottom clockwise) are +90° around Y? That can't be right for a Rubik's cube.
  
  The issue is that "clockwise" is relative to the viewer's perspective. When you look at the top face, clockwise is one direction. When you look at the bottom face (from below), clockwise is the opposite direction in terms of the rotation axis.
  
  Think of it this way: if you rotate the top face clockwise (from above) and the bottom face clockwise (from below), they should rotate in opposite directions around the Y axis.
  
  From above (+Y): clockwise = +90° around Y
  From below (-Y): clockwise = also +90° around... wait, let me think again.
  
  From below, looking up:
  - The front edge (+Z direction) should move to the right (+X direction) for clockwise
  - +90° around Y: +Z → +X ✓
  
  Hmm, but this gives the same rotation for both top and bottom. That means if I rotate both faces 90° with the same rotation, both the top front edge moves right AND the bottom front edge moves right. That's actually correct! 
  
  Wait no, that doesn't make sense physically. If I turn the top face clockwise, the top front sticker moves right. If I turn the bottom face clockwise (from below), the bottom front sticker also moves right. These are independent rotations and they use the same axis rotation direction.
  
  OK I think I was overcomplicating this. Let me just use:
  - Clockwise from outside of face = +90° around the face normal
  - So the rotation axis = face normal, angle = +π/2
  
  - Click face with normal (1,0,0): rotate π/2 around X
  - Click face with normal (-1,0,0): rotate π/2 around -X = -π/2 around X
  - Click face with normal (0,1,0): rotate π/2 around Y
  - Click face with normal (0,-1,0): rotate π/2 around -Y = -π/2 around Y
  - Click face with normal (0,0,1): rotate π/2 around Z
  - Click face with normal (0,0,-1): rotate π/2 around -Z = -π/2 around Z

  Let me verify with R move (right face, +X):
  - Rotate π/2 around X
  - Right-hand rule: thumb along +X, fingers curl +Y → +Z
  - From right view: +Y is up, +Z is left
  - So rotation is up → left = COUNTER-clockwise from right view
  
  That's NOT clockwise! So my convention is wrong.
  
  OK let me try the opposite: clockwise from outside = -π/2 around face normal.
  
  R move (+X face):
  - Rotate -π/2 around X
  - Fingers curl +Z → +Y (opposite of before)
  - From right view: left → up = CLOCKWISE ✓
  
  So the convention is: clockwise from outside = -π/2 around the face normal.

  Let me redo:
  - Normal (1,0,0): -π/2 around X → +Y → -Z → from right view: up → right ✓ clockwise
  - Normal (-1,0,0): -π/2 around -X = +π/2 around X → +Y → +Z → from left view: up → left = clockwise from left view
  - Normal (0,1,0): -π/2 around Y → +Z → -X → from top view: front → left... hmm, is that clockwise?
    - From top: front (+Z) is bottom of view, right (+X) is right of view
    - -π/2 around Y: +Z → -X = front → left = counter-clockwise
  
  Hmm, that's wrong. From top view, clockwise should be front → right = +Z → +X = +π/2 around Y.

  So for +Y face, clockwise = +π/2, not -π/2. The sign depends on the axis!
  
  I think the issue is that the "right-hand rule" gives counter-clockwise rotation when looking from the positive direction of the axis. So clockwise = -θ. But this means:
  - For +Y face: clockwise = -π/2 around Y
  - But we saw that +π/2 around Y gives front → right = clockwise from top
  
  Wait, let me re-examine. The right-hand rule:
  - Thumb along +Y
  - Fingers curl from +Z toward +X
  - This means +90° rotation maps +Z direction to +X direction
  - From top view: +Z (front) maps to +X (right)
  - Front → right is CLOCKWISE from top view ✓
  
  So +π/2 around Y IS clockwise for the top face. Good.
  
  But for the right face (+X):
  - Thumb along +X
  - Fingers curl from +Y toward +Z
  - +90° maps +Y to +Z
  - From right view: +Y is up, +Z is... let me think. When I look at the cube from +X (right side):
    - I'm looking in the -X direction
    - +Y is up
    - +Z is... my left (because in right-hand system, if I face -X with +Y up, then +Z is to my left)
    - So +Y → +Z = up → left = COUNTER-clockwise
  
  So +π/2 around X is counter-clockwise from the right view, meaning clockwise = -π/2 around X.
  
  Why is +π/2 clockwise for Y but -π/2 clockwise for X?
  
  The answer is that the "viewer perspective" rotates differently for different axes. The relationship between the axis rotation and the perceived rotation direction depends on the axis.
  
  Let me think about it more systematically. For a viewer looking at a face with normal n:
  - The viewer looks in direction -n
  - The viewer's "up" direction needs to be defined
  - The perceived clockwise direction depends on both the rotation axis and the viewer's orientation

  I think the cleanest approach is to define the rotation direction empirically:
  - R (right face clockwise): -π/2 around X
  - L (left face clockwise): +π/2 around X
  - U (top face clockwise): +π/2 around Y
  - D (bottom face clockwise): -π/2 around Y
  - F (front face clockwise): -π/2 around Z (wait, let me check)
  - B (back face clockwise): +π/2 around Z

  Let me verify F (front face, +Z, clockwise from front):
  - From front: +Y is up, +X is right
  - Clockwise: up → right = +Y → +X
  - Around Z axis: right-hand rule, +Z rotation goes from +X toward +Y
  - So -Z rotation goes from +Y toward +X ✓
  - F = -π/2 around Z ✓

  Let me verify B (back face, -Z, clockwise from back):
  - From back: looking in +Z direction
  - +Y is up, -X is right (because facing +Z: right = (+Z) × (+Y) = -X)
  - Wait: forward = +Z, up = +Y, right = (+Z) × (+Y) = -(Y × Z) = -X
  - Clockwise: up → right = +Y → -X
  - Around -Z: +rotation around -Z = -rotation around Z
  - -Z rotation: from +Y toward +X (opposite of +Z which is +X → +Y)
  - Hmm, let me reconsider. +π/2 around -Z:
    - Thumb along -Z, fingers curl from +X toward -Y... no wait.
    - +π/2 around -Z: thumb along -Z, fingers curl from... 
    - +Z rotation: +X → +Y
    - -Z rotation: +Y → +X (opposite)
    - So +π/2 around -Z: +X → -Y... hmm, this is getting confusing.
    
  Let me just use: rotation around -Z with angle θ = rotation around Z with angle -θ.
  
  So +π/2 around -Z = -π/2 around Z = +Y → +X
  
  From back view: +Y is up, -X is right
  +Y → +X means... +Y is up and +X is -(-X) = left
  So up → left = counter-clockwise from back view
  
  That's wrong. Clockwise from back = up → right = +Y → -X
  
  Rotation that does +Y → -X:
  - Around Z: +Y → -X is a -90° (or +270°) rotation? Let me check.
  - +Z rotation: +X → +Y → -X → -Y → +X (90° increments)
  - So +Y → -X = +90° around Z (one step in the +Z cycle)
  
  So B (back clockwise) = +π/2 around Z.

  Let me verify: +π/2 around Z rotates +X → +Y → -X. So +Y → -X. From back view: +Y is up, -X is right. Up → right = clockwise ✓.

  Summary:
  - Click +X face: -π/2 around X
  - Click -X face: +π/2 around X
  - Click +Y face: +π/2 around Y
  - Click -Y face: -π/2 around Y
  - Click +Z face: -π/2 around Z
  - Click -Z face: +π/2 around Z

  Let me verify once more:
  - R (+X, -π/2 X): +Y → -Z (up → left from right view) = clockwise ✓
  - L (-X, +π/2 X): +Y → +Z (up → right from left view) = clockwise ✓
  - U (+Y, +π/2 Y): +Z → +X (front → right from top view) = clockwise ✓
  - D (-Y, -π/2 Y): +X → +Z... wait, -π/2 Y is the reverse of +π/2 Y.
    - +π/2 Y: +Z → +X → -Z → -X → +Z
    - -π/2 Y: +X → +Z → -X → -Z → +X
    - So -π/2 Y: +X → +Z
    
    From bottom view: +X is right, +Z is front (which is "up" in view from below)
    Right → front/up = counter-clockwise
    
    Hmm, that doesn't seem right. D (bottom clockwise) should have the bottom-right edge move to the back.
    
    From bottom view: 
    - Looking up from -Y
    - "Up" in my view = +Z (front of cube), "right" = +X
    - Clockwise: front/up → right = +Z → +X
    
    Wait, I need to re-examine the bottom view orientation.
    
    Viewer at -Y looking toward origin:
    - Forward = +Y
    - What is "up" for this viewer? In a natural viewing position, if you look up at the bottom of a cube, the "front" of the cube (+Z face) would be at the TOP of your view. So "up" in your view = +Z.
    - "Right" = Forward × Up = (+Y) × (+Z) = +X
    - Clockwise = from +Z toward +X (up in view → right in view)
    - Rotation: +Z → +X
    
    -π/2 around Y: +X → +Z → -X → -Z → +X
    So +Z → -X (not +Z → +X). That's wrong.
    
    +π/2 around Y: +Z → +X ✓
    
    So D (bottom clockwise) = +π/2 around Y... but that's the same as U (top clockwise). That seems odd.
    
    Actually, thinking about it: U and D rotate around the SAME axis but affect different layers. U rotates the top layer (y=1), D rotates the bottom layer (y=-1). The rotation direction around Y is the same (+π/2), but they affect different cubies.
    
    In Rubik's cube notation:
    - U = clockwise rotation of top face = +π/2 around Y (looking from +Y)
    - D = clockwise rotation of bottom face = +π/2 around Y (looking from -Y)
    
    When you rotate +π/2 around Y:
    - Top layer (y=1): +Z face moves to +X position (front → right) = clockwise from top ✓
    - Bottom layer (y=-1): +Z face moves to +X position = but from below, this looks counter-clockwise
    
    Hmm, so U and D are NOT the same rotation. D should be -π/2 around Y.
    
    Let me re-examine from below:
    Viewer at -Y looking toward origin (+Y direction):
    - My eye is below the cube
    - The +Z face (front) is... where? In my field of view, the front of the cube is at the TOP (because I'm looking up and the front of the cube is closer to my eyes than the back).
    - Wait, actually, the cube center is at origin. The front face (+Z) is at z=1. The back face (-Z) is at z=-1. I'm at y=-something looking toward origin.
    - The +Z face is in front of the cube from the standard viewing angle, but from below, it's still the "front" face.
    
    OK I think the issue is defining "clockwise" for the bottom face. Let me use Rubik's cube standard notation:
    - D = clockwise when looking at the bottom face from below
    - Standard cube: white on top, green in front, red on right
    - Looking at bottom (yellow face): green (front) bottom edge moves to the right (red side)
    - So the green bottom edge moves toward the red side
    - Green is +Z, red is +X
    - Bottom front edge (+Z at y=-1) moves to +X position
    - This is +Z → +X rotation
    
    +π/2 around Y: +Z → +X ✓
    
    So D = +π/2 around Y. And U = +π/2 around Y too? That can't be right...
    
    Wait, let me reconsider U:
    - U = clockwise when looking at top face from above
    - Looking at white face from above: green (front) top edge moves to the right (red side)
    - Green is +Z, red is +X
    - Top front edge (+Z at y=1) moves to +X position
    - +Z → +X
    - +π/2 around Y: +Z → +X ✓
    
    So U = +π/2 around Y and D = +π/2 around Y.
    
    BUT they rotate different layers! U rotates cubies at y=1, D rotates cubies at y=-1. The rotation axis and angle are the same, but the set of cubies affected is different.
    
    Wait, that's actually correct! In Rubik's cube notation, U and D are both clockwise rotations when looking at their respective faces. And both correspond to +π/2 around Y. They just affect different layers.
    
    Hmm, but in standard cube notation, U and D' are often used together because they rotate in the same direction (both +Y rotation), and U' and D rotate in the same direction (-Y rotation).
    
    Actually, I think I've been confusing myself. Let me just use standard cube notation conventions:
    - U (up face clockwise): +90° around Y axis
    - D (down face clockwise): -90° around Y axis (because from below, clockwise appears opposite from above)
    
    No wait, I just showed that D from below with clockwise = +Z → +X = +90° around Y. Let me reconsider.
    
    Actually, I think the issue is that "from below" doesn't mean the same thing as "from above" in terms of what direction is "clockwise."
    
    Imagine a clock on the top face and a clock on the bottom face. If you look at the top clock from above, it shows a certain orientation. If you look at the bottom clock from below, the numbers would appear mirrored.
    
    For a Rubik's cube, "clockwise" for U means: imagine a clock painted on the top face, and rotate the face so the clock hands move clockwise (as you see them from above).
    "Clockwise" for D means: imagine a clock painted on the bottom face, and rotate so the clock hands move clockwise (as you see them from below).
    
    A clock on the bottom face, when viewed from below:
    - 12 o'clock = front of cube (+Z direction)
    - 3 o'clock = right side (+X direction)
    - 6 o'clock = back (-Z direction)
    - 9 o'clock = left side (-X direction)
    - Clockwise: 12 → 3 → 6 → 9 = front → right → back → left
    - So +Z → +X → -Z → -X
    - This is +90° around Y (fingers curl +Z → +X)
    
    A clock on the top face, when viewed from above:
    - 12 o'clock = front of cube (+Z direction)... 
    - Wait, from above, the front of the cube is the direction closest to the viewer. If I'm at +Y looking down, the front of the cube (+Z) is... 
    - This depends on how I'm oriented. If I'm standing and looking down at the cube, the "front" of the cube (the +Z face) would be the edge closest to me, which would be at the bottom of my field of view.
    - So: 12 o'clock = back (-Z), 3 o'clock = right (+X), 6 o'clock = front (+Z), 9 o'clock = left (-X)
    - Clockwise: 12 → 3 → 6 → 9 = back → right → front → left
    - So -Z → +X → +Z → -X
    - That's -90° around Y (opposite of +Z → +X)
    
    So U (top clockwise) = -90° around Y!
    
    And D (bottom clockwise) = +90° around Y!
    
    These are OPPOSITE rotations. That makes physical sense - if you rotate the top face clockwise (from above) and the bottom face clockwise (from below), they rotate in opposite directions.
    
    Let me redo all the rotations with this understanding:
    
    From above (+Y), top face clock: 12=back(-Z), 3=right(+X), 6=front(+Z), 9=left(-X)
    - Clockwise: -Z → +X → +Z → -X
    - -90° around Y ✓ (since +90° goes +Z → +X)
    
    From below (-Y), bottom face clock: 12=front(+Z), 3=right(+X), 6=back(-Z), 9=left(-X)
    - Clockwise: +Z → +X → -Z → -X
    - +90° around Y ✓
    
    From right (+X), right face clock: I need to figure out the clock orientation
    - Looking from +X toward origin
    - Up = +Y (world up)
    - What's the equivalent of "front" for this face? The +Z face
    - From right view: +Z is to my LEFT, -Z is to my RIGHT
    - So: 12=up(+Y), 3=right(-Z), 6=down(-Y), 9=left(+Z)
    - Clockwise: +Y → -Z → -Y → +Z
    - Rotation: +Y → -Z
    - Around X: +90° goes +Y → +Z, so -90° goes +Y → -Z ✓
    - R = -90° around X ✓
    
    From left (-X), left face clock:
    - Looking from -X toward origin
    - Up = +Y
    - From left view: +Z is to my RIGHT, -Z is to my LEFT
    - So: 12=up(+Y), 3=right(+Z), 6=down(-Y), 9=left(-Z)
    - Clockwise: +Y → +Z → -Y → -Z
    - Rotation: +Y → +Z
    - +90° around X: +Y → +Z ✓
    - L = +90° around X ✓
    
    From front (+Z), front face clock:
    - Looking from +Z toward origin
    - Up = +Y
    - From front view: +X is to my RIGHT
    - So: 12=up(+Y), 3=right(+X), 6=down(-Y), 9=left(-X)
    - Clockwise: +Y → +X → -Y → -X
    - Rotation: +Y → +X
    - Around Z: +90° goes +X → +Y, so -90° goes +Y → +X ✓
    - F = -90° around Z ✓
    
    From back (-Z), back face clock:
    - Looking from -Z toward origin
    - Up = +Y
    - From back view: +X is to my LEFT (because I'm facing +Z, and +X × +Y = +Z, so +X is to my left when facing +Z)
    - So: 12=up(+Y), 3=right(-X), 6=down(-Y), 9=left(+X)
    - Clockwise: +Y → -X → -Y → +X
    - Rotation: +Y → -X
    - Around Z: +90° goes +X → +Y, so +90° goes +Y → -X ✓
    - B = +90° around Z ✓
    
    Final rotation mapping:
    - Click +X face: -π/2 around X
    - Click -X face: +π/2 around X
    - Click +Y face: -π/2 around Y  (CORRECTION from earlier)
    - Click -Y face: +π/2 around Y
    - Click +Z face: -π/2 around Z
    - Click -Z face: +π/2 around Z
    
    So the pattern is:
    - For each axis: the +side is -π/2, the -side is +π/2
    - This means: angle = -sign * π/2 where sign is the sign of the face normal component
    
    Or equivalently: angle = -π/2 for positive normal, +π/2 for negative normal
    
    This is cleaner than I thought! Let me just use:
    
    For each axis (x, y, z):
    - Face normal component = +1 → rotation angle = -π/2
    - Face normal component = -1 → rotation angle = +π/2
    
    So:
    ```
    const angle = -Math.sign(normalComponent) * Math.PI / 2;
    ```
    
    Great, that's a clean formula. Now let me write the actual code.

For the scramble, I'll perform a series of random face rotations (like 20-25 moves). I'll queue them up and animate them quickly.

Let me now write the complete implementation. I'll be careful about:
1. Creating cubies with proper colors
2. Handling click detection (distinguishing click from drag)
3. Animated rotations using pivot
4. Orbit camera controls
5. Scramble functionality

Let me code this up now.

For the cubie geometry, I'll use BoxGeometry with 6 materials:
- Each cubie has 6 faces with colors based on position
- Inner faces are black
- Outer faces have the cube's color

BoxGeometry face order in THREE.js: [+X, -X, +Y, -Y, +Z, -Z]

Colors:
- +X (right): Red (0xff0000 or similar)
- -X (left): Orange (0xff8800)
- +Y (top): White (0xffffff)
- -Y (bottom): Yellow (0xffff00)
- +Z (front): Blue (0x0000ff)
- -Z (back): Green (0x00ff00)

Actually, let me use more standard Rubik's cube colors:
- Right (+X): Red (#C41E3A)
- Left (-X): Orange (#FF5800)
- Top (+Y): White (#FFFFFF)
- Bottom (-Y): Yellow (#FFD500)
- Front (+Z): Blue (#0051BA)
- Back (-Z): Green (#009E60)

These are the official Westcolor Rubik's cube colors.

Now let me write the code.

For the black background faces (inner faces), I'll use a dark color like #1a1a1a.

Let me also add a subtle border/edge effect to make the cubies look more like actual Rubik's cube pieces. I can do this by making the cubies slightly smaller than the grid spacing and giving them rounded edges, or I can just use the gap approach (scale < 1).

I'll use scale 0.92 for each cubie and give the black faces a dark color to simulate the gaps.

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

```javascript
const CUBIE_SIZE = 0.92;
const GRID_SPACING = 1;

const COLORS = {
    right: 0xC41E3A,   // +X Red
    left: 0xFF5800,    // -X Orange  
    top: 0xFFFFFF,     // +Y White
    bottom: 0xFFD500,  // -Y Yellow
    front: 0x0051BA,   // +Z Blue
    back: 0x009E60,    // -Z Green
    inner: 0x1a1a1a    // Black
};

// Create 27 cubies
for (let x = -1; x <= 1; x++) {
    for (let y = -1; y <= 1; y++) {
        for (let z = -1; z <= 1; z++) {
            const materials = [
                new THREE.MeshStandardMaterial({ color: x === 1 ? COLORS.right : COLORS.inner }),
                new THREE.MeshStandardMaterial({ color: x === -1 ? COLORS.left : COLORS.inner }),
                new THREE.MeshStandardMaterial({ color: y === 1 ? COLORS.top : COLORS.inner }),
                new THREE.MeshStandardMaterial({ color: y === -1 ? COLORS.bottom : COLORS.inner }),
                new THREE.MeshStandardMaterial({ color: z === 1 ? COLORS.front : COLORS.front }), // Wait, front is +Z
                new THREE.MeshStandardMaterial({ color: z === -1 ? COLORS.back : COLORS.inner }),
            ];
            // Actually, the front face color should be Blue for +Z
            // And back face color should be Green for -Z
            const geo = new THREE.BoxGeometry(CUBIE_SIZE, CUBIE_SIZE, CUBIE_SIZE);
            const mesh = new THREE.Mesh(geo, materials);
            mesh.position.set(x * GRID_SPACING, y * GRID_SPACING, z * GRID_SPACING);
            // Store the grid position for later
            mesh.userData.gridPos = { x, y, z };
            scene.add(mesh);
            cubies.push(mesh);
        }
    }
}
```

Wait, let me reconsider the face order for BoxGeometry. In THREE.js:
- BoxGeometry materials: [right(+X), left(-X), top(+Y), bottom(-Y), front(+Z), back(-Z)]

Actually, I just realized that THREE.js BoxGeometry uses the following face order:
0: +X (right)
1: -X (left)  
2: +Y (top)
3: -Y (bottom)
4: +Z (front)
5: -Z (back)

Wait, let me verify. In THREE.js, BoxGeometry faces are:
- Index 0: +X face
- Index 1: -X face
- Index 2: +Y face
- Index 3: -Y face
- Index 4: +Z face (front)
- Index 5: -Z face (back)

Yes, that's correct.

Now for the click handling, I need to determine which face of the cubie was clicked. I can use the face normal from the raycast intersection, transformed to world space.

Actually, THREE.js raycaster gives me `face.normal` which is in the object's local space. For a BoxGeometry with no rotation, this should be aligned with world axes. But after rotations, the cubie's geometry might be rotated, so the face normal needs to be transformed.

Wait, actually when I rotate a cubie using the pivot method, the cubie's local rotation changes. So the face normal in local space might not match the world face direction.

Hmm, I need to think about this differently. After rotation, the cubie's mesh.rotation has changed. So `face.normal` in local space, when transformed by the mesh's world matrix, gives the correct world-space normal.

THREE.js provides `face.normal.clone().applyQuaternion(mesh.getWorldQuaternion(new THREE.Quaternion()))` to get the world-space normal.

Or more simply: `intersect.face.normal.clone().applyMatrix3(new THREE.Matrix3().getNormalMatrix(mesh.matrixWorld))`.

Actually, for the raycaster, the intersection already gives world-space information. Let me check: `intersect.face.normal` is in the object's local space, but `intersect.faceIndex` can help identify the face.

Actually, I think the simplest approach is to use the face normal and transform it to world space using the mesh's world quaternion:

```javascript
const worldNormal = face.normal.clone().applyQuaternion(mesh.quaternion);
```

This gives the world-space direction of the face normal. Then I can determine which axis has the largest absolute value to identify the clicked face.

For the layer determination, I use the cubie's world position and find the coordinate closest to the axis value.

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

Let me also think about the scramble animation speed. I'll use a faster animation for scramble (smaller step per frame).

Here's my final plan:
1. Scene setup with lighting
2. Create 27 cubies with proper colors
3. Orbit camera controls (mouse drag)
4. Click detection for face rotation
5. Rotation animation system
6. Scramble button
7. UI styling

Let me write it all now. I'll make it a complete, polished implementation.

For the UI, I'll add:
- A scramble button with nice styling
- Instructions text
- A dark themed UI that overlays the 3D canvas

Let me also add some visual polish:
- Rounded cubie edges (using a subtle bevel effect)
- Smooth rotation animations with easing
- Nice lighting setup

For the rounded edges, I can't easily create rounded boxes without extra geometry. I'll just use the gap approach (slightly smaller cubies) and it should look fine.

One more thing: for the scramble, I'll generate random moves and animate them. A "move" is a 90° rotation of a face. I'll pick random faces and random directions.

Let me now write the complete code:

Actually, I realize I should also handle the case where the user is dragging for orbit vs clicking for rotation. I'll use a threshold: if the mouse moves more than a few pixels between mousedown and mouseup, it's an orbit, not a click.

Let me finalize the code now.

For the animation system:
```javascript
let pendingRotations = [];
let isAnimating = false;
let animationProgress = 0;
let currentRotation = null;
const ROTATION_DURATION = 300; // ms

function queueRotation(axis, layer, angle) {
    pendingRotations.push({ axis, layer, angle });
    if (!isAnimating) processNextRotation();
}

function processNextRotation() {
    if (pendingRotations.length === 0) {
        isAnimating = false;
        return;
    }
    isAnimating = true;
    animationProgress = 0;
    currentRotation = pendingRotations.shift();
    
    // Attach cubies to pivot
    const pivot = new THREE.Object3D();
    scene.add(pivot);
    
    currentRotation.cubiesToRotate = cubies.filter(c => {
        const pos = c.position[currentRotation.axis];
        return Math.abs(pos - currentRotation.layer) < 0.1;
    });
    
    currentRotation.cubiesToRotate.forEach(c => {
        pivot.attach(c);
    });
    
    currentRotation.pivot = pivot;
}

// In animation loop:
if (isAnimating && currentRotation) {
    animationProgress += deltaTime / ROTATION_DURATION;
    if (animationProgress >= 1) {
        animationProgress = 1;
        // Finalize rotation
        const pivot = currentRotation.pivot;
        const angle = currentRotation.angle;
        pivot.rotation[currentRotation.axis] = angle;
        
        // Detach cubies back to scene
        currentRotation.cubiesToRotate.forEach(c => {
            scene.attach(c);
            // Snap position to grid
            c.position.x = Math.round(c.position.x);
            c.position.y = Math.round(c.position.y);
            c.position.z = Math.round(c.position.z);
            c.rotation.x = Math.round(c.rotation.x / (Math.PI/2)) * (Math.PI/2);
            c.rotation.y = Math.round(c.rotation.y / (Math.PI/2)) * (Math.PI/2);
            c.rotation.z = Math.round(c.rotation.z / (Math.PI/2)) * (Math.PI/2);
        });
        
        scene.remove(pivot);
        currentRotation = null;
        processNextRotation();
    } else {
        const eased = easeInOutCubic(animationProgress);
        currentRotation.pivot.rotation[currentRotation.axis] = currentRotation.angle * eased;
    }
}
```

This is a solid plan. Let me now write the complete HTML file.

One thing I want to add is a nice visual style. I'll use:
- Dark background (#1a1a2e or similar)
- Glowing button for scramble
- Clean typography

Let me write the final code now. I'll make it comprehensive and polished.

Let me reconsider the colors to make it look great:
- Background: dark gradient or solid dark
- Cube: standard colors with slight emissive for a premium look
- Lighting: ambient + multiple directional lights for nice shading

Actually, let me use a subtle approach. The cube should look like a real Rubik's cube with some nice lighting.

Here's my final lighting setup:
- Ambient light (soft, ~0.4 intensity)
- Directional light 1 (main light, from upper-right)
- Directional light 2 (fill light, from lower-left)
- Maybe a hemisphere light for subtle color variation

Let me write the code now.

For the scrambling, I'll do 25 random moves. Each move is:
1. Pick a random axis (x, y, z)
2. Pick a random layer (-1, 0, 1)
3. Pick a random direction (+π/2 or -π/2)

I'll queue these up and animate them with a shorter duration for faster scrambling.

Let me finalize and write the code. I'll aim for about 400-500 lines of well-organized code.

Actually, wait - I need to also handle the `scene.attach()` method. In THREE.js, `Object3D.attach(child)` moves a child from another parent to this parent while preserving its world transform. This is exactly what I need for the pivot rotation technique.

OK, writing the final code now. Let me be thorough and write a complete, working implementation.

Let me also consider: what if the user clicks on an inner face of a cubie? Inner faces are not visible on the surface of the cube, so they shouldn't be clickable for rotation. I can handle this by checking if the clicked face's normal aligns with an outer face of the cube.

For example, if I click on a cubie at (0, 0, 0) and the clicked face has normal (1, 0, 0), this is an inner face (since x=0 is not on the surface). I should ignore this click.

I can check: `Math.abs(clickedPosition[axis]) === 1` to verify the clicked face is on an outer layer.

Actually, I need to be more careful. The cubie at (1, 0, 0) has an outer +X face. If I click on its +X face, that's valid. But if I click on its -X face (which is internal, facing the center), that's also an inner face and should be ignored.

So the check is: if the clicked face normal points outward from the cube (i.e., the cubie is at the extreme position along that axis AND the normal points outward), then it's a valid click.

More precisely:
- For +X face (normal 1,0,0): valid if cubie x position ≈ 1
- For -X face (normal -1,0,0): valid if cubie x position ≈ -1
- For +Y face (normal 0,1,0): valid if cubie y position ≈ 1
- For -Y face (normal 0,-1,0): valid if cubie y position ≈ -1
- For +Z face (normal 0,0,1): valid if cubie z position ≈ 1
- For -Z face (normal 0,0,-1): valid if cubie z position ≈ -1

This ensures we only rotate outer faces.

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

Let me also think about edge cases:
- What if the cubie has been rotated and its position is no longer exactly at integer coordinates? The `scene.attach()` and position snapping should handle this.
- What if the user clicks during an animation? I'll queue the click as a pending rotation.
- What about mobile touch support? I'll add touch event handlers for orbit and click.

Let me write the final code now. I'll include touch support for mobile devices.

Let me reconsider the approach slightly. Instead of using `scene.attach()` which can be tricky, I'll use `THREE.Object3D.attach()` which is designed for this purpose. The pivot is added to the scene, and cubies are attached to the pivot. After rotation, cubies are attached back to the scene.

Actually, let me reconsider. Using `attach` is the right approach because it preserves world transforms. The key insight is:

1. Create a pivot Object3D at the origin (scene center)
2. For each cubie in the layer, `pivot.attach(cubie)` - this moves the cubie to the pivot while keeping its world position the same
3. Rotate the pivot
4. For each cubie, `scene.attach(cubie)` - this moves the cubie back to the scene while keeping its world position the same (but now rotated)
5. Snap positions and rotations to clean values

This is the standard technique for Rubik's cube rotation in Three.js.

Let me write the code now. I'm confident in the approach.

One more thought: I should use `THREE.MeshStandardMaterial` with a roughness value to make the cube faces look more like plastic. I'll use roughness around 0.3-0.5 for a nice look.

And I'll add a subtle edge by using `THREE.EdgesGeometry` and `THREE.LineSegments` to draw black edges around each cubie. This gives the appearance of the gaps between cubie pieces.

Actually, for simplicity, let me just use the gap approach (cubies slightly smaller than the grid) with dark colored inner faces. The edges won't be perfectly defined, but it should still look good.

Let me write the complete code now!

I realize I should also think about the camera position. I'll place the camera at a nice angle that shows 3 faces of the cube (like looking from slightly above and to the side).

Camera setup:
- Position: (5, 4, 5) or similar
- Looking at: (0, 0, 0)
- Orbit controls: drag to rotate around the cube

Let me finalize and write the code.

For the scramble button, I'll position it at the top center of the screen with a clean, modern style.

Here's my final code structure:
1. HTML/CSS for layout and styling
2. Three.js scene setup
3. Cube creation (27 cubies)
4. Orbit camera implementation
5. Click-to-rotate implementation
6. Scramble button
7. Animation loop
8. Touch support

Let me write it all now. This will be a substantial piece of code, but I'll make it clean and well-organized.

OK one more thing I want to verify: the face normal from raycasting. When I raycast against a mesh, I get:
- `intersection.face` - the face that was hit
- `intersection.face.normal` - the normal of that face in LOCAL space

To get the world-space normal, I need to transform it by the mesh's rotation. But if I use `applyQuaternion(mesh.quaternion)`, I get the normal in the mesh's local coordinate system rotated by the mesh's quaternion. This is correct because the mesh's rotation represents how it's oriented in world space.

Wait, actually, I need to use the world quaternion:
```javascript
const worldQuaternion = new THREE.Quaternion();
mesh.getWorldQuaternion(worldQuaternion);
const worldNormal = face.normal.clone().applyQuaternion(worldQuaternion);
```

This is because the mesh might be a child of another object (like the pivot), so its local quaternion might not reflect its full world rotation.

Actually, if I use `pivot.attach(cubie)`, the cubie becomes a child of the pivot. The cubie's local rotation stays the same, but its world rotation changes because the pivot is rotated. So I need the world quaternion.

But wait, during animation, I rotate the pivot, not the cubies. The cubies' local quaternions don't change during animation. Only after the animation completes do I `scene.attach(cubie)` and snap the rotation.

So when raycasting:
- Before any rotation: cubie world rotation = (0, 0, 0), local quaternion = identity
- During animation: cubie world rotation changes due to pivot, but local quaternion stays the same
- After animation: cubie local rotation is updated (snapped)

For raycasting during animation (which we should allow), I need the world quaternion. Let me use:
```javascript
const worldNormal = face.normal.clone().applyQuaternion(mesh.getWorldQuaternion(new THREE.Quaternion()));
```

This will give the correct world-space face normal at any point.

OK, I'm writing the code now. For real this time!

Let me structure the code cleanly:

```javascript
// === Configuration ===
const CUBIE_SIZE = 0.92;
const GRID = [-1, 0, 1];

// === Colors ===
const FACE_COLORS = {
    right: 0xC41E3A,    // Red (+X)
    left: 0xFF5800,     // Orange (-X)
    up: 0xFFFFFF,       // White (+Y)
    down: 0xFFD500,     // Yellow (-Y)
    front: 0x0046AD,    // Blue (+Z)
    back: 0x009E60,     // Green (-Z)
    inner: 0x111111     // Dark
};

// === State ===
let cubies = [];
let pivot = null;
let animating = false;
let animQueue = [];
let animProgress = 0;
let animDuration = 250; // ms per rotation

// ... rest of the code
```

Let me write the complete file now. I'll aim for completeness and polish.

I want to add one more thing: a subtle glow or shadow effect. I can add a shadow plane below the cube or just use good lighting.

Actually, let me keep it simple and just use good lighting. The key features are:
1. Nice lighting setup
2. Interactive rotations
3. Orbit camera
4. Scramble button

Let me write the final code. I'll be thorough but not over-engineer.

Wait, I also want to make sure the cube looks good from all angles. I'll add:
- A subtle ambient occlusion effect (not really possible without post-processing, so I'll skip this)
- Good lighting from multiple directions
- Maybe a subtle gradient background

For the background, I'll use a dark color or a simple radial gradient. In Three.js, I can set `scene.background = new THREE.Color(0x1a1a2e)` or use a CSS gradient on the body.

Let me use a CSS gradient for the body and a matching dark color for the scene background (or leave the scene background transparent).

OK, writing the final code now. I'll create a comprehensive, working implementation.

Let me also think about the animation easing. I'll use a smooth ease-in-out curve:
```javascript
function easeInOutCubic(t) {
    return t < 0.5 ? 4 * t * t * t : 1 - Math.pow(-2 * t + 2, 3) / 2;
}
```

This gives a nice smooth animation that starts slow, speeds up in the middle, and slows down at the end.

For the scramble, I'll use a faster animation (shorter duration) to make it feel snappy.

Let me write the final code. I'll include all the features in a well-structured manner.

Actually, one more consideration: for the scramble, I should avoid doing the same face rotation twice in a row (since rotating the same face twice is equivalent to one rotation of double the angle, which is not a standard Rubik's move). I'll generate 25 moves, ensuring no two consecutive moves are on the same face.

Also, for a proper scramble, I should avoid opposite faces (e.g., R followed by L) since they cancel out in some sense. But actually, in Rubik's cube, R L is a valid move sequence. So I'll just avoid consecutive same-face rotations.

Let me finalize:
- 25 random moves
- No two consecutive moves on the same axis+layer (i.e., no R R, U U, etc.)
- Random direction (clockwise or counter-clockwise)

Now let me write the code!

For the CSS, I'll create a clean, modern look:
- Full-screen canvas
- Scramble button at the top
- Instructions at the bottom
- Dark theme

```css
body {
    margin: 0;
    overflow: hidden;
    background: radial-gradient(ellipse at center, #1a1a3e 0%, #0a0a1a 100%);
    font-family: 'Segoe UI', system-ui, sans-serif;
}

#ui {
    position: absolute;
    top: 20px;
    left: 0;
    right: 0;
    text-align: center;
    z-index: 10;
    pointer-events: none;
}

#scramble {
    pointer-events: auto;
    padding: 12px 32px;
    font-size: 16px;
    font-weight: 600;
    border: none;
    border-radius: 8px;
    cursor: pointer;
    background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
    color: white;
    box-shadow: 0 4px 15px rgba(102, 126, 234, 0.4);
    transition: transform 0.2s, box-shadow 0.2s;
}

#scramble:hover {
    transform: translateY(-2px);
    box-shadow: 0 6px 20px rgba(102, 126, 234, 0.6);
}

#scramble:active {
    transform: translateY(0);
}

#info {
    position: absolute;
    bottom: 20px;
    left: 0;
    right: 0;
    text-align: center;
    color: rgba(255, 255, 255, 0.5);
    font-size: 14px;
    pointer-events: none;
}
```

OK I've thought about this enough. Let me write the complete code now.

I want to make sure I handle all edge cases:
1. Click on inner face → ignore
2. Click during animation → queue the rotation
3. Drag for orbit vs click for rotation → use movement threshold
4. Touch support for mobile

And I'll make the code clean and well-commented.

Let me write it now. Final answer time!

Here's one more thing: I want to make the face rotation feel satisfying. I'll use:
- Smooth easing (ease-in-out-cubic)
- Duration of about 250ms for single rotations
- Duration of about 150ms for scramble rotations
- A subtle "click" sound effect... actually, I'll skip sound to keep it simple.

Let me finalize and write the complete code.

Hmm, let me reconsider one thing. When I use `pivot.attach(cubie)`, the cubie's world position stays the same. But after the pivot rotation, when I call `scene.attach(cubie)`, the cubie's world position is preserved. However, the cubie's position relative to the scene will now be rotated. I then snap the position to the nearest integer to clean up floating-point errors.

Let me verify this works correctly:
1. Cubie at (1, 1, 1) is attached to pivot at (0, 0, 0)
2. Pivot rotates 90° around Y
3. Cubie's world position becomes (-1, 1, 1) (rotated from (1, 1, 1))
4. `scene.attach(cubie)` preserves world position (-1, 1, 1)
5. Snap to integer: (-1, 1, 1) ✓

This should work correctly. The key is that `attach` preserves world transforms.

OK, writing the final code now. I'm going to produce a complete, working implementation.

Let me verify the file was created correctly by checking it exists and reviewing its structure.

The file has been written successfully. Let me verify the three.min.js is present and that the HTML references it correctly.