diff --git a/Week-4/Task-2.md b/Week-4/Task-2.md
new file mode 100644
index 0000000..4e960c0
--- /dev/null
+++ b/Week-4/Task-2.md
@@ -0,0 +1,92 @@
+# Ansh Week 4 — Scene Priority Recommendations
+
+## 3 Quick Wins
+
+### 1) Binding Lifecycle Cleanup For Interaction Handlers
+- Problem
+	- Across Week 2 and Week 3 Tasks 2 and 3, repeated warnings like GetBindingData already registered, update-static-component-prop already registered, and resetPOI already registered strongly indicate duplicate handler registration.
+- Why it matters
+	- One trigger to many updates becomes inconsistent, causing missed or duplicated state changes in camera, visibility, and transforms.
+- Recommendation
+	- Enforce single registration per handler key with teardown on unmount/rerender.
+	- Add a lightweight runtime guard to log and skip duplicate registration attempts.
+- Expected user impact
+	- More reliable one-click scene changes and fewer random interaction failures.
+- Confidence level
+	- High
+
+### 2) Property Panel State Stability (Controlled/Uncontrolled)
+- Problem
+	- Repeated uncontrolled to controlled warnings in Week 2 and Week 3 suggest unstable form state in critical interaction setup flows.
+- Why it matters
+	- If controls are unstable, users lose trust while wiring multi-target actions.
+- Recommendation
+	- Standardize control initialization and enforce explicit default values for all bindable properties.
+	- Add immediate validation feedback when a binding value is invalid or incomplete.
+- Expected user impact
+	- Lower setup confusion, fewer broken bindings, and faster authoring for non-technical users.
+- Confidence level
+	- High
+
+### 3) Transition Controls For State And Step Switching
+- Problem
+	- Week 3 proved state and step switching can be reliable through prebuilt visibility states, but transitions are instant and feel abrupt.
+- Why it matters
+	- Instant jumps limit storytelling quality for demos, onboarding, and product explainers.
+- Recommendation
+	- Add per-action transition duration and easing for camera and transform changes.
+	- Keep visibility switches deterministic while interpolating transform and camera values.
+- Expected user impact
+	- Immediate quality lift in guided narratives without changing existing state authoring patterns.
+- Confidence level
+	- Medium-High
+
+## 2 Medium Features
+
+### 1) Atomic Multi-Target Action Bundles
+- Problem
+	- Tasks 2 and 3 repeatedly show that mapping one button to many coordinated updates is hard and often non-atomic.
+- Why it matters
+	- Real customer flows need camera plus visibility plus transform updates to happen together as one scene event.
+- Recommendation
+	- Introduce an action bundle model: one trigger, many target updates, single transaction apply.
+	- Include per-target success/failure reporting so users can debug quickly.
+- Scope estimate
+	- Medium
+- Risk
+	- Medium risk of edge cases around partial failures and rollback behavior.
+
+### 2) Perspective Camera Rotation Reliability Fix
+- Problem
+	- Week 2 and Week 3 Task 4 identified a critical issue: rotating the Perspective Camera can make objects disappear.
+- Why it matters
+	- This blocks confidence in guided camera storytelling, even when hierarchy and parent-child motion are otherwise strong.
+- Recommendation
+	- Prioritize camera rotation bug isolation and fix, then add regression tests for axis rotation and repeated step switching.
+- Scope estimate
+	- Medium
+- Risk
+	- Medium because root cause may involve rendering lifecycle, transform update order, or camera state sync.
+
+## 1 Deeper Architecture Concern
+
+### Missing First-Class Scene Orchestration Model
+- Problem
+	- Current reliable flows often depend on workarounds (prebuilt states plus visibility toggles) instead of a native orchestration system.
+- Why it matters
+	- The platform can set up scenes quickly, but advanced storytelling still struggles with reusable, debuggable, scalable interaction logic.
+- Why it is deeper than a quick fix
+	- This is not only a UI issue. It spans runtime state model, event execution semantics, transaction guarantees, and authoring ergonomics.
+- What kind of spike or investigation is needed
+	- Build a small orchestration spike with:
+		- Step bundle schema (camera, visibility, transforms, transition config)
+		- Atomic apply semantics with rollback strategy
+		- Debug panel showing exactly which target updates succeeded/failed
+		- Performance test on repeated rapid switching
+
+## Final Recommendation
+- If only one scene/architecture-facing thing should be built first, build atomic multi-target orchestration (one trigger to one transactional state change across camera, visibility, and transforms).
+- Why first:
+	- It addresses the most repeated pain across Task 2 and Task 3.
+	- It compounds value with existing strengths (fast visual setup and reliable hierarchy).
+	- It creates the foundation needed for smoother transitions and guided-flow primitives afterward.
\ No newline at end of file