# 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.2
**Status:** Baseline Candidate
**Source baseline:** `chanora_SysDes_ASPICE_SYS3_v0.5.md`
**Architecture baseline:** Flutter + Rust Core + `tsclientlib` protocol adapter
**Target client platforms:** Windows, macOS, Linux, iOS, Android

**Repo path:** `docs/requirements/srs.md`  ---

## 1. Purpose

This SRS defines the software requirements for the Chanora client application. It is derived from the approved SysDes baseline and is written in the style of ASPICE SWE.1 Software Requirements Analysis.

The SRS covers all SysDes design items that require implementation or enablement by the software team, including software-facing constraints from hardware, operating system services, networks, external compatible servers, deployment, diagnostics, and verification.

Chanora remains an application, not an operating system. The software requirements specify what the Chanora software shall do and what operating-environment assumptions or interfaces it shall handle.

## 2. ASPICE SWE.1 Alignment

This document addresses the following SWE.1 concerns:

- Specify software requirements from system requirements and system architecture.
- Structure and prioritize software requirements.
- Analyze software requirements for correctness, technical feasibility, and operating-environment impact.
- Establish consistency and traceability to system architecture; system-requirement coverage is inherited through the SysDes allocation chain.
- Communicate the agreed software requirements and impact analysis to affected parties.

## 3. Software Scope

### 3.1 In Scope for Software Team

The software team owns or implements the following software elements:

- Chanora application container
- Flutter UI layer
- Flutter state layer
- Flutter-Rust bridge layer
- Rust Core and connection manager
- Protocol adapter using `tsclientlib`
- State synchronization engine
- Audio subsystem
- Platform adapter software layer
- Local data store integration
- Secure storage integration layer
- Diagnostics and observability subsystem
- Software-facing deployment scripts and release metadata
- Software verification hooks and test-support tooling

### 3.2 Out of Scope for Software Implementation

- Implementing or operating external TeamSpeak 3-compatible servers
- Controlling user-managed network infrastructure, routers, VPNs, NAT devices, or ISPs
- Manufacturing or controlling physical audio hardware
- Changing operating system vendor policies for permissions, secure storage, background execution, or app-store review
- Providing a Chanora-operated backend for MVP voice, channels, or text

Software shall still handle these items as external interfaces, constraints, assumptions, degraded states, or error conditions where applicable.

## 4. Requirement Attribute Model

Each SRS requirement uses the following attributes.

| Attribute | Meaning |
|---|---|
| SRS ID | Unique software requirement identifier, formatted as `SRS-XXX` |
| Type | Functional, non-functional, interface, platform, security, diagnostics, packaging, analysis, or process classification |
| Stage | Delivery stage: `P0 / MVP`, `P1 / Beta`, `P2 / Production`, or `P3 / Future` |
| Allocated to | Software component or software engineering responsibility |
| Source SysDes | System design item(s) from which the software requirement is directly derived |
| Verification method | Review, inspection, unit test, integration test, system test, platform test, security audit, performance test, demo, or release audit |
| Acceptance criteria | Objective condition for acceptance |
| Analysis | Technical feasibility and impact note |


## 4.1 Traceability Policy

This SRS uses `Source SysDes` as the only direct upstream source field for individual `SRS-XXX` requirements.

The approved lifecycle chain is:

```text
System requirements baseline -> SysDes -> SRS
```

Therefore:

- System-level requirements are allocated and justified in SysDes.
- SRS requirements are derived from SysDes design items.
- Individual SRS requirements shall cite `Source SysDes` only.
- Individual SRS requirements shall not directly cite upstream system requirement IDs.
- A missing software need shall be fixed by correcting SysDes first, then deriving or updating SRS.

## 5. Software Requirements

### 5.1 SWE.1 Process, Traceability, and Baseline Requirements

**SRS-001**: The software requirements specification shall define software requirements derived from the approved Chanora SysDes baseline.

- Type: Process / SWE.1
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-001 through SysDes-003
- Verification method: Review
- Acceptance criteria: SRS contains requirement statements, attributes, and source links to SysDes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-002**: Each software requirement shall have a unique `SRS-XXX` identifier, type, stage, software allocation, source SysDes link, verification method, acceptance criteria, and feasibility analysis.

- Type: Process / Requirement Attribute
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-004 through SysDes-009, SysDes-092 through SysDes-097
- Verification method: Inspection
- Acceptance criteria: Every SRS item contains the mandatory attribute fields.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-003**: The software requirements shall be structured by software component and cross-cutting concern to support allocation to the software team.

- Type: Process / Structuring
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039
- Verification method: Review
- Acceptance criteria: Document sections map to UI, state, bridge, Rust Core, protocol, audio, storage, diagnostics, platform adapters, packaging, and verification hooks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-004**: The software requirements shall be prioritized using P0 / MVP, P1 / Beta, P2 / Production, and P3 / Future stage labels.

- Type: Process / Prioritization
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110
- Verification method: Inspection
- Acceptance criteria: Each SRS item contains a stage value.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-005**: The software requirements shall maintain bidirectional traceability to SysDes design items only; upstream system-requirement coverage shall be inherited through the approved SysDes allocation baseline.

- Type: Process / Traceability
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110
- Verification method: Inspection
- Acceptance criteria: Coverage matrix shows SysDes-to-SRS and SRS-to-SysDes mappings, without direct links from SRS requirements to upstream system requirement IDs.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-006**: The software requirements shall analyze impact on the operating environment for OS services, audio hardware, network connectivity, external compatible servers, secure storage, deployment, and mobile lifecycle constraints.

- Type: Process / Operating Environment Analysis
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101
- Verification method: Review
- Acceptance criteria: Operating environment section identifies software impacts and external dependencies.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-007**: The agreed SRS baseline shall be communicated to SAD, SDD, implementation, and verification authors.

- Type: Process / Communication
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-003, SysDes-098 through SysDes-100
- Verification method: Review
- Acceptance criteria: Revision history and communication section identify affected parties and downstream use.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.2 Software Boundary and Architecture Requirements

**SRS-008**: The software shall be implemented as a cross-platform client application and shall not be implemented or described as an operating system.

- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Application Container
- Source SysDes: SysDes-002, SysDes-024
- Verification method: Review
- Acceptance criteria: App metadata, documentation, and architecture describe Chanora as an application.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-009**: The software shall operate without requiring Chanora-operated backend infrastructure for MVP voice, channel, and text operation.

- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Application Container, Rust Core
- Source SysDes: SysDes-016, SysDes-083
- Verification method: Review, System Test
- Acceptance criteria: MVP operation connects directly to user-provided compatible servers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-010**: The software shall not implement TeamSpeak-compatible server hosting functionality in MVP.

- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Application Container, Protocol Adapter
- Source SysDes: SysDes-023, SysDes-082, SysDes-083
- Verification method: Inspection
- Acceptance criteria: No server-hosting module or process exists in the MVP software.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-011**: The software shall use a layered structure that separates Flutter UI, Flutter State, Bridge, Rust Core, Protocol Adapter, State Sync, Audio, Storage, Diagnostics, and Platform Adapters.

- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: All Software Components
- Source SysDes: SysDes-010, SysDes-038, SysDes-039, SysDes-041
- Verification method: Inspection
- Acceptance criteria: Repository and dependency graph show separate modules/crates/layers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-012**: The software shall keep real-time audio processing outside Flutter UI.

- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Audio Subsystem
- Source SysDes: SysDes-014, SysDes-040, SysDes-071, SysDes-072
- Verification method: Inspection, Performance Test
- Acceptance criteria: Flutter UI does not process PCM frames or execute real-time DSP.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-013**: The software shall support Windows, macOS, Linux, iOS, and Android through shared Flutter UI, shared Rust Core, and platform-specific adapters.

- Type: Platform Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Platform Adapters
- Source SysDes: SysDes-012, SysDes-032, SysDes-041
- Verification method: Build Test
- Acceptance criteria: Target platform builds compile with shared core and platform adapter boundaries.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-014**: The software shall isolate OS-specific permissions, audio routing, lifecycle, secure storage, notification, and packaging behavior behind platform adapter interfaces.

- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Platform Adapters
- Source SysDes: SysDes-032, SysDes-050, SysDes-080
- Verification method: Inspection, Integration Test
- Acceptance criteria: Platform-specific code is not embedded directly in core protocol or state modules.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-015**: The software shall provide verification hooks for protocol, state, audio, security, packaging, and platform behavior.

- Type: Verification Hook
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters
- Source SysDes: SysDes-017, SysDes-102 through SysDes-107
- Verification method: Inspection, Demo
- Acceptance criteria: Tools, logs, and tests expose evidence for each verification area.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.3 Application Container and Flutter UI Requirements

**SRS-016**: The software shall provide an application container that initializes Flutter UI, Bridge, Rust Core, platform adapters, storage, and diagnostics in a deterministic startup sequence.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Application Container
- Source SysDes: SysDes-024, SysDes-038, SysDes-041
- Verification method: Integration Test
- Acceptance criteria: Application startup reaches idle/home state without race-condition crashes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-017**: The software shall provide a home or entry screen for manual connection, recent servers, and saved bookmarks.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI
- Source SysDes: SysDes-025, SysDes-055, SysDes-059
- Verification method: UI Test
- Acceptance criteria: User can open connection and bookmark flows from the entry screen.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-018**: The software shall provide a manual connection UI that accepts host or IP address, port, nickname, and optional server password.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI
- Source SysDes: SysDes-025, SysDes-055, SysDes-059, SysDes-065
- Verification method: UI Test
- Acceptance criteria: Connection request can be submitted with all required fields and validated before dispatch.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-019**: The software shall display connection states including Disconnected, Connecting, Synchronizing, Connected, Reconnecting, and Failed or equivalent user-safe states.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066
- Verification method: UI Test, System Test
- Acceptance criteria: UI state follows Rust Core connection events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-020**: The software shall display a server channel tree derived from the Rust Core snapshot and delta events.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068
- Verification method: UI Test, System Test
- Acceptance criteria: Channel tree updates after initial sync and live channel events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-021**: The software shall display online clients in their channels and update the display after client join, leave, and move events.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068
- Verification method: UI Test, System Test
- Acceptance criteria: Client list reflects snapshot and live delta changes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-022**: The software shall visually identify the current user and current channel when the data is available from Rust Core.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-067
- Verification method: UI Test
- Acceptance criteria: Current user and current channel receive distinct UI state markers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-023**: The software shall provide a channel join interaction that sends a join command through the Bridge and waits for Rust Core or protocol confirmation before treating the join as authoritative.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Bridge, Rust Core
- Source SysDes: SysDes-055, SysDes-069
- Verification method: System Test
- Acceptance criteria: UI does not finalize current-channel state until confirmation or failure event is received.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-024**: The software shall provide channel text chat UI for message display and message input.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Bridge, Rust Core
- Source SysDes: SysDes-025, SysDes-055, SysDes-070
- Verification method: UI Test, System Test
- Acceptance criteria: User can send text and receive displayed messages through core events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-025**: The software shall provide a persistent voice control surface for microphone mute, output deaf, push-to-talk state, input level, and current channel.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Audio Subsystem
- Source SysDes: SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072
- Verification method: UI Test, System Test
- Acceptance criteria: Voice controls are visible and correctly update Rust Core/audio state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-026**: The software shall provide an audio settings UI for input device, output device, Echo Canceller, Automatic Gain Control, Noise Suppression, High-Pass Filter, and related defaults.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter UI, Audio Subsystem, Storage
- Source SysDes: SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086
- Verification method: UI Test
- Acceptance criteria: Settings can be changed and persist across application restart where supported.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-027**: The software shall provide permission explanation UI before requesting microphone, notification, or mobile foreground-service related permissions where platform guidelines allow.

