Validate D-Cerno API client against physical controller
Validate crates/televic against the user-provided local D-Cerno controller. User explicitly authorizes write operations, including enabling microphones. Exercise all implemented read/control endpoints and event polling/cursors, preserving evidence and fixing demonstrated contract mismatches. Add opt-in live tests without embedding credentials. Capture the initial state and restore microphone/request state after mutation tests; do not modify audio, recording, voting or system configuration. Acceptance criteria: - Live reads validate seat discovery, individual seats, discussion state, ordered speakers/requests and module discovery. - Live writes validate microphone activation/deactivation, request activation/deactivation, combined updates, and clearing speakers, delegates and requests, subject to available device capabilities. - Observe real event payloads and cursor/no-content behavior; keep any unverified aspects explicit. - Restore and verify initial state following tests, report any restoration failure immediately. - Mock regression tests, formatting, checks and Clippy pass. Keep secrets out of repository artifacts. Verified controller behavior and implementation decision: - API is served on the documented HTTP port 9080. Discovery reports two online units (delegate and chairperson) and one offline delegate. Invalid tokens return HTTP 403. - Firmware rejects a one-field seat PUT with HTTP 400 and the body "Missing json field: requestingToSpeak". This contradicts the published optional-field schema. Reproduced in a failing regression; partial updates now read the seat and send both flags. Explicit two-field updates remain a single PUT. Document the unavoidable read-modify-write race with physical buttons/other clients. - Mic/request activation/deactivation, combined updates, speaker order, delegate-only clear preserving the chair, clear-all speakers and clear requests passed against hardware. Real discussion events decoded; cursor continuation passed; an idle poll returned HTTP 204 after roughly 60 seconds. Initial all-off/empty-list state was restored and verified after failed and successful mutation runs. - Additional diagnostics and the reusable Rust live test confirm activating a queued mic consumes its request, and requesting while already speaking is normalized back to no request. Seat and list events can describe intermediate transitions; do not assume an atomic event order. Live state assertions check three consecutive matching reads before passing. - Final validation passed: both opt-in live tests ran serially against the controller, all 15 mock/model client tests and the compiled README example pass, Bosch regression tests pass, cargo fmt --all --check, cargo clippy -p televic --all-targets --offline -- -D warnings, cargo check --workspace --offline and git diff --check pass. Live tests are ignored by default and require explicit environment opt-ins. - Final physical-controller readback verified all three microphones off, no pending requests, and empty speaker/request lists. No settings outside microphone/request state were changed. The repository scan found neither the supplied key nor the hardware address in crate files. - No credentials are written to repository files. HTTPS, physical-button races, restarts and forced event-store discontinuity remain unverified on hardware.
Checklist
3 of 3 complete- Verify physical-controller reads and authentication using the Rust client; record actual event payloads and polling behavior.
- Exercise implemented write operations in an opt-in live test and restore/verify original microphone and request state.
- Add regressions for any hardware-discovered mismatches and pass formatting, check, Clippy and mock tests; preserve limitations.
- Area
- Streaming
- Project
- streaming-engines
- Kind
- Research
- Task ID
tsk_jg846dn8qv- Updated