# Divya Week 4 — Visual Priority Recommendations

## 3 Quick Wins

### 1. Asset Pipeline Validation & Feedback
- **Problem**: Texture uploads larger than 5MB fail silently without informing the user.
- **Why it matters**: It creates "Invisible Walls" for professional designers, leading to wasted time troubleshooting missing assets.
- **Recommendation**: Implement a simple file-size check and "Error Toast" notification when an upload is rejected.
- **Expected user impact**: Immediate reduction in "Unreliable Asset" complaints and faster authoring loops.
- **Confidence level**: High (This is a standard frontend validation).

### 2. $Context Syntax Dropdown / Autocomplete
- **Problem**: Binding UI triggers to Mesh IDs requires memorizing proprietary `$context` syntax.
- **Why it matters**: It is the single biggest friction point during the "Logic Linking" phase of building a configurator.
- **Recommendation**: Add a simple "Logic Picker" dropdown in the Binding panel that pre-fills valid $context paths.
- **Expected user impact**: Drastic reduction in "Interaction Drift" and a much lower learning curve for new designers.
- **Confidence level**: High.

### 3. Configurator Default State Persistence
- **Problem**: Active selections (like a chosen planet texture) reset to default on browser refresh.
- **Why it matters**: Makes "Reviewing" or "Sharing" specific configurations impossible during the build process.
- **Recommendation**: Store the active variant indices in the local editor session or URL params.
- **Expected user impact**: Improves the "QA and Review" workflow for design teams.
- **Confidence level**: Medium.

## 2 Medium Features

### 1. The "Selection Manager" Logic Primitive
- **Problem**: Managing mutual exclusivity (Single-Select) across 10+ parts is currently manual and fragile (State Explosion).
- **Why it matters**: This is the #1 requirement for complex retail configurators (e.g., choosing 1 wheel out of 20 options).
- **Recommendation**: Build a "Selection Group" node. Any mesh added to this group follows a "Radio Button" rule automagically.
- **Scope estimate**: 1–1.5 weeks.
- **Risk**: Low product risk; high engineering leverage.

### 2. Material Variant Block (Atomic UI)
- **Problem**: Creating a color switcher requires building individual buttons and linking manual visibility logic.
- **Why it matters**: It’s the most common task but also the most repetitive.
- **Recommendation**: A dedicated UI component that automatically generates buttons for every Variant defined on a Material.
- **Scope estimate**: 2 weeks.
- **Risk**: Requires a tight bridge between the Material Schema and the UI Engine.

## 1 Deeper Architecture Concern
- **Problem**: Absence of Native 3D Raycasting (Interaction Engine). 
- **Why it matters**: Without the ability to click 3D objects directly, Thob is a "UI Overlay" tool rather than a truly immersive 3D experience. Interaction remains shallow and limited to 2D buttons.
- **Why it is deeper than a quick fix**: This requires integrating a robust Pointer/Event system into the core Three.js render loop and exposing it through the Editor's Node system.
- **What kind of spike or investigation is needed**: A technical spike on "Pointer Event Propogation" in the Thob Fiber layer to see how to expose onClick and onPointerOver triggers to the user.

## Final Recommendation
- If only 1 visual/product-facing thing should be built first, it is the **Selection Manager Logic Primitive**. Direct interaction is the ultimate goal, but a "Selection Manager" would immediately unlock the ability to build massive, professional configurators that are currently too "Fragile" to maintain.