Build a single index.html containing three.min.js, a solar system, orbital camera controls (custom implementation, no OrbitControls import), and a point-based starfield.

Write the file.

Write index.html that includes a complete solar system. Features:
- Sun: emissive sphere + PointLight
- 8 planets with varying sizes and speeds, with orbit rings
- Maybe a moon around the Earth too
- Custom orbit camera: rotate on drag, zoom on wheel
- Starfield: Points with random positions
- Saturn's rings would be nice too
- Labels are optional — keep it simple, maybe show planet names via raycast hover. Keep it moderate: add planet name display on hover, and a speed slider if needed. Keep it robust.

Quick sanity check — verify that the three.min.js version is compatible with the features being used. Check whether BufferGeometry's setAttribute exists (r110+) and the PointLight decay parameter. Let me grep the three.min.js version.

That didn't work. Let me try searching for "REVISION:" or "revision".

It's minified as a variable. Let's try searching another way: the 'BufferGeometry.prototype.setAttribute' or 'setAttribute' method, and 'CanvasTexture'.

The name only appears once each — that's probably because minified code registers them like `THREE.SphereGeometry=...`, and the occurrence count is low. But they exist. Let's check if they're attached to THREE (exports). Also, should I check whether it's a newer version that uses the newer light intensity units (r155+ has physically correct lighting by default, PointLight intensity 2.2 with decay 1.6 might be very dark)? In newer three (r155+), useLegacyLights defaults to false, point light intensity is in candela units, and decay 2 is physical. A PointLight with intensity 2.2 at a distance of 66 units would be essentially 2.2/66² ≈ negligible. This would make the planets very dark.

To be safe, boost the point light's intensity substantially and lower the decay, and also rely on the ambient light. Let's detect the version. I'll check for strings like 'useLegacyLights' or 'WebGPURenderer' that indicate a newer version.

No useLegacyLights — meaning either old (<r150) or it's been minified away. Let's find the REVISION value another way: search for the pattern around the THREE.REVISION assignment, e.g. look for `"1` near the top of the file.

REVISION=e, where e is a variable. Find where e is defined near the beginning:

Can't easily tell. Let's just try running it headless — check whether node + a headless browser exist? Probably not available. Safer approach: make the lighting robust regardless of the version:

1. Use a moderate-intensity PointLight, plus a decent ambient light (already 0.55). If this is the physically-based lighting era (r155+), a PointLight intensity of 2.2 with decay 1.6 will produce almost no light contribution. Bump the intensity up high (e.g., 1500, decay 2) — but if it's the old legacy lighting, that would blow out white. Hmm.

Alternative: use DirectionalLight? No, the sun is at the center. Use MeshLambert/Standard... Actually, the simplest and most robust option: check THREE.WebGLRenderer.useLegacyLights at runtime? In older versions this property doesn't exist. Could branch:

```
var intensity = (THREE.PointLight && renderer.useLegacyLights === false) ? 2000 : 2.2;
```

If renderer.useLegacyLights is undefined (old version), use the legacy value. In newer versions (r155–r16x?) useLegacyLights existed until r165? It was removed in r165 (always physically based). In that case renderer.useLegacyLights === undefined again. Hmm.

Better approach: set a decay-independent approach. Actually there's another trick: keep PointLight, but additionally give each planet a small emissive component so it's always visible. Emissive color = planet color * 0.25 guarantees visibility under any lighting regime. And scale the point light intensity dynamically: set intensity in candela-ish units depending on the renderer's capabilities...

The simplest and most robust: try to detect at runtime:
```
var legacy = renderer.useLegacyLights; // r150-r165
```
For older versions (<r150), legacy lighting is the default. For r155+, the default is false. For r165+, the property was removed, and the default is physical.

Detection: if `renderer.useLegacyLights === false`, it's physical. If undefined: either old (legacy) or very new (physical). Hmm, ambiguous.

Alternative robust solution: compute intensity so it looks OK either way — impossible with a single value.

Yet another approach: make the sun's contribution independent of the renderer's lighting mode, by using MeshBasicMaterial or MeshLambert for the planets? Lambert still needs light.

The cleanest is: add a modest emissive per planet, plus two point lights? No.

Actually, let me try harder to detect the revision. Search for strings that differ across versions, like "WebXR", "LinearSRGBColorSpace" (r152+), "sRGBEncoding" (older).

sRGBEncoding exists, but LinearSRGBColorSpace / ColorManagement don't → this is an older three.js (pre-r152), legacy lighting by default, physicallyCorrectLights is opt-in (off). In other words, PointLight intensity 2.2 works fine. The current code is compatible. Also, the existence of setAttribute confirms r110+. Good.

One concern: in older three, PointLight's decay parameter defaults to 1 with distance 0 — if distance is 0, does decay have no effect? In legacy mode with distance=0, there's no distance attenuation at all, so no problem — planets are lit uniformly. Good.

Everything else is compatible. Done — confirm the file exists.

The replace trick doesn't really validate that much, but at least Function's syntax parsing succeeded (in reality, `new Function` should throw an exception if the syntax is invalid, but `undefined_check` as an identifier is fine). That's enough.