- Type: Functional / Privacy
- Stage: P0 / MVP
- Allocated to: Flutter UI, Platform Adapters
- Source SysDes: SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090
- Verification method: UI Test, Privacy Review
- Acceptance criteria: Permission explainers appear before or with OS permission prompts as appropriate.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-028**: The software shall provide a diagnostics UI that allows user-initiated diagnostic export and displays user-safe diagnostic status.

- Type: Functional / Diagnostics
- Stage: P1 / Beta
- Allocated to: Flutter UI, Diagnostics
- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105
- Verification method: UI Test, Security Audit
- Acceptance criteria: User can export diagnostics only by explicit action, and export is redacted.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-029**: The Flutter UI shall not directly invoke `tsclientlib`, access raw protocol types, or own authoritative server state.

- Type: Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Flutter State
- Source SysDes: SysDes-040, SysDes-052 through SysDes-054, SysDes-057
- Verification method: Inspection
- Acceptance criteria: Static dependency analysis shows no UI dependency on protocol library types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-030**: The Flutter UI shall subscribe to UI-safe core events and reduce them into presentation state only.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Flutter State
- Source SysDes: SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068
- Verification method: Inspection, UI Test
- Acceptance criteria: State providers/stores are driven by event DTOs and do not mutate Rust-owned server state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-031**: The software shall provide a typed Flutter-Rust Bridge API for connection, channel, chat, voice, settings, storage, and diagnostics commands.

- Type: Interface
- Stage: P0 / MVP
- Allocated to: Bridge Layer
- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056
- Verification method: Integration Test
- Acceptance criteria: Flutter can call each command group through generated or native bindings.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.4 Bridge Requirements

**SRS-032**: The Bridge shall expose long-lived event streams from Rust Core to Flutter for connection, snapshot, delta, chat, voice, audio device, error, and diagnostic events.

- Type: Interface
- Stage: P0 / MVP
- Allocated to: Bridge Layer, Rust Core
- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068
- Verification method: Integration Test
- Acceptance criteria: Flutter receives ordered events and handles stream lifecycle without UI blocking.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-033**: The Bridge shall serialize and deserialize only bridge-safe DTOs and shall not expose Rust internal references or raw protocol library objects.

- Type: Interface / Safety
- Stage: P0 / MVP
- Allocated to: Bridge Layer
- Source SysDes: SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057
- Verification method: Inspection, Integration Test
- Acceptance criteria: Generated bindings contain DTOs and value objects only.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-034**: The Bridge shall map Rust Core errors into user-safe Flutter error DTOs.

- Type: Interface / Error Handling
- Stage: P0 / MVP
- Allocated to: Bridge Layer, Rust Core
- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089
- Verification method: Integration Test
- Acceptance criteria: Known error cases produce category, message, and recovery hint fields.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-035**: The Bridge shall execute commands asynchronously and shall not block the Flutter UI thread during network, storage, or audio operations.

- Type: Non-functional
- Stage: P0 / MVP
- Allocated to: Bridge Layer, Rust Core
- Source SysDes: SysDes-027, SysDes-042, SysDes-046, SysDes-085
- Verification method: Performance Test
- Acceptance criteria: UI remains responsive during connect, reconnect, sync, and diagnostic export.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-036**: The Rust Core shall own authoritative connection lifecycle and server state for each active connection.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Connection state transitions and snapshots are managed in Rust Core.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.5 Rust Core and Connection Management Requirements

**SRS-037**: The Rust Core shall manage connection actors or equivalent isolated execution contexts for connection-specific commands and events.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066
- Verification method: Inspection, Unit Test
- Acceptance criteria: Each connection has an isolated command/event path.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-038**: The Rust Core shall expose connect, disconnect, reconnect, join channel, send message, audio control, settings, bookmark, identity, and diagnostics commands to the Bridge.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core, Bridge
- Source SysDes: SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076
- Verification method: Integration Test
- Acceptance criteria: Bridge command suite calls corresponding Rust Core operations.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-039**: The Rust Core shall coordinate protocol, state synchronization, audio, storage, diagnostics, and platform adapter interfaces without leaking implementation details to Flutter.

- Type: Functional / Architecture
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077
- Verification method: Inspection
- Acceptance criteria: Core public API exposes stable DTOs and not internal crate types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-040**: The Rust Core shall emit connection status events for Connecting, Synchronizing, Connected, Reconnecting, Disconnected, and failure states.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core, State Sync
- Source SysDes: SysDes-060, SysDes-064, SysDes-066, SysDes-074
- Verification method: Unit Test, System Test
- Acceptance criteria: Status event sequence matches connection state machine under normal and failure flows.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-041**: The Rust Core shall suppress automatic reconnect after user-triggered disconnect.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Rust Core
- Source SysDes: SysDes-064, SysDes-073, SysDes-074, SysDes-088
- Verification method: System Test
- Acceptance criteria: User disconnect results in Disconnected state and no reconnect attempt.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-042**: The Rust Core shall apply reconnect policy after recoverable network or protocol failures.

- Type: Functional / Reliability
- Stage: P0 / MVP
- Allocated to: Rust Core, Protocol Adapter, State Sync
- Source SysDes: SysDes-064, SysDes-066, SysDes-074, SysDes-088
- Verification method: System Test
- Acceptance criteria: Recoverable failure enters Reconnecting and either recovers or reports safe failure.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-043**: The Rust Core shall rebuild server state from a fresh snapshot after reconnect succeeds.

- Type: Functional / Reliability
- Stage: P0 / MVP
- Allocated to: Rust Core, State Sync
- Source SysDes: SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088
- Verification method: System Test, Event Replay Test
- Acceptance criteria: Post-reconnect state is produced from new snapshot, not patched from stale state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-044**: The Protocol Adapter shall be the only software component that directly depends on `tsclientlib`.

- Type: Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Protocol Adapter
- Source SysDes: SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078
- Verification method: Inspection
- Acceptance criteria: Dependency graph shows `tsclientlib` dependency only in protocol adapter crate/module.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.6 Protocol Adapter Requirements

**SRS-045**: The Protocol Adapter shall connect to TeamSpeak 3-compatible servers through `tsclientlib` using user-provided host, port, nickname, identity, and optional password.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Rust Core
- Source SysDes: SysDes-029, SysDes-043, SysDes-065, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Protocol probe and app can establish a session to a compatible test server.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-046**: The Protocol Adapter shall fetch server information, channel list, client list, and current-user information needed to build the initial snapshot.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, State Sync
- Source SysDes: SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Initial snapshot has server, channel, client, and self-client data.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-047**: The Protocol Adapter shall translate raw `tsclientlib` events into internal protocol events.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, State Sync
- Source SysDes: SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Known client, channel, message, voice, and disconnect events map to internal events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-048**: The Protocol Adapter shall translate protocol errors into normalized Chanora protocol errors.

- Type: Functional / Error Handling
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Rust Core
- Source SysDes: SysDes-029, SysDes-043, SysDes-045, SysDes-088
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Known network, authentication, permission, and protocol failures produce normalized errors.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-049**: The Protocol Adapter shall implement channel join commands and report success or failure to Rust Core.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter
- Source SysDes: SysDes-029, SysDes-043, SysDes-069, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Accessible channel join succeeds; denied join reports user-safe failure.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-050**: The Protocol Adapter shall implement channel text message send and receive paths.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter
- Source SysDes: SysDes-029, SysDes-043, SysDes-070, SysDes-102
- Verification method: Protocol Integration Test
- Acceptance criteria: Text sent from UI reaches server and incoming text reaches core events.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-051**: The Protocol Adapter shall implement voice packet send and receive paths required by the audio subsystem.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Audio Subsystem
- Source SysDes: SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104
- Verification method: Protocol Integration Test, Audio Test
- Acceptance criteria: Encoded outgoing frames are sent and incoming voice packets are delivered to audio pipeline.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-052**: The Protocol Adapter shall expose protocol-probe diagnostics for connection, snapshot, event, text, and voice compatibility.

- Type: Verification Hook
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Diagnostics
- Source SysDes: SysDes-017, SysDes-035, SysDes-102
- Verification method: Demo
- Acceptance criteria: Protocol probe produces compatibility output for test servers.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-053**: The Protocol Adapter shall support future patching, forking, or replacement of protocol implementation without changing Flutter UI contracts.

- Type: Maintainability
- Stage: P1 / Beta
- Allocated to: Protocol Adapter, Bridge
- Source SysDes: SysDes-011, SysDes-029, SysDes-043, SysDes-078
- Verification method: Architecture Review
- Acceptance criteria: Protocol adapter trait/API boundary isolates library-specific types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-054**: The State Synchronization Engine shall maintain a connection state model containing connection status, server info, current user, channels, clients, channel tree, permissions, chat state, and voice state where available.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068
- Verification method: Unit Test
- Acceptance criteria: State object can represent required snapshot and runtime states.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.7 State Synchronization Requirements

**SRS-055**: The State Synchronization Engine shall produce a full snapshot event after initial synchronization.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-067
- Verification method: Unit Test, Integration Test
- Acceptance criteria: SnapshotReady event is emitted after server, channel, and client data are available.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-056**: The State Synchronization Engine shall apply live server events as deterministic deltas.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-068
- Verification method: Unit Test
- Acceptance criteria: Same event sequence produces same final state and emitted deltas.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-057**: The State Synchronization Engine shall preserve per-connection event ordering.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync, Rust Core
- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-068
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Out-of-order processing is prevented or deterministically handled per connection.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-058**: The State Synchronization Engine shall use reducer functions or equivalent deterministic logic for snapshot, channel, client, chat, voice, and connection events.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103
- Verification method: Unit Test
- Acceptance criteria: Reducer tests cover snapshot and major delta event types.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-059**: The State Synchronization Engine shall replace stale server state with a fresh snapshot after reconnect.

- Type: Functional / Reliability
- Stage: P0 / MVP
- Allocated to: State Sync
- Source SysDes: SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103
- Verification method: Event Replay Test, System Test
- Acceptance criteria: Reconnect tests confirm old channel/client state is replaced.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-060**: The State Synchronization Engine shall tolerate malformed or unexpected protocol events without crashing the application.

- Type: Reliability
- Stage: P0 / MVP
- Allocated to: State Sync, Rust Core
- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103
- Verification method: Unit Test, Fuzz/Negative Test
- Acceptance criteria: Malformed event tests produce safe error or ignored event behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-061**: The State Synchronization Engine shall provide replayable event recording hooks for debugging state synchronization.

- Type: Verification Hook
- Stage: P1 / Beta
- Allocated to: State Sync, Diagnostics
- Source SysDes: SysDes-030, SysDes-035, SysDes-079, SysDes-103
- Verification method: Demo
- Acceptance criteria: Recorded event stream can be replayed to reproduce state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-062**: The Audio Subsystem shall coordinate audio capture, preprocessing, audio processing, Opus-compatible encoding, voice packet handoff, receive decoding, jitter buffering, per-user controls, mixing, and playback.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104
- Verification method: Audio Integration Test
- Acceptance criteria: End-to-end voice send and receive operate through the audio subsystem.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.8 Audio Subsystem Requirements

**SRS-063**: The Audio Subsystem shall process outgoing microphone PCM frames before encoding.

