diff --git a/Week-2/Task-3/ProductLens.md b/Week-2/Task-3/ProductLens.md
index 4ec5a91..e302a16 100644
--- a/Week-2/Task-3/ProductLens.md
+++ b/Week-2/Task-3/ProductLens.md
@@ -5,7 +5,8 @@
 	- Guided demos for feature highlights, onboarding walkthroughs, and education content.
 	- Presentation flows where some objects appear later and camera framing adapts per step.
 - Does Thob feel strong enough for this use case?
-	- Partial. We can approach the same result by toggling Make Default on Perspective Camera and toggling object components, but button-driven prop updates are still hard to wire clearly.
+	- Partial. We can approach the same result by toggling Make Default on Perspective Camera and toggling object components, but my first instinct was button-driven step switching and that was hard to make reliable end-to-end.
+	- A practical fallback is radio-button switching across preconfigured step states.
 - What would improve the experience?
 	- Improve the button UX.
 	- Make it easier and more intuitive for buttons to connect to and change component prop values.
diff --git a/Week-2/Task-3/TaskNotes.md b/Week-2/Task-3/TaskNotes.md
index 8015a4a..efa92cc 100644
--- a/Week-2/Task-3/TaskNotes.md
+++ b/Week-2/Task-3/TaskNotes.md
@@ -32,9 +32,11 @@ Create a 3-step guided flow where each step changes camera position/look target
 -Possible: Partial
 -Notes:
   - We can create the same result by toggling multiple combinations of the Make Default button of the Perspective Camera component and by toggling the visibilty object component.
+  - My first intuition was to drive the guided steps with buttons, but I was not able to make that flow work reliably end-to-end.
   - Same as before, the button UX needs improvement.
   - The button should connect to and change component prop values in an easier and more intuitive way.
   - I was not able to clearly figure out how to make the button functional end-to-end.
+  - A practical fallback is using radio buttons to switch between preconfigured step states.
 
 - Builder steps:
   - Add Perspective Camera component and toggle Make Default.
@@ -68,6 +70,7 @@ Create a 3-step guided flow where each step changes camera position/look target
   - Partial workaround.
 - If yes, what is it?
   - Use Make Default and object toggles for basic/static setups.
+  - Use radio buttons to switch between preconfigured step states (camera + object presets) as a preset-like fallback.
   - For complete multi-step transitions, implement custom interaction logic outside the current builder button flow.
 
 ## Suggested Improvement
diff --git a/Week-2/Task-3/builder/BuilderNotes.md b/Week-2/Task-3/builder/BuilderNotes.md
index 633757b..3574691 100644
--- a/Week-2/Task-3/builder/BuilderNotes.md
+++ b/Week-2/Task-3/builder/BuilderNotes.md
@@ -3,7 +3,7 @@
 ## Thob Observations from Task Notes
 
 - **Possible:** Partial
-- **Implementation used:** Perspective Camera with Make Default toggle, object visibility toggles, and attempted button bindings for step transitions.
+- **Implementation used:** Perspective Camera with Make Default toggle, object visibility toggles; first intuition was button-driven step transitions, but that setup was not reliable end-to-end.
 - **What worked as expected:**
 	- Camera can be set as default quickly.
 	- Object visibility/state can be adjusted manually.
@@ -20,7 +20,7 @@
 	5. Validate step transitions and check repeatability.
 - **Complexity:** Hard
 - **Main limitation signals:** Editor UX + Event system + Runtime stability concerns.
-- **Workaround status:** Partial workaround only (manual/static states are possible; robust step orchestration via button bindings remains difficult).
+- **Workaround status:** Partial workaround only (manual/static states are possible, and radio buttons can switch preconfigured step-state presets; robust step orchestration via button bindings remains difficult).
 
 ## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning
 
@@ -72,6 +72,7 @@
 ## Overall Read
 
 - Task 3 behavior is partially achievable in thob: static setup and manual state toggles work, but robust multi-step interaction wiring is still difficult.
+- A practical fallback is radio-button-driven switching between preconfigured step states.
 - The repeated registration warnings (`GetBindingData`, `update-static-component-prop`, `resetPOI`) strongly align with the core issue: unstable button-driven multi-prop updates.
 - Controlled/uncontrolled warnings indicate editor form-state instability, which likely contributes to confusion during binding setup.
 - Runtime instability signals (`404`, `Context Lost`) reduce trust during validation and should be addressed alongside interaction UX improvements.