From 3200312b0ddca8cfc038dfe676c442a86f24a170 Mon Sep 17 00:00:00 2001 From: Edison Jwa Date: Sat, 23 May 2026 06:52:24 +0900 Subject: [PATCH] docs: add baseline references and workspace tasks --- docs/additional_docs/material3-guideline.md | 93 + docs/additional_docs/srs.md | 2850 +++++++++++++++++ docs/additional_docs/sysdes.md | 3047 +++++++++++++++++++ docs/additional_docs/sysrs.md | 2007 ++++++++++++ justfile | 56 +- 5 files changed, 8017 insertions(+), 36 deletions(-) create mode 100644 docs/additional_docs/material3-guideline.md create mode 100644 docs/additional_docs/srs.md create mode 100644 docs/additional_docs/sysdes.md create mode 100644 docs/additional_docs/sysrs.md diff --git a/docs/additional_docs/material3-guideline.md b/docs/additional_docs/material3-guideline.md new file mode 100644 index 0000000..38b93db --- /dev/null +++ b/docs/additional_docs/material3-guideline.md @@ -0,0 +1,93 @@ + +# Chanora UI/UX Guideline — Material 3 Baseline + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Lifecycle support:** Supports SysDes, SRS, SAD, SDD, and Verification +**Design baseline:** Material 3 + Chanora Design System + +**Repo path:** `docs/ui-ux/material3-guideline.md` --- + +## 1. Purpose + +This guideline defines the UI and UX baseline for the Chanora Flutter application. Chanora shall use Material 3 as the foundation, but product-specific voice, channel, connection, latency, diagnostics, platform, and accessibility semantics shall be expressed through Chanora Design System components and tokens. + +## 2. Core UI Principles + +| Principle | Requirement | +|---|---| +| Voice-first control | Mute, deaf, push-to-talk, current channel, and input status must be visible or directly reachable. | +| Connection awareness | Connected, connecting, reconnecting, disconnected, and error states must be visible. | +| Adaptive layout | Layout must adapt by window class rather than hardcoding behavior by platform name. | +| Accessibility baseline | Critical controls must have semantics, focus behavior, text scaling support, and non-color-only status expression. | +| Platform respect | Permission, safe area, keyboard, back, haptic, and audio-route behavior must follow platform expectations. | +| Localization-ready | Product-owned strings must be localized; server-provided content must be displayed as content. | + +## 3. Primary Screens + +| Screen | Stage | Purpose | +|---|---|---| +| Home | P0 | Recent servers, bookmarks, manual connect entry | +| Connect | P0 | Host, port, nickname, password, identity selection | +| Server | P0 | Channel tree, clients, connection status, current channel | +| Voice | P0 | Voice controls, input level, device summary | +| Chat | P1 | Channel text messages | +| Settings | P0 | Audio, UI, localization, platform behavior, shortcuts | +| Diagnostics | P0 | Status, redacted export, troubleshooting information | + +## 4. Interaction Rules + +| Area | Rule | +|---|---| +| Channel tree | Select, expand/collapse, join, context menu, keyboard traversal | +| Client tile | Show speaking, mute/deaf, volume, latency when available | +| Voice controls | Must be reachable with touch, mouse, and keyboard | +| Diagnostics | Export must require explicit user action and show redaction notice | +| Settings | Destructive or permission-changing actions require clear confirmation or explanation | +| Text entry | Chat input must respect IME and keyboard safe areas | + +## 5. Motion Rules + +| Scenario | Allowed behavior | +|---|---| +| Page transition | Minimal fade or shared-axis style transition | +| Speaking indicator | Subtle pulse, disabled or simplified under reduced motion | +| Reconnect banner | Clear state transition without disruptive animation | +| Layout change | Resize/reflow smoothly where possible | +| Error state | Immediate, clear, non-color-only feedback | + +## 6. Accessibility Rules + +| Rule | Baseline | +|---|---| +| Minimum target | Critical controls should meet a 48dp target where practical. | +| Semantics | Icon-only controls require labels. | +| Focus | Desktop and tablet keyboard use require visible focus. | +| State expression | Critical states require more than color. | +| Text scale | Critical controls remain reachable under increased text size. | +| Reduced motion | Non-essential animation is reduced or disabled. | + +## 7. Internationalization UX + +Product strings are localized. Server-provided server names, channel names, nicknames, and messages are not translated. Mixed-language and bidirectional text must be rendered as text content and preserved through diagnostics unless redacted. + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial UI/UX guideline for Material 3, adaptive layout, accessibility, platform behavior, and i18n. | + + +## 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 to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/additional_docs/srs.md b/docs/additional_docs/srs.md new file mode 100644 index 0000000..6b11506 --- /dev/null +++ b/docs/additional_docs/srs.md @@ -0,0 +1,2850 @@ +# Chanora SRS — Software Requirements Specification + +**Product name:** Chanora +**Document type:** SRS / Software Requirements Specification +**ASPICE process alignment:** SWE.1 Software Requirements Analysis +**Version:** 0.9.9 +**Status:** Baseline Candidate +**Source baseline:** `chanora_SysDes_ASPICE_SYS3_v0.5.md` +**Architecture baseline:** Flutter + Rust Core + `tsclientlib` protocol adapter +**Target client platforms:** Windows, macOS, Linux, iOS, Android + +**Repo path:** `docs/requirements/srs.md` --- + +## 1. Purpose + +This SRS defines the software requirements for the Chanora client application. It is derived from the approved SysDes baseline and is written in the style of ASPICE SWE.1 Software Requirements Analysis. + +The SRS covers all SysDes design items that require implementation or enablement by the software team, including software-facing constraints from hardware, operating system services, networks, external compatible servers, deployment, diagnostics, and verification. + +Chanora remains an application, not an operating system. The software requirements specify what the Chanora software shall do and what operating-environment assumptions or interfaces it shall handle. + +## 2. ASPICE SWE.1 Alignment + +This document addresses the following SWE.1 concerns: + +- Specify software requirements from system requirements and system architecture. +- Structure and prioritize software requirements. +- Analyze software requirements for correctness, technical feasibility, and operating-environment impact. +- Establish consistency and traceability to system architecture; system-requirement coverage is inherited through the SysDes allocation chain. +- Communicate the agreed software requirements and impact analysis to affected parties. + +## 3. Software Scope + +### 3.1 In Scope for Software Team + +The software team owns or implements the following software elements: + +- Chanora application container +- Flutter UI layer +- Flutter state layer +- Flutter-Rust bridge layer +- Rust Core and connection manager +- Protocol adapter using `tsclientlib` +- State synchronization engine +- Audio subsystem +- Platform adapter software layer +- Local data store integration +- Secure storage integration layer +- Diagnostics and observability subsystem +- Software-facing deployment scripts and release metadata +- Software verification hooks and test-support tooling + +### 3.2 Out of Scope for Software Implementation + +- Implementing or operating external TeamSpeak 3-compatible servers +- Controlling user-managed network infrastructure, routers, VPNs, NAT devices, or ISPs +- Manufacturing or controlling physical audio hardware +- Changing operating system vendor policies for permissions, secure storage, background execution, or app-store review +- Providing a Chanora-operated backend for MVP voice, channels, or text + +Software shall still handle these items as external interfaces, constraints, assumptions, degraded states, or error conditions where applicable. + +## 4. Requirement Attribute Model + +Each SRS requirement uses the following attributes. + +| Attribute | Meaning | +|---|---| +| SRS ID | Unique software requirement identifier, formatted as `SRS-XXX` | +| Type | Functional, non-functional, interface, platform, security, diagnostics, packaging, analysis, or process classification | +| Stage | Delivery stage: `P0 / MVP`, `P1 / Beta`, `P2 / Production`, or `P3 / Future` | +| Allocated to | Software component or software engineering responsibility | +| Source SysDes | System design item(s) from which the software requirement is directly derived | +| Verification method | Review, inspection, unit test, integration test, system test, platform test, security audit, performance test, demo, or release audit | +| Acceptance criteria | Objective condition for acceptance | +| Analysis | Technical feasibility and impact note | + + +## 4.1 Traceability Policy + +This SRS uses `Source SysDes` as the only direct upstream source field for individual `SRS-XXX` requirements. + +The approved lifecycle chain is: + +```text +System requirements baseline -> SysDes -> SRS +``` + +Therefore: + +- System-level requirements are allocated and justified in SysDes. +- SRS requirements are derived from SysDes design items. +- Individual SRS requirements shall cite `Source SysDes` only. +- Individual SRS requirements shall not directly cite upstream system requirement IDs. +- A missing software need shall be fixed by correcting SysDes first, then deriving or updating SRS. + +## 5. Software Requirements + +### 5.1 SWE.1 Process, Traceability, and Baseline Requirements + +**SRS-001**: The software requirements specification shall define software requirements derived from the approved Chanora SysDes baseline. + +- Type: Process / SWE.1 +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-001 through SysDes-003 +- Verification method: Review +- Acceptance criteria: SRS contains requirement statements, attributes, and source links to SysDes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-002**: Each software requirement shall have a unique `SRS-XXX` identifier, type, stage, software allocation, source SysDes link, verification method, acceptance criteria, and feasibility analysis. + +- Type: Process / Requirement Attribute +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-004 through SysDes-009, SysDes-092 through SysDes-097 +- Verification method: Inspection +- Acceptance criteria: Every SRS item contains the mandatory attribute fields. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-003**: The software requirements shall be structured by software component and cross-cutting concern to support allocation to the software team. + +- Type: Process / Structuring +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039 +- Verification method: Review +- Acceptance criteria: Document sections map to UI, state, bridge, Rust Core, protocol, audio, storage, diagnostics, platform adapters, packaging, and verification hooks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-004**: The software requirements shall be prioritized using P0 / MVP, P1 / Beta, P2 / Production, and P3 / Future stage labels. + +- Type: Process / Prioritization +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110 +- Verification method: Inspection +- Acceptance criteria: Each SRS item contains a stage value. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-005**: The software requirements shall maintain bidirectional traceability to SysDes design items only; upstream system-requirement coverage shall be inherited through the approved SysDes allocation baseline. + +- Type: Process / Traceability +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110 +- Verification method: Inspection +- Acceptance criteria: Coverage matrix shows SysDes-to-SRS and SRS-to-SysDes mappings, without direct links from SRS requirements to upstream system requirement IDs. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-006**: The software requirements shall analyze impact on the operating environment for OS services, audio hardware, network connectivity, external compatible servers, secure storage, deployment, and mobile lifecycle constraints. + +- Type: Process / Operating Environment Analysis +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101 +- Verification method: Review +- Acceptance criteria: Operating environment section identifies software impacts and external dependencies. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-007**: The agreed SRS baseline shall be communicated to SAD, SDD, implementation, and verification authors. + +- Type: Process / Communication +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-003, SysDes-098 through SysDes-100 +- Verification method: Review +- Acceptance criteria: Revision history and communication section identify affected parties and downstream use. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.2 Software Boundary and Architecture Requirements + +**SRS-008**: The software shall be implemented as a cross-platform client application and shall not be implemented or described as an operating system. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Application Container +- Source SysDes: SysDes-002, SysDes-024 +- Verification method: Review +- Acceptance criteria: App metadata, documentation, and architecture describe Chanora as an application. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-009**: The software shall operate without requiring Chanora-operated backend infrastructure for MVP voice, channel, and text operation. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Application Container, Rust Core +- Source SysDes: SysDes-016, SysDes-083 +- Verification method: Review, System Test +- Acceptance criteria: MVP operation connects directly to user-provided compatible servers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-010**: The software shall not implement TeamSpeak-compatible server hosting functionality in MVP. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Application Container, Protocol Adapter +- Source SysDes: SysDes-023, SysDes-082, SysDes-083 +- Verification method: Inspection +- Acceptance criteria: No server-hosting module or process exists in the MVP software. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-011**: The software shall use a layered structure that separates Flutter UI, Flutter State, Bridge, Rust Core, Protocol Adapter, State Sync, Audio, Storage, Diagnostics, and Platform Adapters. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: All Software Components +- Source SysDes: SysDes-010, SysDes-038, SysDes-039, SysDes-041 +- Verification method: Inspection +- Acceptance criteria: Repository and dependency graph show separate modules/crates/layers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-012**: The software shall keep real-time audio processing outside Flutter UI. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Audio Subsystem +- Source SysDes: SysDes-014, SysDes-040, SysDes-071, SysDes-072 +- Verification method: Inspection, Performance Test +- Acceptance criteria: Flutter UI does not process PCM frames or execute real-time DSP. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-013**: The software shall support Windows, macOS, Linux, iOS, and Android through shared Flutter UI, shared Rust Core, and platform-specific adapters. + +- Type: Platform Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Platform Adapters +- Source SysDes: SysDes-012, SysDes-032, SysDes-041 +- Verification method: Build Test +- Acceptance criteria: Target platform builds compile with shared core and platform adapter boundaries. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-014**: The software shall isolate OS-specific permissions, audio routing, lifecycle, secure storage, notification, and packaging behavior behind platform adapter interfaces. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Platform Adapters +- Source SysDes: SysDes-032, SysDes-050, SysDes-080 +- Verification method: Inspection, Integration Test +- Acceptance criteria: Platform-specific code is not embedded directly in core protocol or state modules. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-015**: The software shall provide verification hooks for protocol, state, audio, security, packaging, and platform behavior. + +- Type: Verification Hook +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters +- Source SysDes: SysDes-017, SysDes-102 through SysDes-107 +- Verification method: Inspection, Demo +- Acceptance criteria: Tools, logs, and tests expose evidence for each verification area. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.3 Application Container and Flutter UI Requirements + +**SRS-016**: The software shall provide an application container that initializes Flutter UI, Bridge, Rust Core, platform adapters, storage, and diagnostics in a deterministic startup sequence. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Application Container +- Source SysDes: SysDes-024, SysDes-038, SysDes-041 +- Verification method: Integration Test +- Acceptance criteria: Application startup reaches idle/home state without race-condition crashes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-017**: The software shall provide a home or entry screen for manual connection, recent servers, and saved bookmarks. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SysDes: SysDes-025, SysDes-055, SysDes-059 +- Verification method: UI Test +- Acceptance criteria: User can open connection and bookmark flows from the entry screen. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-018**: The software shall provide a manual connection UI that accepts host or IP address, port, nickname, and optional server password. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SysDes: SysDes-025, SysDes-055, SysDes-059, SysDes-065 +- Verification method: UI Test +- Acceptance criteria: Connection request can be submitted with all required fields and validated before dispatch. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-019**: The software shall display connection states including Disconnected, Connecting, Synchronizing, Connected, Reconnecting, and Failed or equivalent user-safe states. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066 +- Verification method: UI Test, System Test +- Acceptance criteria: UI state follows Rust Core connection events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-020**: The software shall display a server channel tree derived from the Rust Core snapshot and delta events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068 +- Verification method: UI Test, System Test +- Acceptance criteria: Channel tree updates after initial sync and live channel events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-021**: The software shall display online clients in their channels and update the display after client join, leave, and move events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068 +- Verification method: UI Test, System Test +- Acceptance criteria: Client list reflects snapshot and live delta changes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-022**: The software shall visually identify the current user and current channel when the data is available from Rust Core. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-067 +- Verification method: UI Test +- Acceptance criteria: Current user and current channel receive distinct UI state markers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-023**: The software shall provide a channel join interaction that sends a join command through the Bridge and waits for Rust Core or protocol confirmation before treating the join as authoritative. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Bridge, Rust Core +- Source SysDes: SysDes-055, SysDes-069 +- Verification method: System Test +- Acceptance criteria: UI does not finalize current-channel state until confirmation or failure event is received. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-024**: The software shall provide channel text chat UI for message display and message input. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Bridge, Rust Core +- Source SysDes: SysDes-025, SysDes-055, SysDes-070 +- Verification method: UI Test, System Test +- Acceptance criteria: User can send text and receive displayed messages through core events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-025**: The software shall provide a persistent voice control surface for microphone mute, output deaf, push-to-talk state, input level, and current channel. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Audio Subsystem +- Source SysDes: SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072 +- Verification method: UI Test, System Test +- Acceptance criteria: Voice controls are visible and correctly update Rust Core/audio state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-026**: The software shall provide an audio settings UI for input device, output device, Echo Canceller, Automatic Gain Control, Noise Suppression, High-Pass Filter, and related defaults. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Audio Subsystem, Storage +- Source SysDes: SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086 +- Verification method: UI Test +- Acceptance criteria: Settings can be changed and persist across application restart where supported. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-027**: The software shall provide permission explanation UI before requesting microphone, notification, or mobile foreground-service related permissions where platform guidelines allow. + +- Type: Functional / Privacy +- Stage: P0 / MVP +- Allocated to: Flutter UI, Platform Adapters +- Source SysDes: SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 +- Verification method: UI Test, Privacy Review +- Acceptance criteria: Permission explainers appear before or with OS permission prompts as appropriate. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-028**: The software shall provide a diagnostics UI that allows user-initiated diagnostic export and displays user-safe diagnostic status. + +- Type: Functional / Diagnostics +- Stage: P1 / Beta +- Allocated to: Flutter UI, Diagnostics +- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105 +- Verification method: UI Test, Security Audit +- Acceptance criteria: User can export diagnostics only by explicit action, and export is redacted. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-029**: The Flutter UI shall not directly invoke `tsclientlib`, access raw protocol types, or own authoritative server state. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-040, SysDes-052 through SysDes-054, SysDes-057 +- Verification method: Inspection +- Acceptance criteria: Static dependency analysis shows no UI dependency on protocol library types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-030**: The Flutter UI shall subscribe to UI-safe core events and reduce them into presentation state only. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter State +- Source SysDes: SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068 +- Verification method: Inspection, UI Test +- Acceptance criteria: State providers/stores are driven by event DTOs and do not mutate Rust-owned server state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-031**: The software shall provide a typed Flutter-Rust Bridge API for connection, channel, chat, voice, settings, storage, and diagnostics commands. + +- Type: Interface +- Stage: P0 / MVP +- Allocated to: Bridge Layer +- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056 +- Verification method: Integration Test +- Acceptance criteria: Flutter can call each command group through generated or native bindings. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.4 Bridge Requirements + +**SRS-032**: The Bridge shall expose long-lived event streams from Rust Core to Flutter for connection, snapshot, delta, chat, voice, audio device, error, and diagnostic events. + +- Type: Interface +- Stage: P0 / MVP +- Allocated to: Bridge Layer, Rust Core +- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068 +- Verification method: Integration Test +- Acceptance criteria: Flutter receives ordered events and handles stream lifecycle without UI blocking. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-033**: The Bridge shall serialize and deserialize only bridge-safe DTOs and shall not expose Rust internal references or raw protocol library objects. + +- Type: Interface / Safety +- Stage: P0 / MVP +- Allocated to: Bridge Layer +- Source SysDes: SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057 +- Verification method: Inspection, Integration Test +- Acceptance criteria: Generated bindings contain DTOs and value objects only. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-034**: The Bridge shall map Rust Core errors into user-safe Flutter error DTOs. + +- Type: Interface / Error Handling +- Stage: P0 / MVP +- Allocated to: Bridge Layer, Rust Core +- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089 +- Verification method: Integration Test +- Acceptance criteria: Known error cases produce category, message, and recovery hint fields. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-035**: The Bridge shall execute commands asynchronously and shall not block the Flutter UI thread during network, storage, or audio operations. + +- Type: Non-functional +- Stage: P0 / MVP +- Allocated to: Bridge Layer, Rust Core +- Source SysDes: SysDes-027, SysDes-042, SysDes-046, SysDes-085 +- Verification method: Performance Test +- Acceptance criteria: UI remains responsive during connect, reconnect, sync, and diagnostic export. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-036**: The Rust Core shall own authoritative connection lifecycle and server state for each active connection. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Connection state transitions and snapshots are managed in Rust Core. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.5 Rust Core and Connection Management Requirements + +**SRS-037**: The Rust Core shall manage connection actors or equivalent isolated execution contexts for connection-specific commands and events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066 +- Verification method: Inspection, Unit Test +- Acceptance criteria: Each connection has an isolated command/event path. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-038**: The Rust Core shall expose connect, disconnect, reconnect, join channel, send message, audio control, settings, bookmark, identity, and diagnostics commands to the Bridge. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core, Bridge +- Source SysDes: SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076 +- Verification method: Integration Test +- Acceptance criteria: Bridge command suite calls corresponding Rust Core operations. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-039**: The Rust Core shall coordinate protocol, state synchronization, audio, storage, diagnostics, and platform adapter interfaces without leaking implementation details to Flutter. + +- Type: Functional / Architecture +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077 +- Verification method: Inspection +- Acceptance criteria: Core public API exposes stable DTOs and not internal crate types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-040**: The Rust Core shall emit connection status events for Connecting, Synchronizing, Connected, Reconnecting, Disconnected, and failure states. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core, State Sync +- Source SysDes: SysDes-060, SysDes-064, SysDes-066, SysDes-074 +- Verification method: Unit Test, System Test +- Acceptance criteria: Status event sequence matches connection state machine under normal and failure flows. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-041**: The Rust Core shall suppress automatic reconnect after user-triggered disconnect. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-064, SysDes-073, SysDes-074, SysDes-088 +- Verification method: System Test +- Acceptance criteria: User disconnect results in Disconnected state and no reconnect attempt. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-042**: The Rust Core shall apply reconnect policy after recoverable network or protocol failures. + +- Type: Functional / Reliability +- Stage: P0 / MVP +- Allocated to: Rust Core, Protocol Adapter, State Sync +- Source SysDes: SysDes-064, SysDes-066, SysDes-074, SysDes-088 +- Verification method: System Test +- Acceptance criteria: Recoverable failure enters Reconnecting and either recovers or reports safe failure. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-043**: The Rust Core shall rebuild server state from a fresh snapshot after reconnect succeeds. + +- Type: Functional / Reliability +- Stage: P0 / MVP +- Allocated to: Rust Core, State Sync +- Source SysDes: SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088 +- Verification method: System Test, Event Replay Test +- Acceptance criteria: Post-reconnect state is produced from new snapshot, not patched from stale state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-044**: The Protocol Adapter shall be the only software component that directly depends on `tsclientlib`. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Protocol Adapter +- Source SysDes: SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078 +- Verification method: Inspection +- Acceptance criteria: Dependency graph shows `tsclientlib` dependency only in protocol adapter crate/module. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.6 Protocol Adapter Requirements + +**SRS-045**: The Protocol Adapter shall connect to TeamSpeak 3-compatible servers through `tsclientlib` using user-provided host, port, nickname, identity, and optional password. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core +- Source SysDes: SysDes-029, SysDes-043, SysDes-065, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Protocol probe and app can establish a session to a compatible test server. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-046**: The Protocol Adapter shall fetch server information, channel list, client list, and current-user information needed to build the initial snapshot. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, State Sync +- Source SysDes: SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Initial snapshot has server, channel, client, and self-client data. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-047**: The Protocol Adapter shall translate raw `tsclientlib` events into internal protocol events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, State Sync +- Source SysDes: SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Known client, channel, message, voice, and disconnect events map to internal events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-048**: The Protocol Adapter shall translate protocol errors into normalized Chanora protocol errors. + +- Type: Functional / Error Handling +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core +- Source SysDes: SysDes-029, SysDes-043, SysDes-045, SysDes-088 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Known network, authentication, permission, and protocol failures produce normalized errors. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-049**: The Protocol Adapter shall implement channel join commands and report success or failure to Rust Core. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter +- Source SysDes: SysDes-029, SysDes-043, SysDes-069, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Accessible channel join succeeds; denied join reports user-safe failure. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-050**: The Protocol Adapter shall implement channel text message send and receive paths. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter +- Source SysDes: SysDes-029, SysDes-043, SysDes-070, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Text sent from UI reaches server and incoming text reaches core events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-051**: The Protocol Adapter shall implement voice packet send and receive paths required by the audio subsystem. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Audio Subsystem +- Source SysDes: SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104 +- Verification method: Protocol Integration Test, Audio Test +- Acceptance criteria: Encoded outgoing frames are sent and incoming voice packets are delivered to audio pipeline. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-052**: The Protocol Adapter shall expose protocol-probe diagnostics for connection, snapshot, event, text, and voice compatibility. + +- Type: Verification Hook +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Diagnostics +- Source SysDes: SysDes-017, SysDes-035, SysDes-102 +- Verification method: Demo +- Acceptance criteria: Protocol probe produces compatibility output for test servers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-053**: The Protocol Adapter shall support future patching, forking, or replacement of protocol implementation without changing Flutter UI contracts. + +- Type: Maintainability +- Stage: P1 / Beta +- Allocated to: Protocol Adapter, Bridge +- Source SysDes: SysDes-011, SysDes-029, SysDes-043, SysDes-078 +- Verification method: Architecture Review +- Acceptance criteria: Protocol adapter trait/API boundary isolates library-specific types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-054**: The State Synchronization Engine shall maintain a connection state model containing connection status, server info, current user, channels, clients, channel tree, permissions, chat state, and voice state where available. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068 +- Verification method: Unit Test +- Acceptance criteria: State object can represent required snapshot and runtime states. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.7 State Synchronization Requirements + +**SRS-055**: The State Synchronization Engine shall produce a full snapshot event after initial synchronization. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-067 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: SnapshotReady event is emitted after server, channel, and client data are available. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-056**: The State Synchronization Engine shall apply live server events as deterministic deltas. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-068 +- Verification method: Unit Test +- Acceptance criteria: Same event sequence produces same final state and emitted deltas. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-057**: The State Synchronization Engine shall preserve per-connection event ordering. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync, Rust Core +- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-068 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Out-of-order processing is prevented or deterministically handled per connection. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-058**: The State Synchronization Engine shall use reducer functions or equivalent deterministic logic for snapshot, channel, client, chat, voice, and connection events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103 +- Verification method: Unit Test +- Acceptance criteria: Reducer tests cover snapshot and major delta event types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-059**: The State Synchronization Engine shall replace stale server state with a fresh snapshot after reconnect. + +- Type: Functional / Reliability +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103 +- Verification method: Event Replay Test, System Test +- Acceptance criteria: Reconnect tests confirm old channel/client state is replaced. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-060**: The State Synchronization Engine shall tolerate malformed or unexpected protocol events without crashing the application. + +- Type: Reliability +- Stage: P0 / MVP +- Allocated to: State Sync, Rust Core +- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103 +- Verification method: Unit Test, Fuzz/Negative Test +- Acceptance criteria: Malformed event tests produce safe error or ignored event behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-061**: The State Synchronization Engine shall provide replayable event recording hooks for debugging state synchronization. + +- Type: Verification Hook +- Stage: P1 / Beta +- Allocated to: State Sync, Diagnostics +- Source SysDes: SysDes-030, SysDes-035, SysDes-079, SysDes-103 +- Verification method: Demo +- Acceptance criteria: Recorded event stream can be replayed to reproduce state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-062**: The Audio Subsystem shall coordinate audio capture, preprocessing, audio processing, Opus-compatible encoding, voice packet handoff, receive decoding, jitter buffering, per-user controls, mixing, and playback. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104 +- Verification method: Audio Integration Test +- Acceptance criteria: End-to-end voice send and receive operate through the audio subsystem. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.8 Audio Subsystem Requirements + +**SRS-063**: The Audio Subsystem shall process outgoing microphone PCM frames before encoding. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Capture pipeline accepts PCM frames and outputs encoded voice frames when gate allows. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-064**: The Audio Subsystem shall apply a High-Pass Filter before voice encoding when enabled. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: Low-frequency attenuation is measurable in HPF test cases. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-065**: The Audio Subsystem shall apply Noise Suppression before voice encoding when enabled. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: Stationary-noise reduction is measurable or verified by backend tests. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-066**: The Audio Subsystem shall apply Echo Canceller before voice encoding when enabled and when playback reference audio is available or the selected backend provides equivalent behavior. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: Echo cancellation backend can use playback reference or platform equivalent. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-067**: The Audio Subsystem shall apply Automatic Gain Control before voice encoding when enabled. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: AGC normalizes input gain without unacceptable clipping under test cases. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-068**: The Audio Subsystem shall expose enable/disable settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. + +- Type: Functional / Settings +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI, Storage +- Source SysDes: SysDes-031, SysDes-033, SysDes-056, SysDes-081 +- Verification method: UI Test, Unit Test +- Acceptance criteria: Changing each setting updates Rust Core/audio configuration and persists locally. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-069**: The Audio Subsystem shall support conservative default audio processing configuration per platform. + +- Type: Non-functional / Audio +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-013, SysDes-031, SysDes-081, SysDes-086 +- Verification method: Review, Audio Test +- Acceptance criteria: Default configuration is documented and validated for each supported platform. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-070**: The Audio Subsystem shall provide an audio processing backend abstraction supporting platform-native and Rust-based implementations. + +- Type: Architecture / Audio +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-031, SysDes-032, SysDes-058, SysDes-081 +- Verification method: Inspection +- Acceptance criteria: Backend trait/interface allows substitution without Flutter UI changes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-071**: The Audio Subsystem shall encode outgoing voice using an Opus-compatible encoder. + +- Type: Functional / Audio Codec +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: PCM input produces decodable Opus-compatible encoded frames. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-072**: The Audio Subsystem shall decode incoming voice using an Opus-compatible decoder. + +- Type: Functional / Audio Codec +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Incoming encoded frames produce expected PCM output. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-073**: The Audio Subsystem shall use jitter buffering for incoming voice packets. + +- Type: Functional / Audio Playback +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Packet jitter test produces continuous playback without buffer instability within defined limits. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-074**: The Audio Subsystem shall support per-user mute during playback. + +- Type: Functional / Audio Playback +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI +- Source SysDes: SysDes-031, SysDes-058, SysDes-072 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Muted remote user is not mixed into output. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-075**: The Audio Subsystem shall support per-user volume during playback. + +- Type: Functional / Audio Playback +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Flutter UI, Storage +- Source SysDes: SysDes-031, SysDes-033, SysDes-058, SysDes-072 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Remote user gain changes affect only that user and persist where applicable. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-076**: The Audio Subsystem shall mix decoded incoming voice streams before playback. + +- Type: Functional / Audio Playback +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Multiple incoming streams are mixed into a playback stream without clipping beyond defined limits. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-077**: The Audio Subsystem shall implement microphone mute as a gate that prevents local voice transmission. + +- Type: Functional / Voice Control +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Rust Core, Flutter UI +- Source SysDes: SysDes-031, SysDes-063, SysDes-071 +- Verification method: System Test +- Acceptance criteria: When muted, no outgoing voice packets are sent. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-078**: The Audio Subsystem shall implement output deaf as a gate that prevents incoming voice playback. + +- Type: Functional / Voice Control +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Rust Core, Flutter UI +- Source SysDes: SysDes-031, SysDes-063, SysDes-072 +- Verification method: System Test +- Acceptance criteria: When deafened, incoming voice is not played. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-079**: The Audio Subsystem shall implement push-to-talk gating before outgoing voice packet transmission. + +- Type: Functional / Voice Control +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI +- Source SysDes: SysDes-031, SysDes-063, SysDes-071 +- Verification method: System Test +- Acceptance criteria: Outgoing voice is sent only when push-to-talk is active unless configured otherwise. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-080**: The Audio Subsystem shall provide input level metering to Rust Core or Flutter through UI-safe events. + +- Type: Functional / Voice Metering +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI +- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-071 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Input level meter changes with microphone input. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-081**: The Audio Subsystem shall provide speaking indicator events for local and remote users where available. + +- Type: Functional / Voice Metering +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, State Sync, Flutter UI +- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-072 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Speaking indicators activate according to local gate and remote voice activity. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-082**: The Audio Subsystem shall recover from audio route or device changes by reconfiguring audio streams or entering a user-safe blocked/degraded state. + +- Type: Reliability / Audio +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-032, SysDes-050, SysDes-075, SysDes-086 +- Verification method: Platform Integration Test +- Acceptance criteria: Device disconnect/change does not crash the app and reports clear status. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-083**: The Audio Subsystem shall provide audio loopback and processing test hooks for verification. + +- Type: Verification Hook +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Diagnostics +- Source SysDes: SysDes-017, SysDes-035, SysDes-104 +- Verification method: Demo +- Acceptance criteria: Audio test tools can exercise capture, processing, encode/decode, jitter, mixer, and playback paths. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-084**: The software shall persist bookmarks in local non-secret storage. + +- Type: Functional / Storage +- Stage: P0 / MVP +- Allocated to: Storage +- Source SysDes: SysDes-033, SysDes-036, SysDes-049 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Bookmark create, update, delete, and list operations persist across restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.9 Storage and Secure Storage Requirements + +**SRS-085**: The software shall persist recent servers in local non-secret storage. + +- Type: Functional / Storage +- Stage: P1 / Beta +- Allocated to: Storage +- Source SysDes: SysDes-033, SysDes-036, SysDes-049 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Recent server entries are stored and displayed after restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-086**: The software shall persist audio settings in local non-secret storage. + +- Type: Functional / Storage +- Stage: P0 / MVP +- Allocated to: Storage, Audio Subsystem +- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Audio settings survive application restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-087**: The software shall persist UI settings in local non-secret storage. + +- Type: Functional / Storage +- Stage: P1 / Beta +- Allocated to: Storage, Flutter UI +- Source SysDes: SysDes-033, SysDes-036, SysDes-049 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: UI settings survive application restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-088**: The software shall persist per-user volume and per-user mute preferences where applicable. + +- Type: Functional / Storage +- Stage: P1 / Beta +- Allocated to: Storage, Audio Subsystem +- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-072 +- Verification method: Unit Test +- Acceptance criteria: Preferences are stored by server/user identity keys where available. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-089**: The software shall use SQLite or an equivalent embedded data store for non-secret local data. + +- Type: Architecture / Storage +- Stage: P0 / MVP +- Allocated to: Storage +- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-091 +- Verification method: Inspection +- Acceptance criteria: Storage implementation uses an embedded local data store and migration mechanism. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-090**: The software shall access platform secure storage only through a secure storage provider abstraction. + +- Type: Interface / Security +- Stage: P0 / MVP +- Allocated to: Storage, Platform Adapters +- Source SysDes: SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105 +- Verification method: Inspection, Security Audit +- Acceptance criteria: Secrets are read/written through secure storage interface only. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-091**: The software shall store identity private keys using platform secure storage and shall not persist them in plaintext files. + +- Type: Security +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage +- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Filesystem and database inspection shows no plaintext private keys. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-092**: The software shall store server passwords using platform secure storage and shall not persist them in plaintext logs or non-secret database fields. + +- Type: Security +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage, Diagnostics +- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Password values are redacted from logs and absent from non-secret storage. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-093**: The software shall redact secrets before writing diagnostic logs or diagnostic exports. + +- Type: Security / Diagnostics +- Stage: P0 / MVP +- Allocated to: Diagnostics, Storage +- Source SysDes: SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Diagnostic redaction tests cover private keys, passwords, tokens, and known secret fields. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-094**: The software shall validate user input before passing values to protocol operations or storage operations. + +- Type: Security +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage +- Source SysDes: SysDes-045, SysDes-065, SysDes-089, SysDes-105 +- Verification method: Unit Test, Security Test +- Acceptance criteria: Invalid host, port, nickname, password, and path-like values are rejected or sanitized safely. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-095**: The software shall produce structured diagnostic logs for connection, protocol, state, audio, storage, platform, and release-relevant events. + +- Type: Diagnostics +- Stage: P0 / MVP +- Allocated to: Diagnostics +- Source SysDes: SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105 +- Verification method: Inspection, Demo +- Acceptance criteria: Logs contain structured fields and categories without secrets. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.10 Diagnostics, Security, and Privacy Requirements + +**SRS-096**: The software shall support user-initiated diagnostic export. + +- Type: Diagnostics +- Stage: P1 / Beta +- Allocated to: Diagnostics, Flutter UI +- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105 +- Verification method: Demo, Security Audit +- Acceptance criteria: Export is available only after user action and output is redacted. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-097**: The software shall provide protocol event recording in development or diagnostics mode. + +- Type: Diagnostics / Verification Hook +- Stage: P1 / Beta +- Allocated to: Diagnostics, Protocol Adapter, State Sync +- Source SysDes: SysDes-035, SysDes-079, SysDes-102, SysDes-103 +- Verification method: Demo +- Acceptance criteria: Recorded protocol/core event file can be generated in diagnostics mode. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-098**: The software shall provide event replay support for state synchronization debugging. + +- Type: Diagnostics / Verification Hook +- Stage: P1 / Beta +- Allocated to: Diagnostics, State Sync +- Source SysDes: SysDes-035, SysDes-079, SysDes-103 +- Verification method: Demo +- Acceptance criteria: Event replay can rebuild expected state from a recorded sequence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-099**: The software shall provide audio diagnostics for capture, processing backend, codec, jitter buffer, mixer, playback, and route/device status. + +- Type: Diagnostics / Verification Hook +- Stage: P1 / Beta +- Allocated to: Diagnostics, Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-035, SysDes-075, SysDes-086, SysDes-104 +- Verification method: Demo +- Acceptance criteria: Audio diagnostics report current pipeline and device status. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-100**: The software shall provide network diagnostics for connection status, reconnect attempts, latency where available, and protocol-relevant network failures. + +- Type: Diagnostics / Reliability +- Stage: P1 / Beta +- Allocated to: Diagnostics, Rust Core, Protocol Adapter +- Source SysDes: SysDes-035, SysDes-074, SysDes-088, SysDes-102 +- Verification method: Demo +- Acceptance criteria: Diagnostics include network and reconnect evidence without secrets. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-101**: The software shall minimize personal data collection in MVP. + +- Type: Privacy +- Stage: P0 / MVP +- Allocated to: All Software Components +- Source SysDes: SysDes-090, SysDes-105 +- Verification method: Privacy Review +- Acceptance criteria: MVP does not collect telemetry or upload personal diagnostics automatically. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-102**: The software shall not automatically upload diagnostics in MVP. + +- Type: Privacy / Constraint +- Stage: P0 / MVP +- Allocated to: Diagnostics +- Source SysDes: SysDes-090, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: No automatic diagnostic upload endpoint or job is present. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-103**: The software shall display user-safe errors without raw internal stack traces. + +- Type: Security / Error Handling +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Bridge, Diagnostics +- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089 +- Verification method: UI Test, Security Review +- Acceptance criteria: Runtime errors displayed to users contain safe message and recovery hint only. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-104**: The software shall provide a platform adapter interface for microphone capture. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071 +- Verification method: Platform Integration Test +- Acceptance criteria: Each supported platform can provide captured PCM frames to the audio pipeline. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.11 Platform Adapter Requirements + +**SRS-105**: The software shall provide a platform adapter interface for speaker/headphone playback. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072 +- Verification method: Platform Integration Test +- Acceptance criteria: Each supported platform can play mixed PCM frames from the audio pipeline. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-106**: The software shall provide a platform adapter interface for audio device enumeration and selection where supported. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem, Flutter UI +- Source SysDes: SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075 +- Verification method: Platform Integration Test +- Acceptance criteria: Input/output device lists are exposed and selection changes are applied or reported as unsupported. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-107**: The software shall provide a platform adapter interface for audio route changes. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086 +- Verification method: Platform Integration Test +- Acceptance criteria: Route changes are emitted to Rust Core/Flutter and handled safely. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-108**: The software shall provide a platform adapter interface for microphone permission requests. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Flutter UI +- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 +- Verification method: Platform Integration Test +- Acceptance criteria: Permission state is queryable and request flow triggers platform permission behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-109**: The software shall provide a platform adapter interface for notification permission requests where required. + +- Type: Interface / Platform +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Flutter UI +- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 +- Verification method: Platform Integration Test +- Acceptance criteria: Notification permission flow is available on platforms requiring it. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-110**: The iOS software shall integrate with AVAudioSession or equivalent platform audio session behavior for foreground voice sessions. + +- Type: Platform / iOS +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 +- Verification method: iOS Integration Test +- Acceptance criteria: iOS foreground voice session handles capture, playback, route change, and interruption callbacks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-111**: The Android software shall integrate with foreground service behavior for active voice sessions. + +- Type: Platform / Android +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 +- Verification method: Android Integration Test +- Acceptance criteria: Android active voice session uses foreground service behavior according to platform rules. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-112**: The Android software shall handle audio focus and Bluetooth route changes where platform APIs expose them. + +- Type: Platform / Android +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 +- Verification method: Android Integration Test +- Acceptance criteria: Audio focus loss/gain and Bluetooth route events are handled safely. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-113**: The desktop software shall support validated audio backends for Windows, macOS, and Linux. + +- Type: Platform / Desktop +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 +- Verification method: Desktop Integration Test +- Acceptance criteria: Desktop audio capture/playback works on representative Windows, macOS, and Linux systems. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-114**: The software shall provide platform adapter lifecycle events for foreground/background, app resume, app suspend, audio interruption, and shutdown where supported. + +- Type: Interface / Platform +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Rust Core, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 +- Verification method: Platform Integration Test +- Acceptance criteria: Lifecycle events reach Rust Core and do not corrupt connection/audio state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-115**: The software shall document unsupported or degraded platform behaviors through user-safe status and diagnostics. + +- Type: Platform / Diagnostics +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Diagnostics, Flutter UI +- Source SysDes: SysDes-050, SysDes-075, SysDes-084, SysDes-090 +- Verification method: Review, Demo +- Acceptance criteria: Unsupported device/permission/lifecycle cases are visible in UI or diagnostics. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-116**: The software shall produce build artifacts for Windows installer packaging. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: Windows installer artifact is generated from configured CI or release script. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.12 Packaging and Release Requirements + +**SRS-117**: The software shall produce signed and notarized macOS release builds for production release. + +- Type: Packaging +- Stage: P2 / Production +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build/Release Audit +- Acceptance criteria: macOS release process includes signing and notarization evidence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-118**: The software shall produce Linux release packages using the selected supported package formats. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: At least one selected Linux package format is generated. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-119**: The software shall produce Android AAB release builds. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: Android AAB build succeeds with release configuration. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-120**: The software shall produce iOS TestFlight and App Store release builds when signing assets are available. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: iOS archive/export succeeds on supported macOS build environment. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-121**: The software release metadata and in-app wording shall not imply official TeamSpeak affiliation. + +- Type: Legal / Product Constraint +- Stage: P0 / MVP +- Allocated to: Application Container, Flutter UI, Deployment Scripts +- Source SysDes: SysDes-005, SysDes-036, SysDes-091, SysDes-106 +- Verification method: Legal Review, Inspection +- Acceptance criteria: App metadata, UI copy, README, and store text use independent compatibility wording. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-122**: The software shall provide release-build configuration that disables development-only diagnostic capture unless explicitly enabled for test builds. + +- Type: Security / Release +- Stage: P1 / Beta +- Allocated to: Application Container, Diagnostics, Deployment Scripts +- Source SysDes: SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106 +- Verification method: Inspection, Security Review +- Acceptance criteria: Production configuration does not enable protocol recording or verbose logs by default. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-123**: The software shall include or support a protocol probe tool for validating `tsclientlib` adapter behavior against compatible test servers. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Diagnostics +- Source SysDes: SysDes-017, SysDes-035, SysDes-102 +- Verification method: Demo +- Acceptance criteria: Protocol probe reports connection, snapshot, event, text, and voice compatibility evidence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.13 Verification Support Requirements + +**SRS-124**: The software shall include reducer tests and event replay tests for state synchronization. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: State Sync, Diagnostics +- Source SysDes: SysDes-030, SysDes-035, SysDes-103 +- Verification method: Unit Test, Demo +- Acceptance criteria: Reducer and replay tests cover snapshot, delta, reconnect, and malformed-event behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-125**: The software shall include audio loopback and audio processing tests for capture, playback, codec, jitter buffer, mixer, Echo Canceller, AGC, Noise Suppression, and High-Pass Filter. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Diagnostics +- Source SysDes: SysDes-031, SysDes-035, SysDes-104 +- Verification method: Audio Test, Demo +- Acceptance criteria: Audio verification tools execute required audio processing checks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-126**: The software shall include security verification support for secure storage, private-key handling, password handling, input validation, and diagnostic redaction. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: Storage, Diagnostics, Platform Adapters +- Source SysDes: SysDes-034, SysDes-035, SysDes-089, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Security checklist and tests cover required sensitive data behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-127**: The software shall include release verification support for package creation, signing, notarization, app-store builds, and release metadata wording. + +- Type: Verification Support +- Stage: P1 / Beta +- Allocated to: Deployment Scripts, Application Container +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test, Release Audit +- Acceptance criteria: Release verification checklist covers each target platform and metadata review. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-128**: The software shall support MVP acceptance verification demonstrating connection, channel tree, online clients, channel join, send/receive voice, mute, deaf, push-to-talk, required audio processing, channel text, bookmarks, secure storage, and redacted diagnostics. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: All Software Components +- Source SysDes: SysDes-017, SysDes-035, SysDes-102 through SysDes-107 +- Verification method: System Test, Demo +- Acceptance criteria: MVP acceptance test run passes all acceptance checks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-129**: The software shall expose clear user-facing errors when client hardware lacks a usable microphone, output device, CPU capacity, storage, or network interface required for the requested operation. + +- Type: Operating Environment Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-020, SysDes-045, SysDes-086, SysDes-089 +- Verification method: System Test +- Acceptance criteria: Missing hardware/resource conditions produce non-crashing user-safe errors. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.14 Operating Environment and External Interface Requirements + +**SRS-130**: The software shall expose clear user-facing errors when network connectivity prevents server connection or real-time voice operation. + +- Type: Operating Environment Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Protocol Adapter +- Source SysDes: SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088 +- Verification method: System Test +- Acceptance criteria: Network failures produce reconnect or safe error behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-131**: The software shall handle external compatible server permissions, availability, and event behavior as external dependencies and shall not assume administrative control. + +- Type: Operating Environment Constraint +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core, Flutter UI +- Source SysDes: SysDes-023, SysDes-043, SysDes-082, SysDes-102 +- Verification method: System Test +- Acceptance criteria: Permission denied and server unavailable cases produce user-safe outcomes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-132**: The software shall allow server details, credentials, and identity selection to be supplied by the user rather than hardcoding a server environment. + +- Type: Functional / Environment +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage +- Source SysDes: SysDes-019, SysDes-023, SysDes-055, SysDes-065 +- Verification method: UI Test, System Test +- Acceptance criteria: User can provide and save server details without Chanora backend dependency. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-133**: The software shall integrate with OS-level secure storage, permission, audio, network, notification, lifecycle, and app sandboxing policies through platform adapters. + +- Type: Operating Environment Interface +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Rust Core, Flutter UI +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090 +- Verification method: Platform Integration Test +- Acceptance criteria: Platform services are used through approved adapter APIs. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-134**: The software team shall analyze `tsclientlib` feasibility for all MVP protocol features and document unsupported or risky features before MVP acceptance. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Software Requirements Engineering +- Source SysDes: SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102 +- Verification method: Review, Protocol Probe +- Acceptance criteria: Protocol compatibility matrix identifies pass/fail/unknown state for MVP protocol features. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.15 Technical Feasibility and Impact Analysis Requirements + +**SRS-135**: The software team shall analyze real-time audio feasibility on each target platform for capture, playback, required audio processing, and latency. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104 +- Verification method: Review, Audio Test +- Acceptance criteria: Audio feasibility report exists per platform with known limitations and mitigations. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-136**: The software team shall analyze memory growth and define limits for event queues, chat history, logs, audio buffers, and diagnostic bundles. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage +- Source SysDes: SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087 +- Verification method: Review, Performance Test +- Acceptance criteria: Resource limit configuration and tests exist for queues, buffers, and logs. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-137**: The software team shall analyze security and privacy impacts of local secrets, logs, diagnostics, permissions, and release configuration. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Storage, Diagnostics, Platform Adapters, Flutter UI +- Source SysDes: SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 +- Verification method: Security Review, Privacy Review +- Acceptance criteria: Security/privacy analysis documents risks, mitigations, and verification evidence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-138**: The software team shall analyze operating-environment impacts of mobile lifecycle, foreground service behavior, AVAudioSession behavior, route changes, and app store policies. + +- Type: Analysis Requirement +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Audio Subsystem, Deployment Scripts +- Source SysDes: SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106 +- Verification method: Review, Platform Test +- Acceptance criteria: Mobile lifecycle analysis documents behavior and limitations. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-139**: The software requirements baseline shall account for SysDes-037: SE-19 Engineering Process and Evidence shall be a defined system element in the Chanora architecture with responsibility for: Architecture reviews, traceability records, verification evidence, compatibility matrix, open decisions, and downstream SRS/SAD/SDD/Verification artifacts. + +- Type: Traceability / Coverage +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-037 +- Verification method: Review +- Acceptance criteria: SysDes-037 is represented in SRS traceability and downstream software analysis. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-140**: The software requirements baseline shall account for SysDes-062: The permission-blocked mode shall prevent unsafe voice operations while preserving user visibility into corrective actions. + +- Type: Traceability / Coverage +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-062 +- Verification method: Review +- Acceptance criteria: SysDes-062 is represented in SRS traceability and downstream software analysis. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-141**: The SRS shall use SysDes design items as the mandatory architectural allocation source for every software requirement. + +- Type: Process / Traceability +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-108, SysDes-109 +- Verification method: Review, Inspection +- Acceptance criteria: Every SRS requirement has a `Source SysDes` field and no individual SRS requirement uses an upstream system-requirement ID as its direct source. +- Analysis: Feasible because SysDes v0.5 defines the downstream derivation rule and software-impacting allocation layer. +- Owner: Software Team + +**SRS-142**: If the software team identifies a required software behavior, constraint, or interface that cannot be derived from an existing SysDes design item, the SRS shall not be baselined until the SysDes is revised. + +- Type: Process / Change Control +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering, Change Control +- Source SysDes: SysDes-110 +- Verification method: Review, Inspection +- Acceptance criteria: Change-control records show SysDes-first correction for any new software requirement source gap. +- Analysis: Feasible through requirements review and change-control workflow before SRS baseline. +- Owner: Software Team + +**SRS-143**: The SRS shall maintain a SysDes-to-SRS coverage matrix for all SysDes items that require software implementation, software enablement, software-facing constraint handling, or software verification support. + +- Type: Process / Coverage +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering, Verification +- Source SysDes: SysDes-108, SysDes-109, SysDes-110 +- Verification method: Review, Inspection +- Acceptance criteria: Coverage matrix shows that each software-impacting SysDes item is covered by one or more SRS requirements, or explicitly identified as non-software-owned. +- Analysis: Feasible with the SysDes metadata register and SRS coverage matrix. +- Owner: Software Team + + +## 6. Operating Environment Impact Analysis + +| Environment element | Software impact | Related SRS | +|---|---|---| +| Client hardware | Software must detect or report missing microphone, output device, CPU/storage/network resource constraints. | SRS-130 | +| OS services | Software must integrate with permissions, secure storage, audio stack, lifecycle, notifications, and sandbox policies through platform adapters. | SRS-105 through SRS-116, SRS-134 | +| Network | Software must handle unreachable servers, recoverable failures, reconnect, and user-safe errors. | SRS-131 | +| External compatible server | Software must treat server permissions, availability, authentication, events, and protocol behavior as external dependencies. | SRS-132, SRS-133 | +| Audio devices | Software must handle input/output device selection, route changes, and degraded audio states. | SRS-107 through SRS-110 | +| Mobile lifecycle | Software must handle foreground voice sessions, audio interruption, route changes, and background policy limits. | SRS-111 through SRS-115, SRS-139 | +| Secure storage | Software must use platform secure storage through an abstraction and avoid plaintext secret persistence. | SRS-091 through SRS-095 | +| Deployment environment | Software must produce platform-specific release packages and safe release metadata. | SRS-117 through SRS-123 | + +## 7. Software Requirement Analysis Summary + +| Analysis area | Result | Follow-up artifact | +|---|---|---| +| Correctness | Requirements are derived from SysDes and structured by software component. | SAD / SDD | +| Technical feasibility | Feasibility checks are required for `tsclientlib`, audio processing, mobile lifecycle, resource limits, and security. | Analysis report, SAD, SDD | +| Testability | Each requirement contains verification method and acceptance criteria. | Verification plan | +| Operating environment impact | OS services, hardware, network, server, deployment, and mobile lifecycle impacts are captured. | Platform design, Verification plan | +| Traceability | Every SysDes design item is mapped to one or more SRS requirements; direct SRS-to-upstream-system-requirement links are intentionally not used. | Traceability matrix | +| Communication | SRS baseline shall be communicated downstream to SWE.2/SAD, SWE.3/SDD, and SWE.6/Verification. | Review evidence | + +## 8. SRS to SWE Lifecycle Handoff + +| Downstream process/artifact | SRS handoff content | +|---|---| +| SWE.2 / SAD | Software components, interfaces, static and dynamic architecture constraints, NFR allocation, security and platform boundaries | +| SWE.3 / SDD | DTOs, API contracts, state machines, reducers, storage schema, audio pipeline module design, protocol adapter interfaces, error models | +| SWE.4 | Unit verification needs for reducers, audio processors, protocol mappers, storage logic, redaction, validation, and utility functions | +| SWE.5 | Software integration verification for Flutter-Bridge-Core, protocol-state, audio-platform, storage-secure-store, diagnostics-export, and packaging flows | +| SWE.6 | Integrated software verification against this SRS including MVP acceptance and platform compatibility | + +## 9. SysDes to SRS Coverage Matrix + +Coverage summary: 110 / 110 SysDes design items are covered by one or more SRS requirements. + +Software-impacting SysDes items: 95 / 110. All software-impacting SysDes items are represented in the SRS coverage below. Non-software design items are covered as software assumptions, external-interface constraints, verification hooks, or process controls when they affect software work. + +Missing SysDes coverage: None. + +| SysDes ID | SysDes allocation | Covered by SRS | +|---|---|---| +| SysDes-001 | System Engineering | SRS-001 | +| SysDes-002 | System Engineering | SRS-001, SRS-008 | +| SysDes-003 | System Engineering | SRS-001, SRS-007 | +| SysDes-004 | System Engineering, Verification | SRS-002 | +| SysDes-005 | System Engineering | SRS-002, SRS-003, SRS-121 | +| SysDes-006 | Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-002, SRS-003, SRS-004 | +| SysDes-007 | System Engineering | SRS-002 | +| SysDes-008 | System Engineering, Verification | SRS-002, SRS-005 | +| SysDes-009 | System Engineering, Verification | SRS-002, SRS-005 | +| SysDes-010 | Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011 | +| SysDes-011 | Software: Protocol Adapter | SRS-044, SRS-053, SRS-134 | +| SysDes-012 | Software: Flutter UI, Software: Rust Core | SRS-013 | +| SysDes-013 | Software: Audio Subsystem | SRS-062, SRS-064, SRS-065, SRS-066, SRS-067, SRS-069, SRS-135 | +| SysDes-014 | Software: Flutter UI, Software: Audio Subsystem | SRS-012, SRS-135 | +| SysDes-015 | Software: Diagnostics, Verification | SRS-093, SRS-095, SRS-137 | +| SysDes-016 | System Engineering | SRS-009 | +| SysDes-017 | Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations | SRS-004, SRS-015, SRS-052, SRS-083, SRS-095, SRS-123, SRS-128, SRS-134 | +| SysDes-018 | External Server, Software: Audio Subsystem, Deployment / Operations | SRS-006 | +| SysDes-019 | User / Operator, Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-096, SRS-132 | +| SysDes-020 | Hardware, Software: Audio Subsystem | SRS-006, SRS-062, SRS-106, SRS-129, SRS-135 | +| SysDes-021 | Platform, Software: Audio Subsystem, Platform Secure Storage | SRS-006, SRS-027, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-137, SRS-138 | +| SysDes-022 | Network | SRS-006, SRS-130 | +| SysDes-023 | External Server, Software: Audio Subsystem, Platform | SRS-006, SRS-010, SRS-131, SRS-132 | +| SysDes-024 | Software, Platform | SRS-008, SRS-016 | +| SysDes-025 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-017, SRS-018, SRS-019, SRS-020, SRS-021, SRS-022, SRS-024, SRS-025, SRS-026, SRS-027, SRS-028, SRS-080, SRS-081, SRS-096, SRS-108, SRS-109 | +| SysDes-026 | Software: Flutter State, Software: Rust Core, Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030 | +| SysDes-027 | Software: Bridge, Software: Rust Core | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-103 | +| SysDes-028 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-036, SRS-037, SRS-038, SRS-039, SRS-136 | +| SysDes-029 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-134 | +| SysDes-030 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-036, SRS-043, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060, SRS-061, SRS-124, SRS-136 | +| SysDes-031 | Software: Audio Subsystem | SRS-025, SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081, SRS-125, SRS-135, SRS-136 | +| SysDes-032 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-013, SRS-014, SRS-027, SRS-070, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-138 | +| SysDes-033 | Software: Audio Subsystem, Software: Storage | SRS-026, SRS-068, SRS-075, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-136 | +| SysDes-034 | Platform Secure Storage | SRS-006, SRS-090, SRS-091, SRS-092, SRS-126, SRS-137 | +| SysDes-035 | Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-028, SRS-052, SRS-061, SRS-083, SRS-093, SRS-095, SRS-096, SRS-097, SRS-098, SRS-099, SRS-100, SRS-122, SRS-123, SRS-124, SRS-125, SRS-126, SRS-128, SRS-136, SRS-137 | +| SysDes-036 | Software: Storage, Deployment / Operations | SRS-006, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-127 | +| SysDes-037 | System Engineering, Verification | SRS-139 | +| SysDes-038 | Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core | SRS-003, SRS-011, SRS-016, SRS-031, SRS-032 | +| SysDes-039 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011, SRS-039 | +| SysDes-040 | Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter | SRS-012, SRS-029, SRS-033, SRS-044 | +| SysDes-041 | Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem | SRS-011, SRS-013, SRS-016 | +| SysDes-042 | System Engineering | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-038, SRS-039, SRS-103 | +| SysDes-043 | External Server, Deployment / Operations, System Engineering, Verification | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-131, SRS-134 | +| SysDes-044 | Software: Flutter UI, Software: Rust Core | SRS-036, SRS-037, SRS-054, SRS-057 | +| SysDes-045 | Hardware, Platform, Network | SRS-031, SRS-034, SRS-048, SRS-094, SRS-103, SRS-129, SRS-130 | +| SysDes-046 | Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering | SRS-020, SRS-032, SRS-035 | +| SysDes-047 | System Engineering | SRS-030, SRS-032, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060 | +| SysDes-048 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-090, SRS-091, SRS-092 | +| SysDes-049 | Software: Bridge, Software: Protocol Adapter | SRS-031, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089 | +| SysDes-050 | Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-014, SRS-027, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-133 | +| SysDes-051 | Software: Protocol Adapter | SRS-036, SRS-037 | +| SysDes-052 | External Server, Software: Protocol Adapter | SRS-029, SRS-033, SRS-039, SRS-047 | +| SysDes-053 | Software: Audio Subsystem | SRS-029, SRS-044 | +| SysDes-054 | Software: Audio Subsystem | SRS-029 | +| SysDes-055 | Software: Storage, Platform Secure Storage | SRS-017, SRS-018, SRS-023, SRS-024, SRS-031, SRS-038, SRS-132 | +| SysDes-056 | Software: Storage | SRS-025, SRS-026, SRS-028, SRS-031, SRS-032, SRS-068, SRS-086, SRS-095, SRS-103, SRS-106 | +| SysDes-057 | Software: Diagnostics, Verification | SRS-029, SRS-030, SRS-033, SRS-037, SRS-044, SRS-047 | +| SysDes-058 | Software: Diagnostics, Verification | SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-104, SRS-105 | +| SysDes-059 | Software: Audio Subsystem, Platform | SRS-017, SRS-018 | +| SysDes-060 | Software: Rust Core | SRS-019, SRS-036, SRS-037, SRS-038, SRS-040 | +| SysDes-061 | Software: Protocol Adapter, Software: Audio Subsystem, Platform | SRS-019, SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-046, SRS-054, SRS-055, SRS-056 | +| SysDes-062 | Software: Audio Subsystem, Platform | SRS-140 | +| SysDes-063 | Software: State Sync | SRS-025, SRS-062, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081 | +| SysDes-064 | Software: Diagnostics, Verification | SRS-019, SRS-036, SRS-040, SRS-041, SRS-042, SRS-130 | +| SysDes-065 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-018, SRS-038, SRS-045, SRS-094, SRS-132 | +| SysDes-066 | Software: Rust Core, Software: Protocol Adapter | SRS-019, SRS-036, SRS-037, SRS-040, SRS-042, SRS-059 | +| SysDes-067 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-032, SRS-036, SRS-043, SRS-046, SRS-054, SRS-055 | +| SysDes-068 | Software: State Sync | SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-047, SRS-054, SRS-056, SRS-057, SRS-058, SRS-060 | +| SysDes-069 | Software: Rust Core, Software: Protocol Adapter | SRS-023, SRS-038, SRS-049 | +| SysDes-070 | Software: Rust Core, Software: Protocol Adapter | SRS-024, SRS-038, SRS-050 | +| SysDes-071 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-077, SRS-079, SRS-080, SRS-104 | +| SysDes-072 | Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-078, SRS-081, SRS-088, SRS-105 | +| SysDes-073 | Software | SRS-038, SRS-041 | +| SysDes-074 | Software: State Sync | SRS-038, SRS-040, SRS-041, SRS-042, SRS-043, SRS-059, SRS-100, SRS-130 | +| SysDes-075 | Software: Audio Subsystem, Platform | SRS-026, SRS-082, SRS-099, SRS-106, SRS-107, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-135, SRS-138 | +| SysDes-076 | Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification | SRS-028, SRS-038, SRS-090, SRS-091, SRS-092, SRS-093, SRS-095, SRS-096, SRS-137 | +| SysDes-077 | Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-039 | +| SysDes-078 | Software: Protocol Adapter | SRS-044, SRS-047, SRS-053, SRS-134 | +| SysDes-079 | Software: State Sync, System Engineering, Verification | SRS-043, SRS-058, SRS-059, SRS-061, SRS-097, SRS-098 | +| SysDes-080 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-014, SRS-090, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-138 | +| SysDes-081 | Software: Audio Subsystem | SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-086, SRS-135 | +| SysDes-082 | Platform | SRS-006, SRS-010, SRS-131 | +| SysDes-083 | Software: Audio Subsystem | SRS-009, SRS-010 | +| SysDes-084 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-006, SRS-115, SRS-122, SRS-134, SRS-138 | +| SysDes-085 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-035 | +| SysDes-086 | Hardware, Network, Software: Audio Subsystem, Platform | SRS-006, SRS-026, SRS-062, SRS-066, SRS-069, SRS-073, SRS-082, SRS-099, SRS-107, SRS-112, SRS-113, SRS-129, SRS-135 | +| SysDes-087 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-095, SRS-136 | +| SysDes-088 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem | SRS-034, SRS-041, SRS-042, SRS-043, SRS-048, SRS-059, SRS-060, SRS-100, SRS-130 | +| SysDes-089 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-034, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-103, SRS-126, SRS-129, SRS-137 | +| SysDes-090 | Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-093, SRS-095, SRS-096, SRS-101, SRS-102, SRS-108, SRS-109, SRS-115, SRS-122, SRS-133, SRS-137 | +| SysDes-091 | Software: Storage, Deployment / Operations, System Engineering, Verification | SRS-004, SRS-006, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-138 | +| SysDes-092 | System Engineering | SRS-002, SRS-005 | +| SysDes-093 | System Engineering | SRS-002, SRS-005 | +| SysDes-094 | System Engineering | SRS-002, SRS-005 | +| SysDes-095 | System Engineering | SRS-002, SRS-005 | +| SysDes-096 | System Engineering | SRS-002, SRS-005 | +| SysDes-097 | System Engineering, Verification | SRS-002, SRS-005 | +| SysDes-098 | Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification | SRS-007, SRS-095 | +| SysDes-099 | System Engineering, Verification | SRS-007 | +| SysDes-100 | System Engineering | SRS-007 | +| SysDes-101 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification | SRS-006 | +| SysDes-102 | External Server, Software: Protocol Adapter | SRS-004, SRS-015, SRS-045, SRS-046, SRS-049, SRS-050, SRS-051, SRS-052, SRS-097, SRS-100, SRS-123, SRS-128, SRS-131, SRS-134 | +| SysDes-103 | Software: State Sync | SRS-004, SRS-015, SRS-058, SRS-059, SRS-060, SRS-061, SRS-097, SRS-098, SRS-124, SRS-128 | +| SysDes-104 | Software: Audio Subsystem | SRS-004, SRS-015, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-072, SRS-073, SRS-076, SRS-083, SRS-099, SRS-125, SRS-128, SRS-135 | +| SysDes-105 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-004, SRS-015, SRS-028, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-095, SRS-096, SRS-101, SRS-102, SRS-126, SRS-128, SRS-137 | +| SysDes-106 | Software: Storage, Deployment / Operations | SRS-004, SRS-015, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-128, SRS-138 | +| SysDes-107 | Verification | SRS-004, SRS-015, SRS-128 | +| SysDes-108 | System Engineering, Software Requirements Engineering, Verification | SRS-004, SRS-005, SRS-141, SRS-143 | +| SysDes-109 | System Engineering, Software Requirements Engineering | SRS-004, SRS-005, SRS-141, SRS-143 | +| SysDes-110 | System Engineering, Software Requirements Engineering, Change Control, Verification | SRS-004, SRS-005, SRS-142, SRS-143 | + +## 10. SRS Requirement Register + +| SRS ID | Type | Stage | Allocated to | Verification method | Source SysDes | +|---|---|---|---|---|---| +| SRS-001 | Process / SWE.1 | P0 / MVP | Software Requirements Engineering | Review | SysDes-001 through SysDes-003 | +| SRS-002 | Process / Requirement Attribute | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-004 through SysDes-009, SysDes-092 through SysDes-097 | +| SRS-003 | Process / Structuring | P0 / MVP | Software Requirements Engineering | Review | SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039 | +| SRS-004 | Process / Prioritization | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110 | +| SRS-005 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110 | +| SRS-006 | Process / Operating Environment Analysis | P0 / MVP | Software Requirements Engineering | Review | SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101 | +| SRS-007 | Process / Communication | P0 / MVP | Software Requirements Engineering | Review | SysDes-003, SysDes-098 through SysDes-100 | +| SRS-008 | Constraint | P0 / MVP | Application Container | Review | SysDes-002, SysDes-024 | +| SRS-009 | Constraint | P0 / MVP | Application Container, Rust Core | Review, System Test | SysDes-016, SysDes-083 | +| SRS-010 | Constraint | P0 / MVP | Application Container, Protocol Adapter | Inspection | SysDes-023, SysDes-082, SysDes-083 | +| SRS-011 | Architecture Constraint | P0 / MVP | All Software Components | Inspection | SysDes-010, SysDes-038, SysDes-039, SysDes-041 | +| SRS-012 | Architecture Constraint | P0 / MVP | Flutter UI, Audio Subsystem | Inspection, Performance Test | SysDes-014, SysDes-040, SysDes-071, SysDes-072 | +| SRS-013 | Platform Requirement | P0 / MVP | Flutter UI, Rust Core, Platform Adapters | Build Test | SysDes-012, SysDes-032, SysDes-041 | +| SRS-014 | Architecture Constraint | P0 / MVP | Platform Adapters | Inspection, Integration Test | SysDes-032, SysDes-050, SysDes-080 | +| SRS-015 | Verification Hook | P0 / MVP | Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters | Inspection, Demo | SysDes-017, SysDes-102 through SysDes-107 | +| SRS-016 | Functional | P0 / MVP | Application Container | Integration Test | SysDes-024, SysDes-038, SysDes-041 | +| SRS-017 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059 | +| SRS-018 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059, SysDes-065 | +| SRS-019 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066 | +| SRS-020 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068 | +| SRS-021 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068 | +| SRS-022 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test | SysDes-025, SysDes-026, SysDes-030, SysDes-067 | +| SRS-023 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | System Test | SysDes-055, SysDes-069 | +| SRS-024 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | UI Test, System Test | SysDes-025, SysDes-055, SysDes-070 | +| SRS-025 | Functional | P0 / MVP | Flutter UI, Audio Subsystem | UI Test, System Test | SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072 | +| SRS-026 | Functional | P0 / MVP | Flutter UI, Audio Subsystem, Storage | UI Test | SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086 | +| SRS-027 | Functional / Privacy | P0 / MVP | Flutter UI, Platform Adapters | UI Test, Privacy Review | SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 | +| SRS-028 | Functional / Diagnostics | P1 / Beta | Flutter UI, Diagnostics | UI Test, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105 | +| SRS-029 | Constraint | P0 / MVP | Flutter UI, Flutter State | Inspection | SysDes-040, SysDes-052 through SysDes-054, SysDes-057 | +| SRS-030 | Functional | P0 / MVP | Flutter State | Inspection, UI Test | SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068 | +| SRS-031 | Interface | P0 / MVP | Bridge Layer | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056 | +| SRS-032 | Interface | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068 | +| SRS-033 | Interface / Safety | P0 / MVP | Bridge Layer | Inspection, Integration Test | SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057 | +| SRS-034 | Interface / Error Handling | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089 | +| SRS-035 | Non-functional | P0 / MVP | Bridge Layer, Rust Core | Performance Test | SysDes-027, SysDes-042, SysDes-046, SysDes-085 | +| SRS-036 | Functional | P0 / MVP | Rust Core | Unit Test, Integration Test | SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068 | +| SRS-037 | Functional | P0 / MVP | Rust Core | Inspection, Unit Test | SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066 | +| SRS-038 | Functional | P0 / MVP | Rust Core, Bridge | Integration Test | SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076 | +| SRS-039 | Functional / Architecture | P0 / MVP | Rust Core | Inspection | SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077 | +| SRS-040 | Functional | P0 / MVP | Rust Core, State Sync | Unit Test, System Test | SysDes-060, SysDes-064, SysDes-066, SysDes-074 | +| SRS-041 | Functional | P0 / MVP | Rust Core | System Test | SysDes-064, SysDes-073, SysDes-074, SysDes-088 | +| SRS-042 | Functional / Reliability | P0 / MVP | Rust Core, Protocol Adapter, State Sync | System Test | SysDes-064, SysDes-066, SysDes-074, SysDes-088 | +| SRS-043 | Functional / Reliability | P0 / MVP | Rust Core, State Sync | System Test, Event Replay Test | SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088 | +| SRS-044 | Architecture Constraint | P0 / MVP | Protocol Adapter | Inspection | SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078 | +| SRS-045 | Functional | P0 / MVP | Protocol Adapter, Rust Core | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-065, SysDes-102 | +| SRS-046 | Functional | P0 / MVP | Protocol Adapter, State Sync | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102 | +| SRS-047 | Functional | P0 / MVP | Protocol Adapter, State Sync | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078 | +| SRS-048 | Functional / Error Handling | P0 / MVP | Protocol Adapter, Rust Core | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-045, SysDes-088 | +| SRS-049 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-069, SysDes-102 | +| SRS-050 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-070, SysDes-102 | +| SRS-051 | Functional | P0 / MVP | Protocol Adapter, Audio Subsystem | Protocol Integration Test, Audio Test | SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104 | +| SRS-052 | Verification Hook | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 | +| SRS-053 | Maintainability | P1 / Beta | Protocol Adapter, Bridge | Architecture Review | SysDes-011, SysDes-029, SysDes-043, SysDes-078 | +| SRS-054 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068 | +| SRS-055 | Functional | P0 / MVP | State Sync | Unit Test, Integration Test | SysDes-030, SysDes-047, SysDes-061, SysDes-067 | +| SRS-056 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-061, SysDes-068 | +| SRS-057 | Functional | P0 / MVP | State Sync, Rust Core | Unit Test, Integration Test | SysDes-030, SysDes-044, SysDes-047, SysDes-068 | +| SRS-058 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103 | +| SRS-059 | Functional / Reliability | P0 / MVP | State Sync | Event Replay Test, System Test | SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103 | +| SRS-060 | Reliability | P0 / MVP | State Sync, Rust Core | Unit Test, Fuzz/Negative Test | SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103 | +| SRS-061 | Verification Hook | P1 / Beta | State Sync, Diagnostics | Demo | SysDes-030, SysDes-035, SysDes-079, SysDes-103 | +| SRS-062 | Functional | P0 / MVP | Audio Subsystem | Audio Integration Test | SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104 | +| SRS-063 | Functional | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-064 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-065 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-066 | Functional / Audio Processing | P0 / MVP | Audio Subsystem, Platform Adapters | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104 | +| SRS-067 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-068 | Functional / Settings | P0 / MVP | Audio Subsystem, Flutter UI, Storage | UI Test, Unit Test | SysDes-031, SysDes-033, SysDes-056, SysDes-081 | +| SRS-069 | Non-functional / Audio | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-031, SysDes-081, SysDes-086 | +| SRS-070 | Architecture / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Inspection | SysDes-031, SysDes-032, SysDes-058, SysDes-081 | +| SRS-071 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-104 | +| SRS-072 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 | +| SRS-073 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104 | +| SRS-074 | Functional / Audio Playback | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-031, SysDes-058, SysDes-072 | +| SRS-075 | Functional / Audio Playback | P1 / Beta | Audio Subsystem, Flutter UI, Storage | Audio Test, UI Test | SysDes-031, SysDes-033, SysDes-058, SysDes-072 | +| SRS-076 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 | +| SRS-077 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 | +| SRS-078 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-072 | +| SRS-079 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 | +| SRS-080 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-071 | +| SRS-081 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, State Sync, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-072 | +| SRS-082 | Reliability / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Platform Integration Test | SysDes-032, SysDes-050, SysDes-075, SysDes-086 | +| SRS-083 | Verification Hook | P1 / Beta | Audio Subsystem, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-104 | +| SRS-084 | Functional / Storage | P0 / MVP | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 | +| SRS-085 | Functional / Storage | P1 / Beta | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 | +| SRS-086 | Functional / Storage | P0 / MVP | Storage, Audio Subsystem | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081 | +| SRS-087 | Functional / Storage | P1 / Beta | Storage, Flutter UI | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 | +| SRS-088 | Functional / Storage | P1 / Beta | Storage, Audio Subsystem | Unit Test | SysDes-033, SysDes-036, SysDes-049, SysDes-072 | +| SRS-089 | Architecture / Storage | P0 / MVP | Storage | Inspection | SysDes-033, SysDes-036, SysDes-049, SysDes-091 | +| SRS-090 | Interface / Security | P0 / MVP | Storage, Platform Adapters | Inspection, Security Audit | SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105 | +| SRS-091 | Security | P0 / MVP | Storage, Platform Secure Storage | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 | +| SRS-092 | Security | P0 / MVP | Storage, Platform Secure Storage, Diagnostics | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 | +| SRS-093 | Security / Diagnostics | P0 / MVP | Diagnostics, Storage | Security Audit | SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 | +| SRS-094 | Security | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | Unit Test, Security Test | SysDes-045, SysDes-065, SysDes-089, SysDes-105 | +| SRS-095 | Diagnostics | P0 / MVP | Diagnostics | Inspection, Demo | SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105 | +| SRS-096 | Diagnostics | P1 / Beta | Diagnostics, Flutter UI | Demo, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105 | +| SRS-097 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Protocol Adapter, State Sync | Demo | SysDes-035, SysDes-079, SysDes-102, SysDes-103 | +| SRS-098 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, State Sync | Demo | SysDes-035, SysDes-079, SysDes-103 | +| SRS-099 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Audio Subsystem, Platform Adapters | Demo | SysDes-035, SysDes-075, SysDes-086, SysDes-104 | +| SRS-100 | Diagnostics / Reliability | P1 / Beta | Diagnostics, Rust Core, Protocol Adapter | Demo | SysDes-035, SysDes-074, SysDes-088, SysDes-102 | +| SRS-101 | Privacy | P0 / MVP | All Software Components | Privacy Review | SysDes-090, SysDes-105 | +| SRS-102 | Privacy / Constraint | P0 / MVP | Diagnostics | Security Audit | SysDes-090, SysDes-105 | +| SRS-103 | Security / Error Handling | P0 / MVP | Flutter UI, Rust Core, Bridge, Diagnostics | UI Test, Security Review | SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089 | +| SRS-104 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071 | +| SRS-105 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072 | +| SRS-106 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem, Flutter UI | Platform Integration Test | SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075 | +| SRS-107 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086 | +| SRS-108 | Interface / Platform | P0 / MVP | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 | +| SRS-109 | Interface / Platform | P1 / Beta | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 | +| SRS-110 | Platform / iOS | P0 / MVP | Platform Adapters, Audio Subsystem | iOS Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 | +| SRS-111 | Platform / Android | P0 / MVP | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 | +| SRS-112 | Platform / Android | P1 / Beta | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 | +| SRS-113 | Platform / Desktop | P1 / Beta | Platform Adapters, Audio Subsystem | Desktop Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 | +| SRS-114 | Interface / Platform | P1 / Beta | Platform Adapters, Rust Core, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 | +| SRS-115 | Platform / Diagnostics | P1 / Beta | Platform Adapters, Diagnostics, Flutter UI | Review, Demo | SysDes-050, SysDes-075, SysDes-084, SysDes-090 | +| SRS-116 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-117 | Packaging | P2 / Production | Application Container, Deployment Scripts | Build/Release Audit | SysDes-036, SysDes-091, SysDes-106 | +| SRS-118 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-119 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-120 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-121 | Legal / Product Constraint | P0 / MVP | Application Container, Flutter UI, Deployment Scripts | Legal Review, Inspection | SysDes-005, SysDes-036, SysDes-091, SysDes-106 | +| SRS-122 | Security / Release | P1 / Beta | Application Container, Diagnostics, Deployment Scripts | Inspection, Security Review | SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106 | +| SRS-123 | Verification Support | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 | +| SRS-124 | Verification Support | P0 / MVP | State Sync, Diagnostics | Unit Test, Demo | SysDes-030, SysDes-035, SysDes-103 | +| SRS-125 | Verification Support | P0 / MVP | Audio Subsystem, Diagnostics | Audio Test, Demo | SysDes-031, SysDes-035, SysDes-104 | +| SRS-126 | Verification Support | P0 / MVP | Storage, Diagnostics, Platform Adapters | Security Audit | SysDes-034, SysDes-035, SysDes-089, SysDes-105 | +| SRS-127 | Verification Support | P1 / Beta | Deployment Scripts, Application Container | Build Test, Release Audit | SysDes-036, SysDes-091, SysDes-106 | +| SRS-128 | Verification Support | P0 / MVP | All Software Components | System Test, Demo | SysDes-017, SysDes-035, SysDes-102 through SysDes-107 | +| SRS-129 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Audio Subsystem, Platform Adapters | System Test | SysDes-020, SysDes-045, SysDes-086, SysDes-089 | +| SRS-130 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter | System Test | SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088 | +| SRS-131 | Operating Environment Constraint | P0 / MVP | Protocol Adapter, Rust Core, Flutter UI | System Test | SysDes-023, SysDes-043, SysDes-082, SysDes-102 | +| SRS-132 | Functional / Environment | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | UI Test, System Test | SysDes-019, SysDes-023, SysDes-055, SysDes-065 | +| SRS-133 | Operating Environment Interface | P0 / MVP | Platform Adapters, Rust Core, Flutter UI | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090 | +| SRS-134 | Analysis Requirement | P0 / MVP | Protocol Adapter, Software Requirements Engineering | Review, Protocol Probe | SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102 | +| SRS-135 | Analysis Requirement | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104 | +| SRS-136 | Analysis Requirement | P0 / MVP | Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage | Review, Performance Test | SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087 | +| SRS-137 | Analysis Requirement | P0 / MVP | Storage, Diagnostics, Platform Adapters, Flutter UI | Security Review, Privacy Review | SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 | +| SRS-138 | Analysis Requirement | P1 / Beta | Platform Adapters, Audio Subsystem, Deployment Scripts | Review, Platform Test | SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106 | +| SRS-139 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-037 | +| SRS-140 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-062 | +| SRS-141 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Review, Inspection | SysDes-108, SysDes-109 | +| SRS-142 | Process / Change Control | P0 / MVP | Software Requirements Engineering, Change Control | Review, Inspection | SysDes-110 | +| SRS-143 | Process / Coverage | P0 / MVP | Software Requirements Engineering, Verification | Review, Inspection | SysDes-108, SysDes-109, SysDes-110 | + +## 11. Revision History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-13 | Initial ASPICE SWE.1-style SRS derived from early SysDes baseline | +| 0.2.0 | 2026-05-13 | Added inherited upstream coverage via SysDes to show complete chained requirement traceability | +| 0.3.0 | 2026-05-13 | Removed all direct individual SRS-to-upstream-system-requirement links; SRS now traces only to SysDes as the system architectural allocation baseline | +| 0.4.0 | 2026-05-13 | Updated source baseline to SysDes v0.5 and added SRS requirements for SysDes-108 through SysDes-110 derivation and change-control rules | + + + + +--- + +## 13. UI/UX, Material 3, Platform, and Internationalization Software Requirements + +This section extends the ASPICE SWE.1 Software Requirements Specification. The source baseline for these requirements is **SysDes only**. This SRS does not link directly to system-requirement IDs. + +**SRS-144**: The software shall initialize the Flutter client theme using Material 3 as the baseline UI system. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Design System +- Source SysDes: SysDes-111, SysDes-112 +- Verification method: Review, Widget Test + +**SRS-145**: The software shall provide a Chanora Design System layer above Material 3 for product-specific semantic states. + +- Status: Baseline +- Type: Software Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-111, SysDes-112, SysDes-113 +- Verification method: Inspection, Widget Test + +**SRS-146**: The software shall define semantic tokens for connection states. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-114 +- Verification method: Unit Test + +**SRS-147**: The software shall define semantic tokens for voice states including speaking, muted, deafened, and push-to-talk active states. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-114 +- Verification method: Unit Test + +**SRS-148**: The software shall define semantic tokens for latency, packet loss, diagnostics, and error states. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-114 +- Verification method: Unit Test + +**SRS-149**: The software shall expose design tokens through `ThemeData`, `ColorScheme`, `TextTheme`, component themes, `ThemeExtension`, or equivalent Flutter theming mechanisms. + +- Status: Baseline +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-113, SysDes-114 +- Verification method: Inspection, Widget Test + +**SRS-150**: Feature screens shall not hardcode product semantic colors, spacing, shape, density, or motion values. + +- Status: Baseline +- Type: Software Constraint +- Stage: P0 / MVP +- Allocated to: Flutter Feature Screens +- Source SysDes: SysDes-112, SysDes-113, SysDes-114 +- Verification method: Review, Static Inspection + +**SRS-151**: The software shall provide an Adaptive Shell that resolves compact, medium, and expanded layout classes. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115 +- Verification method: Widget Test, Integration Test + +**SRS-152**: The compact layout shall use a single-column primary content structure and mobile-appropriate primary navigation. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115, SysDes-116 +- Verification method: Widget Test, Integration Test + +**SRS-153**: The medium layout shall support side navigation or equivalent navigation rail behavior where available display width permits. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P1 / Beta +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115, SysDes-116 +- Verification method: Widget Test, Integration Test + +**SRS-154**: The expanded layout shall support persistent side panes and persistent voice controls where available display width permits. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P2 / Production +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115, SysDes-116 +- Verification method: Integration Test, System Test + +**SRS-155**: The software shall keep connection status visible or directly reachable in compact, medium, and expanded layouts. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Connection UI +- Source SysDes: SysDes-116 +- Verification method: Integration Test + +**SRS-156**: The software shall keep primary voice controls visible or directly reachable in compact, medium, and expanded layouts. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Voice UI +- Source SysDes: SysDes-116 +- Verification method: Integration Test + +**SRS-157**: The software shall provide screen-reader semantics for critical connection, voice, channel, diagnostics, and settings controls. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System +- Source SysDes: SysDes-117, SysDes-130 +- Verification method: Accessibility Test + +**SRS-158**: The software shall provide localized accessibility labels for icon-only controls. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Localization Service +- Source SysDes: SysDes-117, SysDes-130 +- Verification method: Accessibility Test, Localization Test + +**SRS-159**: The software shall not express critical states by color alone; it shall also use text, iconography, shape, position, or semantic labeling. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System +- Source SysDes: SysDes-117 +- Verification method: Widget Test, Accessibility Test + +**SRS-160**: The software shall support visible focus indication and logical focus traversal for desktop and tablet keyboard use. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P1 / Beta +- Allocated to: Flutter UI +- Source SysDes: SysDes-117 +- Verification method: Widget Test, System Test + +**SRS-161**: The software shall keep critical actions reachable under increased text scaling. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SysDes: SysDes-117 +- Verification method: Accessibility Test + +**SRS-162**: The software shall apply platform safe area, display cutout, system bar, virtual keyboard, and desktop window inset constraints through shared shell behavior. + +- Status: Baseline +- Type: Software Platform Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Platform Adapter +- Source SysDes: SysDes-118 +- Verification method: Platform Test + +**SRS-163**: The software shall model Android back navigation as a platform back intent handled by the shell or platform service layer. + +- Status: Baseline +- Type: Software Platform Requirement +- Stage: P1 / Beta +- Allocated to: Flutter App Shell, Platform Adapter +- Source SysDes: SysDes-118 +- Verification method: Platform Test + +**SRS-164**: The software shall model iOS navigation gestures, safe areas, keyboard avoidance, and haptics through platform-aware UI services. + +- Status: Baseline +- Type: Software Platform Requirement +- Stage: P1 / Beta +- Allocated to: Flutter App Shell, Platform Adapter +- Source SysDes: SysDes-118 +- Verification method: Platform Test + +**SRS-165**: The software shall provide a Localization Service for product-owned user-visible strings. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119 +- Verification method: Unit Test, Integration Test + +**SRS-166**: The software shall externalize product-owned user-visible strings into localization resources or an equivalent mechanism. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119 +- Verification method: Inspection + +**SRS-167**: The software shall provide English as the baseline product locale. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119, SysDes-131 +- Verification method: Localization Test + +**SRS-168**: The software shall implement deterministic fallback behavior when a translation key is missing. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119, SysDes-131 +- Verification method: Unit Test + +**SRS-169**: The software shall allow additional locales to be added without changing protocol, audio, state synchronization, or storage modules. + +- Status: Baseline +- Type: Software Maintainability Requirement +- Stage: P1 / Beta +- Allocated to: Localization Service, Flutter UI +- Source SysDes: SysDes-119 +- Verification method: Review, Inspection + +**SRS-170**: The software shall display server-provided server names, channel names, client nicknames, and text messages as content rather than translating them. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Protocol DTOs +- Source SysDes: SysDes-120 +- Verification method: Integration Test + +**SRS-171**: The software shall preserve Unicode text received from compatible servers through protocol adapter, bridge DTO, state store, and UI rendering paths. + +- Status: Baseline +- Type: Software Data Requirement +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Bridge, Rust Core, Flutter UI +- Source SysDes: SysDes-120, SysDes-121 +- Verification method: Integration Test + +**SRS-172**: The software shall use UTF-8 internally for cross-layer text DTOs unless a boundary adapter requires conversion. + +- Status: Baseline +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Bridge, Rust Core, Storage, Diagnostics, Protocol Adapter +- Source SysDes: SysDes-121 +- Verification method: Inspection, Integration Test + +**SRS-173**: The software shall isolate non-UTF-8 or platform-specific string conversion in boundary adapters. + +- Status: Baseline +- Type: Software Interface Requirement +- Stage: P1 / Beta +- Allocated to: Protocol Adapter, Platform Adapter, Bridge +- Source SysDes: SysDes-122 +- Verification method: Inspection, Integration Test + +**SRS-174**: The software shall not corrupt multilingual Unicode content in logs or diagnostic exports unless redaction intentionally removes sensitive content. + +- Status: Baseline +- Type: Software Data Integrity Requirement +- Stage: P0 / MVP +- Allocated to: Diagnostics, Storage +- Source SysDes: SysDes-121, SysDes-124 +- Verification method: Test, Audit + +**SRS-175**: The software shall support bidirectional text display where the Flutter platform text engine supports it. + +- Status: Baseline +- Type: Software Internationalization Requirement +- Stage: P2 / Production +- Allocated to: Flutter UI +- Source SysDes: SysDes-123 +- Verification method: Localization Test + +**SRS-176**: The software shall use locale-aware formatting for user-visible dates, times, numbers, and diagnostic timestamps. + +- Status: Baseline +- Type: Software Internationalization Requirement +- Stage: P1 / Beta +- Allocated to: Localization Service, Diagnostics UI +- Source SysDes: SysDes-123, SysDes-124 +- Verification method: Localization Test + +**SRS-177**: The software shall keep diagnostic event keys, codes, and machine-readable fields language-neutral. + +- Status: Baseline +- Type: Software Diagnostics Requirement +- Stage: P1 / Beta +- Allocated to: Diagnostics +- Source SysDes: SysDes-124 +- Verification method: Inspection, Test + +**SRS-178**: The software shall allow user-facing diagnostic descriptions to be localized independently of machine-readable diagnostic fields. + +- Status: Baseline +- Type: Software Diagnostics Requirement +- Stage: P1 / Beta +- Allocated to: Diagnostics, Localization Service +- Source SysDes: SysDes-124 +- Verification method: Inspection, Localization Test + +**SRS-179**: The software shall maintain UI/UX guideline, design token, component catalog, adaptive layout, and platform behavior documents as downstream design baselines. + +- Status: Baseline +- Type: Software Documentation Requirement +- Stage: P1 / Beta +- Allocated to: UX, Software Engineering +- Source SysDes: SysDes-125 +- Verification method: Review + +**SRS-180**: The software requirements baseline shall derive requirements only from `SysDes-XXX` sources. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Engineering +- Source SysDes: SysDes-126, SysDes-127 +- Verification method: Inspection + +**SRS-181**: The SRS shall not use direct upstream system-requirement source fields or direct system-requirement trace links. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Engineering +- Source SysDes: SysDes-127 +- Verification method: Inspection + +**SRS-182**: The software architecture shall derive architecture items only from `SRS-XXX` sources. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Architecture +- Source SysDes: SysDes-128 +- Verification method: Inspection + +**SRS-183**: The software detailed design shall derive detailed design items only from `SAD-XXX` sources. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Design +- Source SysDes: SysDes-129 +- Verification method: Inspection + +**SRS-184**: Theme, localization, and initial platform adaptation shall be initialized before feature screens render user-visible content. + +- Status: Baseline +- Type: Software Dynamic Behavior Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Design System, Localization Service, Platform Adapter +- Source SysDes: SysDes-132 +- Verification method: Integration Test + +## 14. Updated SRS to SysDes Coverage Statement + +| SysDes Range | SRS Coverage | +|---|---| +| SysDes-001 through SysDes-110 | Covered by inherited SRS baseline `SRS-001` through `SRS-143` | +| SysDes-111 through SysDes-132 | Covered by `SRS-144` through `SRS-184` | + +## 15. Change History + +| Version | Date | Description | +|---|---|---| +| 0.5.0 | 2026-05-14 | Added Material 3, design system, adaptive layout, accessibility, platform behavior, localization, Unicode, diagnostics localization, and strict downstream traceability software requirements. | + +--- + +## 16. Platform Baseline and Product Decision Software Requirements + +**SRS-185**: The software shall define iOS 13 as the minimum iOS runtime deployment baseline unless approved platform constraints raise the minimum version. + +- Status: Baseline Candidate +- Type: Software Platform Requirement +- Stage: P0 / MVP +- Allocated to: iOS Build Configuration, Platform Adapter +- Source SysDes: SysDes-133 +- Verification method: Platform Test, Release Inspection + +**SRS-186**: The iOS/iPadOS release build process shall require Xcode 26 or later and the iOS 26 / iPadOS 26 SDK or later for App Store Connect upload on or after 2026-04-28, unless Apple publishes a newer applicable upload requirement before upload. + +- Status: Baseline Candidate +- Type: Software Release Requirement +- Stage: P0 / MVP +- Allocated to: iOS Build Configuration, Release Pipeline +- Source SysDes: SysDes-134 +- Verification method: Release Inspection + +**SRS-187**: The software shall define Android API 28 (Android 9.0) as the minimum Android runtime baseline, per DEC-004 (Accepted 2026-05-14, which raised the original API 24 recommendation to API 28). The minimum may be raised further only if Flutter, plugin, audio, or platform constraints require it; it shall not be lowered without a superseding accepted decision. + +- Status: Baseline Candidate +- Type: Software Platform Requirement +- Stage: P0 / MVP +- Allocated to: Android Build Configuration, Platform Adapter +- Source SysDes: SysDes-135 +- Verification method: Platform Test, Release Inspection +- Change record: 0.9.6 (2026-05-17) updated minimum Android API from 24 to 28 to align with DEC-004 and the reconciled SysRS-288 wording. ID preserved. + +**SRS-188**: The Android release build process shall target the Android API level required by Google Play on the upload date. + +- Status: Baseline Candidate +- Type: Software Release Requirement +- Stage: P0 / MVP +- Allocated to: Android Build Configuration, Release Pipeline +- Source SysDes: SysDes-135 +- Verification method: Release Inspection + +**SRS-189**: The software shall permit only one active server connection per client instance in MVP. + +- Status: Baseline Candidate +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Rust Core, Flutter UI, Protocol Adapter, State Sync +- Source SysDes: SysDes-136 +- Verification method: System Test + +**SRS-190**: The software shall enable AEC, AGC, Noise Suppression, and High-Pass Filter by default where supported and stable, with user or platform control to disable supported processing where applicable. + +- Status: Baseline Candidate +- Type: Software Audio Requirement +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Settings UI, Platform Audio +- Source SysDes: SysDes-137 +- Verification method: Audio Test + +**SRS-191**: The software shall use platform-native audio processing first for MVP where available and stable, and shall isolate any Rust/WebRTC-style fallback behind the audio subsystem boundary. + +- Status: Baseline Candidate +- Type: Software Architecture Constraint +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Audio Adapter +- Source SysDes: SysDes-138 +- Verification method: Architecture Review, Audio Test + +**SRS-192**: The software shall use SQLite or an equivalent embedded local database for non-secret local state and platform secure storage for secrets. + +- Status: Baseline Candidate +- Type: Software Storage Requirement +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage +- Source SysDes: SysDes-139 +- Verification method: Storage Test, Security Audit + +**SRS-193**: The software shall use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs. + +- Status: Baseline Candidate +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Bridge, Flutter State, Rust Core +- Source SysDes: SysDes-140 +- Verification method: Integration Test, Architecture Review + +**SRS-194**: The software shall not perform automatic diagnostic upload, automatic telemetry upload, or automatic crash reporting in MVP unless a later approved decision updates privacy, security, legal, release, and verification baselines. + +- Status: Baseline Candidate +- Type: Software Privacy Requirement +- Stage: P0 / MVP +- Allocated to: Diagnostics, Privacy, Release Pipeline +- Source SysDes: SysDes-141 +- Verification method: Privacy Review, Security Audit + +**SRS-195**: The software shall expose a `DesktopPttBackend` trait owned by the audio subsystem, with one implementation per supported desktop platform (Windows, macOS, Linux/GNOME-Wayland) and a `FocusedPttBackend` implementation used as the universal terminal fallback. The selected backend shall be discoverable at runtime and shall report its identifier through the diagnostics sanitizer. + +- Status: Baseline Candidate +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Audio, Platform Input +- Source SysDes: SysDes-142, SysDes-145 +- Verification method: Architecture Review, Unit Test + +**SRS-196**: The software shall publish a `PttCapabilityLevel` enum value (`L0` Focused, `L1` Global-shortcut-activation, `L2` Global-hold-to-talk, `L3` Global-with-mouse-buttons, `L4` Device-aware) from the active backend, and the value shall match the actual runtime capability rather than the platform's theoretical maximum. + +- Status: Baseline Candidate +- Type: Software Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio, Rust Core +- Source SysDes: SysDes-143 +- Verification method: Unit Test, Integration Test + +**SRS-197**: The Windows desktop backend shall attempt Raw Input first; if Raw Input is unavailable or initialisation fails, it shall attempt a low-level keyboard hook; if that also fails it shall return `PttCapabilityLevel::L0` and engage Focused PTT. The selected sub-strategy shall be recorded as the backend identifier for diagnostics and release verification. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Windows) +- Source SysDes: SysDes-145 +- Verification method: Platform Test (Windows), Unit Test + +**SRS-198**: The macOS desktop backend shall query the operating-system Input Monitoring / Accessibility permission state, return `PttCapabilityLevel::L0` while the permission is undecided or denied, and upgrade to the appropriate Global level only after the user grants the required permission. The user shall be able to dismiss the permission prompt and continue using Focused PTT without functional regression. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (macOS) +- Source SysDes: SysDes-145 +- Verification method: Platform Test (macOS), User Acceptance Test + +**SRS-199**: The Linux desktop backend shall probe the active display server and compositor at runtime. On GNOME-on-Wayland (the officially-tested target per DEC-026), the backend shall use the freedesktop GlobalShortcuts portal. On any other Linux environment the backend shall return `PttCapabilityLevel::L0` and engage Focused PTT. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Linux) +- Source SysDes: SysDes-145 +- Verification method: Platform Test (Linux, GNOME Wayland), Unit Test + +**SRS-200**: The software shall support mouse side buttons (typically labelled Mouse4 / Mouse5 or "back" / "forward") as bindable inputs for Global PTT on the Windows and macOS backends per DEC-027. The Linux GlobalShortcuts portal binding shall accept whatever input classes the portal exposes for the current session; missing mouse-button support shall not block release. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Windows/macOS/Linux) +- Source SysDes: SysDes-142, SysDes-145 +- Verification method: Platform Test, User Acceptance Test + +**SRS-201**: The audio engine shall expose `capture_active` and `transmit_active` as independent atomic states. `capture_active` shall reflect the input-stream lifecycle and the platform input-permission state; `transmit_active` shall reflect the PTT subsystem's decision and shall be the only gate on outbound Opus frame emission. + +- Status: Baseline Candidate +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Audio +- Source SysDes: SysDes-144 +- Verification method: Unit Test, Integration Test + +**SRS-202**: The diagnostics subsystem shall reject any log record carrying a raw key code, scan code, virtual-key value, or key-press timing sequence. The diagnostic export shall include the active `PttCapabilityLevel`, the active backend identifier, and the bound input class (for example "keyboard", "mouse-side-button") but shall never include the specific key value of any user binding. + +- Status: Baseline Candidate +- Type: Software Privacy Requirement +- Stage: P0 / MVP +- Allocated to: Diagnostics, Audio +- Source SysDes: SysDes-146 +- Verification method: Privacy Review, Unit Test, Diagnostic Inspection + +**SRS-203**: The software shall implement a missed-key-up watchdog per DEC-028: if `transmit_active` has been true for longer than a configured upper bound without a corresponding release event (for example because the OS suppressed the key-up while the application was minimised), the watchdog shall force `transmit_active` to false and emit a sanitised diagnostic record naming only the capability level and backend identifier. + +- Status: Baseline Candidate +- Type: Software Safety Requirement +- Stage: P0 / MVP +- Allocated to: Audio +- Source SysDes: SysDes-142, SysDes-144 +- Verification method: Unit Test, Integration Test + +**SRS-204**: The audio engine shall open the input and output streams on the user's first voice-channel join of the session and shall close them on the last voice-channel leave. The software shall expose no `start_audio` or equivalent manual-start operation at the bridge surface and shall expose no manual-start affordance in the UI; the bridge shall instead expose `voice_join(channel_id)` and `voice_leave()` operations and the audio engine shall initialise implicitly on the first `voice_join`. Output-stream opening shall not depend on the microphone-permission grant state, so listen-only is a first-class flow. + +- Status: Baseline Candidate +- Type: Software Lifecycle Requirement +- Stage: P0 / MVP +- Allocated to: Audio, Bridge, Flutter UI +- Source SysDes: SysDes-150 +- Verification method: Integration Test, UI Review + +**SRS-205**: The software shall represent the user's voice transmit mode as a `TransmitMode` enum with variants `Ptt`, `Continuous`, and `VoiceActivity` (the last reserved with no v1 implementation per DEC-030). The setting shall be persisted per identity via the identity store. The default value for a fresh install shall be `Ptt`. The UI shall render `VoiceActivity` as a disabled "coming soon" option until an implementation is allocated in a later baseline. + +- Status: Baseline Candidate +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Audio, Bridge, Flutter UI +- Source SysDes: SysDes-149 +- Verification method: Unit Test, UI Review + +**SRS-206**: The software shall expose a `release_tail_ms` configuration value (default 200 ms, validated range 0 through 500 ms inclusive) and shall delay the `true → false` transition of `transmit_active` by `release_tail_ms` after the PTT backend reports key-up. Where the user re-presses the bound input within the tail window, the pending close timer shall be cancelled and `transmit_active` shall remain true. The release tail shall not affect `capture_active`. + +- Status: Baseline Candidate +- Type: Software Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio +- Source SysDes: SysDes-151 +- Verification method: Unit Test, Integration Test + +**SRS-207**: The software shall expose a hard-mute toggle in the Voice Bar UI. While hard-mute is engaged, `transmit_active` shall be forced false regardless of the active transmit mode, the PTT key state, or any other internal signal. Hard-mute state shall be persisted in-session only and shall reset to off when the user joins a new voice channel. + +- Status: Baseline Candidate +- Type: Software Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio, Flutter UI +- Source SysDes: SysDes-150 +- Verification method: Functional Test, UI Review + +**SRS-208**: The Chanora Android client shall engage the Android in-call audio mode (for example via `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) no later than the moment a voice session becomes connected, so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The client shall release the in-call mode (restoring the prior audio mode) when the last active voice session ends. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Android), Platform Adapter (Android) +- Source SysDes: SysDes-152 (Android in-call audio mode subsystem allocation, primary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, Audio Test +- Acceptance criteria: On Android, audio-mode transitions to in-communication on first voice-session connect and reverts on last voice-session disconnect; behaviour is observable via platform audio diagnostics and produces voice-path routing for SCO/built-in mic. +- Analysis: Feasible via the existing Platform Adapter (Android) boundary and JNI call into `AudioManager`. Verification intent (SWE.6): demonstrate audio-mode entry/exit transitions are bound to voice session lifecycle, not to UI screen lifecycle. +- Unresolved assumptions: None at SRS layer. Upstream SysDes derivation now anchored at SysDes-152 (with SysDes-135 retained as platform-baseline context). + +**SRS-209**: The Chanora Android client shall request the runtime microphone permission (`RECORD_AUDIO`) at or before voice session activation, and shall not begin microphone capture without that permission having been granted. If the permission is denied, revoked, or not yet decided, the client shall fail safe to listen-only operation (output stream remains available consistent with SRS-204) and shall surface a user-visible path to grant the permission before retrying transmit. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement / Privacy +- Stage: P0 / MVP +- Allocated to: Platform Adapter (Android), Audio, Flutter UI +- Source SysDes: SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow, primary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, UI Test, Privacy Review +- Acceptance criteria: Permission prompt occurs no later than the user's first transmit attempt within a voice session; denial keeps the session alive in listen-only mode (`capture_active = false`, `transmit_active = false`, output stream open per SRS-204); UI exposes a non-blocking path to re-request or open system settings to grant the permission. +- Analysis: Feasible via existing platform permission adapter (SRS-108) and the audio engine's split `capture_active` / `transmit_active` states (SRS-201). Verification intent (SWE.6): demonstrate that listen-only is a first-class flow on denial and that no microphone capture is started prior to grant. +- Unresolved assumptions: None at SRS layer. Upstream SysDes derivation now anchored at SysDes-153 (with SysDes-135 retained as platform-baseline context); reuses the general permission obligation already captured in SRS-027 / SRS-108. + +## 17. Updated SRS to SysDes Coverage Statement + +| SysDes Range | SRS Coverage | +|---|---| +| SysDes-001 through SysDes-132 | Covered by inherited SRS baseline `SRS-001` through `SRS-184` | +| SysDes-133 through SysDes-141 | Covered by `SRS-185` through `SRS-194` | +| SysDes-142 through SysDes-148 | Covered by `SRS-195` through `SRS-203` | +| SysDes-149 through SysDes-151 | Covered by `SRS-204` through `SRS-207` | + +## 18. Android Audio Backend (P0) + +This subsection groups the Android voice-audio-backend software requirements derived to support the platform-adapter decision to host Android voice capture and playback through a dedicated low-latency native audio backend (mirroring the iOS voice-processing precedent already represented in the codebase for the iOS path). These requirements close the historical gap in which the Android voice path was carried by a generic desktop-style default backend and the hardware acoustic-echo / noise-suppression / automatic-gain effects were silently not engaged. They are sourced strictly from SysDes (per the SRS layering policy) and additionally cite the upstream SysRS items they help satisfy. + +**SRS-210**: The Chanora Android voice audio path shall achieve a round-trip mouth-to-ear ("glass-to-glass") latency of at most 150 ms on Android devices that support AAudio low-latency performance mode, and at most 250 ms on Android devices that do not support low-latency performance mode. For the purpose of this requirement, an Android device is considered to "support AAudio low-latency performance mode" if and only if (a) the client requested `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` on both the input and output streams at stream-open time, and (b) the AAudio stream returned by the platform reports `getPerformanceMode() == AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` after the stream is opened. Devices that downgrade the returned performance mode to `NONE` or `POWER_SAVING` fall under the 250 ms bound. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement / Performance +- Stage: P0 / MVP +- Allocated to: Audio (Android), Platform Adapter (Android) +- Source SysDes: SysDes-154 (Android voice audio backend subsystem — AAudio low-latency performance-mode path with platform-reported observability, primary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, Audio Test, Loopback Latency Measurement +- Acceptance criteria: On at least one reference Android device that returns `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` for the opened streams, instrumented loopback latency (mouth-to-ear, full duplex through the voice engine) does not exceed 150 ms at the 95th percentile across a 60-second measurement window; on at least one reference device that does not, the same measurement does not exceed 250 ms at the 95th percentile. +- Analysis: Feasible on API 28+ (per SRS-187 / DEC-004) using AAudio low-latency streams, which is one of the platform-recommended paths called out by SysRS-055. The latency tiering reflects the well-understood split between devices that expose the fast mixer / low-latency capture path and devices that do not. Verification intent (SWE.6): demonstrate that the chosen native-audio backend on Android opens streams in low-latency mode where the device permits it, and that the measured round-trip latency falls under the tier appropriate to the reported `getPerformanceMode()`. +- Unresolved assumptions: The exact reference-device matrix (which physical handsets define the "supports low-latency" tier vs the fallback tier) should be ratified by the verification owner. The 150 / 250 ms numeric targets are derived from SysRS-055's "production audio integration" intent and are not yet stated numerically at the SysRS layer; if SysRS owners wish to ratify a numeric mouth-to-ear bound, the values here should be considered the SRS-layer derivation and would update accordingly. + +**SRS-211**: The Chanora Android voice-capture path shall request the platform "voice communication" input preset where the operating system exposes one, so that the OS-side capture chain (gain shaping, far-end suppression, microphone selection) is the voice-optimised chain rather than the music/media chain. On Android the client shall request `AAUDIO_INPUT_PRESET_VOICE_COMMUNICATION` as the primary preset, and shall fall back to `AAUDIO_INPUT_PRESET_VOICE_PERFORMANCE` if the primary preset is not honoured by the device. This mirrors the precedent on iOS, where the voice-capture path is hosted on the platform voice-processing audio unit (`VoiceProcessingIO`); the Android requirement is the platform-analogous obligation, not a port of iOS code. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Android), Platform Adapter (Android) +- Source SysDes: SysDes-154 (Android voice audio backend subsystem — voice-communication input preset on the capture stream, primary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, Audio Test +- Acceptance criteria: On stream open, the Android voice-capture stream is constructed with input preset = `VOICE_COMMUNICATION`; if the device's AAudio stack reports that the preset was not honoured (or stream open fails specifically due to the preset), the client retries with `VOICE_PERFORMANCE`; the active preset is observable via audio diagnostics. The output-stream usage / content-type obligations are covered separately by SRS-213. +- Analysis: Feasible on API 28+ AAudio (covered by SRS-187). The iOS analogue (voice-processing audio unit) is already realised in the codebase, so the platform-symmetric obligation is well-founded. Verification intent (SWE.6): demonstrate that the input preset is set at stream-construction time, not after stream start, and that the fallback path is taken only on documented preset-rejection conditions. +- Unresolved assumptions: None at SRS layer. + +**SRS-212**: Where the Android device exposes the hardware voice-audio effect APIs `AcousticEchoCanceler`, `NoiseSuppressor`, and `AutomaticGainControl`, the Chanora Android client shall engage each available effect on the active microphone capture session (via the platform `audioSession`-id attachment API or the AAudio effect-attachment equivalent) at or before the moment voice capture is started. Where one or more of these hardware effects is not available on the device, the client shall fall back to the equivalent software processing already provided by the cross-platform audio engine, and shall not silently leave that processing disabled. This requirement explicitly closes the prior no-op gap in which the Android path acknowledged the request to engage hardware effects but did not in fact engage them. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Android), Platform Adapter (Android), Audio Engine +- Source SysDes: SysDes-154 (Android voice audio backend subsystem — engagement of platform hardware voice-audio effects with documented software fallback, primary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, Audio Test +- Acceptance criteria: For each of `AcousticEchoCanceler`, `NoiseSuppressor`, `AutomaticGainControl`: on devices where `isAvailable()` is true, the effect is constructed against the capture session id, enabled before the first capture callback delivers samples, and reports `getEnabled() == true` for the duration of the capture session; on devices where the effect is not available, the audio engine's software equivalent is engaged for the same duration. The fall-back decision is recorded in sanitised audio diagnostics. +- Analysis: Feasible via the Android `android.media.audiofx` effect APIs bound to the capture session id surfaced by the native backend. Verification intent (SWE.6): demonstrate via instrumented test that, on at least one device where hardware AEC is reported available, hardware AEC is engaged; and on at least one device where it is not, the software AEC path in the cross-platform engine is engaged. The "silent no-op" prior behaviour is explicitly excluded. +- Unresolved assumptions: None at SRS layer. SRS-208 (Android in-call audio mode) remains the routing-mode obligation; this requirement is the effects-engagement obligation and is complementary, not duplicative. + +**SRS-213**: The Chanora Android voice-output stream shall declare `AAUDIO_USAGE_VOICE_COMMUNICATION` and `AAUDIO_CONTENT_TYPE_SPEECH` at stream construction so that the Android audio policy engine routes the stream under the voice-communication routing rules that engage when `MODE_IN_COMMUNICATION` is active (per SRS-208), including correct Bluetooth SCO routing, earpiece-vs-speaker selection, and ducking behaviour against media. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Android), Platform Adapter (Android) +- Source SysDes: SysDes-154 (Android voice audio backend subsystem — voice-communication usage and content-type declarations on the output stream, primary), SysDes-152 (Android in-call audio mode subsystem — output usage is the precondition for in-call-mode routing, secondary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, Audio Test +- Acceptance criteria: The opened AAudio output stream reports usage = `VOICE_COMMUNICATION` and content type = `SPEECH`; with `MODE_IN_COMMUNICATION` engaged (per SRS-208), playback routes to the in-call output device (earpiece / SCO / wired headset) and does not route to the media output device. +- Analysis: Feasible on API 28+ AAudio. The combination is the platform-documented way to opt the stream into the voice routing path and is the playback-side counterpart of SRS-211's capture-side preset selection. Verification intent (SWE.6): demonstrate routing differs from a media-usage stream under `MODE_IN_COMMUNICATION`. +- Unresolved assumptions: None at SRS layer. + +**SRS-214**: The Chanora Android voice input and output streams shall request `AAUDIO_SHARING_MODE_EXCLUSIVE` on a best-effort basis at stream construction, and shall gracefully fall back to `AAUDIO_SHARING_MODE_SHARED` when the platform denies exclusive access (for example because another application holds an exclusive stream or because shared media playback is active). The fall-back shall not be reported as a fatal error to the user and shall not prevent voice session establishment; it shall be recorded in sanitised audio diagnostics so that the achieved sharing mode is observable for SRS-210 latency analysis. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Audio (Android), Platform Adapter (Android) +- Source SysDes: SysDes-154 (Android voice audio backend subsystem — best-effort exclusive sharing-mode policy with graceful shared fallback, primary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, Audio Test +- Acceptance criteria: On stream open the client requests `EXCLUSIVE`; on devices that grant it, `getSharingMode()` reports `EXCLUSIVE`; on devices or device states that deny it, the client opens with `SHARED` instead and the voice session proceeds; the achieved sharing mode appears in sanitised audio diagnostics for both the input and the output stream. +- Analysis: Feasible on API 28+ AAudio. Exclusive mode is the documented path to the lowest-latency tier on devices that expose a fast capture/playback path; making the request best-effort avoids regressing the user's ability to join a voice session when another exclusive stream is active. Verification intent (SWE.6): demonstrate both the granted and denied paths and that neither blocks voice session establishment. +- Unresolved assumptions: None at SRS layer. + +**SRS-215**: The Chanora Android client shall maintain active microphone capture while the application is backgrounded by hosting voice transmission inside an Android foreground service whose manifest declares `foregroundServiceType="microphone"`. This formalises at the SRS layer the platform-required hosting model under which background microphone capture is permitted on Android 9+ (API 28+) and is the software-requirement counterpart of the existing foreground-service obligation captured in SRS-111. + +- Status: Baseline Candidate +- Type: Platform Behavioural Requirement +- Stage: P0 / MVP +- Allocated to: Platform Adapter (Android), Audio (Android), Android Manifest +- Source SysDes: SysDes-154 (Android voice audio backend subsystem — lifecycle binding to the Android microphone-typed foreground service for background voice capture, primary), SysDes-135 (Android platform baseline, secondary/context) +- Verification method: Android Integration Test, Manifest Review +- Acceptance criteria: With the application backgrounded and a voice session active in transmit-capable state, microphone capture continues to deliver frames to the audio engine; the hosting Android service is observable via `dumpsys activity services` (or equivalent platform diagnostics) as a foreground service of type `microphone`; the manifest declares `foregroundServiceType="microphone"` on the hosting service component. +- Analysis: Feasible on API 28+ per SRS-187 / DEC-004; the foreground-service-type attribute is the platform's documented mechanism for declaring background microphone use. Verification intent (SWE.6): demonstrate that the foreground service is started before background microphone capture begins, and that capture stops if the foreground service is not granted. +- Unresolved assumptions: None at SRS layer. SRS-111 remains the higher-level foreground-service obligation; this requirement narrows it to the microphone-typed variant required by the voice transmission path. + +## 19. Updated SRS to SysDes Coverage Statement (Android Audio Backend) + +| SysDes Range | SRS Coverage | +|---|---| +| SysDes-152 (Android in-call audio mode subsystem) | Primary anchor for `SRS-208`; additionally cited as a secondary anchor by `SRS-213` (output-stream usage/content-type is the precondition for in-call-mode routing). | +| SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow) | Primary anchor for `SRS-209`. | +| SysDes-154 (Android voice audio backend subsystem) | Primary anchor for `SRS-210` (AAudio low-latency performance-mode latency tiering), `SRS-211` (voice-communication input preset with `VOICE_PERFORMANCE` fallback), `SRS-212` (hardware AEC/NS/AGC engagement with software fallback), `SRS-213` (voice-communication output usage/content-type), `SRS-214` (best-effort exclusive sharing mode with shared fallback), and `SRS-215` (microphone-typed foreground-service-hosted background capture). | +| SysDes-135 (Android platform baseline) | Retained as the secondary/context anchor on `SRS-208` through `SRS-215` (the eight Android voice-audio SRS items conceptually rest on the Android platform baseline as their platform context, but no longer take SysDes-135 as the primary derivation). Upstream SysRS items addressed across the eight items are SysRS-055, SysRS-217, SysRS-288, SysRS-305, and SysRS-306. | + + +## 20. Realtime Audio Benchmark Infrastructure (P0) + +This section authors the software-requirements layer of the realtime-audio benchmark infrastructure derived strictly from the SysDes-156 / SysDes-157 / SysDes-158 chain (per SRS-005 strict-layered sourcing). The SysDes anchors are themselves a refinement of SysRS-307 / SysRS-308 / SysRS-309, but the SRS layer does not source upstream of SysDes by policy. + +**SRS-216**: The `chanora_audio` software shall expose its realtime capture and playback paths to benchmark instrumentation that covers the five metrics enumerated by SysDes-156: (1) heap allocation count per realtime callback after a warmup window of approximately 100 callbacks (the steady-state expectation is zero allocations on the realtime thread); (2) per-callback wall-clock duration reported at the p50, p95, and p99 percentiles, expressed as a fraction of the active cpal stream period; (3) Opus encode latency measured on the canonical 960-sample / 20 ms voice frame shape; (4) Opus decode latency measured on the same 960-sample / 20 ms frame shape; and (5) resampler throughput measured at the canonical rate pairs 44.1 → 48 kHz, 16 → 48 kHz, and 48 → 48 kHz (the last serving as a passthrough control). The instrumentation shall be authored as Rust benchmarks located in a per-crate `benches/` directory (the choice of benchmark harness crate — `criterion` or equivalent — is a downstream SDD concern and is not authored here). The instrumentation shall consume the existing realtime-path public surface (for example `CaptureState::ingest`, already public at the chanora_audio crate boundary per the Wave 4 Tier A1 work) without introducing new public seams in production code; if any additional seam is required, that decision is delegated to SAD/SDD and is not authored at the SRS layer. + +- Status: Baseline Candidate +- Type: Verification Infrastructure Requirement +- Stage: P0 / MVP +- Allocated to: `chanora_audio` crate (realtime capture and playback modules, plus a co-located `benches/` directory) +- Source SysDes: SysDes-156 (realtime-audio benchmark surface allocated to SE-13) +- Verification method: SWE.4 — automated benchmark execution against the instrumentation surface; reviewers confirm the five metric families enumerated in SysDes-156 each have at least one benchmark target. +- Acceptance criteria: A `benches/` directory exists under the `chanora_audio` crate (or the SDD-decided per-crate equivalent); the directory contains benchmark targets that exercise the realtime capture callback, the realtime playback callback, the Opus encoder on a 960-sample / 20 ms frame, the Opus decoder on a 960-sample / 20 ms frame, and the resampler at each of the three canonical rate pairs; each benchmark target reports a numeric value in the unit appropriate to its metric family (count, fraction-of-period, ns/iter, or samples/sec); the benchmarks run to completion on a Linux x86_64 host in under the wall-clock budget allowed by SysDes-157's host scope (see SRS-218). +- Analysis: Feasible. The realtime path already exposes the entry points required for benchmark instrumentation per the chanora_audio crate boundary as of Wave 4 Tier A1; no production-code seam authoring is required at the SRS layer. Verification intent (SWE.6): demonstrate that all five metric families have at least one benchmark target and that the benchmarks execute deterministically on the Linux x86_64 host enumerated by SysDes-157. +- Unresolved assumptions: The exact benchmark harness crate (`criterion` is the conventional choice on the Rust ecosystem but is not authored here) and the exact target-naming convention are SDD concerns. If the realtime path requires a new public seam to be benchmarkable at SRS granularity, that gap will be discovered by the SAD/SDD pass and routed back to a future SRS revision; this clause does not authorise such a seam in production code. + +**SRS-217**: Baseline measurements produced by the SRS-216 benchmark instrumentation shall be stored as structured JSON committed to a deterministic location inside the repository, so that the baseline becomes a reviewable, version-controlled artefact rather than an ephemeral CI side effect. Each baseline record shall contain at minimum the following fields: `metric` (string identifier matching the metric name enumerated by SysDes-156), `value` (numeric — the measured value for that metric), `unit` (string — for example `"ns/iter"`, `"samples/sec"`, `"fraction"`, or `"count"`, matching the metric family), `host_arch` (string — the Rust target triple of the measurement host, for example `"x86_64-unknown-linux-gnu"`), `toolchain` (string — the rustc version active at measurement time), `git_sha` (string — the full Git commit SHA at measurement time), and `timestamp` (string — ISO-8601 UTC). The canonical on-disk path for the baseline JSON (for example `benches/baselines/.json` as a suggestion) is delegated to SDD and is not fixed at the SRS layer; however, the path shall be deterministic (the same crate at the same commit shall write to the same file) and shall be committed to the repository on the default branch. + +- Status: Baseline Candidate +- Type: Verification Infrastructure Requirement +- Stage: P0 / MVP +- Allocated to: `chanora_audio` crate (the bench harness publishes the baseline JSON), plus the SDD-decided on-disk path under the repository root. +- Source SysDes: SysDes-156 (baseline storage as structured JSON in a deterministic repo location capturing metric value, host architecture, toolchain version, git SHA, and timestamp). +- Verification method: Review — the JSON record format is review-checkable against this clause by inspecting a sample baseline file. +- Acceptance criteria: A baseline JSON file exists at the SDD-decided deterministic path on the default branch; the file is parseable as JSON; each record carries the seven fields enumerated above; the `metric` field values match the metric names declared by SysDes-156; the `host_arch`, `toolchain`, `git_sha`, and `timestamp` fields are populated with values that correspond to the measurement host and commit; the same crate at the same commit deterministically writes to the same file path. +- Analysis: Feasible. JSON is the conventional serialization format for benchmark-baseline metadata in Rust ecosystem tooling, and the fields enumerated are the minimum needed for the SysDes-157 advisory comparison to be reproducible. Verification intent (SWE.6): inspect a sample baseline file and confirm the seven fields are populated correctly and the file is parseable. +- Unresolved assumptions: The exact on-disk path is delegated to SDD per SysDes-156. The schema may evolve (additional optional fields) without breaking this clause provided the seven enumerated fields remain present. + +**SRS-218**: A continuous-integration workflow shall execute the SRS-216 benchmark suite under the constraints authored by SysDes-157, namely: (1) the workflow shall trigger on every pull request opened against the default branch and on every merge to the default branch, and shall not trigger on tag pushes or on pushes to non-default branches; (2) the workflow shall execute on the Linux x86_64 GitHub Actions runner (`ubuntu-latest`) and shall not execute on any other host architecture (multi-host benchmarking is out of scope for this revision per SysDes-157 point 2); (3) the workflow result shall be rendered as a markdown table on the pull-request surface that compares each metric enumerated by SysDes-156 against the baseline-at-merge-base (per SRS-219), with a per-metric visual marker drawn from the set { 🟢 within tolerance, 🟡 within tolerance but trending, 🔴 outside tolerance } evaluated against the per-metric tolerance window of SysDes-158; (4) the workflow shall report a `success` status check regardless of whether any metric is flagged 🔴, so that the advisory check never blocks merge (this enforces the SysDes-157 point 4 non-blocking semantics at the SRS layer); and (5) the baseline-update operation shall be a separate, manually-invoked workflow (GitHub Actions `workflow_dispatch` or equivalent), and the PR-triggered workflow authored by this clause shall never write to the baseline JSON file authored under SRS-217. + +- Status: Baseline Candidate +- Type: Verification Infrastructure Requirement +- Stage: P0 / MVP +- Allocated to: CI tooling under `.github/workflows/` (or the SDD-decided equivalent integration point) — specifically a new advisory benchmark workflow file; the exact filename is delegated to SAD/SDD. +- Source SysDes: SysDes-157 (advisory CI integration allocated to SE-18, with the six design constraints on trigger, host, surface, non-blocking semantics, baseline source, and baseline-update isolation). +- Verification method: Demo — a synthetic pull-request run shall demonstrate the workflow firing, the markdown comparison table rendering, the status check reporting `success` even when a 🔴 marker is present, and the absence of any write to the baseline JSON file under the PR-triggered path. Human reviewers confirm in the PR. +- Acceptance criteria: A CI workflow file exists at the SDD-decided path; the file's trigger configuration matches SysDes-157 point 1 (PR-against-default plus merge-to-default, no tags, no non-default-branch pushes); the workflow's `runs-on` clause is `ubuntu-latest`; a PR run posts a markdown table that lists each SysDes-156 metric with its measured value, the baseline value at the PR's merge-base, the percentage delta, and one of the three visual markers; the workflow's status check reports `success` on every run, including runs that contain at least one 🔴 marker; a separate `workflow_dispatch` workflow file exists for the baseline-update operation, and the PR-triggered workflow does not modify the baseline JSON. +- Analysis: Feasible on GitHub Actions. The advisory-only, never-block-on-failure semantics is the active rule per SysRS-308 (inherited via SysDes-157); escalating this workflow to a hard build-failing gate would require a future SysRS authorisation and is not within the scope of SRS-218. Verification intent (SWE.6): observe a synthetic PR run end-to-end and confirm the five constraints (trigger, host, surface, non-blocking semantics, baseline-update isolation). +- Unresolved assumptions: The exact workflow filename, the exact named status-check string, and the exact markdown table layout are SAD/SDD concerns. The triggering criterion for the 🟡 "trending" state is delegated to SDD per SysDes-157's notes (this clause only requires that the marker set { 🟢, 🟡, 🔴 } is present, not how 🟡 is computed). + +**SRS-219**: The advisory comparison performed by the SRS-218 workflow shall apply the per-metric tolerance window and the comparison methodology authored by SysDes-158. The tolerance window shall be evaluated per metric as follows: (a) heap allocation count per realtime callback after warmup — tolerance is zero, i.e. any non-zero allocation count on a PR is flagged 🔴; (b) per-callback wall-clock duration at p95 — tolerance is +20% relative to the baseline (p50 and p99 are advisory data only and do not drive the 🔴 marker); (c) Opus encode latency on a 960-sample / 20 ms frame — tolerance is +15% relative to the baseline on the mean; (d) Opus decode latency on a 960-sample / 20 ms frame — tolerance is +15% relative to the baseline on the mean; (e) resampler throughput on the canonical rate pairs — tolerance is −10% relative to the baseline on samples-per-second (i.e. a throughput drop greater than 10% is flagged 🔴). The comparator on a pull-request run shall be the baseline JSON committed at the pull request's merge-base commit, **not** the baseline at the current default-branch tip; this disambiguates the comparison when a PR is rebased onto a newer default and prevents a default-branch baseline update from retroactively re-classifying an in-flight PR's regression status. + +- Status: Baseline Candidate +- Type: Verification Infrastructure Requirement +- Stage: P0 / MVP +- Allocated to: CI tooling co-located with the SRS-218 workflow (the comparison logic resides in the same SE-18 surface). +- Source SysDes: SysDes-158 (per-metric tolerance window and merge-base-snapshot comparison methodology allocated to SE-18). +- Verification method: Review — the comparison logic and the tolerance table are review-checkable against this clause; a small synthetic data set (one baseline, one PR run for each of the five metric families with values at, just inside, and just outside the tolerance window) demonstrates each marker assignment. +- Acceptance criteria: The CI tooling reads the baseline JSON at the PR's merge-base commit (verifiable by observing the SHA the tooling resolves before reading the file); the comparison applies the per-metric thresholds enumerated above (heap = zero, p95 wall-clock = +20%, Opus encode mean = +15%, Opus decode mean = +15%, resampler samples/sec = −10%); the marker assignment for a synthetic value at the threshold, just inside the threshold, and just outside the threshold matches the expected 🟢 / 🟡 (where defined by SDD) / 🔴 result; rebasing a PR onto a newer default branch re-resolves the merge-base and re-reads the baseline at the new merge-base, rather than reading the default-branch-tip baseline. +- Analysis: Feasible. The merge-base resolution is a standard `git merge-base` operation; per-metric thresholds are simple numeric comparisons. The merge-base-snapshot semantics is the SysDes-158 active rule and is preferred over default-branch-tip comparison because it makes the comparator stable across rebases. Verification intent (SWE.6): observe each of the five metric families' threshold behaviour on synthetic data and confirm the merge-base SHA is the comparator anchor. +- Unresolved assumptions: None at the SRS layer. The exact representation of the 🟡 "trending" intermediate state (for example a sub-threshold band, or a multi-run trend) is delegated to SDD per SysDes-157's notes, but does not alter the 🔴 threshold rules authored here. + +### 20.1 SRS-216..219 to SysDes Coverage + +| SysDes anchor | SRS coverage | +|---|---| +| SysDes-156 (realtime-audio benchmark surface, SE-13; five metric families; baseline JSON in deterministic repo location with metric/value/unit/host_arch/toolchain/git_sha/timestamp fields) | Primary anchor for `SRS-216` (benchmark instrumentation covering the five metric families) and `SRS-217` (baseline JSON storage format). | +| SysDes-157 (advisory CI integration, SE-18; trigger on PR + merge-to-default; host = `ubuntu-latest`; markdown table with 🟢/🟡/🔴 markers; never-fail status check; baseline-update isolation via `workflow_dispatch`) | Primary anchor for `SRS-218` (CI advisory-reporting workflow). | +| SysDes-158 (per-metric tolerance window and merge-base-snapshot comparison methodology, SE-18; heap = 0, p95 wall-clock = +20%, Opus encode/decode mean = +15%, resampler samples/sec = −10%) | Primary anchor for `SRS-219` (tolerance window and comparison methodology binding). | + +### 20.2 Intentionally Out of Scope at This Revision + +Consistent with the SysRS-307 / SysRS-308 / SysRS-309 deferrals propagated through SysDes-156 / SysDes-157 / SysDes-158, this revision intentionally does **not** author the following SRS clauses, and they shall not be inferred from SRS-216 through SRS-219: + +- **Dimension 3 production telemetry export** — the runtime-export-of-metrics-from-shipped-clients dimension is deferred to P1 by SysRS, is not authorised by any SysDes-156/157/158 clause, and remains subject to SysRS-295's no-off-device-transmission rule. No SRS clause in this revision authorises such export. +- **Build-failing hard CI gate** — SysRS-308's advisory-only contract is the active rule, enforced at the SysDes layer by SysDes-157's non-blocking semantics. SRS-218 explicitly inherits that contract by requiring the status check to report `success` on every run. Escalation to a hard gate requires a future SysRS authorisation. +- **Multi-host benchmarking** — SysDes-157 point 2 fixes the host to Linux x86_64 (`ubuntu-latest`). ARM Android, macOS Apple Silicon, Windows x86_64, and any other host runner are explicitly deferred. SRS-218 inherits this constraint. + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date and preserved SRS direct-source rule through SysDes only. | + + +## Baseline Candidate 0.9.3 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.3 | 2026-05-15 | Added desktop PTT software requirements SRS-195 through SRS-203: `DesktopPttBackend` trait + per-platform implementations, `PttCapabilityLevel` enum, Windows Raw-Input ladder, macOS permission-aware backend, Linux GNOME-Wayland GlobalShortcuts portal backend, mouse-side-button support per DEC-027, `capture_active` / `transmit_active` split, sanitised diagnostics, missed-key-up watchdog per DEC-028. Sourcing remains strict (`SRS -> SysDes` only). | + + +## Baseline Candidate 0.9.5 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle software requirements SRS-204 through SRS-207 sourced from SysDes-149..151: bridge surface drops `start_audio` / `stop_audio` and adds `voice_join(channel_id)` / `voice_leave()`, audio engine opens streams on first voice-channel join and closes on last leave with output independent of mic-permission state, `TransmitMode` enum (`Ptt` default, `Continuous`, reserved `VoiceActivity` per DEC-030) persisted per identity, `release_tail_ms` (default 200, range 0–500) gate on the `true → false` transition of `transmit_active` with re-press cancellation, Voice Bar hard-mute override of `transmit_active`. Strict layered sourcing preserved (`SRS -> SysDes` only). | + + +## Baseline Candidate 0.9.6 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.9 | 2026-05-18 | Added realtime-audio benchmark-infrastructure software requirements SRS-216 through SRS-219 in a new section 20, sourced strictly from SysDes-156 / SysDes-157 / SysDes-158 (the Option B benchmark-infrastructure scope decision propagated through the Wave 1.5 benchmark chain). SRS-216 allocates benchmark instrumentation covering the five SysDes-156 metric families (heap allocation count per realtime callback after ~100-callback warmup, per-callback wall-clock at p50/p95/p99 as a fraction of cpal stream period, Opus encode latency on 960-sample/20 ms frame, Opus decode latency on the same shape, and resampler throughput at 44.1→48 / 16→48 / 48→48 kHz) to the `chanora_audio` crate's `benches/` directory; no new public seam in production code is authored. SRS-217 authors the baseline-JSON storage format (`metric`, `value`, `unit`, `host_arch`, `toolchain`, `git_sha`, `timestamp` fields at minimum) committed to a deterministic SDD-decided repo path. SRS-218 authors the CI advisory-reporting workflow under SysDes-157 (trigger on PR-against-default + merge-to-default, host = `ubuntu-latest`, markdown table with 🟢/🟡/🔴 markers, never-fail status check, baseline-update isolated to a separate `workflow_dispatch` workflow). SRS-219 binds the per-metric tolerance window of SysDes-158 (heap = 0, p95 wall-clock = +20%, Opus encode/decode mean = +15%, resampler samples/sec = −10%) and the merge-base-snapshot comparison methodology. Intentionally NOT authored consistent with the SysRS deferral chain: (a) Dimension 3 production telemetry export (deferred to P1; SysRS-295 still applies); (b) build-failing hard CI gate (SysRS-308 advisory-only rule active, SysDes-157 non-blocking semantics inherited); (c) multi-host benchmarking (SysDes-157 Linux x86_64 host-scope clause active). Strict layered sourcing preserved (`SRS -> SysDes` only per SRS-005); SysRS-307/308/309 are not cited as direct SRS sources. | +| 0.9.8 | 2026-05-18 | Retargeted the `Source SysDes` field on SRS-208, SRS-209, and SRS-210 through SRS-215 from the generic SysDes-135 (Android platform baseline) to the dedicated Android voice-audio derivation items authored by the system-architecture owner: SysDes-152 (Android in-call audio mode subsystem) is now the primary anchor for SRS-208; SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow as Permission/Voice subsystem partitioning) is now the primary anchor for SRS-209; SysDes-154 (Android voice audio backend subsystem — AAudio low-latency path, voice-communication usage/preset, hardware-effects engagement with software fallback, sharing-mode policy, FGS-hosted background mic lifecycle) is now the primary anchor for SRS-210 (latency), SRS-211 (input preset), SRS-212 (hardware AEC/NS/AGC), SRS-213 (output usage/content-type), SRS-214 (sharing mode), and SRS-215 (microphone-typed foreground service). SRS-213 additionally retains SysDes-152 as a secondary anchor because the output-stream usage is the precondition for in-call-mode routing. SysDes-135 is retained on all eight items as the secondary/context anchor (platform-baseline relationship). Section 19 coverage table updated. Strict layered sourcing preserved (`SRS -> SysDes` only). No technical or behavioural content of SRS-208 through SRS-215 was modified; this is a surgical retargeting of the `Source SysDes` field only. | +| 0.9.7 | 2026-05-18 | Added Android Audio Backend (P0) section 18 hosting SRS-210 through SRS-215 to support the platform-adapter decision to host Android voice capture/playback on a dedicated low-latency native audio backend (mirroring the iOS voice-processing-audio-unit precedent). SRS-210 sets numeric mouth-to-ear latency targets (≤150 ms on devices that return `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY`, ≤250 ms otherwise). SRS-211 mandates `AAUDIO_INPUT_PRESET_VOICE_COMMUNICATION` with `VOICE_PERFORMANCE` fallback. SRS-212 mandates engagement of hardware `AcousticEchoCanceler` / `NoiseSuppressor` / `AutomaticGainControl` on the capture session id with software-AEC fallback (closes the prior silent no-op). SRS-213 mandates `AAUDIO_USAGE_VOICE_COMMUNICATION` + `AAUDIO_CONTENT_TYPE_SPEECH` on output. SRS-214 mandates best-effort `AAUDIO_SHARING_MODE_EXCLUSIVE` with `SHARED` fallback. SRS-215 mandates microphone-typed foreground-service hosting (`foregroundServiceType="microphone"`) for backgrounded voice transmission. Added section 19 coverage statement. Strict SRS→SysDes sourcing preserved: `Source SysDes` traces via SysDes-135 (Android platform baseline) pending a SysDes revision that introduces a dedicated derivation item for the Android voice audio backend; SysRS-055, SysRS-217, SysRS-288, SysRS-305 are cited as the upstream SysRS obligations addressed. | +| 0.9.6 | 2026-05-17 | Propagated SysRS reconciliation (Wave 1.5) into SRS for P0 Android. SRS-187 minimum Android API raised from 24 to 28 per DEC-004 (ID preserved, change record added). SRS-188 verified consistent with SysRS-289 (Google Play upload-date target SDK); no rewrite required. SRS-111 (Android foreground service for active voice session), SRS-119 (Android AAB release build), and SRS-163 (Android back-navigation intent) reviewed and left unchanged — text remains unambiguous and P0/P1 scope is intact. Added SRS-208 (Android in-call audio mode engaged on voice-session connect, released on last disconnect — addresses SysRS-305) and SRS-209 (explicit `RECORD_AUDIO` runtime permission acquisition at or before voice-session activation, fail-safe to listen-only on denial — addresses SysRS-306). Strict layered sourcing preserved (`SRS -> SysDes` only); `Source SysDes` for SRS-208/209 traces via SysDes-135 pending a SysDes revision that introduces dedicated derivation items for SysRS-305/306. | diff --git a/docs/additional_docs/sysdes.md b/docs/additional_docs/sysdes.md new file mode 100644 index 0000000..81b0b9a --- /dev/null +++ b/docs/additional_docs/sysdes.md @@ -0,0 +1,3047 @@ +# Chanora SysDes — ASPICE SYS.3 System Architectural Design + +**Product name:** Chanora +**Document type:** SysDes / System Architectural Design +**Process alignment:** Automotive SPICE SYS.3 System Architectural Design +**Version:** 0.9.8 +**Status:** Baseline Candidate +**Input baseline:** Chanora SysRS v0.6 +**Target application type:** Cross-platform voice client application system +**Target client platforms:** Windows, macOS, Linux, iOS, Android +**Architecture baseline:** Flutter + Rust Core + `tsclientlib` protocol adapter + +**Repo path:** `docs/architecture/sysdes.md` --- + +## 1. Document Control + +### 1.1 Purpose + +This document defines the **system architectural design** for the Chanora application system. + +Chanora is an application, not an operating system. In this document, the word **system** means the complete Chanora application system and its runtime environment: the installed client application, operating system services, client device hardware, audio devices, network environment, external TeamSpeak 3-compatible servers, deployment environment, diagnostics, and engineering evidence. + + +**SysDes-001**: This SysDes shall establish the Chanora system architectural design and allocate all SysRS requirements to system elements. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 overall purpose, BP1, BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-002**: This SysDes shall treat Chanora as a cross-platform application system, not as an operating system. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 system boundary +- Allocated SysRS: SysRS-001, SysRS-006 through SysRS-010 + +**SysDes-003**: This SysDes shall be used as the system-level design baseline for downstream SRS, SAD, SDD, and Verification artifacts. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 communication and traceability +- Allocated SysRS: SysRS-233 through SysRS-240 + + +### 1.2 ASPICE SYS.3 Document Intent + +This SysDes is structured around the ASPICE SYS.3 intent: + +- Define static aspects of the system architecture. +- Define dynamic aspects of the system architecture. +- Analyze the system architecture and record design rationale. +- Ensure consistency and bidirectional traceability between SysRS and SysDes. +- Communicate the agreed system architecture to affected parties. + +This document is an ASPICE-style engineering artifact for Chanora. It does not claim formal Automotive SPICE assessment certification. + + +**SysDes-004**: The SysDes structure shall provide evidence for static architecture, dynamic architecture, architecture analysis, bidirectional traceability, consistency, and architecture communication. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP1 through BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + + +### 1.3 Downstream Lifecycle Relationship + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification +``` + +| Lifecycle artifact | Role | +|---|---| +| SysRS | Defines system-level requirements and runtime environment requirements. | +| SysDes | Allocates SysRS requirements to system elements and defines system architecture. | +| SRS | Derives software-only requirements from software-impacting SysDes items. SysRS traceability is inherited through SysDes and shall not be used as the direct source of an SRS requirement. | +| SAD | Defines software architecture for software elements. | +| SDD | Defines detailed module, interface, data, and implementation design. | +| Verification | Proves requirements and designs through the chained relationship `SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification`. | + + + +### 1.4 SysDes Design Item Attribute Model + +Every `SysDes-XXX` design item shall include the following attributes. + +| Attribute | Meaning | Typical values | +|---|---|---| +| Status | Maturity of the design item | Draft, Baseline, Agreed, Deprecated | +| Type | Design item classification | Functional Dynamic Design, Non-functional Architecture Design, Interface Design, Static Architecture Design, System Element Allocation, Architectural Constraint, Architecture Decision / Rationale, Allocation Rule, Process / Description, Verification Handoff | +| Stage | Delivery stage where the design item must be satisfied | P0 / MVP, P1 / Beta, P2 / Production, P3 / Future | +| Allocated to | System element or responsibility owner that implements/enables the design item | Software, Platform, Hardware, Network, External Server, Deployment / Operations, Product / Legal, Verification | +| Downstream artifact | Lifecycle artifact that must refine or consume this design item | SRS, SAD, SDD, Verification | +| Verification method | How the design item will be verified | Review, Inspection, Analysis, Test, Integration Test, System Test, Demo, Audit | +| Verification owner | Role primarily responsible for verification evidence | System Engineering, Software QA, Audio / Platform QA, Protocol / Integration QA, Security / QA, Release / Operations QA | +| ASPICE SYS.3 alignment | Related ASPICE SYS.3 intent or base practice area | Static architecture, dynamic architecture, analysis, traceability/consistency, communication | +| Allocated SysRS | Upstream SysRS requirement IDs covered by the SysDes design item. This attribute is for SysDes-level traceability only and shall not be copied as the direct source of an SRS requirement. | `SysRS-001`, ranges, or grouped IDs | +| SWE.1 handoff rule | Indicates how downstream SRS shall consume the SysDes item | Direct software requirement input, software-facing constraint, verification input, non-software assumption, or no SWE.1 handoff | + +Important allocation and downstream traceability rules: + +- `Allocated to` identifies the system element or engineering responsibility that realizes the design item. +- `Verification owner` identifies who proves that the design item is satisfied. +- `Test` is normally a verification responsibility, not the implementation allocation, except for explicit verification-handoff items. +- `Allocated SysRS` belongs to SysDes only. It provides SysRS-to-SysDes traceability required by system architectural design. +- Downstream SRS requirements shall use `Source SysDes` as their direct upstream reference. +- Downstream SRS requirements shall not use `Source SysRS` as their direct upstream reference. +- If a software requirement appears to come directly from SysRS and cannot be derived from an existing SysDes item, the SysDes is incomplete and shall be updated before the SRS is baselined. + + +### 1.5 Downstream SRS Derivation Rule + +The SysDes is the architectural allocation layer between SysRS and SRS. + +Correct downstream traceability: + +```text +SysRS-XXX -> SysDes-YYY -> SRS-ZZZ +``` + +Incorrect downstream traceability: + +```text +SysRS-XXX -> SRS-ZZZ +``` + +The SRS shall not reinterpret system requirements directly. It shall derive software requirements from SysDes design items that are allocated to software, contain software-facing constraints, or provide verification handoff for software behavior. + +If the software team identifies a required software behavior directly from SysRS and no SysDes design item represents it, this is a SysDes gap. The correction shall be made in SysDes first, then the SRS shall be updated from the corrected SysDes baseline. + + +## 2. ASPICE SYS.3 Alignment + +### 2.1 SYS.3 Work Products in This Document + +| ASPICE SYS.3 evidence need | Location in this SysDes | +|---|---| +| System architectural design | Sections 4 through 12 | +| Interface definitions | Section 6 | +| Dynamic behavior | Section 7 | +| Requirements allocation | Section 10 and Appendix A | +| Bidirectional traceability | Section 10 and Appendix A | +| Architecture analysis and rationale | Section 8 | +| Communication and review evidence | Section 11 | +| Verification handoff | Section 12 | + + +**SysDes-005**: The SysDes shall identify system elements, their responsibilities, their relationships, and their external interfaces. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1 static aspects +- Allocated SysRS: SysRS-024 through SysRS-034, SysRS-200 through SysRS-210 + +**SysDes-006**: The SysDes shall describe dynamic behavior for connection, synchronization, voice transmission, voice reception, text messaging, reconnect, permissions, diagnostics, and release operation. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 dynamic aspects +- Allocated SysRS: SysRS-102 through SysRS-120, SysRS-129 through SysRS-139 + +**SysDes-007**: The SysDes shall include architecture analysis, major design rationale, known risks, mitigations, and special characteristics. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 analysis +- Allocated SysRS: SysRS-178 through SysRS-191, SysRS-219 through SysRS-224 + +**SysDes-008**: The SysDes shall maintain bidirectional traceability between every SysRS requirement and at least one allocated system element. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 traceability and consistency +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-009**: The SysDes shall identify affected parties for review, agreement, and communication of the system architecture. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP5 communication +- Allocated SysRS: SysRS-011 through SysRS-015, SysRS-233 through SysRS-240 + + +## 3. System Architectural Design Criteria + +The architecture is evaluated against the following criteria. + + +**SysDes-010**: The architecture shall separate user interface, protocol logic, state synchronization, audio processing, storage, diagnostics, and platform-specific services. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-003, SysRS-004, SysRS-024 through SysRS-034 + +**SysDes-011**: The architecture shall isolate direct `tsclientlib` usage inside the protocol adapter. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-005, SysRS-121 through SysRS-128 + +**SysDes-012**: The architecture shall support required target platforms through shared Flutter UI, shared Rust Core, and platform-specific adapters. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-002, SysRS-048 through SysRS-058 + +**SysDes-013**: The architecture shall support production-grade audio processing including Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2, BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-250 through SysRS-253 + +**SysDes-014**: The architecture shall support real-time voice behavior without placing real-time audio processing in Flutter UI. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2, BP3 +- Allocated SysRS: SysRS-178 through SysRS-191 + +**SysDes-015**: The architecture shall support secure local handling of identities, passwords, and diagnostics. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-140 through SysRS-167 + +**SysDes-016**: The architecture shall support operation without a Chanora-operated central backend in MVP. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-016 through SysRS-023 + +**SysDes-017**: The architecture shall provide traceable verification hooks for protocol, state, audio, security, packaging, and platform behavior. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-233 through SysRS-257 + + +## 4. Static System Architecture + +### 4.1 System Context + +```text ++-------------------------------------------------------------------------------------+ +| User Runtime Environment | +| | +| +--------------------+ +--------------------------------------------------+ | +| | User / Operator |<----->| Chanora Client Application | | +| +--------------------+ | | | +| | +----------------+ +-------------------------+ | | +| +--------------------+ | | Flutter UI | | Rust Core | | | +| | Audio Hardware |<----->| | Flutter State | | Connection Manager | | | +| | Mic / Headset | | | Bridge Layer | | Protocol / State / | | | +| | Speaker / BT | | +----------------+ | Audio / Storage / Diag | | | +| +--------------------+ | +-------------------------+ | | +| | | | | +| +--------------------+ | +------------------------------v----------------+ | | +| | OS Services |<----->| | Platform Adapters / Secure Storage / Audio | | | +| +--------------------+ | +------------------------------------------------+ | | +| +-------------------------|------------------------+ | +| | Network | ++---------------------------------------------------------|-----------------------------+ + v + +--------------------------------------------------+ + | External TeamSpeak 3-compatible Voice Server | + | Channels / Clients / Voice / Text / Events | + +--------------------------------------------------+ +``` + + +**SysDes-018**: The static architecture shall define Chanora as a client application system interacting with users, audio hardware, OS services, networks, deployment environments, and external compatible voice servers. + +- Status: Baseline +- Type: Static Architecture Description +- Stage: P0 / MVP +- Allocated to: External Server, Software: Audio Subsystem, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-001 through SysRS-023 + + +### 4.2 System Elements + +| Element ID | Element | Description | Type | +|---|---|---|---| + +| SE-01 | User and Operator | Human users who operate Chanora, provide server details, manage permissions, and initiate diagnostic export. | External actor | + +| SE-02 | Client Device Hardware | Physical device running Chanora, including CPU, memory, storage, network interfaces, microphone, speaker/headphone, and optional Bluetooth/USB audio devices. | External runtime element | + +| SE-03 | Operating System Services | OS services used by Chanora: permissions, secure storage, audio stack, network stack, notifications, windowing, lifecycle, foreground service, app sandboxing, signing/runtime policies. | External runtime element | + +| SE-04 | Network Environment | IP network path between client and external compatible server, including DNS, routing, NAT, firewall, VPN, Wi-Fi, cellular, and ISP behavior. | External runtime element | + +| SE-05 | External Compatible Voice Server | TeamSpeak 3-compatible external server providing channels, clients, identity authentication, voice packets, text messages, permissions, and events. | External system | + +| SE-06 | Chanora Application Container | Installed Chanora client application package on each target platform. Owns app lifecycle at the application boundary. | System element | + +| SE-07 | Flutter UI Layer | Cross-platform user interface for connection, channel tree, chat, voice controls, settings, permissions, and diagnostics. | Software system element | + +| SE-08 | Flutter State Layer | UI-facing state model derived from Rust Core events and snapshots; owns only presentation state. | Software system element | + +| SE-09 | Flutter-Rust Bridge Layer | Generated/native bridge for commands, DTOs, asynchronous calls, event streams, and error propagation between Flutter and Rust Core. | Software system element | + +| SE-10 | Rust Core and Connection Manager | Authoritative application core coordinating connection actors, commands, events, storage, audio, diagnostics, and business rules. | Software system element | + +| SE-11 | Protocol Adapter using tsclientlib | Protocol subsystem wrapping `tsclientlib`, isolating protocol library types, errors, events, and voice packet operations. | Software system element | + +| SE-12 | State Synchronization Engine | Snapshot + delta state model, deterministic reducers, connection state machine, event ordering, and replayable state behavior. | Software system element | + +| SE-13 | Audio Subsystem | Capture/playback coordination, Opus-compatible encoding/decoding, jitter buffer, mixer, push-to-talk, mute/deaf, level metering, and required processing features. | Software system element | + +| SE-14 | Platform Adapter Layer | Platform-specific adapters for audio devices, permissions, lifecycle, notifications, secure storage integration, and release-specific services. | Software/platform system element | + +| SE-15 | Local Data Store | Embedded local database or equivalent storage for bookmarks, recent servers, audio settings, UI settings, per-user volume and mute preferences. | Software/data system element | + +| SE-16 | Secure Storage Provider | Platform secure storage integration for identity private keys, server passwords, and future sensitive tokens. | Software/platform system element | + +| SE-17 | Diagnostics and Observability | Structured logs, redaction, event recording, event replay, network diagnostics, audio diagnostics, diagnostic bundle export. | Software/process support element | + +| SE-18 | Deployment and Release Environment | Packaging, signing, notarization, app-store release, installers, Linux packages, CI/CD, release metadata, and distribution artifacts. | Operational system element | + +| SE-19 | Engineering Process and Evidence | Architecture reviews, traceability records, verification evidence, compatibility matrix, open decisions, and downstream SRS/SAD/SDD/Verification artifacts. | Process/evidence element | + + + +### 4.3 Element Responsibilities and Allocation Rationale + + +**SysDes-019**: SE-01 User and Operator shall be a defined system element in the Chanora architecture with responsibility for: Human users who operate Chanora, provide server details, manage permissions, and initiate diagnostic export. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: User / Operator, Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-011 through SysRS-015, SysRS-102 through SysRS-120 + +**SysDes-020**: SE-02 Client Device Hardware shall be a defined system element in the Chanora architecture with responsibility for: Physical device running Chanora, including CPU, memory, storage, network interfaces, microphone, speaker/headphone, and optional Bluetooth/USB audio devices. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Hardware, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-035 through SysRS-047, SysRS-178 through SysRS-191 + +**SysDes-021**: SE-03 Operating System Services shall be a defined system element in the Chanora architecture with responsibility for: OS services used by Chanora: permissions, secure storage, audio stack, network stack, notifications, windowing, lifecycle, foreground service, app sandboxing, signing/runtime policies. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Platform, Software: Audio Subsystem, Platform Secure Storage +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-048 through SysRS-058, SysRS-153 through SysRS-167 + +**SysDes-022**: SE-04 Network Environment shall be a defined system element in the Chanora architecture with responsibility for: IP network path between client and external compatible server, including DNS, routing, NAT, firewall, VPN, Wi-Fi, cellular, and ISP behavior. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Network +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-075 through SysRS-087 + +**SysDes-023**: SE-05 External Compatible Voice Server shall be a defined system element in the Chanora architecture with responsibility for: TeamSpeak 3-compatible external server providing channels, clients, identity authentication, voice packets, text messages, permissions, and events. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: External Server, Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-088 through SysRS-101 + +**SysDes-024**: SE-06 Chanora Application Container shall be a defined system element in the Chanora architecture with responsibility for: Installed Chanora client application package on each target platform. Owns app lifecycle at the application boundary. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software, Platform +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-001 through SysRS-010, SysRS-225 through SysRS-232 + +**SysDes-025**: SE-07 Flutter UI Layer shall be a defined system element in the Chanora architecture with responsibility for: Cross-platform user interface for connection, channel tree, chat, voice controls, settings, permissions, and diagnostics. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-003, SysRS-102 through SysRS-120, SysRS-200 through SysRS-206 + +**SysDes-026**: SE-08 Flutter State Layer shall be a defined system element in the Chanora architecture with responsibility for: UI-facing state model derived from Rust Core events and snapshots; owns only presentation state. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Flutter State, Software: Rust Core, Software: State Sync +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-024 through SysRS-034, SysRS-129 through SysRS-139 + +**SysDes-027**: SE-09 Flutter-Rust Bridge Layer shall be a defined system element in the Chanora architecture with responsibility for: Generated/native bridge for commands, DTOs, asynchronous calls, event streams, and error propagation between Flutter and Rust Core. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-024 through SysRS-034, SysRS-200 through SysRS-210 + +**SysDes-028**: SE-10 Rust Core and Connection Manager shall be a defined system element in the Chanora architecture with responsibility for: Authoritative application core coordinating connection actors, commands, events, storage, audio, diagnostics, and business rules. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-004, SysRS-102 through SysRS-139, SysRS-178 through SysRS-191 + +**SysDes-029**: SE-11 Protocol Adapter using tsclientlib shall be a defined system element in the Chanora architecture with responsibility for: Protocol subsystem wrapping `tsclientlib`, isolating protocol library types, errors, events, and voice packet operations. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-005, SysRS-088 through SysRS-128, SysRS-241 + +**SysDes-030**: SE-12 State Synchronization Engine shall be a defined system element in the Chanora architecture with responsibility for: Snapshot + delta state model, deterministic reducers, connection state machine, event ordering, and replayable state behavior. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-129 through SysRS-139, SysRS-233 through SysRS-240 + +**SysDes-031**: SE-13 Audio Subsystem shall be a defined system element in the Chanora architecture with responsibility for: Capture/playback coordination, Opus-compatible encoding/decoding, jitter buffer, mixer, push-to-talk, mute/deaf, level metering, and required processing features. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-178 through SysRS-191, SysRS-242 through SysRS-253 + +**SysDes-032**: SE-14 Platform Adapter Layer shall be a defined system element in the Chanora architecture with responsibility for: Platform-specific adapters for audio devices, permissions, lifecycle, notifications, secure storage integration, and release-specific services. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-048 through SysRS-074, SysRS-153 through SysRS-167 + +**SysDes-033**: SE-15 Local Data Store shall be a defined system element in the Chanora architecture with responsibility for: Embedded local database or equivalent storage for bookmarks, recent servers, audio settings, UI settings, per-user volume and mute preferences. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Software: Storage +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-140 through SysRS-152, SysRS-255 + +**SysDes-034**: SE-16 Secure Storage Provider shall be a defined system element in the Chanora architecture with responsibility for: Platform secure storage integration for identity private keys, server passwords, and future sensitive tokens. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Platform Secure Storage +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-140 through SysRS-167, SysRS-256 + +**SysDes-035**: SE-17 Diagnostics and Observability shall be a defined system element in the Chanora architecture with responsibility for: Structured logs, redaction, event recording, event replay, network diagnostics, audio diagnostics, diagnostic bundle export. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-168 through SysRS-177, SysRS-257 + +**SysDes-036**: SE-18 Deployment and Release Environment shall be a defined system element in the Chanora architecture with responsibility for: Packaging, signing, notarization, app-store release, installers, Linux packages, CI/CD, release metadata, and distribution artifacts. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Storage, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Release / Operations QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-192 through SysRS-199 + +**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. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-233 through SysRS-240, SysRS-219 through SysRS-224 + + +### 4.4 Layered Static Decomposition + +```text ++-------------------------------------------------------------+ +| SE-07 Flutter UI Layer | ++-------------------------------------------------------------+ +| SE-08 Flutter State Layer | ++-------------------------------------------------------------+ +| SE-09 Flutter-Rust Bridge Layer | ++-------------------------------------------------------------+ +| SE-10 Rust Core and Connection Manager | +| + SE-11 Protocol Adapter using tsclientlib | +| + SE-12 State Synchronization Engine | +| + SE-13 Audio Subsystem | +| + SE-15 Local Data Store | +| + SE-16 Secure Storage Provider | +| + SE-17 Diagnostics and Observability | ++-------------------------------------------------------------+ +| SE-14 Platform Adapter Layer | ++-------------------------------------------------------------+ +| External Runtime Elements: SE-02, SE-03, SE-04, SE-05 | ++-------------------------------------------------------------+ +``` + + +**SysDes-038**: The architecture shall use a layered decomposition in which Flutter UI and Flutter State Layer communicate with Rust Core only through the Bridge Layer. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-003, SysRS-024 through SysRS-034, SysRS-200 through SysRS-210 + +**SysDes-039**: The architecture shall place protocol, state synchronization, audio processing, storage coordination, diagnostics, and business rules inside Rust Core or Rust Core-owned elements. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-004, SysRS-024 through SysRS-034 + +**SysDes-040**: The architecture shall prevent Flutter UI and Flutter State Layer from invoking `tsclientlib` or depending on raw `tsclientlib` types. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-005, SysRS-121 through SysRS-128, SysRS-211 + +**SysDes-041**: The architecture shall place real-time audio processing outside Flutter UI and inside the Rust Core audio subsystem or platform-native audio processing adapters. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-178 through SysRS-191 + + +## 5. System Requirement Allocation Strategy + +### 5.1 Allocation Rules + + +**SysDes-042**: Every SysRS requirement shall be allocated to at least one system element. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-043**: A SysRS requirement may be allocated to multiple system elements when the requirement depends on cooperation between application software, OS services, hardware, network, external server, deployment, or engineering evidence. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: External Server, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-044**: Functional user-facing requirements shall be allocated to Flutter UI, Rust Core, and the relevant subsystem element that executes the behavior. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-102 through SysRS-120 + +**SysDes-045**: Runtime environment requirements shall be allocated to client device hardware, operating system services, platform adapters, network environment, or external compatible server elements. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Hardware, Platform, Network +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-035 through SysRS-101 + +**SysDes-046**: Security, privacy, and diagnostics requirements shall be allocated to secure storage, diagnostics, platform adapters, and engineering process evidence. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-153 through SysRS-177 + +**SysDes-047**: MVP acceptance requirements shall be allocated to the system elements that implement or enable the accepted behavior. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-241 through SysRS-257 + + +### 5.2 Allocation Summary by Requirement Group + +| SysRS Range | Requirement Topic | Primary System Elements | +|---|---|---| +| SysRS-001 through SysRS-010 | Application system scope | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16 | +| SysRS-011 through SysRS-015 | Stakeholders and user environment | SE-01, SE-07, SE-17, SE-19 | +| SysRS-016 through SysRS-023 | Boundaries and external dependencies | SE-03, SE-04, SE-05, SE-14, SE-18 | +| SysRS-024 through SysRS-034 | Application components | SE-06 through SE-17 | +| SysRS-035 through SysRS-047 | Client device and hardware | SE-02, SE-03, SE-04, SE-13, SE-14 | +| SysRS-048 through SysRS-058 | Operating system services | SE-03, SE-14, SE-18 | +| SysRS-059 through SysRS-074 | Audio hardware and processing | SE-02, SE-03, SE-13, SE-14 | +| SysRS-075 through SysRS-087 | Network environment | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | +| SysRS-088 through SysRS-101 | External compatible server | SE-05, SE-11, SE-12, SE-13 | +| SysRS-102 through SysRS-120 | Application functional behavior | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16 | +| SysRS-121 through SysRS-128 | Protocol integration | SE-11, SE-19 | +| SysRS-129 through SysRS-139 | State synchronization | SE-10, SE-12, SE-09, SE-19 | +| SysRS-140 through SysRS-152 | Data and storage | SE-15, SE-16, SE-17, SE-14 | +| SysRS-153 through SysRS-167 | Security and privacy | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | +| SysRS-168 through SysRS-177 | Diagnostics and operations | SE-17, SE-19 | +| SysRS-178 through SysRS-191 | Non-functional requirements | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | +| SysRS-192 through SysRS-199 | Deployment and release | SE-18, SE-19 | +| SysRS-200 through SysRS-210 | Interfaces | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11, SE-13, SE-14, SE-15, SE-16, SE-17 | +| SysRS-211 through SysRS-218 | Constraints | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | +| SysRS-219 through SysRS-224 | Assumptions | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19 | +| SysRS-225 through SysRS-232 | Out of scope for MVP | SE-06, SE-13, SE-19 | +| SysRS-233 through SysRS-240 | Verification and validation | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | +| SysRS-241 through SysRS-257 | MVP acceptance | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | + + +## 6. Interface Definitions + +### 6.1 Interface Catalogue + +| Interface ID | Interface | Provider | Consumer | Main Data / Signals | Failure Handling | +|---|---|---|---|---|---| +| IF-001 | User Interface | SE-07 | SE-01 | UI events, status, forms, controls, errors | UI-safe error banner/dialog | +| IF-002 | Flutter State Interface | SE-08 | SE-07 | View models, UI state, derived lists | State reset or stale-state overlay | +| IF-003 | Flutter-Rust Command Interface | SE-09 | SE-07/SE-08 | Commands, DTOs, request IDs | Error DTO, timeout, cancellation | +| IF-004 | Rust Core Event Interface | SE-10/SE-09 | SE-08 | Core events, snapshots, deltas | Stream reconnect/resubscribe | +| IF-005 | Protocol Adapter Interface | SE-11 | SE-10 | Connect, join, message, voice, events | ProtocolError mapping | +| IF-006 | External Server Protocol Interface | SE-05 | SE-11 | TeamSpeak-compatible protocol traffic | Network/protocol error mapping | +| IF-007 | Audio Capture Interface | SE-14/SE-03/SE-02 | SE-13 | PCM frames, device events | Device error, fallback, mute | +| IF-008 | Audio Playback Interface | SE-13 | SE-14/SE-03/SE-02 | Mixed PCM frames, route state | Device error, fallback, deaf | +| IF-009 | Secure Storage Interface | SE-16/SE-03 | SE-10/SE-15 | Identity secrets, passwords | SecureStoreError, user re-auth | +| IF-010 | Local Data Store Interface | SE-15 | SE-10/SE-07 | Bookmarks, recent servers, settings | StorageError, repair/migration | +| IF-011 | Diagnostics Export Interface | SE-17 | SE-01/SE-19 | Redacted diagnostic bundle | Export failure message | +| IF-012 | Deployment Interface | SE-18 | SE-01/SE-03 | Installer/package/app-store artifact | Platform installer/store error | +| IF-013 | Network Interface | SE-04 | SE-11/SE-17 | IP connectivity, DNS, latency, packet loss | Reconnect or user-safe error | +| IF-014 | Permission Interface | SE-03/SE-14 | SE-07/SE-10 | Microphone, notification, foreground service | Permission explainer and blocked state | + +**SysDes-048**: IF-001 User Interface shall expose connection, bookmark, channel tree, online client, chat, voice control, audio setting, permission, and diagnostic workflows. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-102 through SysRS-120, SysRS-200 through SysRS-206 + +**SysDes-049**: IF-003 Flutter-Rust Command Interface shall use bridge-safe DTOs and shall not expose raw protocol or `tsclientlib` types. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Bridge, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-121 through SysRS-128, SysRS-200 through SysRS-210 + +**SysDes-050**: IF-004 Rust Core Event Interface shall deliver connection status, snapshots, deltas, voice indicators, errors, and diagnostic events as typed streams. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2 +- Allocated SysRS: SysRS-129 through SysRS-139 + +**SysDes-051**: IF-005 Protocol Adapter Interface shall isolate all direct `tsclientlib` operations and convert protocol data into Chanora internal data structures. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-121 through SysRS-128 + +**SysDes-052**: IF-006 External Server Protocol Interface shall use `tsclientlib` to communicate with reachable TeamSpeak 3-compatible external servers. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: External Server, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-005, SysRS-088 through SysRS-101 + +**SysDes-053**: IF-007 Audio Capture Interface shall provide PCM capture frames, device state, route changes, and capture errors to the audio subsystem. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-059 through SysRS-074 + +**SysDes-054**: IF-008 Audio Playback Interface shall provide mixed PCM playback frames, playback reference for echo cancellation where required, and playback route events. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-059 through SysRS-074 + +**SysDes-055**: IF-009 Secure Storage Interface shall store identity private keys, server passwords, and future sensitive tokens through platform-secure mechanisms. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Storage, Platform Secure Storage +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-140 through SysRS-167 + +**SysDes-056**: IF-010 Local Data Store Interface shall persist non-secret data through SQLite or an equivalent embedded database. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Storage +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-140 through SysRS-152 + +**SysDes-057**: IF-011 Diagnostics Export Interface shall export user-initiated diagnostic bundles with redaction applied before export. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-168 through SysRS-177 + +**SysDes-058**: IF-013 Network Interface shall provide connectivity to external compatible servers and network diagnostic inputs for reconnect and troubleshooting. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2 +- Allocated SysRS: SysRS-075 through SysRS-087 + +**SysDes-059**: IF-014 Permission Interface shall mediate microphone, notification, audio session, foreground service, and lifecycle permission behavior on supported platforms. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2 +- Allocated SysRS: SysRS-048 through SysRS-058, SysRS-153 through SysRS-167 + + +## 7. Dynamic Architecture + +### 7.1 System Modes and States + +| State / Mode | Owner | Description | +|---|---|---| +| Not Installed | SE-18 | Application has not been installed on the client device. | +| Installed / Not Running | SE-06 | Application is installed but not active. | +| Running / Disconnected | SE-06, SE-07, SE-10 | App is active with no server connection. | +| Connecting | SE-10, SE-11 | User has started connection and protocol setup is in progress. | +| Synchronizing | SE-10, SE-11, SE-12 | Protocol connection exists and snapshot is being built. | +| Connected | SE-10, SE-11, SE-12 | Snapshot is ready and live deltas are being applied. | +| Voice Active | SE-13, SE-14 | User is in a voice channel and capture/playback pipelines are active. | +| Reconnecting | SE-10, SE-11, SE-12 | Recoverable failure triggered reconnect policy. | +| Permission Blocked | SE-03, SE-07, SE-14 | Required permission is missing or denied. | +| Diagnostics Export | SE-17 | User-initiated diagnostic export is in progress. | +| Release/Update | SE-18 | Deployment or update process is active. | + + +**SysDes-060**: The connection state machine shall be owned by Rust Core and reflected to Flutter as UI-safe connection status events. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-129 through SysRS-139 + +**SysDes-061**: The voice activity mode shall be active only when a channel context, audio device state, permission state, and protocol voice path are valid. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-241 through SysRS-253 + +**SysDes-062**: The permission-blocked mode shall prevent unsafe voice operations while preserving user visibility into corrective actions. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-153 through SysRS-167 + +**SysDes-063**: The reconnect mode shall preserve UI responsiveness and rebuild authoritative server state from a fresh snapshot after reconnect. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-075 through SysRS-087, SysRS-129 through SysRS-139 + +**SysDes-064**: The diagnostics export mode shall be explicitly user-initiated and shall apply redaction before export. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-168 through SysRS-177, SysRS-257 + + +### 7.2 Dynamic Flow: Manual Connection and Initial Snapshot + +```text +User -> Flutter UI -> Bridge -> Rust Core -> Protocol Adapter -> External Server +External Server -> Protocol Adapter -> Rust Core -> State Engine -> Bridge -> Flutter State -> UI +``` + + +**SysDes-065**: Manual connection flow shall pass host, port, nickname, optional password, and identity reference from Flutter UI to Rust Core through bridge DTOs. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-102 through SysRS-105 + +**SysDes-066**: Rust Core shall use the protocol adapter to establish server connection and authentication through `tsclientlib`. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-088 through SysRS-101, SysRS-121 through SysRS-128 + +**SysDes-067**: Initial synchronization shall fetch server information, channel list, client list, and required self-client information before emitting a full snapshot. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-129 through SysRS-133 + +**SysDes-068**: Live server events shall be converted into internal events, applied through deterministic reducers, and emitted as UI-safe delta events. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-130 through SysRS-136 + +**SysDes-069**: Channel join flow shall wait for Rust Core/protocol confirmation before treating the UI state as authoritative. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-108, SysRS-116, SysRS-244 + +**SysDes-070**: Text message flow shall route user text from Flutter to Rust Core to protocol adapter and route received messages back as core events. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-110, SysRS-119, SysRS-254 + +**SysDes-071**: Outgoing voice flow shall capture PCM frames, apply required processing, encode voice, and send voice packets through the protocol adapter. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-242 + +**SysDes-072**: Incoming voice flow shall receive voice packets, jitter-buffer, decode, apply per-user controls, mix, and play through platform playback. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-243 + +**SysDes-073**: User-triggered disconnect flow shall transition to Disconnected and shall suppress automatic reconnect. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-106, SysRS-138, SysRS-217 + +**SysDes-074**: Recoverable network failure flow shall transition to Reconnecting, apply reconnect policy, and rebuild state from a fresh snapshot. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-085 through SysRS-087, SysRS-137 + +**SysDes-075**: Audio device change flow shall report route/device changes through platform adapters and shall recover or enter a user-safe blocked/degraded state. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-063, SysRS-064, SysRS-188 + +**SysDes-076**: Secure storage flow shall store and retrieve secrets through platform secure storage without exposing plaintext secrets to logs or diagnostic export. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-148 through SysRS-167 + + +## 8. Architecture Analysis and Design Rationale + +### 8.1 Major Design Decisions + +| Decision ID | Decision | Rationale | Main Risk | Mitigation | +|---|---|---|---|---| +| ADR-001 | Flutter + Rust Core | Cross-platform UI with shared protocol/audio/state core | Bridge complexity | Typed DTOs, generated bridge, event streams | +| ADR-002 | `tsclientlib` protocol adapter | Required protocol library and Rust-native integration | Library maturity or feature gaps | Adapter isolation, protocol probe, compatibility matrix | +| ADR-003 | Snapshot + delta state synchronization | Stable state recovery and replayable debugging | Event ordering bugs | Single connection actor, reducer tests, event replay | +| ADR-004 | Audio subsystem outside Flutter | Real-time audio processing and low latency | Platform audio variance | Platform adapters and backend abstraction | +| ADR-005 | Required audio processing features | Voice quality: Echo Canceller, AGC, Noise Suppression, HPF | Feature availability differs by platform | Backend abstraction and platform-specific validation | +| ADR-006 | Platform secure storage | Protect identities and passwords | Platform API variance | SecureStore trait and per-platform adapters | +| ADR-007 | No Chanora central backend for MVP | Simplifies privacy, operations, and system boundary | No cloud sync | Defer cloud sync beyond MVP | +| ADR-008 | External compatible server as external system | Chanora is client-only and not server operator | Server behavior varies | Protocol probe, compatibility matrix, user-safe errors | + + +**SysDes-077**: The architecture shall select Flutter + Rust Core to meet cross-platform UI requirements while centralizing protocol, state, audio, storage, and diagnostics logic. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-001 through SysRS-010 + +**SysDes-078**: The architecture shall isolate `tsclientlib` inside the protocol adapter to reduce impact if protocol implementation must be patched, forked, or replaced. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-121 through SysRS-128, SysRS-220 + +**SysDes-079**: The architecture shall use snapshot + delta synchronization to support deterministic state recovery, reconnect behavior, event replay, and UI consistency. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: State Sync, System Engineering, Verification +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-129 through SysRS-139 + +**SysDes-080**: The architecture shall use platform adapters to isolate OS-specific permission, audio routing, lifecycle, secure storage, notification, and packaging concerns. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-048 through SysRS-058, SysRS-153 through SysRS-167 + +**SysDes-081**: The architecture shall implement audio processing through a backend abstraction that supports platform-native and Rust-based processing options. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-178 through SysRS-191 + +**SysDes-082**: The architecture shall define external compatible server behavior as an external dependency and shall not assume control over server-side permissions, availability, or configuration. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Platform +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-088 through SysRS-101, SysRS-223 + +**SysDes-083**: The architecture shall not introduce Chanora-operated backend infrastructure for MVP voice, channel, or text operation. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-017, SysRS-218 + +**SysDes-084**: The architecture shall treat real-time audio behavior, secure secret storage, protocol compatibility, mobile lifecycle policy, diagnostic redaction, and release signing as special characteristics requiring explicit verification. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-153 through SysRS-199, SysRS-233 through SysRS-257 + + +### 8.2 Special Characteristics + +| Characteristic | Affected Elements | Design Handling | +|---|---|---| +| Real-time voice latency | SE-02, SE-03, SE-13, SE-14 | Audio pipeline outside Flutter, low-latency platform adapters, Opus-compatible codec, jitter buffer | +| Echo cancellation quality | SE-02, SE-03, SE-13, SE-14 | Playback reference support, backend abstraction, per-platform validation | +| Protocol compatibility | SE-05, SE-11 | `tsclientlib` adapter, protocol probe, compatibility matrix | +| Secure identity handling | SE-03, SE-16 | Platform secure storage, no plaintext private keys | +| Diagnostic privacy | SE-17, SE-19 | Redaction before export, user-initiated export | +| Mobile foreground voice | SE-03, SE-14 | AVAudioSession, Android foreground service, lifecycle handling | +| Release trust | SE-18 | Signing, notarization, app-store release metadata review | + + +## 9. Resource, Performance, Reliability, Security, and Deployment Design + + +**SysDes-085**: The architecture shall allocate UI responsiveness to Flutter UI, Bridge Layer, Rust Core asynchronous command handling, and non-blocking reconnect behavior. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-178, SysRS-179, SysRS-187 + +**SysDes-086**: The architecture shall allocate local audio latency requirements to client device hardware, OS audio stack, platform adapters, audio subsystem, codec processing, and network environment. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Hardware, Network, Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-180, SysRS-181 + +**SysDes-087**: The architecture shall allocate memory growth constraints to Rust Core queue management, diagnostics log retention, chat history limits, and audio buffer bounds. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-182 through SysRS-186 + +**SysDes-088**: The architecture shall allocate reliability recovery requirements to Rust Core reconnect policy, protocol adapter error mapping, state engine snapshot replacement, and platform audio recovery. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-187 through SysRS-191 + +**SysDes-089**: The architecture shall allocate security requirements to platform secure storage, secret redaction, diagnostics redaction, user-safe error mapping, and input validation. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Platform Secure Storage, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Audit +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-153 through SysRS-167 + +**SysDes-090**: The architecture shall allocate privacy requirements to user-controlled diagnostics, minimal data collection, and permission explainers. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Audit +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-163 through SysRS-167 + +**SysDes-091**: The architecture shall allocate packaging and release requirements to deployment environment, signing/notarization/app-store packaging, and release metadata review. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Storage, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Demo +- Verification owner: Release / Operations QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-192 through SysRS-199 + + +## 10. Bidirectional Traceability and Consistency + +### 10.1 Traceability Rules + + +**SysDes-092**: Each SysRS requirement shall trace forward to one or more system elements and to one or more SysDes design items with Type, Stage, Allocation, and Verification attributes. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-093**: Each system element shall trace backward to one or more SysRS requirements unless explicitly marked as supporting infrastructure. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-094**: Each interface shall trace backward to the SysRS requirements that require the interaction or runtime dependency. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-200 through SysRS-210 + +**SysDes-095**: Each dynamic flow shall trace backward to the SysRS functional, state, performance, security, or operational requirements that require the behavior. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-102 through SysRS-191 + +**SysDes-096**: Architecture changes shall update the SysRS allocation matrix, affected interfaces, affected dynamic flows, and verification hooks. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-097**: Consistency review shall check that SysDes does not contradict SysRS, does not introduce unapproved scope, and does not remove required MVP capabilities. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + + +## 11. Architecture Agreement and Communication + + +**SysDes-098**: The system architecture shall be reviewed by product, system engineering, Rust Core engineering, Flutter engineering, audio engineering, platform engineering, QA, security/privacy, and release stakeholders. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-011 through SysRS-015, SysRS-233 through SysRS-240 + +**SysDes-099**: Architecture review evidence shall include review date, participants, open issues, decisions, accepted risks, and approval status. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-100**: The agreed SysDes baseline shall be communicated to downstream SRS, SAD, SDD, and Verification authors. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-101**: Any change affecting `tsclientlib` isolation, real-time audio processing, secure storage, mobile lifecycle, or release wording shall trigger architecture impact review. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-005, SysRS-059 through SysRS-074, SysRS-153 through SysRS-199, SysRS-211 through SysRS-218 + + +## 12. Verification Handoff + +The SysDes does not define detailed test cases. It defines verification hooks that shall be expanded in the Verification artifact. + + +**SysDes-102**: Protocol verification shall use a protocol probe tool and compatibility matrix to verify external server compatibility and `tsclientlib` adapter behavior. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: External Server, Software: Protocol Adapter +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-121 through SysRS-128, SysRS-233, SysRS-241 + +**SysDes-103**: State verification shall use reducer tests and event replay tests to verify snapshot, delta, reconnect, and malformed-event behavior. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-129 through SysRS-139, SysRS-234, SysRS-191 + +**SysDes-104**: Audio verification shall use audio loopback and processing tests to verify capture, playback, codec, jitter buffer, mixer, Echo Canceller, AGC, Noise Suppression, and High-Pass Filter. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-235, SysRS-242 through SysRS-253 + +**SysDes-105**: Security verification shall audit secure storage, private-key handling, password handling, input validation, and diagnostic redaction on all target platforms. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Platform Secure Storage, Software: Diagnostics, Verification +- Downstream artifact: Verification +- Verification method: Audit +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-140 through SysRS-167, SysRS-236, SysRS-256 + +**SysDes-106**: Deployment verification shall verify release package creation, signing, notarization, app-store builds, and release metadata wording. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Software: Storage, Deployment / Operations +- Downstream artifact: Verification +- Verification method: Inspection, Demo +- Verification owner: Release / Operations QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-192 through SysRS-199, SysRS-238 + +**SysDes-107**: MVP acceptance verification shall demonstrate all acceptance requirements from SysRS-241 through SysRS-257. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Verification +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-241 through SysRS-257 + + +**SysDes-108**: The SysDes shall be the mandatory architectural allocation layer between SysRS and SRS; downstream SRS requirements shall use SysDes IDs as their direct source and shall not use SysRS IDs as their direct source. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Requirements Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-109**: The SysDes shall provide enough allocation information for SWE.1 to derive software requirements without directly reinterpreting SysRS requirements. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Requirements Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3, BP4, BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-110**: If a downstream software requirement cannot be derived from an existing SysDes design item, the SysDes shall be revised before the SRS is revised or baselined. + +- Status: Baseline +- Type: Change Control / Traceability Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Requirements Engineering, Change Control, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP3, BP4, BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + + +## 13. SysDes Design Item Metadata Register + +This register provides a compact review view of all `SysDes-XXX` design items and their engineering attributes. + +| SysDes ID | Type | Stage | Allocated to | Verification method | Verification owner | Downstream artifact | +|---|---|---|---|---|---|---| +| SysDes-001 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-002 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-003 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-004 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SysDes baseline, Verification | +| SysDes-005 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-006 | Process / Description | P0 / MVP | Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | Review, Inspection | Audio / Platform QA | SysDes baseline, Verification | +| SysDes-007 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-008 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-009 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SysDes baseline, Verification | +| SysDes-010 | Architectural Constraint | P0 / MVP | Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | Review | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-011 | Architectural Constraint | P0 / MVP | Software: Protocol Adapter | Review | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-012 | Architectural Constraint | P0 / MVP | Software: Flutter UI, Software: Rust Core | Review | Software QA | SRS, SAD, SDD | +| SysDes-013 | Architectural Constraint | P0 / MVP | Software: Audio Subsystem | Review | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-014 | Architectural Constraint | P0 / MVP | Software: Flutter UI, Software: Audio Subsystem | Review | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-015 | Architectural Constraint | P0 / MVP | Software: Diagnostics, Verification | Review | Security / QA | SRS, SAD, SDD | +| SysDes-016 | Architectural Constraint | P0 / MVP | System Engineering | Review | System Engineering / QA | SRS, SAD, SDD | +| SysDes-017 | Architectural Constraint | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations | Review | Security / QA | SRS, SAD, SDD | +| SysDes-018 | Static Architecture Description | P0 / MVP | External Server, Software: Audio Subsystem, Deployment / Operations | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-019 | System Element Allocation | P0 / MVP | User / Operator, Platform, Software: Diagnostics, Verification | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-020 | System Element Allocation | P0 / MVP | Hardware, Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-021 | System Element Allocation | P0 / MVP | Platform, Software: Audio Subsystem, Platform Secure Storage | Review, Inspection | Security / QA | SRS, SAD, SDD | +| SysDes-022 | System Element Allocation | P0 / MVP | Network | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-023 | System Element Allocation | P0 / MVP | External Server, Software: Audio Subsystem, Platform | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-024 | System Element Allocation | P0 / MVP | Software, Platform | Review, Inspection | System Engineering / QA | SRS, SAD, SDD | +| SysDes-025 | System Element Allocation | P0 / MVP | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-026 | System Element Allocation | P0 / MVP | Software: Flutter State, Software: Rust Core, Software: State Sync | Review, Inspection | Software QA | SRS, SAD, SDD | +| SysDes-027 | System Element Allocation | P0 / MVP | Software: Bridge, Software: Rust Core | Review, Inspection | Software QA | SRS, SAD, SDD | +| SysDes-028 | System Element Allocation | P0 / MVP | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-029 | System Element Allocation | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-030 | System Element Allocation | P0 / MVP | Software: State Sync | Review, Inspection | System Engineering / QA | SRS, SAD, SDD | +| SysDes-031 | System Element Allocation | P0 / MVP | Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-032 | System Element Allocation | P0 / MVP | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | Review, Inspection | Security / QA | SRS, SAD, SDD | +| SysDes-033 | System Element Allocation | P0 / MVP | Software: Audio Subsystem, Software: Storage | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-034 | System Element Allocation | P0 / MVP | Platform Secure Storage | Review, Inspection | Security / QA | SRS, SAD, SDD | +| SysDes-035 | System Element Allocation | P0 / MVP | Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-036 | System Element Allocation | P0 / MVP | Software: Storage, Deployment / Operations | Review, Inspection | Release / Operations QA | SRS, SAD, SDD | +| SysDes-037 | System Element Allocation | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD | +| SysDes-038 | Static Architecture Design | P0 / MVP | Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core | Review, Inspection | Software QA | SRS, SAD, SDD | +| SysDes-039 | Static Architecture Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-040 | Static Architecture Design | P0 / MVP | Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-041 | Static Architecture Design | P0 / MVP | Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-042 | Allocation Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SRS, SAD, SDD, Verification | +| SysDes-043 | Allocation Rule | P0 / MVP | External Server, Deployment / Operations, System Engineering, Verification | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-044 | Allocation Rule | P0 / MVP | Software: Flutter UI, Software: Rust Core | Review, Inspection | Software QA | SRS, SAD, SDD, Verification | +| SysDes-045 | Allocation Rule | P0 / MVP | Hardware, Platform, Network | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-046 | Allocation Rule | P0 / MVP | Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering | Review, Inspection | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-047 | Allocation Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SRS, SAD, SDD, Verification | +| SysDes-048 | Interface Design | P0 / MVP | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-049 | Interface Design | P0 / MVP | Software: Bridge, Software: Protocol Adapter | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-050 | Interface Design | P0 / MVP | Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-051 | Interface Design | P0 / MVP | Software: Protocol Adapter | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-052 | Interface Design | P0 / MVP | External Server, Software: Protocol Adapter | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-053 | Interface Design | P0 / MVP | Software: Audio Subsystem | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-054 | Interface Design | P0 / MVP | Software: Audio Subsystem | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-055 | Interface Design | P0 / MVP | Software: Storage, Platform Secure Storage | Inspection, Integration Test | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-056 | Interface Design | P0 / MVP | Software: Storage | Inspection, Integration Test | Software QA | SRS, SAD, SDD, Verification | +| SysDes-057 | Interface Design | P0 / MVP | Software: Diagnostics, Verification | Inspection, Integration Test | System Engineering / QA | SRS, SAD, SDD, Verification | +| SysDes-058 | Interface Design | P0 / MVP | Software: Diagnostics, Verification | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-059 | Interface Design | P0 / MVP | Software: Audio Subsystem, Platform | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-060 | Dynamic Behavior | P0 / MVP | Software: Rust Core | System Test, Demo | Software QA | SRS, SAD, SDD, Verification | +| SysDes-061 | Dynamic Behavior | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Platform | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-062 | Dynamic Behavior | P0 / MVP | Software: Audio Subsystem, Platform | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-063 | Dynamic Behavior | P0 / MVP | Software: State Sync | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-064 | Dynamic Behavior | P0 / MVP | Software: Diagnostics, Verification | System Test, Demo | System Engineering / QA | SRS, SAD, SDD, Verification | +| SysDes-065 | Functional Dynamic Design | P0 / MVP | Software: Flutter UI, Software: Bridge, Software: Rust Core | System Test, Demo | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-066 | Functional Dynamic Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-067 | Functional Dynamic Design | P0 / MVP | Software: State Sync | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-068 | Functional Dynamic Design | P0 / MVP | Software: State Sync | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-069 | Functional Dynamic Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-070 | Functional Dynamic Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-071 | Functional Dynamic Design | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-072 | Functional Dynamic Design | P0 / MVP | Software: Audio Subsystem | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-073 | Functional Dynamic Design | P0 / MVP | Software | System Test, Demo | Network / Reliability QA | SRS, SAD, SDD, Verification | +| SysDes-074 | Functional Dynamic Design | P0 / MVP | Software: State Sync | System Test, Demo | Network / Reliability QA | SRS, SAD, SDD, Verification | +| SysDes-075 | Functional Dynamic Design | P0 / MVP | Software: Audio Subsystem, Platform | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-076 | Functional Dynamic Design | P0 / MVP | Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification | System Test, Demo | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-077 | Architecture Decision / Rationale | P0 / MVP | Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Analysis | Audio / Platform QA | SAD, SDD, Verification | +| SysDes-078 | Architecture Decision / Rationale | P0 / MVP | Software: Protocol Adapter | Review, Analysis | Protocol / Integration QA | SAD, SDD, Verification | +| SysDes-079 | Architecture Decision / Rationale | P0 / MVP | Software: State Sync, System Engineering, Verification | Review, Analysis | Network / Reliability QA | SAD, SDD, Verification | +| SysDes-080 | Architecture Decision / Rationale | P0 / MVP | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | Review, Analysis | Security / QA | SAD, SDD, Verification | +| SysDes-081 | Architecture Decision / Rationale | P0 / MVP | Software: Audio Subsystem | Review, Analysis | Audio / Platform QA | SAD, SDD, Verification | +| SysDes-082 | Architecture Decision / Rationale | P0 / MVP | Platform | Review, Analysis | Protocol / Integration QA | SAD, SDD, Verification | +| SysDes-083 | Architecture Decision / Rationale | P0 / MVP | Software: Audio Subsystem | Review, Analysis | Audio / Platform QA | SAD, SDD, Verification | +| SysDes-084 | Architecture Decision / Rationale | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | Review, Analysis | Security / QA | SAD, SDD, Verification | +| SysDes-085 | Non-functional Architecture Design | P0 / MVP | Software: Flutter UI, Software: Bridge, Software: Rust Core | Review | Network / Reliability QA | SRS, SAD, SDD, Verification | +| SysDes-086 | Non-functional Architecture Design | P0 / MVP | Hardware, Network, Software: Audio Subsystem, Platform | Test, Analysis | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-087 | Non-functional Architecture Design | P0 / MVP | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | Test, Analysis | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-088 | Non-functional Architecture Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem | Test, Analysis | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-089 | Non-functional Architecture Design | P0 / MVP | Platform Secure Storage, Software: Diagnostics, Verification | Audit | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-090 | Non-functional Architecture Design | P0 / MVP | Platform, Software: Diagnostics, Verification | Audit | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-091 | Non-functional Architecture Design | P0 / MVP | Software: Storage, Deployment / Operations, System Engineering, Verification | Inspection, Demo | Release / Operations QA | SRS, SAD, SDD, Verification | +| SysDes-092 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-093 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-094 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-095 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Security / QA | SysDes baseline, Verification | +| SysDes-096 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-097 | Traceability / Consistency Rule | P0 / MVP | System Engineering, Verification | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-098 | Process / Description | P0 / MVP | Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification | Review, Inspection | Security / QA | SysDes baseline, Verification | +| SysDes-099 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SysDes baseline, Verification | +| SysDes-100 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-101 | Process / Description | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification | Review, Inspection | Security / QA | SysDes baseline, Verification | +| SysDes-102 | Verification Handoff | P0 / MVP | External Server, Software: Protocol Adapter | Test, Demo | Protocol / Integration QA | Verification | +| SysDes-103 | Verification Handoff | P0 / MVP | Software: State Sync | Test, Demo | Network / Reliability QA | Verification | +| SysDes-104 | Verification Handoff | P0 / MVP | Software: Audio Subsystem | Test, Demo | Audio / Platform QA | Verification | +| SysDes-105 | Verification Handoff | P0 / MVP | Platform Secure Storage, Software: Diagnostics, Verification | Audit | Security / QA | Verification | +| SysDes-106 | Verification Handoff | P0 / MVP | Software: Storage, Deployment / Operations | Inspection, Demo | Release / Operations QA | Verification | +| SysDes-107 | Verification Handoff | P0 / MVP | Verification | Test, Demo | Software QA | Verification | +| SysDes-108 | Traceability / Consistency Rule | P0 / MVP | System Engineering, Software Requirements Engineering, Verification | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD, Verification | +| SysDes-109 | Allocation Rule | P0 / MVP | System Engineering, Software Requirements Engineering | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD, Verification | +| SysDes-110 | Change Control / Traceability Rule | P0 / MVP | System Engineering, Software Requirements Engineering, Change Control, Verification | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD, Verification | + +## Appendix A — Complete SysRS to SysDes Allocation Matrix + +This matrix provides explicit allocation for every SysRS requirement. It is the primary bidirectional traceability record for this SysDes. + +| SysRS ID | SysRS Requirement Summary | Allocated System Elements | Primary SysDes Design Items | +|---|---|---|---| + +| SysRS-001 | The Chanora application shall be a cross-platform client application for channel-based voice communication. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-14 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-002 | The Chanora application shall support Windows, macOS, Linux, iOS, and Android as target client platforms. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-03 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-003 | The Chanora application shall use Flutter for the user-facing client interface. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-08 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-004 | The Chanora application shall use Rust Core for protocol handling, connection management, state synchronization, audio processing, storage coordination, diagnostics, and business logic. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-05 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-005 | The Chanora application shall use `tsclientlib` as the TeamSpeak-compatible protocol client library. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-05 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-006 | The Chanora application shall operate as an independent client and shall not present itself as an official TeamSpeak product. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-007 | The Chanora application shall allow users to connect to TeamSpeak 3-compatible servers reachable from the client device network. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-05 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-008 | The Chanora application shall allow users to participate in channel-based voice communication when the external server and user permissions allow it. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-14 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-009 | The Chanora application shall allow users to send and receive supported text messages when the external server and user permissions allow it. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-010 | The Chanora application shall provide local bookmark, recent server, identity reference, UI setting, and audio setting management on the client device. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-14 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-011 | The Chanora application shall support end users who manually connect to compatible voice servers. | SE-01, SE-07, SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-012 | The Chanora application shall support regular users who rely on saved bookmarks, persistent identity, audio settings, and common voice controls. | SE-01, SE-07, SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-013 | The Chanora application shall support testers and support operators who export diagnostics for troubleshooting. | SE-01, SE-07, SE-17, SE-19 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-014 | The SysRS shall provide requirements traceability suitable for engineering, QA, system administration, and release operations. | SE-01, SE-07, SE-17, SE-19 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-015 | The SysRS shall document external environment dependencies that may need administrator configuration, including network reachability and OS-level audio permissions. | SE-01, SE-07, SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-016 | The Chanora application shall treat external TeamSpeak 3-compatible servers as external systems outside Chanora control. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-11 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-017 | The Chanora application shall not require a Chanora-operated central server for MVP voice, channel, or text operation. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-13, SE-02 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-018 | The Chanora application shall not host or operate TeamSpeak-compatible server functionality in the MVP. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-11 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-019 | The Chanora application shall rely on operating system services for microphone permission, secure storage, audio routing, notifications, and mobile lifecycle behavior. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-13, SE-02, SE-15 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-020 | The Chanora application shall treat app stores, package repositories, installers, and update services as deployment environment components. | SE-03, SE-04, SE-05, SE-14, SE-18 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-021 | The Chanora application shall treat physical microphones, speakers, wired headsets, USB audio devices, and Bluetooth audio devices as external hardware interfaces. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-13, SE-02 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-022 | The Chanora application shall treat routers, firewalls, VPNs, NAT devices, and ISPs as external network environment components. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-17 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-023 | The Chanora application shall expose user-safe errors when external dependencies prevent successful operation. | SE-03, SE-04, SE-05, SE-14, SE-18 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-024 | The Chanora application shall include a Flutter UI component responsible for rendering screens, receiving user input, and presenting application state. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-025 | The Chanora application shall include a Flutter State Layer responsible for UI state derived from Rust Core events. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-026 | The Chanora application shall include a Bridge Layer responsible for commands, DTOs, asynchronous calls, and event streams between Flutter and Rust Core. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-027 | The Chanora application shall include a Rust Core component responsible for authoritative connection, protocol, state, audio, storage, settings, and diagnostics behavior. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-028 | The Chanora application shall include a protocol adapter component that isolates direct `tsclientlib` usage. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-029 | The Chanora application shall include a state synchronization component that implements snapshot + delta state handling. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-030 | The Chanora application shall include an audio subsystem component that coordinates capture, processing, encoding, decoding, jitter buffering, mixing, and playback. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-031 | The Chanora application shall include a local storage component for non-secret data such as bookmarks, recent servers, UI settings, and audio settings. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-032 | The Chanora application shall include a secure storage adapter for private identities, passwords, and future sensitive tokens. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-033 | The Chanora application shall include a diagnostics component for structured logging, redaction, event recording, event replay, audio diagnostics, network diagnostics, and user-initiated export. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-034 | The Chanora application shall include platform adapter components for desktop and mobile platform services. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-035 | The client device shall use a CPU architecture supported by Flutter, Rust, and the selected target platform. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-07, SE-08 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-036 | The client device shall provide sufficient CPU capacity to run the Chanora application, Opus-compatible voice processing, and enabled audio processing features in real time. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-037 | The client device shall provide sufficient memory for the Chanora application to run without unbounded growth in logs, chat history, audio buffers, or event queues. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-17 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-038 | The client device shall provide persistent local storage for Chanora application data, settings, logs, and cached metadata. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-039 | The client device shall provide a microphone or supported audio input device for voice transmission. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-040 | The client device shall provide speakers, headphones, or a supported audio output device for voice playback. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-041 | The client device shall provide network connectivity to the selected compatible voice server. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-17 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-042 | The desktop client environment should be validated on devices with at least 4 GB RAM for MVP operation. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-043 | The desktop client environment should be validated with at least 500 MB free local storage for installation, settings, logs, and diagnostic bundle creation. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-044 | The client device should provide stable audio device identifiers where the target platform supports persistent device selection. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-18 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-045 | The client device should provide hardware or OS support for low-latency audio capture and playback. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-17 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-046 | The client device should provide Bluetooth audio support where the target operating system supports it. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-047 | The project shall document platform-specific hardware limitations discovered during compatibility testing. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-18 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-048 | The Windows runtime environment shall support native desktop window integration for the Chanora application. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-049 | The Windows runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure credential storage to the Chanora application. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-15, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-050 | The macOS runtime environment shall support native desktop window integration for the Chanora application. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-051 | The macOS runtime environment shall provide microphone permission prompts, microphone capture, speaker/headphone playback, audio device selection, and Keychain access to the Chanora application. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-052 | The Linux runtime environment shall support the desktop environments targeted by the selected release package. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-053 | The Linux runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure storage through Secret Service, libsecret, or equivalent where available. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-15, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-054 | The iOS runtime environment shall provide microphone permissions, foreground voice session capability, audio route change handling, audio interruption recovery, Keychain access, and AVAudioSession behavior to the Chanora application. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-055 | The Android runtime environment shall provide microphone permissions, foreground voice session capability, foreground service behavior, audio focus, Bluetooth route handling, Android Keystore access, and production audio integration through AAudio, Oboe, or equivalent. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-056 | The project shall define minimum supported operating system versions for each target platform before beta release. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-057 | The project shall document OS-level permissions required by each target platform before public release. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-058 | The Chanora application shall fail safely with a user-safe message when a required OS service is unavailable. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-059 | The Chanora application shall support microphone input for voice transmission. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-060 | The Chanora application shall support speaker or headphone output for voice playback. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-061 | The Chanora application shall support audio input and output device selection where the target platform exposes selectable devices. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-062 | The Chanora application shall handle audio route changes where the target platform reports them. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-063 | The Chanora application shall recover gracefully from audio device changes where possible. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-064 | The Chanora application shall support Echo Canceller for reducing playback audio leaking into microphone input. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-065 | The Chanora application shall support Automatic Gain Control for normalizing microphone input level. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-066 | The Chanora application shall support Noise Suppression for reducing stationary background noise. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-067 | The Chanora application shall support High-Pass Filter for reducing low-frequency rumble and handling noise. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-068 | The Chanora application shall support an audio processing backend abstraction so platform-native and Rust-based processing can be selected per platform. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-069 | The Chanora application shall allow Echo Canceller to use playback reference audio when the selected implementation requires it. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-070 | The Chanora application shall expose audio processing settings to Rust Core and persist them locally. | SE-02, SE-03, SE-13, SE-14, SE-10, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-071 | The Chanora application shall provide conservative default settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. | SE-02, SE-03, SE-13, SE-14, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-072 | The Chanora application shall allow platform-specific disabling of audio processing features when a feature is unstable or incompatible with a device configuration. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-073 | The project shall provide an audio loopback test tool for development and compatibility testing. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-074 | The project shall provide an audio processing test tool for development and compatibility testing. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-075 | The client network environment shall provide IP network connectivity from the client device to the selected compatible voice server. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-076 | The Chanora application shall allow the user to configure the server host or IP address. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-077 | The Chanora application shall allow the user to configure the server port. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-078 | The Chanora application should support a default TeamSpeak 3-compatible voice port when the user does not provide an explicit port. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-079 | The client network environment shall permit the protocol traffic required by `tsclientlib` and the selected compatible server. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-080 | The client network environment shall support latency suitable for real-time voice communication under expected operating conditions. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-081 | The client network environment should minimize packet loss for acceptable voice quality. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-082 | The Chanora application shall detect recoverable network failures where possible. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-083 | The Chanora application shall enter reconnect behavior after recoverable network failures. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-084 | The Chanora application shall rebuild server state from a fresh snapshot after reconnect. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-085 | The Chanora application shall not require VPN connectivity unless the target server or user environment requires it. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-086 | The Chanora application shall present network failures through user-safe error messages. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-087 | The Chanora application should include network diagnostics in user-initiated diagnostic exports. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-19 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-088 | The external voice server shall be TeamSpeak 3-compatible for Chanora MVP operation. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-089 | The external voice server shall be reachable from the client device network. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03, SE-04 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-090 | The external voice server shall permit client connection using the identity, nickname, password, and permissions supplied by the user. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03, SE-16 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-091 | The external voice server shall expose server information required for initial synchronization. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-092 | The external voice server shall expose channel listing required for the channel tree. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-093 | The external voice server shall expose client listing required for the online client view. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-094 | The external voice server shall support channel join operations for accessible channels. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-095 | The external voice server shall emit channel movement events required for state synchronization. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-096 | The external voice server shall emit client join and leave events required for state synchronization. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-097 | The external voice server shall emit channel create, update, and delete events required for state synchronization where those events occur. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-098 | The external voice server shall support channel text message send and receive where user permissions allow. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-099 | The external voice server shall support voice packet send and receive where user permissions allow. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03, SE-04 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-100 | The external voice server shall expose disconnect behavior or connection failure signals that can be mapped by the protocol adapter. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-101 | The project shall document server-side permissions that can affect channel join, voice transmission, and text messaging. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-102 | The Chanora application shall allow the user to manually connect to a compatible server. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-103 | The Chanora application shall allow the user to provide hostname or IP address, port, nickname, and optional server password before connection. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-104 | The Chanora application shall support persistent local identity for compatible server authentication. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-105 | The Chanora application shall display connection status to the user. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-106 | The Chanora application shall allow the user to disconnect from the active server connection. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-107 | The Chanora application shall display the server channel tree after synchronization. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-108 | The Chanora application shall display online clients after synchronization. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-109 | The Chanora application shall allow the user to join an accessible voice channel. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-110 | The Chanora application shall allow the user to send and receive channel text messages where permitted. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-111 | The Chanora application shall capture and transmit voice where permitted. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-112 | The Chanora application shall receive and play voice where permitted. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-113 | The Chanora application shall provide microphone mute control. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-114 | The Chanora application shall provide output deaf control. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-115 | The Chanora application shall provide push-to-talk control. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-116 | The Chanora application shall display microphone input level where available. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-117 | The Chanora application shall display speaking indicators where available. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-118 | The Chanora application shall allow users to save and reuse server bookmarks. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-119 | The Chanora application shall allow users to configure audio processing features. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-120 | The Chanora application shall allow users to export redacted diagnostics. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-121 | The Chanora application shall use `tsclientlib` inside the protocol subsystem. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-122 | The Chanora application shall isolate direct `tsclientlib` calls inside the `chanora_protocol` component. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-123 | The Chanora application shall prevent raw `tsclientlib` types from crossing into Flutter UI or Flutter State Layer. | SE-11, SE-19, SE-07, SE-08, SE-09, SE-05 | SysDes-025, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-124 | The Chanora application shall convert `tsclientlib` errors into Chanora protocol errors. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-125 | The Chanora application shall convert `tsclientlib` events into internal protocol events. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-126 | The Chanora application shall support future patching, replacement, or forking of protocol implementation without changing Flutter UI contracts. | SE-11, SE-19, SE-07, SE-08, SE-09, SE-05 | SysDes-025, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-127 | The project shall provide protocol compatibility test coverage for MVP features. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-128 | The project shall include a protocol probe tool for validating target server compatibility. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-129 | The Chanora application shall maintain one authoritative connection state per active server connection. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-130 | The Chanora application shall synchronize state using a snapshot + delta model. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-131 | The Chanora application shall emit a full snapshot after initial synchronization. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-132 | The Chanora application shall emit delta events after live server-side changes. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-133 | The Chanora application shall apply protocol events through deterministic reducers. | SE-10, SE-12, SE-09, SE-19, SE-11, SE-05 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-134 | The Chanora application shall preserve event ordering per connection. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-135 | The Chanora application shall rebuild state from a fresh snapshot after reconnect. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-136 | The Chanora application shall prevent Flutter from directly mutating server state. | SE-10, SE-12, SE-09, SE-19, SE-07, SE-08 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-137 | The Chanora application shall implement the defined connection state machine from Disconnected through Connecting, Synchronizing, Connected, and Reconnecting. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-138 | The Chanora application shall not automatically reconnect after user-triggered disconnect. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-139 | The project shall include an event replay tool for development and debugging of state synchronization. | SE-10, SE-12, SE-09, SE-19, SE-17 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-140 | The Chanora application shall store server bookmarks locally. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-141 | The Chanora application shall store recent servers locally. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-142 | The Chanora application shall store audio settings locally. | SE-15, SE-16, SE-17, SE-14, SE-13, SE-02, SE-03 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-143 | The Chanora application shall store UI settings locally. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-144 | The Chanora application shall store per-user volume preferences locally where applicable. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-145 | The Chanora application shall store muted user preferences locally where applicable. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-146 | The Chanora application shall use SQLite or an equivalent embedded database for non-secret local data. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-147 | The Chanora application shall use platform secure storage for sensitive data. | SE-15, SE-16, SE-17, SE-14, SE-03, SE-18 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-148 | The Chanora application shall store identity private keys using platform secure storage. | SE-15, SE-16, SE-17, SE-14, SE-03, SE-18 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-149 | The Chanora application shall store server passwords using platform secure storage. | SE-15, SE-16, SE-17, SE-14, SE-03, SE-18 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-150 | The Chanora application shall not store private keys in plaintext files. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-151 | The Chanora application shall not write passwords to logs. | SE-15, SE-16, SE-17, SE-14, SE-19 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-152 | The Chanora application shall redact secrets from diagnostic exports. | SE-15, SE-16, SE-17, SE-14, SE-19 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-153 | The Chanora application shall store sensitive data using platform secure storage. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-154 | The Chanora application shall redact secrets from logs. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-155 | The Chanora application shall redact secrets from diagnostic bundles. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-156 | The Chanora application shall avoid exposing internal stack traces to normal users. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-157 | The Chanora application shall validate user input before passing it to protocol operations. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-11, SE-05 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-158 | The Windows runtime environment shall support Windows Credential Manager, DPAPI, or equivalent secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-159 | The macOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-160 | The iOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-161 | The Android runtime environment shall support Android Keystore or equivalent secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-162 | The Linux runtime environment shall support Secret Service, libsecret, or equivalent secure storage where available. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-163 | The Chanora application shall minimize collection of personal data. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-164 | The Chanora application shall require user action before exporting diagnostics. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-165 | The Chanora application shall explain microphone permission usage before requesting permission where platform guidelines allow. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-13, SE-14 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-166 | The Chanora application shall explain notification permission usage before requesting permission where platform guidelines allow. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-167 | The Chanora application shall not automatically upload diagnostics in MVP. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-168 | The Chanora application shall produce structured diagnostic logs. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-169 | The Chanora application shall support log redaction. | SE-17, SE-19, SE-16 | SysDes-034, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-170 | The Chanora application shall support protocol event recording in development or diagnostics mode. | SE-17, SE-19, SE-11, SE-05 | SysDes-029, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-171 | The Chanora application shall support event replay for debugging state synchronization. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-172 | The Chanora application shall support audio diagnostics. | SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-031, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-173 | The Chanora application shall support network diagnostics. | SE-17, SE-19, SE-04 | SysDes-022, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-174 | The Chanora application shall support user-initiated diagnostic export. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-175 | Diagnostic export shall exclude or redact sensitive data. | SE-17, SE-19, SE-16 | SysDes-034, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-176 | The project shall document the expected support workflow for diagnostic bundle collection. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-177 | The project shall include compatibility test tracking for supported platforms. | SE-17, SE-19, SE-03, SE-14, SE-18 | SysDes-021, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-178 | The Chanora application shall keep the UI responsive during connection, synchronization, and reconnect. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-179 | The Chanora application shall avoid visible UI freezes longer than 100 ms during normal operation. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-180 | The Chanora application shall minimize local audio pipeline latency. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-181 | The Chanora application should target local audio pipeline latency under 100 ms where platform conditions permit. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-182 | The Chanora application shall avoid unbounded memory growth in chat history. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-183 | The Chanora application shall avoid unbounded memory growth in logs. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-17 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-184 | The Chanora application shall avoid unbounded memory growth in audio buffers. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-185 | The Chanora application shall avoid unbounded memory growth in event queues. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-186 | The Chanora application shall perform required audio processing without sustained underruns on supported devices. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-187 | The Chanora application shall keep reconnect processing non-blocking for UI interaction. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-188 | The Chanora application shall recover from transient network loss where possible. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-17 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-189 | The Chanora application shall recover gracefully from audio device changes where possible. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-190 | The Chanora application shall isolate connection failures to the affected connection. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-191 | The Chanora application shall avoid crashing on malformed or unexpected protocol events. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-05 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-192 | The project shall support Windows installer packaging for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-193 | The project shall support macOS signed and notarized builds for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-194 | The project shall support Linux packaging through AppImage, Flatpak, deb, rpm, or a selected subset. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-195 | The project shall support Android AAB release builds for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-196 | The project shall support iOS TestFlight and App Store release builds for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-197 | The project shall document platform signing, packaging, and release requirements before public release. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-198 | The project shall ensure release metadata does not imply official TeamSpeak affiliation. | SE-18, SE-19 | SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-199 | The project shall define release channels for internal, beta, and production builds before external testing. | SE-18, SE-19 | SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-200 | The Chanora application shall provide a user interface for manual server connection. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-201 | The Chanora application shall provide a user interface for bookmark management. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-202 | The Chanora application shall provide a user interface for channel tree navigation. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-203 | The Chanora application shall provide a user interface for chat. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-204 | The Chanora application shall provide a user interface for voice controls. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-205 | The Chanora application shall provide a user interface for audio processing settings. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-206 | The Chanora application shall provide a bridge interface between Flutter and Rust Core. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-207 | The Chanora application shall provide a protocol interface between Rust Core and `tsclientlib`. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-208 | The Chanora application shall provide an audio hardware interface through platform capture and playback adapters. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-209 | The Chanora application shall provide secure storage interfaces through platform-specific secure storage mechanisms. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-210 | The Chanora application shall provide a network interface to external TeamSpeak 3-compatible servers through `tsclientlib`. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-211 | The Chanora application shall not directly expose raw `tsclientlib` types to Flutter. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-08 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-212 | The Chanora application shall not store private keys in plaintext files. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-213 | The Chanora application shall not write passwords to logs. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-214 | The Chanora application shall not imply official TeamSpeak affiliation in UI, documentation, or release metadata. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-215 | The Chanora application shall not automatically upload diagnostic information in MVP. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-216 | The Chanora application shall comply with iOS background execution policies. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-03 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-217 | The Chanora application shall comply with Android foreground service requirements for active voice sessions. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-13 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-218 | The MVP shall not require Chanora-operated backend infrastructure for voice, channels, or text. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-13 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-219 | The selected `tsclientlib` version can support or be extended to support required MVP protocol features. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-220 | Required audio processing features can be implemented through a combination of platform-native APIs, Rust DSP, and external audio processing libraries. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-02, SE-03 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-221 | Mobile foreground voice behavior is sufficient for MVP. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-02, SE-03 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-222 | Background voice behavior will remain constrained by iOS and Android platform policies. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-02, SE-03 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-223 | External compatible server administrators are responsible for server availability, permissions, and configuration. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-224 | End users are responsible for providing valid server connection details and network access. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-17 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-225 | The MVP shall not include TeamSpeak-compatible server hosting functionality. | SE-06, SE-13, SE-19, SE-11, SE-05 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-226 | The MVP shall not include full server administration functionality. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-227 | The MVP shall not include a complete permission editor. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-228 | The MVP shall not include a plugin system. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-229 | The MVP shall not include 3D positional audio unless explicitly reprioritized. | SE-06, SE-13, SE-19, SE-14, SE-02, SE-03 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-230 | The MVP shall not include advanced whisper list management unless explicitly reprioritized. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-231 | The MVP shall not include Server Query administration tools. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-232 | The MVP shall not include automatic cloud sync of bookmarks, identities, settings, or diagnostics. | SE-06, SE-13, SE-19, SE-15, SE-16, SE-17 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-233 | The project shall maintain a requirements traceability matrix from SysRS requirements through SysDes, SRS, SAD, SDD, and Verification evidence. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-234 | The project shall verify protocol compatibility through a protocol probe tool. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-05 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-235 | The project shall verify state synchronization through reducer tests and event replay tests. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-236 | The project shall verify audio capture, processing, encode/decode, and playback through audio loopback and processing tests. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-14 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-237 | The project shall verify secure storage behavior on every target platform before public release. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-15 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-238 | The project shall verify diagnostic redaction before enabling diagnostic export for external testers. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-239 | The project shall verify release packaging on every target platform before production release. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-03 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-240 | The project shall verify that public wording does not imply official TeamSpeak affiliation. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-241 | The MVP shall connect to a TeamSpeak 3-compatible server using `tsclientlib`. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-242 | The MVP shall display the server channel tree. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-243 | The MVP shall display online clients. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-244 | The MVP shall allow the user to join a voice channel. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-245 | The MVP shall send voice. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-246 | The MVP shall receive voice. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-247 | The MVP shall support microphone mute. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-248 | The MVP shall support output deaf. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-249 | The MVP shall support push-to-talk. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-250 | The MVP shall support Echo Canceller. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-251 | The MVP shall support Automatic Gain Control. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-252 | The MVP shall support Noise Suppression. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-253 | The MVP shall support High-Pass Filter. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-254 | The MVP shall send and receive channel text messages. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-255 | The MVP shall save and reuse server bookmarks. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-256 | The MVP shall use secure storage for sensitive data. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-257 | The MVP shall export redacted diagnostic logs. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + + +## Appendix B — ASPICE SYS.3 Base Practice Coverage + +| ASPICE SYS.3 area | Evidence in this SysDes | +|---|---| +| BP1 Static aspects of system architecture | Sections 4, 5, 6 and Appendix A define system boundary, system elements, relationships, and interfaces. | +| BP2 Dynamic aspects of system architecture | Section 7 defines states, modes, and major interaction flows. | +| BP3 Analyze system architecture | Sections 3, 8, and 9 define criteria, rationale, special characteristics, performance, reliability, security, privacy, and deployment analysis. | +| BP4 Consistency and bidirectional traceability | Sections 5 and 10 plus Appendix A allocate every SysRS requirement to system elements and design items; Section 1.5 and SysDes-108 through SysDes-110 define the downstream SRS derivation rule. | +| BP5 Communicate agreed system architecture | Section 11 defines review, agreement, communication, baselining, and affected parties. | + +--- + +## Appendix C — Open Architecture Issues + +| Issue ID | Issue | Owner | Target Resolution | +|---|---|---|---| +| OAI-001 | Confirm selected `tsclientlib` version and feature coverage. | Protocol owner | Before SRS baseline | +| OAI-002 | Decide audio processing backend per platform. | Audio owner | Before SAD baseline | +| OAI-003 | Decide minimum supported iOS and Android versions. | Platform owner | Before SRS baseline | +| OAI-004 | Decide whether multiple simultaneous server connections are in MVP. | Product owner | Before SRS baseline | +| OAI-005 | Confirm legal wording for compatible server claims. | Product/legal owner | Before release verification | +| OAI-006 | Confirm secure storage implementation details per platform. | Security/platform owner | Before SDD baseline | + +--- + +## Appendix D — Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-13 | Initial SysDes draft from SysRS | +| 0.2.0 | 2026-05-13 | Updated IDs to SysDes-XXX | +| 0.3.0 | 2026-05-13 | Reworked to follow ASPICE SYS.3 System Architectural Design structure and cover all SysRS IDs | +| 0.4.0 | 2026-05-13 | Added Type, Stage, Allocation, Downstream Artifact, Verification Method, and Verification Owner attributes to all SysDes design items | +| 0.5.0 | 2026-05-13 | Added downstream SRS derivation rule: SRS shall trace directly to SysDes only; if software needs cannot be derived from SysDes, update SysDes first | + + +--- + +## 14. UI/UX, Platform Adaptation, and Internationalization Architecture Addendum + +The following `SysDes-XXX` items extend the SYS.3 System Architectural Design baseline. They allocate `SysRS-258` through `SysRS-285` to system elements and define the downstream software-design handoff. This addendum preserves the strict lifecycle traceability chain: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +SRS items shall derive from `SysDes-XXX` only. SAD items shall derive from `SRS-XXX` only. SDD items shall derive from `SAD-XXX` only. + +**SysDes-111**: The system architecture shall adopt Material 3 as the baseline UI design system for the Flutter client and shall define Chanora-specific UI semantics above it. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Architecture analysis, static architecture +- Allocated SysRS: SysRS-258, SysRS-259 + +**SysDes-112**: The system architecture shall allocate Material 3 theming to a dedicated Design System element rather than to feature screens. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Design System, Flutter UI +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, consistency +- Allocated SysRS: SysRS-258, SysRS-259, SysRS-284 + +**SysDes-113**: The Design System element shall own `ThemeData`, `ColorScheme`, typography mapping, shape mapping, elevation mapping, motion mapping, and product semantic token mapping. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Design System +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture +- Allocated SysRS: SysRS-258, SysRS-259, SysRS-284 + +**SysDes-114**: The system architecture shall define Chanora semantic tokens for connection state, voice state, latency state, channel state, diagnostics state, and accessibility state. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Design System +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection, Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, analysis +- Allocated SysRS: SysRS-259, SysRS-263, SysRS-284 + +**SysDes-115**: The system architecture shall allocate compact, medium, and expanded layout selection to an Adaptive Shell element. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Flutter UI, Adaptive Shell +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture +- Allocated SysRS: SysRS-260, SysRS-261 + +**SysDes-116**: The Adaptive Shell shall keep connection status and primary voice controls visible or directly reachable across compact, medium, and expanded layouts. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Flutter UI, Adaptive Shell, Voice UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Dynamic architecture +- Allocated SysRS: SysRS-260, SysRS-261 + +**SysDes-117**: The system architecture shall allocate accessibility semantics, non-color-only state expression, text scaling, and focus visibility to the Flutter UI and Design System elements. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Accessibility Test, Review +- Verification owner: Software QA / Accessibility QA +- ASPICE SYS.3 alignment: Architecture analysis, consistency +- Allocated SysRS: SysRS-262, SysRS-263, SysRS-264, SysRS-265, SysRS-282 + +**SysDes-118**: The platform architecture shall allocate safe areas, display cutouts, system bars, virtual keyboards, desktop insets, Android back behavior, and iOS navigation behavior to Platform Adapter and Flutter Shell elements. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Platform Adapter, Flutter Shell +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Platform Test, Integration Test +- Verification owner: Platform QA +- ASPICE SYS.3 alignment: Interface definition, dynamic architecture +- Allocated SysRS: SysRS-266, SysRS-267, SysRS-268 + +**SysDes-119**: The system architecture shall allocate user-visible string localization to a Localization Service used by Flutter UI and diagnostics presentation. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Localization Service, Flutter UI, Diagnostics +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, interface definition +- Allocated SysRS: SysRS-269, SysRS-270, SysRS-271, SysRS-272, SysRS-279, SysRS-280, SysRS-282 + +**SysDes-120**: The system architecture shall allocate server-provided names and messages to a Content Text path that is displayed without product localization or translation. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core, Flutter UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test, System Test +- Verification owner: Protocol / Software QA +- ASPICE SYS.3 alignment: Interface definition, dynamic architecture +- Allocated SysRS: SysRS-273, SysRS-281 + +**SysDes-121**: The system architecture shall standardize UTF-8 as the internal text representation across Flutter, Rust Core, storage, diagnostics, and protocol-facing adapter DTOs. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Bridge, Rust Core, Storage, Diagnostics, Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Software QA / Protocol QA +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-274, SysRS-276 + +**SysDes-122**: The system architecture shall isolate non-UTF-8 or platform-specific string conversion at explicit boundary adapters. + +- Status: Baseline +- Type: Interface Design +- Stage: P1 / Beta +- Allocated to: Protocol Adapter, Platform Adapter, Bridge +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Platform QA +- ASPICE SYS.3 alignment: Interface definition, architecture analysis +- Allocated SysRS: SysRS-275 + +**SysDes-123**: The system architecture shall allocate bidirectional text rendering and locale-aware formatting to Flutter UI and Localization Service components. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P1 / Beta +- Allocated to: Flutter UI, Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture +- Allocated SysRS: SysRS-277, SysRS-278 + +**SysDes-124**: The diagnostics architecture shall keep machine-readable diagnostic keys language-neutral while allowing user-facing descriptions to be localized. + +- Status: Baseline +- Type: Interface Design +- Stage: P1 / Beta +- Allocated to: Diagnostics, Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Test +- Verification owner: Diagnostics QA +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-276, SysRS-280 + +**SysDes-125**: The system architecture shall define UI/UX guideline, design token, component catalog, adaptive layout, and platform behavior documents as downstream design baselines. + +- Status: Baseline +- Type: Process / Description +- Stage: P1 / Beta +- Allocated to: System Engineering, UX, Software Team +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review +- Verification owner: System Engineering +- ASPICE SYS.3 alignment: Communication of agreed architecture +- Allocated SysRS: SysRS-283, SysRS-284 + +**SysDes-126**: The system architecture shall enforce lifecycle traceability so that SysDes covers SysRS, SRS covers software-related SysDes, SAD covers SRS, and SDD covers SAD. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-127**: The system architecture shall prevent SRS requirements from linking directly to SysRS IDs; SRS shall use `Source SysDes` only. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: Software Engineering, System Engineering +- Downstream artifact: SRS +- Verification method: Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-128**: The system architecture shall prevent SAD architecture items from linking directly to SysRS or SysDes IDs; SAD shall use `Source SRS` only. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: Software Architecture, System Engineering +- Downstream artifact: SAD +- Verification method: Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-129**: The system architecture shall prevent SDD detailed design items from linking directly to SysRS, SysDes, or SRS IDs; SDD shall use `Source SAD` only. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: Software Design, System Engineering +- Downstream artifact: SDD +- Verification method: Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-130**: The system architecture shall allocate localized accessibility labels for icon-only controls to the Design System and Localization Service. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Design System, Localization Service, Flutter UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Accessibility Test, Inspection +- Verification owner: Software QA / Accessibility QA +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-262, SysRS-269, SysRS-282 + +**SysDes-131**: The system architecture shall allocate language fallback behavior to the Localization Service and require deterministic fallback to the baseline product language. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Dynamic architecture +- Allocated SysRS: SysRS-271, SysRS-279 + +**SysDes-132**: The system architecture shall allocate theme and localization initialization to application startup before feature screens render user-visible content. + +- Status: Baseline +- Type: Dynamic Architecture +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Design System, Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Dynamic architecture +- Allocated SysRS: SysRS-258, SysRS-269, SysRS-270, SysRS-279 + +## 15. Updated SysRS to SysDes Coverage Statement + +This SysDes version covers all known SysRS requirements from `SysRS-001` through `SysRS-285`. + +| SysRS Range | SysDes Coverage | +|---|---| +| SysRS-001 through SysRS-257 | Covered by inherited SysDes baseline `SysDes-001` through `SysDes-110` | +| SysRS-258 through SysRS-285 | Covered by `SysDes-111` through `SysDes-132` | + +## Appendix E — Change History + +| Version | Date | Description | +|---|---|---| +| 0.6.0 | 2026-05-14 | Added Material 3, Chanora Design System, adaptive layout, accessibility, platform UI behavior, localization, Unicode, and strict layer-by-layer traceability architecture items. | + +--- + +## 16. Platform Baseline and Product Decision Architecture Addendum + +**SysDes-133**: The system architecture shall allocate iOS runtime minimum version policy to platform configuration, platform verification, release readiness, and iOS platform services. + +- Status: Baseline Candidate +- Type: Platform Architecture Decision +- Stage: P0 / MVP +- Allocated to: Platform Adapter, Release / Operations, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Platform Test +- Verification owner: Platform QA +- ASPICE SYS.3 alignment: Static architecture, consistency +- Allocated SysRS: SysRS-286 + +**SysDes-134**: The system architecture shall allocate Apple App Store Connect upload SDK compliance to release engineering and release readiness rather than runtime feature logic. + +- Status: Baseline Candidate +- Type: Release Architecture Decision +- Stage: P0 / MVP +- Allocated to: Release / Operations, iOS Build Configuration, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Release Inspection +- Verification owner: Release Manager +- ASPICE SYS.3 alignment: Architecture constraints, communication +- Allocated SysRS: SysRS-287 + +**SysDes-135**: The system architecture shall allocate Android minimum runtime version policy and Google Play target SDK compliance to Android platform configuration, platform verification, and release readiness. + +- Status: Baseline Candidate +- Type: Platform Architecture Decision +- Stage: P0 / MVP +- Allocated to: Platform Adapter, Android Build Configuration, Release / Operations, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Platform Test, Release Inspection +- Verification owner: Android Owner / Release Manager +- ASPICE SYS.3 alignment: Architecture constraints, consistency +- Allocated SysRS: SysRS-288, SysRS-289 + +**SysDes-136**: The system architecture shall constrain MVP runtime state, UI, audio routing, and protocol orchestration to one active server connection per client instance. + +- Status: Baseline Candidate +- Type: Functional Architecture Decision +- Stage: P0 / MVP +- Allocated to: Rust Core, Flutter UI, State Sync, Audio Subsystem, Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, System Test +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture +- Allocated SysRS: SysRS-290 + +**SysDes-137**: The system architecture shall allocate AEC, AGC, Noise Suppression, and High-Pass Filter default enablement to the audio subsystem with platform capability detection and user-setting control. + +- Status: Baseline Candidate +- Type: Audio Architecture Decision +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Audio, Settings UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Audio Test, Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: Dynamic architecture, architecture analysis +- Allocated SysRS: SysRS-291 + +**SysDes-138**: The system architecture shall prefer platform-native audio processing for MVP and isolate any Rust/WebRTC-style fallback behind the audio subsystem boundary. + +- Status: Baseline Candidate +- Type: Audio Architecture Decision +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Audio Adapter, Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Architecture Review, Audio Test +- Verification owner: Software Architect / Audio Owner +- ASPICE SYS.3 alignment: Architecture analysis, interface definition +- Allocated SysRS: SysRS-292 + +**SysDes-139**: The system architecture shall allocate non-secret local state to SQLite or an equivalent embedded database and secrets to platform secure storage. + +- Status: Baseline Candidate +- Type: Storage Architecture Decision +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage, Security +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Storage Test, Security Audit +- Verification owner: Storage Owner / Security +- ASPICE SYS.3 alignment: Static architecture, interface definition +- Allocated SysRS: SysRS-293 + +**SysDes-140**: The system architecture shall allocate Flutter/Rust communication to a stable typed bridge with generated or schema-controlled DTOs. + +- Status: Baseline Candidate +- Type: Interface Architecture Decision +- Stage: P0 / MVP +- Allocated to: Bridge, Flutter State, Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Architecture Review, Integration Test +- Verification owner: Software Architect +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-294 + +**SysDes-141**: The system architecture shall exclude automatic diagnostic upload, telemetry upload, and automatic crash reporting from MVP runtime behavior unless a later approved decision updates privacy, security, legal, release, and verification baselines. + +- Status: Baseline Candidate +- Type: Privacy Architecture Decision +- Stage: P0 / MVP +- Allocated to: Diagnostics, Privacy, Release / Operations, Security +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Privacy Review, Security Audit +- Verification owner: Security / Privacy Reviewer +- ASPICE SYS.3 alignment: Architecture constraints, communication +- Allocated SysRS: SysRS-295 + +**SysDes-142**: The desktop Push-to-Talk subsystem shall be allocated to a dedicated **Platform PTT Backend** layer that is selected at runtime per operating system, display server, and granted permission set, with the **Rust Core PTT State Machine** owning the authoritative `transmit_active` flag and the Flutter Voice UI owning the binding-capture UX. + +- Status: Baseline Candidate +- Type: Subsystem Allocation +- Stage: P0 / MVP +- Allocated to: Platform Input, Rust Core, Flutter UI, Audio Engine +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Architecture Review, Platform Test +- Verification owner: Software Architect +- ASPICE SYS.3 alignment: Element decomposition, interface definition +- Allocated SysRS: SysRS-296, SysRS-297 + +**SysDes-143**: The platform PTT backend layer shall report a typed `PttCapabilityLevel` (`L0` Focused, `L1` Global-shortcut-activation, `L2` Global-hold-to-talk, `L3` Global-with-mouse-buttons, `L4` Device-aware) to the Rust Core, and the Rust Core shall publish the same value to the Flutter UI through the bridge event stream so capability advertising matches actual runtime behaviour. + +- Status: Baseline Candidate +- Type: Cross-Subsystem Interface +- Stage: P0 / MVP +- Allocated to: Platform Input, Rust Core, Flutter UI, Bridge +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test, Architecture Review +- Verification owner: Software Architect +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-298 + +**SysDes-144**: The audio capture pipeline shall expose two distinct atomic states: `capture_active` (the input stream is open and frames flow into the encoder feeder) and `transmit_active` (the encoder is producing outbound Opus frames and the protocol layer is forwarding them). The PTT subsystem shall drive `transmit_active` only; `capture_active` shall follow the audio engine lifecycle and the platform input-permission state independently. + +- Status: Baseline Candidate +- Type: Subsystem Interface +- Stage: P0 / MVP +- Allocated to: Audio Engine, Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Audio Test, Integration Test +- Verification owner: Audio Owner + Software Architect +- ASPICE SYS.3 alignment: Element behaviour, interface definition +- Allocated SysRS: SysRS-296 + +**SysDes-145**: The Windows desktop backend shall be allocated to a Raw-Input-first implementation with a low-level-hook fallback and a Focused-PTT terminal fallback. The macOS desktop backend shall be allocated to a permission-aware Global PTT implementation with a Focused-PTT terminal fallback. The Linux desktop backend shall be allocated to a GNOME-on-Wayland portal-based implementation (the officially-tested compositor) with a Focused-PTT terminal fallback on every other Linux environment. + +- Status: Baseline Candidate +- Type: Platform Allocation +- Stage: P0 / MVP +- Allocated to: Platform Input +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Platform Test (Win/macOS/Linux), Architecture Review +- Verification owner: Software Architect + Platform Owners +- ASPICE SYS.3 alignment: Element decomposition, platform mapping +- Allocated SysRS: SysRS-299, SysRS-300, SysRS-301 + +**SysDes-146**: A **diagnostics sanitizer** shall sit between the platform PTT backend and the application log sink. The sanitizer shall reject any record carrying raw key codes, scan codes, virtual-key values, or key-press timing sequences before the record reaches the in-memory log sink, the platform sink (logcat / fmt / etc.), or the user-initiated diagnostic export pipeline. + +- Status: Baseline Candidate +- Type: Cross-Cutting Constraint +- Stage: P0 / MVP +- Allocated to: Diagnostics, Platform Input +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Privacy Review, Diagnostic Inspection, Unit Test +- Verification owner: Security / Privacy Reviewer +- ASPICE SYS.3 alignment: Architecture constraints, safety / security +- Allocated SysRS: SysRS-302 + +**SysDes-147**: The Flutter Voice UI shall surface the active PTT capability level and the active backend identifier as user-facing status (capability badge, fallback notice) so the user understands when a Global PTT binding cannot be honoured and a Focused-PTT fallback is in effect. + +- Status: Baseline Candidate +- Type: User-Facing Behaviour Allocation +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: User Acceptance Test, UI Review +- Verification owner: UX Owner +- ASPICE SYS.3 alignment: Element behaviour +- Allocated SysRS: SysRS-298 + +**SysDes-148**: The release verification record shall carry per-platform PTT capability evidence (detected `PttCapabilityLevel`, active backend identifier, fallback exercised yes/no) before any release artefact may claim Global PTT support. Release notes shall mirror the actual capability per platform and shall not over-claim. + +- Status: Baseline Candidate +- Type: Release Constraint +- Stage: P0 / MVP +- Allocated to: Release / Operations, Verification +- Downstream artifact: Release Readiness Record, Verification +- Verification method: Release Inspection, Architecture Review +- Verification owner: Release Manager +- ASPICE SYS.3 alignment: Architecture constraints +- Allocated SysRS: SysRS-298 + +**SysDes-149**: The system architecture shall define a `TransmitMode` element carried as an enum at the audio + bridge + UI boundary with variants `Ptt`, `Continuous`, and a reserved `VoiceActivity` placeholder that has no allocated implementation in this baseline (deferred per DEC-030). The active mode shall be persisted in the identity store; the UI shall surface `VoiceActivity` as a disabled "coming soon" option until an implementation is allocated in a later baseline. + +- Status: Baseline Candidate +- Type: Subsystem Interface +- Stage: P0 / MVP +- Allocated to: Audio Engine, Bridge, Flutter UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Unit Test, UI Review +- Verification owner: Audio Owner + UX Owner +- ASPICE SYS.3 alignment: Element behaviour, interface definition +- Allocated SysRS: SysRS-303 + +**SysDes-150**: The audio engine lifecycle shall be allocated to voice-channel membership: the input and output streams shall open on the user's first voice-channel join of the session and shall close on the last voice-channel leave. The output-stream open shall be independent of the microphone-permission state so listen-only remains a first-class flow. No manual start affordance shall be exposed at any system interface (bridge, UI, or otherwise). A user-facing hard-mute element shall force the transmit gate closed and shall take precedence over the active transmit mode, the PTT key state, and every other internal signal. + +- Status: Baseline Candidate +- Type: Lifecycle Allocation +- Stage: P0 / MVP +- Allocated to: Audio Engine, Bridge, Flutter UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test, UI Review +- Verification owner: Audio Owner + Software Architect +- ASPICE SYS.3 alignment: Element behaviour, lifecycle +- Allocated SysRS: SysRS-303 + +**SysDes-151**: A release-tail element shall be allocated to the audio subsystem as a system-level timer adapter on the `transmit_active` atomic defined in SysDes-144, parameterised by a configurable release-tail period (default 200 ms; user-configurable range 0–500 ms). When the PTT backend signals key-up, the adapter shall delay the `true → false` transition of `transmit_active` by the configured period; the adapter shall not affect `capture_active`. + +- Status: Baseline Candidate +- Type: Subsystem Element +- Stage: P0 / MVP +- Allocated to: Audio Engine +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Unit Test, Integration Test +- Verification owner: Audio Owner +- ASPICE SYS.3 alignment: Element behaviour +- Allocated SysRS: SysRS-304 + +**SysDes-152**: The system architecture shall allocate engagement of the Android voice-communication audio mode (for example `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) to the Android Platform Adapter as a dedicated in-call audio mode subsystem responsibility. The Android Platform Adapter shall (a) take a snapshot of the prior `AudioManager` mode before the first active voice session enters the connected state, (b) engage voice-communication mode no later than the moment the voice session becomes connected, (c) hold the mode for the full duration of any active voice session through refcount-composable enter/exit semantics so that overlapping or rapidly cycling sessions do not prematurely drop the mode, and (d) restore the snapshotted prior mode when the last active voice session ends. This is the system-architectural partitioning between the cross-platform Audio Subsystem (which owns capture/playback streams and codec) and the Android Platform Adapter (which owns the platform audio policy mode). This SysDes item is the proper anchor for the Android in-call audio mode software requirement. + +- Status: Baseline Candidate +- Type: Subsystem Element / Platform Allocation +- Stage: P0 / MVP +- Allocated to: Android Platform Adapter, Audio Subsystem (consumer) +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test, System Test +- Verification owner: Audio / Platform QA, Android Owner +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture, element allocation +- Allocated SysRS: SysRS-305 +- Notes: Refines the Android platform baseline anchored by SysDes-135 (Android minimum runtime / Play target SDK policy); SysDes-135 remains the platform-baseline context item and is not in conflict with this element-allocation derivation. Consistent with SysDes-021 (OS services allocation) and SysDes-032 (Platform Adapter Layer). + +**SysDes-153**: The system architecture shall allocate Android runtime microphone permission (`RECORD_AUDIO`) acquisition and denial-handling to the Android Platform Adapter as the system-design partitioning between the Permission Subsystem and the Voice Subsystem. The Android Platform Adapter shall (a) own the runtime permission request flow and surface a typed permission-state signal to the Rust Core, (b) ensure that the permission acquisition attempt occurs at or before voice session activation so that the cross-platform Audio Subsystem never opens an input capture stream without a granted permission, (c) provide a listen-only fallback path when the permission is denied, revoked, or not yet decided, in which the output stream lifecycle (per SysDes-150) is preserved and the transmit gate remains closed, and (d) expose a user-facing re-request entry point for granting the permission and retrying transmit. The Voice Subsystem and Audio Subsystem shall consume only the typed permission-state signal and shall not call platform permission APIs directly. This SysDes item is the proper anchor for the Android RECORD_AUDIO timing software requirement. + +- Status: Baseline Candidate +- Type: Subsystem Element / Platform Allocation +- Stage: P0 / MVP +- Allocated to: Android Platform Adapter, Permission Subsystem, Audio Subsystem (consumer), Voice Subsystem (consumer), Flutter UI (re-request affordance) +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test, System Test +- Verification owner: Audio / Platform QA, Android Owner +- ASPICE SYS.3 alignment: Static architecture, element allocation, interface design +- Allocated SysRS: SysRS-306 +- Notes: Additive to the platform-baseline anchor SysDes-135 and to the general OS-permission allocation in SysDes-021 / SysDes-059 (IF-014 Permission Interface). Consistent with SysDes-150 listen-only path (output stream independent of microphone permission). Inherits but does not duplicate the general microphone-permission obligation traced through SysRS-055. + +**SysDes-154**: The system architecture shall allocate the Android voice audio backend as a dedicated subsystem owned by the Android Platform Adapter and exposed to the cross-platform Audio Subsystem (SE-13) through a trait-based backend abstraction, mirroring the platform-backend pattern already established on iOS (the `coreaudio-rs` / `VoiceProcessingIO` voice-audio path). The Android voice audio backend subsystem shall encapsulate (a) low-latency duplex voice capture and playback via the AAudio low-latency performance-mode path with platform-reported performance-mode observability for downstream latency budget evaluation, (b) voice-communication usage and content-type declarations on the output stream and a voice-communication input-preset selection on the capture stream so that Android's audio policy engine routes the streams under the voice-communication rules engaged by the in-call mode element (SysDes-152), (c) engagement of available platform hardware voice-audio effects (acoustic echo canceller, noise suppressor, automatic gain control) against the active capture session with documented fallback to the cross-platform software processing in the Audio Subsystem (SysDes-137 / SysDes-138) when a given hardware effect is unavailable, (d) a sharing-mode policy that requests exclusive sharing on a best-effort basis with graceful fallback to shared sharing recorded in sanitised audio diagnostics rather than surfaced as a user-facing fatal error, and (e) a lifecycle binding to the Android foreground service of microphone type so that background voice capture is hosted under the platform-required foreground-service model. The Audio Subsystem consumes the backend through the trait abstraction only and shall not depend on AAudio types directly. This SysDes item is the proper anchor for the Android voice audio backend software requirements (latency, input preset, hardware effects, output usage/content-type, sharing mode, foreground-service-hosted background capture). + +- Status: Baseline Candidate +- Type: Subsystem Element / Platform Allocation +- Stage: P0 / MVP +- Allocated to: Android Platform Adapter (owner), Audio Subsystem (consumer through trait), Platform Adapter Layer, Diagnostics (sharing-mode telemetry) +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test, System Test, Audio Test +- Verification owner: Audio / Platform QA, Android Owner +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture, element allocation, interface design, architecture analysis +- Allocated SysRS: SysRS-055, SysRS-305 +- Notes: Refines the Android platform baseline anchored by SysDes-135 (Android minimum runtime / Play target SDK policy); SysDes-135 remains the platform-baseline context item and is unchanged. Trait-based platform backend pattern is shared with the iOS voice-audio path (`VoiceProcessingIO` via `coreaudio-rs`) but is not a code port. Composes with SysDes-152 (in-call mode), SysDes-153 (permission acquisition), SysDes-137 / SysDes-138 (audio processing default policy and platform-native preference with isolated fallback), SysDes-144 (`capture_active` / `transmit_active` split), SysDes-150 (audio engine lifecycle bound to voice-channel membership), and the foreground-service obligation already represented at the system level (SysRS-055, SysRS-111 chain). + +**SysDes-155**: The system architecture shall allocate the macOS runtime baseline as a dedicated platform-baseline element parallel to SysDes-133 (iOS) and SysDes-135 (Android), covering (a) the macOS deployment-target policy as a single-source-of-truth system-design concern owned by the macOS Build Configuration and consumed identically by the Flutter macOS runner and the Rust `chanora_bridge` native dependency (the canonical declaration site is the CocoaPods podspec at `apps/chanora_flutter/macos/chanora_bridge.podspec`, which is the location to be cited by downstream SRS/SAD/SDD; the numeric value itself is an implementation detail and is not embedded in this SysDes item), (b) a universal-binary packaging policy under which the Rust cdylib shall be produced for both `arm64` and `x86_64` host slices and combined via `lipo` into a single fat Mach-O binary so that one packaged macOS application supports Apple Silicon and Intel hosts without per-architecture artefacts, (c) the macOS `.framework` `Versions/A` bundle layout convention (versioned bundle directory with `Current` symlink, `Resources/Info.plist`, and the binary at `Versions/A/`) as the system-level packaging shape for the native bridge so that it is loadable by the Flutter macOS runner and is acceptable to codesigning and notarisation, and (d) CocoaPods podspec integration as the auto-build mechanism that drives the Rust cdylib build, the universal-binary `lipo` step, and the `.framework` assembly during a `pod install` / Flutter macOS build, so that the macOS build pipeline has a single, declarative entry point. This SysDes item is the proper macOS platform-baseline anchor for SAD-087 and for SRS items that allocate macOS-runtime responsibility, replacing any "open follow-up" SysDes placeholder previously carried by SAD-087. + +- Status: Baseline Candidate +- Type: Platform Architecture Decision +- Stage: P0 / MVP +- Allocated to: macOS Build Configuration (owner), Platform Adapter Layer (macOS Platform Services), Release / Operations (Release Pipeline), Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Platform Test (macOS), Release Inspection +- Verification owner: macOS Owner / Release Manager +- ASPICE SYS.3 alignment: Static architecture, architecture constraints, element allocation, consistency +- Allocated SysRS: SysRS-002, SysRS-050, SysRS-193 +- Notes: Parallel in role to SysDes-133 (iOS runtime baseline) and SysDes-135 (Android runtime baseline); neither SysDes-133 nor SysDes-135 is modified by this item. Source SysRS selection: SysRS-002 anchors the multi-platform obligation that explicitly enumerates macOS as a target client platform, SysRS-050 anchors the macOS runtime environment obligation for native desktop integration, and SysRS-193 anchors the signed/notarized macOS build obligation that the `.framework` `Versions/A` layout and universal-binary policy must satisfy in the release pipeline. No macOS-specific deployment-target or universal-binary SysRS item currently exists; if a finer-grained macOS minimum-runtime SysRS item is required (analogous to SysRS-286 for iOS and SysRS-288 for Android), the systems-requirements owner should consider authoring it in a follow-up — this SysDes item is structured so that such a future SysRS item can be added to `Allocated SysRS` without restructuring the element. SysDes-155 cites the podspec file path only and does not embed its current deployment-target value; the value itself remains owned by the Build Configuration subsystem. + +**SysDes-156**: The system architecture shall allocate to SE-13 (Audio Subsystem) the obligation to expose its realtime capture and playback paths to benchmark instrumentation, such that the maintained numeric performance baselines authorized by SysRS-307 are measurable as a deterministic, automated comparison surface. The metric set authored at this layer is: (i) **heap allocation count per realtime callback after warmup** — zero allocations are expected on the steady-state realtime audio thread, where warmup is defined as the first N callbacks with N implementation-specific (recommended N=100 callbacks; refined at SDD); (ii) **per-callback wall-clock time expressed as a fraction of the cpal stream's reported audio frame period**, captured and reported as p50, p95, and p99 of the callback wall-clock as a fraction of that period; (iii) **Opus encode latency** — end-to-end wall-clock time for `encoder.encode_float()` on a 960-sample (20 ms) frame, captured per call; (iv) **Opus decode latency** — same shape, decoder side; (v) **resampler throughput** in samples-per-second produced at the canonical rate pairs 44.1 kHz → 48 kHz, 16 kHz → 48 kHz, and 48 kHz → 48 kHz passthrough (the passthrough pair serves as a control point). The baseline storage format is declared at this layer as structured JSON committed to a deterministic location in the repository; the exact path is delegated to SDD. Each JSON record shall include the metric value, the host architecture, the toolchain version, the git SHA of the measurement, and a timestamp, so that a baseline snapshot is reproducible and traceable to the commit that produced it. This SysDes item does not authorize off-device transmission of any measured baseline data and is consistent with SysRS-295. + +- Status: Baseline Candidate +- Type: System Element Allocation / Performance Verification Surface +- Stage: P0 / MVP +- Allocated to: SE-13 (Audio Subsystem) — owns the realtime path being measured; the realtime callback, the Opus encode/decode paths, and the resampler are all SE-13 surfaces +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Automated Benchmark Execution (criterion crate per SDD); Inspection of the JSON baseline records committed to the default branch +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: Element allocation, dynamic architecture, resource and performance design, verification handoff +- Allocated SysRS: SysRS-307 (primary derivation); refines SysRS-180 / SysRS-181 / SysRS-186 from prescriptive intent into a measurable contract surface +- Notes: The numeric warmup constant (recommended N=100), the exact JSON repository path, the benchmark crate selection (recommendation: criterion), and the harness wiring against the cpal stream are SDD concerns and are not authored here. The cpal stream's reported period referenced in metric (ii) is the stream period reported by the existing audio capture/playback path owned by SE-13; this SysDes item does not authorize a new platform integration. The control-point passthrough at 48 kHz → 48 kHz in metric (v) provides a zero-arithmetic baseline that isolates harness overhead from resampling cost. Metrics (i) and (v) are the structural-property metrics (no acceptable variance for allocations; throughput is a steady-state measurement); metrics (ii)–(iv) are latency-distribution metrics whose tolerance characterisation is the subject of SysDes-158. + +**SysDes-157**: The system architecture shall allocate to SE-18 (Deployment and Release Environment) the integration of the realtime-audio benchmark suite (SysDes-156) into the existing CI workflow as an **advisory** regression-reporting surface, satisfying SysRS-308. The design constraints authored at this layer are: (1) **Trigger** — the benchmark workflow shall execute on every pull request opened against the default branch and on every merge to the default branch; it shall not be triggered on tags and shall not be triggered on non-default-branch pushes. (2) **Host scope** — the benchmark workflow shall execute on the Linux x86_64 GitHub Actions runner (`ubuntu-latest`); other host architectures are explicitly out of scope for this revision and shall not be added by SDD or by implementation without a future SysRS clause authorising multi-host benchmarking. (3) **Surface** — the result shall be rendered on the PR status-check view as a named check (suggested name "Benchmark / advisory" or equivalent; the exact check name is delegated to SDD) and shall additionally be rendered as a markdown table posted to the PR conversation, comparing each metric against the most recent baseline on the default branch with the percentage delta and a clear visual marker (e.g., 🟢 within tolerance, 🟡 within tolerance but trending, 🔴 outside tolerance). (4) **Non-blocking semantics** — the status check shall **never** report a `failure` status; on regression the check shall report `success` (so it does not block merge) and the regression shall be surfaced exclusively in the PR comment for human reviewer attention. This clause is the SysDes-layer enforcement of SysRS-308's advisory-only contract; any future escalation to a build-failing hard gate requires a separate SysRS authorisation and is out of scope of SysDes-157. (5) **Baseline source** — the comparison input shall be read from the deterministic JSON location on the default branch committed under SysDes-156; on the first run after a new benchmark is added, the baseline file may not yet contain that metric, in which case the report shall state "no baseline; this run establishes the baseline candidate" and shall not produce a comparison delta for that metric. (6) **Baseline update isolation** — a separate, manually-invoked CI workflow (GitHub Actions `workflow_dispatch`) shall be the sole mechanism that writes the baseline JSON on the default branch; the PR-triggered benchmark workflow shall never write the baseline file. This isolation guarantees that baseline updates are intentional, reviewable acts and prevents silent baseline drift from PR runs. + +- Status: Baseline Candidate +- Type: System Element Allocation / CI Integration Architecture +- Stage: P0 / MVP +- Allocated to: SE-18 (Deployment and Release Environment) — owns CI/CD per SysDes-036; the CI workflow definitions, the GitHub Actions runner selection, the PR status-check surface, the PR comment rendering, and the baseline-update workflow all live here +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Demo (a CI run on a synthetic PR demonstrates the markdown table report, the visual markers, the non-blocking `success` status on a simulated regression, and the "no baseline" fallback on a metric with no prior baseline) +- Verification owner: Release / Operations QA, Audio / Platform QA (co-verification of the report content) +- ASPICE SYS.3 alignment: Element allocation, deployment architecture, verification handoff +- Allocated SysRS: SysRS-308 (primary derivation); composes with SysRS-307 (baselines being compared against) and SysRS-309 (tolerance window applied by the comparison, refined by SysDes-158); consistent with SysRS-295 (no off-device transmission beyond the existing CI provider surface visible to repository collaborators) and with the SysRS-234..239 verification-family pattern +- Notes: The exact YAML workflow filenames, the exact named status-check string, the exact markdown layout of the comparison table, the exact emoji set, and the exact triggering criteria for the 🟡 "trending" state are SDD concerns and are not authored here. The merge-base baseline-snapshot semantics of the comparison are authored separately in SysDes-158. The Linux x86_64 host-scope clause is the active rule that explicitly defers ARM Android, macOS Apple Silicon, Windows x86_64, and any other host runner; that deferral is preserved here intentionally. Composes with SysDes-036 (CI/CD as a system element) as the SE-18 integration anchor. + +**SysDes-158**: The system architecture shall allocate to SE-18 (Deployment and Release Environment) the per-metric tolerance window and the baseline-comparison methodology used by the advisory CI surface (SysDes-157), satisfying SysRS-309. The tolerance window is authored at this layer as a per-metric set rather than as a single global value, because the metrics defined in SysDes-156 have different statistical character and require different comparison rules: + +| Metric (per SysDes-156) | Tolerance window | Comparison rule | Rationale | +|---|---|---|---| +| Heap allocation count per realtime callback after warmup | **Zero** | Any non-zero allocation count is reported as a regression (🔴) | Structural property of the code, not a statistical measurement; no acceptable variance | +| Per-callback wall-clock as a fraction of the audio frame period | **+20% on p95** | Compare current-run p95 against baseline p95; report regression if delta exceeds +20%. p50 and p99 are reported but not compared against tolerance (advisory data only) | p95 is the operational tail; p50 is too lenient and p99 is too noisy to gate on at MVP | +| Opus encode latency (960-sample / 20 ms frame) | **+15% on mean** | Compare current-run mean against baseline mean; report regression if delta exceeds +15% | Codec encode latency is a tight loop with low variance; mean is a stable comparator | +| Opus decode latency (same frame shape) | **+15% on mean** | Same shape as encode | Symmetric with encode | +| Resampler throughput (samples/second) at 44.1→48, 16→48, 48→48 passthrough | **−10% on samples/second** (lower is worse) | Compare current-run samples/sec against baseline samples/sec; report regression if delta is below −10% | Throughput regression is a *drop* in samples/sec, not an *increase*; sign convention is inverted relative to the latency metrics | + +The **comparison methodology** authored at this layer is: each PR-triggered benchmark run shall be compared against the most recent baseline committed to the default branch *at the time of the PR's merge-base commit*, not against the current tip of the default branch. This ensures PR comparisons are stable as the default branch advances during the PR's lifetime, and it also means that rebasing a PR onto a newer default-branch base can change which baseline snapshot is used as the comparator. The +20% starting value recorded as non-binding guidance in SysRS-309 is honoured here only for the per-callback wall-clock metric (and is bound to p95); the other metric tolerances are authored independently of the SysRS-309 suggestion, as authorised by SysRS-309's "single declared value (or one declared value per metric)" allowance. + +- Status: Baseline Candidate +- Type: System Element Allocation / Performance Comparison Methodology +- Stage: P0 / MVP +- Allocated to: SE-18 (Deployment and Release Environment) — the comparison logic lives in CI tooling co-located with the workflow authored in SysDes-157 +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review (the per-metric tolerance values are subject to periodic review; SDD ratifies the values as authored here and may refine the harness implementation; future SAD/SDD revisions may re-tune the values as baseline noise characteristics are observed empirically) +- Verification owner: Release / Operations QA, Audio / Platform QA +- ASPICE SYS.3 alignment: Element allocation, architecture decision / rationale, resource and performance design, verification handoff +- Allocated SysRS: SysRS-309 (primary derivation); composes with SysRS-307 (the baselines being compared) and SysRS-308 (the advisory surface that consumes this comparison) +- Notes: The selection of p95 (rather than p99) as the gated tail for the wall-clock metric is an explicit architectural decision recorded here: p99 is reported for diagnostic value but is intentionally not tolerance-gated at MVP because the sample population of a single CI run is too small for p99 to be a stable comparator. The merge-base baseline-snapshot rule is the active comparison methodology; an alternative methodology comparing against the latest default-branch baseline (rather than the merge-base baseline) was considered and intentionally rejected because it produces unstable PR comparisons when the default branch advances during the PR's lifetime. Re-tuning of the per-metric tolerance values may be performed by future SAD or SDD revisions without requiring a new SysRS clause, provided the values remain numeric and per-metric (the structural constraints authored here); a change from the per-metric model to a global single value, or vice versa, would require a SysRS-309 revision. + +## 17. Updated SysRS Coverage Statement + +This SysDes version covers all known SysRS requirements from `SysRS-001` through `SysRS-309`. + +| SysRS Range | SysDes Coverage | +|---|---| +| SysRS-001 through SysRS-285 | Covered by inherited SysDes baseline `SysDes-001` through `SysDes-132` | +| SysRS-286 through SysRS-295 | Covered by `SysDes-133` through `SysDes-141` | +| SysRS-296 through SysRS-302 | Covered by `SysDes-142` through `SysDes-148` | +| SysRS-303 through SysRS-304 | Covered by `SysDes-149` through `SysDes-151` | +| SysRS-305 through SysRS-306 | Covered by `SysDes-152` through `SysDes-154` (with SysDes-154 additionally refining SysRS-055 for the Android voice audio backend) | +| SysRS-002 / SysRS-050 / SysRS-193 (macOS platform-baseline slice) | Additionally refined by `SysDes-155` (macOS runtime baseline, parallel to SysDes-133 / SysDes-135) | +| SysRS-307 through SysRS-309 (realtime-audio benchmark infrastructure) | Covered by `SysDes-156` (audio benchmark surface, SE-13), `SysDes-157` (advisory CI integration, SE-18), and `SysDes-158` (per-metric tolerance window and comparison methodology, SE-18) | + + +## 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 separated release build SDK compliance from iOS runtime deployment target. | + + +## Baseline Candidate 0.9.3 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.3 | 2026-05-15 | Added desktop PTT subsystem allocation SysDes-142 through SysDes-148: Platform PTT Backend layer, typed `PttCapabilityLevel` cross-interface, audio-pipeline split into `capture_active` and `transmit_active`, per-OS backend allocation (Windows Raw-Input ladder, macOS permission-aware, Linux GNOME-Wayland portal), diagnostics sanitizer for raw key events, UI capability badge, release-record evidence requirement. | + + +## Baseline Candidate 0.9.5 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle allocation SysDes-149 through SysDes-151 sourced from SysRS-303 / SysRS-304: `TransmitMode` enum element (`Ptt` / `Continuous` / reserved `VoiceActivity` per DEC-030) at the audio + bridge + UI boundary, audio engine lifecycle bound to voice-channel membership with no manual start affordance and a listen-only path independent of mic permission, hard-mute override element, and the release-tail timer adapter (default 200 ms, range 0–500 ms) on `transmit_active`. Strict layered sourcing preserved (`SysDes -> SysRS` only). | + + +## Baseline Candidate 0.9.6 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.6 | 2026-05-18 | Added dedicated Android voice-audio element allocations SysDes-152 (Android in-call audio mode subsystem, source SysRS-305), SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow as system-design partitioning between Permission Subsystem and Voice Subsystem, source SysRS-306), and SysDes-154 (Android voice audio backend subsystem: trait-based platform backend mirroring the iOS `VoiceProcessingIO` pattern, AAudio low-latency path, voice-communication usage/preset, hardware effects engagement, sharing-mode policy, FGS-hosted background mic lifecycle; source SysRS-055 + SysRS-305). SysDes-135 remains the Android platform-baseline context item and is unchanged. These derivations are the proper SysDes anchors for SRS-208, SRS-209, and SRS-210..215, which currently cite SysDes-135 generically and shall be retargeted by the software-requirements owner in a follow-up pass. Strict layered sourcing preserved (`SysDes -> SysRS` only). | + + +## Baseline Candidate 0.9.7 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.8 | 2026-05-18 | Added benchmark-infrastructure SysDes derivations SysDes-156, SysDes-157, and SysDes-158 sourced from SysRS-307 / SysRS-308 / SysRS-309 (Wave 1.5 benchmark chain, Step 2). SysDes-156 allocates the realtime-audio benchmark instrumentation surface (heap allocation count per realtime callback after warmup, per-callback wall-clock as a fraction of the cpal stream period at p50/p95/p99, Opus encode latency on a 960-sample / 20 ms frame, Opus decode latency on the same shape, and resampler throughput at 44.1→48 kHz, 16→48 kHz, and 48→48 kHz passthrough as a control) to SE-13 (Audio Subsystem); declares baseline storage as structured JSON committed to a deterministic repo location (exact path delegated to SDD) capturing metric value, host architecture, toolchain version, git SHA, and timestamp. SysDes-157 allocates the advisory CI integration to SE-18 (Deployment and Release Environment): trigger on every PR against the default branch + every merge to default (not on tags, not on non-default-branch pushes), host = Linux x86_64 (`ubuntu-latest`), surface = PR status-check view rendered as a markdown table with per-metric delta and a visual marker (🟢 within tolerance, 🟡 within tolerance but trending, 🔴 outside tolerance), strict non-blocking semantics (the check shall never report `failure` status — even on regression it reports `success` and surfaces the regression in the PR comment for human reviewer attention), baseline source = JSON on the default branch with first-run-establishes-candidate fallback, and baseline-update isolation via a separate `workflow_dispatch` workflow (PR-triggered workflow shall never write the baseline file). SysDes-158 authors the per-metric tolerance window and the comparison methodology: heap allocations tolerance = zero (any non-zero count is 🔴), per-callback wall-clock tolerance = +20% on p95 (p50 and p99 are advisory data only), Opus encode/decode latency tolerance = +15% on mean, resampler throughput tolerance = −10% on samples/second; comparison is against the most recent baseline committed to the default branch at the PR's merge-base. Allocated to SE-18 (comparison logic lives in CI tooling). Strict layered sourcing preserved (`SysDes -> SysRS` only). Explicitly **NOT** authored in this update, consistent with the SysRS-307/308/309 deferral: (a) Dimension 3 production telemetry export (deferred to P1; SysRS-307/308/309 do not authorize off-device transmission and SysRS-295 still applies); (b) build-failing hard CI gate (SysRS-308's advisory-only clause is the active rule — SysDes-157's non-blocking semantics enforces it at this layer); (c) multi-host benchmarking (ARM Android, macOS Apple Silicon, etc. — SysDes-157's Linux x86_64 host-scope clause is the active rule). | +| 0.9.7 | 2026-05-18 | Added dedicated macOS runtime baseline element allocation SysDes-155, parallel in role to SysDes-133 (iOS runtime baseline) and SysDes-135 (Android runtime baseline). SysDes-155 anchors the macOS deployment-target policy as a single-source-of-truth concern (citing the podspec file path `apps/chanora_flutter/macos/chanora_bridge.podspec` without embedding its value), the universal-binary (`lipo`'d `arm64` + `x86_64`) packaging policy, the `.framework` `Versions/A` bundle layout convention, and CocoaPods podspec integration as the auto-build mechanism for the Rust cdylib. Allocated to macOS Build Configuration, Platform Adapter Layer (macOS Platform Services), Release Pipeline, and Verification. Source SysRS: SysRS-002 (multi-platform target client platforms including macOS), SysRS-050 (macOS runtime environment / native desktop window integration), SysRS-193 (signed/notarized macOS builds). SysDes-155 is the proper SysDes anchor for SAD-087 and for downstream SRS items that allocate macOS-runtime responsibility, and is the recommended retarget for SAD-087's previously-open Source SysDes follow-up. SysDes-133 and SysDes-135 are unchanged. Strict layered sourcing preserved (`SysDes -> SysRS` only). Follow-up recommendation: systems-requirements owner may consider authoring a finer-grained macOS minimum-runtime SysRS item parallel to SysRS-286 (iOS) and SysRS-288 (Android); SysDes-155 is structured so that such a future SysRS item can be added to its `Allocated SysRS` list without restructuring the element. | diff --git a/docs/additional_docs/sysrs.md b/docs/additional_docs/sysrs.md new file mode 100644 index 0000000..7fcd503 --- /dev/null +++ b/docs/additional_docs/sysrs.md @@ -0,0 +1,2007 @@ +# Chanora SysRS — System Requirements Specification + +**Product name:** Chanora +**Document type:** SysRS / System Requirements Specification +**Version:** 0.9.11 +**Status:** Baseline Candidate +**Product category:** Cross-platform voice client application +**Architecture:** Flutter + Rust Core +**Protocol library:** `tsclientlib` +**Target client platforms:** Windows, macOS, Linux, iOS, Android +**Source material:** Initial Chanora application-system requirements draft +**Supersedes:** Earlier mixed SYS/SRS draft + +**Repo path:** `docs/requirements/sysrs.md` --- + +## 1. Document Control + +### 1.1 Purpose + +This document is the **System Requirements Specification (SysRS)** for the **Chanora application system**. + +Chanora is an **application**, not an operating system. In this document, the word **system** means the complete application system and its runtime environment: + +- The Chanora client application +- The Flutter user interface +- The Rust Core +- The `tsclientlib` protocol adapter +- Platform adapters +- Local and secure storage +- Audio input/output devices used by the application +- Operating system services used by the application +- Network connectivity required by the application +- External TeamSpeak 3-compatible servers used by the application +- Deployment, diagnostics, and support processes + +The SysRS covers the whole environment required for the application to run correctly. It does not claim that Chanora is an operating system. + +--- + +### 1.2 SysRS vs Software SRS + +A software-only SRS would focus mainly on the application code. + +This SysRS includes both application requirements and runtime environment requirements, including: + +- Client device requirements +- Operating system service requirements +- Audio hardware requirements +- Network requirements +- External compatible server requirements +- Deployment requirements +- Security and privacy requirements +- Diagnostics and support requirements + +--- + +### 1.3 Requirement ID Convention + +Every normative requirement uses this format: + +```text +SysRS-XXX +``` + +Where `XXX` is a three-digit sequential number. + +Requirement keywords: + +| Keyword | Meaning | +|---|---| +| shall | Mandatory | +| should | Strongly recommended | +| may | Optional | +| shall not | Prohibited | + +Priority values: + +| Priority | Meaning | +|---|---| +| P0 | Required for MVP | +| P1 | Required for Beta | +| P2 | Required for Production | +| P3 | Future or optional | + +Verification methods: + +| Method | Meaning | +|---|---| +| Review | Verified by reviewing documentation, requirements, or design | +| Inspection | Verified by inspecting code, configuration, packaging, or environment setup | +| Test | Verified by automated or manual test | +| Demo | Verified through a working demonstration | +| Audit | Verified through security, privacy, legal, or compliance review | + +--- + +### 1.4 Input Reference Documents + +| Document | Description | +|---|---| +| Initial Chanora application-system requirements draft | Source material used to prepare this SysRS | + +### 1.5 Downstream Lifecycle Documents + +The downstream engineering documentation sequence shall be: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification +``` + +This SysRS is the system-level requirements baseline. Downstream documents shall be derived from this SysRS and shall not override it unless the SysRS is formally revised. + +| Order | Document | Purpose | +|---:|---|---| +| 1 | SysRS — System Requirements Specification | Defines whole application-system requirements, including client application behavior, runtime environment, devices, networks, external compatible servers, security, deployment, diagnostics, and operational constraints. | +| 2 | SysDes — System Design Specification | Defines system-level design and allocation of SysRS requirements to system elements such as Flutter UI, Rust Core, protocol adapter, audio subsystem, platform adapters, storage, diagnostics, external servers, and deployment environment. | +| 3 | SRS — Software Requirements Specification | Defines software-only requirements for the Chanora software components derived from the SysRS and SysDes. | +| 4 | SAD — Software Architecture Description | Defines software architecture views, major software components, interfaces, runtime flows, dependency rules, and architectural decisions. | +| 5 | SDD — Software Detailed Design | Defines detailed module design, APIs, data structures, state machines, database schemas, DTOs, bridge contracts, and implementation-level design details. | +| 6 | Verification | Defines verification plans, test cases, acceptance criteria, traceability matrices, platform compatibility tests, security checks, audio validation, and release validation. | + +Potential downstream file names: + +| Document | Suggested file | +|---|---| +| SysDes | `docs/chanora_SysDes.md` | +| SRS | `docs/chanora_SRS.md` | +| SAD | `docs/chanora_SAD.md` | +| SDD | `docs/chanora_SDD.md` | +| Verification | `docs/chanora_Verification.md` | + +--- + +## 2. System Overview + +### 2.1 Application Context + +```text +┌─────────────────────────────────────────────────────────────────────────────┐ +│ User Runtime Environment │ +│ │ +│ ┌────────────────────┐ ┌─────────────────────────────────────────┐ │ +│ │ Audio Hardware │<----->│ Chanora Client Application │ │ +│ │ Mic / Headset │ │ │ │ +│ │ Speakers / BT │ │ Flutter UI │ │ +│ └────────────────────┘ │ Flutter State Layer │ │ +│ │ Bridge Layer │ │ +│ ┌────────────────────┐ │ Rust Core │ │ +│ │ OS Services │<----->│ tsclientlib Protocol Adapter │ │ +│ │ Permissions │ │ Audio Processing Pipeline │ │ +│ │ Secure Storage │ │ Local Storage │ │ +│ │ Audio Session │ │ Diagnostics │ │ +│ │ Notifications │ └─────────────────────────────────────────┘ │ +│ └────────────────────┘ │ │ +│ │ Network │ +│ v │ +│ ┌─────────────────────────────────────────┐ │ +│ │ External TeamSpeak 3-compatible Server │ │ +│ │ Channels / Clients / Voice / Text │ │ +│ └─────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────────────────┘ +``` + +### 2.2 System Boundary + +Inside the Chanora application system boundary: + +- Chanora client application +- Flutter UI +- Flutter state layer +- Rust Core +- Bridge layer +- `tsclientlib` adapter +- Audio processing pipeline +- Local database +- Secure storage adapter +- Diagnostics and export tools +- Platform service adapters + +Outside the Chanora application system boundary: + +- External TeamSpeak 3-compatible servers +- Server administration and server-side permissions +- Physical audio hardware +- Operating system vendor services +- App stores and package repositories +- User-managed routers, firewalls, VPNs, NAT devices, and ISPs + +### 2.3 Primary Runtime Flow + +```text +User action + -> Flutter UI + -> Bridge command + -> Rust Core + -> tsclientlib protocol adapter + -> External compatible voice server + -> Protocol event + -> Rust Core state reducer + -> Bridge event stream + -> Flutter UI update +``` + +### 2.4 Primary Audio Flow + +```text +Microphone + -> OS/platform capture + -> Audio preprocessing + -> High-Pass Filter + -> Noise Suppression + -> Echo Canceller + -> Automatic Gain Control + -> Push-to-talk / mute gate + -> Opus-compatible encoder + -> tsclientlib protocol adapter + -> External compatible server + +External compatible server + -> tsclientlib protocol adapter + -> Jitter buffer + -> Opus-compatible decoder + -> Per-user mute/volume + -> Mixer + -> OS/platform playback + -> Speaker/headphones +``` + + +## 3. Application System Scope Requirements + + +**SysRS-001**: The Chanora application shall be a cross-platform client application for channel-based voice communication. + +- Priority: P0 +- Verification: Review + +**SysRS-002**: The Chanora application shall support Windows, macOS, Linux, iOS, and Android as target client platforms. + +- Priority: P0 +- Verification: Review + +**SysRS-003**: The Chanora application shall use Flutter for the user-facing client interface. + +- Priority: P0 +- Verification: Inspection + +**SysRS-004**: The Chanora application shall use Rust Core for protocol handling, connection management, state synchronization, audio processing, storage coordination, diagnostics, and business logic. + +- Priority: P0 +- Verification: Inspection + +**SysRS-005**: The Chanora application shall use `tsclientlib` as the TeamSpeak-compatible protocol client library. + +- Priority: P0 +- Verification: Inspection + +**SysRS-006**: The Chanora application shall operate as an independent client and shall not present itself as an official TeamSpeak product. + +- Priority: P0 +- Verification: Audit + +**SysRS-007**: The Chanora application shall allow users to connect to TeamSpeak 3-compatible servers reachable from the client device network. + +- Priority: P0 +- Verification: Test + +**SysRS-008**: The Chanora application shall allow users to participate in channel-based voice communication when the external server and user permissions allow it. + +- Priority: P0 +- Verification: Test + +**SysRS-009**: The Chanora application shall allow users to send and receive supported text messages when the external server and user permissions allow it. + +- Priority: P0 +- Verification: Test + +**SysRS-010**: The Chanora application shall provide local bookmark, recent server, identity reference, UI setting, and audio setting management on the client device. + +- Priority: P0 +- Verification: Test + + +## 4. Stakeholder and User Environment Requirements + + +**SysRS-011**: The Chanora application shall support end users who manually connect to compatible voice servers. + +- Priority: P0 +- Verification: Demo + +**SysRS-012**: The Chanora application shall support regular users who rely on saved bookmarks, persistent identity, audio settings, and common voice controls. + +- Priority: P0 +- Verification: Demo + +**SysRS-013**: The Chanora application shall support testers and support operators who export diagnostics for troubleshooting. + +- Priority: P1 +- Verification: Demo + +**SysRS-014**: The SysRS shall provide requirements traceability suitable for engineering, QA, system administration, and release operations. + +- Priority: P1 +- Verification: Review + +**SysRS-015**: The SysRS shall document external environment dependencies that may need administrator configuration, including network reachability and OS-level audio permissions. + +- Priority: P1 +- Verification: Review + + +## 5. System Boundary and External Dependency Requirements + + +**SysRS-016**: The Chanora application shall treat external TeamSpeak 3-compatible servers as external systems outside Chanora control. + +- Priority: P0 +- Verification: Review + +**SysRS-017**: The Chanora application shall not require a Chanora-operated central server for MVP voice, channel, or text operation. + +- Priority: P0 +- Verification: Review + +**SysRS-018**: The Chanora application shall not host or operate TeamSpeak-compatible server functionality in the MVP. + +- Priority: P0 +- Verification: Review + +**SysRS-019**: The Chanora application shall rely on operating system services for microphone permission, secure storage, audio routing, notifications, and mobile lifecycle behavior. + +- Priority: P0 +- Verification: Review + +**SysRS-020**: The Chanora application shall treat app stores, package repositories, installers, and update services as deployment environment components. + +- Priority: P1 +- Verification: Review + +**SysRS-021**: The Chanora application shall treat physical microphones, speakers, wired headsets, USB audio devices, and Bluetooth audio devices as external hardware interfaces. + +- Priority: P0 +- Verification: Review + +**SysRS-022**: The Chanora application shall treat routers, firewalls, VPNs, NAT devices, and ISPs as external network environment components. + +- Priority: P1 +- Verification: Review + +**SysRS-023**: The Chanora application shall expose user-safe errors when external dependencies prevent successful operation. + +- Priority: P0 +- Verification: Test + + +## 6. Application Component Requirements + + +**SysRS-024**: The Chanora application shall include a Flutter UI component responsible for rendering screens, receiving user input, and presenting application state. + +- Priority: P0 +- Verification: Inspection + +**SysRS-025**: The Chanora application shall include a Flutter State Layer responsible for UI state derived from Rust Core events. + +- Priority: P0 +- Verification: Inspection + +**SysRS-026**: The Chanora application shall include a Bridge Layer responsible for commands, DTOs, asynchronous calls, and event streams between Flutter and Rust Core. + +- Priority: P0 +- Verification: Inspection + +**SysRS-027**: The Chanora application shall include a Rust Core component responsible for authoritative connection, protocol, state, audio, storage, settings, and diagnostics behavior. + +- Priority: P0 +- Verification: Inspection + +**SysRS-028**: The Chanora application shall include a protocol adapter component that isolates direct `tsclientlib` usage. + +- Priority: P0 +- Verification: Inspection + +**SysRS-029**: The Chanora application shall include a state synchronization component that implements snapshot + delta state handling. + +- Priority: P0 +- Verification: Inspection + +**SysRS-030**: The Chanora application shall include an audio subsystem component that coordinates capture, processing, encoding, decoding, jitter buffering, mixing, and playback. + +- Priority: P0 +- Verification: Inspection + +**SysRS-031**: The Chanora application shall include a local storage component for non-secret data such as bookmarks, recent servers, UI settings, and audio settings. + +- Priority: P0 +- Verification: Inspection + +**SysRS-032**: The Chanora application shall include a secure storage adapter for private identities, passwords, and future sensitive tokens. + +- Priority: P0 +- Verification: Inspection + +**SysRS-033**: The Chanora application shall include a diagnostics component for structured logging, redaction, event recording, event replay, audio diagnostics, network diagnostics, and user-initiated export. + +- Priority: P1 +- Verification: Inspection + +**SysRS-034**: The Chanora application shall include platform adapter components for desktop and mobile platform services. + +- Priority: P0 +- Verification: Inspection + + +## 7. Client Device and Hardware Environment Requirements + + +**SysRS-035**: The client device shall use a CPU architecture supported by Flutter, Rust, and the selected target platform. + +- Priority: P0 +- Verification: Inspection + +**SysRS-036**: The client device shall provide sufficient CPU capacity to run the Chanora application, Opus-compatible voice processing, and enabled audio processing features in real time. + +- Priority: P0 +- Verification: Test + +**SysRS-037**: The client device shall provide sufficient memory for the Chanora application to run without unbounded growth in logs, chat history, audio buffers, or event queues. + +- Priority: P0 +- Verification: Test + +**SysRS-038**: The client device shall provide persistent local storage for Chanora application data, settings, logs, and cached metadata. + +- Priority: P0 +- Verification: Inspection + +**SysRS-039**: The client device shall provide a microphone or supported audio input device for voice transmission. + +- Priority: P0 +- Verification: Test + +**SysRS-040**: The client device shall provide speakers, headphones, or a supported audio output device for voice playback. + +- Priority: P0 +- Verification: Test + +**SysRS-041**: The client device shall provide network connectivity to the selected compatible voice server. + +- Priority: P0 +- Verification: Test + +**SysRS-042**: The desktop client environment should be validated on devices with at least 4 GB RAM for MVP operation. + +- Priority: P1 +- Verification: Test + +**SysRS-043**: The desktop client environment should be validated with at least 500 MB free local storage for installation, settings, logs, and diagnostic bundle creation. + +- Priority: P1 +- Verification: Test + +**SysRS-044**: The client device should provide stable audio device identifiers where the target platform supports persistent device selection. + +- Priority: P1 +- Verification: Test + +**SysRS-045**: The client device should provide hardware or OS support for low-latency audio capture and playback. + +- Priority: P1 +- Verification: Test + +**SysRS-046**: The client device should provide Bluetooth audio support where the target operating system supports it. + +- Priority: P1 +- Verification: Test + +**SysRS-047**: The project shall document platform-specific hardware limitations discovered during compatibility testing. + +- Priority: P1 +- Verification: Review + + +## 8. Operating System Service Requirements + + +**SysRS-048**: The Windows runtime environment shall support native desktop window integration for the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-049**: The Windows runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure credential storage to the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-050**: The macOS runtime environment shall support native desktop window integration for the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-051**: The macOS runtime environment shall provide microphone permission prompts, microphone capture, speaker/headphone playback, audio device selection, and Keychain access to the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-052**: The Linux runtime environment shall support the desktop environments targeted by the selected release package. + +- Priority: P1 +- Verification: Test + +**SysRS-053**: The Linux runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure storage through Secret Service, libsecret, or equivalent where available. + +- Priority: P1 +- Verification: Test + +**SysRS-054**: The iOS runtime environment shall provide microphone permissions, foreground voice session capability, audio route change handling, audio interruption recovery, Keychain access, and AVAudioSession behavior to the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-055**: The Android runtime environment shall provide microphone permissions, foreground voice session capability, foreground service behavior, audio focus, Bluetooth route handling, Android Keystore access, and production audio integration through AAudio, Oboe, or equivalent. + +- Priority: P0 +- Verification: Test + +**SysRS-056**: The project shall define minimum supported operating system versions for each target platform before beta release. + +- Priority: P1 +- Verification: Review + +**SysRS-057**: The project shall document OS-level permissions required by each target platform before public release. + +- Priority: P1 +- Verification: Review + +**SysRS-058**: The Chanora application shall fail safely with a user-safe message when a required OS service is unavailable. + +- Priority: P0 +- Verification: Test + + +## 9. Audio Hardware and Audio Processing Requirements + + +**SysRS-059**: The Chanora application shall support microphone input for voice transmission. + +- Priority: P0 +- Verification: Test + +**SysRS-060**: The Chanora application shall support speaker or headphone output for voice playback. + +- Priority: P0 +- Verification: Test + +**SysRS-061**: The Chanora application shall support audio input and output device selection where the target platform exposes selectable devices. + +- Priority: P0 +- Verification: Test + +**SysRS-062**: The Chanora application shall handle audio route changes where the target platform reports them. + +- Priority: P0 +- Verification: Test + +**SysRS-063**: The Chanora application shall recover gracefully from audio device changes where possible. + +- Priority: P1 +- Verification: Test + +**SysRS-064**: The Chanora application shall support Echo Canceller for reducing playback audio leaking into microphone input. + +- Priority: P0 +- Verification: Test + +**SysRS-065**: The Chanora application shall support Automatic Gain Control for normalizing microphone input level. + +- Priority: P0 +- Verification: Test + +**SysRS-066**: The Chanora application shall support Noise Suppression for reducing stationary background noise. + +- Priority: P0 +- Verification: Test + +**SysRS-067**: The Chanora application shall support High-Pass Filter for reducing low-frequency rumble and handling noise. + +- Priority: P0 +- Verification: Test + +**SysRS-068**: The Chanora application shall support an audio processing backend abstraction so platform-native and Rust-based processing can be selected per platform. + +- Priority: P1 +- Verification: Review + +**SysRS-069**: The Chanora application shall allow Echo Canceller to use playback reference audio when the selected implementation requires it. + +- Priority: P0 +- Verification: Test + +**SysRS-070**: The Chanora application shall expose audio processing settings to Rust Core and persist them locally. + +- Priority: P0 +- Verification: Test + +**SysRS-071**: The Chanora application shall provide conservative default settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. + +- Priority: P0 +- Verification: Review + +**SysRS-072**: The Chanora application shall allow platform-specific disabling of audio processing features when a feature is unstable or incompatible with a device configuration. + +- Priority: P0 +- Verification: Test + +**SysRS-073**: The project shall provide an audio loopback test tool for development and compatibility testing. + +- Priority: P1 +- Verification: Demo + +**SysRS-074**: The project shall provide an audio processing test tool for development and compatibility testing. + +- Priority: P1 +- Verification: Demo + + +## 10. Network Environment Requirements + + +**SysRS-075**: The client network environment shall provide IP network connectivity from the client device to the selected compatible voice server. + +- Priority: P0 +- Verification: Test + +**SysRS-076**: The Chanora application shall allow the user to configure the server host or IP address. + +- Priority: P0 +- Verification: Test + +**SysRS-077**: The Chanora application shall allow the user to configure the server port. + +- Priority: P0 +- Verification: Test + +**SysRS-078**: The Chanora application should support a default TeamSpeak 3-compatible voice port when the user does not provide an explicit port. + +- Priority: P1 +- Verification: Test + +**SysRS-079**: The client network environment shall permit the protocol traffic required by `tsclientlib` and the selected compatible server. + +- Priority: P0 +- Verification: Test + +**SysRS-080**: The client network environment shall support latency suitable for real-time voice communication under expected operating conditions. + +- Priority: P0 +- Verification: Test + +**SysRS-081**: The client network environment should minimize packet loss for acceptable voice quality. + +- Priority: P1 +- Verification: Test + +**SysRS-082**: The Chanora application shall detect recoverable network failures where possible. + +- Priority: P0 +- Verification: Test + +**SysRS-083**: The Chanora application shall enter reconnect behavior after recoverable network failures. + +- Priority: P0 +- Verification: Test + +**SysRS-084**: The Chanora application shall rebuild server state from a fresh snapshot after reconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-085**: The Chanora application shall not require VPN connectivity unless the target server or user environment requires it. + +- Priority: P1 +- Verification: Review + +**SysRS-086**: The Chanora application shall present network failures through user-safe error messages. + +- Priority: P0 +- Verification: Test + +**SysRS-087**: The Chanora application should include network diagnostics in user-initiated diagnostic exports. + +- Priority: P1 +- Verification: Inspection + + +## 11. External Compatible Server Requirements + + +**SysRS-088**: The external voice server shall be TeamSpeak 3-compatible for Chanora MVP operation. + +- Priority: P0 +- Verification: Test + +**SysRS-089**: The external voice server shall be reachable from the client device network. + +- Priority: P0 +- Verification: Test + +**SysRS-090**: The external voice server shall permit client connection using the identity, nickname, password, and permissions supplied by the user. + +- Priority: P0 +- Verification: Test + +**SysRS-091**: The external voice server shall expose server information required for initial synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-092**: The external voice server shall expose channel listing required for the channel tree. + +- Priority: P0 +- Verification: Test + +**SysRS-093**: The external voice server shall expose client listing required for the online client view. + +- Priority: P0 +- Verification: Test + +**SysRS-094**: The external voice server shall support channel join operations for accessible channels. + +- Priority: P0 +- Verification: Test + +**SysRS-095**: The external voice server shall emit channel movement events required for state synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-096**: The external voice server shall emit client join and leave events required for state synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-097**: The external voice server shall emit channel create, update, and delete events required for state synchronization where those events occur. + +- Priority: P0 +- Verification: Test + +**SysRS-098**: The external voice server shall support channel text message send and receive where user permissions allow. + +- Priority: P0 +- Verification: Test + +**SysRS-099**: The external voice server shall support voice packet send and receive where user permissions allow. + +- Priority: P0 +- Verification: Test + +**SysRS-100**: The external voice server shall expose disconnect behavior or connection failure signals that can be mapped by the protocol adapter. + +- Priority: P0 +- Verification: Test + +**SysRS-101**: The project shall document server-side permissions that can affect channel join, voice transmission, and text messaging. + +- Priority: P1 +- Verification: Review + + +## 12. Application Functional Requirements + + +**SysRS-102**: The Chanora application shall allow the user to manually connect to a compatible server. + +- Priority: P0 +- Verification: Demo + +**SysRS-103**: The Chanora application shall allow the user to provide hostname or IP address, port, nickname, and optional server password before connection. + +- Priority: P0 +- Verification: Demo + +**SysRS-104**: The Chanora application shall support persistent local identity for compatible server authentication. + +- Priority: P0 +- Verification: Demo + +**SysRS-105**: The Chanora application shall display connection status to the user. + +- Priority: P0 +- Verification: Demo + +**SysRS-106**: The Chanora application shall allow the user to disconnect from the active server connection. + +- Priority: P0 +- Verification: Demo + +**SysRS-107**: The Chanora application shall display the server channel tree after synchronization. + +- Priority: P0 +- Verification: Demo + +**SysRS-108**: The Chanora application shall display online clients after synchronization. + +- Priority: P0 +- Verification: Demo + +**SysRS-109**: The Chanora application shall allow the user to join an accessible voice channel. + +- Priority: P0 +- Verification: Demo + +**SysRS-110**: The Chanora application shall allow the user to send and receive channel text messages where permitted. + +- Priority: P0 +- Verification: Demo + +**SysRS-111**: The Chanora application shall capture and transmit voice where permitted. + +- Priority: P0 +- Verification: Demo + +**SysRS-112**: The Chanora application shall receive and play voice where permitted. + +- Priority: P0 +- Verification: Demo + +**SysRS-113**: The Chanora application shall provide microphone mute control. + +- Priority: P0 +- Verification: Demo + +**SysRS-114**: The Chanora application shall provide output deaf control. + +- Priority: P0 +- Verification: Demo + +**SysRS-115**: The Chanora application shall provide push-to-talk control. + +- Priority: P0 +- Verification: Demo + +**SysRS-116**: The Chanora application shall display microphone input level where available. + +- Priority: P0 +- Verification: Demo + +**SysRS-117**: The Chanora application shall display speaking indicators where available. + +- Priority: P0 +- Verification: Demo + +**SysRS-118**: The Chanora application shall allow users to save and reuse server bookmarks. + +- Priority: P0 +- Verification: Demo + +**SysRS-119**: The Chanora application shall allow users to configure audio processing features. + +- Priority: P0 +- Verification: Demo + +**SysRS-120**: The Chanora application shall allow users to export redacted diagnostics. + +- Priority: P1 +- Verification: Demo + + +## 13. Protocol Integration Requirements + + +**SysRS-121**: The Chanora application shall use `tsclientlib` inside the protocol subsystem. + +- Priority: P0 +- Verification: Inspection + +**SysRS-122**: The Chanora application shall isolate direct `tsclientlib` calls inside the `chanora_protocol` component. + +- Priority: P0 +- Verification: Inspection + +**SysRS-123**: The Chanora application shall prevent raw `tsclientlib` types from crossing into Flutter UI or Flutter State Layer. + +- Priority: P0 +- Verification: Inspection + +**SysRS-124**: The Chanora application shall convert `tsclientlib` errors into Chanora protocol errors. + +- Priority: P0 +- Verification: Test + +**SysRS-125**: The Chanora application shall convert `tsclientlib` events into internal protocol events. + +- Priority: P0 +- Verification: Test + +**SysRS-126**: The Chanora application shall support future patching, replacement, or forking of protocol implementation without changing Flutter UI contracts. + +- Priority: P1 +- Verification: Review + +**SysRS-127**: The project shall provide protocol compatibility test coverage for MVP features. + +- Priority: P1 +- Verification: Test + +**SysRS-128**: The project shall include a protocol probe tool for validating target server compatibility. + +- Priority: P0 +- Verification: Demo + + +## 14. State Synchronization Requirements + + +**SysRS-129**: The Chanora application shall maintain one authoritative connection state per active server connection. + +- Priority: P0 +- Verification: Test + +**SysRS-130**: The Chanora application shall synchronize state using a snapshot + delta model. + +- Priority: P0 +- Verification: Test + +**SysRS-131**: The Chanora application shall emit a full snapshot after initial synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-132**: The Chanora application shall emit delta events after live server-side changes. + +- Priority: P0 +- Verification: Test + +**SysRS-133**: The Chanora application shall apply protocol events through deterministic reducers. + +- Priority: P0 +- Verification: Test + +**SysRS-134**: The Chanora application shall preserve event ordering per connection. + +- Priority: P0 +- Verification: Test + +**SysRS-135**: The Chanora application shall rebuild state from a fresh snapshot after reconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-136**: The Chanora application shall prevent Flutter from directly mutating server state. + +- Priority: P0 +- Verification: Inspection + +**SysRS-137**: The Chanora application shall implement the defined connection state machine from Disconnected through Connecting, Synchronizing, Connected, and Reconnecting. + +- Priority: P0 +- Verification: Test + +**SysRS-138**: The Chanora application shall not automatically reconnect after user-triggered disconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-139**: The project shall include an event replay tool for development and debugging of state synchronization. + +- Priority: P1 +- Verification: Demo + + +## 15. Data and Storage Requirements + + +**SysRS-140**: The Chanora application shall store server bookmarks locally. + +- Priority: P0 +- Verification: Test + +**SysRS-141**: The Chanora application shall store recent servers locally. + +- Priority: P1 +- Verification: Test + +**SysRS-142**: The Chanora application shall store audio settings locally. + +- Priority: P0 +- Verification: Test + +**SysRS-143**: The Chanora application shall store UI settings locally. + +- Priority: P1 +- Verification: Test + +**SysRS-144**: The Chanora application shall store per-user volume preferences locally where applicable. + +- Priority: P1 +- Verification: Test + +**SysRS-145**: The Chanora application shall store muted user preferences locally where applicable. + +- Priority: P1 +- Verification: Test + +**SysRS-146**: The Chanora application shall use SQLite or an equivalent embedded database for non-secret local data. + +- Priority: P0 +- Verification: Inspection + +**SysRS-147**: The Chanora application shall use platform secure storage for sensitive data. + +- Priority: P0 +- Verification: Audit + +**SysRS-148**: The Chanora application shall store identity private keys using platform secure storage. + +- Priority: P0 +- Verification: Audit + +**SysRS-149**: The Chanora application shall store server passwords using platform secure storage. + +- Priority: P0 +- Verification: Audit + +**SysRS-150**: The Chanora application shall not store private keys in plaintext files. + +- Priority: P0 +- Verification: Audit + +**SysRS-151**: The Chanora application shall not write passwords to logs. + +- Priority: P0 +- Verification: Audit + +**SysRS-152**: The Chanora application shall redact secrets from diagnostic exports. + +- Priority: P0 +- Verification: Audit + + +## 16. Security and Privacy Requirements + + +**SysRS-153**: The Chanora application shall store sensitive data using platform secure storage. + +- Priority: P0 +- Verification: Audit + +**SysRS-154**: The Chanora application shall redact secrets from logs. + +- Priority: P0 +- Verification: Audit + +**SysRS-155**: The Chanora application shall redact secrets from diagnostic bundles. + +- Priority: P0 +- Verification: Audit + +**SysRS-156**: The Chanora application shall avoid exposing internal stack traces to normal users. + +- Priority: P0 +- Verification: Test + +**SysRS-157**: The Chanora application shall validate user input before passing it to protocol operations. + +- Priority: P0 +- Verification: Test + +**SysRS-158**: The Windows runtime environment shall support Windows Credential Manager, DPAPI, or equivalent secure credential storage for the Chanora application. + +- Priority: P1 +- Verification: Inspection + +**SysRS-159**: The macOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. + +- Priority: P1 +- Verification: Inspection + +**SysRS-160**: The iOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. + +- Priority: P0 +- Verification: Inspection + +**SysRS-161**: The Android runtime environment shall support Android Keystore or equivalent secure credential storage for the Chanora application. + +- Priority: P0 +- Verification: Inspection + +**SysRS-162**: The Linux runtime environment shall support Secret Service, libsecret, or equivalent secure storage where available. + +- Priority: P2 +- Verification: Inspection + +**SysRS-163**: The Chanora application shall minimize collection of personal data. + +- Priority: P0 +- Verification: Audit + +**SysRS-164**: The Chanora application shall require user action before exporting diagnostics. + +- Priority: P0 +- Verification: Test + +**SysRS-165**: The Chanora application shall explain microphone permission usage before requesting permission where platform guidelines allow. + +- Priority: P0 +- Verification: Test + +**SysRS-166**: The Chanora application shall explain notification permission usage before requesting permission where platform guidelines allow. + +- Priority: P1 +- Verification: Test + +**SysRS-167**: The Chanora application shall not automatically upload diagnostics in MVP. + +- Priority: P0 +- Verification: Audit + + +## 17. Diagnostics and Operations Requirements + + +**SysRS-168**: The Chanora application shall produce structured diagnostic logs. + +- Priority: P0 +- Verification: Inspection + +**SysRS-169**: The Chanora application shall support log redaction. + +- Priority: P0 +- Verification: Audit + +**SysRS-170**: The Chanora application shall support protocol event recording in development or diagnostics mode. + +- Priority: P1 +- Verification: Demo + +**SysRS-171**: The Chanora application shall support event replay for debugging state synchronization. + +- Priority: P1 +- Verification: Demo + +**SysRS-172**: The Chanora application shall support audio diagnostics. + +- Priority: P1 +- Verification: Demo + +**SysRS-173**: The Chanora application shall support network diagnostics. + +- Priority: P1 +- Verification: Demo + +**SysRS-174**: The Chanora application shall support user-initiated diagnostic export. + +- Priority: P1 +- Verification: Demo + +**SysRS-175**: Diagnostic export shall exclude or redact sensitive data. + +- Priority: P0 +- Verification: Audit + +**SysRS-176**: The project shall document the expected support workflow for diagnostic bundle collection. + +- Priority: P2 +- Verification: Review + +**SysRS-177**: The project shall include compatibility test tracking for supported platforms. + +- Priority: P1 +- Verification: Inspection + + +## 18. Non-Functional Requirements + + +**SysRS-178**: The Chanora application shall keep the UI responsive during connection, synchronization, and reconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-179**: The Chanora application shall avoid visible UI freezes longer than 100 ms during normal operation. + +- Priority: P0 +- Verification: Test + +**SysRS-180**: The Chanora application shall minimize local audio pipeline latency. + +- Priority: P0 +- Verification: Test + +**SysRS-181**: The Chanora application should target local audio pipeline latency under 100 ms where platform conditions permit. + +- Priority: P1 +- Verification: Test + +**SysRS-182**: The Chanora application shall avoid unbounded memory growth in chat history. + +- Priority: P0 +- Verification: Test + +**SysRS-183**: The Chanora application shall avoid unbounded memory growth in logs. + +- Priority: P0 +- Verification: Test + +**SysRS-184**: The Chanora application shall avoid unbounded memory growth in audio buffers. + +- Priority: P0 +- Verification: Test + +**SysRS-185**: The Chanora application shall avoid unbounded memory growth in event queues. + +- Priority: P0 +- Verification: Test + +**SysRS-186**: The Chanora application shall perform required audio processing without sustained underruns on supported devices. + +- Priority: P0 +- Verification: Test + +**SysRS-187**: The Chanora application shall keep reconnect processing non-blocking for UI interaction. + +- Priority: P0 +- Verification: Test + +**SysRS-188**: The Chanora application shall recover from transient network loss where possible. + +- Priority: P0 +- Verification: Test + +**SysRS-189**: The Chanora application shall recover gracefully from audio device changes where possible. + +- Priority: P1 +- Verification: Test + +**SysRS-190**: The Chanora application shall isolate connection failures to the affected connection. + +- Priority: P1 +- Verification: Test + +**SysRS-191**: The Chanora application shall avoid crashing on malformed or unexpected protocol events. + +- Priority: P0 +- Verification: Test + + +## 19. Deployment and Release Environment Requirements + + +**SysRS-192**: The project shall support Windows installer packaging for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-193**: The project shall support macOS signed and notarized builds for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-194**: The project shall support Linux packaging through AppImage, Flatpak, deb, rpm, or a selected subset. + +- Priority: P1 +- Verification: Demo + +**SysRS-195**: The project shall support Android AAB release builds for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-196**: The project shall support iOS TestFlight and App Store release builds for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-197**: The project shall document platform signing, packaging, and release requirements before public release. + +- Priority: P1 +- Verification: Review + +**SysRS-198**: The project shall ensure release metadata does not imply official TeamSpeak affiliation. + +- Priority: P0 +- Verification: Audit + +**SysRS-199**: The project shall define release channels for internal, beta, and production builds before external testing. + +- Priority: P1 +- Verification: Review + + +## 20. Interface Requirements + + +**SysRS-200**: The Chanora application shall provide a user interface for manual server connection. + +- Priority: P0 +- Verification: Demo + +**SysRS-201**: The Chanora application shall provide a user interface for bookmark management. + +- Priority: P0 +- Verification: Demo + +**SysRS-202**: The Chanora application shall provide a user interface for channel tree navigation. + +- Priority: P0 +- Verification: Demo + +**SysRS-203**: The Chanora application shall provide a user interface for chat. + +- Priority: P0 +- Verification: Demo + +**SysRS-204**: The Chanora application shall provide a user interface for voice controls. + +- Priority: P0 +- Verification: Demo + +**SysRS-205**: The Chanora application shall provide a user interface for audio processing settings. + +- Priority: P0 +- Verification: Demo + +**SysRS-206**: The Chanora application shall provide a bridge interface between Flutter and Rust Core. + +- Priority: P0 +- Verification: Inspection + +**SysRS-207**: The Chanora application shall provide a protocol interface between Rust Core and `tsclientlib`. + +- Priority: P0 +- Verification: Inspection + +**SysRS-208**: The Chanora application shall provide an audio hardware interface through platform capture and playback adapters. + +- Priority: P0 +- Verification: Test + +**SysRS-209**: The Chanora application shall provide secure storage interfaces through platform-specific secure storage mechanisms. + +- Priority: P0 +- Verification: Audit + +**SysRS-210**: The Chanora application shall provide a network interface to external TeamSpeak 3-compatible servers through `tsclientlib`. + +- Priority: P0 +- Verification: Test + + +## 21. System Constraints + + +**SysRS-211**: The Chanora application shall not directly expose raw `tsclientlib` types to Flutter. + +- Priority: P0 +- Verification: Inspection + +**SysRS-212**: The Chanora application shall not store private keys in plaintext files. + +- Priority: P0 +- Verification: Audit + +**SysRS-213**: The Chanora application shall not write passwords to logs. + +- Priority: P0 +- Verification: Audit + +**SysRS-214**: The Chanora application shall not imply official TeamSpeak affiliation in UI, documentation, or release metadata. + +- Priority: P0 +- Verification: Audit + +**SysRS-215**: The Chanora application shall not automatically upload diagnostic information in MVP. + +- Priority: P0 +- Verification: Audit + +**SysRS-216**: The Chanora application shall comply with iOS background execution policies. + +- Priority: P0 +- Verification: Audit + +**SysRS-217**: The Chanora application shall comply with Android foreground service requirements for active voice sessions. + +- Priority: P0 +- Verification: Audit + +**SysRS-218**: The MVP shall not require Chanora-operated backend infrastructure for voice, channels, or text. + +- Priority: P0 +- Verification: Review + + +## 22. Assumptions + + +**SysRS-219**: The selected `tsclientlib` version can support or be extended to support required MVP protocol features. + +- Priority: P0 +- Verification: Review + +**SysRS-220**: Required audio processing features can be implemented through a combination of platform-native APIs, Rust DSP, and external audio processing libraries. + +- Priority: P0 +- Verification: Review + +**SysRS-221**: Mobile foreground voice behavior is sufficient for MVP. + +- Priority: P0 +- Verification: Review + +**SysRS-222**: Background voice behavior will remain constrained by iOS and Android platform policies. + +- Priority: P0 +- Verification: Review + +**SysRS-223**: External compatible server administrators are responsible for server availability, permissions, and configuration. + +- Priority: P0 +- Verification: Review + +**SysRS-224**: End users are responsible for providing valid server connection details and network access. + +- Priority: P0 +- Verification: Review + + +## 23. Out of Scope for MVP + + +**SysRS-225**: The MVP shall not include TeamSpeak-compatible server hosting functionality. + +- Priority: P0 +- Verification: Review + +**SysRS-226**: The MVP shall not include full server administration functionality. + +- Priority: P0 +- Verification: Review + +**SysRS-227**: The MVP shall not include a complete permission editor. + +- Priority: P0 +- Verification: Review + +**SysRS-228**: The MVP shall not include a plugin system. + +- Priority: P0 +- Verification: Review + +**SysRS-229**: The MVP shall not include 3D positional audio unless explicitly reprioritized. + +- Priority: P1 +- Verification: Review + +**SysRS-230**: The MVP shall not include advanced whisper list management unless explicitly reprioritized. + +- Priority: P1 +- Verification: Review + +**SysRS-231**: The MVP shall not include Server Query administration tools. + +- Priority: P0 +- Verification: Review + +**SysRS-232**: The MVP shall not include automatic cloud sync of bookmarks, identities, settings, or diagnostics. + +- Priority: P1 +- Verification: Review + + +## 24. Verification and Validation Requirements + + +**SysRS-233**: The project shall maintain a requirements traceability matrix from SysRS requirements through SysDes, SRS, SAD, SDD, and Verification evidence. + +- Priority: P1 +- Verification: Review + +**SysRS-234**: The project shall verify protocol compatibility through a protocol probe tool. + +- Priority: P0 +- Verification: Demo + +**SysRS-235**: The project shall verify state synchronization through reducer tests and event replay tests. + +- Priority: P1 +- Verification: Test + +**SysRS-236**: The project shall verify audio capture, processing, encode/decode, and playback through audio loopback and processing tests. + +- Priority: P1 +- Verification: Test + +**SysRS-237**: The project shall verify secure storage behavior on every target platform before public release. + +- Priority: P1 +- Verification: Audit + +**SysRS-238**: The project shall verify diagnostic redaction before enabling diagnostic export for external testers. + +- Priority: P1 +- Verification: Audit + +**SysRS-239**: The project shall verify release packaging on every target platform before production release. + +- Priority: P1 +- Verification: Demo + +**SysRS-240**: The project shall verify that public wording does not imply official TeamSpeak affiliation. + +- Priority: P0 +- Verification: Audit + + +## 25. MVP Acceptance Requirements + + +**SysRS-241**: The MVP shall connect to a TeamSpeak 3-compatible server using `tsclientlib`. + +- Priority: P0 +- Verification: Demo + +**SysRS-242**: The MVP shall display the server channel tree. + +- Priority: P0 +- Verification: Demo + +**SysRS-243**: The MVP shall display online clients. + +- Priority: P0 +- Verification: Demo + +**SysRS-244**: The MVP shall allow the user to join a voice channel. + +- Priority: P0 +- Verification: Demo + +**SysRS-245**: The MVP shall send voice. + +- Priority: P0 +- Verification: Demo + +**SysRS-246**: The MVP shall receive voice. + +- Priority: P0 +- Verification: Demo + +**SysRS-247**: The MVP shall support microphone mute. + +- Priority: P0 +- Verification: Demo + +**SysRS-248**: The MVP shall support output deaf. + +- Priority: P0 +- Verification: Demo + +**SysRS-249**: The MVP shall support push-to-talk. + +- Priority: P0 +- Verification: Demo + +**SysRS-250**: The MVP shall support Echo Canceller. + +- Priority: P0 +- Verification: Demo + +**SysRS-251**: The MVP shall support Automatic Gain Control. + +- Priority: P0 +- Verification: Demo + +**SysRS-252**: The MVP shall support Noise Suppression. + +- Priority: P0 +- Verification: Demo + +**SysRS-253**: The MVP shall support High-Pass Filter. + +- Priority: P0 +- Verification: Demo + +**SysRS-254**: The MVP shall send and receive channel text messages. + +- Priority: P0 +- Verification: Demo + +**SysRS-255**: The MVP shall save and reuse server bookmarks. + +- Priority: P0 +- Verification: Demo + +**SysRS-256**: The MVP shall use secure storage for sensitive data. + +- Priority: P0 +- Verification: Audit + +**SysRS-257**: The MVP shall export redacted diagnostic logs. + +- Priority: P1 +- Verification: Demo + + +--- + +## 30. UI/UX, Material 3, Platform, and Internationalization Requirements + +This section extends the system requirement baseline for the Chanora application system. These requirements are system-level because they define externally observable application behavior, accessibility behavior, platform behavior, multilingual behavior, deployment-region behavior, and interoperability constraints. + +**SysRS-258**: The Chanora application system shall use Material 3 as the baseline design system for the Flutter client user interface. + +- Priority: P0 +- Verification: Review, Inspection + +**SysRS-259**: The Chanora application system shall define a Chanora-specific design system above Material 3 for voice, connection, channel, latency, diagnostics, accessibility, and platform-adaptive states. + +- Priority: P0 +- Verification: Review, Inspection + +**SysRS-260**: The Chanora application system shall support compact, medium, and expanded window classes for responsive client layout. + +- Priority: P0 +- Verification: Test, Demo + +**SysRS-261**: The Chanora application system shall preserve visibility of connection status and primary voice controls across compact, medium, and expanded layouts. + +- Priority: P0 +- Verification: Test, Demo + +**SysRS-262**: The Chanora application system shall provide screen-reader semantics for critical interactive controls and critical status indicators. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-263**: The Chanora application system shall not communicate critical connection, voice, latency, permission, or error states by color alone. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-264**: The Chanora application system shall support keyboard focus traversal and visible focus indication on desktop-class and tablet keyboard environments. + +- Priority: P1 +- Verification: Test + +**SysRS-265**: The Chanora application system shall keep critical controls reachable when the user increases text size using platform accessibility settings. + +- Priority: P0 +- Verification: Test + +**SysRS-266**: The Chanora application system shall respect platform safe areas, display cutouts, system bars, virtual keyboards, and desktop window insets. + +- Priority: P0 +- Verification: Test + +**SysRS-267**: The Chanora application system shall provide platform-appropriate handling for Android system back navigation, including predictive-back-compatible behavior where supported by the platform. + +- Priority: P1 +- Verification: Test + +**SysRS-268**: The Chanora application system shall provide platform-appropriate handling for iOS navigation gestures, safe areas, keyboard avoidance, haptics, and system permission presentation. + +- Priority: P1 +- Verification: Test + +**SysRS-269**: The Chanora application system shall support localization of user-visible client application strings. + +- Priority: P0 +- Verification: Inspection, Test + +**SysRS-270**: The Chanora application system shall externalize user-visible strings from source code into localization resources or an equivalent localization mechanism. + +- Priority: P0 +- Verification: Inspection + +**SysRS-271**: The Chanora application system shall support English as the baseline product language. + +- Priority: P0 +- Verification: Review, Test + +**SysRS-272**: The Chanora application system shall support adding additional product languages without changing protocol, audio, state synchronization, or storage architecture. + +- Priority: P1 +- Verification: Review, Inspection + +**SysRS-273**: The Chanora application system shall preserve and display Unicode server names, channel names, client nicknames, and text messages received from compatible servers. + +- Priority: P0 +- Verification: Test + +**SysRS-274**: The Chanora application system shall use UTF-8 internally for text exchanged between Flutter, Rust Core, local storage, diagnostics, and protocol-facing adapters unless a platform API requires conversion at the boundary. + +- Priority: P0 +- Verification: Inspection, Test + +**SysRS-275**: The Chanora application system shall perform encoding conversion at explicit boundary adapters when external server, operating system, or platform APIs use a different text representation. + +- Priority: P1 +- Verification: Inspection, Test + +**SysRS-276**: The Chanora application system shall not corrupt or drop multilingual Unicode content in logs or diagnostic exports, except where redaction intentionally removes sensitive content. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-277**: The Chanora application system shall support bidirectional text display for user-visible localized strings and server-provided text where the platform text engine supports it. + +- Priority: P2 +- Verification: Test + +**SysRS-278**: The Chanora application system shall support locale-aware formatting for dates, times, numbers, and diagnostic timestamps where those values are user-visible. + +- Priority: P1 +- Verification: Test + +**SysRS-279**: The Chanora application system shall support fallback behavior when a translation key is missing. + +- Priority: P0 +- Verification: Test + +**SysRS-280**: The Chanora application system shall keep machine-readable diagnostic fields stable and language-neutral while allowing user-facing diagnostic descriptions to be localized. + +- Priority: P1 +- Verification: Inspection, Test + +**SysRS-281**: The Chanora application system shall separate product localization from server-provided content; server-provided names and messages shall be displayed as content, not translated by the client. + +- Priority: P0 +- Verification: Review, Test + +**SysRS-282**: The Chanora application system shall support accessibility labels and localization for icon-only controls. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-283**: The Chanora application system shall define a UI/UX guideline document as a downstream non-normative design baseline derived from this SysRS and SysDes. + +- Priority: P1 +- Verification: Review + +**SysRS-284**: The Chanora application system shall define design tokens for color, typography, spacing, shape, elevation, motion, density, connection state, voice state, latency state, and diagnostics state. + +- Priority: P1 +- Verification: Review, Inspection + +**SysRS-285**: The Chanora application system shall maintain traceability across the hierarchy `SysRS -> SysDes -> SRS -> SAD -> SDD` without allowing SRS, SAD, or SDD to bypass the immediately preceding lifecycle layer. + +- Priority: P0 +- Verification: Review, Inspection + + +## 26. Glossary + +| Term | Definition | +|---|---| +| Chanora | Cross-platform voice client application | +| Application system | The Chanora application plus runtime environment elements required for operation | +| Client device | User device running the Chanora application | +| Runtime environment | OS services, hardware, network, and external dependencies used by the application | +| External compatible server | TeamSpeak 3-compatible voice server not operated by Chanora | +| `tsclientlib` | Rust protocol library used for TeamSpeak-compatible protocol integration | +| Rust Core | Shared Rust layer for protocol, state, audio, storage, diagnostics, and business logic | +| Flutter UI | Cross-platform UI layer | +| Platform adapter | OS-specific integration layer for audio, permissions, secure storage, lifecycle, and packaging | +| Echo Canceller | Audio processing feature that reduces playback audio leaking into microphone input | +| Automatic Gain Control | Audio processing feature that normalizes microphone input gain | +| Noise Suppression | Audio processing feature that reduces background noise | +| High-Pass Filter | Audio processing feature that reduces low-frequency noise | + +--- + +## 27. SysRS Coverage Matrix + +| SysRS Area | Requirement Coverage | +|---|---| +| Product and application-system scope | SysRS-001 through SysRS-010 | +| Stakeholder and user environment | SysRS-011 through SysRS-015 | +| System boundary and external dependencies | SysRS-016 through SysRS-023 | +| Application components | SysRS-024 through SysRS-034 | +| Client device and hardware environment | SysRS-035 through SysRS-047 | +| Operating system services | SysRS-048 through SysRS-058 | +| Audio hardware and audio processing | SysRS-059 through SysRS-074 | +| Network environment | SysRS-075 through SysRS-087 | +| External compatible servers | SysRS-088 through SysRS-101 | +| Application functional behavior | SysRS-102 through SysRS-120 | +| Protocol integration | SysRS-121 through SysRS-128 | +| State synchronization | SysRS-129 through SysRS-139 | +| Data and storage | SysRS-140 through SysRS-152 | +| Security and privacy | SysRS-153 through SysRS-167 | +| Diagnostics and operations | SysRS-168 through SysRS-177 | +| Non-functional requirements | SysRS-178 through SysRS-191 | +| Deployment and release environment | SysRS-192 through SysRS-199 | +| Interfaces | SysRS-200 through SysRS-210 | +| Constraints | SysRS-211 through SysRS-218 | +| Assumptions | SysRS-219 through SysRS-224 | +| Out of scope for MVP | SysRS-225 through SysRS-232 | +| Verification and validation | SysRS-233 through SysRS-240 | +| MVP acceptance requirements | SysRS-241 through SysRS-257 | +| UI/UX, Material 3, platform, i18n, and strict traceability | SysRS-258 through SysRS-285 | + + +--- + +## 28. Open Decisions + +| Decision ID | Area | Question | Default Recommendation | +|---|---|---|---| +| SysRS-DEC-001 | Mobile | Minimum supported iOS version | Decide before iOS implementation | +| SysRS-DEC-002 | Mobile | Minimum supported Android version | Decide before Android implementation | +| SysRS-DEC-003 | Connection | Multiple simultaneous server connections in MVP | Defer unless required | +| SysRS-DEC-004 | Audio | Default Echo Canceller state per platform | Enable only after validation | +| SysRS-DEC-005 | Audio | Default AGC state per platform | Enable with conservative settings | +| SysRS-DEC-006 | Audio | Default Noise Suppression state per platform | Enable if quality is acceptable | +| SysRS-DEC-007 | Audio | Default High-Pass Filter cutoff frequency | 80 Hz initial default | +| SysRS-DEC-008 | Audio | Platform-native vs Rust audio processing per platform | Prefer best quality and lowest latency | +| SysRS-DEC-009 | Legal | Official SDK licensing review before public distribution | Recommended | +| SysRS-DEC-010 | Storage | Embedded database choice | SQLite or equivalent | +| SysRS-DEC-011 | Bridge | Rust/Flutter bridge choice | `flutter_rust_bridge` initially | + +--- + +## 29. Revision History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-13 | Initial application-system requirements draft | +| 0.2.0 | 2026-05-13 | Converted software-only direction into application-system SysRS | +| 0.3.0 | 2026-05-13 | Corrected terminology: Chanora is an application; SysRS covers the application system and runtime environment | +| 0.4.0 | 2026-05-13 | Removed old SYS requirement references and standardized requirement IDs as SysRS-XXX | +| 0.5.0 | 2026-05-13 | Moved implementation and design documents out of input references into downstream non-normative documents | +| 0.6.0 | 2026-05-13 | Corrected downstream documentation lifecycle to SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification | +| 0.7.0 | 2026-05-14 | Added Material 3, adaptive UI, accessibility, platform behavior, internationalization, Unicode, and strict lifecycle traceability requirements | + +--- + +## 31. Platform Baseline, Release Policy, and Architecture Decision Requirements + +This section converts the baseline product decisions into auditable system-level requirements. + +**SysRS-286**: The Chanora application system shall support iOS runtime deployment on iOS 13 or later unless Flutter, plugin, audio, or platform constraints require raising the minimum version. + +- Priority: P0 +- Verification: Review, Platform Test + +**SysRS-287**: For Apple App Store Connect upload on or after 2026-04-28, the Chanora iOS/iPadOS build shall be produced with Xcode 26 or later using the iOS 26 / iPadOS 26 SDK or later, unless Apple publishes a newer applicable upload requirement before upload. + +- Priority: P0 +- Verification: Release Inspection + +**SysRS-288**: The Chanora Android application shall support Android API 28 (Android 9.0) or later as the minimum runtime baseline, per DEC-004 (Accepted 2026-05-14, which raised the original API 24 recommendation to API 28). The minimum may be raised further only if Flutter, plugin, audio, or platform constraints require it; it shall not be lowered without a superseding accepted decision. + +- Priority: P0 +- Verification: Review, Platform Test + +**SysRS-289**: For Google Play submission, the Chanora Android build shall target the Android API level required by Google Play on the upload date. + +- Priority: P0 +- Verification: Release Inspection + +**SysRS-290**: The Chanora MVP shall support one active server connection per client instance; multiple simultaneous active server connections shall be deferred outside MVP scope. + +- Priority: P0 +- Verification: Review, System Test + +**SysRS-291**: The Chanora MVP shall enable Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter by default where supported and stable, while allowing user or platform policy to disable supported processing where applicable. + +- Priority: P0 +- Verification: Audio Test, Review + +**SysRS-292**: The Chanora application system shall prefer platform-native audio processing for MVP where available and stable, with Rust/WebRTC-style audio processing retained as a controlled fallback or later architecture option. + +- Priority: P1 +- Verification: Architecture Review, Audio Test + +**SysRS-293**: The Chanora application system shall use SQLite or an equivalent embedded local database for non-secret local state, while storing secrets only through platform secure storage. + +- Priority: P0 +- Verification: Storage Test, Security Audit + +**SysRS-294**: The Chanora application system shall use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs; `flutter_rust_bridge` is the default candidate unless prototype evidence selects a better option. + +- Priority: P0 +- Verification: Architecture Review, Integration Test + +**SysRS-295**: The Chanora MVP shall not perform automatic diagnostic upload, automatic telemetry upload, or automatic crash reporting unless a later approved decision updates privacy, security, legal, release, and verification documents. + +- Priority: P0 +- Verification: Privacy Review, Security Audit + +**SysRS-296**: The Chanora desktop application shall support **Focused Push-to-Talk** on Windows, macOS, and Linux. Focused PTT is the minimum required behaviour: the user shall be able to hold a bound input (keyboard key, mouse button) inside the focused Chanora window to enable voice transmission, and release of that input shall disable voice transmission. + +- Priority: P0 +- Verification: Platform Test, User Acceptance Test + +**SysRS-297**: The Chanora desktop application shall additionally support **Global Push-to-Talk** where the operating system, the user-granted permission set, the display server, and the available input backend together permit it. Where global PTT is not available, the application shall fall back to Focused PTT without claiming Global PTT support. + +- Priority: P0 +- Verification: Platform Test, Architecture Review + +**SysRS-298**: The detected desktop PTT capability level shall be exposed to the user interface and to the release verification record. The exposed value shall match the actual runtime capability — the application shall not advertise a Global PTT level when the active backend is the Focused fallback. + +- Priority: P0 +- Verification: Integration Test, Release Inspection + +**SysRS-299**: The Chanora Windows desktop application shall prefer the Raw Input backend for Global PTT, with a low-level keyboard hook used only as a fallback when Raw Input is unavailable, and Focused PTT used as the final fallback when no Global PTT backend can be initialised. + +- Priority: P0 +- Verification: Platform Test (Windows), Architecture Review + +**SysRS-300**: The Chanora macOS desktop application shall request the operating-system permission required for Global PTT (Input Monitoring / Accessibility), use the permission-aware Global PTT backend when the permission is granted, and fall back to Focused PTT when the permission is denied, revoked, or not yet decided. The application shall not block voice functionality while the user decides on the permission prompt. + +- Priority: P0 +- Verification: Platform Test (macOS), User Acceptance Test + +**SysRS-301**: The Chanora Linux desktop application shall use a capability-dependent Global PTT backend selected from the available display server (X11 or Wayland) and compositor support (GNOME on Wayland is the officially-tested target for the first public release per DEC-026; other compositors fall back to Focused PTT). The application shall not claim Global PTT support on an untested Linux environment. + +- Priority: P0 +- Verification: Platform Test (Linux, GNOME Wayland), Architecture Review + +**SysRS-302**: The Chanora application system shall not log, store, persist, or include in the user-initiated diagnostic export any raw desktop key-event history, key code stream, or key-press timing sequence. Diagnostic export may include the detected PTT capability level, the active backend identifier, and the bound input class (for example "keyboard", "mouse-side-button"), but shall not include the specific key code, scan code, or virtual-key value of any user binding. + +- Priority: P0 +- Verification: Privacy Review, Security Audit, Diagnostic Inspection + +**SysRS-303**: The Chanora application system shall define the v1 voice transmit mode set as `Ptt` and `Continuous`, with `VoiceActivity` reserved on the enum surface but unimplemented in this baseline (deferred per DEC-030). The default mode on a fresh install shall be `Ptt`; the user-selected mode shall be persisted per identity. The audio engine lifecycle shall be bound to voice-channel membership: input and output streams shall open on the user's first voice-channel join of the session and shall close on the last voice-channel leave, with no manual start affordance exposed at any system interface. The output stream shall open regardless of microphone-permission state so listen-only is a first-class flow. A user-facing hard-mute toggle shall force the transmit gate closed and shall override the active transmit mode, the PTT key state, and every other internal signal. + +- Priority: P0 +- Verification: Functional Test, UX Review + +**SysRS-304**: The Chanora application system shall apply a configurable PTT release-tail interval between the moment the bound PTT input reports key-up and the moment the transmit gate closes, so that the trailing syllable of a spoken word is not clipped at word boundaries. The default release-tail value shall be 200 ms (matching the TeamSpeak / Mumble default); the user-configurable range shall be 0 ms through 500 ms inclusive. The release tail shall not affect the input-stream capture lifecycle; it shall affect only the transmit gate. + +- Priority: P0 +- Verification: Functional Test, UX Review + +**SysRS-305**: When the Chanora Android application has an active voice session connected, the system shall engage the Android in-call audio mode (for example via `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The in-call mode shall be entered no later than the moment the voice session becomes connected and shall be released when the last active voice session ends. Back-fills the v0.9.8 product-decision-register entry that recorded `AudioManager.setMode(MODE_IN_COMMUNICATION)` engagement via JNI without prior SysRS coverage. + +- Priority: P0 +- Verification: Platform Test (Android), Audio Test + +**SysRS-306**: The Chanora Android application shall acquire the Android runtime microphone permission (`RECORD_AUDIO`) at or before the point of voice session activation, and shall not begin microphone capture without that permission having been granted by the user. If the permission is denied, revoked, or not yet decided, the application shall remain functional in listen-only mode (consistent with SysRS-303) and shall surface a user-facing path to grant the permission before retrying transmit. This requirement is additive to the general permission obligation in SysRS-055 and makes the runtime-acquisition timing explicit. + +- Priority: P0 +- Verification: Platform Test (Android), Functional Test + +**SysRS-307**: The Chanora project shall maintain measured numeric performance baselines for the realtime audio capture and playback paths. The baseline set shall include, at minimum: (i) heap allocation count per realtime audio callback measured after warmup, (ii) per-callback wall-clock time expressed as a fraction of (or absolute bound relative to) the audio frame period, (iii) Opus encode latency and Opus decode latency per frame, and (iv) resampler throughput at the common rate-pair conversions exercised by the audio pipeline. Each baseline shall be expressed as a numeric threshold (or numeric range), not as free-form prose, so that regression against the baseline is deterministically detectable by automated comparison. This requirement extends the prescriptive intent of SysRS-180 ("shall minimize local audio pipeline latency") and the directional target of SysRS-181 ("should target local audio pipeline latency under 100 ms") into a measurable, contract-grade obligation, and it is consistent with the underrun-avoidance obligation in SysRS-186. The specific baseline values, the warmup definition, the rate-pair set, and the storage format for the baselines are SysDes/SAD/SDD concerns and are not authored here. This clause does not authorize automatic upload, transmission, or off-device export of any measured baseline data and is therefore consistent with SysRS-295 (no automatic telemetry / diagnostic upload in MVP). + +- Priority: P0 +- Verification: Test (SWE.4 benchmark assertions, delegated to verification layer; cross-references SysRS-236) + +**SysRS-308**: The Chanora project's continuous-integration workflow shall execute the realtime-audio benchmark suite on every pull request against the default branch and on every merge to the default branch, on at least one host architecture (Linux x86_64 on the existing GitHub Actions runner is sufficient to satisfy this clause), and shall report the comparison of the executed run against the maintained baselines (SysRS-307) in the pull request's status-check surface such that human reviewers can see, before approving the change, whether any baseline has regressed beyond the declared tolerance window (SysRS-309). The CI regression check authorized by this clause is **advisory only**: it shall NOT fail the CI build, shall NOT block merge, and shall NOT be treated as a hard quality gate at the P0-MVP stage. Its purpose is to surface evidence for human reviewer judgement and to avoid the failure mode in which a strict build-failing gate is bypassed under release-crunch pressure (e.g., "skip CI"). Escalation of this advisory tier to a build-failing hard gate is explicitly out of scope of SysRS-308 and shall be authorized only by a separate, later SysRS clause after a period of baseline maturity sufficient to establish that the advisory signal is stable and low-noise (indicative target: 4–6 weeks of clean baseline data on the default branch, but the actual escalation criteria are to be set by the future clause). This requirement is consistent with the CI-as-quality-evidence pattern established by the SysRS-234..239 verification family and does not displace any obligation in that family. This clause does not authorize off-device transmission of baseline measurements beyond the project's existing CI provider surface (i.e., GitHub Actions logs and PR status checks visible to repository collaborators); it is therefore consistent with SysRS-295. + +- Priority: P0 +- Verification: Demo (CI workflow exercised on a representative PR; advisory status check appears and does not block merge on regression) + +**SysRS-309**: The advisory CI regression comparison authorized by SysRS-308 shall use an explicitly declared tolerance window — a numeric percentage (or a numeric per-metric percentage set) above the maintained baseline (SysRS-307) — beyond which the advisory check shall mark the run as a regression. The tolerance shall be a single declared value (or one declared value per metric), not an ad-hoc reviewer judgement, so that the advisory signal is reproducible. The specific numeric value(s) of the tolerance window and the comparison methodology (for example, "comparison against the most recent baseline snapshot on the default branch") shall be authored at the SysDes layer and may be refined at SAD/SDD; a suggested starting value of +20% over baseline is recorded here for downstream traceability but is not binding at the SysRS layer. Cross-references: SysRS-307 (the baselines being compared against), SysRS-308 (the advisory CI surface in which the comparison runs), SysRS-180/SysRS-181 (latency intent the tolerance must not silently erode), SysRS-295 (the tolerance window value is a project-local configuration and does not authorize off-device telemetry). + +- Priority: P0 +- Verification: Review (SysDes/SAD declaration of tolerance value is present and is referenced by the CI workflow definition) + +**SysRS-310**: The Chanora application system shall support macOS runtime deployment on macOS 10.15 (Catalina) or later as the minimum supported runtime, unless Flutter, plugin, audio, or platform constraints require raising the minimum version. This clause ratifies at the SysRS layer the existing macOS baseline already encoded in `apps/chanora_flutter/macos/chanora_bridge.podspec` (`MACOSX_DEPLOYMENT_TARGET = 10.15`) and provides explicit cross-platform-baseline coverage parallel to SysRS-286 (iOS) and SysRS-288 (Android). Rationale: macOS 10.15 is the floor that supports the modern CoreAudio / AVAudioEngine voice-processing-IO surfaces relied on by the realtime audio path, native arm64 Apple Silicon builds (no Rosetta dependence), and the SDK version used by the existing podspec lipo step that produces the universal binary; a lower minimum would require backporting audio code paths or shipping a non-universal build, neither of which is in P0-MVP scope. The minimum may be raised further (for example, to macOS 11.0 / Big Sur for native Apple Silicon performance gains) only via a superseding accepted decision recorded as a DEC entry; it shall not be lowered without a superseding accepted decision. Cross-references: SAD-087 (architectural macOS runtime allocation), SDD-119 (macOS bridge build pipeline consuming this baseline), SysRS-286 (iOS minimum runtime parallel), SysRS-288 (Android minimum runtime parallel). ID-allocation note: this clause uses SysRS-310 rather than the structurally parallel SysRS-290 because SysRS-290 is already allocated (MVP single-active-server-connection scope); monotonic numbering convention is preserved. + +- Priority: P0 +- Verification: Review (the SysRS baseline matches the podspec `MACOSX_DEPLOYMENT_TARGET` setting), Platform Test (the produced macOS binary runs on a macOS 10.15 system) + + +## 32. Change History Addendum + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Added platform runtime baselines, Apple SDK submission gate, Android Play target gate, MVP connection scope, audio defaults, audio implementation path, local database, bridge, and diagnostics/crash reporting policy requirements. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date to 2026-04-28 and propagated distinction between runtime deployment target and build-SDK upload gate. | + +## Baseline Candidate 0.9.3 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.3 | 2026-05-15 | Added desktop Push-to-Talk requirements SysRS-296 through SysRS-302: mandatory Focused PTT on Windows/macOS/Linux, capability-dependent Global PTT, capability-level exposure to UI and release record, Windows Raw Input + low-level-hook + Focused fallback ladder, macOS permission-aware Global PTT, Linux capability-dependent Global PTT (GNOME on Wayland officially-tested per DEC-026), and the privacy rule prohibiting raw key-event history in logs and diagnostic exports. Owner-resolved gen2 review questions PTT-OPEN-001..006 land as DEC-023..028 in the product decision register. | + + +## Baseline Candidate 0.9.5 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle requirements SysRS-303 and SysRS-304 capturing the no-manual-start audio engine bound to voice-channel membership, the v1 transmit-mode set (`Ptt` default + `Continuous`, with `VoiceActivity` reserved per DEC-030), the listen-only flow (output independent of mic permission), the hard-mute override, and the 200 ms (0–500 ms) PTT release tail for word-boundary anti-clipping. | + + +## Baseline Candidate 0.9.9 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.9 | 2026-05-17 | Reconciled SysRS-288 with DEC-004 (Accepted 2026-05-14): Android minimum runtime baseline raised from API 24 to API 28 (Android 9.0); rationale and decision citation added in-line. Verified SysRS-055, SysRS-161, SysRS-195, SysRS-217, and SysRS-289 remain consistent with DEC-004 (no API-level text in any of these; no rewrite required). Added SysRS-305 (Android in-call audio mode engagement during active voice session — back-fills the v0.9.8 product-decision-register `AudioManager.setMode(MODE_IN_COMMUNICATION)` entry) and SysRS-306 (explicit Android runtime microphone permission acquisition at or before voice session activation, additive to SysRS-055). | + + +## Baseline Candidate 0.9.10 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.11 | 2026-05-18 | Closed the Wave 1.5 traceability-audit deferred-but-optional follow-up by adding SysRS-310 (macOS minimum runtime baseline at macOS 10.15 / Catalina), ratifying at SysRS layer the existing `apps/chanora_flutter/macos/chanora_bridge.podspec` `MACOSX_DEPLOYMENT_TARGET = 10.15` setting and providing explicit cross-platform-baseline coverage parallel to SysRS-286 (iOS) and SysRS-288 (Android). Allocated SysRS-310 rather than SysRS-290 because SysRS-290 is already taken (MVP single-active-server-connection scope); monotonic numbering convention preserved. No change to the numeric baseline value; any future raise (e.g., to macOS 11.0 / Big Sur for native Apple Silicon performance gains) is flagged as a DEC-level change, not authored here. | +| 0.9.10 | 2026-05-18 | Authorized Option B of the benchmark-infrastructure decision for the realtime audio path. Added SysRS-307 (maintained numeric performance baselines for the realtime audio capture and playback paths — heap allocation count per callback after warmup, per-callback wall-clock budget relative to the audio frame period, Opus encode/decode latency, and resampler throughput at common rate-pair conversions; extends SysRS-180/SysRS-181 from prescriptive intent into a measurable contract; consistent with SysRS-186 and SysRS-236). Added SysRS-308 (advisory CI regression reporting executing the benchmark suite on every PR and every merge to the default branch on at least one host architecture, surfacing results in the PR status-check view; explicitly **advisory only** — does not fail the build, does not block merge; escalation to a build-failing hard gate is out of scope and deferred to a future SysRS clause after baseline maturity; consistent with the SysRS-234..239 verification-family pattern). Added SysRS-309 (explicitly declared numeric tolerance window for the advisory comparison; numeric value(s) and comparison methodology delegated to SysDes/SAD; suggested starting value +20% recorded as non-binding downstream guidance). All three new clauses are consistent with SysRS-295 (no automatic telemetry / diagnostic upload in MVP) — they neither authorize nor require off-device transmission of measurement data beyond the existing CI provider surface visible to repository collaborators. Explicitly **NOT** authored in this update: (a) Dimension 3 production telemetry export of timing histograms (deferred to P1; any future opt-in performance-evidence export through the user-initiated diagnostic-export path requires a separate P1 SysRS clause and must be reconciled with SysRS-295 at that time); (b) build-failing hard CI gate (deferred to a future SysRS clause). | diff --git a/justfile b/justfile index c42c0a6..211b229 100644 --- a/justfile +++ b/justfile @@ -2,9 +2,7 @@ # # Conforms to docs/governance/repository-bootstrap-plan.md v0.1.0 §3, # which requires a `justfile` with stubs for format / lint / test / -# verify-docs / security-scan. The repository is documentation- and -# PoC-first; until the product Flutter/Rust workspace exists, most -# targets are placeholders. +# verify-docs / security-scan. # # Install just: https://github.com/casey/just @@ -25,16 +23,10 @@ verify-docs: # Format every codebase in the repo that has a formatter wired up. format: - @echo "[format] Rust PoCs" - @for d in poc/*/; do \ - if [ -f "$$d/Cargo.toml" ]; then \ - (cd "$$d" && cargo fmt --all) || exit 1; \ - fi; \ - done - @if [ -d poc/flutter_rust_bridge_hello ]; then \ - echo "[format] Flutter PoC"; \ - (cd poc/flutter_rust_bridge_hello && dart format lib test integration_test rust/src) || exit 1; \ - fi + @echo "[format] Rust workspace" + cargo fmt --package chanora_audio --package chanora_bridge --package chanora_core --package chanora_diagnostics --package chanora_protocol --package chanora_state --package chanora_storage + @echo "[format] Flutter app" + cd apps/chanora_flutter && dart format lib test # --------------------------------------------------------------------------- # Lint @@ -42,38 +34,30 @@ format: # Run linters on every codebase that has them wired up. lint: - @echo "[lint] Rust PoCs" - @for d in poc/*/; do \ - if [ -f "$$d/Cargo.toml" ]; then \ - (cd "$$d" && cargo clippy --all-targets -- -D warnings) || exit 1; \ - fi; \ - done - @if [ -d poc/flutter_rust_bridge_hello ]; then \ - echo "[lint] Flutter PoC"; \ - (cd poc/flutter_rust_bridge_hello && flutter analyze) || exit 1; \ - fi + @echo "[lint] Rust workspace" + cargo clippy --workspace --all-targets --all-features -- -W clippy::all + @echo "[lint] Flutter app" + cd apps/chanora_flutter && flutter analyze # --------------------------------------------------------------------------- # Test # --------------------------------------------------------------------------- -# Run all PoC test suites that have one. +# Run local test suites. Live/network tests remain explicitly ignored. test: - @echo "[test] tsclientlib-connect-spike: build only (live-server smoke must be run manually)" - @(cd poc/tsclientlib-connect-spike && cargo build --release) - @echo "[test] flutter_rust_bridge_hello: headless verification" - @(cd poc/flutter_rust_bridge_hello && \ - flutter build linux --debug && \ - LD_LIBRARY_PATH="$$PWD/build/linux/x64/debug/bundle/lib:$$LD_LIBRARY_PATH" \ - flutter test test/poc_verification_test.dart) + @echo "[test] Rust workspace" + cargo test --workspace --all-targets --all-features + @echo "[test] Flutter app" + cd apps/chanora_flutter && flutter test # --------------------------------------------------------------------------- # Security scan # --------------------------------------------------------------------------- -# Placeholder — real security scanning will be wired up when the product -# workspace exists. See docs/security/dependency-and-supply-chain-report.md -# and docs/governance/repository-bootstrap-plan.md §5. +# Run the local dependency audit when cargo-audit is installed. security-scan: - @echo "[security-scan] placeholder — no product workspace yet." - @echo "[security-scan] documentation gates live under docs/security/" + @if command -v cargo-audit >/dev/null 2>&1; then \ + cargo audit; \ + else \ + echo "[security-scan] cargo-audit not installed; run: cargo install cargo-audit"; \ + fi