Files

T

Edison Jwa fe6e07353e chore: restore product scaffold to rollback baseline

2026-05-29 14:02:04 +09:00

191 KiB

Raw Permalink Blame History

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:

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.

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

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 (the last reserved with no v1 implementation per DEC-030). The setting shall be persisted per identity via the identity store. The default value for a fresh install shall be Ptt. The UI shall render VoiceActivity as a disabled "coming soon" option until an implementation is allocated in a later baseline.

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`, reserved `VoiceActivity` per DEC-030) persisted per identity, `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.

191 KiB Raw Permalink Blame History Unescape Escape