# Phase 11.1: Proximity Sensor App Compatibility Fix - Discussion Log

> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

**Date:** 2026-03-25
**Phase:** 11.1-proximity-sensor-app-compatibility-fix
**Areas discussed:** Root cause diagnosis, Fix mechanism, Scope of affected apps

---

## Root Cause Diagnosis

| Option | Description | Selected |
|--------|-------------|----------|
| No detection at all | Apps never see proximity state — they behave as if no proximity sensor exists | |
| Initial only, no updates | Apps detect the first state but don't respond to subsequent on/off changes | |
| Haven't tested yet | Based on user reports or suspicion | |

**User's choice:** Custom response — described two distinct failure modes:
- VRChat: behaves as though headset is always on, doesn't trigger AFK mode
- ET enrollment (Godot/OpenXR app): goes completely black once proximity/"person detected" triggers

**Follow-up: ET recovery behavior**

| Option | Description | Selected |
|--------|-------------|----------|
| Recovers on state change | Screen comes back when proximity toggles off | ✓ |
| Stays black permanently | App must be restarted | |
| Not sure | Haven't observed recovery | |

**User's choice:** Recovers on state change
**Notes:** ET enrollment black screen is a live state issue, not permanent. Screen goes black when person_detected=true, recovers when false — inverted behavior.

---

## Fix Mechanism

| Option | Description | Selected |
|--------|-------------|----------|
| Input component on HMD (Recommended) | CreateBooleanComponent("/proximity") on HMD container from sidecar | |
| Register minimal device | Add TrackedDeviceAdded for virtual device that owns proximity component | |
| Button events on HMD | Send k_EButton_ProximitySensor press/unpress via VRServerDriverHost on device 0 | |
| Spike all three | Test all mechanisms in a spike first | |

**User's choice:** Custom — do input component + button events simultaneously. Input component is continuous state, button events are rising/falling edge triggers. Both likely needed for different apps.

**Follow-up: Property toggling**

| Option | Description | Selected |
|--------|-------------|----------|
| Keep toggling (Recommended) | Don't risk breaking standby. Belt and suspenders. | |
| Set once, stop toggling | Set Prop_ContainsProximitySensor_Bool=true once at init. Cleaner semantics. | ✓ |

**User's choice:** Set once, stop toggling
**Notes:** Semantically correct approach — property is a capability flag, not state. Verify SteamVR standby still works; fallback to re-add toggling if regression.

---

## Scope of Affected Apps

| Option | Description | Selected |
|--------|-------------|----------|
| SteamVR standby/wake | Core v1.0 functionality — must not regress | ✓ |
| VRChat AFK detection | Should detect headset on/off correctly | ✓ |
| Beyond ET enrollment | Godot/OpenXR app should not go black | ✓ |
| General OpenXR/SteamVR apps | Broader compatibility target | |

**User's choice:** SteamVR standby/wake, VRChat AFK detection, Beyond ET enrollment
**Notes:** Three specific verification targets. General compatibility is nice-to-have but not required for this phase.

---

## Claude's Discretion

- Internal code organization for three-signal approach
- Error handling if CreateBooleanComponent fails on HMD container
- Timing of init calls relative to HMD availability
- Config toggle for property-toggling fallback

## Deferred Ideas

None — discussion stayed within phase scope