# Chanora SysRS — System Requirements Specification **Product name:** Chanora **Document type:** SysRS / System Requirements Specification **Version:** 0.9.11 **Status:** Baseline Candidate **Product category:** Cross-platform voice client application **Architecture:** Flutter + Rust Core **Protocol library:** `tsclientlib` **Target client platforms:** Windows, macOS, Linux, iOS, Android **Source material:** Initial Chanora application-system requirements draft **Supersedes:** Earlier mixed SYS/SRS draft **Repo path:** `docs/requirements/sysrs.md` --- ## 1. Document Control ### 1.1 Purpose This document is the **System Requirements Specification (SysRS)** for the **Chanora application system**. Chanora is an **application**, not an operating system. In this document, the word **system** means the complete application system and its runtime environment: - The Chanora client application - The Flutter user interface - The Rust Core - The `tsclientlib` protocol adapter - Platform adapters - Local and secure storage - Audio input/output devices used by the application - Operating system services used by the application - Network connectivity required by the application - External TeamSpeak 3-compatible servers used by the application - Deployment, diagnostics, and support processes The SysRS covers the whole environment required for the application to run correctly. It does not claim that Chanora is an operating system. --- ### 1.2 SysRS vs Software SRS A software-only SRS would focus mainly on the application code. This SysRS includes both application requirements and runtime environment requirements, including: - Client device requirements - Operating system service requirements - Audio hardware requirements - Network requirements - External compatible server requirements - Deployment requirements - Security and privacy requirements - Diagnostics and support requirements --- ### 1.3 Requirement ID Convention Every normative requirement uses this format: ```text SysRS-XXX ``` Where `XXX` is a three-digit sequential number. Requirement keywords: | Keyword | Meaning | |---|---| | shall | Mandatory | | should | Strongly recommended | | may | Optional | | shall not | Prohibited | Priority values: | Priority | Meaning | |---|---| | P0 | Required for MVP | | P1 | Required for Beta | | P2 | Required for Production | | P3 | Future or optional | Verification methods: | Method | Meaning | |---|---| | Review | Verified by reviewing documentation, requirements, or design | | Inspection | Verified by inspecting code, configuration, packaging, or environment setup | | Test | Verified by automated or manual test | | Demo | Verified through a working demonstration | | Audit | Verified through security, privacy, legal, or compliance review | --- ### 1.4 Input Reference Documents | Document | Description | |---|---| | Initial Chanora application-system requirements draft | Source material used to prepare this SysRS | ### 1.5 Downstream Lifecycle Documents The downstream engineering documentation sequence shall be: ```text SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification ``` This SysRS is the system-level requirements baseline. Downstream documents shall be derived from this SysRS and shall not override it unless the SysRS is formally revised. | Order | Document | Purpose | |---:|---|---| | 1 | SysRS — System Requirements Specification | Defines whole application-system requirements, including client application behavior, runtime environment, devices, networks, external compatible servers, security, deployment, diagnostics, and operational constraints. | | 2 | SysDes — System Design Specification | Defines system-level design and allocation of SysRS requirements to system elements such as Flutter UI, Rust Core, protocol adapter, audio subsystem, platform adapters, storage, diagnostics, external servers, and deployment environment. | | 3 | SRS — Software Requirements Specification | Defines software-only requirements for the Chanora software components derived from the SysRS and SysDes. | | 4 | SAD — Software Architecture Description | Defines software architecture views, major software components, interfaces, runtime flows, dependency rules, and architectural decisions. | | 5 | SDD — Software Detailed Design | Defines detailed module design, APIs, data structures, state machines, database schemas, DTOs, bridge contracts, and implementation-level design details. | | 6 | Verification | Defines verification plans, test cases, acceptance criteria, traceability matrices, platform compatibility tests, security checks, audio validation, and release validation. | Potential downstream file names: | Document | Suggested file | |---|---| | SysDes | `docs/chanora_SysDes.md` | | SRS | `docs/chanora_SRS.md` | | SAD | `docs/chanora_SAD.md` | | SDD | `docs/chanora_SDD.md` | | Verification | `docs/chanora_Verification.md` | --- ## 2. System Overview ### 2.1 Application Context ```text ┌─────────────────────────────────────────────────────────────────────────────┐ │ User Runtime Environment │ │ │ │ ┌────────────────────┐ ┌─────────────────────────────────────────┐ │ │ │ Audio Hardware │<----->│ Chanora Client Application │ │ │ │ Mic / Headset │ │ │ │ │ │ Speakers / BT │ │ Flutter UI │ │ │ └────────────────────┘ │ Flutter State Layer │ │ │ │ Bridge Layer │ │ │ ┌────────────────────┐ │ Rust Core │ │ │ │ OS Services │<----->│ tsclientlib Protocol Adapter │ │ │ │ Permissions │ │ Audio Processing Pipeline │ │ │ │ Secure Storage │ │ Local Storage │ │ │ │ Audio Session │ │ Diagnostics │ │ │ │ Notifications │ └─────────────────────────────────────────┘ │ │ └────────────────────┘ │ │ │ │ Network │ │ v │ │ ┌─────────────────────────────────────────┐ │ │ │ External TeamSpeak 3-compatible Server │ │ │ │ Channels / Clients / Voice / Text │ │ │ └─────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ### 2.2 System Boundary Inside the Chanora application system boundary: - Chanora client application - Flutter UI - Flutter state layer - Rust Core - Bridge layer - `tsclientlib` adapter - Audio processing pipeline - Local database - Secure storage adapter - Diagnostics and export tools - Platform service adapters Outside the Chanora application system boundary: - External TeamSpeak 3-compatible servers - Server administration and server-side permissions - Physical audio hardware - Operating system vendor services - App stores and package repositories - User-managed routers, firewalls, VPNs, NAT devices, and ISPs ### 2.3 Primary Runtime Flow ```text User action -> Flutter UI -> Bridge command -> Rust Core -> tsclientlib protocol adapter -> External compatible voice server -> Protocol event -> Rust Core state reducer -> Bridge event stream -> Flutter UI update ``` ### 2.4 Primary Audio Flow ```text Microphone -> OS/platform capture -> Audio preprocessing -> High-Pass Filter -> Noise Suppression -> Echo Canceller -> Automatic Gain Control -> Push-to-talk / mute gate -> Opus-compatible encoder -> tsclientlib protocol adapter -> External compatible server External compatible server -> tsclientlib protocol adapter -> Jitter buffer -> Opus-compatible decoder -> Per-user mute/volume -> Mixer -> OS/platform playback -> Speaker/headphones ``` ## 3. Application System Scope Requirements **SysRS-001**: The Chanora application shall be a cross-platform client application for channel-based voice communication. - Priority: P0 - Verification: Review **SysRS-002**: The Chanora application shall support Windows, macOS, Linux, iOS, and Android as target client platforms. - Priority: P0 - Verification: Review **SysRS-003**: The Chanora application shall use Flutter for the user-facing client interface. - Priority: P0 - Verification: Inspection **SysRS-004**: The Chanora application shall use Rust Core for protocol handling, connection management, state synchronization, audio processing, storage coordination, diagnostics, and business logic. - Priority: P0 - Verification: Inspection **SysRS-005**: The Chanora application shall use `tsclientlib` as the TeamSpeak-compatible protocol client library. - Priority: P0 - Verification: Inspection **SysRS-006**: The Chanora application shall operate as an independent client and shall not present itself as an official TeamSpeak product. - Priority: P0 - Verification: Audit **SysRS-007**: The Chanora application shall allow users to connect to TeamSpeak 3-compatible servers reachable from the client device network. - Priority: P0 - Verification: Test **SysRS-008**: The Chanora application shall allow users to participate in channel-based voice communication when the external server and user permissions allow it. - Priority: P0 - Verification: Test **SysRS-009**: The Chanora application shall allow users to send and receive supported text messages when the external server and user permissions allow it. - Priority: P0 - Verification: Test **SysRS-010**: The Chanora application shall provide local bookmark, recent server, identity reference, UI setting, and audio setting management on the client device. - Priority: P0 - Verification: Test ## 4. Stakeholder and User Environment Requirements **SysRS-011**: The Chanora application shall support end users who manually connect to compatible voice servers. - Priority: P0 - Verification: Demo **SysRS-012**: The Chanora application shall support regular users who rely on saved bookmarks, persistent identity, audio settings, and common voice controls. - Priority: P0 - Verification: Demo **SysRS-013**: The Chanora application shall support testers and support operators who export diagnostics for troubleshooting. - Priority: P1 - Verification: Demo **SysRS-014**: The SysRS shall provide requirements traceability suitable for engineering, QA, system administration, and release operations. - Priority: P1 - Verification: Review **SysRS-015**: The SysRS shall document external environment dependencies that may need administrator configuration, including network reachability and OS-level audio permissions. - Priority: P1 - Verification: Review ## 5. System Boundary and External Dependency Requirements **SysRS-016**: The Chanora application shall treat external TeamSpeak 3-compatible servers as external systems outside Chanora control. - Priority: P0 - Verification: Review **SysRS-017**: The Chanora application shall not require a Chanora-operated central server for MVP voice, channel, or text operation. - Priority: P0 - Verification: Review **SysRS-018**: The Chanora application shall not host or operate TeamSpeak-compatible server functionality in the MVP. - Priority: P0 - Verification: Review **SysRS-019**: The Chanora application shall rely on operating system services for microphone permission, secure storage, audio routing, notifications, and mobile lifecycle behavior. - Priority: P0 - Verification: Review **SysRS-020**: The Chanora application shall treat app stores, package repositories, installers, and update services as deployment environment components. - Priority: P1 - Verification: Review **SysRS-021**: The Chanora application shall treat physical microphones, speakers, wired headsets, USB audio devices, and Bluetooth audio devices as external hardware interfaces. - Priority: P0 - Verification: Review **SysRS-022**: The Chanora application shall treat routers, firewalls, VPNs, NAT devices, and ISPs as external network environment components. - Priority: P1 - Verification: Review **SysRS-023**: The Chanora application shall expose user-safe errors when external dependencies prevent successful operation. - Priority: P0 - Verification: Test ## 6. Application Component Requirements **SysRS-024**: The Chanora application shall include a Flutter UI component responsible for rendering screens, receiving user input, and presenting application state. - Priority: P0 - Verification: Inspection **SysRS-025**: The Chanora application shall include a Flutter State Layer responsible for UI state derived from Rust Core events. - Priority: P0 - Verification: Inspection **SysRS-026**: The Chanora application shall include a Bridge Layer responsible for commands, DTOs, asynchronous calls, and event streams between Flutter and Rust Core. - Priority: P0 - Verification: Inspection **SysRS-027**: The Chanora application shall include a Rust Core component responsible for authoritative connection, protocol, state, audio, storage, settings, and diagnostics behavior. - Priority: P0 - Verification: Inspection **SysRS-028**: The Chanora application shall include a protocol adapter component that isolates direct `tsclientlib` usage. - Priority: P0 - Verification: Inspection **SysRS-029**: The Chanora application shall include a state synchronization component that implements snapshot + delta state handling. - Priority: P0 - Verification: Inspection **SysRS-030**: The Chanora application shall include an audio subsystem component that coordinates capture, processing, encoding, decoding, jitter buffering, mixing, and playback. - Priority: P0 - Verification: Inspection **SysRS-031**: The Chanora application shall include a local storage component for non-secret data such as bookmarks, recent servers, UI settings, and audio settings. - Priority: P0 - Verification: Inspection **SysRS-032**: The Chanora application shall include a secure storage adapter for private identities, passwords, and future sensitive tokens. - Priority: P0 - Verification: Inspection **SysRS-033**: The Chanora application shall include a diagnostics component for structured logging, redaction, event recording, event replay, audio diagnostics, network diagnostics, and user-initiated export. - Priority: P1 - Verification: Inspection **SysRS-034**: The Chanora application shall include platform adapter components for desktop and mobile platform services. - Priority: P0 - Verification: Inspection ## 7. Client Device and Hardware Environment Requirements **SysRS-035**: The client device shall use a CPU architecture supported by Flutter, Rust, and the selected target platform. - Priority: P0 - Verification: Inspection **SysRS-036**: The client device shall provide sufficient CPU capacity to run the Chanora application, Opus-compatible voice processing, and enabled audio processing features in real time. - Priority: P0 - Verification: Test **SysRS-037**: The client device shall provide sufficient memory for the Chanora application to run without unbounded growth in logs, chat history, audio buffers, or event queues. - Priority: P0 - Verification: Test **SysRS-038**: The client device shall provide persistent local storage for Chanora application data, settings, logs, and cached metadata. - Priority: P0 - Verification: Inspection **SysRS-039**: The client device shall provide a microphone or supported audio input device for voice transmission. - Priority: P0 - Verification: Test **SysRS-040**: The client device shall provide speakers, headphones, or a supported audio output device for voice playback. - Priority: P0 - Verification: Test **SysRS-041**: The client device shall provide network connectivity to the selected compatible voice server. - Priority: P0 - Verification: Test **SysRS-042**: The desktop client environment should be validated on devices with at least 4 GB RAM for MVP operation. - Priority: P1 - Verification: Test **SysRS-043**: The desktop client environment should be validated with at least 500 MB free local storage for installation, settings, logs, and diagnostic bundle creation. - Priority: P1 - Verification: Test **SysRS-044**: The client device should provide stable audio device identifiers where the target platform supports persistent device selection. - Priority: P1 - Verification: Test **SysRS-045**: The client device should provide hardware or OS support for low-latency audio capture and playback. - Priority: P1 - Verification: Test **SysRS-046**: The client device should provide Bluetooth audio support where the target operating system supports it. - Priority: P1 - Verification: Test **SysRS-047**: The project shall document platform-specific hardware limitations discovered during compatibility testing. - Priority: P1 - Verification: Review ## 8. Operating System Service Requirements **SysRS-048**: The Windows runtime environment shall support native desktop window integration for the Chanora application. - Priority: P0 - Verification: Test **SysRS-049**: The Windows runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure credential storage to the Chanora application. - Priority: P0 - Verification: Test **SysRS-050**: The macOS runtime environment shall support native desktop window integration for the Chanora application. - Priority: P0 - Verification: Test **SysRS-051**: The macOS runtime environment shall provide microphone permission prompts, microphone capture, speaker/headphone playback, audio device selection, and Keychain access to the Chanora application. - Priority: P0 - Verification: Test **SysRS-052**: The Linux runtime environment shall support the desktop environments targeted by the selected release package. - Priority: P1 - Verification: Test **SysRS-053**: The Linux runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure storage through Secret Service, libsecret, or equivalent where available. - Priority: P1 - Verification: Test **SysRS-054**: The iOS runtime environment shall provide microphone permissions, foreground voice session capability, audio route change handling, audio interruption recovery, Keychain access, and AVAudioSession behavior to the Chanora application. - Priority: P0 - Verification: Test **SysRS-055**: The Android runtime environment shall provide microphone permissions, foreground voice session capability, foreground service behavior, audio focus, Bluetooth route handling, Android Keystore access, and production audio integration through AAudio, Oboe, or equivalent. - Priority: P0 - Verification: Test **SysRS-056**: The project shall define minimum supported operating system versions for each target platform before beta release. - Priority: P1 - Verification: Review **SysRS-057**: The project shall document OS-level permissions required by each target platform before public release. - Priority: P1 - Verification: Review **SysRS-058**: The Chanora application shall fail safely with a user-safe message when a required OS service is unavailable. - Priority: P0 - Verification: Test ## 9. Audio Hardware and Audio Processing Requirements **SysRS-059**: The Chanora application shall support microphone input for voice transmission. - Priority: P0 - Verification: Test **SysRS-060**: The Chanora application shall support speaker or headphone output for voice playback. - Priority: P0 - Verification: Test **SysRS-061**: The Chanora application shall support audio input and output device selection where the target platform exposes selectable devices. - Priority: P0 - Verification: Test **SysRS-062**: The Chanora application shall handle audio route changes where the target platform reports them. - Priority: P0 - Verification: Test **SysRS-063**: The Chanora application shall recover gracefully from audio device changes where possible. - Priority: P1 - Verification: Test **SysRS-064**: The Chanora application shall support Echo Canceller for reducing playback audio leaking into microphone input. - Priority: P0 - Verification: Test **SysRS-065**: The Chanora application shall support Automatic Gain Control for normalizing microphone input level. - Priority: P0 - Verification: Test **SysRS-066**: The Chanora application shall support Noise Suppression for reducing stationary background noise. - Priority: P0 - Verification: Test **SysRS-067**: The Chanora application shall support High-Pass Filter for reducing low-frequency rumble and handling noise. - Priority: P0 - Verification: Test **SysRS-068**: The Chanora application shall support an audio processing backend abstraction so platform-native and Rust-based processing can be selected per platform. - Priority: P1 - Verification: Review **SysRS-069**: The Chanora application shall allow Echo Canceller to use playback reference audio when the selected implementation requires it. - Priority: P0 - Verification: Test **SysRS-070**: The Chanora application shall expose audio processing settings to Rust Core and persist them locally. - Priority: P0 - Verification: Test **SysRS-071**: The Chanora application shall provide conservative default settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. - Priority: P0 - Verification: Review **SysRS-072**: The Chanora application shall allow platform-specific disabling of audio processing features when a feature is unstable or incompatible with a device configuration. - Priority: P0 - Verification: Test **SysRS-073**: The project shall provide an audio loopback test tool for development and compatibility testing. - Priority: P1 - Verification: Demo **SysRS-074**: The project shall provide an audio processing test tool for development and compatibility testing. - Priority: P1 - Verification: Demo ## 10. Network Environment Requirements **SysRS-075**: The client network environment shall provide IP network connectivity from the client device to the selected compatible voice server. - Priority: P0 - Verification: Test **SysRS-076**: The Chanora application shall allow the user to configure the server host or IP address. - Priority: P0 - Verification: Test **SysRS-077**: The Chanora application shall allow the user to configure the server port. - Priority: P0 - Verification: Test **SysRS-078**: The Chanora application should support a default TeamSpeak 3-compatible voice port when the user does not provide an explicit port. - Priority: P1 - Verification: Test **SysRS-079**: The client network environment shall permit the protocol traffic required by `tsclientlib` and the selected compatible server. - Priority: P0 - Verification: Test **SysRS-080**: The client network environment shall support latency suitable for real-time voice communication under expected operating conditions. - Priority: P0 - Verification: Test **SysRS-081**: The client network environment should minimize packet loss for acceptable voice quality. - Priority: P1 - Verification: Test **SysRS-082**: The Chanora application shall detect recoverable network failures where possible. - Priority: P0 - Verification: Test **SysRS-083**: The Chanora application shall enter reconnect behavior after recoverable network failures. - Priority: P0 - Verification: Test **SysRS-084**: The Chanora application shall rebuild server state from a fresh snapshot after reconnect. - Priority: P0 - Verification: Test **SysRS-085**: The Chanora application shall not require VPN connectivity unless the target server or user environment requires it. - Priority: P1 - Verification: Review **SysRS-086**: The Chanora application shall present network failures through user-safe error messages. - Priority: P0 - Verification: Test **SysRS-087**: The Chanora application should include network diagnostics in user-initiated diagnostic exports. - Priority: P1 - Verification: Inspection ## 11. External Compatible Server Requirements **SysRS-088**: The external voice server shall be TeamSpeak 3-compatible for Chanora MVP operation. - Priority: P0 - Verification: Test **SysRS-089**: The external voice server shall be reachable from the client device network. - Priority: P0 - Verification: Test **SysRS-090**: The external voice server shall permit client connection using the identity, nickname, password, and permissions supplied by the user. - Priority: P0 - Verification: Test **SysRS-091**: The external voice server shall expose server information required for initial synchronization. - Priority: P0 - Verification: Test **SysRS-092**: The external voice server shall expose channel listing required for the channel tree. - Priority: P0 - Verification: Test **SysRS-093**: The external voice server shall expose client listing required for the online client view. - Priority: P0 - Verification: Test **SysRS-094**: The external voice server shall support channel join operations for accessible channels. - Priority: P0 - Verification: Test **SysRS-095**: The external voice server shall emit channel movement events required for state synchronization. - Priority: P0 - Verification: Test **SysRS-096**: The external voice server shall emit client join and leave events required for state synchronization. - Priority: P0 - Verification: Test **SysRS-097**: The external voice server shall emit channel create, update, and delete events required for state synchronization where those events occur. - Priority: P0 - Verification: Test **SysRS-098**: The external voice server shall support channel text message send and receive where user permissions allow. - Priority: P0 - Verification: Test **SysRS-099**: The external voice server shall support voice packet send and receive where user permissions allow. - Priority: P0 - Verification: Test **SysRS-100**: The external voice server shall expose disconnect behavior or connection failure signals that can be mapped by the protocol adapter. - Priority: P0 - Verification: Test **SysRS-101**: The project shall document server-side permissions that can affect channel join, voice transmission, and text messaging. - Priority: P1 - Verification: Review ## 12. Application Functional Requirements **SysRS-102**: The Chanora application shall allow the user to manually connect to a compatible server. - Priority: P0 - Verification: Demo **SysRS-103**: The Chanora application shall allow the user to provide hostname or IP address, port, nickname, and optional server password before connection. - Priority: P0 - Verification: Demo **SysRS-104**: The Chanora application shall support persistent local identity for compatible server authentication. - Priority: P0 - Verification: Demo **SysRS-105**: The Chanora application shall display connection status to the user. - Priority: P0 - Verification: Demo **SysRS-106**: The Chanora application shall allow the user to disconnect from the active server connection. - Priority: P0 - Verification: Demo **SysRS-107**: The Chanora application shall display the server channel tree after synchronization. - Priority: P0 - Verification: Demo **SysRS-108**: The Chanora application shall display online clients after synchronization. - Priority: P0 - Verification: Demo **SysRS-109**: The Chanora application shall allow the user to join an accessible voice channel. - Priority: P0 - Verification: Demo **SysRS-110**: The Chanora application shall allow the user to send and receive channel text messages where permitted. - Priority: P0 - Verification: Demo **SysRS-111**: The Chanora application shall capture and transmit voice where permitted. - Priority: P0 - Verification: Demo **SysRS-112**: The Chanora application shall receive and play voice where permitted. - Priority: P0 - Verification: Demo **SysRS-113**: The Chanora application shall provide microphone mute control. - Priority: P0 - Verification: Demo **SysRS-114**: The Chanora application shall provide output deaf control. - Priority: P0 - Verification: Demo **SysRS-115**: The Chanora application shall provide push-to-talk control. - Priority: P0 - Verification: Demo **SysRS-116**: The Chanora application shall display microphone input level where available. - Priority: P0 - Verification: Demo **SysRS-117**: The Chanora application shall display speaking indicators where available. - Priority: P0 - Verification: Demo **SysRS-118**: The Chanora application shall allow users to save and reuse server bookmarks. - Priority: P0 - Verification: Demo **SysRS-119**: The Chanora application shall allow users to configure audio processing features. - Priority: P0 - Verification: Demo **SysRS-120**: The Chanora application shall allow users to export redacted diagnostics. - Priority: P1 - Verification: Demo ## 13. Protocol Integration Requirements **SysRS-121**: The Chanora application shall use `tsclientlib` inside the protocol subsystem. - Priority: P0 - Verification: Inspection **SysRS-122**: The Chanora application shall isolate direct `tsclientlib` calls inside the `chanora_protocol` component. - Priority: P0 - Verification: Inspection **SysRS-123**: The Chanora application shall prevent raw `tsclientlib` types from crossing into Flutter UI or Flutter State Layer. - Priority: P0 - Verification: Inspection **SysRS-124**: The Chanora application shall convert `tsclientlib` errors into Chanora protocol errors. - Priority: P0 - Verification: Test **SysRS-125**: The Chanora application shall convert `tsclientlib` events into internal protocol events. - Priority: P0 - Verification: Test **SysRS-126**: The Chanora application shall support future patching, replacement, or forking of protocol implementation without changing Flutter UI contracts. - Priority: P1 - Verification: Review **SysRS-127**: The project shall provide protocol compatibility test coverage for MVP features. - Priority: P1 - Verification: Test **SysRS-128**: The project shall include a protocol probe tool for validating target server compatibility. - Priority: P0 - Verification: Demo ## 14. State Synchronization Requirements **SysRS-129**: The Chanora application shall maintain one authoritative connection state per active server connection. - Priority: P0 - Verification: Test **SysRS-130**: The Chanora application shall synchronize state using a snapshot + delta model. - Priority: P0 - Verification: Test **SysRS-131**: The Chanora application shall emit a full snapshot after initial synchronization. - Priority: P0 - Verification: Test **SysRS-132**: The Chanora application shall emit delta events after live server-side changes. - Priority: P0 - Verification: Test **SysRS-133**: The Chanora application shall apply protocol events through deterministic reducers. - Priority: P0 - Verification: Test **SysRS-134**: The Chanora application shall preserve event ordering per connection. - Priority: P0 - Verification: Test **SysRS-135**: The Chanora application shall rebuild state from a fresh snapshot after reconnect. - Priority: P0 - Verification: Test **SysRS-136**: The Chanora application shall prevent Flutter from directly mutating server state. - Priority: P0 - Verification: Inspection **SysRS-137**: The Chanora application shall implement the defined connection state machine from Disconnected through Connecting, Synchronizing, Connected, and Reconnecting. - Priority: P0 - Verification: Test **SysRS-138**: The Chanora application shall not automatically reconnect after user-triggered disconnect. - Priority: P0 - Verification: Test **SysRS-139**: The project shall include an event replay tool for development and debugging of state synchronization. - Priority: P1 - Verification: Demo ## 15. Data and Storage Requirements **SysRS-140**: The Chanora application shall store server bookmarks locally. - Priority: P0 - Verification: Test **SysRS-141**: The Chanora application shall store recent servers locally. - Priority: P1 - Verification: Test **SysRS-142**: The Chanora application shall store audio settings locally. - Priority: P0 - Verification: Test **SysRS-143**: The Chanora application shall store UI settings locally. - Priority: P1 - Verification: Test **SysRS-144**: The Chanora application shall store per-user volume preferences locally where applicable. - Priority: P1 - Verification: Test **SysRS-145**: The Chanora application shall store muted user preferences locally where applicable. - Priority: P1 - Verification: Test **SysRS-146**: The Chanora application shall use SQLite or an equivalent embedded database for non-secret local data. - Priority: P0 - Verification: Inspection **SysRS-147**: The Chanora application shall use platform secure storage for sensitive data. - Priority: P0 - Verification: Audit **SysRS-148**: The Chanora application shall store identity private keys using platform secure storage. - Priority: P0 - Verification: Audit **SysRS-149**: The Chanora application shall store server passwords using platform secure storage. - Priority: P0 - Verification: Audit **SysRS-150**: The Chanora application shall not store private keys in plaintext files. - Priority: P0 - Verification: Audit **SysRS-151**: The Chanora application shall not write passwords to logs. - Priority: P0 - Verification: Audit **SysRS-152**: The Chanora application shall redact secrets from diagnostic exports. - Priority: P0 - Verification: Audit ## 16. Security and Privacy Requirements **SysRS-153**: The Chanora application shall store sensitive data using platform secure storage. - Priority: P0 - Verification: Audit **SysRS-154**: The Chanora application shall redact secrets from logs. - Priority: P0 - Verification: Audit **SysRS-155**: The Chanora application shall redact secrets from diagnostic bundles. - Priority: P0 - Verification: Audit **SysRS-156**: The Chanora application shall avoid exposing internal stack traces to normal users. - Priority: P0 - Verification: Test **SysRS-157**: The Chanora application shall validate user input before passing it to protocol operations. - Priority: P0 - Verification: Test **SysRS-158**: The Windows runtime environment shall support Windows Credential Manager, DPAPI, or equivalent secure credential storage for the Chanora application. - Priority: P1 - Verification: Inspection **SysRS-159**: The macOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. - Priority: P1 - Verification: Inspection **SysRS-160**: The iOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. - Priority: P0 - Verification: Inspection **SysRS-161**: The Android runtime environment shall support Android Keystore or equivalent secure credential storage for the Chanora application. - Priority: P0 - Verification: Inspection **SysRS-162**: The Linux runtime environment shall support Secret Service, libsecret, or equivalent secure storage where available. - Priority: P2 - Verification: Inspection **SysRS-163**: The Chanora application shall minimize collection of personal data. - Priority: P0 - Verification: Audit **SysRS-164**: The Chanora application shall require user action before exporting diagnostics. - Priority: P0 - Verification: Test **SysRS-165**: The Chanora application shall explain microphone permission usage before requesting permission where platform guidelines allow. - Priority: P0 - Verification: Test **SysRS-166**: The Chanora application shall explain notification permission usage before requesting permission where platform guidelines allow. - Priority: P1 - Verification: Test **SysRS-167**: The Chanora application shall not automatically upload diagnostics in MVP. - Priority: P0 - Verification: Audit ## 17. Diagnostics and Operations Requirements **SysRS-168**: The Chanora application shall produce structured diagnostic logs. - Priority: P0 - Verification: Inspection **SysRS-169**: The Chanora application shall support log redaction. - Priority: P0 - Verification: Audit **SysRS-170**: The Chanora application shall support protocol event recording in development or diagnostics mode. - Priority: P1 - Verification: Demo **SysRS-171**: The Chanora application shall support event replay for debugging state synchronization. - Priority: P1 - Verification: Demo **SysRS-172**: The Chanora application shall support audio diagnostics. - Priority: P1 - Verification: Demo **SysRS-173**: The Chanora application shall support network diagnostics. - Priority: P1 - Verification: Demo **SysRS-174**: The Chanora application shall support user-initiated diagnostic export. - Priority: P1 - Verification: Demo **SysRS-175**: Diagnostic export shall exclude or redact sensitive data. - Priority: P0 - Verification: Audit **SysRS-176**: The project shall document the expected support workflow for diagnostic bundle collection. - Priority: P2 - Verification: Review **SysRS-177**: The project shall include compatibility test tracking for supported platforms. - Priority: P1 - Verification: Inspection ## 18. Non-Functional Requirements **SysRS-178**: The Chanora application shall keep the UI responsive during connection, synchronization, and reconnect. - Priority: P0 - Verification: Test **SysRS-179**: The Chanora application shall avoid visible UI freezes longer than 100 ms during normal operation. - Priority: P0 - Verification: Test **SysRS-180**: The Chanora application shall minimize local audio pipeline latency. - Priority: P0 - Verification: Test **SysRS-181**: The Chanora application should target local audio pipeline latency under 100 ms where platform conditions permit. - Priority: P1 - Verification: Test **SysRS-182**: The Chanora application shall avoid unbounded memory growth in chat history. - Priority: P0 - Verification: Test **SysRS-183**: The Chanora application shall avoid unbounded memory growth in logs. - Priority: P0 - Verification: Test **SysRS-184**: The Chanora application shall avoid unbounded memory growth in audio buffers. - Priority: P0 - Verification: Test **SysRS-185**: The Chanora application shall avoid unbounded memory growth in event queues. - Priority: P0 - Verification: Test **SysRS-186**: The Chanora application shall perform required audio processing without sustained underruns on supported devices. - Priority: P0 - Verification: Test **SysRS-187**: The Chanora application shall keep reconnect processing non-blocking for UI interaction. - Priority: P0 - Verification: Test **SysRS-188**: The Chanora application shall recover from transient network loss where possible. - Priority: P0 - Verification: Test **SysRS-189**: The Chanora application shall recover gracefully from audio device changes where possible. - Priority: P1 - Verification: Test **SysRS-190**: The Chanora application shall isolate connection failures to the affected connection. - Priority: P1 - Verification: Test **SysRS-191**: The Chanora application shall avoid crashing on malformed or unexpected protocol events. - Priority: P0 - Verification: Test ## 19. Deployment and Release Environment Requirements **SysRS-192**: The project shall support Windows installer packaging for the Chanora application. - Priority: P1 - Verification: Demo **SysRS-193**: The project shall support macOS signed and notarized builds for the Chanora application. - Priority: P1 - Verification: Demo **SysRS-194**: The project shall support Linux packaging through AppImage, Flatpak, deb, rpm, or a selected subset. - Priority: P1 - Verification: Demo **SysRS-195**: The project shall support Android AAB release builds for the Chanora application. - Priority: P1 - Verification: Demo **SysRS-196**: The project shall support iOS TestFlight and App Store release builds for the Chanora application. - Priority: P1 - Verification: Demo **SysRS-197**: The project shall document platform signing, packaging, and release requirements before public release. - Priority: P1 - Verification: Review **SysRS-198**: The project shall ensure release metadata does not imply official TeamSpeak affiliation. - Priority: P0 - Verification: Audit **SysRS-199**: The project shall define release channels for internal, beta, and production builds before external testing. - Priority: P1 - Verification: Review ## 20. Interface Requirements **SysRS-200**: The Chanora application shall provide a user interface for manual server connection. - Priority: P0 - Verification: Demo **SysRS-201**: The Chanora application shall provide a user interface for bookmark management. - Priority: P0 - Verification: Demo **SysRS-202**: The Chanora application shall provide a user interface for channel tree navigation. - Priority: P0 - Verification: Demo **SysRS-203**: The Chanora application shall provide a user interface for chat. - Priority: P0 - Verification: Demo **SysRS-204**: The Chanora application shall provide a user interface for voice controls. - Priority: P0 - Verification: Demo **SysRS-205**: The Chanora application shall provide a user interface for audio processing settings. - Priority: P0 - Verification: Demo **SysRS-206**: The Chanora application shall provide a bridge interface between Flutter and Rust Core. - Priority: P0 - Verification: Inspection **SysRS-207**: The Chanora application shall provide a protocol interface between Rust Core and `tsclientlib`. - Priority: P0 - Verification: Inspection **SysRS-208**: The Chanora application shall provide an audio hardware interface through platform capture and playback adapters. - Priority: P0 - Verification: Test **SysRS-209**: The Chanora application shall provide secure storage interfaces through platform-specific secure storage mechanisms. - Priority: P0 - Verification: Audit **SysRS-210**: The Chanora application shall provide a network interface to external TeamSpeak 3-compatible servers through `tsclientlib`. - Priority: P0 - Verification: Test ## 21. System Constraints **SysRS-211**: The Chanora application shall not directly expose raw `tsclientlib` types to Flutter. - Priority: P0 - Verification: Inspection **SysRS-212**: The Chanora application shall not store private keys in plaintext files. - Priority: P0 - Verification: Audit **SysRS-213**: The Chanora application shall not write passwords to logs. - Priority: P0 - Verification: Audit **SysRS-214**: The Chanora application shall not imply official TeamSpeak affiliation in UI, documentation, or release metadata. - Priority: P0 - Verification: Audit **SysRS-215**: The Chanora application shall not automatically upload diagnostic information in MVP. - Priority: P0 - Verification: Audit **SysRS-216**: The Chanora application shall comply with iOS background execution policies. - Priority: P0 - Verification: Audit **SysRS-217**: The Chanora application shall comply with Android foreground service requirements for active voice sessions. - Priority: P0 - Verification: Audit **SysRS-218**: The MVP shall not require Chanora-operated backend infrastructure for voice, channels, or text. - Priority: P0 - Verification: Review ## 22. Assumptions **SysRS-219**: The selected `tsclientlib` version can support or be extended to support required MVP protocol features. - Priority: P0 - Verification: Review **SysRS-220**: Required audio processing features can be implemented through a combination of platform-native APIs, Rust DSP, and external audio processing libraries. - Priority: P0 - Verification: Review **SysRS-221**: Mobile foreground voice behavior is sufficient for MVP. - Priority: P0 - Verification: Review **SysRS-222**: Background voice behavior will remain constrained by iOS and Android platform policies. - Priority: P0 - Verification: Review **SysRS-223**: External compatible server administrators are responsible for server availability, permissions, and configuration. - Priority: P0 - Verification: Review **SysRS-224**: End users are responsible for providing valid server connection details and network access. - Priority: P0 - Verification: Review ## 23. Out of Scope for MVP **SysRS-225**: The MVP shall not include TeamSpeak-compatible server hosting functionality. - Priority: P0 - Verification: Review **SysRS-226**: The MVP shall not include full server administration functionality. - Priority: P0 - Verification: Review **SysRS-227**: The MVP shall not include a complete permission editor. - Priority: P0 - Verification: Review **SysRS-228**: The MVP shall not include a plugin system. - Priority: P0 - Verification: Review **SysRS-229**: The MVP shall not include 3D positional audio unless explicitly reprioritized. - Priority: P1 - Verification: Review **SysRS-230**: The MVP shall not include advanced whisper list management unless explicitly reprioritized. - Priority: P1 - Verification: Review **SysRS-231**: The MVP shall not include Server Query administration tools. - Priority: P0 - Verification: Review **SysRS-232**: The MVP shall not include automatic cloud sync of bookmarks, identities, settings, or diagnostics. - Priority: P1 - Verification: Review ## 24. Verification and Validation Requirements **SysRS-233**: The project shall maintain a requirements traceability matrix from SysRS requirements through SysDes, SRS, SAD, SDD, and Verification evidence. - Priority: P1 - Verification: Review **SysRS-234**: The project shall verify protocol compatibility through a protocol probe tool. - Priority: P0 - Verification: Demo **SysRS-235**: The project shall verify state synchronization through reducer tests and event replay tests. - Priority: P1 - Verification: Test **SysRS-236**: The project shall verify audio capture, processing, encode/decode, and playback through audio loopback and processing tests. - Priority: P1 - Verification: Test **SysRS-237**: The project shall verify secure storage behavior on every target platform before public release. - Priority: P1 - Verification: Audit **SysRS-238**: The project shall verify diagnostic redaction before enabling diagnostic export for external testers. - Priority: P1 - Verification: Audit **SysRS-239**: The project shall verify release packaging on every target platform before production release. - Priority: P1 - Verification: Demo **SysRS-240**: The project shall verify that public wording does not imply official TeamSpeak affiliation. - Priority: P0 - Verification: Audit ## 25. MVP Acceptance Requirements **SysRS-241**: The MVP shall connect to a TeamSpeak 3-compatible server using `tsclientlib`. - Priority: P0 - Verification: Demo **SysRS-242**: The MVP shall display the server channel tree. - Priority: P0 - Verification: Demo **SysRS-243**: The MVP shall display online clients. - Priority: P0 - Verification: Demo **SysRS-244**: The MVP shall allow the user to join a voice channel. - Priority: P0 - Verification: Demo **SysRS-245**: The MVP shall send voice. - Priority: P0 - Verification: Demo **SysRS-246**: The MVP shall receive voice. - Priority: P0 - Verification: Demo **SysRS-247**: The MVP shall support microphone mute. - Priority: P0 - Verification: Demo **SysRS-248**: The MVP shall support output deaf. - Priority: P0 - Verification: Demo **SysRS-249**: The MVP shall support push-to-talk. - Priority: P0 - Verification: Demo **SysRS-250**: The MVP shall support Echo Canceller. - Priority: P0 - Verification: Demo **SysRS-251**: The MVP shall support Automatic Gain Control. - Priority: P0 - Verification: Demo **SysRS-252**: The MVP shall support Noise Suppression. - Priority: P0 - Verification: Demo **SysRS-253**: The MVP shall support High-Pass Filter. - Priority: P0 - Verification: Demo **SysRS-254**: The MVP shall send and receive channel text messages. - Priority: P0 - Verification: Demo **SysRS-255**: The MVP shall save and reuse server bookmarks. - Priority: P0 - Verification: Demo **SysRS-256**: The MVP shall use secure storage for sensitive data. - Priority: P0 - Verification: Audit **SysRS-257**: The MVP shall export redacted diagnostic logs. - Priority: P1 - Verification: Demo --- ## 30. UI/UX, Material 3, Platform, and Internationalization Requirements This section extends the system requirement baseline for the Chanora application system. These requirements are system-level because they define externally observable application behavior, accessibility behavior, platform behavior, multilingual behavior, deployment-region behavior, and interoperability constraints. **SysRS-258**: The Chanora application system shall use Material 3 as the baseline design system for the Flutter client user interface. - Priority: P0 - Verification: Review, Inspection **SysRS-259**: The Chanora application system shall define a Chanora-specific design system above Material 3 for voice, connection, channel, latency, diagnostics, accessibility, and platform-adaptive states. - Priority: P0 - Verification: Review, Inspection **SysRS-260**: The Chanora application system shall support compact, medium, and expanded window classes for responsive client layout. - Priority: P0 - Verification: Test, Demo **SysRS-261**: The Chanora application system shall preserve visibility of connection status and primary voice controls across compact, medium, and expanded layouts. - Priority: P0 - Verification: Test, Demo **SysRS-262**: The Chanora application system shall provide screen-reader semantics for critical interactive controls and critical status indicators. - Priority: P0 - Verification: Test, Audit **SysRS-263**: The Chanora application system shall not communicate critical connection, voice, latency, permission, or error states by color alone. - Priority: P0 - Verification: Test, Audit **SysRS-264**: The Chanora application system shall support keyboard focus traversal and visible focus indication on desktop-class and tablet keyboard environments. - Priority: P1 - Verification: Test **SysRS-265**: The Chanora application system shall keep critical controls reachable when the user increases text size using platform accessibility settings. - Priority: P0 - Verification: Test **SysRS-266**: The Chanora application system shall respect platform safe areas, display cutouts, system bars, virtual keyboards, and desktop window insets. - Priority: P0 - Verification: Test **SysRS-267**: The Chanora application system shall provide platform-appropriate handling for Android system back navigation, including predictive-back-compatible behavior where supported by the platform. - Priority: P1 - Verification: Test **SysRS-268**: The Chanora application system shall provide platform-appropriate handling for iOS navigation gestures, safe areas, keyboard avoidance, haptics, and system permission presentation. - Priority: P1 - Verification: Test **SysRS-269**: The Chanora application system shall support localization of user-visible client application strings. - Priority: P0 - Verification: Inspection, Test **SysRS-270**: The Chanora application system shall externalize user-visible strings from source code into localization resources or an equivalent localization mechanism. - Priority: P0 - Verification: Inspection **SysRS-271**: The Chanora application system shall support English as the baseline product language. - Priority: P0 - Verification: Review, Test **SysRS-272**: The Chanora application system shall support adding additional product languages without changing protocol, audio, state synchronization, or storage architecture. - Priority: P1 - Verification: Review, Inspection **SysRS-273**: The Chanora application system shall preserve and display Unicode server names, channel names, client nicknames, and text messages received from compatible servers. - Priority: P0 - Verification: Test **SysRS-274**: The Chanora application system shall use UTF-8 internally for text exchanged between Flutter, Rust Core, local storage, diagnostics, and protocol-facing adapters unless a platform API requires conversion at the boundary. - Priority: P0 - Verification: Inspection, Test **SysRS-275**: The Chanora application system shall perform encoding conversion at explicit boundary adapters when external server, operating system, or platform APIs use a different text representation. - Priority: P1 - Verification: Inspection, Test **SysRS-276**: The Chanora application system shall not corrupt or drop multilingual Unicode content in logs or diagnostic exports, except where redaction intentionally removes sensitive content. - Priority: P0 - Verification: Test, Audit **SysRS-277**: The Chanora application system shall support bidirectional text display for user-visible localized strings and server-provided text where the platform text engine supports it. - Priority: P2 - Verification: Test **SysRS-278**: The Chanora application system shall support locale-aware formatting for dates, times, numbers, and diagnostic timestamps where those values are user-visible. - Priority: P1 - Verification: Test **SysRS-279**: The Chanora application system shall support fallback behavior when a translation key is missing. - Priority: P0 - Verification: Test **SysRS-280**: The Chanora application system shall keep machine-readable diagnostic fields stable and language-neutral while allowing user-facing diagnostic descriptions to be localized. - Priority: P1 - Verification: Inspection, Test **SysRS-281**: The Chanora application system shall separate product localization from server-provided content; server-provided names and messages shall be displayed as content, not translated by the client. - Priority: P0 - Verification: Review, Test **SysRS-282**: The Chanora application system shall support accessibility labels and localization for icon-only controls. - Priority: P0 - Verification: Test, Audit **SysRS-283**: The Chanora application system shall define a UI/UX guideline document as a downstream non-normative design baseline derived from this SysRS and SysDes. - Priority: P1 - Verification: Review **SysRS-284**: The Chanora application system shall define design tokens for color, typography, spacing, shape, elevation, motion, density, connection state, voice state, latency state, and diagnostics state. - Priority: P1 - Verification: Review, Inspection **SysRS-285**: The Chanora application system shall maintain traceability across the hierarchy `SysRS -> SysDes -> SRS -> SAD -> SDD` without allowing SRS, SAD, or SDD to bypass the immediately preceding lifecycle layer. - Priority: P0 - Verification: Review, Inspection ## 26. Glossary | Term | Definition | |---|---| | Chanora | Cross-platform voice client application | | Application system | The Chanora application plus runtime environment elements required for operation | | Client device | User device running the Chanora application | | Runtime environment | OS services, hardware, network, and external dependencies used by the application | | External compatible server | TeamSpeak 3-compatible voice server not operated by Chanora | | `tsclientlib` | Rust protocol library used for TeamSpeak-compatible protocol integration | | Rust Core | Shared Rust layer for protocol, state, audio, storage, diagnostics, and business logic | | Flutter UI | Cross-platform UI layer | | Platform adapter | OS-specific integration layer for audio, permissions, secure storage, lifecycle, and packaging | | Echo Canceller | Audio processing feature that reduces playback audio leaking into microphone input | | Automatic Gain Control | Audio processing feature that normalizes microphone input gain | | Noise Suppression | Audio processing feature that reduces background noise | | High-Pass Filter | Audio processing feature that reduces low-frequency noise | --- ## 27. SysRS Coverage Matrix | SysRS Area | Requirement Coverage | |---|---| | Product and application-system scope | SysRS-001 through SysRS-010 | | Stakeholder and user environment | SysRS-011 through SysRS-015 | | System boundary and external dependencies | SysRS-016 through SysRS-023 | | Application components | SysRS-024 through SysRS-034 | | Client device and hardware environment | SysRS-035 through SysRS-047 | | Operating system services | SysRS-048 through SysRS-058 | | Audio hardware and audio processing | SysRS-059 through SysRS-074 | | Network environment | SysRS-075 through SysRS-087 | | External compatible servers | SysRS-088 through SysRS-101 | | Application functional behavior | SysRS-102 through SysRS-120 | | Protocol integration | SysRS-121 through SysRS-128 | | State synchronization | SysRS-129 through SysRS-139 | | Data and storage | SysRS-140 through SysRS-152 | | Security and privacy | SysRS-153 through SysRS-167 | | Diagnostics and operations | SysRS-168 through SysRS-177 | | Non-functional requirements | SysRS-178 through SysRS-191 | | Deployment and release environment | SysRS-192 through SysRS-199 | | Interfaces | SysRS-200 through SysRS-210 | | Constraints | SysRS-211 through SysRS-218 | | Assumptions | SysRS-219 through SysRS-224 | | Out of scope for MVP | SysRS-225 through SysRS-232 | | Verification and validation | SysRS-233 through SysRS-240 | | MVP acceptance requirements | SysRS-241 through SysRS-257 | | UI/UX, Material 3, platform, i18n, and strict traceability | SysRS-258 through SysRS-285 | --- ## 28. Open Decisions | Decision ID | Area | Question | Default Recommendation | |---|---|---|---| | SysRS-DEC-001 | Mobile | Minimum supported iOS version | Decide before iOS implementation | | SysRS-DEC-002 | Mobile | Minimum supported Android version | Decide before Android implementation | | SysRS-DEC-003 | Connection | Multiple simultaneous server connections in MVP | Defer unless required | | SysRS-DEC-004 | Audio | Default Echo Canceller state per platform | Enable only after validation | | SysRS-DEC-005 | Audio | Default AGC state per platform | Enable with conservative settings | | SysRS-DEC-006 | Audio | Default Noise Suppression state per platform | Enable if quality is acceptable | | SysRS-DEC-007 | Audio | Default High-Pass Filter cutoff frequency | 80 Hz initial default | | SysRS-DEC-008 | Audio | Platform-native vs Rust audio processing per platform | Prefer best quality and lowest latency | | SysRS-DEC-009 | Legal | Official SDK licensing review before public distribution | Recommended | | SysRS-DEC-010 | Storage | Embedded database choice | SQLite or equivalent | | SysRS-DEC-011 | Bridge | Rust/Flutter bridge choice | `flutter_rust_bridge` initially | --- ## 29. Revision History | Version | Date | Description | |---|---|---| | 0.1.0 | 2026-05-13 | Initial application-system requirements draft | | 0.2.0 | 2026-05-13 | Converted software-only direction into application-system SysRS | | 0.3.0 | 2026-05-13 | Corrected terminology: Chanora is an application; SysRS covers the application system and runtime environment | | 0.4.0 | 2026-05-13 | Removed old SYS requirement references and standardized requirement IDs as SysRS-XXX | | 0.5.0 | 2026-05-13 | Moved implementation and design documents out of input references into downstream non-normative documents | | 0.6.0 | 2026-05-13 | Corrected downstream documentation lifecycle to SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification | | 0.7.0 | 2026-05-14 | Added Material 3, adaptive UI, accessibility, platform behavior, internationalization, Unicode, and strict lifecycle traceability requirements | --- ## 31. Platform Baseline, Release Policy, and Architecture Decision Requirements This section converts the baseline product decisions into auditable system-level requirements. **SysRS-286**: The Chanora application system shall support iOS runtime deployment on iOS 13 or later unless Flutter, plugin, audio, or platform constraints require raising the minimum version. - Priority: P0 - Verification: Review, Platform Test **SysRS-287**: For Apple App Store Connect upload on or after 2026-04-28, the Chanora iOS/iPadOS build shall be produced with Xcode 26 or later using the iOS 26 / iPadOS 26 SDK or later, unless Apple publishes a newer applicable upload requirement before upload. - Priority: P0 - Verification: Release Inspection **SysRS-288**: The Chanora Android application shall support Android API 28 (Android 9.0) or later as the minimum runtime baseline, per DEC-004 (Accepted 2026-05-14, which raised the original API 24 recommendation to API 28). The minimum may be raised further only if Flutter, plugin, audio, or platform constraints require it; it shall not be lowered without a superseding accepted decision. - Priority: P0 - Verification: Review, Platform Test **SysRS-289**: For Google Play submission, the Chanora Android build shall target the Android API level required by Google Play on the upload date. - Priority: P0 - Verification: Release Inspection **SysRS-290**: The Chanora MVP shall support one active server connection per client instance; multiple simultaneous active server connections shall be deferred outside MVP scope. - Priority: P0 - Verification: Review, System Test **SysRS-291**: The Chanora MVP shall enable Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter by default where supported and stable, while allowing user or platform policy to disable supported processing where applicable. - Priority: P0 - Verification: Audio Test, Review **SysRS-292**: The Chanora application system shall prefer platform-native audio processing for MVP where available and stable, with Rust/WebRTC-style audio processing retained as a controlled fallback or later architecture option. - Priority: P1 - Verification: Architecture Review, Audio Test **SysRS-293**: The Chanora application system shall use SQLite or an equivalent embedded local database for non-secret local state, while storing secrets only through platform secure storage. - Priority: P0 - Verification: Storage Test, Security Audit **SysRS-294**: The Chanora application system shall use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs; `flutter_rust_bridge` is the default candidate unless prototype evidence selects a better option. - Priority: P0 - Verification: Architecture Review, Integration Test **SysRS-295**: The Chanora MVP shall not perform automatic diagnostic upload, automatic telemetry upload, or automatic crash reporting unless a later approved decision updates privacy, security, legal, release, and verification documents. - Priority: P0 - Verification: Privacy Review, Security Audit **SysRS-296**: The Chanora desktop application shall support **Focused Push-to-Talk** on Windows, macOS, and Linux. Focused PTT is the minimum required behaviour: the user shall be able to hold a bound input (keyboard key, mouse button) inside the focused Chanora window to enable voice transmission, and release of that input shall disable voice transmission. - Priority: P0 - Verification: Platform Test, User Acceptance Test **SysRS-297**: The Chanora desktop application shall additionally support **Global Push-to-Talk** where the operating system, the user-granted permission set, the display server, and the available input backend together permit it. Where global PTT is not available, the application shall fall back to Focused PTT without claiming Global PTT support. - Priority: P0 - Verification: Platform Test, Architecture Review **SysRS-298**: The detected desktop PTT capability level shall be exposed to the user interface and to the release verification record. The exposed value shall match the actual runtime capability — the application shall not advertise a Global PTT level when the active backend is the Focused fallback. - Priority: P0 - Verification: Integration Test, Release Inspection **SysRS-299**: The Chanora Windows desktop application shall prefer the Raw Input backend for Global PTT, with a low-level keyboard hook used only as a fallback when Raw Input is unavailable, and Focused PTT used as the final fallback when no Global PTT backend can be initialised. - Priority: P0 - Verification: Platform Test (Windows), Architecture Review **SysRS-300**: The Chanora macOS desktop application shall request the operating-system permission required for Global PTT (Input Monitoring / Accessibility), use the permission-aware Global PTT backend when the permission is granted, and fall back to Focused PTT when the permission is denied, revoked, or not yet decided. The application shall not block voice functionality while the user decides on the permission prompt. - Priority: P0 - Verification: Platform Test (macOS), User Acceptance Test **SysRS-301**: The Chanora Linux desktop application shall use a capability-dependent Global PTT backend selected from the available display server (X11 or Wayland) and compositor support (GNOME on Wayland is the officially-tested target for the first public release per DEC-026; other compositors fall back to Focused PTT). The application shall not claim Global PTT support on an untested Linux environment. - Priority: P0 - Verification: Platform Test (Linux, GNOME Wayland), Architecture Review **SysRS-302**: The Chanora application system shall not log, store, persist, or include in the user-initiated diagnostic export any raw desktop key-event history, key code stream, or key-press timing sequence. Diagnostic export may include the detected PTT capability level, the active backend identifier, and the bound input class (for example "keyboard", "mouse-side-button"), but shall not include the specific key code, scan code, or virtual-key value of any user binding. - Priority: P0 - Verification: Privacy Review, Security Audit, Diagnostic Inspection **SysRS-303**: The Chanora application system shall define the v1 voice transmit mode set as `Ptt` and `Continuous`, with `VoiceActivity` reserved on the enum surface but unimplemented in this baseline (deferred per DEC-030). The default mode on a fresh install shall be `Ptt`; the user-selected mode shall be persisted per identity. The audio engine lifecycle shall be bound to voice-channel membership: input and output streams shall open on the user's first voice-channel join of the session and shall close on the last voice-channel leave, with no manual start affordance exposed at any system interface. The output stream shall open regardless of microphone-permission state so listen-only is a first-class flow. A user-facing hard-mute toggle shall force the transmit gate closed and shall override the active transmit mode, the PTT key state, and every other internal signal. - Priority: P0 - Verification: Functional Test, UX Review **SysRS-304**: The Chanora application system shall apply a configurable PTT release-tail interval between the moment the bound PTT input reports key-up and the moment the transmit gate closes, so that the trailing syllable of a spoken word is not clipped at word boundaries. The default release-tail value shall be 200 ms (matching the TeamSpeak / Mumble default); the user-configurable range shall be 0 ms through 500 ms inclusive. The release tail shall not affect the input-stream capture lifecycle; it shall affect only the transmit gate. - Priority: P0 - Verification: Functional Test, UX Review **SysRS-305**: When the Chanora Android application has an active voice session connected, the system shall engage the Android in-call audio mode (for example via `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The in-call mode shall be entered no later than the moment the voice session becomes connected and shall be released when the last active voice session ends. Back-fills the v0.9.8 product-decision-register entry that recorded `AudioManager.setMode(MODE_IN_COMMUNICATION)` engagement via JNI without prior SysRS coverage. - Priority: P0 - Verification: Platform Test (Android), Audio Test **SysRS-306**: The Chanora Android application shall acquire the Android runtime microphone permission (`RECORD_AUDIO`) at or before the point of voice session activation, and shall not begin microphone capture without that permission having been granted by the user. If the permission is denied, revoked, or not yet decided, the application shall remain functional in listen-only mode (consistent with SysRS-303) and shall surface a user-facing path to grant the permission before retrying transmit. This requirement is additive to the general permission obligation in SysRS-055 and makes the runtime-acquisition timing explicit. - Priority: P0 - Verification: Platform Test (Android), Functional Test **SysRS-307**: The Chanora project shall maintain measured numeric performance baselines for the realtime audio capture and playback paths. The baseline set shall include, at minimum: (i) heap allocation count per realtime audio callback measured after warmup, (ii) per-callback wall-clock time expressed as a fraction of (or absolute bound relative to) the audio frame period, (iii) Opus encode latency and Opus decode latency per frame, and (iv) resampler throughput at the common rate-pair conversions exercised by the audio pipeline. Each baseline shall be expressed as a numeric threshold (or numeric range), not as free-form prose, so that regression against the baseline is deterministically detectable by automated comparison. This requirement extends the prescriptive intent of SysRS-180 ("shall minimize local audio pipeline latency") and the directional target of SysRS-181 ("should target local audio pipeline latency under 100 ms") into a measurable, contract-grade obligation, and it is consistent with the underrun-avoidance obligation in SysRS-186. The specific baseline values, the warmup definition, the rate-pair set, and the storage format for the baselines are SysDes/SAD/SDD concerns and are not authored here. This clause does not authorize automatic upload, transmission, or off-device export of any measured baseline data and is therefore consistent with SysRS-295 (no automatic telemetry / diagnostic upload in MVP). - Priority: P0 - Verification: Test (SWE.4 benchmark assertions, delegated to verification layer; cross-references SysRS-236) **SysRS-308**: The Chanora project's continuous-integration workflow shall execute the realtime-audio benchmark suite on every pull request against the default branch and on every merge to the default branch, on at least one host architecture (Linux x86_64 on the existing GitHub Actions runner is sufficient to satisfy this clause), and shall report the comparison of the executed run against the maintained baselines (SysRS-307) in the pull request's status-check surface such that human reviewers can see, before approving the change, whether any baseline has regressed beyond the declared tolerance window (SysRS-309). The CI regression check authorized by this clause is **advisory only**: it shall NOT fail the CI build, shall NOT block merge, and shall NOT be treated as a hard quality gate at the P0-MVP stage. Its purpose is to surface evidence for human reviewer judgement and to avoid the failure mode in which a strict build-failing gate is bypassed under release-crunch pressure (e.g., "skip CI"). Escalation of this advisory tier to a build-failing hard gate is explicitly out of scope of SysRS-308 and shall be authorized only by a separate, later SysRS clause after a period of baseline maturity sufficient to establish that the advisory signal is stable and low-noise (indicative target: 4–6 weeks of clean baseline data on the default branch, but the actual escalation criteria are to be set by the future clause). This requirement is consistent with the CI-as-quality-evidence pattern established by the SysRS-234..239 verification family and does not displace any obligation in that family. This clause does not authorize off-device transmission of baseline measurements beyond the project's existing CI provider surface (i.e., GitHub Actions logs and PR status checks visible to repository collaborators); it is therefore consistent with SysRS-295. - Priority: P0 - Verification: Demo (CI workflow exercised on a representative PR; advisory status check appears and does not block merge on regression) **SysRS-309**: The advisory CI regression comparison authorized by SysRS-308 shall use an explicitly declared tolerance window — a numeric percentage (or a numeric per-metric percentage set) above the maintained baseline (SysRS-307) — beyond which the advisory check shall mark the run as a regression. The tolerance shall be a single declared value (or one declared value per metric), not an ad-hoc reviewer judgement, so that the advisory signal is reproducible. The specific numeric value(s) of the tolerance window and the comparison methodology (for example, "comparison against the most recent baseline snapshot on the default branch") shall be authored at the SysDes layer and may be refined at SAD/SDD; a suggested starting value of +20% over baseline is recorded here for downstream traceability but is not binding at the SysRS layer. Cross-references: SysRS-307 (the baselines being compared against), SysRS-308 (the advisory CI surface in which the comparison runs), SysRS-180/SysRS-181 (latency intent the tolerance must not silently erode), SysRS-295 (the tolerance window value is a project-local configuration and does not authorize off-device telemetry). - Priority: P0 - Verification: Review (SysDes/SAD declaration of tolerance value is present and is referenced by the CI workflow definition) **SysRS-310**: The Chanora application system shall support macOS runtime deployment on macOS 10.15 (Catalina) or later as the minimum supported runtime, unless Flutter, plugin, audio, or platform constraints require raising the minimum version. This clause ratifies at the SysRS layer the existing macOS baseline already encoded in `apps/chanora_flutter/macos/chanora_bridge.podspec` (`MACOSX_DEPLOYMENT_TARGET = 10.15`) and provides explicit cross-platform-baseline coverage parallel to SysRS-286 (iOS) and SysRS-288 (Android). Rationale: macOS 10.15 is the floor that supports the modern CoreAudio / AVAudioEngine voice-processing-IO surfaces relied on by the realtime audio path, native arm64 Apple Silicon builds (no Rosetta dependence), and the SDK version used by the existing podspec lipo step that produces the universal binary; a lower minimum would require backporting audio code paths or shipping a non-universal build, neither of which is in P0-MVP scope. The minimum may be raised further (for example, to macOS 11.0 / Big Sur for native Apple Silicon performance gains) only via a superseding accepted decision recorded as a DEC entry; it shall not be lowered without a superseding accepted decision. Cross-references: SAD-087 (architectural macOS runtime allocation), SDD-119 (macOS bridge build pipeline consuming this baseline), SysRS-286 (iOS minimum runtime parallel), SysRS-288 (Android minimum runtime parallel). ID-allocation note: this clause uses SysRS-310 rather than the structurally parallel SysRS-290 because SysRS-290 is already allocated (MVP single-active-server-connection scope); monotonic numbering convention is preserved. - Priority: P0 - Verification: Review (the SysRS baseline matches the podspec `MACOSX_DEPLOYMENT_TARGET` setting), Platform Test (the produced macOS binary runs on a macOS 10.15 system) ## 32. Change History Addendum | Version | Date | Description | |---|---|---| | 0.9.1 | 2026-05-14 | Added platform runtime baselines, Apple SDK submission gate, Android Play target gate, MVP connection scope, audio defaults, audio implementation path, local database, bridge, and diagnostics/crash reporting policy requirements. | ## Baseline Candidate 0.9.2 Update | Version | Date | Description | |---|---|---| | 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date to 2026-04-28 and propagated distinction between runtime deployment target and build-SDK upload gate. | ## Baseline Candidate 0.9.3 Update | Version | Date | Description | |---|---|---| | 0.9.3 | 2026-05-15 | Added desktop Push-to-Talk requirements SysRS-296 through SysRS-302: mandatory Focused PTT on Windows/macOS/Linux, capability-dependent Global PTT, capability-level exposure to UI and release record, Windows Raw Input + low-level-hook + Focused fallback ladder, macOS permission-aware Global PTT, Linux capability-dependent Global PTT (GNOME on Wayland officially-tested per DEC-026), and the privacy rule prohibiting raw key-event history in logs and diagnostic exports. Owner-resolved gen2 review questions PTT-OPEN-001..006 land as DEC-023..028 in the product decision register. | ## Baseline Candidate 0.9.5 Update | Version | Date | Description | |---|---|---| | 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle requirements SysRS-303 and SysRS-304 capturing the no-manual-start audio engine bound to voice-channel membership, the v1 transmit-mode set (`Ptt` default + `Continuous`, with `VoiceActivity` reserved per DEC-030), the listen-only flow (output independent of mic permission), the hard-mute override, and the 200 ms (0–500 ms) PTT release tail for word-boundary anti-clipping. | ## Baseline Candidate 0.9.9 Update | Version | Date | Description | |---|---|---| | 0.9.9 | 2026-05-17 | Reconciled SysRS-288 with DEC-004 (Accepted 2026-05-14): Android minimum runtime baseline raised from API 24 to API 28 (Android 9.0); rationale and decision citation added in-line. Verified SysRS-055, SysRS-161, SysRS-195, SysRS-217, and SysRS-289 remain consistent with DEC-004 (no API-level text in any of these; no rewrite required). Added SysRS-305 (Android in-call audio mode engagement during active voice session — back-fills the v0.9.8 product-decision-register `AudioManager.setMode(MODE_IN_COMMUNICATION)` entry) and SysRS-306 (explicit Android runtime microphone permission acquisition at or before voice session activation, additive to SysRS-055). | ## Baseline Candidate 0.9.10 Update | Version | Date | Description | |---|---|---| | 0.9.11 | 2026-05-18 | Closed the Wave 1.5 traceability-audit deferred-but-optional follow-up by adding SysRS-310 (macOS minimum runtime baseline at macOS 10.15 / Catalina), ratifying at SysRS layer the existing `apps/chanora_flutter/macos/chanora_bridge.podspec` `MACOSX_DEPLOYMENT_TARGET = 10.15` setting and providing explicit cross-platform-baseline coverage parallel to SysRS-286 (iOS) and SysRS-288 (Android). Allocated SysRS-310 rather than SysRS-290 because SysRS-290 is already taken (MVP single-active-server-connection scope); monotonic numbering convention preserved. No change to the numeric baseline value; any future raise (e.g., to macOS 11.0 / Big Sur for native Apple Silicon performance gains) is flagged as a DEC-level change, not authored here. | | 0.9.10 | 2026-05-18 | Authorized Option B of the benchmark-infrastructure decision for the realtime audio path. Added SysRS-307 (maintained numeric performance baselines for the realtime audio capture and playback paths — heap allocation count per callback after warmup, per-callback wall-clock budget relative to the audio frame period, Opus encode/decode latency, and resampler throughput at common rate-pair conversions; extends SysRS-180/SysRS-181 from prescriptive intent into a measurable contract; consistent with SysRS-186 and SysRS-236). Added SysRS-308 (advisory CI regression reporting executing the benchmark suite on every PR and every merge to the default branch on at least one host architecture, surfacing results in the PR status-check view; explicitly **advisory only** — does not fail the build, does not block merge; escalation to a build-failing hard gate is out of scope and deferred to a future SysRS clause after baseline maturity; consistent with the SysRS-234..239 verification-family pattern). Added SysRS-309 (explicitly declared numeric tolerance window for the advisory comparison; numeric value(s) and comparison methodology delegated to SysDes/SAD; suggested starting value +20% recorded as non-binding downstream guidance). All three new clauses are consistent with SysRS-295 (no automatic telemetry / diagnostic upload in MVP) — they neither authorize nor require off-device transmission of measurement data beyond the existing CI provider surface visible to repository collaborators. Explicitly **NOT** authored in this update: (a) Dimension 3 production telemetry export of timing histograms (deferred to P1; any future opt-in performance-evidence export through the user-initiated diagnostic-export path requires a separate P1 SysRS clause and must be reconciled with SysRS-295 at that time); (b) build-failing hard CI gate (deferred to a future SysRS clause). |