docs: task4 notes

Week-2/Task-4/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?
+	- Product assemblies where parts move together while keeping relative spacing.
+	- Educational and explainer scenes showing hierarchy and inheritance.
+	- Motion design layouts where one parent motion drives a cluster of elements.
 - Does Thob feel strong enough for this use case?
+	- Partial. The mesh-inside-mesh pattern works for parent-child inheritance, but Perspective Camera rotation seems broken because objects disappear no matter which rotation axis is used.
 - What would improve the experience?
+	- Fix Perspective Camera component rotation so scene objects do not disappear during camera rotation.
+	- Add reusable presets for common parent-child motion examples.
+	- Provide clearer step-state visualization for guided camera plus transform sequences.

Week-2/Task-4/TaskNotes.md

@@ -1,60 +1,95 @@
-# Task: [Feature Name]
+# Task: Parent Group Motion with Child Offset Inheritance
 
 ## Objective
-What is the feature trying to do?
+Build a step-based scene where a parent group is translated and rotated, while child meshes inherit those transforms and keep their relative spacing.
 
 ## Vanilla three.js
--Possible: Yes / Partial / No
+-Possible: Yes
 -Notes:
+  - Uses a parent group containing three child meshes.
+  - Step data controls camera position, look target, group position, group rotation, and spin speed.
+  - Animation loop lerps toward target transforms for smooth guided transitions.
 -Key concepts:
--Complexity: Easy / Medium / Hard
+  - Group hierarchy and transform inheritance
+  - Step-driven state config
+  - Camera and group interpolation
+  - Maintaining child local offsets under parent motion
+-Complexity: Medium
 
 ## R3F
--Possible: Yes / Partial / No
+-Possible: Yes
 -Notes:
+  - Uses a group with child meshes in declarative JSX.
+  - Step index in React state drives camera and parent group targets.
+  - useFrame performs smooth interpolation and optional spin per step.
 -What R3F abstracted:
--Complexity: Easy / Medium / Hard
+  - Render-loop integration through hooks
+  - Scene graph composition with nested components
+  - State-driven UI to scene updates
+-Complexity: Medium
 
 ## Thob Page Builder
--Possible: Yes / Partial / No
+-Possible: Partial
 -Notes:
+  - We can make things like this by following the simple mesh-inside-mesh design.
+  - Rotate the parent object, and children inherit the rotation and move with the parent while maintaining offset distance.
+  - This matches the same parent-child transform behavior used in vanilla and R3F.
+  - Perspective Camera component rotation feature appears broken right now: no matter how much camera rotation is changed on any axis, objects disappear.
 -Builder steps:
--Complexity: Easy / Medium / Hard
+  - Create a parent mesh/group container.
+  - Place child meshes inside it with different local positions.
+  - Animate or rotate only the parent transform to drive combined motion.
+  - Add camera positions per step if needed for guided presentation, but avoid camera rotation controls until this issue is fixed.
+-Complexity: Easy
 
 ## Comparison Summary
--Possible in all 3? Yes / Partial / No
+-Possible in all 3? Partial
 -Main differences:
+  - Vanilla is explicit and manual for hierarchy and animation wiring.
+  - R3F keeps hierarchy readable and state-driven.
+  - Thob can represent the same hierarchy visually with low setup effort, but camera rotation behavior blocks full parity.
 -Where Thob is better:
+  - Fast scene assembly for parent-child structures.
+  - Easier visual understanding of nested transforms.
 -Where Thob is weaker:
+  - Perspective Camera rotation currently causes objects to disappear.
+  - Fine-grained transition logic can still need extra workflow clarity.
 -What feels awkward or unclear:
+  - Managing more advanced multi-step timing and orchestration can become less obvious than code-first flow.
+  - Camera rotation controls are not reliable due to object disappearance.
 
 ## Limitation Type (if any)
 -[ ] Editor UX limitation
--[ ] Runtime limitation
+-[x] Runtime limitation
 -[ ] Schema / data model limitation
 -[ ] Component limitation
 -[ ] Event system limitation
 -[ ] Asset pipeline limitation
--[ ] Unknown / needs investigation
+-[x] Unknown / needs investigation
 
 ## Workaround
 -Is there a workaround?
+  - Partial workaround.
 -If yes, what is it?
