docs: task2 notes

Week-2/Task-2/ProductLens.md

@@ -1,5 +1,12 @@
 ## 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?
+	- Guided product stories where objects appear/disappear across steps.
+	- Feature comparison scenes with predefined arrangements.
+	- Presentation flows where one click changes scene composition and framing.
 - Does Thob feel strong enough for this use case?
+	- Partial. The pattern is possible by combining object visibility states and Perspective Camera positions, but button-triggered updates are not reliably synchronized.
 - What would improve the experience?
+	- One button should update all linked properties simultaneously, or fast enough that transitions feel instant.
+	- Better multi-target binding UX for visibility, transforms, and camera props.
+	- Clearer feedback/debugging for whether each bound prop was successfully updated.

Week-2/Task-2/TaskNotes.md

@@ -1,60 +1,89 @@
-# Task: [Feature Name]
+# Task: Scene State Switching (Visibility + Transform Presets)
 
 ## Objective
-What is the feature trying to do?
+Switch between predefined scene states where each state controls object visibility, object transforms, and scene framing behavior.
 
 ## Vanilla three.js
--Possible: Yes / Partial / No
+-Possible: Yes
 -Notes:
+  - Uses a `states` map with three scene presets (`state1`, `state2`, `state3`).
+  - Each state defines object `position`, `rotation`, and `visible` values.
+  - Buttons and keyboard shortcuts apply state changes, and transforms are smoothed with lerp.
 -Key concepts:
--Complexity: Easy / Medium / Hard
+  - State configuration object
+  - Visibility toggling per object
+  - Transform interpolation
+  - UI-triggered state transitions
+-Complexity: Medium
 
 ## R3F
--Possible: Yes / Partial / No
+-Possible: Yes
 -Notes:
+  - Uses React state (`stateKey`) to drive active scene state.
+  - `SCENE_STATES` config mirrors vanilla behavior in a declarative structure.
+  - `useEffect` updates visibility/targets and `useFrame` handles smooth interpolation.
 -What R3F abstracted:
--Complexity: Easy / Medium / Hard
+  - Render-loop management via `useFrame`
+  - State-driven scene updates through React
+  - Cleaner component organization for scene objects
+-Complexity: Medium
 
 ## Thob Page Builder
--Possible: Yes / Partial / No
+-Possible: Partial
 -Notes:
+  - We can make things like this by creating combinations of object visibility and Perspective Camera position, but the button issue persists.
+  - We should be able to click the button and it all should be simultaneously or fast enough to not notice.
+  - Current button flow is not reliable enough for multi-property state switching.
 -Builder steps:
--Complexity: Easy / Medium / Hard
+  - Create scene objects and define visibility combinations.
+  - Set Perspective Camera positions for each target state.
+  - Add state buttons.
+  - Try binding each button to all required prop changes (visibility + transforms + camera).
+-Complexity: Hard
 
 ## Comparison Summary
--Possible in all 3? Yes / Partial / No
+-Possible in all 3? Partial
 -Main differences:
+  - Vanilla and R3F both support clean, predictable state switching.
+  - Thob can represent the same state idea, but synchronized multi-prop button updates are not smooth/reliable yet.
 -Where Thob is better:
+  - Fast visual setup of objects, visibility states, and camera values.
 -Where Thob is weaker:
+  - Button-driven multi-target updates are difficult to make feel atomic.
 -What feels awkward or unclear:
+  - Mapping one button to many coordinated prop updates without visible delay or missed updates.
 
 ## Limitation Type (if any)
--[ ] Editor UX limitation
+-[x] Editor UX limitation
 -[ ] Runtime limitation
 -[ ] Schema / data model limitation
 -[ ] Component limitation
--[ ] Event system limitation
+-[x] Event system limitation
 -[ ] Asset pipeline limitation
 -[ ] Unknown / needs investigation
 
 ## Workaround
 -Is there a workaround?
+  - Partial workaround.
 -If yes, what is it?
+  - Manually set visibility and camera values in sequence.
+  - Use simpler, fewer state transitions to reduce button binding complexity.
 
 ## Suggested Improvement
 -What should improve in Thob?
+  - Allow one button to trigger bundled multi-component updates in one action.
+  - Ensure updates happen simultaneously (or visually instant) for all linked props.
+  - Improve binding UX so multi-target mappings are easy to build and verify.
 -Is it:
   - editor
-  -runtime
-  -component
   - UX
-  -schema/data
+  - component
 
 ## Difficulty Estimate
--Easy / Medium / Hard
+-Medium
 
 ## Business Value
