SMART CONFERENCE ROOM 3.2.3.6 - VALIDATION REPORT
==================================================

BASELINE
--------
Smart Conference Room 3.2.3.5 Full Source
Branch: original full source, no SCR license runtime, no Windows Demo Builder

IMPLEMENTED SCOPE
-----------------
1. Atomic/consistent seat-layout + microphone mapping workflow across room profile,
   Central meeting snapshot, Room Agent and PC local session.
2. Stable saved checkbox/mapping state using seatMicRevision and stale-delta rejection.
3. Participant assignment remains meeting-specific and is not persisted in room profiles.
4. Unmatched/stale external microphone IDs are reported without silently deleting mappings.
5. DICENTIS Gateway loopback Web UI local-session authentication for simulator controls.
6. Client-token authentication remains mandatory for PC Server/external clients.
7. Bridge-token authentication remains separate and unchanged for dicentis-real-bridge.

STATIC VALIDATION
-----------------
JavaScript syntax                         : 193/193 PASS
Python syntax                             : 8/8 PASS
JSON parse before release manifest        : 18/18 PASS
Forbidden package/cache artifacts         : 0
Active SCR license runtime markers        : 0
Android STT source comparison             : 79/79 files byte-for-byte identical

TARGETED / REGRESSION VALIDATION
--------------------------------
Curated JavaScript + Python matrix         : 50/50 PASS
Synthetic long-meeting soak               : PASS
  - existing segments                     : 3,000
  - partial updates                        : 20,000
  - result                                 : coalesced without regression

The matrix includes:
- SCR 3.2.3.6 seat-mic profile source contract
- Central seat-mic transaction modes: apply_profile, update_profile, save_session
- SCR 3.2.3 and SCR 3.2.2 seat-profile regressions
- saved mapping/scroll/focus stability
- mic auto-assignment and anti-chairperson regression
- long-meeting delivery, inbound queue and incremental persistence
- editable minutes lifecycle
- login/bootstrap de-license contract
- runtime presence and Room Agent connectivity
- Modern/Classic navigation and UI operation feedback
- Voting, CR profile and DICENTIS source-isolation regressions
- Gateway local UI session static contract
- Gateway HTTP authorization contract with loopback cookie and forged-Origin rejection
- Room Agent and Central static/lifecycle tests
- CR JavaScript/Python regressions

GATEWAY AUTHORIZATION RESULTS
-----------------------------
POST without client token or local session          : 401 PASS
POST with valid Bearer client token                  : 200 PASS
GET loopback Web UI issues HttpOnly local cookie     : PASS
POST with loopback cookie + same Origin              : 200 PASS
POST with loopback cookie + forged Origin            : 401 PASS
Simulator/real-provider source isolation             : PASS

LIMITATIONS / REQUIRED WINDOWS ACCEPTANCE
-----------------------------------------
- The container does not contain the real npm `ws` dependency. The Gateway HTTP/local-session
  contract was executed with a minimal WebSocket API stub so the actual HTTP server could run.
- Real WebSocket frame exchange, dicentis-real-bridge and Bosch DICENTIS SDK were not live-tested.
- Final acceptance should run on Windows with installed npm dependencies, Chrome/Edge, Room Agent,
  PC Server, Central Server, Android and the intended DICENTIS simulator/real bridge.
- Recommended acceptance cases:
  1. Create a five-seat/five-mic profile; create a new meeting and verify all mappings load.
  2. Assign participants to seats and verify mic cards show the current participant names.
  3. Save mapping, reload browser, restart PC Server/Room Agent and verify mapping persists.
  4. Move one mic, save only for current meeting, then update selected profile and verify future meeting behavior.
  5. Reset simulator UUIDs and verify unmatched mapping warning without silent data loss.
  6. Open http://127.0.0.1:17880 without a token query and operate simulator buttons successfully.
  7. Verify PC Server still connects only with matching GATEWAY_CLIENT_TOKEN.
  8. Verify real bridge still connects only with matching GATEWAY_BRIDGE_TOKEN.

RELEASE PACKAGE PRECHECK
------------------------
JSON files including release manifest                : 19/19 PASS
Files represented by manifest (manifest self-excluded): 653
ZIP CRC and extracted-manifest verification           : performed after packaging; see delivery summary
