# 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.