- Type: Functional
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Capture pipeline accepts PCM frames and outputs encoded voice frames when gate allows.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-064**: The Audio Subsystem shall apply a High-Pass Filter before voice encoding when enabled.

- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: Low-frequency attenuation is measurable in HPF test cases.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-065**: The Audio Subsystem shall apply Noise Suppression before voice encoding when enabled.

- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: Stationary-noise reduction is measurable or verified by backend tests.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-066**: The Audio Subsystem shall apply Echo Canceller before voice encoding when enabled and when playback reference audio is available or the selected backend provides equivalent behavior.

- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: Echo cancellation backend can use playback reference or platform equivalent.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-067**: The Audio Subsystem shall apply Automatic Gain Control before voice encoding when enabled.

- Type: Functional / Audio Processing
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104
- Verification method: Audio Processing Test
- Acceptance criteria: AGC normalizes input gain without unacceptable clipping under test cases.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-068**: The Audio Subsystem shall expose enable/disable settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter.

- Type: Functional / Settings
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI, Storage
- Source SysDes: SysDes-031, SysDes-033, SysDes-056, SysDes-081
- Verification method: UI Test, Unit Test
- Acceptance criteria: Changing each setting updates Rust Core/audio configuration and persists locally.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-069**: The Audio Subsystem shall support conservative default audio processing configuration per platform.

- Type: Non-functional / Audio
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-013, SysDes-031, SysDes-081, SysDes-086
- Verification method: Review, Audio Test
- Acceptance criteria: Default configuration is documented and validated for each supported platform.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-070**: The Audio Subsystem shall provide an audio processing backend abstraction supporting platform-native and Rust-based implementations.

- Type: Architecture / Audio
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-031, SysDes-032, SysDes-058, SysDes-081
- Verification method: Inspection
- Acceptance criteria: Backend trait/interface allows substitution without Flutter UI changes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-071**: The Audio Subsystem shall encode outgoing voice using an Opus-compatible encoder.

- Type: Functional / Audio Codec
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: PCM input produces decodable Opus-compatible encoded frames.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-072**: The Audio Subsystem shall decode incoming voice using an Opus-compatible decoder.

- Type: Functional / Audio Codec
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Incoming encoded frames produce expected PCM output.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-073**: The Audio Subsystem shall use jitter buffering for incoming voice packets.

- Type: Functional / Audio Playback
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Packet jitter test produces continuous playback without buffer instability within defined limits.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-074**: The Audio Subsystem shall support per-user mute during playback.

- Type: Functional / Audio Playback
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI
- Source SysDes: SysDes-031, SysDes-058, SysDes-072
- Verification method: Audio Test, UI Test
- Acceptance criteria: Muted remote user is not mixed into output.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-075**: The Audio Subsystem shall support per-user volume during playback.

- Type: Functional / Audio Playback
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Flutter UI, Storage
- Source SysDes: SysDes-031, SysDes-033, SysDes-058, SysDes-072
- Verification method: Audio Test, UI Test
- Acceptance criteria: Remote user gain changes affect only that user and persist where applicable.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-076**: The Audio Subsystem shall mix decoded incoming voice streams before playback.

- Type: Functional / Audio Playback
- Stage: P0 / MVP
- Allocated to: Audio Subsystem
- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104
- Verification method: Audio Test
- Acceptance criteria: Multiple incoming streams are mixed into a playback stream without clipping beyond defined limits.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-077**: The Audio Subsystem shall implement microphone mute as a gate that prevents local voice transmission.

- Type: Functional / Voice Control
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Rust Core, Flutter UI
- Source SysDes: SysDes-031, SysDes-063, SysDes-071
- Verification method: System Test
- Acceptance criteria: When muted, no outgoing voice packets are sent.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-078**: The Audio Subsystem shall implement output deaf as a gate that prevents incoming voice playback.

- Type: Functional / Voice Control
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Rust Core, Flutter UI
- Source SysDes: SysDes-031, SysDes-063, SysDes-072
- Verification method: System Test
- Acceptance criteria: When deafened, incoming voice is not played.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-079**: The Audio Subsystem shall implement push-to-talk gating before outgoing voice packet transmission.

- Type: Functional / Voice Control
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI
- Source SysDes: SysDes-031, SysDes-063, SysDes-071
- Verification method: System Test
- Acceptance criteria: Outgoing voice is sent only when push-to-talk is active unless configured otherwise.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-080**: The Audio Subsystem shall provide input level metering to Rust Core or Flutter through UI-safe events.

- Type: Functional / Voice Metering
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Flutter UI
- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-071
- Verification method: Audio Test, UI Test
- Acceptance criteria: Input level meter changes with microphone input.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-081**: The Audio Subsystem shall provide speaking indicator events for local and remote users where available.

- Type: Functional / Voice Metering
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, State Sync, Flutter UI
- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-072
- Verification method: Audio Test, UI Test
- Acceptance criteria: Speaking indicators activate according to local gate and remote voice activity.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-082**: The Audio Subsystem shall recover from audio route or device changes by reconfiguring audio streams or entering a user-safe blocked/degraded state.

- Type: Reliability / Audio
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-032, SysDes-050, SysDes-075, SysDes-086
- Verification method: Platform Integration Test
- Acceptance criteria: Device disconnect/change does not crash the app and reports clear status.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-083**: The Audio Subsystem shall provide audio loopback and processing test hooks for verification.

- Type: Verification Hook
- Stage: P1 / Beta
- Allocated to: Audio Subsystem, Diagnostics
- Source SysDes: SysDes-017, SysDes-035, SysDes-104
- Verification method: Demo
- Acceptance criteria: Audio test tools can exercise capture, processing, encode/decode, jitter, mixer, and playback paths.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-084**: The software shall persist bookmarks in local non-secret storage.

- Type: Functional / Storage
- Stage: P0 / MVP
- Allocated to: Storage
- Source SysDes: SysDes-033, SysDes-036, SysDes-049
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Bookmark create, update, delete, and list operations persist across restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.9 Storage and Secure Storage Requirements

**SRS-085**: The software shall persist recent servers in local non-secret storage.

- Type: Functional / Storage
- Stage: P1 / Beta
- Allocated to: Storage
- Source SysDes: SysDes-033, SysDes-036, SysDes-049
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Recent server entries are stored and displayed after restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-086**: The software shall persist audio settings in local non-secret storage.

- Type: Functional / Storage
- Stage: P0 / MVP
- Allocated to: Storage, Audio Subsystem
- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081
- Verification method: Unit Test, Integration Test
- Acceptance criteria: Audio settings survive application restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-087**: The software shall persist UI settings in local non-secret storage.

- Type: Functional / Storage
- Stage: P1 / Beta
- Allocated to: Storage, Flutter UI
- Source SysDes: SysDes-033, SysDes-036, SysDes-049
- Verification method: Unit Test, Integration Test
- Acceptance criteria: UI settings survive application restart.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-088**: The software shall persist per-user volume and per-user mute preferences where applicable.

- Type: Functional / Storage
- Stage: P1 / Beta
- Allocated to: Storage, Audio Subsystem
- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-072
- Verification method: Unit Test
- Acceptance criteria: Preferences are stored by server/user identity keys where available.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-089**: The software shall use SQLite or an equivalent embedded data store for non-secret local data.

- Type: Architecture / Storage
- Stage: P0 / MVP
- Allocated to: Storage
- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-091
- Verification method: Inspection
- Acceptance criteria: Storage implementation uses an embedded local data store and migration mechanism.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-090**: The software shall access platform secure storage only through a secure storage provider abstraction.

- Type: Interface / Security
- Stage: P0 / MVP
- Allocated to: Storage, Platform Adapters
- Source SysDes: SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105
- Verification method: Inspection, Security Audit
- Acceptance criteria: Secrets are read/written through secure storage interface only.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-091**: The software shall store identity private keys using platform secure storage and shall not persist them in plaintext files.

- Type: Security
- Stage: P0 / MVP
- Allocated to: Storage, Platform Secure Storage
- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Filesystem and database inspection shows no plaintext private keys.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-092**: The software shall store server passwords using platform secure storage and shall not persist them in plaintext logs or non-secret database fields.

- Type: Security
- Stage: P0 / MVP
- Allocated to: Storage, Platform Secure Storage, Diagnostics
- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Password values are redacted from logs and absent from non-secret storage.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-093**: The software shall redact secrets before writing diagnostic logs or diagnostic exports.

- Type: Security / Diagnostics
- Stage: P0 / MVP
- Allocated to: Diagnostics, Storage
- Source SysDes: SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Diagnostic redaction tests cover private keys, passwords, tokens, and known secret fields.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-094**: The software shall validate user input before passing values to protocol operations or storage operations.

- Type: Security
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage
- Source SysDes: SysDes-045, SysDes-065, SysDes-089, SysDes-105
- Verification method: Unit Test, Security Test
- Acceptance criteria: Invalid host, port, nickname, password, and path-like values are rejected or sanitized safely.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-095**: The software shall produce structured diagnostic logs for connection, protocol, state, audio, storage, platform, and release-relevant events.

- Type: Diagnostics
- Stage: P0 / MVP
- Allocated to: Diagnostics
- Source SysDes: SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105
- Verification method: Inspection, Demo
- Acceptance criteria: Logs contain structured fields and categories without secrets.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.10 Diagnostics, Security, and Privacy Requirements

**SRS-096**: The software shall support user-initiated diagnostic export.

- Type: Diagnostics
- Stage: P1 / Beta
- Allocated to: Diagnostics, Flutter UI
- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105
- Verification method: Demo, Security Audit
- Acceptance criteria: Export is available only after user action and output is redacted.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-097**: The software shall provide protocol event recording in development or diagnostics mode.

- Type: Diagnostics / Verification Hook
- Stage: P1 / Beta
- Allocated to: Diagnostics, Protocol Adapter, State Sync
- Source SysDes: SysDes-035, SysDes-079, SysDes-102, SysDes-103
- Verification method: Demo
- Acceptance criteria: Recorded protocol/core event file can be generated in diagnostics mode.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-098**: The software shall provide event replay support for state synchronization debugging.

- Type: Diagnostics / Verification Hook
- Stage: P1 / Beta
- Allocated to: Diagnostics, State Sync
- Source SysDes: SysDes-035, SysDes-079, SysDes-103
- Verification method: Demo
- Acceptance criteria: Event replay can rebuild expected state from a recorded sequence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-099**: The software shall provide audio diagnostics for capture, processing backend, codec, jitter buffer, mixer, playback, and route/device status.

- Type: Diagnostics / Verification Hook
- Stage: P1 / Beta
- Allocated to: Diagnostics, Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-035, SysDes-075, SysDes-086, SysDes-104
- Verification method: Demo
- Acceptance criteria: Audio diagnostics report current pipeline and device status.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-100**: The software shall provide network diagnostics for connection status, reconnect attempts, latency where available, and protocol-relevant network failures.

- Type: Diagnostics / Reliability
- Stage: P1 / Beta
- Allocated to: Diagnostics, Rust Core, Protocol Adapter
- Source SysDes: SysDes-035, SysDes-074, SysDes-088, SysDes-102
- Verification method: Demo
- Acceptance criteria: Diagnostics include network and reconnect evidence without secrets.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-101**: The software shall minimize personal data collection in MVP.

- Type: Privacy
- Stage: P0 / MVP
- Allocated to: All Software Components
- Source SysDes: SysDes-090, SysDes-105
- Verification method: Privacy Review
- Acceptance criteria: MVP does not collect telemetry or upload personal diagnostics automatically.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-102**: The software shall not automatically upload diagnostics in MVP.

