Loading screen polish: Three.js background bleed-through, slide arrows, smart ETA

Started with a simple question: “why doesn’t the Three.js background show on the loading page?”

The opaque background was the culprit

.loadingAnalysis, .loadingAurora, and .loadingParticles in globals.css all had hardcoded dark background colors.

The Three.js canvas was sitting at z-index: -2, completely covered by the opaque backgrounds above it.

/* Before — opaque background hides canvas */
.loadingAnalysis { background: #0a0b2a; }

/* After — transparent to let canvas show through */
.loadingAnalysis { background: transparent; }

Switching to transparent fixed it immediately.

CSS went from 18 lines → 3 lines.

Slides were overlapping the status bar

The .eduSlide.in class had translateY(-6vh) which was pushing slides into the top status bar area.

/* Problem: slides drifting into status bar zone */
.eduSlide.in { transform: translateY(-6vh); }

/* Fix: reset to normal position */
.eduSlide.in { transform: translateY(0); }

Fixing this meant rethinking the entire slide container layout.

Two additional UX improvements

• Arrow buttons Desktop users can manually advance slides. Hidden on touch devices via @media (hover: hover).
• Smart ETA Stores the last 3 LLM round-trip times in localStorage under a fortuneTimings key. Averages them and displays "estimated ~N seconds." First-time users see a static fallback.

Prompt strategy

Bundling everything in one Claude prompt invites over-refactoring.

So I split by commit scope.

First prompt: only the transparency fix.

Second prompt combined the rest:

“eduSlide is overlapping the status bar due to translateY(-6vh). Fix that. Also add prev/next arrows for desktop. Track average LLM response time in localStorage and show it as estimated time.”

Smaller scope = more precise output from Claude.

---