+  - Keep parent/child group rotation for the main motion behavior.
+  - Avoid rotating the Perspective Camera component for now.
+  - Use camera position changes and look target adjustments instead of direct camera rotation.
 
 ## Suggested Improvement
 -What should improve in Thob?
+  - Fix Perspective Camera component rotation behavior so objects do not disappear when rotating on any axis.
+  - Optional guided presets for common parent-child motion patterns.
+  - Better timeline/state visualization for multi-step camera + transform storytelling.
 -Is it:
-  -editor
-  -runtime
-  -component
-  -UX
-  -schema/data
+  - editor
+  - runtime
+  - UX
 
 ## Difficulty Estimate
--Easy / Medium / Hard
+-Medium
 
 ## Business Value
--Low / Medium / High
+-High
 
 ## Recommendation
-Should Thob support this better? Why?
+Yes, Thob should support this strongly because parent-child transform inheritance is foundational for many real scenes, from product showcases to motion compositions. Priority should include fixing Perspective Camera rotation reliability first.

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

@@ -1,73 +1,67 @@
-# Builder Notes (Thob) — Task 4: Basic Rotation / Motion
+# Builder Notes (Thob) — Task 4: Parent-Child Group Motion
 
 ## Thob Observations from Task Notes
 
 - **Possible:** Partial
-- **Implementation used:** Applied available built-in animation presets on a cube/object inside thob builder.
+- **Implementation used:** Mesh-inside-mesh (parent with children offsets), parent rotation/motion, and Perspective Camera setup.
 - **What worked as expected:**
-	- Preset animation can be applied quickly.
-	- Basic motion effects are visible without writing code.
+	- Parent-child hierarchy setup is straightforward.
+	- Rotating the parent makes children inherit rotation while keeping offset distance.
+	- Basic grouped motion behavior is achievable visually.
 - **Main limitation observed:**
-	- Custom animation is not possible; only pre-provided animation can be applied.
-	- Exact motion parity with Vanilla/R3F frame-loop logic is not achievable from the builder controls.
+	- Perspective Camera rotation appears unreliable: objects disappear regardless of rotation axis changes.
+	- Because camera rotation is unstable, full parity with the planned step-guided camera behavior is blocked.
+	- Multi-step orchestration remains harder to validate when preview state is unstable.
 - **Builder flow used:**
-	1. Create/Add cube object in scene.
-	2. Open animation controls.
-	3. Apply available preset animation.
-	4. Tune exposed preset options (for example speed/intensity where available).
-- **Complexity:** Easy for preset motion, hard for custom motion requirements.
-- **Main limitation signals:** Editor UX + Runtime + Component concerns.
-- **Workaround status:** Partial workaround only (use nearest preset); no true custom per-frame animation authoring.
+	1. Create parent mesh/group container.
+	2. Add child meshes with local offsets.
+	3. Rotate/move parent to verify inheritance.
+	4. Configure Perspective Camera and test camera orientation adjustments.
+	5. Validate whether grouped motion plus camera framing can be repeated reliably.
+- **Complexity:** Easy for hierarchy behavior, Medium for complete camera-guided flow due runtime issues.
+- **Main limitation signals:** Runtime + Editor UX + Unknown investigation needed.
+- **Workaround status:** Partial workaround only (keep parent-driven motion, avoid direct camera rotation, prefer camera position/look target adjustments).
 
 ## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning
 
-### warn: `Permissions-Policy header unrecognized feature ('browsing-topics')`
+### warn: `Permissions-Policy header: Unrecognized feature: 'browsing-topics'`
 - **Type:** Browser/header compatibility warning.
-- **Probable meaning:** Response header includes a policy directive not recognized by the current browser engine.
-- **Impact:** Usually low for scene editing itself; mostly platform/header noise.
+- **Probable meaning:** Response includes a policy directive unsupported by current browser/runtime.
+- **Impact:** Usually low for core feature behavior; mainly environment-level noise.
 
 ### error: `GET https://builder.thob.studio/builder/<id> 404 (Not Found)`
 - **Type:** Network/resource error.
