Files

T

Edison Jwa 2f6d45fb04 feat(audio): desktop Silero ONNX VAD + Windows PTT modernization + MSVC CRT build fix (#37 )

* feat(audio): add Silero ONNX VAD with WebRTC fallback

Introduce SileroOnnxVad and SileroOnnxVadWorker for desktop targets. The worker runs Silero v6 ONNX inference on a dedicated thread, accumulating 10 ms frames into the 512-sample 16 kHz input the model expects. Add VadOutput, VoiceActivityDetector trait, and WebRtcFallbackVad to provide a uniform VAD interface with graceful fallback when the ONNX model is unavailable. Wire the new VadBackend variants through AudioProcessingConfig and the snapshot stats so the bridge can report which detector is active.

* feat(audio): integrate desktop VAD worker into capture engine

Wire SileroOnnxVadWorker into the desktop capture path so voice activity can open the transmit gate before encoding. The capture callback now processes all audio through resample, downmix, and VAD unconditionally; transmit_active still gates Opus encoding.

Add new_desktop_audio_processing_state() to construct the config/stats/worker triple, and apply_desktop_vad_backend() to synchronously load or clear the worker on config changes. Override processing_backend to Noop for desktop so bridge diagnostics report the correct backend rather than the iOS-oriented PlatformVoiceProcessing default.

Includes review-driven cleanups: StreamConfig clone to deref per clippy, and a comment explaining why two try_lock calls on silero_vad_worker are structurally necessary (borrow checker requires the policy probe and the fallback path to not share a lock guard because mark_vad_fallback_active takes &mut self).

* fix(audio): modernize Windows PTT to current windows-rs API

Port the Raw Input plus low-level keyboard hook PTT backend to the newer windows-rs patterns: OptionalHandle, Result-returning CreateWindowExW, and None for CallNextHookEx. Replaces the old HHOOK(0) pointer casts. Add deterministic tests for mouse button 4 and 5 press and release driving the gate.

* build(windows): force MSVC release CRT for audiopus cmake builds

audiopus_sys calls cmake::build(opus_path), so downstream Cargo env cannot use cmake-rs Config::define() to override CMake's MSVC Debug CRT defaults. Point cmake-rs at a small wrapper that injects the policy and cache variables during configure while passing cmake --build, --version, and -E through unchanged. Keeps Opus Debug builds on Rust's release dynamic CRT (/MD) instead of CMake's default debug CRT (/MDd), which otherwise pulls in unresolved __imp__CrtDbgReportW symbols at test link.

Document that the iOS deployment target is intentionally absent from this file. It is enforced by tools/build-ios.sh and the Xcode project; setting it globally here would make native macOS cargo check runs try to link iPhone objects against the macOS SDK.

* build(flutter): update pubspec.lock after plugin additions

Regenerated lockfile reflecting the local_notifications and connectivity_plus plugin additions from the poke-notifications feature.

* fix(audio): address PR #37 review findings

Six fixes from independent PR review:

1. BLOCKER: Replace Windows-only cmake .cmd wrapper with cross-platform
CMake env vars. Setting CMAKE=tools/cmake-msvc-release-crt.cmd
globally broke non-Windows hosts because cmake-rs would try to
execute a .cmd file on macOS/Linux. Instead, set
CMAKE_POLICY_DEFAULT_CMP0091=NEW and CMAKE_MSVC_RUNTIME_LIBRARY=
MultiThreadedDLL as env vars that CMake reads natively. MSVC-
specific vars are safely ignored by GCC/Clang toolchains. Delete
the now-unnecessary wrapper script.

2. IMPORTANT: Join the Silero worker thread in Drop instead of
detaching it. The old code dropped the JoinHandle which detaches
the thread; the new code calls handle.join() after closing the
channel, ensuring the ONNX session is cleaned up before the
worker is replaced during config changes.

3. IMPORTANT: Single-try_lock refactor of the capture VAD callback.
The double try_lock (policy probe + send) is replaced by a single
scoped try_lock that both probes availability and sends the frame.
The guard is dropped before the fallback path, which needs &mut
self for mark_vad_fallback_active. This also eliminates the
VadWorkerPolicy enum and callback_vad_worker_policy function,
whose behavior is now inlined into the callback.

4. IMPORTANT: Remove tracing from the realtime capture callback.
mark_vad_fallback_active and sync_vad_backend emitted info!/warn!
from the audio thread. Replace with silent atomic state
publishing via SharedAudioProcessingStats; the bridge stats
stream already exposes vad_fallback_active for diagnostics.

5. IMPORTANT: Defer ONNX model load outside the worker mutex.
apply_desktop_vad_backend_to_worker now constructs the new worker
before taking the lock, then swaps it in under a short hold.
This prevents the realtime callback from being blocked during
model I/O + thread spawn.

6. MINOR: Remove unused VadBackend import from vad/mod.rs after
deleting the policy code.

* fix(audio): address PR #37 second-pass review findings

5-agent review found 5 blocking issues. All addressed:

1. BLOCKER: CMake env vars don't reach CMake cache. Restored .cmd wrapper
but scoped to Windows MSVC targets only via [target.x86_64-pc-windows-msvc]
and [target.aarch64-pc-windows-msvc] in .cargo/config.toml. Non-Windows
hosts are unaffected.

2. BLOCKER: processing_backend normalized in set_audio_processing_config
on desktop (cfg-gated override to Noop), mirroring startup default.

3. BLOCKER: Model-path reload was already wired via reload_audio_processing_config.
Fixed misleading doc comment in core/lib.rs.

4. BLOCKER: DEC-030 updated to reflect desktop VoiceActivity enablement.
Traceability docs (SRS, SysDes, SAD, SDD, implementation-status) updated.

5. Silero ONNX cfg narrowed to desktop-only (excludes macOS/Android).
Cargo.toml ort dependency target cfg narrowed similarly.

6. Realtime callback debt documented as TODO at CaptureState::ingest.

* fix(audio): exclude ort dep on Android target

ort does not provide first-class Android prebuilts in our pin, mirror the
iOS/macOS exclusion so cargo metadata succeeds for android targets.

* test(audio): fix stale select_ptt_backend import in ptt_privacy

The helper moved out of the ptt_backends submodule onto the crate root;
update the integration test imports so the test compiles again.

* build(windows): scope MSVC release CRT cmake wrapper via Cargo [env]

Cargo's [target.<triple>] table only forwards a fixed allowlist
(linker, runner, rustflags, rustdocflags, ar), so setting CMAKE there
was silently dropped and audiopus_sys kept linking the debug CRT,
producing LNK4098 'MSVCRTD conflicts' and __imp__CrtDbgReportW errors
on x86_64-pc-windows-msvc test builds.

Move the override to Cargo's [env] table using cc/cmake-rs's
target-suffixed CMAKE_<triple> lookup (force=true, relative=true) so it
applies to MSVC targets only and not to host tooling. Add stdout
markers to the wrapper so its invocation is provable in cargo -vv logs.

Verified: cargo test -p chanora_audio --target x86_64-pc-windows-msvc
--lib --no-run now links cleanly; CMakeCache.txt records
CMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL and CMP0091=NEW.

* fix(flutter): gate VoiceActivity transmit mode by platform support

VoiceActivity relies on the native VAD worker, which is only wired up
on Windows, Linux, and Android. Showing the option on iOS, macOS, or
web let users select a mode that silently never transmitted.

Add voiceActivityTransmitAvailable + transmitModeSegmentsFor() helpers
in voice_settings_controls.dart, hide the VAD row in voice_compact.dart
and drop the VAD segment from the settings dialog when unsupported.
Keep the legacy const transmitModeSegments for the existing widget test
and add two new tests covering the gated helper.

2026-06-09 20:47:16 +09:00

82 KiB

Raw Permalink Blame History

Chanora SysRS — System Requirements Specification

Product name: Chanora
Document type: SysRS / System Requirements Specification
Version: 0.9.11 Status: Baseline Candidate
Product category: Cross-platform voice client application
Architecture: Flutter + Rust Core
Protocol library: tsclientlib
Target client platforms: Windows, macOS, Linux, iOS, Android
Source material: Initial Chanora application-system requirements draft
Supersedes: Earlier mixed SYS/SRS draft

Repo path: docs/requirements/sysrs.md ---

1. Document Control

1.1 Purpose

This document is the System Requirements Specification (SysRS) for the Chanora application system.

Chanora is an application, not an operating system. In this document, the word system means the complete application system and its runtime environment:

The Chanora client application
The Flutter user interface
The Rust Core
The tsclientlib protocol adapter
Platform adapters
Local and secure storage
Audio input/output devices used by the application
Operating system services used by the application
Network connectivity required by the application
External TeamSpeak 3-compatible servers used by the application
Deployment, diagnostics, and support processes

The SysRS covers the whole environment required for the application to run correctly. It does not claim that Chanora is an operating system.

1.2 SysRS vs Software SRS

A software-only SRS would focus mainly on the application code.

This SysRS includes both application requirements and runtime environment requirements, including:

Client device requirements
Operating system service requirements
Audio hardware requirements
Network requirements
External compatible server requirements
Deployment requirements
Security and privacy requirements
Diagnostics and support requirements

1.3 Requirement ID Convention

Every normative requirement uses this format:

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. Note: macOS has no AVAudioSession-equivalent surface; the macOS audio lifecycle in the current baseline is limited to launch-time microphone permission (AVCaptureDevice.requestAccess), the VPIO engine restart on Core Audio HAL default-device change (kAudioHardwarePropertyDefaultInputDevice / DefaultOutputDevice listeners), and the VPIO startup readback at engine start. Full audio route change + interruption handling — as available on iOS via AVAudioSession observers in apps/chanora_flutter/ios/Runner/AppDelegate.swift — is not present in the current macOS baseline; closing the gap is DEC-level scope, not a P0-MVP item.

Priority: P0
Verification: Test

SysRS-052: The Linux runtime environment shall support the desktop environments targeted by the selected release package.

Priority: P1
Verification: Test

SysRS-053: The Linux runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure storage through Secret Service, libsecret, or equivalent where available.

Priority: P1
Verification: Test

SysRS-054: The iOS runtime environment shall provide microphone permissions, foreground voice session capability, audio route change handling, audio interruption recovery, Keychain access, and AVAudioSession behavior to the Chanora application.

Priority: P0
Verification: Test

SysRS-055: The Android runtime environment shall provide microphone permissions, foreground voice session capability, foreground service behavior, audio focus, Bluetooth route handling, Android Keystore access, and production audio integration through AAudio, Oboe, or equivalent.

Priority: P0
Verification: Test

SysRS-056: The project shall define minimum supported operating system versions for each target platform before beta release.

Priority: P1
Verification: Review

SysRS-057: The project shall document OS-level permissions required by each target platform before public release.

Priority: P1
Verification: Review

SysRS-058: The Chanora application shall fail safely with a user-safe message when a required OS service is unavailable.

Priority: P0
Verification: Test

9. Audio Hardware and Audio Processing Requirements

SysRS-059: The Chanora application shall support microphone input for voice transmission.

Priority: P0
Verification: Test

SysRS-060: The Chanora application shall support speaker or headphone output for voice playback.

Priority: P0
Verification: Test

SysRS-061: The Chanora application shall support audio input and output device selection where the target platform exposes selectable devices.

Priority: P0
Verification: Test

SysRS-062: The Chanora application shall handle audio route changes where the target platform reports them.

Priority: P0
Verification: Test

SysRS-063: The Chanora application shall recover gracefully from audio device changes where possible.

Priority: P1
Verification: Test

SysRS-064: The Chanora application shall support Echo Canceller for reducing playback audio leaking into microphone input.

Priority: P0
Verification: Test

SysRS-065: The Chanora application shall support Automatic Gain Control for normalizing microphone input level.

Priority: P0
Verification: Test

SysRS-066: The Chanora application shall support Noise Suppression for reducing stationary background noise.

Priority: P0
Verification: Test

SysRS-067: The Chanora application shall support High-Pass Filter for reducing low-frequency rumble and handling noise.

Priority: P0
Verification: Test

SysRS-068: The Chanora application shall support an audio processing backend abstraction so platform-native and Rust-based processing can be selected per platform.

Priority: P1
Verification: Review

SysRS-069: The Chanora application shall allow Echo Canceller to use playback reference audio when the selected implementation requires it.

Priority: P0
Verification: Test

SysRS-070: The Chanora application shall expose audio processing settings to Rust Core and persist them locally.

Priority: P0
Verification: Test

SysRS-071: The Chanora application shall provide conservative default settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter.

Priority: P0
Verification: Review

SysRS-072: The Chanora application shall allow platform-specific disabling of audio processing features when a feature is unstable or incompatible with a device configuration.

Priority: P0
Verification: Test

SysRS-073: The project shall provide an audio loopback test tool for development and compatibility testing.

Priority: P1
Verification: Demo

SysRS-074: The project shall provide an audio processing test tool for development and compatibility testing.

Priority: P1
Verification: Demo

10. Network Environment Requirements

SysRS-075: The client network environment shall provide IP network connectivity from the client device to the selected compatible voice server.

Priority: P0
Verification: Test

SysRS-076: The Chanora application shall allow the user to configure the server host or IP address.

Priority: P0
Verification: Test

SysRS-077: The Chanora application shall allow the user to configure the server port.

Priority: P0
Verification: Test

SysRS-078: The Chanora application should support a default TeamSpeak 3-compatible voice port when the user does not provide an explicit port.

Priority: P1
Verification: Test

SysRS-079: The client network environment shall permit the protocol traffic required by tsclientlib and the selected compatible server.

Priority: P0
Verification: Test

SysRS-080: The client network environment shall support latency suitable for real-time voice communication under expected operating conditions.

Priority: P0
Verification: Test

SysRS-081: The client network environment should minimize packet loss for acceptable voice quality.

Priority: P1
Verification: Test

SysRS-082: The Chanora application shall detect recoverable network failures where possible.

Priority: P0
Verification: Test

SysRS-083: The Chanora application shall enter reconnect behavior after recoverable network failures.

Priority: P0
Verification: Test

SysRS-084: The Chanora application shall rebuild server state from a fresh snapshot after reconnect.

Priority: P0
Verification: Test

SysRS-085: The Chanora application shall not require VPN connectivity unless the target server or user environment requires it.

Priority: P1
Verification: Review

SysRS-086: The Chanora application shall present network failures through user-safe error messages.

Priority: P0
Verification: Test

SysRS-087: The Chanora application should include network diagnostics in user-initiated diagnostic exports.

Priority: P1
Verification: Inspection

11. External Compatible Server Requirements

SysRS-088: The external voice server shall be TeamSpeak 3-compatible for Chanora MVP operation.

Priority: P0
Verification: Test

SysRS-089: The external voice server shall be reachable from the client device network.

Priority: P0
Verification: Test

SysRS-090: The external voice server shall permit client connection using the identity, nickname, password, and permissions supplied by the user.

Priority: P0
Verification: Test

SysRS-091: The external voice server shall expose server information required for initial synchronization.

Priority: P0
Verification: Test

SysRS-092: The external voice server shall expose channel listing required for the channel tree.

Priority: P0
Verification: Test

SysRS-093: The external voice server shall expose client listing required for the online client view.

Priority: P0
Verification: Test

SysRS-094: The external voice server shall support channel join operations for accessible channels.

Priority: P0
Verification: Test

SysRS-095: The external voice server shall emit channel movement events required for state synchronization.

Priority: P0
Verification: Test

SysRS-096: The external voice server shall emit client join and leave events required for state synchronization.

Priority: P0
Verification: Test

SysRS-097: The external voice server shall emit channel create, update, and delete events required for state synchronization where those events occur.

Priority: P0
Verification: Test

SysRS-098: The external voice server shall support channel text message send and receive where user permissions allow.

Priority: P0
Verification: Test

SysRS-099: The external voice server shall support voice packet send and receive where user permissions allow.

Priority: P0
Verification: Test

SysRS-100: The external voice server shall expose disconnect behavior or connection failure signals that can be mapped by the protocol adapter.

Priority: P0
Verification: Test

SysRS-101: The project shall document server-side permissions that can affect channel join, voice transmission, and text messaging.

Priority: P1
Verification: Review

12. Application Functional Requirements

SysRS-102: The Chanora application shall allow the user to manually connect to a compatible server.

Priority: P0
Verification: Demo

SysRS-103: The Chanora application shall allow the user to provide hostname or IP address, port, nickname, and optional server password before connection.

Priority: P0
Verification: Demo

SysRS-104: The Chanora application shall support persistent local identity for compatible server authentication.

Priority: P0
Verification: Demo

SysRS-105: The Chanora application shall display connection status to the user.

Priority: P0
Verification: Demo

SysRS-106: The Chanora application shall allow the user to disconnect from the active server connection.

Priority: P0
Verification: Demo

SysRS-107: The Chanora application shall display the server channel tree after synchronization.

Priority: P0
Verification: Demo

SysRS-108: The Chanora application shall display online clients after synchronization.

Priority: P0
Verification: Demo

SysRS-109: The Chanora application shall allow the user to join an accessible voice channel.

Priority: P0
Verification: Demo

SysRS-110: The Chanora application shall allow the user to send and receive channel text messages where permitted.

Priority: P0
Verification: Demo

SysRS-111: The Chanora application shall capture and transmit voice where permitted.

Priority: P0
Verification: Demo

SysRS-112: The Chanora application shall receive and play voice where permitted.

Priority: P0
Verification: Demo

SysRS-113: The Chanora application shall provide microphone mute control.

Priority: P0
Verification: Demo

SysRS-114: The Chanora application shall provide output deaf control.

Priority: P0
Verification: Demo

SysRS-115: The Chanora application shall provide push-to-talk control.

Priority: P0
Verification: Demo

SysRS-116: The Chanora application shall display microphone input level where available.

Priority: P0
Verification: Demo

SysRS-117: The Chanora application shall display speaking indicators where available.

Priority: P0
Verification: Demo

SysRS-118: The Chanora application shall allow users to save and reuse server bookmarks.

Priority: P0
Verification: Demo

SysRS-119: The Chanora application shall allow users to configure audio processing features.

Priority: P0
Verification: Demo

SysRS-120: The Chanora application shall allow users to export redacted diagnostics.

Priority: P1
Verification: Demo

13. Protocol Integration Requirements

SysRS-121: The Chanora application shall use tsclientlib inside the protocol subsystem.

Priority: P0
Verification: Inspection

SysRS-122: The Chanora application shall isolate direct tsclientlib calls inside the chanora_protocol component.

Priority: P0
Verification: Inspection

SysRS-123: The Chanora application shall prevent raw tsclientlib types from crossing into Flutter UI or Flutter State Layer.

Priority: P0
Verification: Inspection

SysRS-124: The Chanora application shall convert tsclientlib errors into Chanora protocol errors.

Priority: P0
Verification: Test

SysRS-125: The Chanora application shall convert tsclientlib events into internal protocol events.

Priority: P0
Verification: Test

SysRS-126: The Chanora application shall support future patching, replacement, or forking of protocol implementation without changing Flutter UI contracts.

Priority: P1
Verification: Review

SysRS-127: The project shall provide protocol compatibility test coverage for MVP features.

Priority: P1
Verification: Test

SysRS-128: The project shall include a protocol probe tool for validating target server compatibility.

Priority: P0
Verification: Demo

14. State Synchronization Requirements

SysRS-129: The Chanora application shall maintain one authoritative connection state per active server connection.

Priority: P0
Verification: Test

SysRS-130: The Chanora application shall synchronize state using a snapshot + delta model.

Priority: P0
Verification: Test

SysRS-131: The Chanora application shall emit a full snapshot after initial synchronization.

Priority: P0
Verification: Test

SysRS-132: The Chanora application shall emit delta events after live server-side changes.

Priority: P0
Verification: Test

SysRS-133: The Chanora application shall apply protocol events through deterministic reducers.

Priority: P0
Verification: Test

SysRS-134: The Chanora application shall preserve event ordering per connection.

Priority: P0
Verification: Test

SysRS-135: The Chanora application shall rebuild state from a fresh snapshot after reconnect.

Priority: P0
Verification: Test

SysRS-136: The Chanora application shall prevent Flutter from directly mutating server state.

Priority: P0
Verification: Inspection

SysRS-137: The Chanora application shall implement the defined connection state machine from Disconnected through Connecting, Synchronizing, Connected, and Reconnecting.

Priority: P0
Verification: Test

SysRS-138: The Chanora application shall not automatically reconnect after user-triggered disconnect.

Priority: P0
Verification: Test

SysRS-139: The project shall include an event replay tool for development and debugging of state synchronization.

Priority: P1
Verification: Demo

15. Data and Storage Requirements

SysRS-140: The Chanora application shall store server bookmarks locally.

Priority: P0
Verification: Test

SysRS-141: The Chanora application shall store recent servers locally.

Priority: P1
Verification: Test

SysRS-142: The Chanora application shall store audio settings locally.

Priority: P0
Verification: Test

SysRS-143: The Chanora application shall store UI settings locally.

Priority: P1
Verification: Test

SysRS-144: The Chanora application shall store per-user volume preferences locally where applicable.

Priority: P1
Verification: Test

SysRS-145: The Chanora application shall store muted user preferences locally where applicable.

Priority: P1
Verification: Test

SysRS-146: The Chanora application shall use SQLite or an equivalent embedded database for non-secret local data.

Priority: P0
Verification: Inspection

SysRS-147: The Chanora application shall use platform secure storage for sensitive data.

Priority: P0
Verification: Audit

SysRS-148: The Chanora application shall store identity private keys using platform secure storage.

Priority: P0
Verification: Audit

SysRS-149: The Chanora application shall store server passwords using platform secure storage.

Priority: P0
Verification: Audit

SysRS-150: The Chanora application shall not store private keys in plaintext files.

Priority: P0
Verification: Audit

SysRS-151: The Chanora application shall not write passwords to logs.

Priority: P0
Verification: Audit

SysRS-152: The Chanora application shall redact secrets from diagnostic exports.

Priority: P0
Verification: Audit

16. Security and Privacy Requirements

SysRS-153: The Chanora application shall store sensitive data using platform secure storage.

Priority: P0
Verification: Audit

SysRS-154: The Chanora application shall redact secrets from logs.

Priority: P0
Verification: Audit

SysRS-155: The Chanora application shall redact secrets from diagnostic bundles.

Priority: P0
Verification: Audit

SysRS-156: The Chanora application shall avoid exposing internal stack traces to normal users.

Priority: P0
Verification: Test

SysRS-157: The Chanora application shall validate user input before passing it to protocol operations.

Priority: P0
Verification: Test

SysRS-158: The Windows runtime environment shall support Windows Credential Manager, DPAPI, or equivalent secure credential storage for the Chanora application.

Priority: P1
Verification: Inspection

SysRS-159: The macOS runtime environment shall support Keychain-based secure credential storage for the Chanora application.

Priority: P1
Verification: Inspection

SysRS-160: The iOS runtime environment shall support Keychain-based secure credential storage for the Chanora application.

Priority: P0
Verification: Inspection

SysRS-161: The Android runtime environment shall support Android Keystore or equivalent secure credential storage for the Chanora application.

Priority: P0
Verification: Inspection

SysRS-162: The Linux runtime environment shall support Secret Service, libsecret, or equivalent secure storage where available.

Priority: P2
Verification: Inspection

SysRS-163: The Chanora application shall minimize collection of personal data.

Priority: P0
Verification: Audit

SysRS-164: The Chanora application shall require user action before exporting diagnostics.

Priority: P0
Verification: Test

SysRS-165: The Chanora application shall explain microphone permission usage before requesting permission where platform guidelines allow.

Priority: P0
Verification: Test

SysRS-166: The Chanora application shall explain notification permission usage before requesting permission where platform guidelines allow.

Priority: P1
Verification: Test

SysRS-167: The Chanora application shall not automatically upload diagnostics in MVP.

Priority: P0
Verification: Audit

17. Diagnostics and Operations Requirements

SysRS-168: The Chanora application shall produce structured diagnostic logs.

Priority: P0
Verification: Inspection

SysRS-169: The Chanora application shall support log redaction.

Priority: P0
Verification: Audit

SysRS-170: The Chanora application shall support protocol event recording in development or diagnostics mode.

Priority: P1
Verification: Demo

SysRS-171: The Chanora application shall support event replay for debugging state synchronization.

Priority: P1
Verification: Demo

SysRS-172: The Chanora application shall support audio diagnostics.

Priority: P1
Verification: Demo

SysRS-173: The Chanora application shall support network diagnostics.

Priority: P1
Verification: Demo

SysRS-174: The Chanora application shall support user-initiated diagnostic export.

Priority: P1
Verification: Demo

SysRS-175: Diagnostic export shall exclude or redact sensitive data.

Priority: P0
Verification: Audit

SysRS-176: The project shall document the expected support workflow for diagnostic bundle collection.

Priority: P2
Verification: Review

SysRS-177: The project shall include compatibility test tracking for supported platforms.

Priority: P1
Verification: Inspection

18. Non-Functional Requirements

SysRS-178: The Chanora application shall keep the UI responsive during connection, synchronization, and reconnect.

Priority: P0
Verification: Test

SysRS-179: The Chanora application shall avoid visible UI freezes longer than 100 ms during normal operation.

Priority: P0
Verification: Test

SysRS-180: The Chanora application shall minimize local audio pipeline latency.

Priority: P0
Verification: Test

SysRS-181: The Chanora application should target local audio pipeline latency under 100 ms where platform conditions permit.

Priority: P1
Verification: Test

SysRS-182: The Chanora application shall avoid unbounded memory growth in chat history.

Priority: P0
Verification: Test

SysRS-183: The Chanora application shall avoid unbounded memory growth in logs.

Priority: P0
Verification: Test

SysRS-184: The Chanora application shall avoid unbounded memory growth in audio buffers.

Priority: P0
Verification: Test

SysRS-185: The Chanora application shall avoid unbounded memory growth in event queues.

Priority: P0
Verification: Test

SysRS-186: The Chanora application shall perform required audio processing without sustained underruns on supported devices.

Priority: P0
Verification: Test

SysRS-187: The Chanora application shall keep reconnect processing non-blocking for UI interaction.

Priority: P0
Verification: Test

SysRS-188: The Chanora application shall recover from transient network loss where possible.

Priority: P0
Verification: Test

SysRS-189: The Chanora application shall recover gracefully from audio device changes where possible.

Priority: P1
Verification: Test

SysRS-190: The Chanora application shall isolate connection failures to the affected connection.

Priority: P1
Verification: Test

SysRS-191: The Chanora application shall avoid crashing on malformed or unexpected protocol events.

Priority: P0
Verification: Test

19. Deployment and Release Environment Requirements

SysRS-192: The project shall support Windows installer packaging for the Chanora application.

Priority: P1
Verification: Demo

SysRS-193: The project shall support macOS signed and notarized builds for the Chanora application.

Priority: P1
Verification: Demo

SysRS-194: The project shall support Linux packaging through AppImage, Flatpak, deb, rpm, or a selected subset.

Priority: P1
Verification: Demo

SysRS-195: The project shall support Android AAB release builds for the Chanora application.

Priority: P1
Verification: Demo

SysRS-196: The project shall support iOS TestFlight and App Store release builds for the Chanora application.

Priority: P1
Verification: Demo

SysRS-197: The project shall document platform signing, packaging, and release requirements before public release.

Priority: P1
Verification: Review

SysRS-198: The project shall ensure release metadata does not imply official TeamSpeak affiliation.

Priority: P0
Verification: Audit

SysRS-199: The project shall define release channels for internal, beta, and production builds before external testing.

Priority: P1
Verification: Review

20. Interface Requirements

SysRS-200: The Chanora application shall provide a user interface for manual server connection.

Priority: P0
Verification: Demo

SysRS-201: The Chanora application shall provide a user interface for bookmark management.

Priority: P0
Verification: Demo

SysRS-202: The Chanora application shall provide a user interface for channel tree navigation.

Priority: P0
Verification: Demo

SysRS-203: The Chanora application shall provide a user interface for chat.

Priority: P0
Verification: Demo

SysRS-204: The Chanora application shall provide a user interface for voice controls.

Priority: P0
Verification: Demo

SysRS-205: The Chanora application shall provide a user interface for audio processing settings.

Priority: P0
Verification: Demo

SysRS-206: The Chanora application shall provide a bridge interface between Flutter and Rust Core.

Priority: P0
Verification: Inspection

SysRS-207: The Chanora application shall provide a protocol interface between Rust Core and tsclientlib.

Priority: P0
Verification: Inspection

SysRS-208: The Chanora application shall provide an audio hardware interface through platform capture and playback adapters.

Priority: P0
Verification: Test

SysRS-209: The Chanora application shall provide secure storage interfaces through platform-specific secure storage mechanisms.

Priority: P0
Verification: Audit

SysRS-210: The Chanora application shall provide a network interface to external TeamSpeak 3-compatible servers through tsclientlib.

Priority: P0
Verification: Test

21. System Constraints

SysRS-211: The Chanora application shall not directly expose raw tsclientlib types to Flutter.

Priority: P0
Verification: Inspection

SysRS-212: The Chanora application shall not store private keys in plaintext files.

Priority: P0
Verification: Audit

SysRS-213: The Chanora application shall not write passwords to logs.

Priority: P0
Verification: Audit

SysRS-214: The Chanora application shall not imply official TeamSpeak affiliation in UI, documentation, or release metadata.

Priority: P0
Verification: Audit

SysRS-215: The Chanora application shall not automatically upload diagnostic information in MVP.

Priority: P0
Verification: Audit

SysRS-216: The Chanora application shall comply with iOS background execution policies.

Priority: P0
Verification: Audit

SysRS-217: The Chanora application shall comply with Android foreground service requirements for active voice sessions.

Priority: P0
Verification: Audit

SysRS-218: The MVP shall not require Chanora-operated backend infrastructure for voice, channels, or text.

Priority: P0
Verification: Review

22. Assumptions

SysRS-219: The selected tsclientlib version can support or be extended to support required MVP protocol features.

Priority: P0
Verification: Review

SysRS-220: Required audio processing features can be implemented through a combination of platform-native APIs, Rust DSP, and external audio processing libraries.

Priority: P0
Verification: Review

SysRS-221: Mobile foreground voice behavior is sufficient for MVP.

Priority: P0
Verification: Review

SysRS-222: Background voice behavior will remain constrained by iOS and Android platform policies.

Priority: P0
Verification: Review

SysRS-223: External compatible server administrators are responsible for server availability, permissions, and configuration.

Priority: P0
Verification: Review

SysRS-224: End users are responsible for providing valid server connection details and network access.

Priority: P0
Verification: Review

23. Out of Scope for MVP

SysRS-225: The MVP shall not include TeamSpeak-compatible server hosting functionality.

Priority: P0
Verification: Review

SysRS-226: The MVP shall not include full server administration functionality.

Priority: P0
Verification: Review

SysRS-227: The MVP shall not include a complete permission editor.

Priority: P0
Verification: Review

SysRS-228: The MVP shall not include a plugin system.

Priority: P0
Verification: Review

SysRS-229: The MVP shall not include 3D positional audio unless explicitly reprioritized.

Priority: P1
Verification: Review

SysRS-230: The MVP shall not include advanced whisper list management unless explicitly reprioritized.

Priority: P1
Verification: Review

SysRS-231: The MVP shall not include Server Query administration tools.

Priority: P0
Verification: Review

SysRS-232: The MVP shall not include automatic cloud sync of bookmarks, identities, settings, or diagnostics.

Priority: P1
Verification: Review

24. Verification and Validation Requirements

SysRS-233: The project shall maintain a requirements traceability matrix from SysRS requirements through SysDes, SRS, SAD, SDD, and Verification evidence.

Priority: P1
Verification: Review

SysRS-234: The project shall verify protocol compatibility through a protocol probe tool.

Priority: P0
Verification: Demo

SysRS-235: The project shall verify state synchronization through reducer tests and event replay tests.

Priority: P1
Verification: Test

SysRS-236: The project shall verify audio capture, processing, encode/decode, and playback through audio loopback and processing tests.

Priority: P1
Verification: Test

SysRS-237: The project shall verify secure storage behavior on every target platform before public release.

Priority: P1
Verification: Audit

SysRS-238: The project shall verify diagnostic redaction before enabling diagnostic export for external testers.

Priority: P1
Verification: Audit

SysRS-239: The project shall verify release packaging on every target platform before production release.

Priority: P1
Verification: Demo

SysRS-240: The project shall verify that public wording does not imply official TeamSpeak affiliation.

Priority: P0
Verification: Audit

25. MVP Acceptance Requirements

SysRS-241: The MVP shall connect to a TeamSpeak 3-compatible server using tsclientlib.

Priority: P0
Verification: Demo

SysRS-242: The MVP shall display the server channel tree.

Priority: P0
Verification: Demo

SysRS-243: The MVP shall display online clients.

Priority: P0
Verification: Demo

SysRS-244: The MVP shall allow the user to join a voice channel.

Priority: P0
Verification: Demo

SysRS-245: The MVP shall send voice.

Priority: P0
Verification: Demo

SysRS-246: The MVP shall receive voice.

Priority: P0
Verification: Demo

SysRS-247: The MVP shall support microphone mute.

Priority: P0
Verification: Demo

SysRS-248: The MVP shall support output deaf.

Priority: P0
Verification: Demo

SysRS-249: The MVP shall support push-to-talk.

Priority: P0
Verification: Demo

SysRS-250: The MVP shall support Echo Canceller.

Priority: P0
Verification: Demo

SysRS-251: The MVP shall support Automatic Gain Control.

Priority: P0
Verification: Demo

SysRS-252: The MVP shall support Noise Suppression.

Priority: P0
Verification: Demo

SysRS-253: The MVP shall support High-Pass Filter.

Priority: P0
Verification: Demo

SysRS-254: The MVP shall send and receive channel text messages.

Priority: P0
Verification: Demo

SysRS-255: The MVP shall save and reuse server bookmarks.

Priority: P0
Verification: Demo

SysRS-256: The MVP shall use secure storage for sensitive data.

Priority: P0
Verification: Audit

SysRS-257: The MVP shall export redacted diagnostic logs.

Priority: P1
Verification: Demo

30. UI/UX, Material 3, Platform, and Internationalization Requirements

This section extends the system requirement baseline for the Chanora application system. These requirements are system-level because they define externally observable application behavior, accessibility behavior, platform behavior, multilingual behavior, deployment-region behavior, and interoperability constraints.

SysRS-258: The Chanora application system shall use Material 3 as the baseline design system for the Flutter client user interface.

Priority: P0
Verification: Review, Inspection

SysRS-259: The Chanora application system shall define a Chanora-specific design system above Material 3 for voice, connection, channel, latency, diagnostics, accessibility, and platform-adaptive states.

Priority: P0
Verification: Review, Inspection

SysRS-260: The Chanora application system shall support compact, medium, and expanded window classes for responsive client layout.

Priority: P0
Verification: Test, Demo

SysRS-261: The Chanora application system shall preserve visibility of connection status and primary voice controls across compact, medium, and expanded layouts.

Priority: P0
Verification: Test, Demo

SysRS-262: The Chanora application system shall provide screen-reader semantics for critical interactive controls and critical status indicators.

Priority: P0
Verification: Test, Audit

SysRS-263: The Chanora application system shall not communicate critical connection, voice, latency, permission, or error states by color alone.

Priority: P0
Verification: Test, Audit

SysRS-264: The Chanora application system shall support keyboard focus traversal and visible focus indication on desktop-class and tablet keyboard environments.

Priority: P1
Verification: Test

SysRS-265: The Chanora application system shall keep critical controls reachable when the user increases text size using platform accessibility settings.

Priority: P0
Verification: Test

SysRS-266: The Chanora application system shall respect platform safe areas, display cutouts, system bars, virtual keyboards, and desktop window insets.

Priority: P0
Verification: Test

SysRS-267: The Chanora application system shall provide platform-appropriate handling for Android system back navigation, including predictive-back-compatible behavior where supported by the platform.

Priority: P1
Verification: Test

SysRS-268: The Chanora application system shall provide platform-appropriate handling for iOS navigation gestures, safe areas, keyboard avoidance, haptics, and system permission presentation.

Priority: P1
Verification: Test

SysRS-269: The Chanora application system shall support localization of user-visible client application strings.

Priority: P0
Verification: Inspection, Test

SysRS-270: The Chanora application system shall externalize user-visible strings from source code into localization resources or an equivalent localization mechanism.

Priority: P0
Verification: Inspection

SysRS-271: The Chanora application system shall support English as the baseline product language.

Priority: P0
Verification: Review, Test

SysRS-272: The Chanora application system shall support adding additional product languages without changing protocol, audio, state synchronization, or storage architecture.

Priority: P1
Verification: Review, Inspection

SysRS-273: The Chanora application system shall preserve and display Unicode server names, channel names, client nicknames, and text messages received from compatible servers.

Priority: P0
Verification: Test

SysRS-274: The Chanora application system shall use UTF-8 internally for text exchanged between Flutter, Rust Core, local storage, diagnostics, and protocol-facing adapters unless a platform API requires conversion at the boundary.

Priority: P0
Verification: Inspection, Test

SysRS-275: The Chanora application system shall perform encoding conversion at explicit boundary adapters when external server, operating system, or platform APIs use a different text representation.

Priority: P1
Verification: Inspection, Test

SysRS-276: The Chanora application system shall not corrupt or drop multilingual Unicode content in logs or diagnostic exports, except where redaction intentionally removes sensitive content.

Priority: P0
Verification: Test, Audit

SysRS-277: The Chanora application system shall support bidirectional text display for user-visible localized strings and server-provided text where the platform text engine supports it.

Priority: P2
Verification: Test

SysRS-278: The Chanora application system shall support locale-aware formatting for dates, times, numbers, and diagnostic timestamps where those values are user-visible.

Priority: P1
Verification: Test

SysRS-279: The Chanora application system shall support fallback behavior when a translation key is missing.

Priority: P0
Verification: Test

SysRS-280: The Chanora application system shall keep machine-readable diagnostic fields stable and language-neutral while allowing user-facing diagnostic descriptions to be localized.

Priority: P1
Verification: Inspection, Test

SysRS-281: The Chanora application system shall separate product localization from server-provided content; server-provided names and messages shall be displayed as content, not translated by the client.

Priority: P0
Verification: Review, Test

SysRS-282: The Chanora application system shall support accessibility labels and localization for icon-only controls.

Priority: P0
Verification: Test, Audit

SysRS-283: The Chanora application system shall define a UI/UX guideline document as a downstream non-normative design baseline derived from this SysRS and SysDes.

Priority: P1
Verification: Review

SysRS-284: The Chanora application system shall define design tokens for color, typography, spacing, shape, elevation, motion, density, connection state, voice state, latency state, and diagnostics state.

Priority: P1
Verification: Review, Inspection

SysRS-285: The Chanora application system shall maintain traceability across the hierarchy SysRS -> SysDes -> SRS -> SAD -> SDD without allowing SRS, SAD, or SDD to bypass the immediately preceding lifecycle layer.

Priority: P0
Verification: Review, Inspection

26. Glossary

Term	Definition
Chanora	Cross-platform voice client application
Application system	The Chanora application plus runtime environment elements required for operation
Client device	User device running the Chanora application
Runtime environment	OS services, hardware, network, and external dependencies used by the application
External compatible server	TeamSpeak 3-compatible voice server not operated by Chanora
`tsclientlib`	Rust protocol library used for TeamSpeak-compatible protocol integration
Rust Core	Shared Rust layer for protocol, state, audio, storage, diagnostics, and business logic
Flutter UI	Cross-platform UI layer
Platform adapter	OS-specific integration layer for audio, permissions, secure storage, lifecycle, and packaging
Echo Canceller	Audio processing feature that reduces playback audio leaking into microphone input
Automatic Gain Control	Audio processing feature that normalizes microphone input gain
Noise Suppression	Audio processing feature that reduces background noise
High-Pass Filter	Audio processing feature that reduces low-frequency noise

27. SysRS Coverage Matrix

SysRS Area	Requirement Coverage
Product and application-system scope	SysRS-001 through SysRS-010
Stakeholder and user environment	SysRS-011 through SysRS-015
System boundary and external dependencies	SysRS-016 through SysRS-023
Application components	SysRS-024 through SysRS-034
Client device and hardware environment	SysRS-035 through SysRS-047
Operating system services	SysRS-048 through SysRS-058
Audio hardware and audio processing	SysRS-059 through SysRS-074
Network environment	SysRS-075 through SysRS-087
External compatible servers	SysRS-088 through SysRS-101
Application functional behavior	SysRS-102 through SysRS-120
Protocol integration	SysRS-121 through SysRS-128
State synchronization	SysRS-129 through SysRS-139
Data and storage	SysRS-140 through SysRS-152
Security and privacy	SysRS-153 through SysRS-167
Diagnostics and operations	SysRS-168 through SysRS-177
Non-functional requirements	SysRS-178 through SysRS-191
Deployment and release environment	SysRS-192 through SysRS-199
Interfaces	SysRS-200 through SysRS-210
Constraints	SysRS-211 through SysRS-218
Assumptions	SysRS-219 through SysRS-224
Out of scope for MVP	SysRS-225 through SysRS-232
Verification and validation	SysRS-233 through SysRS-240
MVP acceptance requirements	SysRS-241 through SysRS-257
UI/UX, Material 3, platform, i18n, and strict traceability	SysRS-258 through SysRS-285

28. Open Decisions

Decision ID	Area	Question	Default Recommendation
SysRS-DEC-001	Mobile	Minimum supported iOS version	Decide before iOS implementation
SysRS-DEC-002	Mobile	Minimum supported Android version	Decide before Android implementation
SysRS-DEC-003	Connection	Multiple simultaneous server connections in MVP	Defer unless required
SysRS-DEC-004	Audio	Default Echo Canceller state per platform	Enable only after validation
SysRS-DEC-005	Audio	Default AGC state per platform	Enable with conservative settings
SysRS-DEC-006	Audio	Default Noise Suppression state per platform	Enable if quality is acceptable
SysRS-DEC-007	Audio	Default High-Pass Filter cutoff frequency	80 Hz initial default
SysRS-DEC-008	Audio	Platform-native vs Rust audio processing per platform	Prefer best quality and lowest latency
SysRS-DEC-009	Legal	Official SDK licensing review before public distribution	Recommended
SysRS-DEC-010	Storage	Embedded database choice	SQLite or equivalent
SysRS-DEC-011	Bridge	Rust/Flutter bridge choice	`flutter_rust_bridge` initially

29. Revision History

Version	Date	Description
0.1.0	2026-05-13	Initial application-system requirements draft
0.2.0	2026-05-13	Converted software-only direction into application-system SysRS
0.3.0	2026-05-13	Corrected terminology: Chanora is an application; SysRS covers the application system and runtime environment
0.4.0	2026-05-13	Removed old SYS requirement references and standardized requirement IDs as SysRS-XXX
0.5.0	2026-05-13	Moved implementation and design documents out of input references into downstream non-normative documents
0.6.0	2026-05-13	Corrected downstream documentation lifecycle to SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification
0.7.0	2026-05-14	Added Material 3, adaptive UI, accessibility, platform behavior, internationalization, Unicode, and strict lifecycle traceability requirements

31. Platform Baseline, Release Policy, and Architecture Decision Requirements

This section converts the baseline product decisions into auditable system-level requirements.

SysRS-286: The Chanora application system shall support iOS runtime deployment on iOS 13 or later unless Flutter, plugin, audio, or platform constraints require raising the minimum version.

Priority: P0
Verification: Review, Platform Test

SysRS-287: For Apple App Store Connect upload on or after 2026-04-28, the Chanora iOS/iPadOS build shall be produced with Xcode 26 or later using the iOS 26 / iPadOS 26 SDK or later, unless Apple publishes a newer applicable upload requirement before upload.

Priority: P0
Verification: Release Inspection

SysRS-288: The Chanora Android application shall support Android API 28 (Android 9.0) or later as the minimum runtime baseline, per DEC-004 (Accepted 2026-05-14, which raised the original API 24 recommendation to API 28). The minimum may be raised further only if Flutter, plugin, audio, or platform constraints require it; it shall not be lowered without a superseding accepted decision.

Priority: P0
Verification: Review, Platform Test

SysRS-289: For Google Play submission, the Chanora Android build shall target the Android API level required by Google Play on the upload date.

Priority: P0
Verification: Release Inspection

SysRS-290: The Chanora MVP shall support one active server connection per client instance; multiple simultaneous active server connections shall be deferred outside MVP scope.

Priority: P0
Verification: Review, System Test

SysRS-291: The Chanora MVP shall enable Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter by default where supported and stable, while allowing user or platform policy to disable supported processing where applicable.

Priority: P0
Verification: Audio Test, Review

SysRS-292: The Chanora application system shall prefer platform-native audio processing for MVP where available and stable, with Rust/WebRTC-style audio processing retained as a controlled fallback or later architecture option.

Priority: P1
Verification: Architecture Review, Audio Test

SysRS-293: The Chanora application system shall use SQLite or an equivalent embedded local database for non-secret local state, while storing secrets only through platform secure storage.

Priority: P0
Verification: Storage Test, Security Audit

SysRS-294: The Chanora application system shall use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs; flutter_rust_bridge is the default candidate unless prototype evidence selects a better option.

Priority: P0
Verification: Architecture Review, Integration Test

SysRS-295: The Chanora MVP shall not perform automatic diagnostic upload, automatic telemetry upload, or automatic crash reporting unless a later approved decision updates privacy, security, legal, release, and verification documents.

Priority: P0
Verification: Privacy Review, Security Audit

SysRS-296: The Chanora desktop application shall support Focused Push-to-Talk on Windows, macOS, and Linux. Focused PTT is the minimum required behaviour: the user shall be able to hold a bound input (keyboard key, mouse button) inside the focused Chanora window to enable voice transmission, and release of that input shall disable voice transmission.

Priority: P0
Verification: Platform Test, User Acceptance Test

SysRS-297: The Chanora desktop application shall additionally support Global Push-to-Talk where the operating system, the user-granted permission set, the display server, and the available input backend together permit it. Where global PTT is not available, the application shall fall back to Focused PTT without claiming Global PTT support.

Priority: P0
Verification: Platform Test, Architecture Review

SysRS-298: The detected desktop PTT capability level shall be exposed to the user interface and to the release verification record. The exposed value shall match the actual runtime capability — the application shall not advertise a Global PTT level when the active backend is the Focused fallback.

Priority: P0
Verification: Integration Test, Release Inspection

SysRS-299: The Chanora Windows desktop application shall prefer the Raw Input backend for Global PTT, with a low-level keyboard hook used only as a fallback when Raw Input is unavailable, and Focused PTT used as the final fallback when no Global PTT backend can be initialised.

Priority: P0
Verification: Platform Test (Windows), Architecture Review

SysRS-300: The Chanora macOS desktop application shall request the operating-system permission required for Global PTT (Input Monitoring / Accessibility), use the permission-aware Global PTT backend when the permission is granted, and fall back to Focused PTT when the permission is denied, revoked, or not yet decided. The application shall not block voice functionality while the user decides on the permission prompt.

Priority: P0
Verification: Platform Test (macOS), User Acceptance Test

SysRS-301: The Chanora Linux desktop application shall use a capability-dependent Global PTT backend selected from the available display server (X11 or Wayland) and compositor support (GNOME on Wayland is the officially-tested target for the first public release per DEC-026; other compositors fall back to Focused PTT). The application shall not claim Global PTT support on an untested Linux environment.

Priority: P0
Verification: Platform Test (Linux, GNOME Wayland), Architecture Review

SysRS-302: The Chanora application system shall not log, store, persist, or include in the user-initiated diagnostic export any raw desktop key-event history, key code stream, or key-press timing sequence. Diagnostic export may include the detected PTT capability level, the active backend identifier, and the bound input class (for example "keyboard", "mouse-side-button"), but shall not include the specific key code, scan code, or virtual-key value of any user binding.

Priority: P0
Verification: Privacy Review, Security Audit, Diagnostic Inspection

SysRS-303: The Chanora application system shall define the v1 voice transmit mode set as Ptt, Continuous, and VoiceActivity. VoiceActivity shall be enabled only on platforms with an implemented and verified VAD capture path in this baseline (currently Windows/Linux desktop); mobile, macOS, and unverified-platform enablement remain deferred per DEC-030. The default mode on a fresh install shall be Ptt; the user-selected mode shall be persisted per identity where the selected platform supports it. The audio engine lifecycle shall be bound to voice-channel membership: input and output streams shall open on the user's first voice-channel join of the session and shall close on the last voice-channel leave, with no manual start affordance exposed at any system interface. The output stream shall open regardless of microphone-permission state so listen-only is a first-class flow. A user-facing hard-mute toggle shall force the transmit gate closed and shall override the active transmit mode, the PTT key state, and every other internal signal.

Priority: P0
Verification: Functional Test, UX Review

SysRS-304: The Chanora application system shall apply a configurable PTT release-tail interval between the moment the bound PTT input reports key-up and the moment the transmit gate closes, so that the trailing syllable of a spoken word is not clipped at word boundaries. The default release-tail value shall be 200 ms (matching the TeamSpeak / Mumble default); the user-configurable range shall be 0 ms through 500 ms inclusive. The release tail shall not affect the input-stream capture lifecycle; it shall affect only the transmit gate.

Priority: P0
Verification: Functional Test, UX Review

SysRS-305: When the Chanora Android application has an active voice session connected, the system shall engage the Android in-call audio mode (for example via AudioManager.setMode(MODE_IN_COMMUNICATION) or an equivalent platform routing-assist mechanism) so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The in-call mode shall be entered no later than the moment the voice session becomes connected and shall be released when the last active voice session ends. Back-fills the v0.9.8 product-decision-register entry that recorded AudioManager.setMode(MODE_IN_COMMUNICATION) engagement via JNI without prior SysRS coverage.

Priority: P0
Verification: Platform Test (Android), Audio Test

SysRS-306: The Chanora Android application shall acquire the Android runtime microphone permission (RECORD_AUDIO) at or before the point of voice session activation, and shall not begin microphone capture without that permission having been granted by the user. If the permission is denied, revoked, or not yet decided, the application shall remain functional in listen-only mode (consistent with SysRS-303) and shall surface a user-facing path to grant the permission before retrying transmit. This requirement is additive to the general permission obligation in SysRS-055 and makes the runtime-acquisition timing explicit.

Priority: P0
Verification: Platform Test (Android), Functional Test

SysRS-307: The Chanora project shall maintain measured numeric performance baselines for the realtime audio capture and playback paths. The baseline set shall include, at minimum: (i) heap allocation count per realtime audio callback measured after warmup, (ii) per-callback wall-clock time expressed as a fraction of (or absolute bound relative to) the audio frame period, (iii) Opus encode latency and Opus decode latency per frame, and (iv) resampler throughput at the common rate-pair conversions exercised by the audio pipeline. Each baseline shall be expressed as a numeric threshold (or numeric range), not as free-form prose, so that regression against the baseline is deterministically detectable by automated comparison. This requirement extends the prescriptive intent of SysRS-180 ("shall minimize local audio pipeline latency") and the directional target of SysRS-181 ("should target local audio pipeline latency under 100 ms") into a measurable, contract-grade obligation, and it is consistent with the underrun-avoidance obligation in SysRS-186. The specific baseline values, the warmup definition, the rate-pair set, and the storage format for the baselines are SysDes/SAD/SDD concerns and are not authored here. This clause does not authorize automatic upload, transmission, or off-device export of any measured baseline data and is therefore consistent with SysRS-295 (no automatic telemetry / diagnostic upload in MVP).

Priority: P0
Verification: Test (SWE.4 benchmark assertions, delegated to verification layer; cross-references SysRS-236)

SysRS-308: The Chanora project's continuous-integration workflow shall execute the realtime-audio benchmark suite on every pull request against the default branch and on every merge to the default branch, on at least one host architecture (Linux x86_64 on the existing GitHub Actions runner is sufficient to satisfy this clause), and shall report the comparison of the executed run against the maintained baselines (SysRS-307) in the pull request's status-check surface such that human reviewers can see, before approving the change, whether any baseline has regressed beyond the declared tolerance window (SysRS-309). The CI regression check authorized by this clause is advisory only: it shall NOT fail the CI build, shall NOT block merge, and shall NOT be treated as a hard quality gate at the P0-MVP stage. Its purpose is to surface evidence for human reviewer judgement and to avoid the failure mode in which a strict build-failing gate is bypassed under release-crunch pressure (e.g., "skip CI"). Escalation of this advisory tier to a build-failing hard gate is explicitly out of scope of SysRS-308 and shall be authorized only by a separate, later SysRS clause after a period of baseline maturity sufficient to establish that the advisory signal is stable and low-noise (indicative target: 4–6 weeks of clean baseline data on the default branch, but the actual escalation criteria are to be set by the future clause). This requirement is consistent with the CI-as-quality-evidence pattern established by the SysRS-234..239 verification family and does not displace any obligation in that family. This clause does not authorize off-device transmission of baseline measurements beyond the project's existing CI provider surface (i.e., GitHub Actions logs and PR status checks visible to repository collaborators); it is therefore consistent with SysRS-295.

Priority: P0
Verification: Demo (CI workflow exercised on a representative PR; advisory status check appears and does not block merge on regression)

SysRS-309: The advisory CI regression comparison authorized by SysRS-308 shall use an explicitly declared tolerance window — a numeric percentage (or a numeric per-metric percentage set) above the maintained baseline (SysRS-307) — beyond which the advisory check shall mark the run as a regression. The tolerance shall be a single declared value (or one declared value per metric), not an ad-hoc reviewer judgement, so that the advisory signal is reproducible. The specific numeric value(s) of the tolerance window and the comparison methodology (for example, "comparison against the most recent baseline snapshot on the default branch") shall be authored at the SysDes layer and may be refined at SAD/SDD; a suggested starting value of +20% over baseline is recorded here for downstream traceability but is not binding at the SysRS layer. Cross-references: SysRS-307 (the baselines being compared against), SysRS-308 (the advisory CI surface in which the comparison runs), SysRS-180/SysRS-181 (latency intent the tolerance must not silently erode), SysRS-295 (the tolerance window value is a project-local configuration and does not authorize off-device telemetry).

Priority: P0
Verification: Review (SysDes/SAD declaration of tolerance value is present and is referenced by the CI workflow definition)

SysRS-310: The Chanora application system shall support macOS runtime deployment on macOS 13.0 (Ventura) or later as the minimum supported runtime, unless Flutter, plugin, audio, or platform constraints require raising the minimum version. This clause ratifies at the SysRS layer the existing macOS baseline already encoded in apps/chanora_flutter/macos/chanora_bridge.podspec (MACOSX_DEPLOYMENT_TARGET = 13.0) and provides explicit cross-platform-baseline coverage parallel to SysRS-286 (iOS) and SysRS-288 (Android). Rationale: macOS 13.0 is the floor that supports the modern CoreAudio / VoiceProcessingIO surfaces relied on by the realtime audio path, native arm64 Apple Silicon builds (no Rosetta dependence), and the SDK version used by the existing podspec lipo step that produces the universal binary; a lower minimum would require backporting audio code paths or shipping a non-universal build, neither of which is in P0-MVP scope. The minimum may be raised further (for example, to macOS 14 / Sonoma to gain the kAUVoiceIOProperty_OtherAudioDuckingConfiguration AudioUnit property) only via a superseding accepted decision recorded as a DEC entry; it shall not be lowered without a superseding accepted decision. Cross-references: SAD-087 (architectural macOS runtime allocation), SDD-119 (macOS bridge build pipeline consuming this baseline), SysRS-286 (iOS minimum runtime parallel), SysRS-288 (Android minimum runtime parallel). ID-allocation note: this clause uses SysRS-310 rather than the structurally parallel SysRS-290 because SysRS-290 is already allocated (MVP single-active-server-connection scope); monotonic numbering convention is preserved.

Priority: P0
Verification: Review (the SysRS baseline matches the podspec MACOSX_DEPLOYMENT_TARGET setting), Platform Test (the produced macOS binary runs on a macOS 13.0 system)

32. Change History Addendum

Version	Date	Description
0.9.1	2026-05-14	Added platform runtime baselines, Apple SDK submission gate, Android Play target gate, MVP connection scope, audio defaults, audio implementation path, local database, bridge, and diagnostics/crash reporting policy requirements.

Baseline Candidate 0.9.2 Update

Version	Date	Description
0.9.2	2026-05-14	Corrected Apple App Store Connect upload gate effective date to 2026-04-28 and propagated distinction between runtime deployment target and build-SDK upload gate.

Baseline Candidate 0.9.3 Update

Version	Date	Description
0.9.3	2026-05-15	Added desktop Push-to-Talk requirements SysRS-296 through SysRS-302: mandatory Focused PTT on Windows/macOS/Linux, capability-dependent Global PTT, capability-level exposure to UI and release record, Windows Raw Input + low-level-hook + Focused fallback ladder, macOS permission-aware Global PTT, Linux capability-dependent Global PTT (GNOME on Wayland officially-tested per DEC-026), and the privacy rule prohibiting raw key-event history in logs and diagnostic exports. Owner-resolved gen2 review questions PTT-OPEN-001..006 land as DEC-023..028 in the product decision register.

Baseline Candidate 0.9.5 Update

Version	Date	Description
0.9.5	2026-05-15	Added v1 audio + PTT lifecycle requirements SysRS-303 and SysRS-304 capturing the no-manual-start audio engine bound to voice-channel membership, the v1 transmit-mode set (`Ptt` default, `Continuous`, and platform-scoped `VoiceActivity` per DEC-030), the listen-only flow (output independent of mic permission), the hard-mute override, and the 200 ms (0–500 ms) PTT release tail for word-boundary anti-clipping.

Baseline Candidate 0.9.9 Update

Version	Date	Description
0.9.9	2026-05-17	Reconciled SysRS-288 with DEC-004 (Accepted 2026-05-14): Android minimum runtime baseline raised from API 24 to API 28 (Android 9.0); rationale and decision citation added in-line. Verified SysRS-055, SysRS-161, SysRS-195, SysRS-217, and SysRS-289 remain consistent with DEC-004 (no API-level text in any of these; no rewrite required). Added SysRS-305 (Android in-call audio mode engagement during active voice session — back-fills the v0.9.8 product-decision-register `AudioManager.setMode(MODE_IN_COMMUNICATION)` entry) and SysRS-306 (explicit Android runtime microphone permission acquisition at or before voice session activation, additive to SysRS-055).

Baseline Candidate 0.9.10 Update

Version	Date	Description
0.9.11	2026-05-18	Closed the Wave 1.5 traceability-audit deferred-but-optional follow-up by adding SysRS-310 (macOS minimum runtime baseline at macOS 10.15 / Catalina), ratifying at SysRS layer the existing `apps/chanora_flutter/macos/chanora_bridge.podspec` `MACOSX_DEPLOYMENT_TARGET = 10.15` setting and providing explicit cross-platform-baseline coverage parallel to SysRS-286 (iOS) and SysRS-288 (Android). Allocated SysRS-310 rather than SysRS-290 because SysRS-290 is already taken (MVP single-active-server-connection scope); monotonic numbering convention preserved. No change to the numeric baseline value; any future raise (e.g., to macOS 11.0 / Big Sur for native Apple Silicon performance gains) is flagged as a DEC-level change, not authored here.
0.9.10	2026-05-18	Authorized Option B of the benchmark-infrastructure decision for the realtime audio path. Added SysRS-307 (maintained numeric performance baselines for the realtime audio capture and playback paths — heap allocation count per callback after warmup, per-callback wall-clock budget relative to the audio frame period, Opus encode/decode latency, and resampler throughput at common rate-pair conversions; extends SysRS-180/SysRS-181 from prescriptive intent into a measurable contract; consistent with SysRS-186 and SysRS-236). Added SysRS-308 (advisory CI regression reporting executing the benchmark suite on every PR and every merge to the default branch on at least one host architecture, surfacing results in the PR status-check view; explicitly advisory only — does not fail the build, does not block merge; escalation to a build-failing hard gate is out of scope and deferred to a future SysRS clause after baseline maturity; consistent with the SysRS-234..239 verification-family pattern). Added SysRS-309 (explicitly declared numeric tolerance window for the advisory comparison; numeric value(s) and comparison methodology delegated to SysDes/SAD; suggested starting value +20% recorded as non-binding downstream guidance). All three new clauses are consistent with SysRS-295 (no automatic telemetry / diagnostic upload in MVP) — they neither authorize nor require off-device transmission of measurement data beyond the existing CI provider surface visible to repository collaborators. Explicitly NOT authored in this update: (a) Dimension 3 production telemetry export of timing histograms (deferred to P1; any future opt-in performance-evidence export through the user-initiated diagnostic-export path requires a separate P1 SysRS clause and must be reconciled with SysRS-295 at that time); (b) build-failing hard CI gate (deferred to a future SysRS clause).

Baseline Candidate 0.9.12 Update

Version	Date	Description
0.9.12	2026-06-07	Raised the macOS minimum runtime baseline in `SysRS-310` from macOS 10.15 (Catalina) to macOS 13.0 (Ventura) to match the actual floor encoded in `apps/chanora_flutter/macos/chanora_bridge.podspec` (`MACOSX_DEPLOYMENT_TARGET = 13.0`) and `apps/chanora_flutter/macos/macos_deployment_target.rb`. The previous 10.15 text was a documentation lag; no behavioural change, no DEC-level raise, and the podspec + Xcode project are unchanged. macOS 13.0 is the floor that supports native arm64 Apple Silicon without Rosetta, modern CoreAudio / VoiceProcessingIO surfaces, and the podspec lipo step that produces the universal binary. Strict layered sourcing preserved (`SysDes -> SysRS` only).

82 KiB Raw Permalink Blame History Unescape Escape