- Type: Privacy / Constraint
- Stage: P0 / MVP
- Allocated to: Diagnostics
- Source SysDes: SysDes-090, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: No automatic diagnostic upload endpoint or job is present.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-103**: The software shall display user-safe errors without raw internal stack traces.

- Type: Security / Error Handling
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Bridge, Diagnostics
- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089
- Verification method: UI Test, Security Review
- Acceptance criteria: Runtime errors displayed to users contain safe message and recovery hint only.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-104**: The software shall provide a platform adapter interface for microphone capture.

- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071
- Verification method: Platform Integration Test
- Acceptance criteria: Each supported platform can provide captured PCM frames to the audio pipeline.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.11 Platform Adapter Requirements

**SRS-105**: The software shall provide a platform adapter interface for speaker/headphone playback.

- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072
- Verification method: Platform Integration Test
- Acceptance criteria: Each supported platform can play mixed PCM frames from the audio pipeline.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-106**: The software shall provide a platform adapter interface for audio device enumeration and selection where supported.

- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem, Flutter UI
- Source SysDes: SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075
- Verification method: Platform Integration Test
- Acceptance criteria: Input/output device lists are exposed and selection changes are applied or reported as unsupported.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-107**: The software shall provide a platform adapter interface for audio route changes.

- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086
- Verification method: Platform Integration Test
- Acceptance criteria: Route changes are emitted to Rust Core/Flutter and handled safely.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-108**: The software shall provide a platform adapter interface for microphone permission requests.

- Type: Interface / Platform
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Flutter UI
- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090
- Verification method: Platform Integration Test
- Acceptance criteria: Permission state is queryable and request flow triggers platform permission behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-109**: The software shall provide a platform adapter interface for notification permission requests where required.

- Type: Interface / Platform
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Flutter UI
- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090
- Verification method: Platform Integration Test
- Acceptance criteria: Notification permission flow is available on platforms requiring it.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-110**: The iOS software shall integrate with AVAudioSession or equivalent platform audio session behavior for foreground voice sessions.

- Type: Platform / iOS
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080
- Verification method: iOS Integration Test
- Acceptance criteria: iOS foreground voice session handles capture, playback, route change, and interruption callbacks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-111**: The Android software shall integrate with foreground service behavior for active voice sessions.

- Type: Platform / Android
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080
- Verification method: Android Integration Test
- Acceptance criteria: Android active voice session uses foreground service behavior according to platform rules.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-112**: The Android software shall handle audio focus and Bluetooth route changes where platform APIs expose them.

- Type: Platform / Android
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086
- Verification method: Android Integration Test
- Acceptance criteria: Audio focus loss/gain and Bluetooth route events are handled safely.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-113**: The desktop software shall support validated audio backends for Windows, macOS, and Linux.

- Type: Platform / Desktop
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086
- Verification method: Desktop Integration Test
- Acceptance criteria: Desktop audio capture/playback works on representative Windows, macOS, and Linux systems.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-114**: The software shall provide platform adapter lifecycle events for foreground/background, app resume, app suspend, audio interruption, and shutdown where supported.

- Type: Interface / Platform
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Rust Core, Audio Subsystem
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080
- Verification method: Platform Integration Test
- Acceptance criteria: Lifecycle events reach Rust Core and do not corrupt connection/audio state.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-115**: The software shall document unsupported or degraded platform behaviors through user-safe status and diagnostics.

- Type: Platform / Diagnostics
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Diagnostics, Flutter UI
- Source SysDes: SysDes-050, SysDes-075, SysDes-084, SysDes-090
- Verification method: Review, Demo
- Acceptance criteria: Unsupported device/permission/lifecycle cases are visible in UI or diagnostics.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-116**: The software shall produce build artifacts for Windows installer packaging.

- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: Windows installer artifact is generated from configured CI or release script.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.12 Packaging and Release Requirements

**SRS-117**: The software shall produce signed and notarized macOS release builds for production release.

- Type: Packaging
- Stage: P2 / Production
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build/Release Audit
- Acceptance criteria: macOS release process includes signing and notarization evidence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-118**: The software shall produce Linux release packages using the selected supported package formats.

- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: At least one selected Linux package format is generated.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-119**: The software shall produce Android AAB release builds.

- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: Android AAB build succeeds with release configuration.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-120**: The software shall produce iOS TestFlight and App Store release builds when signing assets are available.

- Type: Packaging
- Stage: P1 / Beta
- Allocated to: Application Container, Deployment Scripts
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test
- Acceptance criteria: iOS archive/export succeeds on supported macOS build environment.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-121**: The software release metadata and in-app wording shall not imply official TeamSpeak affiliation.

- Type: Legal / Product Constraint
- Stage: P0 / MVP
- Allocated to: Application Container, Flutter UI, Deployment Scripts
- Source SysDes: SysDes-005, SysDes-036, SysDes-091, SysDes-106
- Verification method: Legal Review, Inspection
- Acceptance criteria: App metadata, UI copy, README, and store text use independent compatibility wording.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-122**: The software shall provide release-build configuration that disables development-only diagnostic capture unless explicitly enabled for test builds.

- Type: Security / Release
- Stage: P1 / Beta
- Allocated to: Application Container, Diagnostics, Deployment Scripts
- Source SysDes: SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106
- Verification method: Inspection, Security Review
- Acceptance criteria: Production configuration does not enable protocol recording or verbose logs by default.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-123**: The software shall include or support a protocol probe tool for validating `tsclientlib` adapter behavior against compatible test servers.

- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Diagnostics
- Source SysDes: SysDes-017, SysDes-035, SysDes-102
- Verification method: Demo
- Acceptance criteria: Protocol probe reports connection, snapshot, event, text, and voice compatibility evidence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.13 Verification Support Requirements

**SRS-124**: The software shall include reducer tests and event replay tests for state synchronization.

- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: State Sync, Diagnostics
- Source SysDes: SysDes-030, SysDes-035, SysDes-103
- Verification method: Unit Test, Demo
- Acceptance criteria: Reducer and replay tests cover snapshot, delta, reconnect, and malformed-event behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-125**: The software shall include audio loopback and audio processing tests for capture, playback, codec, jitter buffer, mixer, Echo Canceller, AGC, Noise Suppression, and High-Pass Filter.

- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Diagnostics
- Source SysDes: SysDes-031, SysDes-035, SysDes-104
- Verification method: Audio Test, Demo
- Acceptance criteria: Audio verification tools execute required audio processing checks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-126**: The software shall include security verification support for secure storage, private-key handling, password handling, input validation, and diagnostic redaction.

- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: Storage, Diagnostics, Platform Adapters
- Source SysDes: SysDes-034, SysDes-035, SysDes-089, SysDes-105
- Verification method: Security Audit
- Acceptance criteria: Security checklist and tests cover required sensitive data behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-127**: The software shall include release verification support for package creation, signing, notarization, app-store builds, and release metadata wording.

- Type: Verification Support
- Stage: P1 / Beta
- Allocated to: Deployment Scripts, Application Container
- Source SysDes: SysDes-036, SysDes-091, SysDes-106
- Verification method: Build Test, Release Audit
- Acceptance criteria: Release verification checklist covers each target platform and metadata review.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-128**: The software shall support MVP acceptance verification demonstrating connection, channel tree, online clients, channel join, send/receive voice, mute, deaf, push-to-talk, required audio processing, channel text, bookmarks, secure storage, and redacted diagnostics.

- Type: Verification Support
- Stage: P0 / MVP
- Allocated to: All Software Components
- Source SysDes: SysDes-017, SysDes-035, SysDes-102 through SysDes-107
- Verification method: System Test, Demo
- Acceptance criteria: MVP acceptance test run passes all acceptance checks.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-129**: The software shall expose clear user-facing errors when client hardware lacks a usable microphone, output device, CPU capacity, storage, or network interface required for the requested operation.

- Type: Operating Environment Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-020, SysDes-045, SysDes-086, SysDes-089
- Verification method: System Test
- Acceptance criteria: Missing hardware/resource conditions produce non-crashing user-safe errors.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.14 Operating Environment and External Interface Requirements

**SRS-130**: The software shall expose clear user-facing errors when network connectivity prevents server connection or real-time voice operation.

- Type: Operating Environment Constraint
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Protocol Adapter
- Source SysDes: SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088
- Verification method: System Test
- Acceptance criteria: Network failures produce reconnect or safe error behavior.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-131**: The software shall handle external compatible server permissions, availability, and event behavior as external dependencies and shall not assume administrative control.

- Type: Operating Environment Constraint
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Rust Core, Flutter UI
- Source SysDes: SysDes-023, SysDes-043, SysDes-082, SysDes-102
- Verification method: System Test
- Acceptance criteria: Permission denied and server unavailable cases produce user-safe outcomes.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-132**: The software shall allow server details, credentials, and identity selection to be supplied by the user rather than hardcoding a server environment.

- Type: Functional / Environment
- Stage: P0 / MVP
- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage
- Source SysDes: SysDes-019, SysDes-023, SysDes-055, SysDes-065
- Verification method: UI Test, System Test
- Acceptance criteria: User can provide and save server details without Chanora backend dependency.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-133**: The software shall integrate with OS-level secure storage, permission, audio, network, notification, lifecycle, and app sandboxing policies through platform adapters.

- Type: Operating Environment Interface
- Stage: P0 / MVP
- Allocated to: Platform Adapters, Rust Core, Flutter UI
- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090
- Verification method: Platform Integration Test
- Acceptance criteria: Platform services are used through approved adapter APIs.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-134**: The software team shall analyze `tsclientlib` feasibility for all MVP protocol features and document unsupported or risky features before MVP acceptance.

- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Software Requirements Engineering
- Source SysDes: SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102
- Verification method: Review, Protocol Probe
- Acceptance criteria: Protocol compatibility matrix identifies pass/fail/unknown state for MVP protocol features.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

### 5.15 Technical Feasibility and Impact Analysis Requirements

**SRS-135**: The software team shall analyze real-time audio feasibility on each target platform for capture, playback, required audio processing, and latency.

- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Audio Subsystem, Platform Adapters
- Source SysDes: SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104
- Verification method: Review, Audio Test
- Acceptance criteria: Audio feasibility report exists per platform with known limitations and mitigations.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-136**: The software team shall analyze memory growth and define limits for event queues, chat history, logs, audio buffers, and diagnostic bundles.

- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage
- Source SysDes: SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087
- Verification method: Review, Performance Test
- Acceptance criteria: Resource limit configuration and tests exist for queues, buffers, and logs.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-137**: The software team shall analyze security and privacy impacts of local secrets, logs, diagnostics, permissions, and release configuration.

- Type: Analysis Requirement
- Stage: P0 / MVP
- Allocated to: Storage, Diagnostics, Platform Adapters, Flutter UI
- Source SysDes: SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105
- Verification method: Security Review, Privacy Review
- Acceptance criteria: Security/privacy analysis documents risks, mitigations, and verification evidence.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-138**: The software team shall analyze operating-environment impacts of mobile lifecycle, foreground service behavior, AVAudioSession behavior, route changes, and app store policies.

