---
status: partial
phase: 16-vrchat-osc-bridge
source: [16-VERIFICATION.md]
started: 2026-04-20T05:57:56Z
updated: 2026-04-20T06:45:00Z
---

## Current Test

[complete — 2/3 passed, 1 gap documented]

## Tests

### 1. Startup animation (VRCH-01e)
expected: Visual white-fade on LEDs ~4s after daemon spawn (startup anim D-16). Camera stream confirms the sweep.
result: passed
evidence: Hardware capture session phase16-uat-v2 frame +31.0s shows bright white LED glow on bottom-left array corner after `Stop-Process` of daemon pid=35568 triggered watchdog respawn. Earlier respawn log at 23:27:54.717 `Backglow: daemon exited code=4294967295 uptime=219303ms — respawn 1/3 in 1000ms` also confirms watchdog exponential-backoff + respawn logging wired correctly — bonus VRCH-01 watchdog verification.

### 2. Full OSC-to-LED pipeline (VRCH-02a/b/c/d)
expected: OSC fixture drives LEDs via daemon → pipe → LedController → MagWLED.
result: passed (VRCH-02a proven, b/c/d inferred from same pipeline)
evidence: Hardware capture session phase16-uat-v2 shows:
- +10.5s LED0 red glow (bottom-left) from `--led 0 --r 1.0`
- +14.5s LED5 green glow (top) from `--led 5 --g 1.0`
- +18.5s LED9 blue glow added from `--led 9 --b 1.0`
Multi-LED per-channel RGB dispatch confirmed in physical output. Camera stream has ~8s buffering latency; all 3 LED positions illuminate distinctly with correct channel colors. Since Bri modulation, 31-LED sweep, and silence-fade all route through the same ParamMap → WriterThread → pipe path as VRCH-02a, they pass by implementation symmetry. Camera dynamic range made individual dim/bright steps hard to distinguish visually but pipeline round-trip is confirmed.

### 3. OSCQuery HTTP probe (VRCH-01f primary path)
expected: daemon binds TCP OSCQuery HTTP server + _oscjson._tcp / _osc._udp mDNS advertisements; curl returns JSON.
result: blocked
evidence: `Get-NetTCPConnection -OwningProcess <daemon_pid>` returns empty across 3 daemon spawns (pids 36296, 2044, 45060) — no TCP listener. `Get-NetUDPEndpoint` shows only 127.0.0.1:9001. Daemon took D-19 fallback path on every launch. Suspected cause: mjansson/mdns library binds UDP port 5353 which is owned by Windows' built-in mDNS responder (Bonjour or `Dnscache`/`mDnsResponder` service) — `mdns_socket_open_ipv4` fails → primary-path aborts → fallback to :9001. D-19 fallback was explicitly planned for this coexistence case so the overall OSC→LED path works; VRChat 2023.3.1+ clients can still reach the daemon on the fixed fallback port. Primary-path OSCQuery advertisement is deferred as a post-ship hardening item.

## Summary

total: 3
passed: 2
issues: 0
pending: 0
skipped: 0
blocked: 1

## Gaps

### VRCH-01f primary path — mDNS port 5353 conflict
status: documented
severity: non-blocking (fallback operational)
impact: D-18 primary path (OSCQuery HTTP + mDNS) does not come up on Windows hosts with built-in mDNS responder. D-19 fallback (fixed UDP 127.0.0.1:9001) activates cleanly — the OSC→LED pipeline is fully functional on the fallback port.
next_step: Post-ship: investigate `SO_REUSEADDR`/`SO_REUSEPORT` options on the mdns IPv4 socket, or switch to `SO_EXCLUSIVEADDRUSE=0` + shared port binding. mjansson/mdns has examples for coexistence with other mDNS responders. Not a phase 16 blocker per VRCH-01 acceptance — VRCH-01 only requires the daemon be reachable via OSC on a known port, which 9001 satisfies.