--Low / Medium / High
+-High
 
 ## Recommendation
-Should Thob support this better? Why?
+Yes, Thob should support this better because state-based visibility and framing transitions are common in demos and guided presentations. Reliable one-click synchronized updates would significantly improve real project usability.

Week-2/Task-2/builder/BuilderNotes.md

@@ -0,0 +1,77 @@
+# Builder Notes (Thob) — Task 2: Scene State Switching
+
+## Thob Observations from Task Notes
+
+- **Possible:** Partial
+- **Implementation used:** Combinations of object visibility states and Perspective Camera positions, with button-based switching attempts.
+- **What worked as expected:**
+	- Visibility states can be configured for multiple objects.
+	- Camera position presets can be prepared for different scene views.
+	- Base scene composition is quick to assemble in the editor.
+- **Main limitation observed:**
+	- One button updating multiple targets (visibility + transforms + camera) is not consistently reliable.
+	- Updates should happen simultaneously (or fast enough to feel instant), but current behavior can feel staggered/inconsistent.
+	- Button binding flow remains hard to reason about for multi-prop state orchestration.
+- **Builder flow used:**
+	1. Create scene objects and set initial visibility/transform states.
+	2. Add Perspective Camera and set target positions per scene state.
+	3. Add state buttons in UI.
+	4. Attempt to bind each button to all required prop updates.
+	5. Validate whether transitions are synchronized and repeatable.
+- **Complexity:** Hard
+- **Main limitation signals:** Editor UX + Event system + Runtime stability concerns.
+- **Workaround status:** Partial workaround only (manual or simplified transitions; full one-click synchronized switching is not dependable yet).
+
+## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning
+
+### warn: `Found both blacklist and siteRules — using siteRules`
+- **Type:** Configuration precedence warning.
+- **Probable meaning:** Multiple rule sets are available and runtime is choosing one path (`siteRules`).
+- **Impact:** Usually low, but indicates overlapping configuration paths.
+
+### warn: `... changing from uncontrolled to controlled` and `RadioGroup is changing from uncontrolled to controlled`
+- **Type:** React state-management warning.
+- **Probable meaning:** UI controls start with unstable values and later switch to controlled mode.
+- **Impact:** Property panel/control behavior can become inconsistent during binding setup.
+
+### warn: `Permissions-Policy header: Unrecognized feature: 'browsing-topics'`
+- **Type:** Browser/header compatibility warning.
+- **Probable meaning:** Response headers include unsupported policy directives for current browser.
+- **Impact:** Low direct impact on scene logic; mostly environment noise.
+
+### warn: `Unchecked runtime.lastError: The message port closed before a response was received`
+- **Type:** Browser runtime/extension messaging warning.
+- **Probable meaning:** A message channel closed before callback completion.
+- **Impact:** Usually non-fatal, but adds noise and can complicate debugging.
+
+### warn: `GetBindingData<id> method already registered` (repeated)
+- **Type:** Duplicate registration warning.
+- **Probable meaning:** Binding handlers are being registered repeatedly across rerenders/remounts.
+- **Impact:** High relevance for this task; can cause duplicate triggers and unreliable button-driven state updates.
+
+### warn: `update-static-component-prop method already registered`
+- **Type:** Duplicate update pipeline warning.
+- **Probable meaning:** Static prop update handler is attached more than once.
+- **Impact:** Can produce repeated writes and non-atomic multi-prop transitions.
+
+### warn: `resetPOI method already registered`
+- **Type:** Duplicate command registration warning.
+- **Probable meaning:** Camera/POI reset command is mounted multiple times.
+- **Impact:** Camera behavior may drift or feel inconsistent during state switching.
+
+### error: `Failed to load resource: 404`
+- **Type:** Network/resource error.
+- **Probable meaning:** Missing/stale project asset or endpoint.
+- **Impact:** Can partially break expected editor/preview behavior.
+
+### error: `THREE.WebGLRenderer: Context Lost`
+- **Type:** Graphics runtime error.
+- **Probable meaning:** WebGL context dropped due to resource pressure, remount loops, or browser/GPU reset.
+- **Impact:** Preview instability can invalidate transition testing.
+
+## Overall Read
+
+- Task 2 concept is achievable in thob at a basic level: visibility and camera state combinations can be authored.
+- The key product gap is synchronized execution: one button should apply all linked updates simultaneously, but current binding behavior is not reliably atomic.
+- Recurring duplicate-registration warnings strongly match the interaction issues seen during multi-prop button setup.
+- Improving binding lifecycle stability and one-click bundled updates should be the highest priority for this task pattern.