- Type: Analysis Requirement
- Stage: P1 / Beta
- Allocated to: Platform Adapters, Audio Subsystem, Deployment Scripts
- Source SysDes: SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106
- Verification method: Review, Platform Test
- Acceptance criteria: Mobile lifecycle analysis documents behavior and limitations.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-139**: The software requirements baseline shall account for SysDes-037: SE-19 Engineering Process and Evidence shall be a defined system element in the Chanora architecture with responsibility for: Architecture reviews, traceability records, verification evidence, compatibility matrix, open decisions, and downstream SRS/SAD/SDD/Verification artifacts.

- Type: Traceability / Coverage
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-037
- Verification method: Review
- Acceptance criteria: SysDes-037 is represented in SRS traceability and downstream software analysis.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-140**: The software requirements baseline shall account for SysDes-062: The permission-blocked mode shall prevent unsafe voice operations while preserving user visibility into corrective actions.

- Type: Traceability / Coverage
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-062
- Verification method: Review
- Acceptance criteria: SysDes-062 is represented in SRS traceability and downstream software analysis.
- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed.
- Owner: Software Team

**SRS-141**: The SRS shall use SysDes design items as the mandatory architectural allocation source for every software requirement.

- Type: Process / Traceability
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering
- Source SysDes: SysDes-108, SysDes-109
- Verification method: Review, Inspection
- Acceptance criteria: Every SRS requirement has a `Source SysDes` field and no individual SRS requirement uses an upstream system-requirement ID as its direct source.
- Analysis: Feasible because SysDes v0.5 defines the downstream derivation rule and software-impacting allocation layer.
- Owner: Software Team

**SRS-142**: If the software team identifies a required software behavior, constraint, or interface that cannot be derived from an existing SysDes design item, the SRS shall not be baselined until the SysDes is revised.

- Type: Process / Change Control
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering, Change Control
- Source SysDes: SysDes-110
- Verification method: Review, Inspection
- Acceptance criteria: Change-control records show SysDes-first correction for any new software requirement source gap.
- Analysis: Feasible through requirements review and change-control workflow before SRS baseline.
- Owner: Software Team

**SRS-143**: The SRS shall maintain a SysDes-to-SRS coverage matrix for all SysDes items that require software implementation, software enablement, software-facing constraint handling, or software verification support.

- Type: Process / Coverage
- Stage: P0 / MVP
- Allocated to: Software Requirements Engineering, Verification
- Source SysDes: SysDes-108, SysDes-109, SysDes-110
- Verification method: Review, Inspection
- Acceptance criteria: Coverage matrix shows that each software-impacting SysDes item is covered by one or more SRS requirements, or explicitly identified as non-software-owned.
- Analysis: Feasible with the SysDes metadata register and SRS coverage matrix.
- Owner: Software Team


## 6. Operating Environment Impact Analysis

| Environment element | Software impact | Related SRS |
|---|---|---|
| Client hardware | Software must detect or report missing microphone, output device, CPU/storage/network resource constraints. | SRS-130 |
| OS services | Software must integrate with permissions, secure storage, audio stack, lifecycle, notifications, and sandbox policies through platform adapters. | SRS-105 through SRS-116, SRS-134 |
| Network | Software must handle unreachable servers, recoverable failures, reconnect, and user-safe errors. | SRS-131 |
| External compatible server | Software must treat server permissions, availability, authentication, events, and protocol behavior as external dependencies. | SRS-132, SRS-133 |
| Audio devices | Software must handle input/output device selection, route changes, and degraded audio states. | SRS-107 through SRS-110 |
| Mobile lifecycle | Software must handle foreground voice sessions, audio interruption, route changes, and background policy limits. | SRS-111 through SRS-115, SRS-139 |
| Secure storage | Software must use platform secure storage through an abstraction and avoid plaintext secret persistence. | SRS-091 through SRS-095 |
| Deployment environment | Software must produce platform-specific release packages and safe release metadata. | SRS-117 through SRS-123 |

## 7. Software Requirement Analysis Summary

| Analysis area | Result | Follow-up artifact |
|---|---|---|
| Correctness | Requirements are derived from SysDes and structured by software component. | SAD / SDD |
| Technical feasibility | Feasibility checks are required for `tsclientlib`, audio processing, mobile lifecycle, resource limits, and security. | Analysis report, SAD, SDD |
| Testability | Each requirement contains verification method and acceptance criteria. | Verification plan |
| Operating environment impact | OS services, hardware, network, server, deployment, and mobile lifecycle impacts are captured. | Platform design, Verification plan |
| Traceability | Every SysDes design item is mapped to one or more SRS requirements; direct SRS-to-upstream-system-requirement links are intentionally not used. | Traceability matrix |
| Communication | SRS baseline shall be communicated downstream to SWE.2/SAD, SWE.3/SDD, and SWE.6/Verification. | Review evidence |

## 8. SRS to SWE Lifecycle Handoff

| Downstream process/artifact | SRS handoff content |
|---|---|
| SWE.2 / SAD | Software components, interfaces, static and dynamic architecture constraints, NFR allocation, security and platform boundaries |
| SWE.3 / SDD | DTOs, API contracts, state machines, reducers, storage schema, audio pipeline module design, protocol adapter interfaces, error models |
| SWE.4 | Unit verification needs for reducers, audio processors, protocol mappers, storage logic, redaction, validation, and utility functions |
| SWE.5 | Software integration verification for Flutter-Bridge-Core, protocol-state, audio-platform, storage-secure-store, diagnostics-export, and packaging flows |
| SWE.6 | Integrated software verification against this SRS including MVP acceptance and platform compatibility |

## 9. SysDes to SRS Coverage Matrix

Coverage summary: 110 / 110 SysDes design items are covered by one or more SRS requirements.

Software-impacting SysDes items: 95 / 110. All software-impacting SysDes items are represented in the SRS coverage below. Non-software design items are covered as software assumptions, external-interface constraints, verification hooks, or process controls when they affect software work.

Missing SysDes coverage: None.

