edison/chanora
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
chanora/docs/srs.md
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

2851 lines
191 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Chanora SRS — Software Requirements Specification
**Product name:** Chanora
**Document type:** SRS / Software Requirements Specification
**ASPICE process alignment:** SWE.1 Software Requirements Analysis
**Version:** 0.9.9
**Status:** Baseline Candidate
**Source baseline:** `chanora_SysDes_ASPICE_SYS3_v0.5.md`
**Architecture baseline:** Flutter + Rust Core + `tsclientlib` protocol adapter
**Target client platforms:** Windows, macOS, Linux, iOS, Android
**Repo path:** `docs/requirements/srs.md` ---
## 1. Purpose
This SRS defines the software requirements for the Chanora client application. It is derived from the approved SysDes baseline and is written in the style of ASPICE SWE.1 Software Requirements Analysis.
The SRS covers all SysDes design items that require implementation or enablement by the software team, including software-facing constraints from hardware, operating system services, networks, external compatible servers, deployment, diagnostics, and verification.
Chanora remains an application, not an operating system. The software requirements specify what the Chanora software shall do and what operating-environment assumptions or interfaces it shall handle.
## 2. ASPICE SWE.1 Alignment
This document addresses the following SWE.1 concerns:
- Specify software requirements from system requirements and system architecture.
- Structure and prioritize software requirements.
- Analyze software requirements for correctness, technical feasibility, and operating-environment impact.
- Establish consistency and traceability to system architecture; system-requirement coverage is inherited through the SysDes allocation chain.
- Communicate the agreed software requirements and impact analysis to affected parties.
## 3. Software Scope
### 3.1 In Scope for Software Team
The software team owns or implements the following software elements:
- Chanora application container
- Flutter UI layer
- Flutter state layer
- Flutter-Rust bridge layer
- Rust Core and connection manager
- Protocol adapter using `tsclientlib`
- State synchronization engine
- Audio subsystem
- Platform adapter software layer
- Local data store integration
- Secure storage integration layer
- Diagnostics and observability subsystem
- Software-facing deployment scripts and release metadata
- Software verification hooks and test-support tooling
### 3.2 Out of Scope for Software Implementation
- Implementing or operating external TeamSpeak 3-compatible servers
- Controlling user-managed network infrastructure, routers, VPNs, NAT devices, or ISPs
- Manufacturing or controlling physical audio hardware
- Changing operating system vendor policies for permissions, secure storage, background execution, or app-store review
- Providing a Chanora-operated backend for MVP voice, channels, or text
Software shall still handle these items as external interfaces, constraints, assumptions, degraded states, or error conditions where applicable.
## 4. Requirement Attribute Model
Each SRS requirement uses the following attributes.
| Attribute | Meaning |
|---|---|
| SRS ID | Unique software requirement identifier, formatted as `SRS-XXX` |
| Type | Functional, non-functional, interface, platform, security, diagnostics, packaging, analysis, or process classification |
| Stage | Delivery stage: `P0 / MVP`, `P1 / Beta`, `P2 / Production`, or `P3 / Future` |
| Allocated to | Software component or software engineering responsibility |
| Source SysDes | System design item(s) from which the software requirement is directly derived |
| Verification method | Review, inspection, unit test, integration test, system test, platform test, security audit, performance test, demo, or release audit |
| Acceptance criteria | Objective condition for acceptance |
| Analysis | Technical feasibility and impact note |
## 4.1 Traceability Policy
This SRS uses `Source SysDes` as the only direct upstream source field for individual `SRS-XXX` requirements.
The approved lifecycle chain is:
```text
System requirements baseline -> SysDes -> SRS
```
Therefore:
- System-level requirements are allocated and justified in SysDes.
- SRS requirements are derived from SysDes design items.
- Individual SRS requirements shall cite `Source SysDes` only.
- Individual SRS requirements shall not directly cite upstream system requirement IDs.
- A missing software need shall be fixed by correcting SysDes first, then deriving or updating SRS.
## 5. Software Requirements
### 5.1 SWE.1 Process, Traceability, and Baseline Requirements
**SRS-001**: The software requirements specification shall define software requirements derived from the approved Chanora SysDes baseline.
- Type: Process / SWE.1
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-001 through SysDes-003
- Verification method: Review
- Acceptance criteria: SRS contains requirement statements, attributes, and source links to SysDes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-002**: Each software requirement shall have a unique `SRS-XXX` identifier, type, stage, software allocation, source SysDes link, verification method, acceptance criteria, and feasibility analysis.
- Type: Process / Requirement Attribute
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-004 through SysDes-009, SysDes-092 through SysDes-097
- Verification method: Inspection
- Acceptance criteria: Every SRS item contains the mandatory attribute fields.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-003**: The software requirements shall be structured by software component and cross-cutting concern to support allocation to the software team.
- Type: Process / Structuring
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039
- Verification method: Review
- Acceptance criteria: Document sections map to UI, state, bridge, Rust Core, protocol, audio, storage, diagnostics, platform adapters, packaging, and verification hooks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-004**: The software requirements shall be prioritized using P0 / MVP, P1 / Beta, P2 / Production, and P3 / Future stage labels.
- Type: Process / Prioritization
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110
- Verification method: Inspection
- Acceptance criteria: Each SRS item contains a stage value.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-005**: The software requirements shall maintain bidirectional traceability to SysDes design items only; upstream system-requirement coverage shall be inherited through the approved SysDes allocation baseline.
- Type: Process / Traceability
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110
- Verification method: Inspection
- Acceptance criteria: Coverage matrix shows SysDes-to-SRS and SRS-to-SysDes mappings, without direct links from SRS requirements to upstream system requirement IDs.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-006**: The software requirements shall analyze impact on the operating environment for OS services, audio hardware, network connectivity, external compatible servers, secure storage, deployment, and mobile lifecycle constraints.
- Type: Process / Operating Environment Analysis
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101
- Verification method: Review
- Acceptance criteria: Operating environment section identifies software impacts and external dependencies.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-007**: The agreed SRS baseline shall be communicated to SAD, SDD, implementation, and verification authors.
- Type: Process / Communication
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-003, SysDes-098 through SysDes-100
- Verification method: Review
- Acceptance criteria: Revision history and communication section identify affected parties and downstream use.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.2 Software Boundary and Architecture Requirements
**SRS-008**: The software shall be implemented as a cross-platform client application and shall not be implemented or described as an operating system.
- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Application Container
- Source SysDes: SysDes-002, SysDes-024
- Verification method: Review
- Acceptance criteria: App metadata, documentation, and architecture describe Chanora as an application.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-009**: The software shall operate without requiring Chanora-operated backend infrastructure for MVP voice, channel, and text operation.
- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Application Container, Rust Core
- Source SysDes: SysDes-016, SysDes-083
- Verification method: Review, System Test
- Acceptance criteria: MVP operation connects directly to user-provided compatible servers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-010**: The software shall not implement TeamSpeak-compatible server hosting functionality in MVP.
- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Application Container, Protocol Adapter
- Source SysDes: SysDes-023, SysDes-082, SysDes-083
- Verification method: Inspection
- Acceptance criteria: No server-hosting module or process exists in the MVP software.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-011**: The software shall use a layered structure that separates Flutter UI, Flutter State, Bridge, Rust Core, Protocol Adapter, State Sync, Audio, Storage, Diagnostics, and Platform Adapters.
- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: All Software Components
- Source SysDes: SysDes-010, SysDes-038, SysDes-039, SysDes-041
- Verification method: Inspection
- Acceptance criteria: Repository and dependency graph show separate modules/crates/layers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-012**: The software shall keep real-time audio processing outside Flutter UI.
- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Audio Subsystem
- Source SysDes: SysDes-014, SysDes-040, SysDes-071, SysDes-072
- Verification method: Inspection, Performance Test
- Acceptance criteria: Flutter UI does not process PCM frames or execute real-time DSP.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-013**: The software shall support Windows, macOS, Linux, iOS, and Android through shared Flutter UI, shared Rust Core, and platform-specific adapters.
- Type: Platform Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Platform Adapters
- Source SysDes: SysDes-012, SysDes-032, SysDes-041
- Verification method: Build Test
- Acceptance criteria: Target platform builds compile with shared core and platform adapter boundaries.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-014**: The software shall isolate OS-specific permissions, audio routing, lifecycle, secure storage, notification, and packaging behavior behind platform adapter interfaces.
- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Platform Adapters
- Source SysDes: SysDes-032, SysDes-050, SysDes-080
- Verification method: Inspection, Integration Test
- Acceptance criteria: Platform-specific code is not embedded directly in core protocol or state modules.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-015**: The software shall provide verification hooks for protocol, state, audio, security, packaging, and platform behavior.
- Type: Verification Hook
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters
- Source SysDes: SysDes-017, SysDes-102 through SysDes-107
- Verification method: Inspection, Demo
- Acceptance criteria: Tools, logs, and tests expose evidence for each verification area.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.3 Application Container and Flutter UI Requirements
**SRS-016**: The software shall provide an application container that initializes Flutter UI, Bridge, Rust Core, platform adapters, storage, and diagnostics in a deterministic startup sequence.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Application Container
- Source SysDes: SysDes-024, SysDes-038, SysDes-041
- Verification method: Integration Test
- Acceptance criteria: Application startup reaches idle/home state without race-condition crashes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-017**: The software shall provide a home or entry screen for manual connection, recent servers, and saved bookmarks.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI
- Source SysDes: SysDes-025, SysDes-055, SysDes-059
- Verification method: UI Test
- Acceptance criteria: User can open connection and bookmark flows from the entry screen.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-018**: The software shall provide a manual connection UI that accepts host or IP address, port, nickname, and optional server password.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI
- Source SysDes: SysDes-025, SysDes-055, SysDes-059, SysDes-065
- Verification method: UI Test
- Acceptance criteria: Connection request can be submitted with all required fields and validated before dispatch.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-019**: The software shall display connection states including Disconnected, Connecting, Synchronizing, Connected, Reconnecting, and Failed or equivalent user-safe states.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066
- Verification method: UI Test, System Test
- Acceptance criteria: UI state follows Rust Core connection events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-020**: The software shall display a server channel tree derived from the Rust Core snapshot and delta events.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068
- Verification method: UI Test, System Test
- Acceptance criteria: Channel tree updates after initial sync and live channel events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-021**: The software shall display online clients in their channels and update the display after client join, leave, and move events.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068
- Verification method: UI Test, System Test
- Acceptance criteria: Client list reflects snapshot and live delta changes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-022**: The software shall visually identify the current user and current channel when the data is available from Rust Core.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-067
- Verification method: UI Test
- Acceptance criteria: Current user and current channel receive distinct UI state markers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-023**: The software shall provide a channel join interaction that sends a join command through the Bridge and waits for Rust Core or protocol confirmation before treating the join as authoritative.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Bridge, Rust Core
- Source SysDes: SysDes-055, SysDes-069
- Verification method: System Test
- Acceptance criteria: UI does not finalize current-channel state until confirmation or failure event is received.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-024**: The software shall provide channel text chat UI for message display and message input.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Bridge, Rust Core
- Source SysDes: SysDes-025, SysDes-055, SysDes-070
- Verification method: UI Test, System Test
- Acceptance criteria: User can send text and receive displayed messages through core events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-025**: The software shall provide a persistent voice control surface for microphone mute, output deaf, push-to-talk state, input level, and current channel.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Audio Subsystem
- Source SysDes: SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072
- Verification method: UI Test, System Test
- Acceptance criteria: Voice controls are visible and correctly update Rust Core/audio state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-026**: The software shall provide an audio settings UI for input device, output device, Echo Canceller, Automatic Gain Control, Noise Suppression, High-Pass Filter, and related defaults.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Audio Subsystem, Storage
- Source SysDes: SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086
- Verification method: UI Test
- Acceptance criteria: Settings can be changed and persist across application restart where supported.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-027**: The software shall provide permission explanation UI before requesting microphone, notification, or mobile foreground-service related permissions where platform guidelines allow.
- Type: Functional / Privacy
- Stage: P0 / MVP
- Allocated to: Flutter UI, Platform Adapters
- Source SysDes: SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090
- Verification method: UI Test, Privacy Review
- Acceptance criteria: Permission explainers appear before or with OS permission prompts as appropriate.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-028**: The software shall provide a diagnostics UI that allows user-initiated diagnostic export and displays user-safe diagnostic status.
- Type: Functional / Diagnostics
- Stage: P1 / Beta
- Allocated to: Flutter UI, Diagnostics
- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105
- Verification method: UI Test, Security Audit
- Acceptance criteria: User can export diagnostics only by explicit action, and export is redacted.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-029**: The Flutter UI shall not directly invoke `tsclientlib`, access raw protocol types, or own authoritative server state.
- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-040, SysDes-052 through SysDes-054, SysDes-057
- Verification method: Inspection
- Acceptance criteria: Static dependency analysis shows no UI dependency on protocol library types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-030**: The Flutter UI shall subscribe to UI-safe core events and reduce them into presentation state only.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter State
- Source SysDes: SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068
- Verification method: Inspection, UI Test
- Acceptance criteria: State providers/stores are driven by event DTOs and do not mutate Rust-owned server state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-031**: The software shall provide a typed Flutter-Rust Bridge API for connection, channel, chat, voice, settings, storage, and diagnostics commands.
- Type: Interface
- Stage: P0 / MVP
- Allocated to: Bridge Layer
- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056
- Verification method: Integration Test
- Acceptance criteria: Flutter can call each command group through generated or native bindings.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.4 Bridge Requirements
**SRS-032**: The Bridge shall expose long-lived event streams from Rust Core to Flutter for connection, snapshot, delta, chat, voice, audio device, error, and diagnostic events.
- Type: Interface
- Stage: P0 / MVP
- Allocated to: Bridge Layer, Rust Core
- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068
- Verification method: Integration Test
- Acceptance criteria: Flutter receives ordered events and handles stream lifecycle without UI blocking.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-033**: The Bridge shall serialize and deserialize only bridge-safe DTOs and shall not expose Rust internal references or raw protocol library objects.
- Type: Interface / Safety
- Stage: P0 / MVP
- Allocated to: Bridge Layer
- Source SysDes: SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057
- Verification method: Inspection, Integration Test
- Acceptance criteria: Generated bindings contain DTOs and value objects only.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-034**: The Bridge shall map Rust Core errors into user-safe Flutter error DTOs.
- Type: Interface / Error Handling
- Stage: P0 / MVP
- Allocated to: Bridge Layer, Rust Core
- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089
- Verification method: Integration Test
- Acceptance criteria: Known error cases produce category, message, and recovery hint fields.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-035**: The Bridge shall execute commands asynchronously and shall not block the Flutter UI thread during network, storage, or audio operations.
- Type: Non-functional
- Stage: P0 / MVP
- Allocated to: Bridge Layer, Rust Core
- Source SysDes: SysDes-027, SysDes-042, SysDes-046, SysDes-085
- Verification method: Performance Test
- Acceptance criteria: UI remains responsive during connect, reconnect, sync, and diagnostic export.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-036**: The Rust Core shall own authoritative connection lifecycle and server state for each active connection.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Connection state transitions and snapshots are managed in Rust Core.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.5 Rust Core and Connection Management Requirements
**SRS-037**: The Rust Core shall manage connection actors or equivalent isolated execution contexts for connection-specific commands and events.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066
- Verification method: Inspection, Unit Test
- Acceptance criteria: Each connection has an isolated command/event path.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-038**: The Rust Core shall expose connect, disconnect, reconnect, join channel, send message, audio control, settings, bookmark, identity, and diagnostics commands to the Bridge.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core, Bridge
- Source SysDes: SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076
- Verification method: Integration Test
- Acceptance criteria: Bridge command suite calls corresponding Rust Core operations.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-039**: The Rust Core shall coordinate protocol, state synchronization, audio, storage, diagnostics, and platform adapter interfaces without leaking implementation details to Flutter.
- Type: Functional / Architecture
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077
- Verification method: Inspection
- Acceptance criteria: Core public API exposes stable DTOs and not internal crate types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-040**: The Rust Core shall emit connection status events for Connecting, Synchronizing, Connected, Reconnecting, Disconnected, and failure states.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core, State Sync
- Source SysDes: SysDes-060, SysDes-064, SysDes-066, SysDes-074
- Verification method: Unit Test, System Test
- Acceptance criteria: Status event sequence matches connection state machine under normal and failure flows.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-041**: The Rust Core shall suppress automatic reconnect after user-triggered disconnect.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-064, SysDes-073, SysDes-074, SysDes-088
- Verification method: System Test
- Acceptance criteria: User disconnect results in Disconnected state and no reconnect attempt.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-042**: The Rust Core shall apply reconnect policy after recoverable network or protocol failures.
- Type: Functional / Reliability
- Stage: P0 / MVP
- Allocated to: Rust Core, Protocol Adapter, State Sync
- Source SysDes: SysDes-064, SysDes-066, SysDes-074, SysDes-088
- Verification method: System Test
- Acceptance criteria: Recoverable failure enters Reconnecting and either recovers or reports safe failure.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-043**: The Rust Core shall rebuild server state from a fresh snapshot after reconnect succeeds.
- Type: Functional / Reliability
- Stage: P0 / MVP
- Allocated to: Rust Core, State Sync
- Source SysDes: SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088
- Verification method: System Test, Event Replay Test
- Acceptance criteria: Post-reconnect state is produced from new snapshot, not patched from stale state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-044**: The Protocol Adapter shall be the only software component that directly depends on `tsclientlib`.
- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Protocol Adapter
- Source SysDes: SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078
- Verification method: Inspection
- Acceptance criteria: Dependency graph shows `tsclientlib` dependency only in protocol adapter crate/module.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.6 Protocol Adapter Requirements
**SRS-045**: The Protocol Adapter shall connect to TeamSpeak 3-compatible servers through `tsclientlib` using user-provided host, port, nickname, identity, and optional password.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Rust Core
- Source SysDes: SysDes-029, SysDes-043, SysDes-065, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Protocol probe and app can establish a session to a compatible test server.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-046**: The Protocol Adapter shall fetch server information, channel list, client list, and current-user information needed to build the initial snapshot.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, State Sync
- Source SysDes: SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Initial snapshot has server, channel, client, and self-client data.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-047**: The Protocol Adapter shall translate raw `tsclientlib` events into internal protocol events.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, State Sync
- Source SysDes: SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Known client, channel, message, voice, and disconnect events map to internal events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-048**: The Protocol Adapter shall translate protocol errors into normalized Chanora protocol errors.
- Type: Functional / Error Handling
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Rust Core
- Source SysDes: SysDes-029, SysDes-043, SysDes-045, SysDes-088
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Known network, authentication, permission, and protocol failures produce normalized errors.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-049**: The Protocol Adapter shall implement channel join commands and report success or failure to Rust Core.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter
- Source SysDes: SysDes-029, SysDes-043, SysDes-069, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Accessible channel join succeeds; denied join reports user-safe failure.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-050**: The Protocol Adapter shall implement channel text message send and receive paths.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter
- Source SysDes: SysDes-029, SysDes-043, SysDes-070, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Text sent from UI reaches server and incoming text reaches core events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-051**: The Protocol Adapter shall implement voice packet send and receive paths required by the audio subsystem.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Audio Subsystem
- Source SysDes: SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104
- Verification method: Protocol Integration Test, Audio Test
- Acceptance criteria: Encoded outgoing frames are sent and incoming voice packets are delivered to audio pipeline.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-052**: The Protocol Adapter shall expose protocol-probe diagnostics for connection, snapshot, event, text, and voice compatibility.
- Type: Verification Hook
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Diagnostics
- Source SysDes: SysDes-017, SysDes-035, SysDes-102
- Verification method: Demo
- Acceptance criteria: Protocol probe produces compatibility output for test servers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-053**: The Protocol Adapter shall support future patching, forking, or replacement of protocol implementation without changing Flutter UI contracts.
- Type: Maintainability
- Stage: P1 / Beta
- Allocated to: Protocol Adapter, Bridge
- Source SysDes: SysDes-011, SysDes-029, SysDes-043, SysDes-078
- Verification method: Architecture Review
- Acceptance criteria: Protocol adapter trait/API boundary isolates library-specific types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-054**: The State Synchronization Engine shall maintain a connection state model containing connection status, server info, current user, channels, clients, channel tree, permissions, chat state, and voice state where available.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068
- Verification method: Unit Test
- Acceptance criteria: State object can represent required snapshot and runtime states.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.7 State Synchronization Requirements
**SRS-055**: The State Synchronization Engine shall produce a full snapshot event after initial synchronization.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-067
- Verification method: Unit Test, Integration Test
- Acceptance criteria: SnapshotReady event is emitted after server, channel, and client data are available.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-056**: The State Synchronization Engine shall apply live server events as deterministic deltas.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-068
- Verification method: Unit Test
- Acceptance criteria: Same event sequence produces same final state and emitted deltas.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-057**: The State Synchronization Engine shall preserve per-connection event ordering.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync, Rust Core
- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-068
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Out-of-order processing is prevented or deterministically handled per connection.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-058**: The State Synchronization Engine shall use reducer functions or equivalent deterministic logic for snapshot, channel, client, chat, voice, and connection events.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103
- Verification method: Unit Test
- Acceptance criteria: Reducer tests cover snapshot and major delta event types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-059**: The State Synchronization Engine shall replace stale server state with a fresh snapshot after reconnect.
- Type: Functional / Reliability
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103
- Verification method: Event Replay Test, System Test
- Acceptance criteria: Reconnect tests confirm old channel/client state is replaced.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-060**: The State Synchronization Engine shall tolerate malformed or unexpected protocol events without crashing the application.
- Type: Reliability
- Stage: P0 / MVP
- Allocated to: State Sync, Rust Core
- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103
- Verification method: Unit Test, Fuzz/Negative Test
- Acceptance criteria: Malformed event tests produce safe error or ignored event behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-061**: The State Synchronization Engine shall provide replayable event recording hooks for debugging state synchronization.
- Type: Verification Hook
- Stage: P1 / Beta
- Allocated to: State Sync, Diagnostics
- Source SysDes: SysDes-030, SysDes-035, SysDes-079, SysDes-103
- Verification method: Demo
- Acceptance criteria: Recorded event stream can be replayed to reproduce state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-062**: The Audio Subsystem shall coordinate audio capture, preprocessing, audio processing, Opus-compatible encoding, voice packet handoff, receive decoding, jitter buffering, per-user controls, mixing, and playback.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104
- Verification method: Audio Integration Test
- Acceptance criteria: End-to-end voice send and receive operate through the audio subsystem.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.8 Audio Subsystem Requirements
**SRS-063**: The Audio Subsystem shall process outgoing microphone PCM frames before encoding.
- Type: Functional
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Capture pipeline accepts PCM frames and outputs encoded voice frames when gate allows.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-064**: The Audio Subsystem shall apply a High-Pass Filter before voice encoding when enabled.
- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: Low-frequency attenuation is measurable in HPF test cases.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-065**: The Audio Subsystem shall apply Noise Suppression before voice encoding when enabled.
- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: Stationary-noise reduction is measurable or verified by backend tests.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-066**: The Audio Subsystem shall apply Echo Canceller before voice encoding when enabled and when playback reference audio is available or the selected backend provides equivalent behavior.
- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: Echo cancellation backend can use playback reference or platform equivalent.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-067**: The Audio Subsystem shall apply Automatic Gain Control before voice encoding when enabled.
- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: AGC normalizes input gain without unacceptable clipping under test cases.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-068**: The Audio Subsystem shall expose enable/disable settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter.
- Type: Functional / Settings
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI, Storage
- Source SysDes: SysDes-031, SysDes-033, SysDes-056, SysDes-081
- Verification method: UI Test, Unit Test
- Acceptance criteria: Changing each setting updates Rust Core/audio configuration and persists locally.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-069**: The Audio Subsystem shall support conservative default audio processing configuration per platform.
- Type: Non-functional / Audio
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-013, SysDes-031, SysDes-081, SysDes-086
- Verification method: Review, Audio Test
- Acceptance criteria: Default configuration is documented and validated for each supported platform.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-070**: The Audio Subsystem shall provide an audio processing backend abstraction supporting platform-native and Rust-based implementations.
- Type: Architecture / Audio
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-031, SysDes-032, SysDes-058, SysDes-081
- Verification method: Inspection
- Acceptance criteria: Backend trait/interface allows substitution without Flutter UI changes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-071**: The Audio Subsystem shall encode outgoing voice using an Opus-compatible encoder.
- Type: Functional / Audio Codec
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: PCM input produces decodable Opus-compatible encoded frames.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-072**: The Audio Subsystem shall decode incoming voice using an Opus-compatible decoder.
- Type: Functional / Audio Codec
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Incoming encoded frames produce expected PCM output.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-073**: The Audio Subsystem shall use jitter buffering for incoming voice packets.
- Type: Functional / Audio Playback
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Packet jitter test produces continuous playback without buffer instability within defined limits.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-074**: The Audio Subsystem shall support per-user mute during playback.
- Type: Functional / Audio Playback
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI
- Source SysDes: SysDes-031, SysDes-058, SysDes-072
- Verification method: Audio Test, UI Test
- Acceptance criteria: Muted remote user is not mixed into output.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-075**: The Audio Subsystem shall support per-user volume during playback.
- Type: Functional / Audio Playback
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Flutter UI, Storage
- Source SysDes: SysDes-031, SysDes-033, SysDes-058, SysDes-072
- Verification method: Audio Test, UI Test
- Acceptance criteria: Remote user gain changes affect only that user and persist where applicable.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-076**: The Audio Subsystem shall mix decoded incoming voice streams before playback.
- Type: Functional / Audio Playback
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Multiple incoming streams are mixed into a playback stream without clipping beyond defined limits.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-077**: The Audio Subsystem shall implement microphone mute as a gate that prevents local voice transmission.
- Type: Functional / Voice Control
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Rust Core, Flutter UI
- Source SysDes: SysDes-031, SysDes-063, SysDes-071
- Verification method: System Test
- Acceptance criteria: When muted, no outgoing voice packets are sent.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-078**: The Audio Subsystem shall implement output deaf as a gate that prevents incoming voice playback.
- Type: Functional / Voice Control
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Rust Core, Flutter UI
- Source SysDes: SysDes-031, SysDes-063, SysDes-072
- Verification method: System Test
- Acceptance criteria: When deafened, incoming voice is not played.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-079**: The Audio Subsystem shall implement push-to-talk gating before outgoing voice packet transmission.
- Type: Functional / Voice Control
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI
- Source SysDes: SysDes-031, SysDes-063, SysDes-071
- Verification method: System Test
- Acceptance criteria: Outgoing voice is sent only when push-to-talk is active unless configured otherwise.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-080**: The Audio Subsystem shall provide input level metering to Rust Core or Flutter through UI-safe events.
- Type: Functional / Voice Metering
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI
- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-071
- Verification method: Audio Test, UI Test
- Acceptance criteria: Input level meter changes with microphone input.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-081**: The Audio Subsystem shall provide speaking indicator events for local and remote users where available.
- Type: Functional / Voice Metering
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, State Sync, Flutter UI
- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-072
- Verification method: Audio Test, UI Test
- Acceptance criteria: Speaking indicators activate according to local gate and remote voice activity.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-082**: The Audio Subsystem shall recover from audio route or device changes by reconfiguring audio streams or entering a user-safe blocked/degraded state.
- Type: Reliability / Audio
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-032, SysDes-050, SysDes-075, SysDes-086
- Verification method: Platform Integration Test
- Acceptance criteria: Device disconnect/change does not crash the app and reports clear status.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-083**: The Audio Subsystem shall provide audio loopback and processing test hooks for verification.
- Type: Verification Hook
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Diagnostics
- Source SysDes: SysDes-017, SysDes-035, SysDes-104
- Verification method: Demo
- Acceptance criteria: Audio test tools can exercise capture, processing, encode/decode, jitter, mixer, and playback paths.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-084**: The software shall persist bookmarks in local non-secret storage.
- Type: Functional / Storage
- Stage: P0 / MVP
- Allocated to: Storage
- Source SysDes: SysDes-033, SysDes-036, SysDes-049
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Bookmark create, update, delete, and list operations persist across restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.9 Storage and Secure Storage Requirements
**SRS-085**: The software shall persist recent servers in local non-secret storage.
- Type: Functional / Storage
- Stage: P1 / Beta
- Allocated to: Storage
- Source SysDes: SysDes-033, SysDes-036, SysDes-049
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Recent server entries are stored and displayed after restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-086**: The software shall persist audio settings in local non-secret storage.
- Type: Functional / Storage
- Stage: P0 / MVP
- Allocated to: Storage, Audio Subsystem
- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Audio settings survive application restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-087**: The software shall persist UI settings in local non-secret storage.
- Type: Functional / Storage
- Stage: P1 / Beta
- Allocated to: Storage, Flutter UI
- Source SysDes: SysDes-033, SysDes-036, SysDes-049
- Verification method: Unit Test, Integration Test
- Acceptance criteria: UI settings survive application restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-088**: The software shall persist per-user volume and per-user mute preferences where applicable.
- Type: Functional / Storage
- Stage: P1 / Beta
- Allocated to: Storage, Audio Subsystem
- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-072
- Verification method: Unit Test
- Acceptance criteria: Preferences are stored by server/user identity keys where available.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-089**: The software shall use SQLite or an equivalent embedded data store for non-secret local data.
- Type: Architecture / Storage
- Stage: P0 / MVP
- Allocated to: Storage
- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-091
- Verification method: Inspection
- Acceptance criteria: Storage implementation uses an embedded local data store and migration mechanism.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-090**: The software shall access platform secure storage only through a secure storage provider abstraction.
- Type: Interface / Security
- Stage: P0 / MVP
- Allocated to: Storage, Platform Adapters
- Source SysDes: SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105
- Verification method: Inspection, Security Audit
- Acceptance criteria: Secrets are read/written through secure storage interface only.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-091**: The software shall store identity private keys using platform secure storage and shall not persist them in plaintext files.
- Type: Security
- Stage: P0 / MVP
- Allocated to: Storage, Platform Secure Storage
- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Filesystem and database inspection shows no plaintext private keys.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-092**: The software shall store server passwords using platform secure storage and shall not persist them in plaintext logs or non-secret database fields.
- Type: Security
- Stage: P0 / MVP
- Allocated to: Storage, Platform Secure Storage, Diagnostics
- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Password values are redacted from logs and absent from non-secret storage.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-093**: The software shall redact secrets before writing diagnostic logs or diagnostic exports.
- Type: Security / Diagnostics
- Stage: P0 / MVP
- Allocated to: Diagnostics, Storage
- Source SysDes: SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Diagnostic redaction tests cover private keys, passwords, tokens, and known secret fields.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-094**: The software shall validate user input before passing values to protocol operations or storage operations.
- Type: Security
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage
- Source SysDes: SysDes-045, SysDes-065, SysDes-089, SysDes-105
- Verification method: Unit Test, Security Test
- Acceptance criteria: Invalid host, port, nickname, password, and path-like values are rejected or sanitized safely.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-095**: The software shall produce structured diagnostic logs for connection, protocol, state, audio, storage, platform, and release-relevant events.
- Type: Diagnostics
- Stage: P0 / MVP
- Allocated to: Diagnostics
- Source SysDes: SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105
- Verification method: Inspection, Demo
- Acceptance criteria: Logs contain structured fields and categories without secrets.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.10 Diagnostics, Security, and Privacy Requirements
**SRS-096**: The software shall support user-initiated diagnostic export.
- Type: Diagnostics
- Stage: P1 / Beta
- Allocated to: Diagnostics, Flutter UI
- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105
- Verification method: Demo, Security Audit
- Acceptance criteria: Export is available only after user action and output is redacted.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-097**: The software shall provide protocol event recording in development or diagnostics mode.
- Type: Diagnostics / Verification Hook
- Stage: P1 / Beta
- Allocated to: Diagnostics, Protocol Adapter, State Sync
- Source SysDes: SysDes-035, SysDes-079, SysDes-102, SysDes-103
- Verification method: Demo
- Acceptance criteria: Recorded protocol/core event file can be generated in diagnostics mode.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-098**: The software shall provide event replay support for state synchronization debugging.
- Type: Diagnostics / Verification Hook
- Stage: P1 / Beta
- Allocated to: Diagnostics, State Sync
- Source SysDes: SysDes-035, SysDes-079, SysDes-103
- Verification method: Demo
- Acceptance criteria: Event replay can rebuild expected state from a recorded sequence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-099**: The software shall provide audio diagnostics for capture, processing backend, codec, jitter buffer, mixer, playback, and route/device status.
- Type: Diagnostics / Verification Hook
- Stage: P1 / Beta
- Allocated to: Diagnostics, Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-035, SysDes-075, SysDes-086, SysDes-104
- Verification method: Demo
- Acceptance criteria: Audio diagnostics report current pipeline and device status.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-100**: The software shall provide network diagnostics for connection status, reconnect attempts, latency where available, and protocol-relevant network failures.
- Type: Diagnostics / Reliability
- Stage: P1 / Beta
- Allocated to: Diagnostics, Rust Core, Protocol Adapter
- Source SysDes: SysDes-035, SysDes-074, SysDes-088, SysDes-102
- Verification method: Demo
- Acceptance criteria: Diagnostics include network and reconnect evidence without secrets.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-101**: The software shall minimize personal data collection in MVP.
- Type: Privacy
- Stage: P0 / MVP
- Allocated to: All Software Components
- Source SysDes: SysDes-090, SysDes-105
- Verification method: Privacy Review
- Acceptance criteria: MVP does not collect telemetry or upload personal diagnostics automatically.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-102**: The software shall not automatically upload diagnostics in MVP.
- Type: Privacy / Constraint
- Stage: P0 / MVP
- Allocated to: Diagnostics
- Source SysDes: SysDes-090, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: No automatic diagnostic upload endpoint or job is present.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-103**: The software shall display user-safe errors without raw internal stack traces.
- Type: Security / Error Handling
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Bridge, Diagnostics
- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089
- Verification method: UI Test, Security Review
- Acceptance criteria: Runtime errors displayed to users contain safe message and recovery hint only.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-104**: The software shall provide a platform adapter interface for microphone capture.
- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071
- Verification method: Platform Integration Test
- Acceptance criteria: Each supported platform can provide captured PCM frames to the audio pipeline.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.11 Platform Adapter Requirements
**SRS-105**: The software shall provide a platform adapter interface for speaker/headphone playback.
- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072
- Verification method: Platform Integration Test
- Acceptance criteria: Each supported platform can play mixed PCM frames from the audio pipeline.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-106**: The software shall provide a platform adapter interface for audio device enumeration and selection where supported.
- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem, Flutter UI
- Source SysDes: SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075
- Verification method: Platform Integration Test
- Acceptance criteria: Input/output device lists are exposed and selection changes are applied or reported as unsupported.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-107**: The software shall provide a platform adapter interface for audio route changes.
- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086
- Verification method: Platform Integration Test
- Acceptance criteria: Route changes are emitted to Rust Core/Flutter and handled safely.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-108**: The software shall provide a platform adapter interface for microphone permission requests.
- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Flutter UI
- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090
- Verification method: Platform Integration Test
- Acceptance criteria: Permission state is queryable and request flow triggers platform permission behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-109**: The software shall provide a platform adapter interface for notification permission requests where required.
- Type: Interface / Platform
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Flutter UI
- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090
- Verification method: Platform Integration Test
- Acceptance criteria: Notification permission flow is available on platforms requiring it.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-110**: The iOS software shall integrate with AVAudioSession or equivalent platform audio session behavior for foreground voice sessions. The session shall be configured for VoIP (`.playAndRecord` + `.voiceChat` + `.mixWithOthers`) only while a voice channel is active, and shall return to a non-disruptive idle state (`.ambient`, inactive, with `.notifyOthersOnDeactivation`) at all other times so that other apps' audio (music, podcasts, navigation) is preserved when the user opens Chanora to read text chat.
- Type: Platform / iOS
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080
- Verification method: iOS Integration Test
- Acceptance criteria: iOS foreground voice session handles capture, playback, route change, and interruption callbacks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-111**: The Android software shall integrate with foreground service behavior for active voice sessions.
- Type: Platform / Android
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080
- Verification method: Android Integration Test
- Acceptance criteria: Android active voice session uses foreground service behavior according to platform rules.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-112**: The Android software shall handle audio focus and Bluetooth route changes where platform APIs expose them.
- Type: Platform / Android
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086
- Verification method: Android Integration Test
- Acceptance criteria: Audio focus loss/gain and Bluetooth route events are handled safely.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-113**: The desktop software shall support validated audio backends for Windows, macOS, and Linux.
- Type: Platform / Desktop
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086
- Verification method: Desktop Integration Test
- Acceptance criteria: Desktop audio capture/playback works on representative Windows, macOS, and Linux systems.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-114**: The software shall provide platform adapter lifecycle events for foreground/background, app resume, app suspend, audio interruption, and shutdown where supported.
- Type: Interface / Platform
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Rust Core, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080
- Verification method: Platform Integration Test
- Acceptance criteria: Lifecycle events reach Rust Core and do not corrupt connection/audio state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-115**: The software shall document unsupported or degraded platform behaviors through user-safe status and diagnostics.
- Type: Platform / Diagnostics
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Diagnostics, Flutter UI
- Source SysDes: SysDes-050, SysDes-075, SysDes-084, SysDes-090
- Verification method: Review, Demo
- Acceptance criteria: Unsupported device/permission/lifecycle cases are visible in UI or diagnostics.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-116**: The software shall produce build artifacts for Windows installer packaging.
- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: Windows installer artifact is generated from configured CI or release script.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.12 Packaging and Release Requirements
**SRS-117**: The software shall produce signed and notarized macOS release builds for production release.
- Type: Packaging
- Stage: P2 / Production
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build/Release Audit
- Acceptance criteria: macOS release process includes signing and notarization evidence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-118**: The software shall produce Linux release packages using the selected supported package formats.
- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: At least one selected Linux package format is generated.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-119**: The software shall produce Android AAB release builds.
- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: Android AAB build succeeds with release configuration.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-120**: The software shall produce iOS TestFlight and App Store release builds when signing assets are available.
- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: iOS archive/export succeeds on supported macOS build environment.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-121**: The software release metadata and in-app wording shall not imply official TeamSpeak affiliation.
- Type: Legal / Product Constraint
- Stage: P0 / MVP
- Allocated to: Application Container, Flutter UI, Deployment Scripts
- Source SysDes: SysDes-005, SysDes-036, SysDes-091, SysDes-106
- Verification method: Legal Review, Inspection
- Acceptance criteria: App metadata, UI copy, README, and store text use independent compatibility wording.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-122**: The software shall provide release-build configuration that disables development-only diagnostic capture unless explicitly enabled for test builds.
- Type: Security / Release
- Stage: P1 / Beta
- Allocated to: Application Container, Diagnostics, Deployment Scripts
- Source SysDes: SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106
- Verification method: Inspection, Security Review
- Acceptance criteria: Production configuration does not enable protocol recording or verbose logs by default.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-123**: The software shall include or support a protocol probe tool for validating `tsclientlib` adapter behavior against compatible test servers.
- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Diagnostics
- Source SysDes: SysDes-017, SysDes-035, SysDes-102
- Verification method: Demo
- Acceptance criteria: Protocol probe reports connection, snapshot, event, text, and voice compatibility evidence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.13 Verification Support Requirements
**SRS-124**: The software shall include reducer tests and event replay tests for state synchronization.
- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: State Sync, Diagnostics
- Source SysDes: SysDes-030, SysDes-035, SysDes-103
- Verification method: Unit Test, Demo
- Acceptance criteria: Reducer and replay tests cover snapshot, delta, reconnect, and malformed-event behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-125**: The software shall include audio loopback and audio processing tests for capture, playback, codec, jitter buffer, mixer, Echo Canceller, AGC, Noise Suppression, and High-Pass Filter.
- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Diagnostics
- Source SysDes: SysDes-031, SysDes-035, SysDes-104
- Verification method: Audio Test, Demo
- Acceptance criteria: Audio verification tools execute required audio processing checks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-126**: The software shall include security verification support for secure storage, private-key handling, password handling, input validation, and diagnostic redaction.
- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: Storage, Diagnostics, Platform Adapters
- Source SysDes: SysDes-034, SysDes-035, SysDes-089, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Security checklist and tests cover required sensitive data behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-127**: The software shall include release verification support for package creation, signing, notarization, app-store builds, and release metadata wording.
- Type: Verification Support
- Stage: P1 / Beta
- Allocated to: Deployment Scripts, Application Container
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test, Release Audit
- Acceptance criteria: Release verification checklist covers each target platform and metadata review.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-128**: The software shall support MVP acceptance verification demonstrating connection, channel tree, online clients, channel join, send/receive voice, mute, deaf, push-to-talk, required audio processing, channel text, bookmarks, secure storage, and redacted diagnostics.
- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: All Software Components
- Source SysDes: SysDes-017, SysDes-035, SysDes-102 through SysDes-107
- Verification method: System Test, Demo
- Acceptance criteria: MVP acceptance test run passes all acceptance checks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-129**: The software shall expose clear user-facing errors when client hardware lacks a usable microphone, output device, CPU capacity, storage, or network interface required for the requested operation.
- Type: Operating Environment Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-020, SysDes-045, SysDes-086, SysDes-089
- Verification method: System Test
- Acceptance criteria: Missing hardware/resource conditions produce non-crashing user-safe errors.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.14 Operating Environment and External Interface Requirements
**SRS-130**: The software shall expose clear user-facing errors when network connectivity prevents server connection or real-time voice operation.
- Type: Operating Environment Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Protocol Adapter
- Source SysDes: SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088
- Verification method: System Test
- Acceptance criteria: Network failures produce reconnect or safe error behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-131**: The software shall handle external compatible server permissions, availability, and event behavior as external dependencies and shall not assume administrative control.
- Type: Operating Environment Constraint
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Rust Core, Flutter UI
- Source SysDes: SysDes-023, SysDes-043, SysDes-082, SysDes-102
- Verification method: System Test
- Acceptance criteria: Permission denied and server unavailable cases produce user-safe outcomes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-132**: The software shall allow server details, credentials, and identity selection to be supplied by the user rather than hardcoding a server environment.
- Type: Functional / Environment
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage
- Source SysDes: SysDes-019, SysDes-023, SysDes-055, SysDes-065
- Verification method: UI Test, System Test
- Acceptance criteria: User can provide and save server details without Chanora backend dependency.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-133**: The software shall integrate with OS-level secure storage, permission, audio, network, notification, lifecycle, and app sandboxing policies through platform adapters.
- Type: Operating Environment Interface
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Rust Core, Flutter UI
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090
- Verification method: Platform Integration Test
- Acceptance criteria: Platform services are used through approved adapter APIs.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-134**: The software team shall analyze `tsclientlib` feasibility for all MVP protocol features and document unsupported or risky features before MVP acceptance.
- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Software Requirements Engineering
- Source SysDes: SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102
- Verification method: Review, Protocol Probe
- Acceptance criteria: Protocol compatibility matrix identifies pass/fail/unknown state for MVP protocol features.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
### 5.15 Technical Feasibility and Impact Analysis Requirements
**SRS-135**: The software team shall analyze real-time audio feasibility on each target platform for capture, playback, required audio processing, and latency.
- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104
- Verification method: Review, Audio Test
- Acceptance criteria: Audio feasibility report exists per platform with known limitations and mitigations.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-136**: The software team shall analyze memory growth and define limits for event queues, chat history, logs, audio buffers, and diagnostic bundles.
- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage
- Source SysDes: SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087
- Verification method: Review, Performance Test
- Acceptance criteria: Resource limit configuration and tests exist for queues, buffers, and logs.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-137**: The software team shall analyze security and privacy impacts of local secrets, logs, diagnostics, permissions, and release configuration.
- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Storage, Diagnostics, Platform Adapters, Flutter UI
- Source SysDes: SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105
- Verification method: Security Review, Privacy Review
- Acceptance criteria: Security/privacy analysis documents risks, mitigations, and verification evidence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-138**: The software team shall analyze operating-environment impacts of mobile lifecycle, foreground service behavior, AVAudioSession behavior, route changes, and app store policies.
- Type: Analysis Requirement
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Audio Subsystem, Deployment Scripts
- Source SysDes: SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106
- Verification method: Review, Platform Test
- Acceptance criteria: Mobile lifecycle analysis documents behavior and limitations.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-139**: The software requirements baseline shall account for SysDes-037: SE-19 Engineering Process and Evidence shall be a defined system element in the Chanora architecture with responsibility for: Architecture reviews, traceability records, verification evidence, compatibility matrix, open decisions, and downstream SRS/SAD/SDD/Verification artifacts.
- Type: Traceability / Coverage
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-037
- Verification method: Review
- Acceptance criteria: SysDes-037 is represented in SRS traceability and downstream software analysis.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-140**: The software requirements baseline shall account for SysDes-062: The permission-blocked mode shall prevent unsafe voice operations while preserving user visibility into corrective actions.
- Type: Traceability / Coverage
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-062
- Verification method: Review
- Acceptance criteria: SysDes-062 is represented in SRS traceability and downstream software analysis.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team
**SRS-141**: The SRS shall use SysDes design items as the mandatory architectural allocation source for every software requirement.
- Type: Process / Traceability
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-108, SysDes-109
- Verification method: Review, Inspection
- Acceptance criteria: Every SRS requirement has a `Source SysDes` field and no individual SRS requirement uses an upstream system-requirement ID as its direct source.
- Analysis: Feasible because SysDes v0.5 defines the downstream derivation rule and software-impacting allocation layer.
- Owner: Software Team
**SRS-142**: If the software team identifies a required software behavior, constraint, or interface that cannot be derived from an existing SysDes design item, the SRS shall not be baselined until the SysDes is revised.
- Type: Process / Change Control
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering, Change Control
- Source SysDes: SysDes-110
- Verification method: Review, Inspection
- Acceptance criteria: Change-control records show SysDes-first correction for any new software requirement source gap.
- Analysis: Feasible through requirements review and change-control workflow before SRS baseline.
- Owner: Software Team
**SRS-143**: The SRS shall maintain a SysDes-to-SRS coverage matrix for all SysDes items that require software implementation, software enablement, software-facing constraint handling, or software verification support.
- Type: Process / Coverage
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering, Verification
- Source SysDes: SysDes-108, SysDes-109, SysDes-110
- Verification method: Review, Inspection
- Acceptance criteria: Coverage matrix shows that each software-impacting SysDes item is covered by one or more SRS requirements, or explicitly identified as non-software-owned.
- Analysis: Feasible with the SysDes metadata register and SRS coverage matrix.
- Owner: Software Team
## 6. Operating Environment Impact Analysis
| Environment element | Software impact | Related SRS |
|---|---|---|
| Client hardware | Software must detect or report missing microphone, output device, CPU/storage/network resource constraints. | SRS-130 |
| OS services | Software must integrate with permissions, secure storage, audio stack, lifecycle, notifications, and sandbox policies through platform adapters. | SRS-105 through SRS-116, SRS-134 |
| Network | Software must handle unreachable servers, recoverable failures, reconnect, and user-safe errors. | SRS-131 |
| External compatible server | Software must treat server permissions, availability, authentication, events, and protocol behavior as external dependencies. | SRS-132, SRS-133 |
| Audio devices | Software must handle input/output device selection, route changes, and degraded audio states. | SRS-107 through SRS-110 |
| Mobile lifecycle | Software must handle foreground voice sessions, audio interruption, route changes, and background policy limits. | SRS-111 through SRS-115, SRS-139 |
| Secure storage | Software must use platform secure storage through an abstraction and avoid plaintext secret persistence. | SRS-091 through SRS-095 |
| Deployment environment | Software must produce platform-specific release packages and safe release metadata. | SRS-117 through SRS-123 |
## 7. Software Requirement Analysis Summary
| Analysis area | Result | Follow-up artifact |
|---|---|---|
| Correctness | Requirements are derived from SysDes and structured by software component. | SAD / SDD |
| Technical feasibility | Feasibility checks are required for `tsclientlib`, audio processing, mobile lifecycle, resource limits, and security. | Analysis report, SAD, SDD |
| Testability | Each requirement contains verification method and acceptance criteria. | Verification plan |
| Operating environment impact | OS services, hardware, network, server, deployment, and mobile lifecycle impacts are captured. | Platform design, Verification plan |
| Traceability | Every SysDes design item is mapped to one or more SRS requirements; direct SRS-to-upstream-system-requirement links are intentionally not used. | Traceability matrix |
| Communication | SRS baseline shall be communicated downstream to SWE.2/SAD, SWE.3/SDD, and SWE.6/Verification. | Review evidence |
## 8. SRS to SWE Lifecycle Handoff
| Downstream process/artifact | SRS handoff content |
|---|---|
| SWE.2 / SAD | Software components, interfaces, static and dynamic architecture constraints, NFR allocation, security and platform boundaries |
| SWE.3 / SDD | DTOs, API contracts, state machines, reducers, storage schema, audio pipeline module design, protocol adapter interfaces, error models |
| SWE.4 | Unit verification needs for reducers, audio processors, protocol mappers, storage logic, redaction, validation, and utility functions |
| SWE.5 | Software integration verification for Flutter-Bridge-Core, protocol-state, audio-platform, storage-secure-store, diagnostics-export, and packaging flows |
| SWE.6 | Integrated software verification against this SRS including MVP acceptance and platform compatibility |
## 9. SysDes to SRS Coverage Matrix
Coverage summary: 110 / 110 SysDes design items are covered by one or more SRS requirements.
Software-impacting SysDes items: 95 / 110. All software-impacting SysDes items are represented in the SRS coverage below. Non-software design items are covered as software assumptions, external-interface constraints, verification hooks, or process controls when they affect software work.
Missing SysDes coverage: None.
| SysDes ID | SysDes allocation | Covered by SRS |
|---|---|---|
| SysDes-001 | System Engineering | SRS-001 |
| SysDes-002 | System Engineering | SRS-001, SRS-008 |
| SysDes-003 | System Engineering | SRS-001, SRS-007 |
| SysDes-004 | System Engineering, Verification | SRS-002 |
| SysDes-005 | System Engineering | SRS-002, SRS-003, SRS-121 |
| SysDes-006 | Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-002, SRS-003, SRS-004 |
| SysDes-007 | System Engineering | SRS-002 |
| SysDes-008 | System Engineering, Verification | SRS-002, SRS-005 |
| SysDes-009 | System Engineering, Verification | SRS-002, SRS-005 |
| SysDes-010 | Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011 |
| SysDes-011 | Software: Protocol Adapter | SRS-044, SRS-053, SRS-134 |
| SysDes-012 | Software: Flutter UI, Software: Rust Core | SRS-013 |
| SysDes-013 | Software: Audio Subsystem | SRS-062, SRS-064, SRS-065, SRS-066, SRS-067, SRS-069, SRS-135 |
| SysDes-014 | Software: Flutter UI, Software: Audio Subsystem | SRS-012, SRS-135 |
| SysDes-015 | Software: Diagnostics, Verification | SRS-093, SRS-095, SRS-137 |
| SysDes-016 | System Engineering | SRS-009 |
| SysDes-017 | Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations | SRS-004, SRS-015, SRS-052, SRS-083, SRS-095, SRS-123, SRS-128, SRS-134 |
| SysDes-018 | External Server, Software: Audio Subsystem, Deployment / Operations | SRS-006 |
| SysDes-019 | User / Operator, Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-096, SRS-132 |
| SysDes-020 | Hardware, Software: Audio Subsystem | SRS-006, SRS-062, SRS-106, SRS-129, SRS-135 |
| SysDes-021 | Platform, Software: Audio Subsystem, Platform Secure Storage | SRS-006, SRS-027, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-137, SRS-138 |
| SysDes-022 | Network | SRS-006, SRS-130 |
| SysDes-023 | External Server, Software: Audio Subsystem, Platform | SRS-006, SRS-010, SRS-131, SRS-132 |
| SysDes-024 | Software, Platform | SRS-008, SRS-016 |
| SysDes-025 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-017, SRS-018, SRS-019, SRS-020, SRS-021, SRS-022, SRS-024, SRS-025, SRS-026, SRS-027, SRS-028, SRS-080, SRS-081, SRS-096, SRS-108, SRS-109 |
| SysDes-026 | Software: Flutter State, Software: Rust Core, Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030 |
| SysDes-027 | Software: Bridge, Software: Rust Core | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-103 |
| SysDes-028 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-036, SRS-037, SRS-038, SRS-039, SRS-136 |
| SysDes-029 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-134 |
| SysDes-030 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-036, SRS-043, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060, SRS-061, SRS-124, SRS-136 |
| SysDes-031 | Software: Audio Subsystem | SRS-025, SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081, SRS-125, SRS-135, SRS-136 |
| SysDes-032 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-013, SRS-014, SRS-027, SRS-070, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-138 |
| SysDes-033 | Software: Audio Subsystem, Software: Storage | SRS-026, SRS-068, SRS-075, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-136 |
| SysDes-034 | Platform Secure Storage | SRS-006, SRS-090, SRS-091, SRS-092, SRS-126, SRS-137 |
| SysDes-035 | Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-028, SRS-052, SRS-061, SRS-083, SRS-093, SRS-095, SRS-096, SRS-097, SRS-098, SRS-099, SRS-100, SRS-122, SRS-123, SRS-124, SRS-125, SRS-126, SRS-128, SRS-136, SRS-137 |
| SysDes-036 | Software: Storage, Deployment / Operations | SRS-006, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-127 |
| SysDes-037 | System Engineering, Verification | SRS-139 |
| SysDes-038 | Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core | SRS-003, SRS-011, SRS-016, SRS-031, SRS-032 |
| SysDes-039 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011, SRS-039 |
| SysDes-040 | Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter | SRS-012, SRS-029, SRS-033, SRS-044 |
| SysDes-041 | Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem | SRS-011, SRS-013, SRS-016 |
| SysDes-042 | System Engineering | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-038, SRS-039, SRS-103 |
| SysDes-043 | External Server, Deployment / Operations, System Engineering, Verification | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-131, SRS-134 |
| SysDes-044 | Software: Flutter UI, Software: Rust Core | SRS-036, SRS-037, SRS-054, SRS-057 |
| SysDes-045 | Hardware, Platform, Network | SRS-031, SRS-034, SRS-048, SRS-094, SRS-103, SRS-129, SRS-130 |
| SysDes-046 | Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering | SRS-020, SRS-032, SRS-035 |
| SysDes-047 | System Engineering | SRS-030, SRS-032, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060 |
| SysDes-048 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-090, SRS-091, SRS-092 |
| SysDes-049 | Software: Bridge, Software: Protocol Adapter | SRS-031, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089 |
| SysDes-050 | Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-014, SRS-027, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-133 |
| SysDes-051 | Software: Protocol Adapter | SRS-036, SRS-037 |
| SysDes-052 | External Server, Software: Protocol Adapter | SRS-029, SRS-033, SRS-039, SRS-047 |
| SysDes-053 | Software: Audio Subsystem | SRS-029, SRS-044 |
| SysDes-054 | Software: Audio Subsystem | SRS-029 |
| SysDes-055 | Software: Storage, Platform Secure Storage | SRS-017, SRS-018, SRS-023, SRS-024, SRS-031, SRS-038, SRS-132 |
| SysDes-056 | Software: Storage | SRS-025, SRS-026, SRS-028, SRS-031, SRS-032, SRS-068, SRS-086, SRS-095, SRS-103, SRS-106 |
| SysDes-057 | Software: Diagnostics, Verification | SRS-029, SRS-030, SRS-033, SRS-037, SRS-044, SRS-047 |
| SysDes-058 | Software: Diagnostics, Verification | SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-104, SRS-105 |
| SysDes-059 | Software: Audio Subsystem, Platform | SRS-017, SRS-018 |
| SysDes-060 | Software: Rust Core | SRS-019, SRS-036, SRS-037, SRS-038, SRS-040 |
| SysDes-061 | Software: Protocol Adapter, Software: Audio Subsystem, Platform | SRS-019, SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-046, SRS-054, SRS-055, SRS-056 |
| SysDes-062 | Software: Audio Subsystem, Platform | SRS-140 |
| SysDes-063 | Software: State Sync | SRS-025, SRS-062, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081 |
| SysDes-064 | Software: Diagnostics, Verification | SRS-019, SRS-036, SRS-040, SRS-041, SRS-042, SRS-130 |
| SysDes-065 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-018, SRS-038, SRS-045, SRS-094, SRS-132 |
| SysDes-066 | Software: Rust Core, Software: Protocol Adapter | SRS-019, SRS-036, SRS-037, SRS-040, SRS-042, SRS-059 |
| SysDes-067 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-032, SRS-036, SRS-043, SRS-046, SRS-054, SRS-055 |
| SysDes-068 | Software: State Sync | SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-047, SRS-054, SRS-056, SRS-057, SRS-058, SRS-060 |
| SysDes-069 | Software: Rust Core, Software: Protocol Adapter | SRS-023, SRS-038, SRS-049 |
| SysDes-070 | Software: Rust Core, Software: Protocol Adapter | SRS-024, SRS-038, SRS-050 |
| SysDes-071 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-077, SRS-079, SRS-080, SRS-104 |
| SysDes-072 | Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-078, SRS-081, SRS-088, SRS-105 |
| SysDes-073 | Software | SRS-038, SRS-041 |
| SysDes-074 | Software: State Sync | SRS-038, SRS-040, SRS-041, SRS-042, SRS-043, SRS-059, SRS-100, SRS-130 |
| SysDes-075 | Software: Audio Subsystem, Platform | SRS-026, SRS-082, SRS-099, SRS-106, SRS-107, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-135, SRS-138 |
| SysDes-076 | Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification | SRS-028, SRS-038, SRS-090, SRS-091, SRS-092, SRS-093, SRS-095, SRS-096, SRS-137 |
| SysDes-077 | Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-039 |
| SysDes-078 | Software: Protocol Adapter | SRS-044, SRS-047, SRS-053, SRS-134 |
| SysDes-079 | Software: State Sync, System Engineering, Verification | SRS-043, SRS-058, SRS-059, SRS-061, SRS-097, SRS-098 |
| SysDes-080 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-014, SRS-090, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-138 |
| SysDes-081 | Software: Audio Subsystem | SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-086, SRS-135 |
| SysDes-082 | Platform | SRS-006, SRS-010, SRS-131 |
| SysDes-083 | Software: Audio Subsystem | SRS-009, SRS-010 |
| SysDes-084 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-006, SRS-115, SRS-122, SRS-134, SRS-138 |
| SysDes-085 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-035 |
| SysDes-086 | Hardware, Network, Software: Audio Subsystem, Platform | SRS-006, SRS-026, SRS-062, SRS-066, SRS-069, SRS-073, SRS-082, SRS-099, SRS-107, SRS-112, SRS-113, SRS-129, SRS-135 |
| SysDes-087 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-095, SRS-136 |
| SysDes-088 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem | SRS-034, SRS-041, SRS-042, SRS-043, SRS-048, SRS-059, SRS-060, SRS-100, SRS-130 |
| SysDes-089 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-034, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-103, SRS-126, SRS-129, SRS-137 |
| SysDes-090 | Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-093, SRS-095, SRS-096, SRS-101, SRS-102, SRS-108, SRS-109, SRS-115, SRS-122, SRS-133, SRS-137 |
| SysDes-091 | Software: Storage, Deployment / Operations, System Engineering, Verification | SRS-004, SRS-006, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-138 |
| SysDes-092 | System Engineering | SRS-002, SRS-005 |
| SysDes-093 | System Engineering | SRS-002, SRS-005 |
| SysDes-094 | System Engineering | SRS-002, SRS-005 |
| SysDes-095 | System Engineering | SRS-002, SRS-005 |
| SysDes-096 | System Engineering | SRS-002, SRS-005 |
| SysDes-097 | System Engineering, Verification | SRS-002, SRS-005 |
| SysDes-098 | Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification | SRS-007, SRS-095 |
| SysDes-099 | System Engineering, Verification | SRS-007 |
| SysDes-100 | System Engineering | SRS-007 |
| SysDes-101 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification | SRS-006 |
| SysDes-102 | External Server, Software: Protocol Adapter | SRS-004, SRS-015, SRS-045, SRS-046, SRS-049, SRS-050, SRS-051, SRS-052, SRS-097, SRS-100, SRS-123, SRS-128, SRS-131, SRS-134 |
| SysDes-103 | Software: State Sync | SRS-004, SRS-015, SRS-058, SRS-059, SRS-060, SRS-061, SRS-097, SRS-098, SRS-124, SRS-128 |
| SysDes-104 | Software: Audio Subsystem | SRS-004, SRS-015, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-072, SRS-073, SRS-076, SRS-083, SRS-099, SRS-125, SRS-128, SRS-135 |
| SysDes-105 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-004, SRS-015, SRS-028, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-095, SRS-096, SRS-101, SRS-102, SRS-126, SRS-128, SRS-137 |
| SysDes-106 | Software: Storage, Deployment / Operations | SRS-004, SRS-015, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-128, SRS-138 |
| SysDes-107 | Verification | SRS-004, SRS-015, SRS-128 |
| SysDes-108 | System Engineering, Software Requirements Engineering, Verification | SRS-004, SRS-005, SRS-141, SRS-143 |
| SysDes-109 | System Engineering, Software Requirements Engineering | SRS-004, SRS-005, SRS-141, SRS-143 |
| SysDes-110 | System Engineering, Software Requirements Engineering, Change Control, Verification | SRS-004, SRS-005, SRS-142, SRS-143 |
## 10. SRS Requirement Register
| SRS ID | Type | Stage | Allocated to | Verification method | Source SysDes |
|---|---|---|---|---|---|
| SRS-001 | Process / SWE.1 | P0 / MVP | Software Requirements Engineering | Review | SysDes-001 through SysDes-003 |
| SRS-002 | Process / Requirement Attribute | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-004 through SysDes-009, SysDes-092 through SysDes-097 |
| SRS-003 | Process / Structuring | P0 / MVP | Software Requirements Engineering | Review | SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039 |
| SRS-004 | Process / Prioritization | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110 |
| SRS-005 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110 |
| SRS-006 | Process / Operating Environment Analysis | P0 / MVP | Software Requirements Engineering | Review | SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101 |
| SRS-007 | Process / Communication | P0 / MVP | Software Requirements Engineering | Review | SysDes-003, SysDes-098 through SysDes-100 |
| SRS-008 | Constraint | P0 / MVP | Application Container | Review | SysDes-002, SysDes-024 |
| SRS-009 | Constraint | P0 / MVP | Application Container, Rust Core | Review, System Test | SysDes-016, SysDes-083 |
| SRS-010 | Constraint | P0 / MVP | Application Container, Protocol Adapter | Inspection | SysDes-023, SysDes-082, SysDes-083 |
| SRS-011 | Architecture Constraint | P0 / MVP | All Software Components | Inspection | SysDes-010, SysDes-038, SysDes-039, SysDes-041 |
| SRS-012 | Architecture Constraint | P0 / MVP | Flutter UI, Audio Subsystem | Inspection, Performance Test | SysDes-014, SysDes-040, SysDes-071, SysDes-072 |
| SRS-013 | Platform Requirement | P0 / MVP | Flutter UI, Rust Core, Platform Adapters | Build Test | SysDes-012, SysDes-032, SysDes-041 |
| SRS-014 | Architecture Constraint | P0 / MVP | Platform Adapters | Inspection, Integration Test | SysDes-032, SysDes-050, SysDes-080 |
| SRS-015 | Verification Hook | P0 / MVP | Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters | Inspection, Demo | SysDes-017, SysDes-102 through SysDes-107 |
| SRS-016 | Functional | P0 / MVP | Application Container | Integration Test | SysDes-024, SysDes-038, SysDes-041 |
| SRS-017 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059 |
| SRS-018 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059, SysDes-065 |
| SRS-019 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066 |
| SRS-020 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068 |
| SRS-021 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068 |
| SRS-022 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test | SysDes-025, SysDes-026, SysDes-030, SysDes-067 |
| SRS-023 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | System Test | SysDes-055, SysDes-069 |
| SRS-024 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | UI Test, System Test | SysDes-025, SysDes-055, SysDes-070 |
| SRS-025 | Functional | P0 / MVP | Flutter UI, Audio Subsystem | UI Test, System Test | SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072 |
| SRS-026 | Functional | P0 / MVP | Flutter UI, Audio Subsystem, Storage | UI Test | SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086 |
| SRS-027 | Functional / Privacy | P0 / MVP | Flutter UI, Platform Adapters | UI Test, Privacy Review | SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 |
| SRS-028 | Functional / Diagnostics | P1 / Beta | Flutter UI, Diagnostics | UI Test, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105 |
| SRS-029 | Constraint | P0 / MVP | Flutter UI, Flutter State | Inspection | SysDes-040, SysDes-052 through SysDes-054, SysDes-057 |
| SRS-030 | Functional | P0 / MVP | Flutter State | Inspection, UI Test | SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068 |
| SRS-031 | Interface | P0 / MVP | Bridge Layer | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056 |
| SRS-032 | Interface | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068 |
| SRS-033 | Interface / Safety | P0 / MVP | Bridge Layer | Inspection, Integration Test | SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057 |
| SRS-034 | Interface / Error Handling | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089 |
| SRS-035 | Non-functional | P0 / MVP | Bridge Layer, Rust Core | Performance Test | SysDes-027, SysDes-042, SysDes-046, SysDes-085 |
| SRS-036 | Functional | P0 / MVP | Rust Core | Unit Test, Integration Test | SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068 |
| SRS-037 | Functional | P0 / MVP | Rust Core | Inspection, Unit Test | SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066 |
| SRS-038 | Functional | P0 / MVP | Rust Core, Bridge | Integration Test | SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076 |
| SRS-039 | Functional / Architecture | P0 / MVP | Rust Core | Inspection | SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077 |
| SRS-040 | Functional | P0 / MVP | Rust Core, State Sync | Unit Test, System Test | SysDes-060, SysDes-064, SysDes-066, SysDes-074 |
| SRS-041 | Functional | P0 / MVP | Rust Core | System Test | SysDes-064, SysDes-073, SysDes-074, SysDes-088 |
| SRS-042 | Functional / Reliability | P0 / MVP | Rust Core, Protocol Adapter, State Sync | System Test | SysDes-064, SysDes-066, SysDes-074, SysDes-088 |
| SRS-043 | Functional / Reliability | P0 / MVP | Rust Core, State Sync | System Test, Event Replay Test | SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088 |
| SRS-044 | Architecture Constraint | P0 / MVP | Protocol Adapter | Inspection | SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078 |
| SRS-045 | Functional | P0 / MVP | Protocol Adapter, Rust Core | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-065, SysDes-102 |
| SRS-046 | Functional | P0 / MVP | Protocol Adapter, State Sync | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102 |
| SRS-047 | Functional | P0 / MVP | Protocol Adapter, State Sync | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078 |
| SRS-048 | Functional / Error Handling | P0 / MVP | Protocol Adapter, Rust Core | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-045, SysDes-088 |
| SRS-049 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-069, SysDes-102 |
| SRS-050 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-070, SysDes-102 |
| SRS-051 | Functional | P0 / MVP | Protocol Adapter, Audio Subsystem | Protocol Integration Test, Audio Test | SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104 |
| SRS-052 | Verification Hook | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 |
| SRS-053 | Maintainability | P1 / Beta | Protocol Adapter, Bridge | Architecture Review | SysDes-011, SysDes-029, SysDes-043, SysDes-078 |
| SRS-054 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068 |
| SRS-055 | Functional | P0 / MVP | State Sync | Unit Test, Integration Test | SysDes-030, SysDes-047, SysDes-061, SysDes-067 |
| SRS-056 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-061, SysDes-068 |
| SRS-057 | Functional | P0 / MVP | State Sync, Rust Core | Unit Test, Integration Test | SysDes-030, SysDes-044, SysDes-047, SysDes-068 |
| SRS-058 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103 |
| SRS-059 | Functional / Reliability | P0 / MVP | State Sync | Event Replay Test, System Test | SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103 |
| SRS-060 | Reliability | P0 / MVP | State Sync, Rust Core | Unit Test, Fuzz/Negative Test | SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103 |
| SRS-061 | Verification Hook | P1 / Beta | State Sync, Diagnostics | Demo | SysDes-030, SysDes-035, SysDes-079, SysDes-103 |
| SRS-062 | Functional | P0 / MVP | Audio Subsystem | Audio Integration Test | SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104 |
| SRS-063 | Functional | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-064 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-065 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-066 | Functional / Audio Processing | P0 / MVP | Audio Subsystem, Platform Adapters | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104 |
| SRS-067 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-068 | Functional / Settings | P0 / MVP | Audio Subsystem, Flutter UI, Storage | UI Test, Unit Test | SysDes-031, SysDes-033, SysDes-056, SysDes-081 |
| SRS-069 | Non-functional / Audio | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-031, SysDes-081, SysDes-086 |
| SRS-070 | Architecture / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Inspection | SysDes-031, SysDes-032, SysDes-058, SysDes-081 |
| SRS-071 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-104 |
| SRS-072 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 |
| SRS-073 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104 |
| SRS-074 | Functional / Audio Playback | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-031, SysDes-058, SysDes-072 |
| SRS-075 | Functional / Audio Playback | P1 / Beta | Audio Subsystem, Flutter UI, Storage | Audio Test, UI Test | SysDes-031, SysDes-033, SysDes-058, SysDes-072 |
| SRS-076 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 |
| SRS-077 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 |
| SRS-078 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-072 |
| SRS-079 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 |
| SRS-080 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-071 |
| SRS-081 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, State Sync, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-072 |
| SRS-082 | Reliability / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Platform Integration Test | SysDes-032, SysDes-050, SysDes-075, SysDes-086 |
| SRS-083 | Verification Hook | P1 / Beta | Audio Subsystem, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-104 |
| SRS-084 | Functional / Storage | P0 / MVP | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 |
| SRS-085 | Functional / Storage | P1 / Beta | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 |
| SRS-086 | Functional / Storage | P0 / MVP | Storage, Audio Subsystem | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081 |
| SRS-087 | Functional / Storage | P1 / Beta | Storage, Flutter UI | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 |
| SRS-088 | Functional / Storage | P1 / Beta | Storage, Audio Subsystem | Unit Test | SysDes-033, SysDes-036, SysDes-049, SysDes-072 |
| SRS-089 | Architecture / Storage | P0 / MVP | Storage | Inspection | SysDes-033, SysDes-036, SysDes-049, SysDes-091 |
| SRS-090 | Interface / Security | P0 / MVP | Storage, Platform Adapters | Inspection, Security Audit | SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105 |
| SRS-091 | Security | P0 / MVP | Storage, Platform Secure Storage | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 |
| SRS-092 | Security | P0 / MVP | Storage, Platform Secure Storage, Diagnostics | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 |
| SRS-093 | Security / Diagnostics | P0 / MVP | Diagnostics, Storage | Security Audit | SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 |
| SRS-094 | Security | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | Unit Test, Security Test | SysDes-045, SysDes-065, SysDes-089, SysDes-105 |
| SRS-095 | Diagnostics | P0 / MVP | Diagnostics | Inspection, Demo | SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105 |
| SRS-096 | Diagnostics | P1 / Beta | Diagnostics, Flutter UI | Demo, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105 |
| SRS-097 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Protocol Adapter, State Sync | Demo | SysDes-035, SysDes-079, SysDes-102, SysDes-103 |
| SRS-098 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, State Sync | Demo | SysDes-035, SysDes-079, SysDes-103 |
| SRS-099 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Audio Subsystem, Platform Adapters | Demo | SysDes-035, SysDes-075, SysDes-086, SysDes-104 |
| SRS-100 | Diagnostics / Reliability | P1 / Beta | Diagnostics, Rust Core, Protocol Adapter | Demo | SysDes-035, SysDes-074, SysDes-088, SysDes-102 |
| SRS-101 | Privacy | P0 / MVP | All Software Components | Privacy Review | SysDes-090, SysDes-105 |
| SRS-102 | Privacy / Constraint | P0 / MVP | Diagnostics | Security Audit | SysDes-090, SysDes-105 |
| SRS-103 | Security / Error Handling | P0 / MVP | Flutter UI, Rust Core, Bridge, Diagnostics | UI Test, Security Review | SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089 |
| SRS-104 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071 |
| SRS-105 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072 |
| SRS-106 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem, Flutter UI | Platform Integration Test | SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075 |
| SRS-107 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086 |
| SRS-108 | Interface / Platform | P0 / MVP | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 |
| SRS-109 | Interface / Platform | P1 / Beta | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 |
| SRS-110 | Platform / iOS | P0 / MVP | Platform Adapters, Audio Subsystem | iOS Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 |
| SRS-111 | Platform / Android | P0 / MVP | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 |
| SRS-112 | Platform / Android | P1 / Beta | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 |
| SRS-113 | Platform / Desktop | P1 / Beta | Platform Adapters, Audio Subsystem | Desktop Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 |
| SRS-114 | Interface / Platform | P1 / Beta | Platform Adapters, Rust Core, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 |
| SRS-115 | Platform / Diagnostics | P1 / Beta | Platform Adapters, Diagnostics, Flutter UI | Review, Demo | SysDes-050, SysDes-075, SysDes-084, SysDes-090 |
| SRS-116 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-117 | Packaging | P2 / Production | Application Container, Deployment Scripts | Build/Release Audit | SysDes-036, SysDes-091, SysDes-106 |
| SRS-118 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-119 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-120 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-121 | Legal / Product Constraint | P0 / MVP | Application Container, Flutter UI, Deployment Scripts | Legal Review, Inspection | SysDes-005, SysDes-036, SysDes-091, SysDes-106 |
| SRS-122 | Security / Release | P1 / Beta | Application Container, Diagnostics, Deployment Scripts | Inspection, Security Review | SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106 |
| SRS-123 | Verification Support | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 |
| SRS-124 | Verification Support | P0 / MVP | State Sync, Diagnostics | Unit Test, Demo | SysDes-030, SysDes-035, SysDes-103 |
| SRS-125 | Verification Support | P0 / MVP | Audio Subsystem, Diagnostics | Audio Test, Demo | SysDes-031, SysDes-035, SysDes-104 |
| SRS-126 | Verification Support | P0 / MVP | Storage, Diagnostics, Platform Adapters | Security Audit | SysDes-034, SysDes-035, SysDes-089, SysDes-105 |
| SRS-127 | Verification Support | P1 / Beta | Deployment Scripts, Application Container | Build Test, Release Audit | SysDes-036, SysDes-091, SysDes-106 |
| SRS-128 | Verification Support | P0 / MVP | All Software Components | System Test, Demo | SysDes-017, SysDes-035, SysDes-102 through SysDes-107 |
| SRS-129 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Audio Subsystem, Platform Adapters | System Test | SysDes-020, SysDes-045, SysDes-086, SysDes-089 |
| SRS-130 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter | System Test | SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088 |
| SRS-131 | Operating Environment Constraint | P0 / MVP | Protocol Adapter, Rust Core, Flutter UI | System Test | SysDes-023, SysDes-043, SysDes-082, SysDes-102 |
| SRS-132 | Functional / Environment | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | UI Test, System Test | SysDes-019, SysDes-023, SysDes-055, SysDes-065 |
| SRS-133 | Operating Environment Interface | P0 / MVP | Platform Adapters, Rust Core, Flutter UI | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090 |
| SRS-134 | Analysis Requirement | P0 / MVP | Protocol Adapter, Software Requirements Engineering | Review, Protocol Probe | SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102 |
| SRS-135 | Analysis Requirement | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104 |
| SRS-136 | Analysis Requirement | P0 / MVP | Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage | Review, Performance Test | SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087 |
| SRS-137 | Analysis Requirement | P0 / MVP | Storage, Diagnostics, Platform Adapters, Flutter UI | Security Review, Privacy Review | SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 |
| SRS-138 | Analysis Requirement | P1 / Beta | Platform Adapters, Audio Subsystem, Deployment Scripts | Review, Platform Test | SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106 |
| SRS-139 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-037 |
| SRS-140 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-062 |
| SRS-141 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Review, Inspection | SysDes-108, SysDes-109 |
| SRS-142 | Process / Change Control | P0 / MVP | Software Requirements Engineering, Change Control | Review, Inspection | SysDes-110 |
| SRS-143 | Process / Coverage | P0 / MVP | Software Requirements Engineering, Verification | Review, Inspection | SysDes-108, SysDes-109, SysDes-110 |
## 11. Revision History
| Version | Date | Description |
|---|---|---|
| 0.1.0 | 2026-05-13 | Initial ASPICE SWE.1-style SRS derived from early SysDes baseline |
| 0.2.0 | 2026-05-13 | Added inherited upstream coverage via SysDes to show complete chained requirement traceability |
| 0.3.0 | 2026-05-13 | Removed all direct individual SRS-to-upstream-system-requirement links; SRS now traces only to SysDes as the system architectural allocation baseline |
| 0.4.0 | 2026-05-13 | Updated source baseline to SysDes v0.5 and added SRS requirements for SysDes-108 through SysDes-110 derivation and change-control rules |
<!--
Validation:
SRS requirement count: 143
SRS IDs unique: True
SysDes IDs referenced: 110 / 110
Missing SysDes IDs: None
Direct upstream system-requirement IDs referenced by SRS items: 0
Old SYS-XXX IDs remaining: 0
Traceability rule: SRS -> SysDes only; upstream system-requirement coverage is inherited via SysDes.
-->
---
## 13. UI/UX, Material 3, Platform, and Internationalization Software Requirements
This section extends the ASPICE SWE.1 Software Requirements Specification. The source baseline for these requirements is **SysDes only**. This SRS does not link directly to system-requirement IDs.
**SRS-144**: The software shall initialize the Flutter client theme using Material 3 as the baseline UI system.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Design System
- Source SysDes: SysDes-111, SysDes-112
- Verification method: Review, Widget Test
**SRS-145**: The software shall provide a Chanora Design System layer above Material 3 for product-specific semantic states.
- Status: Baseline
- Type: Software Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-111, SysDes-112, SysDes-113
- Verification method: Inspection, Widget Test
**SRS-146**: The software shall define semantic tokens for connection states.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-114
- Verification method: Unit Test
**SRS-147**: The software shall define semantic tokens for voice states including speaking, muted, deafened, and push-to-talk active states.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-114
- Verification method: Unit Test
**SRS-148**: The software shall define semantic tokens for latency, packet loss, diagnostics, and error states.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-114
- Verification method: Unit Test
**SRS-149**: The software shall expose design tokens through `ThemeData`, `ColorScheme`, `TextTheme`, component themes, `ThemeExtension`, or equivalent Flutter theming mechanisms.
- Status: Baseline
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-113, SysDes-114
- Verification method: Inspection, Widget Test
**SRS-150**: Feature screens shall not hardcode product semantic colors, spacing, shape, density, or motion values.
- Status: Baseline
- Type: Software Constraint
- Stage: P0 / MVP
- Allocated to: Flutter Feature Screens
- Source SysDes: SysDes-112, SysDes-113, SysDes-114
- Verification method: Review, Static Inspection
**SRS-151**: The software shall provide an Adaptive Shell that resolves compact, medium, and expanded layout classes.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115
- Verification method: Widget Test, Integration Test
**SRS-152**: The compact layout shall use a single-column primary content structure and mobile-appropriate primary navigation.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115, SysDes-116
- Verification method: Widget Test, Integration Test
**SRS-153**: The medium layout shall support side navigation or equivalent navigation rail behavior where available display width permits.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P1 / Beta
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115, SysDes-116
- Verification method: Widget Test, Integration Test
**SRS-154**: The expanded layout shall support persistent side panes and persistent voice controls where available display width permits.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P2 / Production
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115, SysDes-116
- Verification method: Integration Test, System Test
**SRS-155**: The software shall keep connection status visible or directly reachable in compact, medium, and expanded layouts.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Connection UI
- Source SysDes: SysDes-116
- Verification method: Integration Test
**SRS-156**: The software shall keep primary voice controls visible or directly reachable in compact, medium, and expanded layouts.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Voice UI
- Source SysDes: SysDes-116
- Verification method: Integration Test
**SRS-157**: The software shall provide screen-reader semantics for critical connection, voice, channel, diagnostics, and settings controls.
- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Design System
- Source SysDes: SysDes-117, SysDes-130
- Verification method: Accessibility Test
**SRS-158**: The software shall provide localized accessibility labels for icon-only controls.
- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Localization Service
- Source SysDes: SysDes-117, SysDes-130
- Verification method: Accessibility Test, Localization Test
**SRS-159**: The software shall not express critical states by color alone; it shall also use text, iconography, shape, position, or semantic labeling.
- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Design System
- Source SysDes: SysDes-117
- Verification method: Widget Test, Accessibility Test
**SRS-160**: The software shall support visible focus indication and logical focus traversal for desktop and tablet keyboard use.
- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P1 / Beta
- Allocated to: Flutter UI
- Source SysDes: SysDes-117
- Verification method: Widget Test, System Test
**SRS-161**: The software shall keep critical actions reachable under increased text scaling.
- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI
- Source SysDes: SysDes-117
- Verification method: Accessibility Test
**SRS-162**: The software shall apply platform safe area, display cutout, system bar, virtual keyboard, and desktop window inset constraints through shared shell behavior.
- Status: Baseline
- Type: Software Platform Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Platform Adapter
- Source SysDes: SysDes-118
- Verification method: Platform Test
**SRS-163**: The software shall model Android back navigation as a platform back intent handled by the shell or platform service layer.
- Status: Baseline
- Type: Software Platform Requirement
- Stage: P1 / Beta
- Allocated to: Flutter App Shell, Platform Adapter
- Source SysDes: SysDes-118
- Verification method: Platform Test
**SRS-164**: The software shall model iOS navigation gestures, safe areas, keyboard avoidance, and haptics through platform-aware UI services.
- Status: Baseline
- Type: Software Platform Requirement
- Stage: P1 / Beta
- Allocated to: Flutter App Shell, Platform Adapter
- Source SysDes: SysDes-118
- Verification method: Platform Test
**SRS-165**: The software shall provide a Localization Service for product-owned user-visible strings.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119
- Verification method: Unit Test, Integration Test
**SRS-166**: The software shall externalize product-owned user-visible strings into localization resources or an equivalent mechanism.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119
- Verification method: Inspection
**SRS-167**: The software shall provide English as the baseline product locale.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119, SysDes-131
- Verification method: Localization Test
**SRS-168**: The software shall implement deterministic fallback behavior when a translation key is missing.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119, SysDes-131
- Verification method: Unit Test
**SRS-169**: The software shall allow additional locales to be added without changing protocol, audio, state synchronization, or storage modules.
- Status: Baseline
- Type: Software Maintainability Requirement
- Stage: P1 / Beta
- Allocated to: Localization Service, Flutter UI
- Source SysDes: SysDes-119
- Verification method: Review, Inspection
**SRS-170**: The software shall display server-provided server names, channel names, client nicknames, and text messages as content rather than translating them.
- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Protocol DTOs
- Source SysDes: SysDes-120
- Verification method: Integration Test
**SRS-171**: The software shall preserve Unicode text received from compatible servers through protocol adapter, bridge DTO, state store, and UI rendering paths.
- Status: Baseline
- Type: Software Data Requirement
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Bridge, Rust Core, Flutter UI
- Source SysDes: SysDes-120, SysDes-121
- Verification method: Integration Test
**SRS-172**: The software shall use UTF-8 internally for cross-layer text DTOs unless a boundary adapter requires conversion.
- Status: Baseline
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Bridge, Rust Core, Storage, Diagnostics, Protocol Adapter
- Source SysDes: SysDes-121
- Verification method: Inspection, Integration Test
**SRS-173**: The software shall isolate non-UTF-8 or platform-specific string conversion in boundary adapters.
- Status: Baseline
- Type: Software Interface Requirement
- Stage: P1 / Beta
- Allocated to: Protocol Adapter, Platform Adapter, Bridge
- Source SysDes: SysDes-122
- Verification method: Inspection, Integration Test
**SRS-174**: The software shall not corrupt multilingual Unicode content in logs or diagnostic exports unless redaction intentionally removes sensitive content.
- Status: Baseline
- Type: Software Data Integrity Requirement
- Stage: P0 / MVP
- Allocated to: Diagnostics, Storage
- Source SysDes: SysDes-121, SysDes-124
- Verification method: Test, Audit
**SRS-175**: The software shall support bidirectional text display where the Flutter platform text engine supports it.
- Status: Baseline
- Type: Software Internationalization Requirement
- Stage: P2 / Production
- Allocated to: Flutter UI
- Source SysDes: SysDes-123
- Verification method: Localization Test
**SRS-176**: The software shall use locale-aware formatting for user-visible dates, times, numbers, and diagnostic timestamps.
- Status: Baseline
- Type: Software Internationalization Requirement
- Stage: P1 / Beta
- Allocated to: Localization Service, Diagnostics UI
- Source SysDes: SysDes-123, SysDes-124
- Verification method: Localization Test
**SRS-177**: The software shall keep diagnostic event keys, codes, and machine-readable fields language-neutral.
- Status: Baseline
- Type: Software Diagnostics Requirement
- Stage: P1 / Beta
- Allocated to: Diagnostics
- Source SysDes: SysDes-124
- Verification method: Inspection, Test
**SRS-178**: The software shall allow user-facing diagnostic descriptions to be localized independently of machine-readable diagnostic fields.
- Status: Baseline
- Type: Software Diagnostics Requirement
- Stage: P1 / Beta
- Allocated to: Diagnostics, Localization Service
- Source SysDes: SysDes-124
- Verification method: Inspection, Localization Test
**SRS-179**: The software shall maintain UI/UX guideline, design token, component catalog, adaptive layout, and platform behavior documents as downstream design baselines.
- Status: Baseline
- Type: Software Documentation Requirement
- Stage: P1 / Beta
- Allocated to: UX, Software Engineering
- Source SysDes: SysDes-125
- Verification method: Review
**SRS-180**: The software requirements baseline shall derive requirements only from `SysDes-XXX` sources.
- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Engineering
- Source SysDes: SysDes-126, SysDes-127
- Verification method: Inspection
**SRS-181**: The SRS shall not use direct upstream system-requirement source fields or direct system-requirement trace links.
- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Engineering
- Source SysDes: SysDes-127
- Verification method: Inspection
**SRS-182**: The software architecture shall derive architecture items only from `SRS-XXX` sources.
- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Architecture
- Source SysDes: SysDes-128
- Verification method: Inspection
**SRS-183**: The software detailed design shall derive detailed design items only from `SAD-XXX` sources.
- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Design
- Source SysDes: SysDes-129
- Verification method: Inspection
**SRS-184**: Theme, localization, and initial platform adaptation shall be initialized before feature screens render user-visible content.
- Status: Baseline
- Type: Software Dynamic Behavior Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Design System, Localization Service, Platform Adapter
- Source SysDes: SysDes-132
- Verification method: Integration Test
## 14. Updated SRS to SysDes Coverage Statement
| SysDes Range | SRS Coverage |
|---|---|
| SysDes-001 through SysDes-110 | Covered by inherited SRS baseline `SRS-001` through `SRS-143` |
| SysDes-111 through SysDes-132 | Covered by `SRS-144` through `SRS-184` |
## 15. Change History
| Version | Date | Description |
|---|---|---|
| 0.5.0 | 2026-05-14 | Added Material 3, design system, adaptive layout, accessibility, platform behavior, localization, Unicode, diagnostics localization, and strict downstream traceability software requirements. |
---
## 16. Platform Baseline and Product Decision Software Requirements
**SRS-185**: The software shall define iOS 13 as the minimum iOS runtime deployment baseline unless approved platform constraints raise the minimum version.
- Status: Baseline Candidate
- Type: Software Platform Requirement
- Stage: P0 / MVP
- Allocated to: iOS Build Configuration, Platform Adapter
- Source SysDes: SysDes-133
- Verification method: Platform Test, Release Inspection
**SRS-186**: The iOS/iPadOS release build process shall require Xcode 26 or later and the iOS 26 / iPadOS 26 SDK or later for App Store Connect upload on or after 2026-04-28, unless Apple publishes a newer applicable upload requirement before upload.
- Status: Baseline Candidate
- Type: Software Release Requirement
- Stage: P0 / MVP
- Allocated to: iOS Build Configuration, Release Pipeline
- Source SysDes: SysDes-134
- Verification method: Release Inspection
**SRS-187**: The software shall define Android API 28 (Android 9.0) as the minimum Android 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.
- Status: Baseline Candidate
- Type: Software Platform Requirement
- Stage: P0 / MVP
- Allocated to: Android Build Configuration, Platform Adapter
- Source SysDes: SysDes-135
- Verification method: Platform Test, Release Inspection
- Change record: 0.9.6 (2026-05-17) updated minimum Android API from 24 to 28 to align with DEC-004 and the reconciled SysRS-288 wording. ID preserved.
**SRS-188**: The Android release build process shall target the Android API level required by Google Play on the upload date.
- Status: Baseline Candidate
- Type: Software Release Requirement
- Stage: P0 / MVP
- Allocated to: Android Build Configuration, Release Pipeline
- Source SysDes: SysDes-135
- Verification method: Release Inspection
**SRS-189**: The software shall permit only one active server connection per client instance in MVP.
- Status: Baseline Candidate
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Rust Core, Flutter UI, Protocol Adapter, State Sync
- Source SysDes: SysDes-136
- Verification method: System Test
**SRS-190**: The software shall enable AEC, AGC, Noise Suppression, and High-Pass Filter by default where supported and stable, with user or platform control to disable supported processing where applicable.
- Status: Baseline Candidate
- Type: Software Audio Requirement
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Settings UI, Platform Audio
- Source SysDes: SysDes-137
- Verification method: Audio Test
**SRS-191**: The software shall use platform-native audio processing first for MVP where available and stable, and shall isolate any Rust/WebRTC-style fallback behind the audio subsystem boundary.
- Status: Baseline Candidate
- Type: Software Architecture Constraint
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Platform Audio Adapter
- Source SysDes: SysDes-138
- Verification method: Architecture Review, Audio Test
**SRS-192**: The software shall use SQLite or an equivalent embedded local database for non-secret local state and platform secure storage for secrets.
- Status: Baseline Candidate
- Type: Software Storage Requirement
- Stage: P0 / MVP
- Allocated to: Storage, Platform Secure Storage
- Source SysDes: SysDes-139
- Verification method: Storage Test, Security Audit
**SRS-193**: The software shall use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs.
- Status: Baseline Candidate
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Bridge, Flutter State, Rust Core
- Source SysDes: SysDes-140
- Verification method: Integration Test, Architecture Review
**SRS-194**: The software shall not perform automatic diagnostic upload, automatic telemetry upload, or automatic crash reporting in MVP unless a later approved decision updates privacy, security, legal, release, and verification baselines.
- Status: Baseline Candidate
- Type: Software Privacy Requirement
- Stage: P0 / MVP
- Allocated to: Diagnostics, Privacy, Release Pipeline
- Source SysDes: SysDes-141
- Verification method: Privacy Review, Security Audit
**SRS-195**: The software shall expose a `DesktopPttBackend` trait owned by the audio subsystem, with one implementation per supported desktop platform (Windows, macOS, Linux/GNOME-Wayland) and a `FocusedPttBackend` implementation used as the universal terminal fallback. The selected backend shall be discoverable at runtime and shall report its identifier through the diagnostics sanitizer.
- Status: Baseline Candidate
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Audio, Platform Input
- Source SysDes: SysDes-142, SysDes-145
- Verification method: Architecture Review, Unit Test
**SRS-196**: The software shall publish a `PttCapabilityLevel` enum value (`L0` Focused, `L1` Global-shortcut-activation, `L2` Global-hold-to-talk, `L3` Global-with-mouse-buttons, `L4` Device-aware) from the active backend, and the value shall match the actual runtime capability rather than the platform's theoretical maximum.
- Status: Baseline Candidate
- Type: Software Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio, Rust Core
- Source SysDes: SysDes-143
- Verification method: Unit Test, Integration Test
**SRS-197**: The Windows desktop backend shall attempt Raw Input first; if Raw Input is unavailable or initialisation fails, it shall attempt a low-level keyboard hook; if that also fails it shall return `PttCapabilityLevel::L0` and engage Focused PTT. The selected sub-strategy shall be recorded as the backend identifier for diagnostics and release verification.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Windows)
- Source SysDes: SysDes-145
- Verification method: Platform Test (Windows), Unit Test
**SRS-198**: The macOS desktop backend shall query the operating-system Input Monitoring / Accessibility permission state, return `PttCapabilityLevel::L0` while the permission is undecided or denied, and upgrade to the appropriate Global level only after the user grants the required permission. The user shall be able to dismiss the permission prompt and continue using Focused PTT without functional regression.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (macOS)
- Source SysDes: SysDes-145
- Verification method: Platform Test (macOS), User Acceptance Test
**SRS-199**: The Linux desktop backend shall probe the active display server and compositor at runtime. On GNOME-on-Wayland (the officially-tested target per DEC-026), the backend shall use the freedesktop GlobalShortcuts portal. On any other Linux environment the backend shall return `PttCapabilityLevel::L0` and engage Focused PTT.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Linux)
- Source SysDes: SysDes-145
- Verification method: Platform Test (Linux, GNOME Wayland), Unit Test
**SRS-200**: The software shall support mouse side buttons (typically labelled Mouse4 / Mouse5 or "back" / "forward") as bindable inputs for Global PTT on the Windows and macOS backends per DEC-027. The Linux GlobalShortcuts portal binding shall accept whatever input classes the portal exposes for the current session; missing mouse-button support shall not block release.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Windows/macOS/Linux)
- Source SysDes: SysDes-142, SysDes-145
- Verification method: Platform Test, User Acceptance Test
**SRS-201**: The audio engine shall expose `capture_active` and `transmit_active` as independent atomic states. `capture_active` shall reflect the input-stream lifecycle and the platform input-permission state; `transmit_active` shall reflect the PTT subsystem's decision and shall be the only gate on outbound Opus frame emission.
- Status: Baseline Candidate
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Audio
- Source SysDes: SysDes-144
- Verification method: Unit Test, Integration Test
**SRS-202**: The diagnostics subsystem shall reject any log record carrying a raw key code, scan code, virtual-key value, or key-press timing sequence. The diagnostic export shall include the active `PttCapabilityLevel`, the active backend identifier, and the bound input class (for example "keyboard", "mouse-side-button") but shall never include the specific key value of any user binding.
- Status: Baseline Candidate
- Type: Software Privacy Requirement
- Stage: P0 / MVP
- Allocated to: Diagnostics, Audio
- Source SysDes: SysDes-146
- Verification method: Privacy Review, Unit Test, Diagnostic Inspection
**SRS-203**: The software shall implement a missed-key-up watchdog per DEC-028: if `transmit_active` has been true for longer than a configured upper bound without a corresponding release event (for example because the OS suppressed the key-up while the application was minimised), the watchdog shall force `transmit_active` to false and emit a sanitised diagnostic record naming only the capability level and backend identifier.
- Status: Baseline Candidate
- Type: Software Safety Requirement
- Stage: P0 / MVP
- Allocated to: Audio
- Source SysDes: SysDes-142, SysDes-144
- Verification method: Unit Test, Integration Test
**SRS-204**: The audio engine shall open the input and output streams on the user's first voice-channel join of the session and shall close them on the last voice-channel leave. The software shall expose no `start_audio` or equivalent manual-start operation at the bridge surface and shall expose no manual-start affordance in the UI; the bridge shall instead expose `voice_join(channel_id)` and `voice_leave()` operations and the audio engine shall initialise implicitly on the first `voice_join`. Output-stream opening shall not depend on the microphone-permission grant state, so listen-only is a first-class flow.
- Status: Baseline Candidate
- Type: Software Lifecycle Requirement
- Stage: P0 / MVP
- Allocated to: Audio, Bridge, Flutter UI
- Source SysDes: SysDes-150
- Verification method: Integration Test, UI Review
**SRS-205**: The software shall represent the user's voice transmit mode as a `TransmitMode` enum with variants `Ptt`, `Continuous`, and `VoiceActivity`. `VoiceActivity` shall be selectable 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 setting shall be persisted per identity via the identity store where the selected platform supports it. The default value for a fresh install shall be `Ptt`. The UI shall render `VoiceActivity` as disabled/unavailable on unsupported platforms rather than claiming runtime support.
- Status: Baseline Candidate
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Audio, Bridge, Flutter UI
- Source SysDes: SysDes-149
- Verification method: Unit Test, UI Review
**SRS-206**: The software shall expose a `release_tail_ms` configuration value (default 200 ms, validated range 0 through 500 ms inclusive) and shall delay the `true → false` transition of `transmit_active` by `release_tail_ms` after the PTT backend reports key-up. Where the user re-presses the bound input within the tail window, the pending close timer shall be cancelled and `transmit_active` shall remain true. The release tail shall not affect `capture_active`.
- Status: Baseline Candidate
- Type: Software Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio
- Source SysDes: SysDes-151
- Verification method: Unit Test, Integration Test
**SRS-207**: The software shall expose a hard-mute toggle in the Voice Bar UI. While hard-mute is engaged, `transmit_active` shall be forced false regardless of the active transmit mode, the PTT key state, or any other internal signal. Hard-mute state shall be persisted in-session only and shall reset to off when the user joins a new voice channel.
- Status: Baseline Candidate
- Type: Software Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio, Flutter UI
- Source SysDes: SysDes-150
- Verification method: Functional Test, UI Review
**SRS-208**: The Chanora Android client shall engage the Android in-call audio mode (for example via `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) no later than the moment a voice session becomes connected, so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The client shall release the in-call mode (restoring the prior audio mode) when the last active voice session ends.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Android), Platform Adapter (Android)
- Source SysDes: SysDes-152 (Android in-call audio mode subsystem allocation, primary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, Audio Test
- Acceptance criteria: On Android, audio-mode transitions to in-communication on first voice-session connect and reverts on last voice-session disconnect; behaviour is observable via platform audio diagnostics and produces voice-path routing for SCO/built-in mic.
- Analysis: Feasible via the existing Platform Adapter (Android) boundary and JNI call into `AudioManager`. Verification intent (SWE.6): demonstrate audio-mode entry/exit transitions are bound to voice session lifecycle, not to UI screen lifecycle.
- Unresolved assumptions: None at SRS layer. Upstream SysDes derivation now anchored at SysDes-152 (with SysDes-135 retained as platform-baseline context).
**SRS-209**: The Chanora Android client shall request the runtime microphone permission (`RECORD_AUDIO`) at or before voice session activation, and shall not begin microphone capture without that permission having been granted. If the permission is denied, revoked, or not yet decided, the client shall fail safe to listen-only operation (output stream remains available consistent with SRS-204) and shall surface a user-visible path to grant the permission before retrying transmit.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement / Privacy
- Stage: P0 / MVP
- Allocated to: Platform Adapter (Android), Audio, Flutter UI
- Source SysDes: SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow, primary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, UI Test, Privacy Review
- Acceptance criteria: Permission prompt occurs no later than the user's first transmit attempt within a voice session; denial keeps the session alive in listen-only mode (`capture_active = false`, `transmit_active = false`, output stream open per SRS-204); UI exposes a non-blocking path to re-request or open system settings to grant the permission.
- Analysis: Feasible via existing platform permission adapter (SRS-108) and the audio engine's split `capture_active` / `transmit_active` states (SRS-201). Verification intent (SWE.6): demonstrate that listen-only is a first-class flow on denial and that no microphone capture is started prior to grant.
- Unresolved assumptions: None at SRS layer. Upstream SysDes derivation now anchored at SysDes-153 (with SysDes-135 retained as platform-baseline context); reuses the general permission obligation already captured in SRS-027 / SRS-108.
## 17. Updated SRS to SysDes Coverage Statement
| SysDes Range | SRS Coverage |
|---|---|
| SysDes-001 through SysDes-132 | Covered by inherited SRS baseline `SRS-001` through `SRS-184` |
| SysDes-133 through SysDes-141 | Covered by `SRS-185` through `SRS-194` |
| SysDes-142 through SysDes-148 | Covered by `SRS-195` through `SRS-203` |
| SysDes-149 through SysDes-151 | Covered by `SRS-204` through `SRS-207` |
## 18. Android Audio Backend (P0)
This subsection groups the Android voice-audio-backend software requirements derived to support the platform-adapter decision to host Android voice capture and playback through a dedicated low-latency native audio backend (mirroring the iOS voice-processing precedent already represented in the codebase for the iOS path). These requirements close the historical gap in which the Android voice path was carried by a generic desktop-style default backend and the hardware acoustic-echo / noise-suppression / automatic-gain effects were silently not engaged. They are sourced strictly from SysDes (per the SRS layering policy) and additionally cite the upstream SysRS items they help satisfy.
**SRS-210**: The Chanora Android voice audio path shall achieve a round-trip mouth-to-ear ("glass-to-glass") latency of at most 150 ms on Android devices that support AAudio low-latency performance mode, and at most 250 ms on Android devices that do not support low-latency performance mode. For the purpose of this requirement, an Android device is considered to "support AAudio low-latency performance mode" if and only if (a) the client requested `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` on both the input and output streams at stream-open time, and (b) the AAudio stream returned by the platform reports `getPerformanceMode() == AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` after the stream is opened. Devices that downgrade the returned performance mode to `NONE` or `POWER_SAVING` fall under the 250 ms bound.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement / Performance
- Stage: P0 / MVP
- Allocated to: Audio (Android), Platform Adapter (Android)
- Source SysDes: SysDes-154 (Android voice audio backend subsystem — AAudio low-latency performance-mode path with platform-reported observability, primary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, Audio Test, Loopback Latency Measurement
- Acceptance criteria: On at least one reference Android device that returns `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` for the opened streams, instrumented loopback latency (mouth-to-ear, full duplex through the voice engine) does not exceed 150 ms at the 95th percentile across a 60-second measurement window; on at least one reference device that does not, the same measurement does not exceed 250 ms at the 95th percentile.
- Analysis: Feasible on API 28+ (per SRS-187 / DEC-004) using AAudio low-latency streams, which is one of the platform-recommended paths called out by SysRS-055. The latency tiering reflects the well-understood split between devices that expose the fast mixer / low-latency capture path and devices that do not. Verification intent (SWE.6): demonstrate that the chosen native-audio backend on Android opens streams in low-latency mode where the device permits it, and that the measured round-trip latency falls under the tier appropriate to the reported `getPerformanceMode()`.
- Unresolved assumptions: The exact reference-device matrix (which physical handsets define the "supports low-latency" tier vs the fallback tier) should be ratified by the verification owner. The 150 / 250 ms numeric targets are derived from SysRS-055's "production audio integration" intent and are not yet stated numerically at the SysRS layer; if SysRS owners wish to ratify a numeric mouth-to-ear bound, the values here should be considered the SRS-layer derivation and would update accordingly.
**SRS-211**: The Chanora Android voice-capture path shall request the platform "voice communication" input preset where the operating system exposes one, so that the OS-side capture chain (gain shaping, far-end suppression, microphone selection) is the voice-optimised chain rather than the music/media chain. On Android the client shall request `AAUDIO_INPUT_PRESET_VOICE_COMMUNICATION` as the primary preset, and shall fall back to `AAUDIO_INPUT_PRESET_VOICE_PERFORMANCE` if the primary preset is not honoured by the device. This mirrors the precedent on iOS, where the voice-capture path is hosted on the platform voice-processing audio unit (`VoiceProcessingIO`); the Android requirement is the platform-analogous obligation, not a port of iOS code.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Android), Platform Adapter (Android)
- Source SysDes: SysDes-154 (Android voice audio backend subsystem — voice-communication input preset on the capture stream, primary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, Audio Test
- Acceptance criteria: On stream open, the Android voice-capture stream is constructed with input preset = `VOICE_COMMUNICATION`; if the device's AAudio stack reports that the preset was not honoured (or stream open fails specifically due to the preset), the client retries with `VOICE_PERFORMANCE`; the active preset is observable via audio diagnostics. The output-stream usage / content-type obligations are covered separately by SRS-213.
- Analysis: Feasible on API 28+ AAudio (covered by SRS-187). The iOS analogue (voice-processing audio unit) is already realised in the codebase, so the platform-symmetric obligation is well-founded. Verification intent (SWE.6): demonstrate that the input preset is set at stream-construction time, not after stream start, and that the fallback path is taken only on documented preset-rejection conditions.
- Unresolved assumptions: None at SRS layer.
**SRS-212**: Where the Android device exposes the hardware voice-audio effect APIs `AcousticEchoCanceler`, `NoiseSuppressor`, and `AutomaticGainControl`, the Chanora Android client shall engage each available effect on the active microphone capture session (via the platform `audioSession`-id attachment API or the AAudio effect-attachment equivalent) at or before the moment voice capture is started. Where one or more of these hardware effects is not available on the device, the client shall fall back to the equivalent software processing already provided by the cross-platform audio engine, and shall not silently leave that processing disabled. This requirement explicitly closes the prior no-op gap in which the Android path acknowledged the request to engage hardware effects but did not in fact engage them.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Android), Platform Adapter (Android), Audio Engine
- Source SysDes: SysDes-154 (Android voice audio backend subsystem — engagement of platform hardware voice-audio effects with documented software fallback, primary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, Audio Test
- Acceptance criteria: For each of `AcousticEchoCanceler`, `NoiseSuppressor`, `AutomaticGainControl`: on devices where `isAvailable()` is true, the effect is constructed against the capture session id, enabled before the first capture callback delivers samples, and reports `getEnabled() == true` for the duration of the capture session; on devices where the effect is not available, the audio engine's software equivalent is engaged for the same duration. The fall-back decision is recorded in sanitised audio diagnostics.
- Analysis: Feasible via the Android `android.media.audiofx` effect APIs bound to the capture session id surfaced by the native backend. Verification intent (SWE.6): demonstrate via instrumented test that, on at least one device where hardware AEC is reported available, hardware AEC is engaged; and on at least one device where it is not, the software AEC path in the cross-platform engine is engaged. The "silent no-op" prior behaviour is explicitly excluded.
- Unresolved assumptions: None at SRS layer. SRS-208 (Android in-call audio mode) remains the routing-mode obligation; this requirement is the effects-engagement obligation and is complementary, not duplicative.
**SRS-213**: The Chanora Android voice-output stream shall declare `AAUDIO_USAGE_VOICE_COMMUNICATION` and `AAUDIO_CONTENT_TYPE_SPEECH` at stream construction so that the Android audio policy engine routes the stream under the voice-communication routing rules that engage when `MODE_IN_COMMUNICATION` is active (per SRS-208), including correct Bluetooth SCO routing, earpiece-vs-speaker selection, and ducking behaviour against media.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Android), Platform Adapter (Android)
- Source SysDes: SysDes-154 (Android voice audio backend subsystem — voice-communication usage and content-type declarations on the output stream, primary), SysDes-152 (Android in-call audio mode subsystem — output usage is the precondition for in-call-mode routing, secondary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, Audio Test
- Acceptance criteria: The opened AAudio output stream reports usage = `VOICE_COMMUNICATION` and content type = `SPEECH`; with `MODE_IN_COMMUNICATION` engaged (per SRS-208), playback routes to the in-call output device (earpiece / SCO / wired headset) and does not route to the media output device.
- Analysis: Feasible on API 28+ AAudio. The combination is the platform-documented way to opt the stream into the voice routing path and is the playback-side counterpart of SRS-211's capture-side preset selection. Verification intent (SWE.6): demonstrate routing differs from a media-usage stream under `MODE_IN_COMMUNICATION`.
- Unresolved assumptions: None at SRS layer.
**SRS-214**: The Chanora Android voice input and output streams shall request `AAUDIO_SHARING_MODE_EXCLUSIVE` on a best-effort basis at stream construction, and shall gracefully fall back to `AAUDIO_SHARING_MODE_SHARED` when the platform denies exclusive access (for example because another application holds an exclusive stream or because shared media playback is active). The fall-back shall not be reported as a fatal error to the user and shall not prevent voice session establishment; it shall be recorded in sanitised audio diagnostics so that the achieved sharing mode is observable for SRS-210 latency analysis.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Audio (Android), Platform Adapter (Android)
- Source SysDes: SysDes-154 (Android voice audio backend subsystem — best-effort exclusive sharing-mode policy with graceful shared fallback, primary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, Audio Test
- Acceptance criteria: On stream open the client requests `EXCLUSIVE`; on devices that grant it, `getSharingMode()` reports `EXCLUSIVE`; on devices or device states that deny it, the client opens with `SHARED` instead and the voice session proceeds; the achieved sharing mode appears in sanitised audio diagnostics for both the input and the output stream.
- Analysis: Feasible on API 28+ AAudio. Exclusive mode is the documented path to the lowest-latency tier on devices that expose a fast capture/playback path; making the request best-effort avoids regressing the user's ability to join a voice session when another exclusive stream is active. Verification intent (SWE.6): demonstrate both the granted and denied paths and that neither blocks voice session establishment.
- Unresolved assumptions: None at SRS layer.
**SRS-215**: The Chanora Android client shall maintain active microphone capture while the application is backgrounded by hosting voice transmission inside an Android foreground service whose manifest declares `foregroundServiceType="microphone"`. This formalises at the SRS layer the platform-required hosting model under which background microphone capture is permitted on Android 9+ (API 28+) and is the software-requirement counterpart of the existing foreground-service obligation captured in SRS-111.
- Status: Baseline Candidate
- Type: Platform Behavioural Requirement
- Stage: P0 / MVP
- Allocated to: Platform Adapter (Android), Audio (Android), Android Manifest
- Source SysDes: SysDes-154 (Android voice audio backend subsystem — lifecycle binding to the Android microphone-typed foreground service for background voice capture, primary), SysDes-135 (Android platform baseline, secondary/context)
- Verification method: Android Integration Test, Manifest Review
- Acceptance criteria: With the application backgrounded and a voice session active in transmit-capable state, microphone capture continues to deliver frames to the audio engine; the hosting Android service is observable via `dumpsys activity services` (or equivalent platform diagnostics) as a foreground service of type `microphone`; the manifest declares `foregroundServiceType="microphone"` on the hosting service component.
- Analysis: Feasible on API 28+ per SRS-187 / DEC-004; the foreground-service-type attribute is the platform's documented mechanism for declaring background microphone use. Verification intent (SWE.6): demonstrate that the foreground service is started before background microphone capture begins, and that capture stops if the foreground service is not granted.
- Unresolved assumptions: None at SRS layer. SRS-111 remains the higher-level foreground-service obligation; this requirement narrows it to the microphone-typed variant required by the voice transmission path.
## 19. Updated SRS to SysDes Coverage Statement (Android Audio Backend)
| SysDes Range | SRS Coverage |
|---|---|
| SysDes-152 (Android in-call audio mode subsystem) | Primary anchor for `SRS-208`; additionally cited as a secondary anchor by `SRS-213` (output-stream usage/content-type is the precondition for in-call-mode routing). |
| SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow) | Primary anchor for `SRS-209`. |
| SysDes-154 (Android voice audio backend subsystem) | Primary anchor for `SRS-210` (AAudio low-latency performance-mode latency tiering), `SRS-211` (voice-communication input preset with `VOICE_PERFORMANCE` fallback), `SRS-212` (hardware AEC/NS/AGC engagement with software fallback), `SRS-213` (voice-communication output usage/content-type), `SRS-214` (best-effort exclusive sharing mode with shared fallback), and `SRS-215` (microphone-typed foreground-service-hosted background capture). |
| SysDes-135 (Android platform baseline) | Retained as the secondary/context anchor on `SRS-208` through `SRS-215` (the eight Android voice-audio SRS items conceptually rest on the Android platform baseline as their platform context, but no longer take SysDes-135 as the primary derivation). Upstream SysRS items addressed across the eight items are SysRS-055, SysRS-217, SysRS-288, SysRS-305, and SysRS-306. |
## 20. Realtime Audio Benchmark Infrastructure (P0)
This section authors the software-requirements layer of the realtime-audio benchmark infrastructure derived strictly from the SysDes-156 / SysDes-157 / SysDes-158 chain (per SRS-005 strict-layered sourcing). The SysDes anchors are themselves a refinement of SysRS-307 / SysRS-308 / SysRS-309, but the SRS layer does not source upstream of SysDes by policy.
**SRS-216**: The `chanora_audio` software shall expose its realtime capture and playback paths to benchmark instrumentation that covers the five metrics enumerated by SysDes-156: (1) heap allocation count per realtime callback after a warmup window of approximately 100 callbacks (the steady-state expectation is zero allocations on the realtime thread); (2) per-callback wall-clock duration reported at the p50, p95, and p99 percentiles, expressed as a fraction of the active cpal stream period; (3) Opus encode latency measured on the canonical 960-sample / 20 ms voice frame shape; (4) Opus decode latency measured on the same 960-sample / 20 ms frame shape; and (5) resampler throughput measured at the canonical rate pairs 44.1 → 48 kHz, 16 → 48 kHz, and 48 → 48 kHz (the last serving as a passthrough control). The instrumentation shall be authored as Rust benchmarks located in a per-crate `benches/` directory (the choice of benchmark harness crate — `criterion` or equivalent — is a downstream SDD concern and is not authored here). The instrumentation shall consume the existing realtime-path public surface (for example `CaptureState::ingest`, already public at the chanora_audio crate boundary per the Wave 4 Tier A1 work) without introducing new public seams in production code; if any additional seam is required, that decision is delegated to SAD/SDD and is not authored at the SRS layer.
- Status: Baseline Candidate
- Type: Verification Infrastructure Requirement
- Stage: P0 / MVP
- Allocated to: `chanora_audio` crate (realtime capture and playback modules, plus a co-located `benches/` directory)
- Source SysDes: SysDes-156 (realtime-audio benchmark surface allocated to SE-13)
- Verification method: SWE.4 — automated benchmark execution against the instrumentation surface; reviewers confirm the five metric families enumerated in SysDes-156 each have at least one benchmark target.
- Acceptance criteria: A `benches/` directory exists under the `chanora_audio` crate (or the SDD-decided per-crate equivalent); the directory contains benchmark targets that exercise the realtime capture callback, the realtime playback callback, the Opus encoder on a 960-sample / 20 ms frame, the Opus decoder on a 960-sample / 20 ms frame, and the resampler at each of the three canonical rate pairs; each benchmark target reports a numeric value in the unit appropriate to its metric family (count, fraction-of-period, ns/iter, or samples/sec); the benchmarks run to completion on a Linux x86_64 host in under the wall-clock budget allowed by SysDes-157's host scope (see SRS-218).
- Analysis: Feasible. The realtime path already exposes the entry points required for benchmark instrumentation per the chanora_audio crate boundary as of Wave 4 Tier A1; no production-code seam authoring is required at the SRS layer. Verification intent (SWE.6): demonstrate that all five metric families have at least one benchmark target and that the benchmarks execute deterministically on the Linux x86_64 host enumerated by SysDes-157.
- Unresolved assumptions: The exact benchmark harness crate (`criterion` is the conventional choice on the Rust ecosystem but is not authored here) and the exact target-naming convention are SDD concerns. If the realtime path requires a new public seam to be benchmarkable at SRS granularity, that gap will be discovered by the SAD/SDD pass and routed back to a future SRS revision; this clause does not authorise such a seam in production code.
**SRS-217**: Baseline measurements produced by the SRS-216 benchmark instrumentation shall be stored as structured JSON committed to a deterministic location inside the repository, so that the baseline becomes a reviewable, version-controlled artefact rather than an ephemeral CI side effect. Each baseline record shall contain at minimum the following fields: `metric` (string identifier matching the metric name enumerated by SysDes-156), `value` (numeric — the measured value for that metric), `unit` (string — for example `"ns/iter"`, `"samples/sec"`, `"fraction"`, or `"count"`, matching the metric family), `host_arch` (string — the Rust target triple of the measurement host, for example `"x86_64-unknown-linux-gnu"`), `toolchain` (string — the rustc version active at measurement time), `git_sha` (string — the full Git commit SHA at measurement time), and `timestamp` (string — ISO-8601 UTC). The canonical on-disk path for the baseline JSON (for example `benches/baselines/<crate>.json` as a suggestion) is delegated to SDD and is not fixed at the SRS layer; however, the path shall be deterministic (the same crate at the same commit shall write to the same file) and shall be committed to the repository on the default branch.
- Status: Baseline Candidate
- Type: Verification Infrastructure Requirement
- Stage: P0 / MVP
- Allocated to: `chanora_audio` crate (the bench harness publishes the baseline JSON), plus the SDD-decided on-disk path under the repository root.
- Source SysDes: SysDes-156 (baseline storage as structured JSON in a deterministic repo location capturing metric value, host architecture, toolchain version, git SHA, and timestamp).
- Verification method: Review — the JSON record format is review-checkable against this clause by inspecting a sample baseline file.
- Acceptance criteria: A baseline JSON file exists at the SDD-decided deterministic path on the default branch; the file is parseable as JSON; each record carries the seven fields enumerated above; the `metric` field values match the metric names declared by SysDes-156; the `host_arch`, `toolchain`, `git_sha`, and `timestamp` fields are populated with values that correspond to the measurement host and commit; the same crate at the same commit deterministically writes to the same file path.
- Analysis: Feasible. JSON is the conventional serialization format for benchmark-baseline metadata in Rust ecosystem tooling, and the fields enumerated are the minimum needed for the SysDes-157 advisory comparison to be reproducible. Verification intent (SWE.6): inspect a sample baseline file and confirm the seven fields are populated correctly and the file is parseable.
- Unresolved assumptions: The exact on-disk path is delegated to SDD per SysDes-156. The schema may evolve (additional optional fields) without breaking this clause provided the seven enumerated fields remain present.
**SRS-218**: A continuous-integration workflow shall execute the SRS-216 benchmark suite under the constraints authored by SysDes-157, namely: (1) the workflow shall trigger on every pull request opened against the default branch and on every merge to the default branch, and shall not trigger on tag pushes or on pushes to non-default branches; (2) the workflow shall execute on the Linux x86_64 GitHub Actions runner (`ubuntu-latest`) and shall not execute on any other host architecture (multi-host benchmarking is out of scope for this revision per SysDes-157 point 2); (3) the workflow result shall be rendered as a markdown table on the pull-request surface that compares each metric enumerated by SysDes-156 against the baseline-at-merge-base (per SRS-219), with a per-metric visual marker drawn from the set { 🟢 within tolerance, 🟡 within tolerance but trending, 🔴 outside tolerance } evaluated against the per-metric tolerance window of SysDes-158; (4) the workflow shall report a `success` status check regardless of whether any metric is flagged 🔴, so that the advisory check never blocks merge (this enforces the SysDes-157 point 4 non-blocking semantics at the SRS layer); and (5) the baseline-update operation shall be a separate, manually-invoked workflow (GitHub Actions `workflow_dispatch` or equivalent), and the PR-triggered workflow authored by this clause shall never write to the baseline JSON file authored under SRS-217.
- Status: Baseline Candidate
- Type: Verification Infrastructure Requirement
- Stage: P0 / MVP
- Allocated to: CI tooling under `.github/workflows/` (or the SDD-decided equivalent integration point) — specifically a new advisory benchmark workflow file; the exact filename is delegated to SAD/SDD.
- Source SysDes: SysDes-157 (advisory CI integration allocated to SE-18, with the six design constraints on trigger, host, surface, non-blocking semantics, baseline source, and baseline-update isolation).
- Verification method: Demo — a synthetic pull-request run shall demonstrate the workflow firing, the markdown comparison table rendering, the status check reporting `success` even when a 🔴 marker is present, and the absence of any write to the baseline JSON file under the PR-triggered path. Human reviewers confirm in the PR.
- Acceptance criteria: A CI workflow file exists at the SDD-decided path; the file's trigger configuration matches SysDes-157 point 1 (PR-against-default plus merge-to-default, no tags, no non-default-branch pushes); the workflow's `runs-on` clause is `ubuntu-latest`; a PR run posts a markdown table that lists each SysDes-156 metric with its measured value, the baseline value at the PR's merge-base, the percentage delta, and one of the three visual markers; the workflow's status check reports `success` on every run, including runs that contain at least one 🔴 marker; a separate `workflow_dispatch` workflow file exists for the baseline-update operation, and the PR-triggered workflow does not modify the baseline JSON.
- Analysis: Feasible on GitHub Actions. The advisory-only, never-block-on-failure semantics is the active rule per SysRS-308 (inherited via SysDes-157); escalating this workflow to a hard build-failing gate would require a future SysRS authorisation and is not within the scope of SRS-218. Verification intent (SWE.6): observe a synthetic PR run end-to-end and confirm the five constraints (trigger, host, surface, non-blocking semantics, baseline-update isolation).
- Unresolved assumptions: The exact workflow filename, the exact named status-check string, and the exact markdown table layout are SAD/SDD concerns. The triggering criterion for the 🟡 "trending" state is delegated to SDD per SysDes-157's notes (this clause only requires that the marker set { 🟢, 🟡, 🔴 } is present, not how 🟡 is computed).
**SRS-219**: The advisory comparison performed by the SRS-218 workflow shall apply the per-metric tolerance window and the comparison methodology authored by SysDes-158. The tolerance window shall be evaluated per metric as follows: (a) heap allocation count per realtime callback after warmup — tolerance is zero, i.e. any non-zero allocation count on a PR is flagged 🔴; (b) per-callback wall-clock duration at p95 — tolerance is +20% relative to the baseline (p50 and p99 are advisory data only and do not drive the 🔴 marker); (c) Opus encode latency on a 960-sample / 20 ms frame — tolerance is +15% relative to the baseline on the mean; (d) Opus decode latency on a 960-sample / 20 ms frame — tolerance is +15% relative to the baseline on the mean; (e) resampler throughput on the canonical rate pairs — tolerance is −10% relative to the baseline on samples-per-second (i.e. a throughput drop greater than 10% is flagged 🔴). The comparator on a pull-request run shall be the baseline JSON committed at the pull request's merge-base commit, **not** the baseline at the current default-branch tip; this disambiguates the comparison when a PR is rebased onto a newer default and prevents a default-branch baseline update from retroactively re-classifying an in-flight PR's regression status.
- Status: Baseline Candidate
- Type: Verification Infrastructure Requirement
- Stage: P0 / MVP
- Allocated to: CI tooling co-located with the SRS-218 workflow (the comparison logic resides in the same SE-18 surface).
- Source SysDes: SysDes-158 (per-metric tolerance window and merge-base-snapshot comparison methodology allocated to SE-18).
- Verification method: Review — the comparison logic and the tolerance table are review-checkable against this clause; a small synthetic data set (one baseline, one PR run for each of the five metric families with values at, just inside, and just outside the tolerance window) demonstrates each marker assignment.
- Acceptance criteria: The CI tooling reads the baseline JSON at the PR's merge-base commit (verifiable by observing the SHA the tooling resolves before reading the file); the comparison applies the per-metric thresholds enumerated above (heap = zero, p95 wall-clock = +20%, Opus encode mean = +15%, Opus decode mean = +15%, resampler samples/sec = −10%); the marker assignment for a synthetic value at the threshold, just inside the threshold, and just outside the threshold matches the expected 🟢 / 🟡 (where defined by SDD) / 🔴 result; rebasing a PR onto a newer default branch re-resolves the merge-base and re-reads the baseline at the new merge-base, rather than reading the default-branch-tip baseline.
- Analysis: Feasible. The merge-base resolution is a standard `git merge-base` operation; per-metric thresholds are simple numeric comparisons. The merge-base-snapshot semantics is the SysDes-158 active rule and is preferred over default-branch-tip comparison because it makes the comparator stable across rebases. Verification intent (SWE.6): observe each of the five metric families' threshold behaviour on synthetic data and confirm the merge-base SHA is the comparator anchor.
- Unresolved assumptions: None at the SRS layer. The exact representation of the 🟡 "trending" intermediate state (for example a sub-threshold band, or a multi-run trend) is delegated to SDD per SysDes-157's notes, but does not alter the 🔴 threshold rules authored here.
### 20.1 SRS-216..219 to SysDes Coverage
| SysDes anchor | SRS coverage |
|---|---|
| SysDes-156 (realtime-audio benchmark surface, SE-13; five metric families; baseline JSON in deterministic repo location with metric/value/unit/host_arch/toolchain/git_sha/timestamp fields) | Primary anchor for `SRS-216` (benchmark instrumentation covering the five metric families) and `SRS-217` (baseline JSON storage format). |
| SysDes-157 (advisory CI integration, SE-18; trigger on PR + merge-to-default; host = `ubuntu-latest`; markdown table with 🟢/🟡/🔴 markers; never-fail status check; baseline-update isolation via `workflow_dispatch`) | Primary anchor for `SRS-218` (CI advisory-reporting workflow). |
| SysDes-158 (per-metric tolerance window and merge-base-snapshot comparison methodology, SE-18; heap = 0, p95 wall-clock = +20%, Opus encode/decode mean = +15%, resampler samples/sec = −10%) | Primary anchor for `SRS-219` (tolerance window and comparison methodology binding). |
### 20.2 Intentionally Out of Scope at This Revision
Consistent with the SysRS-307 / SysRS-308 / SysRS-309 deferrals propagated through SysDes-156 / SysDes-157 / SysDes-158, this revision intentionally does **not** author the following SRS clauses, and they shall not be inferred from SRS-216 through SRS-219:
- **Dimension 3 production telemetry export** — the runtime-export-of-metrics-from-shipped-clients dimension is deferred to P1 by SysRS, is not authorised by any SysDes-156/157/158 clause, and remains subject to SysRS-295's no-off-device-transmission rule. No SRS clause in this revision authorises such export.
- **Build-failing hard CI gate** — SysRS-308's advisory-only contract is the active rule, enforced at the SysDes layer by SysDes-157's non-blocking semantics. SRS-218 explicitly inherits that contract by requiring the status check to report `success` on every run. Escalation to a hard gate requires a future SysRS authorisation.
- **Multi-host benchmarking** — SysDes-157 point 2 fixes the host to Linux x86_64 (`ubuntu-latest`). ARM Android, macOS Apple Silicon, Windows x86_64, and any other host runner are explicitly deferred. SRS-218 inherits this constraint.
## Baseline Candidate 0.9.1 Update
| Version | Date | Description |
|---|---|---|
| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. |
## Baseline Candidate 0.9.2 Update
| Version | Date | Description |
|---|---|---|
| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date and preserved SRS direct-source rule through SysDes only. |
## Baseline Candidate 0.9.3 Update
| Version | Date | Description |
|---|---|---|
| 0.9.3 | 2026-05-15 | Added desktop PTT software requirements SRS-195 through SRS-203: `DesktopPttBackend` trait + per-platform implementations, `PttCapabilityLevel` enum, Windows Raw-Input ladder, macOS permission-aware backend, Linux GNOME-Wayland GlobalShortcuts portal backend, mouse-side-button support per DEC-027, `capture_active` / `transmit_active` split, sanitised diagnostics, missed-key-up watchdog per DEC-028. Sourcing remains strict (`SRS -> SysDes` only). |
## Baseline Candidate 0.9.5 Update
| Version | Date | Description |
|---|---|---|
| 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle software requirements SRS-204 through SRS-207 sourced from SysDes-149..151: bridge surface drops `start_audio` / `stop_audio` and adds `voice_join(channel_id)` / `voice_leave()`, audio engine opens streams on first voice-channel join and closes on last leave with output independent of mic-permission state, `TransmitMode` enum (`Ptt` default, `Continuous`, platform-scoped `VoiceActivity` per DEC-030) persisted per identity where supported, `release_tail_ms` (default 200, range 0–500) gate on the `true → false` transition of `transmit_active` with re-press cancellation, Voice Bar hard-mute override of `transmit_active`. Strict layered sourcing preserved (`SRS -> SysDes` only). |
## Baseline Candidate 0.9.6 Update
| Version | Date | Description |
|---|---|---|
| 0.9.9 | 2026-05-18 | Added realtime-audio benchmark-infrastructure software requirements SRS-216 through SRS-219 in a new section 20, sourced strictly from SysDes-156 / SysDes-157 / SysDes-158 (the Option B benchmark-infrastructure scope decision propagated through the Wave 1.5 benchmark chain). SRS-216 allocates benchmark instrumentation covering the five SysDes-156 metric families (heap allocation count per realtime callback after ~100-callback warmup, per-callback wall-clock at p50/p95/p99 as a fraction of cpal stream period, Opus encode latency on 960-sample/20 ms frame, Opus decode latency on the same shape, and resampler throughput at 44.1→48 / 16→48 / 48→48 kHz) to the `chanora_audio` crate's `benches/` directory; no new public seam in production code is authored. SRS-217 authors the baseline-JSON storage format (`metric`, `value`, `unit`, `host_arch`, `toolchain`, `git_sha`, `timestamp` fields at minimum) committed to a deterministic SDD-decided repo path. SRS-218 authors the CI advisory-reporting workflow under SysDes-157 (trigger on PR-against-default + merge-to-default, host = `ubuntu-latest`, markdown table with 🟢/🟡/🔴 markers, never-fail status check, baseline-update isolated to a separate `workflow_dispatch` workflow). SRS-219 binds the per-metric tolerance window of SysDes-158 (heap = 0, p95 wall-clock = +20%, Opus encode/decode mean = +15%, resampler samples/sec = −10%) and the merge-base-snapshot comparison methodology. Intentionally NOT authored consistent with the SysRS deferral chain: (a) Dimension 3 production telemetry export (deferred to P1; SysRS-295 still applies); (b) build-failing hard CI gate (SysRS-308 advisory-only rule active, SysDes-157 non-blocking semantics inherited); (c) multi-host benchmarking (SysDes-157 Linux x86_64 host-scope clause active). Strict layered sourcing preserved (`SRS -> SysDes` only per SRS-005); SysRS-307/308/309 are not cited as direct SRS sources. |
| 0.9.8 | 2026-05-18 | Retargeted the `Source SysDes` field on SRS-208, SRS-209, and SRS-210 through SRS-215 from the generic SysDes-135 (Android platform baseline) to the dedicated Android voice-audio derivation items authored by the system-architecture owner: SysDes-152 (Android in-call audio mode subsystem) is now the primary anchor for SRS-208; SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow as Permission/Voice subsystem partitioning) is now the primary anchor for SRS-209; SysDes-154 (Android voice audio backend subsystem — AAudio low-latency path, voice-communication usage/preset, hardware-effects engagement with software fallback, sharing-mode policy, FGS-hosted background mic lifecycle) is now the primary anchor for SRS-210 (latency), SRS-211 (input preset), SRS-212 (hardware AEC/NS/AGC), SRS-213 (output usage/content-type), SRS-214 (sharing mode), and SRS-215 (microphone-typed foreground service). SRS-213 additionally retains SysDes-152 as a secondary anchor because the output-stream usage is the precondition for in-call-mode routing. SysDes-135 is retained on all eight items as the secondary/context anchor (platform-baseline relationship). Section 19 coverage table updated. Strict layered sourcing preserved (`SRS -> SysDes` only). No technical or behavioural content of SRS-208 through SRS-215 was modified; this is a surgical retargeting of the `Source SysDes` field only. |
| 0.9.7 | 2026-05-18 | Added Android Audio Backend (P0) section 18 hosting SRS-210 through SRS-215 to support the platform-adapter decision to host Android voice capture/playback on a dedicated low-latency native audio backend (mirroring the iOS voice-processing-audio-unit precedent). SRS-210 sets numeric mouth-to-ear latency targets (≤150 ms on devices that return `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY`, ≤250 ms otherwise). SRS-211 mandates `AAUDIO_INPUT_PRESET_VOICE_COMMUNICATION` with `VOICE_PERFORMANCE` fallback. SRS-212 mandates engagement of hardware `AcousticEchoCanceler` / `NoiseSuppressor` / `AutomaticGainControl` on the capture session id with software-AEC fallback (closes the prior silent no-op). SRS-213 mandates `AAUDIO_USAGE_VOICE_COMMUNICATION` + `AAUDIO_CONTENT_TYPE_SPEECH` on output. SRS-214 mandates best-effort `AAUDIO_SHARING_MODE_EXCLUSIVE` with `SHARED` fallback. SRS-215 mandates microphone-typed foreground-service hosting (`foregroundServiceType="microphone"`) for backgrounded voice transmission. Added section 19 coverage statement. Strict SRS→SysDes sourcing preserved: `Source SysDes` traces via SysDes-135 (Android platform baseline) pending a SysDes revision that introduces a dedicated derivation item for the Android voice audio backend; SysRS-055, SysRS-217, SysRS-288, SysRS-305 are cited as the upstream SysRS obligations addressed. |
| 0.9.6 | 2026-05-17 | Propagated SysRS reconciliation (Wave 1.5) into SRS for P0 Android. SRS-187 minimum Android API raised from 24 to 28 per DEC-004 (ID preserved, change record added). SRS-188 verified consistent with SysRS-289 (Google Play upload-date target SDK); no rewrite required. SRS-111 (Android foreground service for active voice session), SRS-119 (Android AAB release build), and SRS-163 (Android back-navigation intent) reviewed and left unchanged — text remains unambiguous and P0/P1 scope is intact. Added SRS-208 (Android in-call audio mode engaged on voice-session connect, released on last disconnect — addresses SysRS-305) and SRS-209 (explicit `RECORD_AUDIO` runtime permission acquisition at or before voice-session activation, fail-safe to listen-only on denial — addresses SysRS-306). Strict layered sourcing preserved (`SRS -> SysDes` only); `Source SysDes` for SRS-208/209 traces via SysDes-135 pending a SysDes revision that introduces dedicated derivation items for SysRS-305/306. |
Reference in New Issue View Git Blame Copy Permalink