diff --git a/Week-2/Task-1/report.md b/Week-2/Task-1/report.md
index c385db1..722fac7 100644
--- a/Week-2/Task-1/report.md
+++ b/Week-2/Task-1/report.md
@@ -1,67 +1,55 @@
-# Task: Material Variant Switcher
+# Builder Notes: Task 1 - Material Variant Switcher
 
 ## Objective
-Create one 3D object with 2–3 material variants and allow switching between them.
-
+Implement a multi-variant Material Switcher (3 color/surface options) on a 3D Mesh and evaluate the developer/user experience across Vanilla Three.js, R3F, and the Thob Page Builder.
 
 ## Vanilla three.js
--Possible: Yes / Partial / No
--Notes:
--Key concepts:
--Complexity: Easy / Medium / Hard
+- **Possible**: Yes
+- **Notes**: Requires a purely imperative approach. The developer must manually create the Material instances, register them in an object, and write an event listener to mutate the `mesh.material` property on click.
+- **Key concepts**: Raycasting, DOM Event Listeners, Material Property Mutation.
+- **Complexity**: Medium (High boilerplate and manual state-syncing required).
 
-## R3F
--Possible: Yes / Partial / No
--Notes:
--What R3F abstracted:
--Complexity: Easy / Medium / Hard
+## R3F (React Three Fiber)
+- **Possible**: Yes
+- **Notes**: Utilizes a declarative state-driven model. React `useState` triggers an automatic re-render of the component whenever the material prop changes, making state-to-3D syncing seamless.
+- **What R3F abstracted**: Scene boilerplate, automatic resource cleanup, and component-level reactivity.
+- **Complexity**: Easy (Best for scaling complex logic via code).
 
 ## Thob Page Builder
--Possible: Yes / Partial / No
--Notes:
--Builder steps:
--Complexity: Easy / Medium / Hard
+- **Possible**: Yes
+- **Notes**: Employs a highly intuitive "No-Code" workflow. The process of defining specialized materials and linking them through the `MaterialVariant` controller feels like the "right way" to build a configurator—focusing on logic and visuals rather than syntax.
+- **Builder steps**: Instantiate Mesh -> Define Project Materials -> Add MaterialVariant Controller -> Create UI (Button/Radio) -> Link Trigger to State.
+- **Complexity**: Easy (Best for rapid production and designers).
 
 ## Comparison Summary
--Possible in all 3? Yes / Partial / No
--Main differences:
--Where Thob is better:
--Where Thob is weaker:
--What feels awkward or unclear:
+- **Possible in all 3?**: Yes
+- **Main differences**: Vanilla requires manual wiring; R3F uses state reactivity; Thob uses visual node linking.
+- **Where Thob is better**: The "Linking" workflow is fast and intuitive. It removes the need for "mental mapping" between the UI and the 3D scene.
+- **Where Thob is weaker**: Excessive theoretical console noise (warnings) and a Layer hierarchy that can become visually heavy. Crucially, advanced data-binding syntax like `$context.item_currentItem.id` is not "discoverable"—without specific documentation, a user has no way to know these internal property names exist.
+- **What feels awkward or unclear**: The "guessing game" required to find the correct expression syntax for UI components.
 
 ## Limitation Type (if any)
--[ ] Editor UX limitation
--[ ] Runtime limitation
--[ ] Schema / data model limitation
--[ ] Component limitation
--[ ] Event system limitation
--[ ] Asset pipeline limitation
--[ ] Unknown / needs investigation
+- [x] Editor UX limitation (Visual hierarchy management)
+- [x] Documentation / Discovery limitation (Expression syntax visibility)
+- [ ] Runtime limitation
+- [x] Schema / data model limitation (Repeated internal data-binding warnings)
 
 ## Workaround
--Is there a workaround?
--If yes, what is it?
+- **Is there a workaround?**: Currently, the only workaround is trial-and-error or external help, as the builder doesn't expose its proprietary syntax objects.
 
 ## Suggested Improvement
--What should improve in Thob?
--Is it:
-  -editor
-  -runtime
-  -component
-  -UX
-  -schema/data
-
-## Difficulty Estimate
--Easy / Medium / Hard
+- **Primary Optimization**: Implement **Expression Autocomplete** or Tooltips. When typing in a value field, Thob should suggest available context objects (like `$context.item`) to make the logic-building process more accessible.
+- **Secondary Optimization**: Suppress the redundant `GetBindingData` console warnings during loop renders.
+- **Is it**: Editor, UX, Docs, Schema.
 
 ## Business Value
--Low / Medium / High
+- **High**: This is the foundational pattern for any e-commerce product configurator (Automotive, Furniture, Fashion).
 
 ## Product Lens
-- Is this pattern useful for real customers? Yes / Partial / No
-- What kind of customer use case does this support?
-- Does Thob feel strong enough for this use case?
-- What would improve the experience?
+- **Is this pattern useful for real customers?**: Yes.
+- **What kind of customer use case does this support?**: Web-based car configurators, home deco apps, and retail customizers.
+- **Does Thob feel strong enough for this use case?**: Yes. The visual results and interaction stability are solid for production.
+- **What would improve the experience?**: A cleaner "Developer Console" with fewer warning signals.
 
 ## Recommendation
-Should Thob support this better? Why?
\ No newline at end of file
+Thob already has the "right" workflow for material switching. It's powerful and designers will find it very easy to use. The primary focus should be on "polishing" the background engine to eliminate the technical warning noise, making it feel like a rock-solid professional platform.
\ No newline at end of file