edison/chanora
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
4d57d189c98eee27e21e5b5b8f849aaca538aeaf
chanora/docs/requirements/sysrs.md
T
EdisonJwa dfa84ee7bb docs(spec): baseline 0.9.5 — v1 audio + PTT lifecycle redesign 
Add SysRS-303/304, SysDes-149/150/151, SRS-204/205/206/207,
SAD-081/082/083, SDD-094/095/096/097, DEC-029/030.

Captures the v1 lifecycle redesign:
- Drop manual Start-audio button; audio engine is bound to voice-channel
  join/leave (ensure_running on first join, shutdown_if_idle on last
  leave). Output stream opens regardless of mic-permission state so
  listen-only is a first-class flow.
- TransmitMode enum (Ptt / Continuous / VoiceActivity-reserved).
  Default Ptt on fresh install. Persisted per identity.
- PTT release tail: 200 ms default (0-500 ms configurable) before
  transmit gate closes, avoiding clipped trailing syllables.
- Hard-mute toggle overrides transmit gate regardless of mode/PTT.
- Bridge surface: drop start_audio/stop_audio; add
  voice_join(channel_id) / voice_leave() and BridgeEvent::VoiceState.

DEC-029 rejects Flutter global-hotkey packages (hotkey_manager,
super_hot_key) for PTT: they wrap RegisterHotKey/RegisterEventHotKey
which consume the key and don't fire key-up, wrong primitive for PTT.
Native Rust DesktopPttBackend (SDD-083/084/085) stays authoritative.

DEC-030 defers Voice Activity Detection to P1. RMS / WebRTC VAD /
Silero VAD trade-off review (binary-size, dependency-surface, CPU
profile) postponed; TransmitMode::VoiceActivity reserved on the enum
surface so a P1 increment is non-breaking.

Validator clean: 304/151/207/83/97 IDs, strict layered sourcing
preserved, no new warnings beyond the pre-existing 35 old-package-name
filenames.
2026-05-15 22:46:51 +08:00

69 KiB
Raw Blame History

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

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

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.
Reference in New Issue View Git Blame Copy Permalink