Senior PHP\WebRTC Developer - Voice Translation & Accessibility Layer

***STOP*** Please review the 2 WORD DOCUMENTS ATTACHED FOR THE JOB SCOPE AND MILESTONES THAT WE WILL STRICKTLY FOLLOW HOTELHUB / OPERATIONSHUB Push-to-Talk (PTT) – Operational Accessibility Addendum v1.0 (Voice Accessibility / Dictation Enhancement Layer) Built Against: • Push-to-Talk Unified Master Scope v2.3 • Existing async transcription and translation infrastructure • Existing provider abstraction architecture Purpose This addendum introduces lightweight operational accessibility enhancements designed to reduce frontline communication friction and improve usability across multilingual and mobile-first hotel environments. This addendum is operationally focused and is NOT intended to create: • conversational AI systems • autonomous AI agents • always-listening assistants • floating voice assistants • surveillance functionality The purpose is strictly: • speak instead of type • listen instead of read • reduce operational hesitation • improve accessibility and communication comfort PART I — SPEECH-TO-TEXT (DICTATION SUPPORT) 1.1 Purpose Users may dictate operational content verbally instead of typing manually. 1.2 Supported Areas (v1) Dictation support may be used within: • Agenda task notes • Comments • Service requests • Chat input • PTT transcript assistance • Operational forms/notes (where text input exists) 1.3 UX Requirements • One-tap or hold-to-speak interaction • Mobile-first behavior mandatory • Must function on handheld and tablet devices • Transcribed text must appear for user review before submission • User may edit text before saving • No hidden submission behavior permitted 1.4 Architectural Requirements • MUST consume existing transcription/provider abstraction infrastructure • MUST remain provider-agnostic • MUST NOT hardcode AI/transcription vendors • MUST NOT block application responsiveness 1.5 Explicit Exclusions • No wake-word systems • No always-listening behavior • No conversational assistant layer • No autonomous AI actions • No emotion/sentiment analysis PART II — TEXT-TO-SPEECH (SCREEN NARRATION) 2.1 Purpose Users may listen to operational content instead of reading manually. 2.2 Supported Narration Areas (v1) Narration support may include: • Agenda tasks • SOP/instruction sections • Comments/notes • Service requests • Operational communications • Translated content playback 2.3 UX Requirements • One-tap playback interaction • Playback state visibility required • Pause/stop controls required • Must remain lightweight and fast • Mobile-first interaction mandatory 2.4 Translation Compatibility If translated content exists: • System may narrate translated output • Playback should align with user-selected/preferred language where possible 2.5 Operational Design Principle Narration exists to: • reduce operational friction • improve accessibility • support multilingual teams • improve frontline usability Narration must NOT: • interrupt workflows excessively • auto-play unexpectedly • create operational noise PART III — PERFORMANCE & RELIABILITY 3.1 Non-Blocking Requirement Narration and dictation functionality MUST: • remain asynchronous where appropriate • avoid blocking core execution workflows • fail gracefully without impacting Agenda/PTT execution 3.2 Failure Handling If narration or dictation fails: • system must surface visible failure state • user must retain ability to continue manual interaction • no data loss permitted PART IV — DEVICE & WRAPPER COMPATIBILITY 4.1 Wrapper Compatibility Functionality must remain compatible with: • Thin Native Container architecture • microphone permission handling • background/resume behavior • mobile operating system permission rules 4.2 Mobile Execution Doctrine Accessibility functionality must prioritize: • handheld execution • fast interaction • operational simplicity • low-friction usage PART V — NON-GOALS (LOCKED EXCLUSIONS) The following are explicitly excluded from this addendum: • full conversational AI assistant • autonomous workflow execution • floating assistant interfaces • always-on listening • AI-generated task completion • employee monitoring/scoring • personality-based assistants • complex voice-command engines PART VI — ACCEPTANCE CRITERIA Acceptance requires: • successful dictation into supported text fields • successful narration playback for supported content • mobile/tablet usability validation • no blocking of Agenda/PTT workflows • no cross-tenant leakage • provider abstraction compliance • graceful failure handling verification STRATEGIC INTENT This addendum exists to: • reduce communication friction • improve operational accessibility • support multilingual hotel environments • improve frontline adoption • enable hands-busy operational workflows This functionality is intended to support operational execution — not replace human decision-making or introduce conversational AI dependency.