docs: week 3 task 1 docs

Week-3/Task-1/ProductLens.md

@@ -1,5 +1,17 @@
 ## Product Lens
-- Is this pattern useful for real customers? Yes / Partial / No
+- Is this pattern useful for real customers? Yes
 - What kind of customer use case does this support?
+	- Product inspection: users switch between front/side/top detail viewpoints.
+	- Guided tours: sequenced camera jumps between key points of interest.
+	- Storytelling/marketing: deliberate framing changes to control narrative focus.
 - Does Thob feel strong enough for this use case?
+	- Partial.
+	- From my Task 1 test, there are two ways:
+		- Way 1: three separate meshes/scenes with one perspective camera setup each, then toggle visibility using radio buttons. This was stable.
+		- Way 2: one mesh + three perspective cameras, toggling `Make Default` using radio buttons. This was unreliable (sometimes appears, then disappears after repeated toggles; sometimes works only at certain positions).
+	- So today, Thob is okay for workaround-based flows, but direct camera preset switching reliability is not strong enough yet.
 - What would improve the experience?
+	- Native camera preset system with explicit position + target/focus per preset.
+	- Clear interaction binding: control -> target camera/preset -> action.
+	- Deterministic behavior under fast repeated switching.
+	- Better visual/debug indication of which camera is active and why.

Week-3/Task-1/TaskNotes.md

@@ -1,60 +1,113 @@
-# Task: [Feature Name]
+# Task: Camera Preset Consistency Audit
 
 ## Objective
-What is the feature trying to do?
+Stress test camera preset switching with 3 presets and verify reliability under repeated and rapid switching, focus/target consistency, transition behavior, and final state correctness.
 
 ## Vanilla three.js
--Possible: Yes / Partial / No
+-Possible: Yes
+-Reliability verdict: Reliable
 -Notes:
+  - Code uses one `PerspectiveCamera`, a fixed `target` vector, and three preset positions (`front`, `side`, `topAngled`).
+  - Repeated switching is reliable because each switch only updates `desiredPosition`; no competing camera instances.
+  - Rapid switching is predictable: latest click/key wins, and camera lerps toward that final preset.
+  - Focus is consistent because `camera.lookAt(target)` runs every frame.
+  - Transition is smooth (`lerp` with factor `0.08`).
+  - Final camera state matches the selected preset in practice (converges over frames; not mathematically exact in one frame due to lerp).
 -Key concepts:
--Complexity: Easy / Medium / Hard
+  - Preset map
+  - Single camera state machine
+  - Frame-loop interpolation
+  - Deterministic target locking
+-Complexity: Medium
 
 ## R3F
--Possible: Yes / Partial / No
+-Possible: Yes
+-Reliability verdict: Reliable
 -Notes:
+  - Uses React state (`preset`) with a `CameraController` that updates camera in `useFrame`.
+  - Repeated and fast switching stay stable because only one active preset state is used at a time.
+  - Focus is predictable (`camera.lookAt(target)` each frame).
+  - Transitions are smooth and consistent (same lerp strategy as vanilla).
+  - Final state converges to whichever preset was selected last.
 -What R3F abstracted:
--Complexity: Easy / Medium / Hard
+  - Input/state separation from camera movement logic
+  - Render-loop integration via `useFrame`
+  - Cleaner UI-to-camera flow with less manual wiring
+-Complexity: Easy
 
 ## Thob Page Builder
--Possible: Yes / Partial / No
+-Possible: Partial
+-Reliability verdict: Partially Reliable
 -Notes:
+  - I found two ways to approach this.
+  - Way 1 (reliable workaround): I built 3 individual meshes/scenes with one perspective camera per setup and fixed positions, then toggled mesh visibility with radio buttons. This worked consistently.
+  - Way 2 (direct preset intent, unreliable): I tried one mesh/geometry with 3 perspective cameras and toggled `Make Default` with radio buttons. This was unreliable.
+  - Observed behavior in Way 2:
+    - Sometimes works once, then does not appear after 1-2 toggles.
+    - Sometimes appears only at certain positions and fails at others.
+    - Final camera state is not always the expected selected preset.
+  - Conclusion: direct multi-camera preset switching feels fragile in current builder flow; multi-mesh visibility toggle is a workaround, not true camera-preset reliability.
 -Builder steps:
--Complexity: Easy / Medium / Hard
+  1. Built three separate mesh setups with one camera and fixed positions.
+  2. Added radio buttons to toggle visibility and verified stable behavior.
+  3. Rebuilt as single mesh + three cameras.
+  4. Tried toggling camera `Make Default` via radio buttons.
+  5. Stress tested repeated and fast toggles, then observed instability.
+-Complexity: Hard
 
 ## Comparison Summary
--Possible in all 3? Yes / Partial / No
+-Possible in all 3? Partial
 -Main differences:
+  - Vanilla/R3F keep one camera pipeline and update only target position.
+  - Thob direct multi-camera default switching can become inconsistent under rapid toggles.
+  - Thob workaround (visibility switching) can look stable but does not validate true camera preset authoring reliability.
 -Where Thob is better:
+  - Fast visual assembly and no-code experimentation.
 -Where Thob is weaker:
+  - Camera state authoring clarity.
+  - Deterministic behavior when switching default camera repeatedly.
 -What feels awkward or unclear:
+  - How radio/button interactions should safely control camera default state and final active camera.
+
+## Use Case Suitability
+-Product inspection: Vanilla/R3F = good. Thob = partial (workaround possible, direct camera preset flow unreliable).
+-Guided tours: Vanilla/R3F = good. Thob = partial to fragile if relying on rapid camera default switching.
+-Storytelling: Vanilla/R3F = good. Thob = partial for simple flows, risky for frequent camera jumps.
 
 ## Limitation Type (if any)
--[ ] Editor UX limitation
--[ ] Runtime limitation
+-[x] Editor UX limitation
+-[x] Runtime limitation
 -[ ] Schema / data model limitation
--[ ] Component limitation
--[ ] Event system limitation
+-[x] Component limitation
+-[x] Event system limitation
 -[ ] Asset pipeline limitation
 -[ ] Unknown / needs investigation
 
 ## Workaround
 -Is there a workaround?
+  - Yes, partial workaround.
 -If yes, what is it?
+  - Build separate meshes/scenes and toggle visibility with radio buttons while keeping camera setup simple per view.
+  - This gives stable visual switching but is not the same as robust camera preset switching on one shared scene/camera model.
 
 ## Suggested Improvement
 -What should improve in Thob?
+  - Add first-class camera preset authoring (preset list with position + target/focus).
+  - Add one explicit "switch to preset" action for buttons/radios.
+  - Ensure deterministic final state when interactions fire quickly.
+  - Improve `Make Default` behavior and lifecycle when multiple cameras exist.
+  - Show active camera and target/focus clearly in editor and runtime inspector.
 -Is it:
   - editor
   - runtime
   - component
   - UX
-  -schema/data
 
 ## Difficulty Estimate
--Easy / Medium / Hard
+-Hard
 
 ## Business Value
--Low / Medium / High
+-High
 
 ## Recommendation
-Should Thob support this better? Why?
+Yes, Thob should support this better. Camera preset reliability is critical for product inspection, guided tours, and storytelling, and current direct multi-camera switching behavior is not predictable enough for production confidence.