chanora/docs/requirements/sysrs.md

Chanora SysRS — System Requirements Specification

Product name: Chanora
Document type: SysRS / System Requirements Specification
Version: 0.9.2 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:

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:

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

┌─────────────────────────────────────────────────────────────────────────────┐
│                         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

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

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 24 or later as the minimum runtime baseline unless Flutter, plugin, audio, or platform constraints require raising the minimum version.

• 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

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.