# Builder Notes (Thob) — Task 3: Step-Guided Camera and Object State Flow

## Thob Observations from Task Notes

- **Possible:** Partial
- **Implementation used:** Perspective Camera with Make Default toggle, object visibility toggles, and attempted button bindings for step transitions.
- **What worked as expected:**
	- Camera can be set as default quickly.
	- Object visibility/state can be adjusted manually.
	- Basic static scene states can be assembled in the editor.
- **Main limitation observed:**
	- One button driving multiple prop updates (camera + objects) is difficult to configure reliably.
	- Button-to-prop mapping is not intuitive for multi-step behavior.
	- Could not complete a fully reliable end-to-end guided step interaction purely in current builder flow.
- **Builder flow used:**
	1. Add Perspective Camera and toggle Make Default.
	2. Add scene objects and configure visibility/transform states.
	3. Create step buttons.
	4. Attempt to bind each button to camera and object prop changes.
	5. Validate step transitions and check repeatability.
- **Complexity:** Hard
- **Main limitation signals:** Editor UX + Event system + Runtime stability concerns.
- **Workaround status:** Partial workaround only (manual/static states are possible; robust step orchestration via button bindings remains difficult).

## Console Warnings/Errors Seen (Deduplicated) and Probable Meaning

### warn: `Found both blacklist and siteRules — using siteRules`
- **Type:** Configuration precedence warning.
- **Probable meaning:** Two policy/rule sources are present and runtime is choosing `siteRules`.
- **Impact:** Usually non-blocking, but indicates overlapping config paths.

### warn: `undefined is changing from uncontrolled to controlled` and `RadioGroup is changing from uncontrolled to controlled`
- **Type:** React state-management warning.
- **Probable meaning:** Controls mount with unstable/default values, then switch to controlled values.
- **Impact:** Can cause inspector/control jitter and unreliable interaction setup.

### warn: `Permissions-Policy header: Unrecognized feature: 'browsing-topics'`
- **Type:** Browser/header compatibility warning.
- **Probable meaning:** Response header contains a policy directive unsupported by the current browser.
- **Impact:** Low direct impact on scene logic; mostly environmental 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:** Typically low for core feature behavior; adds noise during debugging.

### warn: `GetBindingData<id> method already registered` (repeated)
- **Type:** Duplicate registration warning.
- **Probable meaning:** Binding handlers are re-registered on rerenders/remounts/reconnects without cleanup.
- **Impact:** High for this task because step-driven interactions depend on stable bindings; duplicates can trigger repeated or inconsistent updates.

### warn: `update-static-component-prop method already registered`
- **Type:** Duplicate update pipeline warning.
- **Probable meaning:** Static prop update method is attached multiple times.
- **Impact:** Can cause repeated writes and make multi-prop step transitions unreliable.

### warn: `resetPOI method already registered`
- **Type:** Duplicate command registration warning.
- **Probable meaning:** Camera/POI reset command handler is mounted repeatedly.
- **Impact:** Camera state may jump/drift, reducing confidence in guided camera steps.

### error: `Failed to load resource: the server responded with a status of 404 ()`
- **Type:** Network/resource error.
- **Probable meaning:** A required project/resource endpoint is missing or stale.
- **Impact:** Missing resources can break expected editor behavior and complicate reproduction.

### 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/blackouts can invalidate interactive step-flow testing.

## Overall Read

- Task 3 behavior is partially achievable in thob: static setup and manual state toggles work, but robust multi-step interaction wiring is still difficult.
- The repeated registration warnings (`GetBindingData`, `update-static-component-prop`, `resetPOI`) strongly align with the core issue: unstable button-driven multi-prop updates.
- Controlled/uncontrolled warnings indicate editor form-state instability, which likely contributes to confusion during binding setup.
- Runtime instability signals (`404`, `Context Lost`) reduce trust during validation and should be addressed alongside interaction UX improvements.