Files

T

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Six fixes from independent PR review:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

215 KiB

Raw Permalink Blame History

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

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:

SysRS-XXX -> SysDes-YYY -> SRS-ZZZ

Incorrect downstream traceability:

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

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

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

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 (call-scoped VoIP activation with `.mixWithOthers`, idle `.ambient` baseline), 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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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-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:

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 VoiceActivity. VoiceActivity shall be surfaced only when the current platform has an allocated, implemented, and verified VAD capture path in this baseline (currently Windows/Linux desktop); mobile, macOS, and unverified-platform enablement remain deferred per DEC-030. The active mode shall be persisted in the identity store where the selected platform supports it; unsupported platforms shall surface VoiceActivity as disabled/unavailable rather than claiming runtime support.

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/<FrameworkName>) 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` / platform-scoped `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.

215 KiB Raw Permalink Blame History Unescape Escape