diff --git a/Week-4/Task3.md b/Week-4/Task3.md
new file mode 100644
index 0000000..4988029
--- /dev/null
+++ b/Week-4/Task3.md
@@ -0,0 +1,52 @@
+# Divya Week 4 — Visual UX / Product Micro-Proposals
+
+## Proposal 1: The "Selection Group" Logic Node
+
+### Problem
+Currently, managing "Single-Select" behavior (where choosing one option automatically deselects others) requires building individual "Reset" triggers for every single button. This leads to **State Explosion**—as the number of parts grows, the logic becomes unmanageable and fragile.
+
+### User Story
+"As a configurator designer for an automotive brand, I want to add 20 different wheel options to my scene and ensure that only one wheel is active at a time, without having to manually code 400 mutual-exclusivity triggers."
+
+### Proposed Builder Experience
+1. The user drags a new **Selection Group** node into the Logic/Layers panel.
+2. The user drags the desired meshes (e.g., Wheel_A, Wheel_B, Wheel_C) into this group.
+3. The group has a property called **Selection Mode** (Single / Multiple / Exactly One).
+4. Any UI button linked to a mesh inside this group automatically follows the group's "Radio Button" rules.
+
+### Proposed Primitive / Block / Pattern
+A **Logic Container primitive** that acts as a state coordinator for its children. It intercepts visibility/state calls and enforces exclusivity rules at the architecture level rather than the manual trigger level.
+
+### Why This Matters
+It transforms Thob from a "Simple Toggler" into a professional "Product Configurator Engine." It removes the #1 source of logic errors in complex scenes.
+
+### Complexity Guess
+- **Medium** (Requires a new logic-controller node type but uses existing visibility/selection states).
+
+---
+
+## Proposal 2: The "Material Variant" UI Block
+
+### Problem
+Creating a color-switcher UI is currently a manual process: Drag a button, style it, link it to a variant, repeat 10 times. It is repetitive and prone to "Sync Drift" (where the UI doesn't match the actual variants available on the material).
+
+### User Story
+"As a furniture designer, I have a sofa material with 15 fabric variants already defined. I want to generate a polished 'Fabric Selection' menu in my UI with one click, rather than building 15 manual buttons."
+
+### Proposed Builder Experience
+1. User defines Variants on a Material as usual (Red, Blue, Green).
+2. User drags a **Material Variant UI Block** onto their 2D Canvas.
+3. User selects the Target Mesh in the block's properties.
+4. The UI Block **automatically generates** a list of buttons (or a dropdown) based on the variants it finds on that mesh's material. 
+
+### Proposed Primitive / Block / Pattern
+An **Atomic UI Component** that is "schema-aware." It reads the `Material.variants` array and dynamically renders the corresponding interaction UI at runtime.
+
+### Why This Matters
+It reduces "Time-to-Value" for the most common 3D web use case (swappable colors). It ensures the UI is always 100% in sync with the scene data.
+
+### Complexity Guess
+- **Medium** (Requires the UI engine to be able to reach into the 3D Material definitions).
+
+### Optional Tiny Demo (Concept)
+- Refer to **Week 3 Task 1 & 2** reports. The "Simulated" buttons used in those audits are the exact patterns this block would automate.