| SysDes ID | SysDes allocation | Covered by SRS |
|---|---|---|
| SysDes-001 | System Engineering | SRS-001 |
| SysDes-002 | System Engineering | SRS-001, SRS-008 |
| SysDes-003 | System Engineering | SRS-001, SRS-007 |
| SysDes-004 | System Engineering, Verification | SRS-002 |
| SysDes-005 | System Engineering | SRS-002, SRS-003, SRS-121 |
| SysDes-006 | Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-002, SRS-003, SRS-004 |
| SysDes-007 | System Engineering | SRS-002 |
| SysDes-008 | System Engineering, Verification | SRS-002, SRS-005 |
| SysDes-009 | System Engineering, Verification | SRS-002, SRS-005 |
| SysDes-010 | Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011 |
| SysDes-011 | Software: Protocol Adapter | SRS-044, SRS-053, SRS-134 |
| SysDes-012 | Software: Flutter UI, Software: Rust Core | SRS-013 |
| SysDes-013 | Software: Audio Subsystem | SRS-062, SRS-064, SRS-065, SRS-066, SRS-067, SRS-069, SRS-135 |
| SysDes-014 | Software: Flutter UI, Software: Audio Subsystem | SRS-012, SRS-135 |
| SysDes-015 | Software: Diagnostics, Verification | SRS-093, SRS-095, SRS-137 |
| SysDes-016 | System Engineering | SRS-009 |
| SysDes-017 | Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations | SRS-004, SRS-015, SRS-052, SRS-083, SRS-095, SRS-123, SRS-128, SRS-134 |
| SysDes-018 | External Server, Software: Audio Subsystem, Deployment / Operations | SRS-006 |
| SysDes-019 | User / Operator, Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-096, SRS-132 |
| SysDes-020 | Hardware, Software: Audio Subsystem | SRS-006, SRS-062, SRS-106, SRS-129, SRS-135 |
| SysDes-021 | Platform, Software: Audio Subsystem, Platform Secure Storage | SRS-006, SRS-027, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-137, SRS-138 |
| SysDes-022 | Network | SRS-006, SRS-130 |
| SysDes-023 | External Server, Software: Audio Subsystem, Platform | SRS-006, SRS-010, SRS-131, SRS-132 |
| SysDes-024 | Software, Platform | SRS-008, SRS-016 |
| SysDes-025 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-017, SRS-018, SRS-019, SRS-020, SRS-021, SRS-022, SRS-024, SRS-025, SRS-026, SRS-027, SRS-028, SRS-080, SRS-081, SRS-096, SRS-108, SRS-109 |
| SysDes-026 | Software: Flutter State, Software: Rust Core, Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030 |
| SysDes-027 | Software: Bridge, Software: Rust Core | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-103 |
| SysDes-028 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-036, SRS-037, SRS-038, SRS-039, SRS-136 |
| SysDes-029 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-134 |
| SysDes-030 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-036, SRS-043, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060, SRS-061, SRS-124, SRS-136 |
| SysDes-031 | Software: Audio Subsystem | SRS-025, SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081, SRS-125, SRS-135, SRS-136 |
| SysDes-032 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-013, SRS-014, SRS-027, SRS-070, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-138 |
| SysDes-033 | Software: Audio Subsystem, Software: Storage | SRS-026, SRS-068, SRS-075, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-136 |
| SysDes-034 | Platform Secure Storage | SRS-006, SRS-090, SRS-091, SRS-092, SRS-126, SRS-137 |
| SysDes-035 | Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-028, SRS-052, SRS-061, SRS-083, SRS-093, SRS-095, SRS-096, SRS-097, SRS-098, SRS-099, SRS-100, SRS-122, SRS-123, SRS-124, SRS-125, SRS-126, SRS-128, SRS-136, SRS-137 |
| SysDes-036 | Software: Storage, Deployment / Operations | SRS-006, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-127 |
| SysDes-037 | System Engineering, Verification | SRS-139 |
| SysDes-038 | Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core | SRS-003, SRS-011, SRS-016, SRS-031, SRS-032 |
| SysDes-039 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011, SRS-039 |
| SysDes-040 | Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter | SRS-012, SRS-029, SRS-033, SRS-044 |
| SysDes-041 | Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem | SRS-011, SRS-013, SRS-016 |
| SysDes-042 | System Engineering | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-038, SRS-039, SRS-103 |
| SysDes-043 | External Server, Deployment / Operations, System Engineering, Verification | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-131, SRS-134 |
| SysDes-044 | Software: Flutter UI, Software: Rust Core | SRS-036, SRS-037, SRS-054, SRS-057 |
| SysDes-045 | Hardware, Platform, Network | SRS-031, SRS-034, SRS-048, SRS-094, SRS-103, SRS-129, SRS-130 |
| SysDes-046 | Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering | SRS-020, SRS-032, SRS-035 |
| SysDes-047 | System Engineering | SRS-030, SRS-032, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060 |
| SysDes-048 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-090, SRS-091, SRS-092 |
| SysDes-049 | Software: Bridge, Software: Protocol Adapter | SRS-031, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089 |
| SysDes-050 | Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-014, SRS-027, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-133 |
| SysDes-051 | Software: Protocol Adapter | SRS-036, SRS-037 |
| SysDes-052 | External Server, Software: Protocol Adapter | SRS-029, SRS-033, SRS-039, SRS-047 |
| SysDes-053 | Software: Audio Subsystem | SRS-029, SRS-044 |
| SysDes-054 | Software: Audio Subsystem | SRS-029 |
| SysDes-055 | Software: Storage, Platform Secure Storage | SRS-017, SRS-018, SRS-023, SRS-024, SRS-031, SRS-038, SRS-132 |
| SysDes-056 | Software: Storage | SRS-025, SRS-026, SRS-028, SRS-031, SRS-032, SRS-068, SRS-086, SRS-095, SRS-103, SRS-106 |
| SysDes-057 | Software: Diagnostics, Verification | SRS-029, SRS-030, SRS-033, SRS-037, SRS-044, SRS-047 |
| SysDes-058 | Software: Diagnostics, Verification | SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-104, SRS-105 |
| SysDes-059 | Software: Audio Subsystem, Platform | SRS-017, SRS-018 |
| SysDes-060 | Software: Rust Core | SRS-019, SRS-036, SRS-037, SRS-038, SRS-040 |
| SysDes-061 | Software: Protocol Adapter, Software: Audio Subsystem, Platform | SRS-019, SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-046, SRS-054, SRS-055, SRS-056 |
| SysDes-062 | Software: Audio Subsystem, Platform | SRS-140 |
| SysDes-063 | Software: State Sync | SRS-025, SRS-062, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081 |
| SysDes-064 | Software: Diagnostics, Verification | SRS-019, SRS-036, SRS-040, SRS-041, SRS-042, SRS-130 |
| SysDes-065 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-018, SRS-038, SRS-045, SRS-094, SRS-132 |
| SysDes-066 | Software: Rust Core, Software: Protocol Adapter | SRS-019, SRS-036, SRS-037, SRS-040, SRS-042, SRS-059 |
| SysDes-067 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-032, SRS-036, SRS-043, SRS-046, SRS-054, SRS-055 |
| SysDes-068 | Software: State Sync | SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-047, SRS-054, SRS-056, SRS-057, SRS-058, SRS-060 |
| SysDes-069 | Software: Rust Core, Software: Protocol Adapter | SRS-023, SRS-038, SRS-049 |
| SysDes-070 | Software: Rust Core, Software: Protocol Adapter | SRS-024, SRS-038, SRS-050 |
| SysDes-071 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-077, SRS-079, SRS-080, SRS-104 |
| SysDes-072 | Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-078, SRS-081, SRS-088, SRS-105 |
| SysDes-073 | Software | SRS-038, SRS-041 |
| SysDes-074 | Software: State Sync | SRS-038, SRS-040, SRS-041, SRS-042, SRS-043, SRS-059, SRS-100, SRS-130 |
| SysDes-075 | Software: Audio Subsystem, Platform | SRS-026, SRS-082, SRS-099, SRS-106, SRS-107, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-135, SRS-138 |
| SysDes-076 | Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification | SRS-028, SRS-038, SRS-090, SRS-091, SRS-092, SRS-093, SRS-095, SRS-096, SRS-137 |
| SysDes-077 | Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-039 |
| SysDes-078 | Software: Protocol Adapter | SRS-044, SRS-047, SRS-053, SRS-134 |
| SysDes-079 | Software: State Sync, System Engineering, Verification | SRS-043, SRS-058, SRS-059, SRS-061, SRS-097, SRS-098 |
| SysDes-080 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-014, SRS-090, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-138 |
| SysDes-081 | Software: Audio Subsystem | SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-086, SRS-135 |
| SysDes-082 | Platform | SRS-006, SRS-010, SRS-131 |
| SysDes-083 | Software: Audio Subsystem | SRS-009, SRS-010 |
| SysDes-084 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-006, SRS-115, SRS-122, SRS-134, SRS-138 |
| SysDes-085 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-035 |
| SysDes-086 | Hardware, Network, Software: Audio Subsystem, Platform | SRS-006, SRS-026, SRS-062, SRS-066, SRS-069, SRS-073, SRS-082, SRS-099, SRS-107, SRS-112, SRS-113, SRS-129, SRS-135 |
| SysDes-087 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-095, SRS-136 |
| SysDes-088 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem | SRS-034, SRS-041, SRS-042, SRS-043, SRS-048, SRS-059, SRS-060, SRS-100, SRS-130 |
| SysDes-089 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-034, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-103, SRS-126, SRS-129, SRS-137 |
| SysDes-090 | Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-093, SRS-095, SRS-096, SRS-101, SRS-102, SRS-108, SRS-109, SRS-115, SRS-122, SRS-133, SRS-137 |
| SysDes-091 | Software: Storage, Deployment / Operations, System Engineering, Verification | SRS-004, SRS-006, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-138 |
| SysDes-092 | System Engineering | SRS-002, SRS-005 |
| SysDes-093 | System Engineering | SRS-002, SRS-005 |
| SysDes-094 | System Engineering | SRS-002, SRS-005 |
| SysDes-095 | System Engineering | SRS-002, SRS-005 |
| SysDes-096 | System Engineering | SRS-002, SRS-005 |
| SysDes-097 | System Engineering, Verification | SRS-002, SRS-005 |
| SysDes-098 | Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification | SRS-007, SRS-095 |
| SysDes-099 | System Engineering, Verification | SRS-007 |
| SysDes-100 | System Engineering | SRS-007 |
| SysDes-101 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification | SRS-006 |
| SysDes-102 | External Server, Software: Protocol Adapter | SRS-004, SRS-015, SRS-045, SRS-046, SRS-049, SRS-050, SRS-051, SRS-052, SRS-097, SRS-100, SRS-123, SRS-128, SRS-131, SRS-134 |
| SysDes-103 | Software: State Sync | SRS-004, SRS-015, SRS-058, SRS-059, SRS-060, SRS-061, SRS-097, SRS-098, SRS-124, SRS-128 |
| SysDes-104 | Software: Audio Subsystem | SRS-004, SRS-015, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-072, SRS-073, SRS-076, SRS-083, SRS-099, SRS-125, SRS-128, SRS-135 |
| SysDes-105 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-004, SRS-015, SRS-028, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-095, SRS-096, SRS-101, SRS-102, SRS-126, SRS-128, SRS-137 |
| SysDes-106 | Software: Storage, Deployment / Operations | SRS-004, SRS-015, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-128, SRS-138 |
| SysDes-107 | Verification | SRS-004, SRS-015, SRS-128 |
| SysDes-108 | System Engineering, Software Requirements Engineering, Verification | SRS-004, SRS-005, SRS-141, SRS-143 |
| SysDes-109 | System Engineering, Software Requirements Engineering | SRS-004, SRS-005, SRS-141, SRS-143 |
| SysDes-110 | System Engineering, Software Requirements Engineering, Change Control, Verification | SRS-004, SRS-005, SRS-142, SRS-143 |

## 10. SRS Requirement Register