-- **Probable meaning:** Builder page/resource ID is stale, deleted, or inaccessible for current session.
-- **Impact:** High for workflow continuity; can block loading expected builder state.
+- **Probable meaning:** Builder project/resource URL is stale, missing, or inaccessible in the current session.
+- **Impact:** High for workflow continuity; can interrupt loading and testing stability.
 
 ### warn: `Unchecked runtime.lastError: The message port closed before a response was received`
-- **Type:** Browser extension/runtime messaging warning.
-- **Probable meaning:** A background messaging channel closed before callback response (often extension-related).
-- **Impact:** Usually low for core scene logic; can add debugging noise.
+- **Type:** Browser runtime/extension messaging warning.
+- **Probable meaning:** Background/bridge message channel closed before callback completion.
+- **Impact:** Usually non-fatal for scene logic, but adds debugging noise.
 
 ### warn: `No HydrateFallback element provided to render during initial hydration`
 - **Type:** Hydration/lifecycle warning.
-- **Probable meaning:** Initial hydration path expected a fallback UI element but none was configured.
-- **Impact:** Can produce unstable initial editor/preview rendering behavior.
+- **Probable meaning:** Hydration path expects a fallback UI but none is configured.
+- **Impact:** Can cause unstable initial render state in editor/preview panels.
 
-### warn: `... changing from uncontrolled to controlled` and `RadioGroup is changing from uncontrolled to controlled`
+### warn: `Found both blacklist and siteRules — using siteRules`
+- **Type:** Configuration precedence warning.
+- **Probable meaning:** Two rule sources are present, runtime picks one (`siteRules`).
+- **Impact:** Generally non-blocking, but indicates overlapping configuration surfaces.
+
+### warn: `undefined is changing from uncontrolled to controlled` and `RadioGroup is changing from uncontrolled to controlled`
 - **Type:** React state-management warning.
-- **Probable meaning:** Form/editor controls switch value ownership mode across renders.
-- **Impact:** Property panel behavior may become inconsistent or glitchy.
+- **Probable meaning:** Controls mount with undefined/default state and later become controlled.
+- **Impact:** Property controls may behave inconsistently, making camera/property tuning harder.
 
 ### warn: `GetBindingData<id> method already registered` (repeated)
 - **Type:** Duplicate registration warning.
-- **Probable meaning:** Binding method handlers are attached multiple times during rerender/remount cycles.
-- **Impact:** High log noise, risk of duplicated side effects, and potential performance degradation.
-
-### warn: `resetPOI method already registered`
-- **Type:** Duplicate command registration warning.
-- **Probable meaning:** Command/event handler is registered more than once without cleanup.
-- **Impact:** Risk of repeated command execution and state drift.
-
-### warn: `camera-controls: verticalDragToForward was removed...`
-- **Type:** API deprecation/removed option warning.
-- **Probable meaning:** Legacy camera-controls prop is still being used by some path in the runtime/editor.
-- **Impact:** Non-fatal now, but indicates outdated control configuration and future fragility.
-
-### error: `THREE.GLTFLoader: Invalid plugin found: missing name`
-- **Type:** Asset loader/plugin configuration error.
-- **Probable meaning:** GLTF loader plugin object does not satisfy required shape/metadata.
-- **Impact:** Asset loading behavior may be incomplete or fail for some models.
+- **Probable meaning:** Binding handlers are being registered repeatedly across rerenders/remounts without cleanup.
+- **Impact:** High log noise and risk of duplicate event executions, especially problematic for interactive scene controls.
 
 ## Overall Read
 
-- For Task 4, thob supports only preset motion and does not support custom animation logic, which is the core functional gap compared with Vanilla and R3F.
-- Console output shows repeated registration and controlled/uncontrolled warnings, which aligns with editor/runtime stability concerns when iterating quickly in builder.
-- The 404 page load and loader/control warnings suggest platform-level reliability and compatibility issues that can interfere with smooth motion-authoring workflows.
+- Task 4 core hierarchy behavior works in builder: parent rotation correctly drives child motion with preserved local offsets.
+- The major blocker is camera reliability: direct Perspective Camera rotation can make objects disappear, reducing feature parity confidence.
+- Repeated binding-registration and controlled/uncontrolled warnings suggest editor/runtime instability that can amplify interaction and camera issues.
+- Product priority for this task should focus on camera rotation reliability first, then interaction-state stability for repeatable multi-step scene authoring.