| SRS ID | Type | Stage | Allocated to | Verification method | Source SysDes |
|---|---|---|---|---|---|
| SRS-001 | Process / SWE.1 | P0 / MVP | Software Requirements Engineering | Review | SysDes-001 through SysDes-003 |
| SRS-002 | Process / Requirement Attribute | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-004 through SysDes-009, SysDes-092 through SysDes-097 |
| SRS-003 | Process / Structuring | P0 / MVP | Software Requirements Engineering | Review | SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039 |
| SRS-004 | Process / Prioritization | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110 |
| SRS-005 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110 |
| SRS-006 | Process / Operating Environment Analysis | P0 / MVP | Software Requirements Engineering | Review | SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101 |
| SRS-007 | Process / Communication | P0 / MVP | Software Requirements Engineering | Review | SysDes-003, SysDes-098 through SysDes-100 |
| SRS-008 | Constraint | P0 / MVP | Application Container | Review | SysDes-002, SysDes-024 |
| SRS-009 | Constraint | P0 / MVP | Application Container, Rust Core | Review, System Test | SysDes-016, SysDes-083 |
| SRS-010 | Constraint | P0 / MVP | Application Container, Protocol Adapter | Inspection | SysDes-023, SysDes-082, SysDes-083 |
| SRS-011 | Architecture Constraint | P0 / MVP | All Software Components | Inspection | SysDes-010, SysDes-038, SysDes-039, SysDes-041 |
| SRS-012 | Architecture Constraint | P0 / MVP | Flutter UI, Audio Subsystem | Inspection, Performance Test | SysDes-014, SysDes-040, SysDes-071, SysDes-072 |
| SRS-013 | Platform Requirement | P0 / MVP | Flutter UI, Rust Core, Platform Adapters | Build Test | SysDes-012, SysDes-032, SysDes-041 |
| SRS-014 | Architecture Constraint | P0 / MVP | Platform Adapters | Inspection, Integration Test | SysDes-032, SysDes-050, SysDes-080 |
| SRS-015 | Verification Hook | P0 / MVP | Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters | Inspection, Demo | SysDes-017, SysDes-102 through SysDes-107 |
| SRS-016 | Functional | P0 / MVP | Application Container | Integration Test | SysDes-024, SysDes-038, SysDes-041 |
| SRS-017 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059 |
| SRS-018 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059, SysDes-065 |
| SRS-019 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066 |
| SRS-020 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068 |
| SRS-021 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068 |
| SRS-022 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test | SysDes-025, SysDes-026, SysDes-030, SysDes-067 |
| SRS-023 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | System Test | SysDes-055, SysDes-069 |
| SRS-024 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | UI Test, System Test | SysDes-025, SysDes-055, SysDes-070 |
| SRS-025 | Functional | P0 / MVP | Flutter UI, Audio Subsystem | UI Test, System Test | SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072 |
| SRS-026 | Functional | P0 / MVP | Flutter UI, Audio Subsystem, Storage | UI Test | SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086 |
| SRS-027 | Functional / Privacy | P0 / MVP | Flutter UI, Platform Adapters | UI Test, Privacy Review | SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 |
| SRS-028 | Functional / Diagnostics | P1 / Beta | Flutter UI, Diagnostics | UI Test, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105 |
| SRS-029 | Constraint | P0 / MVP | Flutter UI, Flutter State | Inspection | SysDes-040, SysDes-052 through SysDes-054, SysDes-057 |
| SRS-030 | Functional | P0 / MVP | Flutter State | Inspection, UI Test | SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068 |
| SRS-031 | Interface | P0 / MVP | Bridge Layer | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056 |
| SRS-032 | Interface | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068 |
| SRS-033 | Interface / Safety | P0 / MVP | Bridge Layer | Inspection, Integration Test | SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057 |
| SRS-034 | Interface / Error Handling | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089 |
| SRS-035 | Non-functional | P0 / MVP | Bridge Layer, Rust Core | Performance Test | SysDes-027, SysDes-042, SysDes-046, SysDes-085 |
| SRS-036 | Functional | P0 / MVP | Rust Core | Unit Test, Integration Test | SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068 |
| SRS-037 | Functional | P0 / MVP | Rust Core | Inspection, Unit Test | SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066 |
| SRS-038 | Functional | P0 / MVP | Rust Core, Bridge | Integration Test | SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076 |
| SRS-039 | Functional / Architecture | P0 / MVP | Rust Core | Inspection | SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077 |
| SRS-040 | Functional | P0 / MVP | Rust Core, State Sync | Unit Test, System Test | SysDes-060, SysDes-064, SysDes-066, SysDes-074 |
| SRS-041 | Functional | P0 / MVP | Rust Core | System Test | SysDes-064, SysDes-073, SysDes-074, SysDes-088 |
| SRS-042 | Functional / Reliability | P0 / MVP | Rust Core, Protocol Adapter, State Sync | System Test | SysDes-064, SysDes-066, SysDes-074, SysDes-088 |
| SRS-043 | Functional / Reliability | P0 / MVP | Rust Core, State Sync | System Test, Event Replay Test | SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088 |
| SRS-044 | Architecture Constraint | P0 / MVP | Protocol Adapter | Inspection | SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078 |
| SRS-045 | Functional | P0 / MVP | Protocol Adapter, Rust Core | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-065, SysDes-102 |
| SRS-046 | Functional | P0 / MVP | Protocol Adapter, State Sync | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102 |
| SRS-047 | Functional | P0 / MVP | Protocol Adapter, State Sync | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078 |
| SRS-048 | Functional / Error Handling | P0 / MVP | Protocol Adapter, Rust Core | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-045, SysDes-088 |
| SRS-049 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-069, SysDes-102 |
| SRS-050 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-070, SysDes-102 |
| SRS-051 | Functional | P0 / MVP | Protocol Adapter, Audio Subsystem | Protocol Integration Test, Audio Test | SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104 |
| SRS-052 | Verification Hook | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 |
| SRS-053 | Maintainability | P1 / Beta | Protocol Adapter, Bridge | Architecture Review | SysDes-011, SysDes-029, SysDes-043, SysDes-078 |
| SRS-054 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068 |
| SRS-055 | Functional | P0 / MVP | State Sync | Unit Test, Integration Test | SysDes-030, SysDes-047, SysDes-061, SysDes-067 |
| SRS-056 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-061, SysDes-068 |
| SRS-057 | Functional | P0 / MVP | State Sync, Rust Core | Unit Test, Integration Test | SysDes-030, SysDes-044, SysDes-047, SysDes-068 |
| SRS-058 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103 |
| SRS-059 | Functional / Reliability | P0 / MVP | State Sync | Event Replay Test, System Test | SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103 |
| SRS-060 | Reliability | P0 / MVP | State Sync, Rust Core | Unit Test, Fuzz/Negative Test | SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103 |
| SRS-061 | Verification Hook | P1 / Beta | State Sync, Diagnostics | Demo | SysDes-030, SysDes-035, SysDes-079, SysDes-103 |
| SRS-062 | Functional | P0 / MVP | Audio Subsystem | Audio Integration Test | SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104 |
| SRS-063 | Functional | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-064 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-065 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-066 | Functional / Audio Processing | P0 / MVP | Audio Subsystem, Platform Adapters | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104 |
| SRS-067 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 |
| SRS-068 | Functional / Settings | P0 / MVP | Audio Subsystem, Flutter UI, Storage | UI Test, Unit Test | SysDes-031, SysDes-033, SysDes-056, SysDes-081 |
| SRS-069 | Non-functional / Audio | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-031, SysDes-081, SysDes-086 |
| SRS-070 | Architecture / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Inspection | SysDes-031, SysDes-032, SysDes-058, SysDes-081 |
| SRS-071 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-104 |
| SRS-072 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 |
| SRS-073 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104 |
| SRS-074 | Functional / Audio Playback | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-031, SysDes-058, SysDes-072 |
| SRS-075 | Functional / Audio Playback | P1 / Beta | Audio Subsystem, Flutter UI, Storage | Audio Test, UI Test | SysDes-031, SysDes-033, SysDes-058, SysDes-072 |
| SRS-076 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 |
| SRS-077 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 |
| SRS-078 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-072 |
| SRS-079 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 |
| SRS-080 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-071 |
| SRS-081 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, State Sync, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-072 |
| SRS-082 | Reliability / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Platform Integration Test | SysDes-032, SysDes-050, SysDes-075, SysDes-086 |
| SRS-083 | Verification Hook | P1 / Beta | Audio Subsystem, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-104 |
| SRS-084 | Functional / Storage | P0 / MVP | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 |
| SRS-085 | Functional / Storage | P1 / Beta | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 |
| SRS-086 | Functional / Storage | P0 / MVP | Storage, Audio Subsystem | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081 |
| SRS-087 | Functional / Storage | P1 / Beta | Storage, Flutter UI | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 |
| SRS-088 | Functional / Storage | P1 / Beta | Storage, Audio Subsystem | Unit Test | SysDes-033, SysDes-036, SysDes-049, SysDes-072 |
| SRS-089 | Architecture / Storage | P0 / MVP | Storage | Inspection | SysDes-033, SysDes-036, SysDes-049, SysDes-091 |
| SRS-090 | Interface / Security | P0 / MVP | Storage, Platform Adapters | Inspection, Security Audit | SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105 |
| SRS-091 | Security | P0 / MVP | Storage, Platform Secure Storage | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 |
| SRS-092 | Security | P0 / MVP | Storage, Platform Secure Storage, Diagnostics | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 |
| SRS-093 | Security / Diagnostics | P0 / MVP | Diagnostics, Storage | Security Audit | SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 |
| SRS-094 | Security | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | Unit Test, Security Test | SysDes-045, SysDes-065, SysDes-089, SysDes-105 |
| SRS-095 | Diagnostics | P0 / MVP | Diagnostics | Inspection, Demo | SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105 |
| SRS-096 | Diagnostics | P1 / Beta | Diagnostics, Flutter UI | Demo, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105 |
| SRS-097 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Protocol Adapter, State Sync | Demo | SysDes-035, SysDes-079, SysDes-102, SysDes-103 |
| SRS-098 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, State Sync | Demo | SysDes-035, SysDes-079, SysDes-103 |
| SRS-099 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Audio Subsystem, Platform Adapters | Demo | SysDes-035, SysDes-075, SysDes-086, SysDes-104 |
| SRS-100 | Diagnostics / Reliability | P1 / Beta | Diagnostics, Rust Core, Protocol Adapter | Demo | SysDes-035, SysDes-074, SysDes-088, SysDes-102 |
| SRS-101 | Privacy | P0 / MVP | All Software Components | Privacy Review | SysDes-090, SysDes-105 |
| SRS-102 | Privacy / Constraint | P0 / MVP | Diagnostics | Security Audit | SysDes-090, SysDes-105 |
| SRS-103 | Security / Error Handling | P0 / MVP | Flutter UI, Rust Core, Bridge, Diagnostics | UI Test, Security Review | SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089 |
| SRS-104 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071 |
| SRS-105 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072 |
| SRS-106 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem, Flutter UI | Platform Integration Test | SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075 |
| SRS-107 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086 |
| SRS-108 | Interface / Platform | P0 / MVP | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 |
| SRS-109 | Interface / Platform | P1 / Beta | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 |
| SRS-110 | Platform / iOS | P0 / MVP | Platform Adapters, Audio Subsystem | iOS Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 |
| SRS-111 | Platform / Android | P0 / MVP | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 |
| SRS-112 | Platform / Android | P1 / Beta | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 |
| SRS-113 | Platform / Desktop | P1 / Beta | Platform Adapters, Audio Subsystem | Desktop Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 |
| SRS-114 | Interface / Platform | P1 / Beta | Platform Adapters, Rust Core, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 |
| SRS-115 | Platform / Diagnostics | P1 / Beta | Platform Adapters, Diagnostics, Flutter UI | Review, Demo | SysDes-050, SysDes-075, SysDes-084, SysDes-090 |
| SRS-116 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-117 | Packaging | P2 / Production | Application Container, Deployment Scripts | Build/Release Audit | SysDes-036, SysDes-091, SysDes-106 |
| SRS-118 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-119 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-120 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 |
| SRS-121 | Legal / Product Constraint | P0 / MVP | Application Container, Flutter UI, Deployment Scripts | Legal Review, Inspection | SysDes-005, SysDes-036, SysDes-091, SysDes-106 |
| SRS-122 | Security / Release | P1 / Beta | Application Container, Diagnostics, Deployment Scripts | Inspection, Security Review | SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106 |
| SRS-123 | Verification Support | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 |
| SRS-124 | Verification Support | P0 / MVP | State Sync, Diagnostics | Unit Test, Demo | SysDes-030, SysDes-035, SysDes-103 |
| SRS-125 | Verification Support | P0 / MVP | Audio Subsystem, Diagnostics | Audio Test, Demo | SysDes-031, SysDes-035, SysDes-104 |
| SRS-126 | Verification Support | P0 / MVP | Storage, Diagnostics, Platform Adapters | Security Audit | SysDes-034, SysDes-035, SysDes-089, SysDes-105 |
| SRS-127 | Verification Support | P1 / Beta | Deployment Scripts, Application Container | Build Test, Release Audit | SysDes-036, SysDes-091, SysDes-106 |
| SRS-128 | Verification Support | P0 / MVP | All Software Components | System Test, Demo | SysDes-017, SysDes-035, SysDes-102 through SysDes-107 |
| SRS-129 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Audio Subsystem, Platform Adapters | System Test | SysDes-020, SysDes-045, SysDes-086, SysDes-089 |
| SRS-130 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter | System Test | SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088 |
| SRS-131 | Operating Environment Constraint | P0 / MVP | Protocol Adapter, Rust Core, Flutter UI | System Test | SysDes-023, SysDes-043, SysDes-082, SysDes-102 |
| SRS-132 | Functional / Environment | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | UI Test, System Test | SysDes-019, SysDes-023, SysDes-055, SysDes-065 |
| SRS-133 | Operating Environment Interface | P0 / MVP | Platform Adapters, Rust Core, Flutter UI | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090 |
| SRS-134 | Analysis Requirement | P0 / MVP | Protocol Adapter, Software Requirements Engineering | Review, Protocol Probe | SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102 |
| SRS-135 | Analysis Requirement | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104 |
| SRS-136 | Analysis Requirement | P0 / MVP | Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage | Review, Performance Test | SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087 |
| SRS-137 | Analysis Requirement | P0 / MVP | Storage, Diagnostics, Platform Adapters, Flutter UI | Security Review, Privacy Review | SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 |
| SRS-138 | Analysis Requirement | P1 / Beta | Platform Adapters, Audio Subsystem, Deployment Scripts | Review, Platform Test | SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106 |
| SRS-139 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-037 |
| SRS-140 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-062 |
| SRS-141 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Review, Inspection | SysDes-108, SysDes-109 |
| SRS-142 | Process / Change Control | P0 / MVP | Software Requirements Engineering, Change Control | Review, Inspection | SysDes-110 |
| SRS-143 | Process / Coverage | P0 / MVP | Software Requirements Engineering, Verification | Review, Inspection | SysDes-108, SysDes-109, SysDes-110 |

## 11. Revision History

| Version | Date | Description |
|---|---|---|
| 0.1.0 | 2026-05-13 | Initial ASPICE SWE.1-style SRS derived from early SysDes baseline |
| 0.2.0 | 2026-05-13 | Added inherited upstream coverage via SysDes to show complete chained requirement traceability |
| 0.3.0 | 2026-05-13 | Removed all direct individual SRS-to-upstream-system-requirement links; SRS now traces only to SysDes as the system architectural allocation baseline |
| 0.4.0 | 2026-05-13 | Updated source baseline to SysDes v0.5 and added SRS requirements for SysDes-108 through SysDes-110 derivation and change-control rules |

<!--
Validation:
SRS requirement count: 143
SRS IDs unique: True
SysDes IDs referenced: 110 / 110
Missing SysDes IDs: None
Direct upstream system-requirement IDs referenced by SRS items: 0
Old SYS-XXX IDs remaining: 0
Traceability rule: SRS -> SysDes only; upstream system-requirement coverage is inherited via SysDes.
-->


---

## 13. UI/UX, Material 3, Platform, and Internationalization Software Requirements

This section extends the ASPICE SWE.1 Software Requirements Specification. The source baseline for these requirements is **SysDes only**. This SRS does not link directly to system-requirement IDs.

**SRS-144**: The software shall initialize the Flutter client theme using Material 3 as the baseline UI system.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Design System
- Source SysDes: SysDes-111, SysDes-112
- Verification method: Review, Widget Test

**SRS-145**: The software shall provide a Chanora Design System layer above Material 3 for product-specific semantic states.

- Status: Baseline
- Type: Software Architecture Constraint
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-111, SysDes-112, SysDes-113
- Verification method: Inspection, Widget Test

**SRS-146**: The software shall define semantic tokens for connection states.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-114
- Verification method: Unit Test

**SRS-147**: The software shall define semantic tokens for voice states including speaking, muted, deafened, and push-to-talk active states.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-114
- Verification method: Unit Test

**SRS-148**: The software shall define semantic tokens for latency, packet loss, diagnostics, and error states.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-114
- Verification method: Unit Test

**SRS-149**: The software shall expose design tokens through `ThemeData`, `ColorScheme`, `TextTheme`, component themes, `ThemeExtension`, or equivalent Flutter theming mechanisms.

- Status: Baseline
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Design System
- Source SysDes: SysDes-113, SysDes-114
- Verification method: Inspection, Widget Test

**SRS-150**: Feature screens shall not hardcode product semantic colors, spacing, shape, density, or motion values.

- Status: Baseline
- Type: Software Constraint
- Stage: P0 / MVP
- Allocated to: Flutter Feature Screens
- Source SysDes: SysDes-112, SysDes-113, SysDes-114
- Verification method: Review, Static Inspection

**SRS-151**: The software shall provide an Adaptive Shell that resolves compact, medium, and expanded layout classes.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115
- Verification method: Widget Test, Integration Test

**SRS-152**: The compact layout shall use a single-column primary content structure and mobile-appropriate primary navigation.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115, SysDes-116
- Verification method: Widget Test, Integration Test

**SRS-153**: The medium layout shall support side navigation or equivalent navigation rail behavior where available display width permits.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P1 / Beta
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115, SysDes-116
- Verification method: Widget Test, Integration Test

**SRS-154**: The expanded layout shall support persistent side panes and persistent voice controls where available display width permits.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P2 / Production
- Allocated to: Flutter App Shell
- Source SysDes: SysDes-115, SysDes-116
- Verification method: Integration Test, System Test

**SRS-155**: The software shall keep connection status visible or directly reachable in compact, medium, and expanded layouts.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Connection UI
- Source SysDes: SysDes-116
- Verification method: Integration Test

**SRS-156**: The software shall keep primary voice controls visible or directly reachable in compact, medium, and expanded layouts.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Voice UI
- Source SysDes: SysDes-116
- Verification method: Integration Test

**SRS-157**: The software shall provide screen-reader semantics for critical connection, voice, channel, diagnostics, and settings controls.

- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Design System
- Source SysDes: SysDes-117, SysDes-130
- Verification method: Accessibility Test

**SRS-158**: The software shall provide localized accessibility labels for icon-only controls.

- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Localization Service
- Source SysDes: SysDes-117, SysDes-130
- Verification method: Accessibility Test, Localization Test

**SRS-159**: The software shall not express critical states by color alone; it shall also use text, iconography, shape, position, or semantic labeling.

- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Design System
- Source SysDes: SysDes-117
- Verification method: Widget Test, Accessibility Test

**SRS-160**: The software shall support visible focus indication and logical focus traversal for desktop and tablet keyboard use.

- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P1 / Beta
- Allocated to: Flutter UI
- Source SysDes: SysDes-117
- Verification method: Widget Test, System Test

**SRS-161**: The software shall keep critical actions reachable under increased text scaling.

- Status: Baseline
- Type: Software Accessibility Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI
- Source SysDes: SysDes-117
- Verification method: Accessibility Test

**SRS-162**: The software shall apply platform safe area, display cutout, system bar, virtual keyboard, and desktop window inset constraints through shared shell behavior.

- Status: Baseline
- Type: Software Platform Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Platform Adapter
- Source SysDes: SysDes-118
- Verification method: Platform Test

**SRS-163**: The software shall model Android back navigation as a platform back intent handled by the shell or platform service layer.

- Status: Baseline
- Type: Software Platform Requirement
- Stage: P1 / Beta
- Allocated to: Flutter App Shell, Platform Adapter
- Source SysDes: SysDes-118
- Verification method: Platform Test

**SRS-164**: The software shall model iOS navigation gestures, safe areas, keyboard avoidance, and haptics through platform-aware UI services.

- Status: Baseline
- Type: Software Platform Requirement
- Stage: P1 / Beta
- Allocated to: Flutter App Shell, Platform Adapter
- Source SysDes: SysDes-118
- Verification method: Platform Test

**SRS-165**: The software shall provide a Localization Service for product-owned user-visible strings.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119
- Verification method: Unit Test, Integration Test

**SRS-166**: The software shall externalize product-owned user-visible strings into localization resources or an equivalent mechanism.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119
- Verification method: Inspection

**SRS-167**: The software shall provide English as the baseline product locale.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119, SysDes-131
- Verification method: Localization Test

**SRS-168**: The software shall implement deterministic fallback behavior when a translation key is missing.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Localization Service
- Source SysDes: SysDes-119, SysDes-131
- Verification method: Unit Test

**SRS-169**: The software shall allow additional locales to be added without changing protocol, audio, state synchronization, or storage modules.

- Status: Baseline
- Type: Software Maintainability Requirement
- Stage: P1 / Beta
- Allocated to: Localization Service, Flutter UI
- Source SysDes: SysDes-119
- Verification method: Review, Inspection

**SRS-170**: The software shall display server-provided server names, channel names, client nicknames, and text messages as content rather than translating them.

- Status: Baseline
- Type: Software Functional Requirement
- Stage: P0 / MVP
- Allocated to: Flutter UI, Protocol DTOs
- Source SysDes: SysDes-120
- Verification method: Integration Test

**SRS-171**: The software shall preserve Unicode text received from compatible servers through protocol adapter, bridge DTO, state store, and UI rendering paths.

- Status: Baseline
- Type: Software Data Requirement
- Stage: P0 / MVP
- Allocated to: Protocol Adapter, Bridge, Rust Core, Flutter UI
- Source SysDes: SysDes-120, SysDes-121
- Verification method: Integration Test

**SRS-172**: The software shall use UTF-8 internally for cross-layer text DTOs unless a boundary adapter requires conversion.

- Status: Baseline
- Type: Software Interface Requirement
- Stage: P0 / MVP
- Allocated to: Bridge, Rust Core, Storage, Diagnostics, Protocol Adapter
- Source SysDes: SysDes-121
- Verification method: Inspection, Integration Test

**SRS-173**: The software shall isolate non-UTF-8 or platform-specific string conversion in boundary adapters.

- Status: Baseline
- Type: Software Interface Requirement
- Stage: P1 / Beta
- Allocated to: Protocol Adapter, Platform Adapter, Bridge
- Source SysDes: SysDes-122
- Verification method: Inspection, Integration Test

**SRS-174**: The software shall not corrupt multilingual Unicode content in logs or diagnostic exports unless redaction intentionally removes sensitive content.

- Status: Baseline
- Type: Software Data Integrity Requirement
- Stage: P0 / MVP
- Allocated to: Diagnostics, Storage
- Source SysDes: SysDes-121, SysDes-124
- Verification method: Test, Audit

**SRS-175**: The software shall support bidirectional text display where the Flutter platform text engine supports it.

- Status: Baseline
- Type: Software Internationalization Requirement
- Stage: P2 / Production
- Allocated to: Flutter UI
- Source SysDes: SysDes-123
- Verification method: Localization Test

**SRS-176**: The software shall use locale-aware formatting for user-visible dates, times, numbers, and diagnostic timestamps.

- Status: Baseline
- Type: Software Internationalization Requirement
- Stage: P1 / Beta
- Allocated to: Localization Service, Diagnostics UI
- Source SysDes: SysDes-123, SysDes-124
- Verification method: Localization Test

**SRS-177**: The software shall keep diagnostic event keys, codes, and machine-readable fields language-neutral.

- Status: Baseline
- Type: Software Diagnostics Requirement
- Stage: P1 / Beta
- Allocated to: Diagnostics
- Source SysDes: SysDes-124
- Verification method: Inspection, Test

**SRS-178**: The software shall allow user-facing diagnostic descriptions to be localized independently of machine-readable diagnostic fields.

- Status: Baseline
- Type: Software Diagnostics Requirement
- Stage: P1 / Beta
- Allocated to: Diagnostics, Localization Service
- Source SysDes: SysDes-124
- Verification method: Inspection, Localization Test

**SRS-179**: The software shall maintain UI/UX guideline, design token, component catalog, adaptive layout, and platform behavior documents as downstream design baselines.

- Status: Baseline
- Type: Software Documentation Requirement
- Stage: P1 / Beta
- Allocated to: UX, Software Engineering
- Source SysDes: SysDes-125
- Verification method: Review

**SRS-180**: The software requirements baseline shall derive requirements only from `SysDes-XXX` sources.

- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Engineering
- Source SysDes: SysDes-126, SysDes-127
- Verification method: Inspection

**SRS-181**: The SRS shall not use direct upstream system-requirement source fields or direct system-requirement trace links.

- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Engineering
- Source SysDes: SysDes-127
- Verification method: Inspection

**SRS-182**: The software architecture shall derive architecture items only from `SRS-XXX` sources.

- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Architecture
- Source SysDes: SysDes-128
- Verification method: Inspection

**SRS-183**: The software detailed design shall derive detailed design items only from `SAD-XXX` sources.

- Status: Baseline
- Type: Traceability Requirement
- Stage: P0 / MVP
- Allocated to: Software Design
- Source SysDes: SysDes-129
- Verification method: Inspection

**SRS-184**: Theme, localization, and initial platform adaptation shall be initialized before feature screens render user-visible content.

- Status: Baseline
- Type: Software Dynamic Behavior Requirement
- Stage: P0 / MVP
- Allocated to: Flutter App Shell, Design System, Localization Service, Platform Adapter
- Source SysDes: SysDes-132
- Verification method: Integration Test

## 14. Updated SRS to SysDes Coverage Statement

| SysDes Range | SRS Coverage |
|---|---|
| SysDes-001 through SysDes-110 | Covered by inherited SRS baseline `SRS-001` through `SRS-143` |
| SysDes-111 through SysDes-132 | Covered by `SRS-144` through `SRS-184` |

## 15. Change History

| Version | Date | Description |
|---|---|---|
| 0.5.0 | 2026-05-14 | Added Material 3, design system, adaptive layout, accessibility, platform behavior, localization, Unicode, diagnostics localization, and strict downstream traceability software requirements. |

---

## 16. Platform Baseline and Product Decision Software Requirements

**SRS-185**: The software shall define iOS 13 as the minimum iOS runtime deployment baseline unless approved platform constraints raise the minimum version.

- Status: Baseline Candidate
- Type: Software Platform Requirement
- Stage: P0 / MVP
- Allocated to: iOS Build Configuration, Platform Adapter
- Source SysDes: SysDes-133
- Verification method: Platform Test, Release Inspection

**SRS-186**: The iOS/iPadOS release build process shall require Xcode 26 or later and the iOS 26 / iPadOS 26 SDK or later for App Store Connect upload on or after 2026-04-28, unless Apple publishes a newer applicable upload requirement before upload.

- Status: Baseline Candidate
- Type: Software Release Requirement
- Stage: P0 / MVP
- Allocated to: iOS Build Configuration, Release Pipeline
- Source SysDes: SysDes-134
- Verification method: Release Inspection

**SRS-187**: The software shall define Android API 24 as the minimum Android runtime baseline unless approved platform constraints raise the minimum version.

- 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

**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

## 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` |


## 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. |