From f1bc9a6c8574586ad0509d107fc4ae8dd6ef91c7 Mon Sep 17 00:00:00 2001 From: EdisonJwa Date: Thu, 14 May 2026 12:25:33 +0800 Subject: [PATCH] chore(repo): initial baseline import (docs v0.9.2 + bootstrap) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Imports the v0.9.2 documentation baseline and the bootstrap files required by docs/governance/repository-bootstrap-plan.md v0.1.0 §3, minus the justfile (added in the next commit). This commit establishes the git history for the project. All previous work lived only as filesystem state with no version control. --- .editorconfig | 18 + .env.example | 12 + .gitignore | 83 + CHANGELOG.md | 28 + CONTRIBUTING.md | 64 + LICENSE | 9 + NOTICE | 10 + README.md | 384 +++ SECURITY.md | 51 + docs/architecture/proof-of-concept-plan.md | 49 + docs/architecture/sad.md | 1296 ++++++++ docs/architecture/sdd.md | 1027 ++++++ docs/architecture/sysdes.md | 2792 +++++++++++++++++ docs/governance/baseline-approval-record.md | 65 + .../baseline-candidate-validation-report.md | 73 + docs/governance/decision-impact-assessment.md | 79 + docs/governance/development-environment.md | 60 + docs/governance/document-index.md | 86 + docs/governance/document-naming-convention.md | 66 + docs/governance/document-review-report.md | 90 + .../git-commit-message-convention.md | 185 ++ docs/governance/path-migration-map.md | 60 + docs/governance/product-decision-register.md | 145 + .../repo-format-validation-report.md | 75 + docs/governance/repository-bootstrap-plan.md | 72 + docs/governance/traceability-matrix.md | 190 ++ docs/i18n/localization-architecture.md | 87 + .../legal/trademark-and-attribution-review.md | 107 + docs/privacy/privacy-policy.md | 108 + .../aspice-swe2-swe3-integration-note.md | 87 + docs/references/external-references.md | 112 + docs/release/platform-release-policy.md | 63 + docs/release/release-artifact-policy.md | 51 + .../release-readiness-go-nogo-record.md | 210 ++ docs/requirements/srs.md | 2528 +++++++++++++++ docs/requirements/sysrs.md | 1904 +++++++++++ .../dependency-and-supply-chain-report.md | 126 + .../diagnostic-redaction-audit-report.md | 103 + docs/security/secure-storage-audit-report.md | 88 + .../security-privacy-legal-guideline.md | 89 + docs/security/threat-model.md | 138 + docs/ui-ux/adaptive-layout-platform-guide.md | 84 + docs/ui-ux/material3-component-catalog.md | 105 + docs/ui-ux/material3-design-tokens.md | 120 + docs/ui-ux/material3-guideline.md | 93 + .../swe4-unit-verification-plan.md | 375 +++ ...-software-integration-verification-plan.md | 225 ++ .../swe6-software-verification-plan.md | 224 ++ ...s4-system-integration-verification-plan.md | 241 ++ docs/verification/verification-master-plan.md | 83 + tools/validate_docs.py | 90 + 51 files changed, 14510 insertions(+) create mode 100644 .editorconfig create mode 100644 .env.example create mode 100644 .gitignore create mode 100644 CHANGELOG.md create mode 100644 CONTRIBUTING.md create mode 100644 LICENSE create mode 100644 NOTICE create mode 100644 README.md create mode 100644 SECURITY.md create mode 100644 docs/architecture/proof-of-concept-plan.md create mode 100644 docs/architecture/sad.md create mode 100644 docs/architecture/sdd.md create mode 100644 docs/architecture/sysdes.md create mode 100644 docs/governance/baseline-approval-record.md create mode 100644 docs/governance/baseline-candidate-validation-report.md create mode 100644 docs/governance/decision-impact-assessment.md create mode 100644 docs/governance/development-environment.md create mode 100644 docs/governance/document-index.md create mode 100644 docs/governance/document-naming-convention.md create mode 100644 docs/governance/document-review-report.md create mode 100644 docs/governance/git-commit-message-convention.md create mode 100644 docs/governance/path-migration-map.md create mode 100644 docs/governance/product-decision-register.md create mode 100644 docs/governance/repo-format-validation-report.md create mode 100644 docs/governance/repository-bootstrap-plan.md create mode 100644 docs/governance/traceability-matrix.md create mode 100644 docs/i18n/localization-architecture.md create mode 100644 docs/legal/trademark-and-attribution-review.md create mode 100644 docs/privacy/privacy-policy.md create mode 100644 docs/references/aspice-swe2-swe3-integration-note.md create mode 100644 docs/references/external-references.md create mode 100644 docs/release/platform-release-policy.md create mode 100644 docs/release/release-artifact-policy.md create mode 100644 docs/release/release-readiness-go-nogo-record.md create mode 100644 docs/requirements/srs.md create mode 100644 docs/requirements/sysrs.md create mode 100644 docs/security/dependency-and-supply-chain-report.md create mode 100644 docs/security/diagnostic-redaction-audit-report.md create mode 100644 docs/security/secure-storage-audit-report.md create mode 100644 docs/security/security-privacy-legal-guideline.md create mode 100644 docs/security/threat-model.md create mode 100644 docs/ui-ux/adaptive-layout-platform-guide.md create mode 100644 docs/ui-ux/material3-component-catalog.md create mode 100644 docs/ui-ux/material3-design-tokens.md create mode 100644 docs/ui-ux/material3-guideline.md create mode 100644 docs/verification/swe4-unit-verification-plan.md create mode 100644 docs/verification/swe5-software-integration-verification-plan.md create mode 100644 docs/verification/swe6-software-verification-plan.md create mode 100644 docs/verification/sys4-system-integration-verification-plan.md create mode 100644 docs/verification/verification-master-plan.md create mode 100644 tools/validate_docs.py diff --git a/.editorconfig b/.editorconfig new file mode 100644 index 0000000..52c1b2f --- /dev/null +++ b/.editorconfig @@ -0,0 +1,18 @@ +root = true + +[*] +charset = utf-8 +end_of_line = lf +insert_final_newline = true +trim_trailing_whitespace = true +indent_style = space +indent_size = 2 + +[*.md] +trim_trailing_whitespace = false + +[*.{rs,toml}] +indent_size = 4 + +[Makefile] +indent_style = tab diff --git a/.env.example b/.env.example new file mode 100644 index 0000000..e0a06f3 --- /dev/null +++ b/.env.example @@ -0,0 +1,12 @@ +# Chanora local development environment example. +# Do not put real secrets in this file. + +CHANORA_ENV=development +CHANORA_LOG_LEVEL=debug + +# Optional local test server values. +# Never commit real server passwords. +CHANORA_TEST_SERVER_HOST= +CHANORA_TEST_SERVER_PORT= +CHANORA_TEST_SERVER_USERNAME= +CHANORA_TEST_SERVER_PASSWORD= diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..597b2e2 --- /dev/null +++ b/.gitignore @@ -0,0 +1,83 @@ +# OS files +.DS_Store +Thumbs.db + +# Editors +.vscode/ +.idea/ +*.swp +*.swo + +# Logs +*.log +logs/ + +# Environment / secrets +.env +.env.* +!.env.example +*.pem +*.key +*.p12 +*.mobileprovision +*.keystore +*.jks + +# Build output +build/ +dist/ +out/ +target/ +.dart_tool/ +.flutter-plugins +.flutter-plugins-dependencies +.packages +.pub-cache/ +.pub/ +ios/Pods/ +ios/.symlinks/ +android/.gradle/ +android/app/build/ + +# Generated reports +reports/ +coverage/ + +# Diagnostic bundles +diagnostics/ +*.diag.zip +*.diagnostic.zip + +# Local databases +*.sqlite +*.sqlite3 +*.db +*.db-shm +*.db-wal + +# Temporary files +tmp/ +temp/ +.cache/ + +# Upstream documentation snapshots (kept as reference, not project source) +chanora-docs-repo-format-*.zip + +# Cargo +**/Cargo.lock.bak + +# Flutter / Dart generated (but keep pubspec.lock for the PoC apps) +**/.dart_tool/ +**/.flutter-plugins +**/.flutter-plugins-dependencies +**/.packages +**/build/ +**/ephemeral/ +**/generated_plugin_registrant.* +**/GeneratedPluginRegistrant.* + +# FRB / cargokit local build dirs +**/cargokit_build/ + +# IntelliJ / Android Studio per-project +**/*.iml diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..b9bf472 --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1,28 @@ +# Changelog + +All notable changes to Chanora will be documented in this file. + +This project is expected to follow a Conventional Commits style workflow. + +## [Unreleased] + +### Added + +- Initial repository foundation files. +- Documentation-first project structure. + +### Changed + +- N/A + +### Fixed + +- N/A + +### Security + +- N/A + +## Versioning note + +The project implementation has not reached a public release version yet. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..c8aba9e --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,64 @@ +# Contributing to Chanora + +## Status + +Chanora is currently in early implementation preparation. Contributions should preserve the documentation hierarchy and product decisions. + +## Engineering hierarchy + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +Do not bypass layers: + +- SRS shall not link directly to SysRS. +- SAD shall not link directly to SysRS or SysDes. +- SDD shall not link directly to SysRS, SysDes, or SRS. + +## Before making a change + +1. Identify the affected area: requirements, architecture, design, verification, release, security, privacy, legal, UI/UX, i18n, or implementation. +2. Check the relevant document under `docs/`. +3. Update downstream documents if the change affects traceability. +4. Add or update verification expectations when behavior changes. +5. Use the commit message convention in `docs/governance/git-commit-message-convention.md`. + +## Commit format + +Use Conventional Commits style: + +```text +(): +``` + +Examples: + +```text +feat(voice): add push-to-talk state handling +fix(protocol): recover channel tree after reconnect snapshot +docs(sad): add interface catalog and performance view +sec(diagnostics): redact server password from export bundle +``` + +## Pull request expectations + +A pull request should include: + +- summary of change; +- affected documents or modules; +- tests/checks performed; +- related requirement/design IDs where applicable; +- release/security/privacy/legal impact if applicable. + +## Do not include + +Do not commit: + +- secrets; +- server passwords; +- identity private keys; +- local diagnostic bundles containing sensitive data; +- generated build artifacts; +- local IDE/cache files; +- private signing keys or certificates. diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..d79111e --- /dev/null +++ b/LICENSE @@ -0,0 +1,9 @@ +TBD + +The Chanora license model has not been finalized. + +Do not treat this repository as open source, source-available, or proprietary-final until the license model is explicitly approved in: + +docs/governance/product-decision-register.md +docs/security/dependency-and-supply-chain-report.md +docs/legal/trademark-and-attribution-review.md diff --git a/NOTICE b/NOTICE new file mode 100644 index 0000000..60a50c0 --- /dev/null +++ b/NOTICE @@ -0,0 +1,10 @@ +Chanora Notices + +Chanora is an independent project and is not affiliated with, endorsed by, sponsored by, or officially associated with TeamSpeak. + +Third-party notices, OSS attributions, and license obligations are not final. + +Before public release, complete: + +docs/security/dependency-and-supply-chain-report.md +docs/legal/trademark-and-attribution-review.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..a99d7d5 --- /dev/null +++ b/README.md @@ -0,0 +1,384 @@ +# Chanora + +Chanora is a cross-platform voice communication client for TeamSpeak-compatible servers. + +It is built with a shared Flutter UI and a Rust core, with TeamSpeak-compatible protocol integration isolated behind `tsclientlib`. + +```text +Flutter UI + Rust Core + tsclientlib +``` + +> Chanora is an independent project and is not affiliated with, endorsed by, sponsored by, or officially associated with TeamSpeak. + +--- + +## Status + +Chanora is currently in early planning and baseline-candidate design. + +```text +Current documentation baseline: v0.9.2 +Current status: Baseline Candidate +Implementation status: Not production-ready +``` + +The current engineering focus is: + +- defining the system and software architecture; +- preparing the Flutter + Rust application structure; +- validating TeamSpeak-compatible protocol integration through `tsclientlib`; +- defining cross-platform audio behavior; +- preparing release, verification, security, privacy, and legal gates. + +--- + +## Target Platforms + +Chanora is intended to support: + +- Windows +- macOS +- Linux +- Android +- iOS / iPadOS + +Current platform policy: + +| Platform | Baseline | +|---|---| +| iOS / iPadOS runtime target | iOS 13+ unless Flutter, plugin, audio, or product constraints require raising it | +| App Store Connect upload gate | Xcode 26+ with iOS 26 / iPadOS 26 SDK+ for upload on or after 2026-04-28 | +| Android runtime target | Android API 24+ unless Flutter, plugin, audio, or product constraints require raising it | +| Google Play target API | Target the Google Play-required API level on upload date | + +The App Store / Play Store upload gates are release requirements. They are separate from local development and internal testing requirements. + +--- + +## Architecture Overview + +Chanora separates UI, protocol logic, state synchronization, audio processing, diagnostics, and platform services. + +```text +Flutter Application + ├─ App Shell + ├─ Material 3 / Chanora Design System + ├─ Feature Modules + ├─ View Models / State + └─ Typed Flutter/Rust Bridge + +Rust Core + ├─ Connection Manager + ├─ State Synchronization + ├─ Protocol Adapter + ├─ Audio Subsystem + ├─ Storage Services + └─ Diagnostics + +Protocol Layer + └─ tsclientlib + └─ TeamSpeak-compatible server +``` + +Key architecture rules: + +- Flutter does not call `tsclientlib` directly. +- Protocol-specific types do not leak into the Flutter UI layer. +- Rust Core owns protocol coordination, state synchronization, audio logic, storage services, diagnostics, and bridge-facing DTOs. +- Flutter owns presentation, navigation, Material 3 theming, accessibility, localization presentation, and platform UI behavior. +- Product localization and server-provided content are separated. +- UTF-8 is the internal cross-layer text representation. +- Non-UTF-8 conversion, if needed, occurs only at explicit protocol or platform boundaries. + +--- + +## MVP Direction + +The current recommended MVP scope is: + +| Area | MVP decision | +|---|---| +| Active server connections | One active server connection per client instance | +| UI baseline | Material 3 + Chanora Design System | +| Product language | English UI first, i18n-ready architecture | +| Server content | Preserve Unicode and do not translate server-provided content | +| Audio processing defaults | Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter enabled where supported and stable | +| Audio implementation path | Platform-native first; fallback isolated behind the audio subsystem | +| Local non-secret storage | SQLite or equivalent embedded database | +| Secret storage | Platform secure storage | +| Flutter/Rust bridge | Stable typed bridge with generated or schema-controlled DTOs | +| Diagnostics | Local, user-initiated export only | +| Telemetry | None in MVP | +| Crash reporting | Disabled unless explicitly approved later | + +--- + +## Repository Layout + +The repository documentation is expected to live under `docs/`. + +```text +docs/ + requirements/ + sysrs.md + srs.md + + architecture/ + sysdes.md + sad.md + sdd.md + + verification/ + verification-master-plan.md + swe4-unit-verification-plan.md + swe5-software-integration-verification-plan.md + swe6-software-verification-plan.md + sys4-system-integration-verification-plan.md + + release/ + release-readiness-go-nogo-record.md + platform-release-policy.md + + security/ + security-privacy-legal-guideline.md + threat-model.md + secure-storage-audit-report.md + diagnostic-redaction-audit-report.md + dependency-and-supply-chain-report.md + + privacy/ + privacy-policy.md + + legal/ + trademark-and-attribution-review.md + + ui-ux/ + material3-guideline.md + material3-design-tokens.md + material3-component-catalog.md + adaptive-layout-platform-guide.md + + i18n/ + localization-architecture.md + + governance/ + document-index.md + document-naming-convention.md + traceability-matrix.md + baseline-approval-record.md + baseline-candidate-validation-report.md + document-review-report.md + product-decision-register.md + decision-impact-assessment.md + git-commit-message-convention.md + repo-format-validation-report.md + path-migration-map.md + + references/ + external-references.md + aspice-swe2-swe3-integration-note.md +``` + +Implementation source folders may be added later. A likely structure is: + +```text +apps/ + chanora_flutter/ + +core/ + chanora_core/ + +crates/ + chanora_protocol/ + chanora_audio/ + chanora_state/ + chanora_storage/ + chanora_diagnostics/ + chanora_bridge/ +``` + +The exact implementation layout should be finalized when the repository scaffold is created. + +--- + +## Documentation Entry Points + +Start here: + +| Topic | Document | +|---|---| +| System requirements | `docs/requirements/sysrs.md` | +| Software requirements | `docs/requirements/srs.md` | +| System architecture | `docs/architecture/sysdes.md` | +| Software architecture | `docs/architecture/sad.md` | +| Software detailed design | `docs/architecture/sdd.md` | +| Verification strategy | `docs/verification/verification-master-plan.md` | +| Release readiness | `docs/release/release-readiness-go-nogo-record.md` | +| Platform release policy | `docs/release/platform-release-policy.md` | +| Product decisions | `docs/governance/product-decision-register.md` | +| Traceability | `docs/governance/traceability-matrix.md` | +| Security/privacy/legal gates | `docs/security/security-privacy-legal-guideline.md` | + +--- + +## Engineering Process + +Chanora follows this documentation hierarchy: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +Direct traceability rules: + +| Document | Direct upstream source | +|---|---| +| SysDes | SysRS | +| SRS | SysDes only | +| SAD | SRS only | +| SDD | SAD only | + +Verification mapping: + +```text +SDD -> SWE.4 Unit Verification +SAD + SDD -> SWE.5 Software Integration Verification +SRS -> SWE.6 Software Verification +SysDes -> SYS.4 System Integration Verification +``` + +Release readiness is tracked separately through the Go/No-Go record. + +--- + +## Release Readiness + +A release is not approved by design documents alone. + +Before an external or public release, the project must complete: + +```text +docs/release/release-readiness-go-nogo-record.md +``` + +The release decision must explicitly state: + +```text +Go +Conditional Go +No-Go +``` + +Release readiness must include: + +- release scope; +- build number; +- commit SHA; +- Git tag; +- artifact hashes; +- satisfied P0/MVP requirements; +- deferred requirements; +- verification results; +- waivers; +- security review status; +- platform readiness; +- legal and OSS review status; +- privacy policy status; +- approval decision and approvers. + +--- + +## Security, Privacy, and Legal Gates + +Security, privacy, and legal evidence are required before public or store release. + +Required documents include: + +```text +docs/security/threat-model.md +docs/security/secure-storage-audit-report.md +docs/security/diagnostic-redaction-audit-report.md +docs/security/dependency-and-supply-chain-report.md +docs/privacy/privacy-policy.md +docs/legal/trademark-and-attribution-review.md +``` + +Important gates: + +- identity secrets and server passwords must use platform secure storage; +- logs and diagnostic exports must redact secrets; +- diagnostic export must be user-initiated unless a later approved policy changes this; +- dependency licenses and vulnerabilities must be reviewed; +- OSS notices must be prepared where required; +- public wording must not imply official TeamSpeak affiliation; +- privacy policy must describe local storage, diagnostics, permissions, and data handling. + +--- + +## Git Commit Convention + +Chanora uses a Conventional Commits style format: + +```text +(): +``` + +Examples: + +```text +feat(voice): add push-to-talk state handling +fix(protocol): recover channel tree after reconnect snapshot +docs(sad): add interface catalog and performance view +i18n(ui): add fallback behavior for missing localization keys +sec(diagnostics): redact server password from export bundle +release(android): prepare internal alpha build metadata +``` + +See: + +```text +docs/governance/git-commit-message-convention.md +``` + +--- + +## Development + +Implementation commands will be added after the repository scaffold is finalized. + +Expected future commands may include: + +```bash +flutter pub get +flutter test +cargo test +cargo clippy +cargo fmt +``` + +Do not treat these as authoritative until the actual Flutter/Rust workspace has been created. + +--- + +## Contributing + +Before making a change: + +1. Check the affected requirement/design document. +2. Confirm the correct traceability layer. +3. Use the Git commit convention. +4. Update docs and verification plans when the change affects requirements, architecture, detailed design, release behavior, security, privacy, or legal gates. + +--- + +## License + +TBD. + +The license model must be confirmed before public release. See: + +```text +docs/governance/product-decision-register.md +docs/security/dependency-and-supply-chain-report.md +docs/legal/trademark-and-attribution-review.md +``` diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..5326c23 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,51 @@ +# Security Policy + +## Supported status + +Chanora is not production-ready yet. Security reports are still welcome during early development. + +## Reporting a vulnerability + +Do not open public issues for sensitive security reports. + +Until a private security channel is established, report security concerns directly to the project maintainer through the agreed private contact channel. + +## Sensitive areas + +Important security areas include: + +- identity private keys and identity material; +- server passwords; +- platform secure storage; +- local database contents; +- diagnostic logs and export bundles; +- protocol input from compatible servers; +- Flutter/Rust bridge DTO validation; +- audio permission behavior; +- dependency and supply-chain integrity; +- OSS license and attribution compliance. + +## Security gates before public release + +Before any public or store release, the following documents must be completed and reviewed: + +```text +docs/security/threat-model.md +docs/security/secure-storage-audit-report.md +docs/security/diagnostic-redaction-audit-report.md +docs/security/dependency-and-supply-chain-report.md +docs/privacy/privacy-policy.md +docs/legal/trademark-and-attribution-review.md +``` + +## Secret handling rule + +Secrets must not be stored in plaintext local storage or written to logs. + +Secrets include: + +- server passwords; +- identity private keys; +- authentication tokens if later added; +- secure-storage keys; +- signing credentials. diff --git a/docs/architecture/proof-of-concept-plan.md b/docs/architecture/proof-of-concept-plan.md new file mode 100644 index 0000000..9e1cd67 --- /dev/null +++ b/docs/architecture/proof-of-concept-plan.md @@ -0,0 +1,49 @@ +# Proof-of-Concept Plan + +**Document type:** Architecture / Proof-of-Concept Plan +**Version:** 0.1.0 +**Status:** Draft +**Language:** English +**Product:** Chanora +**Repo path:** `docs/architecture/proof-of-concept-plan.md` + +--- + +## 1. Purpose + +This document defines technical proof-of-concept work that should be completed before heavy product implementation. + +## 2. Required PoCs + +| PoC | Purpose | Exit criteria | +|---|---|---| +| Flutter/Rust bridge hello | Prove command/result/event DTO boundary | Flutter can call Rust and receive event stream data | +| `tsclientlib` connect spike | Prove protocol feasibility | Rust can connect to a compatible server/test double | +| Audio capture/playback spike | Prove platform audio behavior | Capture/playback works on at least one desktop and one mobile target | +| Secure storage spike | Prove secret storage behavior | Secret write/read/delete works through platform secure storage | +| SQLite storage spike | Prove local non-secret persistence | Schema, migration, and repository pattern are demonstrated | +| Diagnostics redaction spike | Prove redaction before export | Password and identity-secret samples are redacted | + +## 3. PoC Directory + +Recommended future location: + +```text +poc/ + flutter-rust-bridge-hello/ + tsclientlib-connect-spike/ + audio-capture-playback-spike/ + secure-storage-spike/ + sqlite-storage-spike/ + diagnostics-redaction-spike/ +``` + +## 4. Rule + +A PoC is not product code unless explicitly promoted. + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial proof-of-concept plan. | diff --git a/docs/architecture/sad.md b/docs/architecture/sad.md new file mode 100644 index 0000000..f8db79c --- /dev/null +++ b/docs/architecture/sad.md @@ -0,0 +1,1296 @@ + +# Chanora SAD — Software Architecture Description + +**Document type:** SAD / Software Architecture Description +**Process alignment:** ASPICE SWE.2 Software Architectural Design +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Architecture baseline:** Flutter + Rust Core +**Lifecycle position:** `SysRS -> SysDes -> SRS -> SAD -> SDD` + +**Repo path:** `docs/architecture/sad.md` --- + +## 1. Purpose + +This Software Architecture Description defines the software architecture for Chanora. + +The SAD is intentionally structured as an architecture document, not only a list of modules. It includes: + +- Stakeholders and concerns +- Architecture drivers and constraints +- System context view +- Container view +- Component view +- Runtime / sequence views +- Deployment view +- Data and storage view +- Security and privacy view +- Diagnostics and observability view +- UI architecture view +- Audio architecture view +- Protocol architecture view +- Internationalization architecture view +- Architecture decision records +- SRS-to-SAD traceability + +## 2. Strict Traceability Rules + +The documentation hierarchy is: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +The SAD shall use only the SRS layer as its direct source. + +Rules: + +```text +SAD items shall use Source SRS only. +SAD items shall not use direct system-requirement sources. +SAD items shall not use direct system-design sources. +SDD items shall use Source SAD only. +``` + +## 3. Stakeholders and Architecture Concerns + +| Stakeholder | Concerns | +|---|---| +| End user | Fast voice access, stable connection, clear UI, safe controls | +| Power user | Audio configuration, diagnostics, reliable reconnect | +| Software team | Clear module boundaries, testability, maintainability | +| Platform team | OS permissions, audio routing, lifecycle behavior, packaging | +| QA team | Traceability, test seams, platform coverage, regression verification | +| Security reviewer | Secret storage, redaction, input validation, diagnostics safety | +| UX designer | Material 3 consistency, adaptive layout, accessibility, i18n | +| Release operator | Repeatable builds, signing, packaging, release metadata | + +## 4. Architecture Drivers + +| Driver | Architectural impact | +|---|---| +| Flutter + Rust Core | UI and core logic are separated by bridge DTOs and event streams. | +| `tsclientlib` | Protocol integration is isolated inside a protocol adapter. | +| Cross-platform operation | Platform behavior is isolated behind platform services and adapters. | +| Low-latency voice | Real-time audio processing is isolated from UI rendering. | +| Material 3 baseline | UI architecture uses a design-system layer above Material 3. | +| Strict traceability | SAD derives only from SRS and SDD derives only from SAD. | +| i18n readiness | Product localization, server content, Unicode, and diagnostics text are separated. | +| Diagnostics and support | Logging, redaction, exports, and machine-readable diagnostics are centralized. | + +## 5. Context View + +```text +User + -> Chanora Flutter Client + -> Rust Core + -> tsclientlib Protocol Adapter + -> External TeamSpeak-compatible Server + +Chanora Flutter Client + -> Operating System Services + -> Audio devices + -> Secure storage + -> Permissions + -> Notifications + -> Lifecycle / insets / routing +``` + +### Context boundaries + +Inside Chanora software: + +- Flutter app shell +- Chanora design system +- Feature modules +- Flutter state and view models +- Bridge facade +- Rust Core +- Protocol adapter +- Audio subsystem +- Storage subsystem +- Diagnostics subsystem +- Localization subsystem +- Platform service abstractions + +Outside Chanora software: + +- External compatible voice servers +- Operating systems +- Physical audio devices +- App stores / package repositories +- Network infrastructure + +## 6. Container View + +```text ++---------------------------------------------------------------+ +| Flutter Application Container | +| App Shell | +| Design System | +| Adaptive Shell | +| Feature Modules | +| Flutter State / View Models | +| Localization Service | +| Platform Services | ++------------------------- Bridge DTOs / Events ----------------+ +| Rust Core Container | +| Connection Manager | +| State Synchronization | +| Protocol Adapter | +| Audio Engine | +| Storage Services | +| Diagnostics | ++---------------------------------------------------------------+ +``` + +| Container | Responsibility | +|---|---| +| Flutter Application Container | UI, navigation, Material 3 theming, accessibility, localization, platform presentation | +| Bridge Container | Stable DTOs, commands, event streams, error mapping | +| Rust Core Container | Authoritative connection, protocol coordination, state, audio, storage, diagnostics | +| Platform Services Container | OS-specific services exposed to Flutter/Rust boundaries | +| External Server | Compatible server providing channels, users, voice, and text | + +## 7. Component View + +### 7.1 Flutter application components + +| Component | Responsibility | +|---|---| +| `app_shell` | App initialization, routing, global providers, theme mode, localization bootstrap | +| `design_system` | Material 3 configuration, Chanora tokens, typography, shapes, motion, density | +| `adaptive_shell` | Compact, medium, expanded layout branching | +| `features/connect` | Manual connection and bookmark entry | +| `features/server` | Channel tree, users, connection status | +| `features/voice` | Voice controls and audio settings | +| `features/chat` | Channel text UI | +| `features/settings` | User settings, audio processing settings, i18n options | +| `features/diagnostics` | Redacted diagnostics and export flow | +| `state` | View models derived from Rust Core events | +| `localization` | Product string resources and fallback | +| `platform_services` | Insets, back intent, haptics, permissions, platform behavior | + +### 7.2 Rust components + +| Component | Responsibility | +|---|---| +| `chanora_core` | Top-level Rust API, connection orchestration, command handling | +| `chanora_protocol` | `tsclientlib` isolation and protocol event mapping | +| `chanora_state` | Snapshot, delta, reducers, authoritative state model | +| `chanora_audio` | Capture, processing, encode/decode, jitter, mixing | +| `chanora_storage` | Bookmarks, settings, identity references, non-secret data | +| `chanora_diagnostics` | Logs, redaction, event recording, export | +| `chanora_bridge` | Flutter/Rust DTOs, API, event streams | + +## 8. Runtime Views + +### 8.1 Application startup + +```text +Start process + -> Initialize platform bindings + -> Load localization baseline + -> Build Material 3 theme + -> Register Chanora design tokens + -> Initialize bridge facade + -> Initialize app router + -> Render adaptive shell +``` + +### 8.2 Connect to server + +```text +User submits connection + -> Connect feature controller + -> Bridge command + -> Rust Core connection manager + -> Protocol adapter + -> tsclientlib + -> External server + -> Snapshot fetch + -> State reducer + -> Core event stream + -> Flutter view model + -> Server screen render +``` + +### 8.3 Incoming server event + +```text +External server event + -> tsclientlib + -> Protocol adapter + -> Internal protocol event + -> State reducer + -> Core event + -> Bridge stream + -> Flutter state + -> UI update +``` + +### 8.4 Outgoing voice + +```text +Microphone + -> Platform capture + -> Audio pipeline + -> High-pass filter + -> Noise suppression + -> Echo canceller + -> Automatic gain control + -> Push-to-talk / mute gate + -> Encoder + -> Protocol adapter + -> External server +``` + +### 8.5 Incoming voice + +```text +External server + -> Protocol adapter + -> Jitter buffer + -> Decoder + -> Per-user mute / volume + -> Mixer + -> Platform playback +``` + +### 8.6 Product-localized text rendering + +```text +String key + -> Localization service + -> Locale lookup + -> Fallback if missing + -> Flutter text widget + -> Accessibility semantics +``` + +### 8.7 Server-content rendering + +```text +Server-provided text + -> Protocol boundary conversion if required + -> UTF-8 internal representation + -> DTO / state + -> Flutter UI + -> Display without translation +``` + +## 9. Deployment View + +| Platform | Deployment form | +|---|---| +| Windows | Signed installer or packaged desktop artifact | +| macOS | Signed and notarized application bundle | +| Linux | Selected package format such as AppImage, Flatpak, deb, or rpm | +| Android | AAB/APK with platform permissions and foreground voice behavior | +| iOS | TestFlight/App Store build with platform permission and audio session behavior | + +Deployment architecture separates: + +- Build scripts +- Signing assets +- Store metadata +- Release notes +- Platform permission declarations +- Runtime configuration + +## 10. Data and Storage View + +| Data type | Storage architecture | +|---|---| +| Bookmarks | Local database / repository | +| Recent servers | Local database / repository | +| Audio settings | Local database / repository | +| UI preferences | Local database / repository | +| Identity secrets | Platform secure storage | +| Server passwords | Platform secure storage | +| Diagnostic bundles | User-initiated generated export | +| Protocol state | Runtime state, rebuilt from snapshot | +| Product localization | Static or packaged localization resources | +| Server content | Runtime content, optionally session-level persistence later | + +## 11. Security and Privacy View + +Security architecture rules: + +- Secrets are not stored in plaintext. +- Passwords and identity secrets are stored through platform secure storage. +- Logs and diagnostic exports are redacted. +- User-visible errors do not expose internal stack traces. +- Diagnostics export requires user action. +- Protocol and platform text conversions occur only at explicit boundaries. +- Product localization does not translate server-provided content. + +## 12. Diagnostics and Observability View + +Diagnostics components provide: + +- Structured logs +- Redaction +- Network diagnostics +- Audio diagnostics +- Protocol event recording where enabled +- Event replay support where enabled +- User-initiated diagnostic export +- Stable language-neutral diagnostic keys +- Localizable diagnostic display descriptions + +## 13. UI Architecture View + +```text +Material 3 + -> Chanora Design System + -> Tokens + -> Component themes + -> Chanora components + -> Feature screens + -> View models +``` + +Rules: + +- Feature screens do not hardcode semantic colors, spacing, shapes, or motion. +- Design system owns Material 3 mapping. +- Components own accessibility semantics for common controls. +- Voice and connection controls remain visible or directly reachable across layouts. +- Adaptive shell owns layout class selection. + +## 14. Audio Architecture View + +The audio subsystem is separate from UI rendering. + +Key elements: + +- Platform capture +- Audio preprocessing +- Echo cancellation +- Automatic gain control +- Noise suppression +- High-pass filtering +- Voice activity and metering +- Push-to-talk and mute gate +- Opus-compatible encode/decode +- Jitter buffer +- Mixer +- Playback routing + +## 15. Protocol Architecture View + +The protocol subsystem isolates all `tsclientlib` interaction. + +Rules: + +- Flutter does not call `tsclientlib`. +- Rust Core does not expose raw protocol library types to Flutter. +- Protocol events are converted to internal protocol events. +- Protocol errors are converted to user-safe error models. +- Reconnect orchestration remains above protocol adapter behavior when required. + +## 16. Internationalization Architecture View + +i18n architecture separates: + +| Text type | Handling | +|---|---| +| Product strings | Localized | +| Accessibility labels | Localized | +| Settings labels | Localized | +| Error descriptions | Localized where user-facing | +| Diagnostic keys | Stable and language-neutral | +| Server names | Preserved, not translated | +| Channel names | Preserved, not translated | +| Client nicknames | Preserved, not translated | +| Chat messages | Preserved, not translated | + +UTF-8 is the internal representation for cross-layer text. Conversion occurs only at protocol or platform boundaries. + +## 17. Architecture Decisions + +| ADR | Decision | Status | +|---|---|---| +| ADR-001 | Use Flutter for cross-platform UI | Accepted | +| ADR-002 | Use Rust Core for protocol, state, audio, storage, and diagnostics logic | Accepted | +| ADR-003 | Use `tsclientlib` and isolate it in the protocol adapter | Accepted | +| ADR-004 | Use Material 3 as UI design baseline | Accepted | +| ADR-005 | Define Chanora Design System above Material 3 | Accepted | +| ADR-006 | Use strict `SysRS -> SysDes -> SRS -> SAD -> SDD` traceability | Accepted | +| ADR-007 | Do not let SAD link directly to system requirement or system design IDs | Accepted | +| ADR-008 | Use UTF-8 internally and boundary-only string conversion | Accepted | +| ADR-009 | Treat server-provided text as content, not product localization | Accepted | + + +## 18. SWE.2 Architecture Completeness and Evaluation Criteria + +The architecture shall be evaluated against the following SWE.2 criteria before baseline approval and after architecture-affecting changes. + +| Criterion | Architecture evidence | +|---|---| +| Software elements are identified | Component View and Software Architecture Items | +| Software requirements are allocated | SRS-to-SAD coverage matrix | +| Interfaces are defined | Interface Catalog | +| Dynamic behavior is defined | Runtime Views | +| Resource consumption objectives are considered | Performance and Resource View | +| Architecture is technically feasible | Architecture evaluation checklist | +| Architecture is testable | Verification hooks and test seams | +| Traceability is maintained | Direct `Source SRS` references only | +| Consistency is maintained | View consistency checklist and change impact review | +| Architecture is communicated | Change History and baseline approval record | + +## 19. Interface Catalog + +The interface catalog records software architectural interfaces. Detailed design shall refine these interfaces in the SDD. + +| Interface ID | Interface | Producer | Consumer | Data / message | Error handling | Source SAD | +|---|---|---|---|---|---|---| +| IF-SAD-001 | Flutter command bridge | Flutter Feature Controller | Rust Bridge Facade | Command DTO | Bridge error DTO | SAD-040 | +| IF-SAD-002 | Rust event stream | Rust Core | Flutter State | Core event DTO | Stream close / error event | SAD-041 | +| IF-SAD-003 | Protocol adapter boundary | Rust Core | Protocol Adapter | Protocol command / event | Protocol error mapping | SAD-032 | +| IF-SAD-004 | Audio capture boundary | Platform Audio | Audio Subsystem | Audio frame | Device unavailable / underrun | SAD-034 | +| IF-SAD-005 | Audio playback boundary | Audio Subsystem | Platform Audio | Mixed audio frame | Device unavailable / route changed | SAD-034 | +| IF-SAD-006 | Secure storage boundary | Storage Service | Platform Secure Storage | Secret key/value | Secure-store error | SAD-035 | +| IF-SAD-007 | Localization lookup | Flutter UI | Localization Service | String key + parameters | Missing-key fallback | SAD-020 | +| IF-SAD-008 | Server-content text path | Protocol Adapter | Flutter UI | UTF-8 content text | Boundary conversion error | SAD-021, SAD-022 | +| IF-SAD-009 | Diagnostics export | Diagnostics | File/share target | Redacted diagnostic bundle | Export failure | SAD-036, SAD-050 | +| IF-SAD-010 | Platform behavior service | Flutter Shell | Platform Services | Insets, back, haptics, permissions | Unsupported platform behavior | SAD-017, SAD-018, SAD-019 | + +## 20. Performance and Resource View + +| Area | Objective | Architecture mechanism | +|---|---|---| +| UI responsiveness | Avoid blocking UI during connection, sync, reconnect, and diagnostics export | Async bridge calls, view models, Rust Core background work | +| Audio latency | Minimize local audio pipeline latency | Dedicated audio subsystem and platform audio adapters | +| Memory growth | Avoid unbounded growth in logs, audio buffers, chat history, and event queues | Bounded buffers, retention policies, diagnostic export controls | +| Reconnect | Rebuild state after recoverable connection failure | Connection manager, fresh snapshot, state reducer | +| Localization | Avoid runtime string lookup failures | Baseline English fallback and localization service tests | +| Diagnostics | Export without leaking secrets | Central redaction and export service | + +## 21. Assumptions and Dependencies + +| ID | Assumption / Dependency | Impact | +|---|---|---| +| SAD-ASM-001 | Flutter Material 3 support is available on the target Flutter version. | Design System depends on Material 3 widgets and ThemeData behavior. | +| SAD-ASM-002 | Rust and Flutter bridge tooling supports stable DTO generation. | Bridge and event stream interfaces depend on stable generated bindings. | +| SAD-ASM-003 | `tsclientlib` supports or can be adapted for required MVP protocol behavior. | Protocol Adapter feasibility depends on library capability. | +| SAD-ASM-004 | Target operating systems expose required audio, permission, and secure storage services. | Platform Services depend on OS capabilities. | +| SAD-ASM-005 | Flutter text rendering can preserve Unicode and support bidirectional text where platform engines support it. | i18n architecture depends on platform text support. | + +## 22. Architecture Glossary + +| Term | Meaning | +|---|---| +| App Shell | Top-level Flutter composition root for routing, initialization, theme, localization, and adaptive layout | +| Design System | Chanora UI layer that maps Material 3 and product semantic tokens to components | +| Bridge Facade | Software boundary used by Flutter to call Rust Core and receive Rust events | +| Runtime View | Architecture view describing runtime interaction, sequence, or state behavior | +| Interface Catalog | Architectural list of software interfaces to be refined by detailed design | +| ADR | Architecture Decision Record | +| Product string | User-visible string owned by Chanora and eligible for localization | +| Server content | User/server-provided text received from a compatible voice server and displayed without translation | + + +## 23. Software Architecture Items + +**SAD-001**: The architecture shall use a Flutter App Shell as the top-level software composition root. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Flutter App Shell +- Source SRS: SRS-144, SRS-149, SRS-151, SRS-184 +- Verification method: Review, Inspection + +The shell initializes routing, theme, localization, adaptive layout, platform services, and feature containers before rendering feature screens. + +**SAD-002**: The architecture shall use a Chanora Design System package above Material 3. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Design System +- Source SRS: SRS-145, SRS-146, SRS-147, SRS-148, SRS-149 +- Verification method: Review, Widget Test + +The design system contains product tokens, Material 3 theme configuration, component themes, and product semantic mappings. + +**SAD-003**: The architecture shall isolate feature screens from direct theme-token construction. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Feature Modules, Design System +- Source SRS: SRS-150 +- Verification method: Static Inspection + +Feature screens consume design-system APIs and components instead of creating colors, spacing, shape, or motion locally. + +**SAD-004**: The architecture shall implement connection-state token mapping in the design system. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Design System +- Source SRS: SRS-146, SRS-148 +- Verification method: Unit Test + +Connection states such as connected, connecting, reconnecting, disconnected, and error map to product semantic tokens. + +**SAD-005**: The architecture shall implement voice-state token mapping in the design system. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Design System +- Source SRS: SRS-147 +- Verification method: Unit Test + +Voice states such as speaking, muted, deafened, and push-to-talk active map to product semantic tokens. + +**SAD-006**: The architecture shall implement latency, packet-loss, diagnostics, and error token mapping. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Design System +- Source SRS: SRS-148 +- Verification method: Unit Test + +Latency, packet loss, diagnostics severity, warning, and error semantics are separated from Material base colors. + +**SAD-007**: The architecture shall expose tokens through Flutter theming mechanisms. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Design System +- Source SRS: SRS-149 +- Verification method: Widget Test + +ThemeData, ColorScheme, component themes, TextTheme, and ThemeExtension are the allowed token access mechanisms. + +**SAD-008**: The architecture shall provide an Adaptive Shell that owns window-class resolution. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Flutter App Shell +- Source SRS: SRS-151, SRS-152, SRS-153, SRS-154 +- Verification method: Widget Test, Integration Test + +Window class is resolved once at shell level and passed into layout composition. + +**SAD-009**: The architecture shall implement a compact layout branch. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Adaptive Shell +- Source SRS: SRS-152, SRS-155, SRS-156 +- Verification method: Integration Test + +Compact layout uses single-column content and keeps connection and voice controls visible or directly reachable. + +**SAD-010**: The architecture shall implement a medium layout branch. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Adaptive Shell +- Source SRS: SRS-153, SRS-155, SRS-156 +- Verification method: Integration Test + +Medium layout supports side navigation or navigation rail and main content. + +**SAD-011**: The architecture shall implement an expanded layout branch. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Adaptive Shell +- Source SRS: SRS-154, SRS-155, SRS-156 +- Verification method: System Test + +Expanded layout supports persistent panes and persistent voice controls. + +**SAD-012**: The architecture shall implement a Connection Status UI component. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Components, Feature Modules +- Source SRS: SRS-155, SRS-159 +- Verification method: Widget Test + +Connection state is displayed with non-color-only cues. + +**SAD-013**: The architecture shall implement a persistent VoiceBar component. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Components, Voice Feature +- Source SRS: SRS-156 +- Verification method: Widget Test, Integration Test + +VoiceBar exposes mute, deaf, push-to-talk, input level, current channel, and latency summary. + +**SAD-014**: The architecture shall implement accessible semantics for critical controls. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Components, Localization +- Source SRS: SRS-157, SRS-158, SRS-159 +- Verification method: Accessibility Test + +Critical controls expose semantic labels and state descriptions. + +**SAD-015**: The architecture shall implement keyboard focus traversal for desktop and tablet keyboard use. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SRS: SRS-160 +- Verification method: Widget Test, System Test + +Focusable components use a predictable traversal order and visible focus indication. + +**SAD-016**: The architecture shall protect critical controls under increased text scaling. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Adaptive Shell, Components +- Source SRS: SRS-161 +- Verification method: Accessibility Test + +Shell and components are designed to avoid clipping or loss of critical actions when text scale increases. + +**SAD-017**: The architecture shall centralize safe-area and inset handling. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Platform Services +- Source SRS: SRS-162 +- Verification method: Platform Test + +Safe area, display cutout, system bars, keyboard, and desktop inset handling is performed through shared shell utilities. + +**SAD-018**: The architecture shall model Android back behavior through platform services. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Platform Services +- Source SRS: SRS-163 +- Verification method: Platform Test + +Back behavior is represented as an intent handled by route and shell policy. + +**SAD-019**: The architecture shall model iOS navigation, keyboard avoidance, safe area, and haptics through platform services. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Platform Services +- Source SRS: SRS-164 +- Verification method: Platform Test + +iOS behavior is not hardcoded in feature screens. + +**SAD-020**: The architecture shall implement a Localization Service for product-owned strings. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SRS: SRS-165, SRS-166, SRS-167, SRS-168, SRS-169 +- Verification method: Unit Test, Integration Test + +Product strings are loaded from localization resources with English fallback. + +**SAD-021**: The architecture shall separate product localization from server-provided content. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Localization Service, Protocol DTOs, Flutter UI +- Source SRS: SRS-170 +- Verification method: Integration Test + +Server content is displayed as content and is not translated by the client. + +**SAD-022**: The architecture shall preserve Unicode through protocol, bridge, state, and UI paths. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Bridge, Rust Core, Flutter UI +- Source SRS: SRS-171, SRS-172 +- Verification method: Integration Test + +DTOs and internal state use UTF-8 compatible representations. + +**SAD-023**: The architecture shall isolate non-UTF-8 conversion in boundary adapters. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Platform Adapter, Bridge +- Source SRS: SRS-173 +- Verification method: Inspection, Integration Test + +Encoding conversion is not permitted in feature screens or general business logic. + +**SAD-024**: The architecture shall preserve multilingual content in diagnostics except for intentional redaction. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Diagnostics, Storage +- Source SRS: SRS-174 +- Verification method: Test, Audit + +Diagnostic payload builders preserve Unicode values while applying redaction policy. + +**SAD-025**: The architecture shall support bidirectional text where the platform text engine supports it. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SRS: SRS-175 +- Verification method: Localization Test + +Text widgets are selected and configured to allow natural bidirectional rendering. + +**SAD-026**: The architecture shall centralize locale-aware formatting. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Localization Service, Diagnostics UI +- Source SRS: SRS-176 +- Verification method: Localization Test + +Date, time, number, and visible diagnostic timestamp formatting occurs through localization utilities. + +**SAD-027**: The architecture shall keep diagnostic machine fields language-neutral. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Diagnostics, Localization Service +- Source SRS: SRS-177, SRS-178 +- Verification method: Inspection, Test + +Diagnostic keys and codes remain stable while display descriptions are localized. + +**SAD-028**: The architecture shall maintain downstream UI/UX and design-system documentation. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: UX, Software Engineering +- Source SRS: SRS-179 +- Verification method: Review + +The UI/UX guideline, token guide, component catalog, adaptive layout guide, and platform guide are treated as supporting baselines. + +**SAD-029**: The architecture shall enforce SRS-only source traceability for SAD. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Software Architecture +- Source SRS: SRS-180, SRS-181, SRS-182 +- Verification method: Inspection + +SAD items contain Source SRS and do not contain lower-layer source IDs. + +**SAD-030**: The architecture shall enforce SAD-only source traceability for SDD. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Software Design +- Source SRS: SRS-183 +- Verification method: Inspection + +Detailed design items are derived from SAD items only. + +**SAD-031**: The architecture shall initialize theme, localization, and platform services before first feature render. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Flutter App Shell +- Source SRS: SRS-184 +- Verification method: Integration Test + +The app shell performs initialization sequencing before rendering user-visible feature content. + +**SAD-032**: The architecture shall isolate TeamSpeak-compatible protocol integration behind Rust protocol components. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Rust Core, Protocol Adapter +- Source SRS: SRS-001 through SRS-030 +- Verification method: Integration Test + +Protocol responsibilities remain outside Flutter feature screens. + +**SAD-033**: The architecture shall isolate authoritative server state in Rust Core and state synchronization components. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Rust Core, State Sync +- Source SRS: SRS-031 through SRS-060 +- Verification method: System Test + +Flutter consumes state events and view models rather than mutating protocol state. + +**SAD-034**: The architecture shall isolate real-time audio processing in the audio subsystem. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Audio +- Source SRS: SRS-061 through SRS-090 +- Verification method: Audio Test + +Capture, preprocessing, encoding, decoding, jitter buffer, and mixing are assigned to audio software components. + +**SAD-035**: The architecture shall isolate local storage and secure storage behavior behind storage components. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Storage, Platform Secure Storage +- Source SRS: SRS-091 through SRS-110 +- Verification method: Security Test, Inspection + +Storage APIs separate non-secret data from secrets. + +**SAD-036**: The architecture shall isolate diagnostics and redaction behavior in diagnostics components. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Diagnostics +- Source SRS: SRS-111 through SRS-124 +- Verification method: Audit, Test + +Logs, event capture, export, and redaction stay centralized. + +**SAD-037**: The architecture shall isolate deployment, release, and packaging support in build and release assets. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Build, Release, Operations +- Source SRS: SRS-125 through SRS-134 +- Verification method: Inspection, Demo + +Packaging and release decisions are outside feature-screen code. + +**SAD-038**: The architecture shall provide verification hooks for requirements traceability and platform validation. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Verification Support +- Source SRS: SRS-135 through SRS-143 +- Verification method: Review, Inspection + +Traceability checks and verification evidence are supported by documentation and test structure. + +**SAD-039**: The architecture shall use view models as the boundary between feature screens and application state. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Flutter State +- Source SRS: SRS-001 through SRS-184 +- Verification method: Unit Test, Review + +Feature screens receive render-ready state and issue user intents through controllers. + +**SAD-040**: The architecture shall use a bridge facade as the only Flutter-to-Rust command boundary. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Bridge Facade +- Source SRS: SRS-001 through SRS-184 +- Verification method: Inspection, Integration Test + +Flutter feature modules call bridge services rather than Rust implementation details. + +**SAD-041**: The architecture shall map asynchronous Rust events into Flutter UI state updates. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Bridge, Flutter State +- Source SRS: SRS-001 through SRS-184 +- Verification method: Integration Test + +Core event streams update UI view models deterministically. + +**SAD-042**: The architecture shall define test seams for theme, localization, adaptive shell, platform services, and bridge facade. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Verification Support +- Source SRS: SRS-165 through SRS-184 +- Verification method: Review, Test + +Test seams allow widget, integration, platform, and golden tests. + +**SAD-043**: The architecture shall support light and dark theme mode behavior. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Design System, Flutter App Shell +- Source SRS: SRS-157 +- Verification method: Widget Test + +Theme mode is controlled centrally and propagates through Material theme data. + +**SAD-044**: The architecture shall allow dynamic color as an optional enhancement without overriding Chanora semantic state tokens. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Design System +- Source SRS: SRS-158 +- Verification method: Widget Test + +Dynamic color affects base Material scheme but not product semantic safety states. + +**SAD-045**: The architecture shall keep future SDD derivation independent from non-SAD requirement IDs. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P2 / Production +- Allocated to: Software Design +- Source SRS: SRS-183 +- Verification method: Inspection + +The SAD-to-SDD boundary is the only source path for SDD. + +**SAD-046**: The architecture shall include C4-style architecture views in the SAD baseline. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P2 / Production +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review + +Context, container, component, runtime, deployment, and data views are part of the architecture baseline. + +**SAD-047**: The architecture shall include ADRs for architecturally significant decisions. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P2 / Production +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review + +ADR entries document the rationale for major design decisions. + +**SAD-048**: The architecture shall identify software stakeholders and architecture concerns. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P2 / Production +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review + +Stakeholder concerns guide architecture views and tradeoffs. + +**SAD-049**: The architecture shall include deployment and operational architecture views. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P2 / Production +- Allocated to: Release Architecture +- Source SRS: SRS-125 through SRS-134, SRS-182 +- Verification method: Review, Inspection + +Deployment view covers platform-specific packaging and release architecture. + +**SAD-050**: The architecture shall include diagnostics and observability architecture views. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P2 / Production +- Allocated to: Diagnostics Architecture +- Source SRS: SRS-111 through SRS-124, SRS-177, SRS-178 +- Verification method: Review, Test + +Diagnostics view covers logs, redaction, event keys, localization, and exports. + + + +**SAD-051**: The architecture shall include a SWE.2 evaluation checklist covering software elements, allocation, interfaces, dynamic behavior, resource objectives, feasibility, testability, traceability, consistency, and communication. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review, Inspection + +The checklist is used before SAD baseline approval and after architecture-affecting changes. + +**SAD-052**: The architecture shall maintain an interface catalog for architecturally significant software interfaces. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review, Inspection + +The catalog records producers, consumers, data/message type, and error handling for each architectural interface. + +**SAD-053**: The architecture shall include performance and resource views for UI responsiveness, audio latency, memory growth, reconnect, localization, and diagnostics. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review, Analysis + +Performance and resource objectives are linked to architecture mechanisms. + +**SAD-054**: The architecture shall document assumptions and dependencies that affect design feasibility. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review + +Assumptions and dependencies are reviewed during change impact analysis. + +**SAD-055**: The architecture shall include a glossary for architecture-specific terms. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P2 / Production +- Allocated to: Software Architecture +- Source SRS: SRS-182 +- Verification method: Review + +The glossary reduces ambiguity across architecture, detailed design, and verification activities. + +**SAD-056**: The architecture shall define software interface error-handling responsibilities at the architectural level. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Software Architecture, Bridge, Rust Core, Platform Services +- Source SRS: SRS-182 +- Verification method: Review, Integration Test + +Each architecturally significant interface identifies error handling responsibilities. + +**SAD-057**: The architecture shall explicitly support detailed design refinement of interface names, types, units, resolutions, ranges, and default values. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Software Architecture, Software Design +- Source SRS: SRS-183 +- Verification method: Review, Inspection + +The SAD delegates detailed per-unit interface metadata to the SDD. + +**SAD-058**: The architecture shall define software units as the target decomposition level for SWE.3 detailed design. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Software Architecture, Software Design +- Source SRS: SRS-183 +- Verification method: Review + +Software components are decomposed into software units in the SDD. + +**SAD-059**: The architecture shall define that SDD detail must be sufficient to support implementation and unit verification. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Software Design, Verification +- Source SRS: SRS-183 +- Verification method: Review, Inspection + +The required SDD detail level is driven by implementation and unit verification needs. + +**SAD-060**: The architecture shall require SAD and SDD changes to be communicated to relevant affected parties before downstream implementation or verification updates are treated as baseline. + +- Status: Baseline +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Software Architecture, Software Design, Verification +- Source SRS: SRS-180, SRS-182, SRS-183 +- Verification method: Review + +Communication evidence is maintained through change history and baseline approval records. + + +## 24. SRS-to-SAD Coverage Matrix + +| SRS Range | SAD Coverage | +|---|---| +| SRS-001 through SRS-030 | SAD-032, SAD-039, SAD-040, SAD-041 | +| SRS-031 through SRS-060 | SAD-033, SAD-039, SAD-041 | +| SRS-061 through SRS-090 | SAD-034, SAD-039, SAD-041 | +| SRS-091 through SRS-110 | SAD-035 | +| SRS-111 through SRS-124 | SAD-036, SAD-050 | +| SRS-125 through SRS-134 | SAD-037, SAD-049 | +| SRS-135 through SRS-143 | SAD-038 | +| SRS-144 through SRS-184 | SAD-001 through SAD-031, SAD-039 through SAD-060 | + +## 25. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial SAD baseline covering SRS-001 through SRS-184 and enforcing SRS-only direct traceability. | +| 0.2.0 | 2026-05-14 | Expanded SAD into a full software architecture document with stakeholders, concerns, context/container/component/runtime/deployment/data/security/diagnostics/UI/audio/protocol/i18n views and ADRs. | +| 0.3.0 | 2026-05-14 | Added SWE.2 evaluation checklist, interface catalog, performance/resource view, assumptions/dependencies, glossary, and SDD refinement requirements. | + +--- + +## 26. Platform Baseline and Product Decision Architecture Addendum + +**SAD-061**: The software architecture shall isolate iOS runtime minimum version configuration from feature logic. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: iOS Build Configuration, Platform Services +- Source SRS: SRS-185 +- Verification method: Platform Test, Inspection + +**SAD-062**: The software architecture shall treat Apple App Store SDK compliance as a release pipeline and build configuration responsibility. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Release Pipeline, iOS Build Configuration +- Source SRS: SRS-186 +- Verification method: Release Inspection + +**SAD-063**: The software architecture shall isolate Android runtime minimum version and Play target API compliance in Android build configuration and platform services. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Android Build Configuration, Platform Services, Release Pipeline +- Source SRS: SRS-187, SRS-188 +- Verification method: Platform Test, Release Inspection + +**SAD-064**: The software architecture shall model one active connection as the MVP runtime invariant across UI, Rust Core, state synchronization, audio routing, and protocol adapter components. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, State Sync, Audio Subsystem, Protocol Adapter +- Source SRS: SRS-189 +- Verification method: System Test, Review + +**SAD-065**: The software architecture shall assign audio processing defaults and capability detection to the audio subsystem and settings presentation layer. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Audio, Settings UI +- Source SRS: SRS-190 +- Verification method: Audio Test + +**SAD-066**: The software architecture shall hide platform-native and fallback audio processing implementations behind the audio subsystem interface. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Audio Adapter +- Source SRS: SRS-191 +- Verification method: Architecture Review, Audio Test + +**SAD-067**: The software architecture shall isolate non-secret local persistence in a database repository layer and secret persistence in platform secure storage services. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage +- Source SRS: SRS-192 +- Verification method: Storage Test, Security Audit + +**SAD-068**: The software architecture shall use a stable typed bridge facade with schema-controlled DTO boundaries between Flutter and Rust. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Bridge Facade, Flutter State, Rust Core +- Source SRS: SRS-193 +- Verification method: Integration Test, Architecture Review + +**SAD-069**: The software architecture shall exclude automatic telemetry, automatic diagnostic upload, and automatic crash reporting from MVP components and release configuration. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Diagnostics, Privacy, Release Pipeline +- Source SRS: SRS-194 +- Verification method: Privacy Review, Security Audit + +**SAD-070**: The software architecture shall record the product decisions affecting platform baselines, connection scope, audio defaults, audio implementation path, storage, bridge, diagnostics, and crash reporting in the ADR and decision baseline. + +- Status: Baseline Candidate +- Type: Software Architecture Item +- Stage: P0 / MVP +- Allocated to: Software Architecture, Documentation Control +- Source SRS: SRS-185 through SRS-194 +- Verification method: Review, Inspection + +## 27. Updated SRS-to-SAD Coverage Matrix + +| SRS Range | SAD Coverage | +|---|---| +| SRS-001 through SRS-184 | Covered by inherited SAD baseline `SAD-001` through `SAD-060` | +| SRS-185 through SRS-194 | Covered by `SAD-061` through `SAD-070` | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date and preserved layer-specific traceability. | diff --git a/docs/architecture/sdd.md b/docs/architecture/sdd.md new file mode 100644 index 0000000..ea60748 --- /dev/null +++ b/docs/architecture/sdd.md @@ -0,0 +1,1027 @@ + +# Chanora SDD — Software Detailed Design + +**Document type:** SDD / Software Detailed Design +**Process alignment:** ASPICE SWE.3 Software Detailed Design and Unit Construction +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Lifecycle position:** `SysRS -> SysDes -> SRS -> SAD -> SDD` + +**Repo path:** `docs/architecture/sdd.md` --- + +## 1. Purpose + +This document defines detailed software design units, APIs, data structures, and implementation-level design rules for Chanora. + +The SDD derives from the SAD only. + +## 2. Strict Traceability Rules + +```text +SDD shall link directly to SAD only. +SDD shall not use direct software-requirement source IDs. +SDD shall not use direct system-design source IDs. +SDD shall not use direct system-requirement source IDs. +``` + +## 3. Software Unit Decomposition + +| Software Unit | Responsibility | +|---|---| +| `ChanoraApp` | Root application widget, initialization, theme mode, localization initialization | +| `ChanoraThemeFactory` | Builds ThemeData, ColorScheme, TextTheme, component themes | +| `ChanoraSemanticColors` | ThemeExtension for connection, voice, latency, diagnostic, and error states | +| `ChanoraSpacing` | ThemeExtension for spacing tokens | +| `ChanoraShape` | ThemeExtension for shape tokens | +| `ChanoraMotion` | ThemeExtension for motion tokens and reduced-motion behavior | +| `ChanoraAdaptiveShell` | Window class detection and shell layout selection | +| `CompactShell` | Single-column shell | +| `MediumShell` | Navigation rail / medium-width shell | +| `ExpandedShell` | Persistent pane shell | +| `ChanoraVoiceBar` | Persistent voice control component | +| `ChanoraChannelTree` | Hierarchical channel and client browser | +| `ChanoraClientTile` | Client row component | +| `ChanoraStatusBadge` | Accessible status indicator | +| `ChanoraAudioMeter` | Input level display | +| `LocalizationService` | Product-owned string localization and fallback | +| `ContentTextAdapter` | Server-provided text pass-through and display preparation | +| `UnicodeTextBoundary` | Boundary string validation and conversion helper | +| `PlatformInsetsService` | Safe area, keyboard, cutout, and desktop inset data | +| `BackIntentService` | Android/system back intent abstraction | +| `HapticsService` | Platform-aware haptic feedback wrapper | +| `BridgeFacade` | Flutter-to-Rust command and event facade | +| `CoreEventMapper` | Core-event-to-view-model mapping | +| `DiagnosticsTextPresenter` | Localized diagnostic descriptions and language-neutral event keys | +| `ArchitectureViewDocs` | Maintains context, container, component, runtime, deployment, and ADR architecture documentation | +| `DeploymentConfig` | Platform packaging and release configuration | +| `ArchitectureTraceChecker` | Checks direct-layer traceability rules for documentation | + + +## 4. SWE.3 Detailed Design Completeness Criteria + +The detailed design shall be sufficient to support implementation and unit verification. For each software unit, the SDD shall identify where applicable: + +| Detail | Required information | +|---|---| +| Unit responsibility | Purpose and boundaries of the unit | +| Inputs | Name, type, allowed range, default value, optionality | +| Outputs | Name, type, allowed range, default value, error behavior | +| Interfaces | Internal and external software interfaces | +| Dynamic behavior | State changes, sequence behavior, asynchronous behavior | +| Error behavior | Recoverable errors, fatal errors, fallback behavior | +| Resource behavior | Buffering, time-sensitive operations, memory expectations | +| Unit verification hooks | Test seams and expected verification approach | + +## 5. Software Unit Interface Detail Catalog + +| Unit | Interface | Direction | Name | Type | Unit | Resolution | Range | Default | Error / fallback | +|---|---|---:|---|---|---|---|---|---|---| +| `ChanoraThemeFactory` | Theme creation | Input | seedColor | Color value | n/a | n/a | valid color | Chanora default seed | fallback to default theme | +| `ChanoraThemeFactory` | Theme creation | Input | brightness | enum | n/a | n/a | light/dark | system setting | fallback to light | +| `ChanoraThemeFactory` | Theme creation | Output | themeData | ThemeData | n/a | n/a | valid ThemeData | n/a | construction error treated as app initialization failure | +| `ChanoraAdaptiveShell` | Window classification | Input | widthDp | double | dp | 1dp | >=0 | current window width | compact fallback | +| `ChanoraAdaptiveShell` | Window classification | Output | windowClass | enum | n/a | n/a | compact/medium/expanded | compact | compact fallback | +| `LocalizationService` | String lookup | Input | key | string | n/a | n/a | non-empty | n/a | fallback key display or English fallback | +| `LocalizationService` | String lookup | Input | locale | locale ID | n/a | n/a | supported locale | English | English fallback | +| `LocalizationService` | String lookup | Output | localizedText | UTF-8 string | n/a | n/a | valid Unicode | English fallback | missing-key diagnostic | +| `UnicodeTextBoundary` | Text validation | Input | rawText | external string/bytes | n/a | n/a | platform/protocol dependent | n/a | boundary conversion error | +| `UnicodeTextBoundary` | Text validation | Output | contentText | UTF-8 string | n/a | n/a | valid Unicode | replacement/failure policy | conversion diagnostic | +| `BridgeFacade` | Command bridge | Input | commandDto | DTO | n/a | n/a | valid command schema | n/a | bridge error DTO | +| `BridgeFacade` | Command bridge | Output | commandResult | DTO/result | n/a | n/a | success/error | n/a | typed error | +| `CoreEventMapper` | Event mapping | Input | coreEvent | event DTO | n/a | n/a | known event type | n/a | unknown event diagnostic | +| `CoreEventMapper` | Event mapping | Output | viewModelDelta | UI model delta | n/a | n/a | valid UI state change | n/a | safe no-op + diagnostic | +| `DiagnosticsTextPresenter` | Diagnostic presentation | Input | diagnosticKey | stable key | n/a | n/a | known/unknown key | n/a | generic localized fallback | +| `DiagnosticsTextPresenter` | Diagnostic presentation | Output | diagnosticText | localized string | n/a | n/a | valid Unicode | English fallback | fallback diagnostic text | +| `ChanoraAudioMeter` | Level display | Input | level | double | normalized | 0.01 | 0.0-1.0 | 0.0 | clamp to valid range | +| `ChanoraAudioMeter` | Level display | Output | semanticValue | localized string | n/a | n/a | valid string | "No input" | localized fallback | +| `BackIntentService` | Back handling | Input | platformBackEvent | platform event | n/a | n/a | platform-defined | n/a | ignored if unsupported | +| `BackIntentService` | Back handling | Output | backIntent | enum | n/a | n/a | pop/close/ignore/exitCandidate | ignore | safe no-op | + +## 6. Detailed Design Evaluation Checklist + +| Evaluation area | Question | +|---|---| +| Interoperability | Are interfaces compatible across units and layers? | +| Interaction | Are runtime interactions and asynchronous flows defined? | +| Criticality | Are critical voice, connection, security, and diagnostics behaviors detailed? | +| Technical complexity | Are complex units decomposed and testable? | +| Risks | Are platform, audio, protocol, encoding, and localization risks addressed? | +| Testability | Can unit tests, widget tests, integration tests, and platform tests be derived from the design? | +| Traceability | Does every detailed item link directly to SAD only? | +| Consistency | Are SAD, SDD, unit interfaces, and verification expectations consistent? | + + +## 7. Detailed Design Items + +**SDD-001**: `ChanoraApp` shall initialize theme, localization, platform services, and routing before rendering feature content. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraApp` +- Source SAD: SAD-001, SAD-031 +- Verification method: Unit Test, Integration Test + +Initialization order: platform bindings -> localization resources -> theme model -> app router -> adaptive shell. + +**SDD-002**: `ChanoraThemeFactory` shall create Material 3 ThemeData for light and dark modes. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraThemeFactory` +- Source SAD: SAD-001, SAD-002, SAD-043 +- Verification method: Unit Test + +The factory returns ThemeData instances with Material 3 enabled and populated ColorScheme and TextTheme values. + +**SDD-003**: `ChanoraThemeFactory` shall support seed-color replacement without feature-screen changes. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraThemeFactory` +- Source SAD: SAD-001, SAD-002, SAD-044 +- Verification method: Unit Test + +Seed color is injected into theme construction and not referenced in feature modules. + +**SDD-004**: `ChanoraSemanticColors` shall define connection state colors independently from base ColorScheme. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraSemanticColors` +- Source SAD: SAD-004, SAD-007 +- Verification method: Unit Test + +Connection tokens include connected, connecting, reconnecting, disconnected, and error roles. + +**SDD-005**: `ChanoraSemanticColors` shall define voice state colors independently from base ColorScheme. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraSemanticColors` +- Source SAD: SAD-005, SAD-007 +- Verification method: Unit Test + +Voice tokens include speaking, muted, deafened, push-to-talk-active, and unavailable roles. + +**SDD-006**: `ChanoraSemanticColors` shall define latency, packet-loss, diagnostics, and error semantic roles. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraSemanticColors` +- Source SAD: SAD-006, SAD-007 +- Verification method: Unit Test + +Token names remain semantic and shall not embed raw color names in API names. + +**SDD-007**: `ChanoraSpacing` shall define reusable spacing values for compact, medium, and expanded layouts. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraSpacing` +- Source SAD: SAD-002, SAD-003 +- Verification method: Unit Test + +Spacing APIs expose xs, sm, md, lg, xl, and xxl values. + +**SDD-008**: `ChanoraShape` shall define reusable corner and shape values for cards, buttons, panels, badges, and sheets. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraShape` +- Source SAD: SAD-002, SAD-003 +- Verification method: Unit Test + +Shape APIs expose none, small, medium, large, extraLarge, and full values. + +**SDD-009**: `ChanoraMotion` shall define standard durations and reduced-motion behavior. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraMotion` +- Source SAD: SAD-009 +- Verification method: Unit Test + +The unit maps reduced-motion settings to no-motion or simplified-motion behavior. + +**SDD-010**: Feature widgets shall read tokens through Flutter theme accessors only. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Feature Widgets` +- Source SAD: SAD-003, SAD-007 +- Verification method: Static Inspection + +Feature code may call Theme.of(context) and extension accessors, but shall not instantiate semantic tokens. + +**SDD-011**: `ChanoraAdaptiveShell` shall classify window width into compact, medium, or expanded. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraAdaptiveShell` +- Source SAD: SAD-008 +- Verification method: Unit Test + +Classification thresholds are centralized in the shell configuration. + +**SDD-012**: `ChanoraAdaptiveShell` shall dispatch to `CompactShell`, `MediumShell`, or `ExpandedShell`. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraAdaptiveShell` +- Source SAD: SAD-008, SAD-009, SAD-010, SAD-011 +- Verification method: Widget Test + +Layout selection shall be deterministic for a given window class. + +**SDD-013**: `CompactShell` shall render single-column content and mobile navigation. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `CompactShell` +- Source SAD: SAD-009 +- Verification method: Widget Test + +Compact layout shall avoid side-by-side pane requirements. + +**SDD-014**: `MediumShell` shall render side navigation or navigation rail behavior. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `MediumShell` +- Source SAD: SAD-010 +- Verification method: Widget Test + +Medium layout shall preserve main content and primary navigation. + +**SDD-015**: `ExpandedShell` shall render persistent pane regions and persistent voice controls. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ExpandedShell` +- Source SAD: SAD-011 +- Verification method: Widget Test + +Expanded layout shall support a side pane, main pane, and persistent VoiceBar slot. + +**SDD-016**: `ConnectionStatusPresenter` shall provide non-color-only connection state presentation data. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ConnectionStatusPresenter` +- Source SAD: SAD-012, SAD-014 +- Verification method: Unit Test + +The presenter returns label, icon, severity token, and accessibility description. + +**SDD-017**: `ChanoraVoiceBar` shall expose mute, deaf, push-to-talk, input meter, current channel, and latency properties. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraVoiceBar` +- Source SAD: SAD-013 +- Verification method: Widget Test + +VoiceBar properties are supplied from view models and shall not call Rust Core directly. + +**SDD-018**: `ChanoraVoiceBar` shall remain renderable as a persistent shell slot. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraVoiceBar` +- Source SAD: SAD-007, SAD-013 +- Verification method: Widget Test + +The component shall not depend on a specific route. + +**SDD-019**: `ChanoraChannelTree` shall support hierarchical channel nodes and client rows. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraChannelTree` +- Source SAD: SAD-003, SAD-006 +- Verification method: Widget Test + +The component consumes ChannelTreeVm data and supports expansion state. + +**SDD-020**: `ChanoraChannelTree` shall support selected state, expansion state, join intent, and context-menu intent. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraChannelTree` +- Source SAD: SAD-006, SAD-015 +- Verification method: Widget Test + +UI events are emitted through callbacks and view-model intents. + +**SDD-021**: `ChanoraClientTile` shall display client status with text, icon, and semantic state cues. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraClientTile` +- Source SAD: SAD-003, SAD-014 +- Verification method: Widget Test, Accessibility Test + +Client state shall not rely on color alone. + +**SDD-022**: `ChanoraStatusBadge` shall expose visible text or icon and accessibility semantics. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraStatusBadge` +- Source SAD: SAD-012, SAD-014 +- Verification method: Widget Test, Accessibility Test + +Badge states include normal, warning, error, speaking, muted, and disconnected. + +**SDD-023**: `ChanoraAudioMeter` shall display audio input level and support reduced-motion fallback. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ChanoraAudioMeter` +- Source SAD: SAD-009, SAD-013 +- Verification method: Widget Test + +Reduced-motion mode shall use simplified or static visual behavior. + +**SDD-024**: All icon-only buttons shall provide localized semantic labels. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Design System Components` +- Source SAD: SAD-014, SAD-020 +- Verification method: Accessibility Test + +Icon-only control constructors require label keys or semantic labels. + +**SDD-025**: Focusable components shall define focus order and visible focus style. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `FocusPolicy` +- Source SAD: SAD-015 +- Verification method: Widget Test + +Focus traversal shall be testable with keyboard navigation. + +**SDD-026**: Adaptive shell panes shall support increased text scale without losing critical actions. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Adaptive Shell Components` +- Source SAD: SAD-016 +- Verification method: Accessibility Test + +Critical controls shall wrap, scroll, or remain reachable. + +**SDD-027**: `PlatformInsetsService` shall provide safe area, keyboard inset, display cutout, and desktop inset data. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `PlatformInsetsService` +- Source SAD: SAD-017 +- Verification method: Platform Test + +Insets are consumed by shell layout rather than individual feature screens. + +**SDD-028**: `BackIntentService` shall normalize Android/system back behavior into route-level intents. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `BackIntentService` +- Source SAD: SAD-018 +- Verification method: Platform Test + +Back handling shall be testable without direct platform branching in feature screens. + +**SDD-029**: `HapticsService` shall expose platform-aware haptic feedback operations. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `HapticsService` +- Source SAD: SAD-019 +- Verification method: Platform Test + +Haptics calls are optional and shall no-op where unsupported. + +**SDD-030**: `KeyboardAvoidancePolicy` shall prevent critical controls from being covered by virtual keyboards. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `KeyboardAvoidancePolicy` +- Source SAD: SAD-017, SAD-019 +- Verification method: Platform Test + +Inputs and primary actions remain reachable when the virtual keyboard appears. + +**SDD-031**: `LocalizationService` shall load product string resources for the active locale. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `LocalizationService` +- Source SAD: SAD-020 +- Verification method: Unit Test + +The unit returns localized strings by key. + +**SDD-032**: `LocalizationService` shall fall back to the baseline English locale when a key is missing. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `LocalizationService` +- Source SAD: SAD-020 +- Verification method: Unit Test + +Fallback behavior is deterministic and logged for diagnostics. + +**SDD-033**: `LocalizationService` shall allow new locale resources without changes to protocol, audio, state, or storage modules. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `LocalizationService` +- Source SAD: SAD-020 +- Verification method: Inspection + +Locale resource registration is separated from non-UI software modules. + +**SDD-034**: `ContentTextAdapter` shall pass through server-provided names and messages without translation. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ContentTextAdapter` +- Source SAD: SAD-021 +- Verification method: Integration Test + +Server content is treated as user/server content rather than product copy. + +**SDD-035**: `UnicodeTextBoundary` shall validate cross-layer text DTOs as UTF-8 compatible strings. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `UnicodeTextBoundary` +- Source SAD: SAD-022, SAD-023 +- Verification method: Unit Test, Integration Test + +Invalid external encodings are handled at boundaries. + +**SDD-036**: Protocol-boundary conversion shall be implemented only in protocol adapter code. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Protocol Adapter Text Boundary` +- Source SAD: SAD-023 +- Verification method: Inspection + +No general Flutter feature code may perform protocol encoding conversion. + +**SDD-037**: Platform-boundary conversion shall be implemented only in platform adapter code. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Platform Adapter Text Boundary` +- Source SAD: SAD-023 +- Verification method: Inspection + +Platform-specific string conversion remains explicit and localized. + +**SDD-038**: Diagnostics export shall preserve Unicode after redaction. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `DiagnosticsTextPresenter` +- Source SAD: SAD-024 +- Verification method: Test, Audit + +Redaction removes secrets, not arbitrary multilingual content. + +**SDD-039**: Bidi text rendering shall use Flutter text widgets and directionality behavior compatible with platform support. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Flutter Text Presentation` +- Source SAD: SAD-025 +- Verification method: Localization Test + +Text rendering allows LTR and RTL content where supported. + +**SDD-040**: Locale-aware formatting shall be centralized in localization utilities. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `LocalizationFormatting` +- Source SAD: SAD-026 +- Verification method: Unit Test + +Dates, times, numbers, and timestamps are formatted by locale-aware helpers. + +**SDD-041**: Diagnostics event keys shall remain stable and language-neutral. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `DiagnosticsTextPresenter` +- Source SAD: SAD-027 +- Verification method: Unit Test + +User-facing descriptions are separate from machine-readable event keys. + +**SDD-042**: UI/UX supporting documents shall be versioned with the software architecture baseline. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Documentation Set` +- Source SAD: SAD-028 +- Verification method: Review + +Guidelines, token docs, component docs, adaptive docs, and platform docs are maintained as supporting baselines. + +**SDD-043**: SAD source validation shall reject direct lower-layer source fields. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Traceability Checker` +- Source SAD: SAD-029 +- Verification method: Inspection + +Automated or manual review checks SAD source fields. + +**SDD-044**: SDD source validation shall reject direct non-SAD source fields. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `Traceability Checker` +- Source SAD: SAD-030, SAD-045 +- Verification method: Inspection + +Automated or manual review checks SDD source fields. + +**SDD-045**: Theme/localization/platform initialization shall be tested before first feature render. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `App Initialization Tests` +- Source SAD: SAD-031 +- Verification method: Integration Test + +The app shell is tested for initialization order. + +**SDD-046**: Bridge facade DTOs shall expose only stable UI-safe data structures. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `BridgeFacade` +- Source SAD: SAD-040, SAD-041 +- Verification method: Integration Test + +Flutter must not depend on Rust internal types. + +**SDD-047**: Core event mapping shall convert Rust Core events into feature view models. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `CoreEventMapper` +- Source SAD: SAD-041 +- Verification method: Unit Test + +Event mapping is deterministic and testable. + +**SDD-048**: Audio state view models shall separate UI state from real-time audio processing. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `VoiceViewModel` +- Source SAD: SAD-034, SAD-039 +- Verification method: Unit Test + +Voice UI receives status values without performing DSP. + +**SDD-049**: Storage access shall be isolated from feature widgets behind repository or service APIs. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `StorageFacade` +- Source SAD: SAD-035 +- Verification method: Inspection + +Feature widgets shall not call database APIs directly. + +**SDD-050**: Diagnostics UI shall obtain localized display text from diagnostics presentation services. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `DiagnosticsTextPresenter` +- Source SAD: SAD-027, SAD-036, SAD-050 +- Verification method: Widget Test + +Diagnostics UI consumes display models. + +**SDD-051**: `ArchitectureViewDocs` shall maintain context, container, component, runtime, deployment, data, security, diagnostics, UI, audio, protocol, and i18n views. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `ArchitectureViewDocs` +- Source SAD: SAD-046, SAD-048, SAD-049, SAD-050 +- Verification method: Review + +Architecture views are updated when architecture-affecting changes occur. + +**SDD-052**: `ArchitectureViewDocs` shall maintain an ADR index for accepted, deprecated, and superseded architectural decisions. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `ArchitectureViewDocs` +- Source SAD: SAD-047 +- Verification method: Review + +ADR entries include decision, rationale, status, and impact. + +**SDD-053**: `DeploymentConfig` shall define platform-specific packaging and release configuration units. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `DeploymentConfig` +- Source SAD: SAD-049 +- Verification method: Inspection + +Deployment configuration separates platform package metadata from feature code. + +**SDD-054**: `DiagnosticsArchitecture` shall centralize logging, event keys, localized descriptions, redaction, and export presentation. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `DiagnosticsArchitecture` +- Source SAD: SAD-050 +- Verification method: Unit Test, Audit + +Diagnostics behavior is implemented through centralized services. + +**SDD-055**: `ArchitectureTraceChecker` shall check that SDD items reference only SAD IDs. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `ArchitectureTraceChecker` +- Source SAD: SAD-030, SAD-045 +- Verification method: Inspection + +A documentation check fails when non-SAD source IDs appear in SDD item source fields. + +**SDD-056**: `ArchitectureTraceChecker` shall check that SAD items reference only SRS IDs. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `ArchitectureTraceChecker` +- Source SAD: SAD-029 +- Verification method: Inspection + +A documentation check fails when non-SRS source IDs appear in SAD item source fields. + + + +**SDD-057**: `ArchitectureViewDocs` shall define reviewable architecture views for context, containers, components, runtime behavior, deployment, data, security, diagnostics, UI, audio, protocol, and i18n. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `ArchitectureViewDocs` +- Source SAD: SAD-046, SAD-051 +- Verification method: Review + +Each architecture view is maintained as part of the SAD baseline and referenced by the affected detailed design units. + +**SDD-058**: `ArchitectureViewDocs` shall define an ADR record structure with ID, title, status, decision, rationale, consequences, affected units, and change history. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `ArchitectureViewDocs` +- Source SAD: SAD-047 +- Verification method: Review + +ADR records support architecture communication and change impact analysis. + +**SDD-059**: `InterfaceDetailCatalog` shall refine SAD architectural interfaces into unit-level interface entries. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `InterfaceDetailCatalog` +- Source SAD: SAD-052, SAD-057 +- Verification method: Inspection + +Each entry includes name, type, unit, resolution, range, default value, and error/fallback behavior where applicable. + +**SDD-060**: `InterfaceDetailCatalog` shall define command, event, localization, Unicode, diagnostics, adaptive layout, audio meter, and platform-intent interfaces. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `InterfaceDetailCatalog` +- Source SAD: SAD-052, SAD-056, SAD-057 +- Verification method: Inspection + +The catalog supports integration and unit verification planning. + +**SDD-061**: `PerformanceDesignNotes` shall record UI responsiveness, audio latency, memory growth, reconnect, localization, and diagnostics resource considerations. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `PerformanceDesignNotes` +- Source SAD: SAD-053 +- Verification method: Review, Analysis + +Performance notes identify design mechanisms and verification hooks. + +**SDD-062**: `AssumptionRegister` shall record software design assumptions and dependencies that affect feasibility. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `AssumptionRegister` +- Source SAD: SAD-054 +- Verification method: Review + +Assumptions are reviewed during change impact analysis. + +**SDD-063**: `ArchitectureGlossary` shall provide definitions for architecture and detailed design terms. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P2 / Production +- Software unit: `ArchitectureGlossary` +- Source SAD: SAD-055 +- Verification method: Review + +The glossary reduces ambiguity across software architecture, detailed design, and verification. + +**SDD-064**: Each software unit detailed design shall include responsibility, inputs, outputs, interfaces, dynamic behavior, error behavior, resource behavior, and verification hooks where applicable. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `SoftwareUnitDesignTemplate` +- Source SAD: SAD-058, SAD-059 +- Verification method: Review, Inspection + +The template defines the minimum expected detail for unit construction and unit verification. + +**SDD-065**: `UnitConstructionGuideline` shall state that software units are constructed according to the SDD rather than reverse-documented from code. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `UnitConstructionGuideline` +- Source SAD: SAD-059 +- Verification method: Review + +The unit construction guideline preserves design-to-code traceability. + +**SDD-066**: `SoftwareUnitTraceChecker` shall verify that SDD items link directly to SAD IDs only. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `SoftwareUnitTraceChecker` +- Source SAD: SAD-030, SAD-045, SAD-060 +- Verification method: Inspection + +The checker supports traceability rule enforcement. + +**SDD-067**: `SoftwareUnitTraceChecker` shall support impact analysis from changed SAD items to affected SDD items. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `SoftwareUnitTraceChecker` +- Source SAD: SAD-060 +- Verification method: Inspection + +Impact analysis output identifies affected detailed design units. + +**SDD-068**: `DetailedDesignReviewRecord` shall capture review evidence for SDD completeness, testability, and consistency with SAD. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `DetailedDesignReviewRecord` +- Source SAD: SAD-059, SAD-060 +- Verification method: Review + +Review records support baseline approval and communication. + +**SDD-069**: `UnitVerificationHandoff` shall identify verification method candidates for each software unit. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `UnitVerificationHandoff` +- Source SAD: SAD-059 +- Verification method: Review + +The handoff supports unit verification planning. + +**SDD-070**: `SoftwareUnitRegistry` shall maintain the list of software units, their owning component, source SAD items, and implementation status. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `SoftwareUnitRegistry` +- Source SAD: SAD-058, SAD-060 +- Verification method: Inspection + +The registry supports consistency between architecture, detailed design, implementation, and verification. + + +## 8. SAD-to-SDD Coverage Matrix + +| SAD Range | SDD Coverage | +|---|---| +| SAD-001 through SAD-007 | SDD-001 through SDD-010 | +| SAD-008 through SAD-011 | SDD-011 through SDD-015 | +| SAD-012 through SAD-016 | SDD-016 through SDD-026 | +| SAD-017 through SAD-019 | SDD-027 through SDD-030 | +| SAD-020 through SAD-027 | SDD-031 through SDD-041 | +| SAD-028 through SAD-031 | SDD-042 through SDD-045 | +| SAD-032 through SAD-038 | SDD-046 through SDD-050 | +| SAD-039 through SAD-045 | SDD-046 through SDD-050, SDD-055, SDD-056 | +| SAD-046 through SAD-050 | SDD-051 through SDD-058, SDD-061 | +| SAD-051 through SAD-060 | SDD-057 through SDD-070 | + +## 9. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial SDD baseline covering SAD-001 through SAD-045 and enforcing SAD-only direct traceability. | +| 0.2.0 | 2026-05-14 | Updated SDD coverage for expanded SAD v0.2 architecture views, ADRs, deployment architecture, diagnostics architecture, and traceability checker units. | +| 0.3.0 | 2026-05-14 | Added SWE.3 detailed-design completeness criteria, unit interface detail catalog, evaluation checklist, unit construction guideline, and additional SAD coverage. | + +--- + +## 10. Platform Baseline and Product Decision Detailed Design Addendum + +**SDD-071**: `IOSBuildConfig` shall define the iOS minimum runtime deployment target as iOS 13 unless an approved platform change raises it. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `IOSBuildConfig` +- Source SAD: SAD-061 +- Verification method: Inspection, Platform Test + +**SDD-072**: `IOSReleaseGate` shall verify that App Store Connect upload builds use Xcode 26 or later and the iOS 26 / iPadOS 26 SDK or later on or after 2026-04-28 unless Apple publishes a newer applicable upload requirement. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `IOSReleaseGate` +- Source SAD: SAD-062 +- Verification method: Release Inspection + +**SDD-073**: `AndroidBuildConfig` shall define Android API 24 as the minimum Android runtime baseline and shall expose target SDK configuration for release inspection. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `AndroidBuildConfig` +- Source SAD: SAD-063 +- Verification method: Platform Test, Release Inspection + +**SDD-074**: `ConnectionSessionManager` shall enforce a single active server connection in MVP. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `ConnectionSessionManager` +- Source SAD: SAD-064 +- Verification method: Unit Test, System Test + +**SDD-075**: `AudioProcessingSettings` shall default AEC, AGC, Noise Suppression, and High-Pass Filter to enabled where supported and stable. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `AudioProcessingSettings` +- Source SAD: SAD-065 +- Verification method: Unit Test, Audio Test + +**SDD-076**: `AudioProcessingBackendSelector` shall select platform-native audio processing first where available and stable and isolate any fallback backend behind the audio subsystem interface. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P1 / Beta +- Software unit: `AudioProcessingBackendSelector` +- Source SAD: SAD-066 +- Verification method: Unit Test, Audio Test + +**SDD-077**: `LocalDatabaseRepository` shall persist non-secret local state through SQLite or an equivalent embedded database abstraction. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `LocalDatabaseRepository` +- Source SAD: SAD-067 +- Verification method: Unit Test, Storage Test + +**SDD-078**: `SecretStorageRepository` shall persist secrets only through platform secure storage service interfaces. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `SecretStorageRepository` +- Source SAD: SAD-067 +- Verification method: Unit Test, Security Audit + +**SDD-079**: `TypedBridgeFacade` shall define generated or schema-controlled DTOs for Flutter/Rust commands, results, and events. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `TypedBridgeFacade` +- Source SAD: SAD-068 +- Verification method: Integration Test, Inspection + +**SDD-080**: `DiagnosticsPrivacyGate` shall disable automatic diagnostic upload, telemetry upload, and crash reporting in MVP release configuration unless an approved decision enables them. + +- Status: Draft +- Type: Software Detailed Design Item +- Stage: P0 / MVP +- Software unit: `DiagnosticsPrivacyGate` +- Source SAD: SAD-069, SAD-070 +- Verification method: Privacy Review, Security Audit + +## 11. Updated SAD-to-SDD Coverage Matrix + +| SAD Range | SDD Coverage | +|---|---| +| SAD-001 through SAD-060 | Covered by inherited SDD baseline `SDD-001` through `SDD-070` | +| SAD-061 through SAD-070 | Covered by `SDD-071` through `SDD-080` | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date and preserved layer-specific traceability. | diff --git a/docs/architecture/sysdes.md b/docs/architecture/sysdes.md new file mode 100644 index 0000000..1f3c995 --- /dev/null +++ b/docs/architecture/sysdes.md @@ -0,0 +1,2792 @@ +# 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.2 +**Status:** Baseline Candidate +**Input baseline:** Chanora SysRS v0.6 +**Target application type:** Cross-platform voice client application system +**Target client platforms:** Windows, macOS, Linux, iOS, Android +**Architecture baseline:** Flutter + Rust Core + `tsclientlib` protocol adapter + +**Repo path:** `docs/architecture/sysdes.md` --- + +## 1. Document Control + +### 1.1 Purpose + +This document defines the **system architectural design** for the Chanora application system. + +Chanora is an application, not an operating system. In this document, the word **system** means the complete Chanora application system and its runtime environment: the installed client application, operating system services, client device hardware, audio devices, network environment, external TeamSpeak 3-compatible servers, deployment environment, diagnostics, and engineering evidence. + + +**SysDes-001**: This SysDes shall establish the Chanora system architectural design and allocate all SysRS requirements to system elements. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 overall purpose, BP1, BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-002**: This SysDes shall treat Chanora as a cross-platform application system, not as an operating system. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 system boundary +- Allocated SysRS: SysRS-001, SysRS-006 through SysRS-010 + +**SysDes-003**: This SysDes shall be used as the system-level design baseline for downstream SRS, SAD, SDD, and Verification artifacts. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 communication and traceability +- Allocated SysRS: SysRS-233 through SysRS-240 + + +### 1.2 ASPICE SYS.3 Document Intent + +This SysDes is structured around the ASPICE SYS.3 intent: + +- Define static aspects of the system architecture. +- Define dynamic aspects of the system architecture. +- Analyze the system architecture and record design rationale. +- Ensure consistency and bidirectional traceability between SysRS and SysDes. +- Communicate the agreed system architecture to affected parties. + +This document is an ASPICE-style engineering artifact for Chanora. It does not claim formal Automotive SPICE assessment certification. + + +**SysDes-004**: The SysDes structure shall provide evidence for static architecture, dynamic architecture, architecture analysis, bidirectional traceability, consistency, and architecture communication. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP1 through BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + + +### 1.3 Downstream Lifecycle Relationship + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification +``` + +| Lifecycle artifact | Role | +|---|---| +| SysRS | Defines system-level requirements and runtime environment requirements. | +| SysDes | Allocates SysRS requirements to system elements and defines system architecture. | +| SRS | Derives software-only requirements from software-impacting SysDes items. SysRS traceability is inherited through SysDes and shall not be used as the direct source of an SRS requirement. | +| SAD | Defines software architecture for software elements. | +| SDD | Defines detailed module, interface, data, and implementation design. | +| Verification | Proves requirements and designs through the chained relationship `SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification`. | + + + +### 1.4 SysDes Design Item Attribute Model + +Every `SysDes-XXX` design item shall include the following attributes. + +| Attribute | Meaning | Typical values | +|---|---|---| +| Status | Maturity of the design item | Draft, Baseline, Agreed, Deprecated | +| Type | Design item classification | Functional Dynamic Design, Non-functional Architecture Design, Interface Design, Static Architecture Design, System Element Allocation, Architectural Constraint, Architecture Decision / Rationale, Allocation Rule, Process / Description, Verification Handoff | +| Stage | Delivery stage where the design item must be satisfied | P0 / MVP, P1 / Beta, P2 / Production, P3 / Future | +| Allocated to | System element or responsibility owner that implements/enables the design item | Software, Platform, Hardware, Network, External Server, Deployment / Operations, Product / Legal, Verification | +| Downstream artifact | Lifecycle artifact that must refine or consume this design item | SRS, SAD, SDD, Verification | +| Verification method | How the design item will be verified | Review, Inspection, Analysis, Test, Integration Test, System Test, Demo, Audit | +| Verification owner | Role primarily responsible for verification evidence | System Engineering, Software QA, Audio / Platform QA, Protocol / Integration QA, Security / QA, Release / Operations QA | +| ASPICE SYS.3 alignment | Related ASPICE SYS.3 intent or base practice area | Static architecture, dynamic architecture, analysis, traceability/consistency, communication | +| Allocated SysRS | Upstream SysRS requirement IDs covered by the SysDes design item. This attribute is for SysDes-level traceability only and shall not be copied as the direct source of an SRS requirement. | `SysRS-001`, ranges, or grouped IDs | +| SWE.1 handoff rule | Indicates how downstream SRS shall consume the SysDes item | Direct software requirement input, software-facing constraint, verification input, non-software assumption, or no SWE.1 handoff | + +Important allocation and downstream traceability rules: + +- `Allocated to` identifies the system element or engineering responsibility that realizes the design item. +- `Verification owner` identifies who proves that the design item is satisfied. +- `Test` is normally a verification responsibility, not the implementation allocation, except for explicit verification-handoff items. +- `Allocated SysRS` belongs to SysDes only. It provides SysRS-to-SysDes traceability required by system architectural design. +- Downstream SRS requirements shall use `Source SysDes` as their direct upstream reference. +- Downstream SRS requirements shall not use `Source SysRS` as their direct upstream reference. +- If a software requirement appears to come directly from SysRS and cannot be derived from an existing SysDes item, the SysDes is incomplete and shall be updated before the SRS is baselined. + + +### 1.5 Downstream SRS Derivation Rule + +The SysDes is the architectural allocation layer between SysRS and SRS. + +Correct downstream traceability: + +```text +SysRS-XXX -> SysDes-YYY -> SRS-ZZZ +``` + +Incorrect downstream traceability: + +```text +SysRS-XXX -> SRS-ZZZ +``` + +The SRS shall not reinterpret system requirements directly. It shall derive software requirements from SysDes design items that are allocated to software, contain software-facing constraints, or provide verification handoff for software behavior. + +If the software team identifies a required software behavior directly from SysRS and no SysDes design item represents it, this is a SysDes gap. The correction shall be made in SysDes first, then the SRS shall be updated from the corrected SysDes baseline. + + +## 2. ASPICE SYS.3 Alignment + +### 2.1 SYS.3 Work Products in This Document + +| ASPICE SYS.3 evidence need | Location in this SysDes | +|---|---| +| System architectural design | Sections 4 through 12 | +| Interface definitions | Section 6 | +| Dynamic behavior | Section 7 | +| Requirements allocation | Section 10 and Appendix A | +| Bidirectional traceability | Section 10 and Appendix A | +| Architecture analysis and rationale | Section 8 | +| Communication and review evidence | Section 11 | +| Verification handoff | Section 12 | + + +**SysDes-005**: The SysDes shall identify system elements, their responsibilities, their relationships, and their external interfaces. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1 static aspects +- Allocated SysRS: SysRS-024 through SysRS-034, SysRS-200 through SysRS-210 + +**SysDes-006**: The SysDes shall describe dynamic behavior for connection, synchronization, voice transmission, voice reception, text messaging, reconnect, permissions, diagnostics, and release operation. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 dynamic aspects +- Allocated SysRS: SysRS-102 through SysRS-120, SysRS-129 through SysRS-139 + +**SysDes-007**: The SysDes shall include architecture analysis, major design rationale, known risks, mitigations, and special characteristics. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 analysis +- Allocated SysRS: SysRS-178 through SysRS-191, SysRS-219 through SysRS-224 + +**SysDes-008**: The SysDes shall maintain bidirectional traceability between every SysRS requirement and at least one allocated system element. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 traceability and consistency +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-009**: The SysDes shall identify affected parties for review, agreement, and communication of the system architecture. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP5 communication +- Allocated SysRS: SysRS-011 through SysRS-015, SysRS-233 through SysRS-240 + + +## 3. System Architectural Design Criteria + +The architecture is evaluated against the following criteria. + + +**SysDes-010**: The architecture shall separate user interface, protocol logic, state synchronization, audio processing, storage, diagnostics, and platform-specific services. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-003, SysRS-004, SysRS-024 through SysRS-034 + +**SysDes-011**: The architecture shall isolate direct `tsclientlib` usage inside the protocol adapter. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-005, SysRS-121 through SysRS-128 + +**SysDes-012**: The architecture shall support required target platforms through shared Flutter UI, shared Rust Core, and platform-specific adapters. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-002, SysRS-048 through SysRS-058 + +**SysDes-013**: The architecture shall support production-grade audio processing including Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2, BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-250 through SysRS-253 + +**SysDes-014**: The architecture shall support real-time voice behavior without placing real-time audio processing in Flutter UI. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2, BP3 +- Allocated SysRS: SysRS-178 through SysRS-191 + +**SysDes-015**: The architecture shall support secure local handling of identities, passwords, and diagnostics. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-140 through SysRS-167 + +**SysDes-016**: The architecture shall support operation without a Chanora-operated central backend in MVP. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-016 through SysRS-023 + +**SysDes-017**: The architecture shall provide traceable verification hooks for protocol, state, audio, security, packaging, and platform behavior. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-233 through SysRS-257 + + +## 4. Static System Architecture + +### 4.1 System Context + +```text ++-------------------------------------------------------------------------------------+ +| User Runtime Environment | +| | +| +--------------------+ +--------------------------------------------------+ | +| | User / Operator |<----->| Chanora Client Application | | +| +--------------------+ | | | +| | +----------------+ +-------------------------+ | | +| +--------------------+ | | Flutter UI | | Rust Core | | | +| | Audio Hardware |<----->| | Flutter State | | Connection Manager | | | +| | Mic / Headset | | | Bridge Layer | | Protocol / State / | | | +| | Speaker / BT | | +----------------+ | Audio / Storage / Diag | | | +| +--------------------+ | +-------------------------+ | | +| | | | | +| +--------------------+ | +------------------------------v----------------+ | | +| | OS Services |<----->| | Platform Adapters / Secure Storage / Audio | | | +| +--------------------+ | +------------------------------------------------+ | | +| +-------------------------|------------------------+ | +| | Network | ++---------------------------------------------------------|-----------------------------+ + v + +--------------------------------------------------+ + | External TeamSpeak 3-compatible Voice Server | + | Channels / Clients / Voice / Text / Events | + +--------------------------------------------------+ +``` + + +**SysDes-018**: The static architecture shall define Chanora as a client application system interacting with users, audio hardware, OS services, networks, deployment environments, and external compatible voice servers. + +- Status: Baseline +- Type: Static Architecture Description +- Stage: P0 / MVP +- Allocated to: External Server, Software: Audio Subsystem, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-001 through SysRS-023 + + +### 4.2 System Elements + +| Element ID | Element | Description | Type | +|---|---|---|---| + +| SE-01 | User and Operator | Human users who operate Chanora, provide server details, manage permissions, and initiate diagnostic export. | External actor | + +| SE-02 | Client Device Hardware | Physical device running Chanora, including CPU, memory, storage, network interfaces, microphone, speaker/headphone, and optional Bluetooth/USB audio devices. | External runtime element | + +| SE-03 | Operating System Services | OS services used by Chanora: permissions, secure storage, audio stack, network stack, notifications, windowing, lifecycle, foreground service, app sandboxing, signing/runtime policies. | External runtime element | + +| SE-04 | Network Environment | IP network path between client and external compatible server, including DNS, routing, NAT, firewall, VPN, Wi-Fi, cellular, and ISP behavior. | External runtime element | + +| SE-05 | External Compatible Voice Server | TeamSpeak 3-compatible external server providing channels, clients, identity authentication, voice packets, text messages, permissions, and events. | External system | + +| SE-06 | Chanora Application Container | Installed Chanora client application package on each target platform. Owns app lifecycle at the application boundary. | System element | + +| SE-07 | Flutter UI Layer | Cross-platform user interface for connection, channel tree, chat, voice controls, settings, permissions, and diagnostics. | Software system element | + +| SE-08 | Flutter State Layer | UI-facing state model derived from Rust Core events and snapshots; owns only presentation state. | Software system element | + +| SE-09 | Flutter-Rust Bridge Layer | Generated/native bridge for commands, DTOs, asynchronous calls, event streams, and error propagation between Flutter and Rust Core. | Software system element | + +| SE-10 | Rust Core and Connection Manager | Authoritative application core coordinating connection actors, commands, events, storage, audio, diagnostics, and business rules. | Software system element | + +| SE-11 | Protocol Adapter using tsclientlib | Protocol subsystem wrapping `tsclientlib`, isolating protocol library types, errors, events, and voice packet operations. | Software system element | + +| SE-12 | State Synchronization Engine | Snapshot + delta state model, deterministic reducers, connection state machine, event ordering, and replayable state behavior. | Software system element | + +| SE-13 | Audio Subsystem | Capture/playback coordination, Opus-compatible encoding/decoding, jitter buffer, mixer, push-to-talk, mute/deaf, level metering, and required processing features. | Software system element | + +| SE-14 | Platform Adapter Layer | Platform-specific adapters for audio devices, permissions, lifecycle, notifications, secure storage integration, and release-specific services. | Software/platform system element | + +| SE-15 | Local Data Store | Embedded local database or equivalent storage for bookmarks, recent servers, audio settings, UI settings, per-user volume and mute preferences. | Software/data system element | + +| SE-16 | Secure Storage Provider | Platform secure storage integration for identity private keys, server passwords, and future sensitive tokens. | Software/platform system element | + +| SE-17 | Diagnostics and Observability | Structured logs, redaction, event recording, event replay, network diagnostics, audio diagnostics, diagnostic bundle export. | Software/process support element | + +| SE-18 | Deployment and Release Environment | Packaging, signing, notarization, app-store release, installers, Linux packages, CI/CD, release metadata, and distribution artifacts. | Operational system element | + +| SE-19 | Engineering Process and Evidence | Architecture reviews, traceability records, verification evidence, compatibility matrix, open decisions, and downstream SRS/SAD/SDD/Verification artifacts. | Process/evidence element | + + + +### 4.3 Element Responsibilities and Allocation Rationale + + +**SysDes-019**: SE-01 User and Operator shall be a defined system element in the Chanora architecture with responsibility for: Human users who operate Chanora, provide server details, manage permissions, and initiate diagnostic export. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: User / Operator, Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-011 through SysRS-015, SysRS-102 through SysRS-120 + +**SysDes-020**: SE-02 Client Device Hardware shall be a defined system element in the Chanora architecture with responsibility for: Physical device running Chanora, including CPU, memory, storage, network interfaces, microphone, speaker/headphone, and optional Bluetooth/USB audio devices. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Hardware, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-035 through SysRS-047, SysRS-178 through SysRS-191 + +**SysDes-021**: SE-03 Operating System Services shall be a defined system element in the Chanora architecture with responsibility for: OS services used by Chanora: permissions, secure storage, audio stack, network stack, notifications, windowing, lifecycle, foreground service, app sandboxing, signing/runtime policies. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Platform, Software: Audio Subsystem, Platform Secure Storage +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-048 through SysRS-058, SysRS-153 through SysRS-167 + +**SysDes-022**: SE-04 Network Environment shall be a defined system element in the Chanora architecture with responsibility for: IP network path between client and external compatible server, including DNS, routing, NAT, firewall, VPN, Wi-Fi, cellular, and ISP behavior. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Network +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-075 through SysRS-087 + +**SysDes-023**: SE-05 External Compatible Voice Server shall be a defined system element in the Chanora architecture with responsibility for: TeamSpeak 3-compatible external server providing channels, clients, identity authentication, voice packets, text messages, permissions, and events. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: External Server, Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-088 through SysRS-101 + +**SysDes-024**: SE-06 Chanora Application Container shall be a defined system element in the Chanora architecture with responsibility for: Installed Chanora client application package on each target platform. Owns app lifecycle at the application boundary. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software, Platform +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-001 through SysRS-010, SysRS-225 through SysRS-232 + +**SysDes-025**: SE-07 Flutter UI Layer shall be a defined system element in the Chanora architecture with responsibility for: Cross-platform user interface for connection, channel tree, chat, voice controls, settings, permissions, and diagnostics. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-003, SysRS-102 through SysRS-120, SysRS-200 through SysRS-206 + +**SysDes-026**: SE-08 Flutter State Layer shall be a defined system element in the Chanora architecture with responsibility for: UI-facing state model derived from Rust Core events and snapshots; owns only presentation state. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Flutter State, Software: Rust Core, Software: State Sync +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-024 through SysRS-034, SysRS-129 through SysRS-139 + +**SysDes-027**: SE-09 Flutter-Rust Bridge Layer shall be a defined system element in the Chanora architecture with responsibility for: Generated/native bridge for commands, DTOs, asynchronous calls, event streams, and error propagation between Flutter and Rust Core. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-024 through SysRS-034, SysRS-200 through SysRS-210 + +**SysDes-028**: SE-10 Rust Core and Connection Manager shall be a defined system element in the Chanora architecture with responsibility for: Authoritative application core coordinating connection actors, commands, events, storage, audio, diagnostics, and business rules. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-004, SysRS-102 through SysRS-139, SysRS-178 through SysRS-191 + +**SysDes-029**: SE-11 Protocol Adapter using tsclientlib shall be a defined system element in the Chanora architecture with responsibility for: Protocol subsystem wrapping `tsclientlib`, isolating protocol library types, errors, events, and voice packet operations. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-005, SysRS-088 through SysRS-128, SysRS-241 + +**SysDes-030**: SE-12 State Synchronization Engine shall be a defined system element in the Chanora architecture with responsibility for: Snapshot + delta state model, deterministic reducers, connection state machine, event ordering, and replayable state behavior. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-129 through SysRS-139, SysRS-233 through SysRS-240 + +**SysDes-031**: SE-13 Audio Subsystem shall be a defined system element in the Chanora architecture with responsibility for: Capture/playback coordination, Opus-compatible encoding/decoding, jitter buffer, mixer, push-to-talk, mute/deaf, level metering, and required processing features. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-178 through SysRS-191, SysRS-242 through SysRS-253 + +**SysDes-032**: SE-14 Platform Adapter Layer shall be a defined system element in the Chanora architecture with responsibility for: Platform-specific adapters for audio devices, permissions, lifecycle, notifications, secure storage integration, and release-specific services. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-048 through SysRS-074, SysRS-153 through SysRS-167 + +**SysDes-033**: SE-15 Local Data Store shall be a defined system element in the Chanora architecture with responsibility for: Embedded local database or equivalent storage for bookmarks, recent servers, audio settings, UI settings, per-user volume and mute preferences. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Software: Storage +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-140 through SysRS-152, SysRS-255 + +**SysDes-034**: SE-16 Secure Storage Provider shall be a defined system element in the Chanora architecture with responsibility for: Platform secure storage integration for identity private keys, server passwords, and future sensitive tokens. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Platform Secure Storage +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-140 through SysRS-167, SysRS-256 + +**SysDes-035**: SE-17 Diagnostics and Observability shall be a defined system element in the Chanora architecture with responsibility for: Structured logs, redaction, event recording, event replay, network diagnostics, audio diagnostics, diagnostic bundle export. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-168 through SysRS-177, SysRS-257 + +**SysDes-036**: SE-18 Deployment and Release Environment shall be a defined system element in the Chanora architecture with responsibility for: Packaging, signing, notarization, app-store release, installers, Linux packages, CI/CD, release metadata, and distribution artifacts. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Software: Storage, Deployment / Operations +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Release / Operations QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-192 through SysRS-199 + +**SysDes-037**: SE-19 Engineering Process and Evidence shall be a defined system element in the Chanora architecture with responsibility for: Architecture reviews, traceability records, verification evidence, compatibility matrix, open decisions, and downstream SRS/SAD/SDD/Verification artifacts. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP1, BP4 +- Allocated SysRS: SysRS-233 through SysRS-240, SysRS-219 through SysRS-224 + + +### 4.4 Layered Static Decomposition + +```text ++-------------------------------------------------------------+ +| SE-07 Flutter UI Layer | ++-------------------------------------------------------------+ +| SE-08 Flutter State Layer | ++-------------------------------------------------------------+ +| SE-09 Flutter-Rust Bridge Layer | ++-------------------------------------------------------------+ +| SE-10 Rust Core and Connection Manager | +| + SE-11 Protocol Adapter using tsclientlib | +| + SE-12 State Synchronization Engine | +| + SE-13 Audio Subsystem | +| + SE-15 Local Data Store | +| + SE-16 Secure Storage Provider | +| + SE-17 Diagnostics and Observability | ++-------------------------------------------------------------+ +| SE-14 Platform Adapter Layer | ++-------------------------------------------------------------+ +| External Runtime Elements: SE-02, SE-03, SE-04, SE-05 | ++-------------------------------------------------------------+ +``` + + +**SysDes-038**: The architecture shall use a layered decomposition in which Flutter UI and Flutter State Layer communicate with Rust Core only through the Bridge Layer. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-003, SysRS-024 through SysRS-034, SysRS-200 through SysRS-210 + +**SysDes-039**: The architecture shall place protocol, state synchronization, audio processing, storage coordination, diagnostics, and business rules inside Rust Core or Rust Core-owned elements. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-004, SysRS-024 through SysRS-034 + +**SysDes-040**: The architecture shall prevent Flutter UI and Flutter State Layer from invoking `tsclientlib` or depending on raw `tsclientlib` types. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-005, SysRS-121 through SysRS-128, SysRS-211 + +**SysDes-041**: The architecture shall place real-time audio processing outside Flutter UI and inside the Rust Core audio subsystem or platform-native audio processing adapters. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-178 through SysRS-191 + + +## 5. System Requirement Allocation Strategy + +### 5.1 Allocation Rules + + +**SysDes-042**: Every SysRS requirement shall be allocated to at least one system element. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-043**: A SysRS requirement may be allocated to multiple system elements when the requirement depends on cooperation between application software, OS services, hardware, network, external server, deployment, or engineering evidence. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: External Server, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-044**: Functional user-facing requirements shall be allocated to Flutter UI, Rust Core, and the relevant subsystem element that executes the behavior. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-102 through SysRS-120 + +**SysDes-045**: Runtime environment requirements shall be allocated to client device hardware, operating system services, platform adapters, network environment, or external compatible server elements. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Hardware, Platform, Network +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-035 through SysRS-101 + +**SysDes-046**: Security, privacy, and diagnostics requirements shall be allocated to secure storage, diagnostics, platform adapters, and engineering process evidence. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-153 through SysRS-177 + +**SysDes-047**: MVP acceptance requirements shall be allocated to the system elements that implement or enable the accepted behavior. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-241 through SysRS-257 + + +### 5.2 Allocation Summary by Requirement Group + +| SysRS Range | Requirement Topic | Primary System Elements | +|---|---|---| +| SysRS-001 through SysRS-010 | Application system scope | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16 | +| SysRS-011 through SysRS-015 | Stakeholders and user environment | SE-01, SE-07, SE-17, SE-19 | +| SysRS-016 through SysRS-023 | Boundaries and external dependencies | SE-03, SE-04, SE-05, SE-14, SE-18 | +| SysRS-024 through SysRS-034 | Application components | SE-06 through SE-17 | +| SysRS-035 through SysRS-047 | Client device and hardware | SE-02, SE-03, SE-04, SE-13, SE-14 | +| SysRS-048 through SysRS-058 | Operating system services | SE-03, SE-14, SE-18 | +| SysRS-059 through SysRS-074 | Audio hardware and processing | SE-02, SE-03, SE-13, SE-14 | +| SysRS-075 through SysRS-087 | Network environment | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | +| SysRS-088 through SysRS-101 | External compatible server | SE-05, SE-11, SE-12, SE-13 | +| SysRS-102 through SysRS-120 | Application functional behavior | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16 | +| SysRS-121 through SysRS-128 | Protocol integration | SE-11, SE-19 | +| SysRS-129 through SysRS-139 | State synchronization | SE-10, SE-12, SE-09, SE-19 | +| SysRS-140 through SysRS-152 | Data and storage | SE-15, SE-16, SE-17, SE-14 | +| SysRS-153 through SysRS-167 | Security and privacy | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | +| SysRS-168 through SysRS-177 | Diagnostics and operations | SE-17, SE-19 | +| SysRS-178 through SysRS-191 | Non-functional requirements | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | +| SysRS-192 through SysRS-199 | Deployment and release | SE-18, SE-19 | +| SysRS-200 through SysRS-210 | Interfaces | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11, SE-13, SE-14, SE-15, SE-16, SE-17 | +| SysRS-211 through SysRS-218 | Constraints | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | +| SysRS-219 through SysRS-224 | Assumptions | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19 | +| SysRS-225 through SysRS-232 | Out of scope for MVP | SE-06, SE-13, SE-19 | +| SysRS-233 through SysRS-240 | Verification and validation | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | +| SysRS-241 through SysRS-257 | MVP acceptance | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | + + +## 6. Interface Definitions + +### 6.1 Interface Catalogue + +| Interface ID | Interface | Provider | Consumer | Main Data / Signals | Failure Handling | +|---|---|---|---|---|---| +| IF-001 | User Interface | SE-07 | SE-01 | UI events, status, forms, controls, errors | UI-safe error banner/dialog | +| IF-002 | Flutter State Interface | SE-08 | SE-07 | View models, UI state, derived lists | State reset or stale-state overlay | +| IF-003 | Flutter-Rust Command Interface | SE-09 | SE-07/SE-08 | Commands, DTOs, request IDs | Error DTO, timeout, cancellation | +| IF-004 | Rust Core Event Interface | SE-10/SE-09 | SE-08 | Core events, snapshots, deltas | Stream reconnect/resubscribe | +| IF-005 | Protocol Adapter Interface | SE-11 | SE-10 | Connect, join, message, voice, events | ProtocolError mapping | +| IF-006 | External Server Protocol Interface | SE-05 | SE-11 | TeamSpeak-compatible protocol traffic | Network/protocol error mapping | +| IF-007 | Audio Capture Interface | SE-14/SE-03/SE-02 | SE-13 | PCM frames, device events | Device error, fallback, mute | +| IF-008 | Audio Playback Interface | SE-13 | SE-14/SE-03/SE-02 | Mixed PCM frames, route state | Device error, fallback, deaf | +| IF-009 | Secure Storage Interface | SE-16/SE-03 | SE-10/SE-15 | Identity secrets, passwords | SecureStoreError, user re-auth | +| IF-010 | Local Data Store Interface | SE-15 | SE-10/SE-07 | Bookmarks, recent servers, settings | StorageError, repair/migration | +| IF-011 | Diagnostics Export Interface | SE-17 | SE-01/SE-19 | Redacted diagnostic bundle | Export failure message | +| IF-012 | Deployment Interface | SE-18 | SE-01/SE-03 | Installer/package/app-store artifact | Platform installer/store error | +| IF-013 | Network Interface | SE-04 | SE-11/SE-17 | IP connectivity, DNS, latency, packet loss | Reconnect or user-safe error | +| IF-014 | Permission Interface | SE-03/SE-14 | SE-07/SE-10 | Microphone, notification, foreground service | Permission explainer and blocked state | + +**SysDes-048**: IF-001 User Interface shall expose connection, bookmark, channel tree, online client, chat, voice control, audio setting, permission, and diagnostic workflows. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-102 through SysRS-120, SysRS-200 through SysRS-206 + +**SysDes-049**: IF-003 Flutter-Rust Command Interface shall use bridge-safe DTOs and shall not expose raw protocol or `tsclientlib` types. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Bridge, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-121 through SysRS-128, SysRS-200 through SysRS-210 + +**SysDes-050**: IF-004 Rust Core Event Interface shall deliver connection status, snapshots, deltas, voice indicators, errors, and diagnostic events as typed streams. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2 +- Allocated SysRS: SysRS-129 through SysRS-139 + +**SysDes-051**: IF-005 Protocol Adapter Interface shall isolate all direct `tsclientlib` operations and convert protocol data into Chanora internal data structures. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-121 through SysRS-128 + +**SysDes-052**: IF-006 External Server Protocol Interface shall use `tsclientlib` to communicate with reachable TeamSpeak 3-compatible external servers. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: External Server, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-005, SysRS-088 through SysRS-101 + +**SysDes-053**: IF-007 Audio Capture Interface shall provide PCM capture frames, device state, route changes, and capture errors to the audio subsystem. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-059 through SysRS-074 + +**SysDes-054**: IF-008 Audio Playback Interface shall provide mixed PCM playback frames, playback reference for echo cancellation where required, and playback route events. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-059 through SysRS-074 + +**SysDes-055**: IF-009 Secure Storage Interface shall store identity private keys, server passwords, and future sensitive tokens through platform-secure mechanisms. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Storage, Platform Secure Storage +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-140 through SysRS-167 + +**SysDes-056**: IF-010 Local Data Store Interface shall persist non-secret data through SQLite or an equivalent embedded database. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Storage +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-140 through SysRS-152 + +**SysDes-057**: IF-011 Diagnostics Export Interface shall export user-initiated diagnostic bundles with redaction applied before export. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP1 +- Allocated SysRS: SysRS-168 through SysRS-177 + +**SysDes-058**: IF-013 Network Interface shall provide connectivity to external compatible servers and network diagnostic inputs for reconnect and troubleshooting. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2 +- Allocated SysRS: SysRS-075 through SysRS-087 + +**SysDes-059**: IF-014 Permission Interface shall mediate microphone, notification, audio session, foreground service, and lifecycle permission behavior on supported platforms. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP1, BP2 +- Allocated SysRS: SysRS-048 through SysRS-058, SysRS-153 through SysRS-167 + + +## 7. Dynamic Architecture + +### 7.1 System Modes and States + +| State / Mode | Owner | Description | +|---|---|---| +| Not Installed | SE-18 | Application has not been installed on the client device. | +| Installed / Not Running | SE-06 | Application is installed but not active. | +| Running / Disconnected | SE-06, SE-07, SE-10 | App is active with no server connection. | +| Connecting | SE-10, SE-11 | User has started connection and protocol setup is in progress. | +| Synchronizing | SE-10, SE-11, SE-12 | Protocol connection exists and snapshot is being built. | +| Connected | SE-10, SE-11, SE-12 | Snapshot is ready and live deltas are being applied. | +| Voice Active | SE-13, SE-14 | User is in a voice channel and capture/playback pipelines are active. | +| Reconnecting | SE-10, SE-11, SE-12 | Recoverable failure triggered reconnect policy. | +| Permission Blocked | SE-03, SE-07, SE-14 | Required permission is missing or denied. | +| Diagnostics Export | SE-17 | User-initiated diagnostic export is in progress. | +| Release/Update | SE-18 | Deployment or update process is active. | + + +**SysDes-060**: The connection state machine shall be owned by Rust Core and reflected to Flutter as UI-safe connection status events. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-129 through SysRS-139 + +**SysDes-061**: The voice activity mode shall be active only when a channel context, audio device state, permission state, and protocol voice path are valid. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-241 through SysRS-253 + +**SysDes-062**: The permission-blocked mode shall prevent unsafe voice operations while preserving user visibility into corrective actions. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-153 through SysRS-167 + +**SysDes-063**: The reconnect mode shall preserve UI responsiveness and rebuild authoritative server state from a fresh snapshot after reconnect. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-075 through SysRS-087, SysRS-129 through SysRS-139 + +**SysDes-064**: The diagnostics export mode shall be explicitly user-initiated and shall apply redaction before export. + +- Status: Baseline +- Type: Dynamic Behavior +- Stage: P0 / MVP +- Allocated to: Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-168 through SysRS-177, SysRS-257 + + +### 7.2 Dynamic Flow: Manual Connection and Initial Snapshot + +```text +User -> Flutter UI -> Bridge -> Rust Core -> Protocol Adapter -> External Server +External Server -> Protocol Adapter -> Rust Core -> State Engine -> Bridge -> Flutter State -> UI +``` + + +**SysDes-065**: Manual connection flow shall pass host, port, nickname, optional password, and identity reference from Flutter UI to Rust Core through bridge DTOs. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-102 through SysRS-105 + +**SysDes-066**: Rust Core shall use the protocol adapter to establish server connection and authentication through `tsclientlib`. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-088 through SysRS-101, SysRS-121 through SysRS-128 + +**SysDes-067**: Initial synchronization shall fetch server information, channel list, client list, and required self-client information before emitting a full snapshot. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-129 through SysRS-133 + +**SysDes-068**: Live server events shall be converted into internal events, applied through deterministic reducers, and emitted as UI-safe delta events. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-130 through SysRS-136 + +**SysDes-069**: Channel join flow shall wait for Rust Core/protocol confirmation before treating the UI state as authoritative. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-108, SysRS-116, SysRS-244 + +**SysDes-070**: Text message flow shall route user text from Flutter to Rust Core to protocol adapter and route received messages back as core events. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-110, SysRS-119, SysRS-254 + +**SysDes-071**: Outgoing voice flow shall capture PCM frames, apply required processing, encode voice, and send voice packets through the protocol adapter. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-242 + +**SysDes-072**: Incoming voice flow shall receive voice packets, jitter-buffer, decode, apply per-user controls, mix, and play through platform playback. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-243 + +**SysDes-073**: User-triggered disconnect flow shall transition to Disconnected and shall suppress automatic reconnect. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-106, SysRS-138, SysRS-217 + +**SysDes-074**: Recoverable network failure flow shall transition to Reconnecting, apply reconnect policy, and rebuild state from a fresh snapshot. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-085 through SysRS-087, SysRS-137 + +**SysDes-075**: Audio device change flow shall report route/device changes through platform adapters and shall recover or enter a user-safe blocked/degraded state. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-063, SysRS-064, SysRS-188 + +**SysDes-076**: Secure storage flow shall store and retrieve secrets through platform secure storage without exposing plaintext secrets to logs or diagnostic export. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP2 +- Allocated SysRS: SysRS-148 through SysRS-167 + + +## 8. Architecture Analysis and Design Rationale + +### 8.1 Major Design Decisions + +| Decision ID | Decision | Rationale | Main Risk | Mitigation | +|---|---|---|---|---| +| ADR-001 | Flutter + Rust Core | Cross-platform UI with shared protocol/audio/state core | Bridge complexity | Typed DTOs, generated bridge, event streams | +| ADR-002 | `tsclientlib` protocol adapter | Required protocol library and Rust-native integration | Library maturity or feature gaps | Adapter isolation, protocol probe, compatibility matrix | +| ADR-003 | Snapshot + delta state synchronization | Stable state recovery and replayable debugging | Event ordering bugs | Single connection actor, reducer tests, event replay | +| ADR-004 | Audio subsystem outside Flutter | Real-time audio processing and low latency | Platform audio variance | Platform adapters and backend abstraction | +| ADR-005 | Required audio processing features | Voice quality: Echo Canceller, AGC, Noise Suppression, HPF | Feature availability differs by platform | Backend abstraction and platform-specific validation | +| ADR-006 | Platform secure storage | Protect identities and passwords | Platform API variance | SecureStore trait and per-platform adapters | +| ADR-007 | No Chanora central backend for MVP | Simplifies privacy, operations, and system boundary | No cloud sync | Defer cloud sync beyond MVP | +| ADR-008 | External compatible server as external system | Chanora is client-only and not server operator | Server behavior varies | Protocol probe, compatibility matrix, user-safe errors | + + +**SysDes-077**: The architecture shall select Flutter + Rust Core to meet cross-platform UI requirements while centralizing protocol, state, audio, storage, and diagnostics logic. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-001 through SysRS-010 + +**SysDes-078**: The architecture shall isolate `tsclientlib` inside the protocol adapter to reduce impact if protocol implementation must be patched, forked, or replaced. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-121 through SysRS-128, SysRS-220 + +**SysDes-079**: The architecture shall use snapshot + delta synchronization to support deterministic state recovery, reconnect behavior, event replay, and UI consistency. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: State Sync, System Engineering, Verification +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-129 through SysRS-139 + +**SysDes-080**: The architecture shall use platform adapters to isolate OS-specific permission, audio routing, lifecycle, secure storage, notification, and packaging concerns. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-048 through SysRS-058, SysRS-153 through SysRS-167 + +**SysDes-081**: The architecture shall implement audio processing through a backend abstraction that supports platform-native and Rust-based processing options. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-178 through SysRS-191 + +**SysDes-082**: The architecture shall define external compatible server behavior as an external dependency and shall not assume control over server-side permissions, availability, or configuration. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Platform +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-088 through SysRS-101, SysRS-223 + +**SysDes-083**: The architecture shall not introduce Chanora-operated backend infrastructure for MVP voice, channel, or text operation. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-017, SysRS-218 + +**SysDes-084**: The architecture shall treat real-time audio behavior, secure secret storage, protocol compatibility, mobile lifecycle policy, diagnostic redaction, and release signing as special characteristics requiring explicit verification. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations +- Downstream artifact: SAD, SDD, Verification +- Verification method: Review, Analysis +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-153 through SysRS-199, SysRS-233 through SysRS-257 + + +### 8.2 Special Characteristics + +| Characteristic | Affected Elements | Design Handling | +|---|---|---| +| Real-time voice latency | SE-02, SE-03, SE-13, SE-14 | Audio pipeline outside Flutter, low-latency platform adapters, Opus-compatible codec, jitter buffer | +| Echo cancellation quality | SE-02, SE-03, SE-13, SE-14 | Playback reference support, backend abstraction, per-platform validation | +| Protocol compatibility | SE-05, SE-11 | `tsclientlib` adapter, protocol probe, compatibility matrix | +| Secure identity handling | SE-03, SE-16 | Platform secure storage, no plaintext private keys | +| Diagnostic privacy | SE-17, SE-19 | Redaction before export, user-initiated export | +| Mobile foreground voice | SE-03, SE-14 | AVAudioSession, Android foreground service, lifecycle handling | +| Release trust | SE-18 | Signing, notarization, app-store release metadata review | + + +## 9. Resource, Performance, Reliability, Security, and Deployment Design + + +**SysDes-085**: The architecture shall allocate UI responsiveness to Flutter UI, Bridge Layer, Rust Core asynchronous command handling, and non-blocking reconnect behavior. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Flutter UI, Software: Bridge, Software: Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-178, SysRS-179, SysRS-187 + +**SysDes-086**: The architecture shall allocate local audio latency requirements to client device hardware, OS audio stack, platform adapters, audio subsystem, codec processing, and network environment. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Hardware, Network, Software: Audio Subsystem, Platform +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-180, SysRS-181 + +**SysDes-087**: The architecture shall allocate memory growth constraints to Rust Core queue management, diagnostics log retention, chat history limits, and audio buffer bounds. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-182 through SysRS-186 + +**SysDes-088**: The architecture shall allocate reliability recovery requirements to Rust Core reconnect policy, protocol adapter error mapping, state engine snapshot replacement, and platform audio recovery. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Analysis +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-187 through SysRS-191 + +**SysDes-089**: The architecture shall allocate security requirements to platform secure storage, secret redaction, diagnostics redaction, user-safe error mapping, and input validation. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Platform Secure Storage, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Audit +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-153 through SysRS-167 + +**SysDes-090**: The architecture shall allocate privacy requirements to user-controlled diagnostics, minimal data collection, and permission explainers. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Platform, Software: Diagnostics, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Audit +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-163 through SysRS-167 + +**SysDes-091**: The architecture shall allocate packaging and release requirements to deployment environment, signing/notarization/app-store packaging, and release metadata review. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Software: Storage, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Demo +- Verification owner: Release / Operations QA +- ASPICE SYS.3 alignment: SYS.3 BP3 +- Allocated SysRS: SysRS-192 through SysRS-199 + + +## 10. Bidirectional Traceability and Consistency + +### 10.1 Traceability Rules + + +**SysDes-092**: Each SysRS requirement shall trace forward to one or more system elements and to one or more SysDes design items with Type, Stage, Allocation, and Verification attributes. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-093**: Each system element shall trace backward to one or more SysRS requirements unless explicitly marked as supporting infrastructure. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + +**SysDes-094**: Each interface shall trace backward to the SysRS requirements that require the interaction or runtime dependency. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-200 through SysRS-210 + +**SysDes-095**: Each dynamic flow shall trace backward to the SysRS functional, state, performance, security, or operational requirements that require the behavior. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-102 through SysRS-191 + +**SysDes-096**: Architecture changes shall update the SysRS allocation matrix, affected interfaces, affected dynamic flows, and verification hooks. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-097**: Consistency review shall check that SysDes does not contradict SysRS, does not introduce unapproved scope, and does not remove required MVP capabilities. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4 +- Allocated SysRS: SysRS-001 through SysRS-257 + + +## 11. Architecture Agreement and Communication + + +**SysDes-098**: The system architecture shall be reviewed by product, system engineering, Rust Core engineering, Flutter engineering, audio engineering, platform engineering, QA, security/privacy, and release stakeholders. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-011 through SysRS-015, SysRS-233 through SysRS-240 + +**SysDes-099**: Architecture review evidence shall include review date, participants, open issues, decisions, accepted risks, and approval status. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-100**: The agreed SysDes baseline shall be communicated to downstream SRS, SAD, SDD, and Verification authors. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: System Engineering +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-101**: Any change affecting `tsclientlib` isolation, real-time audio processing, secure storage, mobile lifecycle, or release wording shall trigger architecture impact review. + +- Status: Baseline +- Type: Process / Description +- Stage: P0 / MVP +- Allocated to: Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification +- Downstream artifact: SysDes baseline, Verification +- Verification method: Review, Inspection +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP5 +- Allocated SysRS: SysRS-005, SysRS-059 through SysRS-074, SysRS-153 through SysRS-199, SysRS-211 through SysRS-218 + + +## 12. Verification Handoff + +The SysDes does not define detailed test cases. It defines verification hooks that shall be expanded in the Verification artifact. + + +**SysDes-102**: Protocol verification shall use a protocol probe tool and compatibility matrix to verify external server compatibility and `tsclientlib` adapter behavior. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: External Server, Software: Protocol Adapter +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Protocol / Integration QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-121 through SysRS-128, SysRS-233, SysRS-241 + +**SysDes-103**: State verification shall use reducer tests and event replay tests to verify snapshot, delta, reconnect, and malformed-event behavior. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Software: State Sync +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Network / Reliability QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-129 through SysRS-139, SysRS-234, SysRS-191 + +**SysDes-104**: Audio verification shall use audio loopback and processing tests to verify capture, playback, codec, jitter buffer, mixer, Echo Canceller, AGC, Noise Suppression, and High-Pass Filter. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Software: Audio Subsystem +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-059 through SysRS-074, SysRS-235, SysRS-242 through SysRS-253 + +**SysDes-105**: Security verification shall audit secure storage, private-key handling, password handling, input validation, and diagnostic redaction on all target platforms. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Platform Secure Storage, Software: Diagnostics, Verification +- Downstream artifact: Verification +- Verification method: Audit +- Verification owner: Security / QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-140 through SysRS-167, SysRS-236, SysRS-256 + +**SysDes-106**: Deployment verification shall verify release package creation, signing, notarization, app-store builds, and release metadata wording. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Software: Storage, Deployment / Operations +- Downstream artifact: Verification +- Verification method: Inspection, Demo +- Verification owner: Release / Operations QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-192 through SysRS-199, SysRS-238 + +**SysDes-107**: MVP acceptance verification shall demonstrate all acceptance requirements from SysRS-241 through SysRS-257. + +- Status: Baseline +- Type: Verification Handoff +- Stage: P0 / MVP +- Allocated to: Verification +- Downstream artifact: Verification +- Verification method: Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-241 through SysRS-257 + + +**SysDes-108**: The SysDes shall be the mandatory architectural allocation layer between SysRS and SRS; downstream SRS requirements shall use SysDes IDs as their direct source and shall not use SysRS IDs as their direct source. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Requirements Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP4, BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-109**: The SysDes shall provide enough allocation information for SWE.1 to derive software requirements without directly reinterpreting SysRS requirements. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Requirements Engineering +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP1, BP3, BP4, BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + +**SysDes-110**: If a downstream software requirement cannot be derived from an existing SysDes design item, the SysDes shall be revised before the SRS is revised or baselined. + +- Status: Baseline +- Type: Change Control / Traceability Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Requirements Engineering, Change Control, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: SYS.3 BP3, BP4, BP5 +- Allocated SysRS: SysRS-233 through SysRS-240 + + +## 13. SysDes Design Item Metadata Register + +This register provides a compact review view of all `SysDes-XXX` design items and their engineering attributes. + +| SysDes ID | Type | Stage | Allocated to | Verification method | Verification owner | Downstream artifact | +|---|---|---|---|---|---|---| +| SysDes-001 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-002 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-003 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-004 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SysDes baseline, Verification | +| SysDes-005 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-006 | Process / Description | P0 / MVP | Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | Review, Inspection | Audio / Platform QA | SysDes baseline, Verification | +| SysDes-007 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-008 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-009 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SysDes baseline, Verification | +| SysDes-010 | Architectural Constraint | P0 / MVP | Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | Review | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-011 | Architectural Constraint | P0 / MVP | Software: Protocol Adapter | Review | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-012 | Architectural Constraint | P0 / MVP | Software: Flutter UI, Software: Rust Core | Review | Software QA | SRS, SAD, SDD | +| SysDes-013 | Architectural Constraint | P0 / MVP | Software: Audio Subsystem | Review | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-014 | Architectural Constraint | P0 / MVP | Software: Flutter UI, Software: Audio Subsystem | Review | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-015 | Architectural Constraint | P0 / MVP | Software: Diagnostics, Verification | Review | Security / QA | SRS, SAD, SDD | +| SysDes-016 | Architectural Constraint | P0 / MVP | System Engineering | Review | System Engineering / QA | SRS, SAD, SDD | +| SysDes-017 | Architectural Constraint | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations | Review | Security / QA | SRS, SAD, SDD | +| SysDes-018 | Static Architecture Description | P0 / MVP | External Server, Software: Audio Subsystem, Deployment / Operations | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-019 | System Element Allocation | P0 / MVP | User / Operator, Platform, Software: Diagnostics, Verification | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-020 | System Element Allocation | P0 / MVP | Hardware, Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-021 | System Element Allocation | P0 / MVP | Platform, Software: Audio Subsystem, Platform Secure Storage | Review, Inspection | Security / QA | SRS, SAD, SDD | +| SysDes-022 | System Element Allocation | P0 / MVP | Network | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-023 | System Element Allocation | P0 / MVP | External Server, Software: Audio Subsystem, Platform | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-024 | System Element Allocation | P0 / MVP | Software, Platform | Review, Inspection | System Engineering / QA | SRS, SAD, SDD | +| SysDes-025 | System Element Allocation | P0 / MVP | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-026 | System Element Allocation | P0 / MVP | Software: Flutter State, Software: Rust Core, Software: State Sync | Review, Inspection | Software QA | SRS, SAD, SDD | +| SysDes-027 | System Element Allocation | P0 / MVP | Software: Bridge, Software: Rust Core | Review, Inspection | Software QA | SRS, SAD, SDD | +| SysDes-028 | System Element Allocation | P0 / MVP | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-029 | System Element Allocation | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-030 | System Element Allocation | P0 / MVP | Software: State Sync | Review, Inspection | System Engineering / QA | SRS, SAD, SDD | +| SysDes-031 | System Element Allocation | P0 / MVP | Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-032 | System Element Allocation | P0 / MVP | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | Review, Inspection | Security / QA | SRS, SAD, SDD | +| SysDes-033 | System Element Allocation | P0 / MVP | Software: Audio Subsystem, Software: Storage | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-034 | System Element Allocation | P0 / MVP | Platform Secure Storage | Review, Inspection | Security / QA | SRS, SAD, SDD | +| SysDes-035 | System Element Allocation | P0 / MVP | Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-036 | System Element Allocation | P0 / MVP | Software: Storage, Deployment / Operations | Review, Inspection | Release / Operations QA | SRS, SAD, SDD | +| SysDes-037 | System Element Allocation | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD | +| SysDes-038 | Static Architecture Design | P0 / MVP | Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core | Review, Inspection | Software QA | SRS, SAD, SDD | +| SysDes-039 | Static Architecture Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-040 | Static Architecture Design | P0 / MVP | Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD | +| SysDes-041 | Static Architecture Design | P0 / MVP | Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem | Review, Inspection | Audio / Platform QA | SRS, SAD, SDD | +| SysDes-042 | Allocation Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SRS, SAD, SDD, Verification | +| SysDes-043 | Allocation Rule | P0 / MVP | External Server, Deployment / Operations, System Engineering, Verification | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-044 | Allocation Rule | P0 / MVP | Software: Flutter UI, Software: Rust Core | Review, Inspection | Software QA | SRS, SAD, SDD, Verification | +| SysDes-045 | Allocation Rule | P0 / MVP | Hardware, Platform, Network | Review, Inspection | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-046 | Allocation Rule | P0 / MVP | Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering | Review, Inspection | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-047 | Allocation Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SRS, SAD, SDD, Verification | +| SysDes-048 | Interface Design | P0 / MVP | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-049 | Interface Design | P0 / MVP | Software: Bridge, Software: Protocol Adapter | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-050 | Interface Design | P0 / MVP | Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-051 | Interface Design | P0 / MVP | Software: Protocol Adapter | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-052 | Interface Design | P0 / MVP | External Server, Software: Protocol Adapter | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-053 | Interface Design | P0 / MVP | Software: Audio Subsystem | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-054 | Interface Design | P0 / MVP | Software: Audio Subsystem | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-055 | Interface Design | P0 / MVP | Software: Storage, Platform Secure Storage | Inspection, Integration Test | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-056 | Interface Design | P0 / MVP | Software: Storage | Inspection, Integration Test | Software QA | SRS, SAD, SDD, Verification | +| SysDes-057 | Interface Design | P0 / MVP | Software: Diagnostics, Verification | Inspection, Integration Test | System Engineering / QA | SRS, SAD, SDD, Verification | +| SysDes-058 | Interface Design | P0 / MVP | Software: Diagnostics, Verification | Inspection, Integration Test | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-059 | Interface Design | P0 / MVP | Software: Audio Subsystem, Platform | Inspection, Integration Test | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-060 | Dynamic Behavior | P0 / MVP | Software: Rust Core | System Test, Demo | Software QA | SRS, SAD, SDD, Verification | +| SysDes-061 | Dynamic Behavior | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Platform | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-062 | Dynamic Behavior | P0 / MVP | Software: Audio Subsystem, Platform | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-063 | Dynamic Behavior | P0 / MVP | Software: State Sync | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-064 | Dynamic Behavior | P0 / MVP | Software: Diagnostics, Verification | System Test, Demo | System Engineering / QA | SRS, SAD, SDD, Verification | +| SysDes-065 | Functional Dynamic Design | P0 / MVP | Software: Flutter UI, Software: Bridge, Software: Rust Core | System Test, Demo | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-066 | Functional Dynamic Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-067 | Functional Dynamic Design | P0 / MVP | Software: State Sync | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-068 | Functional Dynamic Design | P0 / MVP | Software: State Sync | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-069 | Functional Dynamic Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-070 | Functional Dynamic Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter | System Test, Demo | Protocol / Integration QA | SRS, SAD, SDD, Verification | +| SysDes-071 | Functional Dynamic Design | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-072 | Functional Dynamic Design | P0 / MVP | Software: Audio Subsystem | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-073 | Functional Dynamic Design | P0 / MVP | Software | System Test, Demo | Network / Reliability QA | SRS, SAD, SDD, Verification | +| SysDes-074 | Functional Dynamic Design | P0 / MVP | Software: State Sync | System Test, Demo | Network / Reliability QA | SRS, SAD, SDD, Verification | +| SysDes-075 | Functional Dynamic Design | P0 / MVP | Software: Audio Subsystem, Platform | System Test, Demo | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-076 | Functional Dynamic Design | P0 / MVP | Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification | System Test, Demo | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-077 | Architecture Decision / Rationale | P0 / MVP | Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification | Review, Analysis | Audio / Platform QA | SAD, SDD, Verification | +| SysDes-078 | Architecture Decision / Rationale | P0 / MVP | Software: Protocol Adapter | Review, Analysis | Protocol / Integration QA | SAD, SDD, Verification | +| SysDes-079 | Architecture Decision / Rationale | P0 / MVP | Software: State Sync, System Engineering, Verification | Review, Analysis | Network / Reliability QA | SAD, SDD, Verification | +| SysDes-080 | Architecture Decision / Rationale | P0 / MVP | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | Review, Analysis | Security / QA | SAD, SDD, Verification | +| SysDes-081 | Architecture Decision / Rationale | P0 / MVP | Software: Audio Subsystem | Review, Analysis | Audio / Platform QA | SAD, SDD, Verification | +| SysDes-082 | Architecture Decision / Rationale | P0 / MVP | Platform | Review, Analysis | Protocol / Integration QA | SAD, SDD, Verification | +| SysDes-083 | Architecture Decision / Rationale | P0 / MVP | Software: Audio Subsystem | Review, Analysis | Audio / Platform QA | SAD, SDD, Verification | +| SysDes-084 | Architecture Decision / Rationale | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | Review, Analysis | Security / QA | SAD, SDD, Verification | +| SysDes-085 | Non-functional Architecture Design | P0 / MVP | Software: Flutter UI, Software: Bridge, Software: Rust Core | Review | Network / Reliability QA | SRS, SAD, SDD, Verification | +| SysDes-086 | Non-functional Architecture Design | P0 / MVP | Hardware, Network, Software: Audio Subsystem, Platform | Test, Analysis | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-087 | Non-functional Architecture Design | P0 / MVP | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | Test, Analysis | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-088 | Non-functional Architecture Design | P0 / MVP | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem | Test, Analysis | Audio / Platform QA | SRS, SAD, SDD, Verification | +| SysDes-089 | Non-functional Architecture Design | P0 / MVP | Platform Secure Storage, Software: Diagnostics, Verification | Audit | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-090 | Non-functional Architecture Design | P0 / MVP | Platform, Software: Diagnostics, Verification | Audit | Security / QA | SRS, SAD, SDD, Verification | +| SysDes-091 | Non-functional Architecture Design | P0 / MVP | Software: Storage, Deployment / Operations, System Engineering, Verification | Inspection, Demo | Release / Operations QA | SRS, SAD, SDD, Verification | +| SysDes-092 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-093 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-094 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-095 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | Security / QA | SysDes baseline, Verification | +| SysDes-096 | Traceability / Consistency Rule | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-097 | Traceability / Consistency Rule | P0 / MVP | System Engineering, Verification | Review, Inspection | Software QA | SysDes baseline, Verification | +| SysDes-098 | Process / Description | P0 / MVP | Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification | Review, Inspection | Security / QA | SysDes baseline, Verification | +| SysDes-099 | Process / Description | P0 / MVP | System Engineering, Verification | Review, Inspection | System Engineering / Verification | SysDes baseline, Verification | +| SysDes-100 | Process / Description | P0 / MVP | System Engineering | Review, Inspection | System Engineering / QA | SysDes baseline, Verification | +| SysDes-101 | Process / Description | P0 / MVP | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification | Review, Inspection | Security / QA | SysDes baseline, Verification | +| SysDes-102 | Verification Handoff | P0 / MVP | External Server, Software: Protocol Adapter | Test, Demo | Protocol / Integration QA | Verification | +| SysDes-103 | Verification Handoff | P0 / MVP | Software: State Sync | Test, Demo | Network / Reliability QA | Verification | +| SysDes-104 | Verification Handoff | P0 / MVP | Software: Audio Subsystem | Test, Demo | Audio / Platform QA | Verification | +| SysDes-105 | Verification Handoff | P0 / MVP | Platform Secure Storage, Software: Diagnostics, Verification | Audit | Security / QA | Verification | +| SysDes-106 | Verification Handoff | P0 / MVP | Software: Storage, Deployment / Operations | Inspection, Demo | Release / Operations QA | Verification | +| SysDes-107 | Verification Handoff | P0 / MVP | Verification | Test, Demo | Software QA | Verification | +| SysDes-108 | Traceability / Consistency Rule | P0 / MVP | System Engineering, Software Requirements Engineering, Verification | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD, Verification | +| SysDes-109 | Allocation Rule | P0 / MVP | System Engineering, Software Requirements Engineering | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD, Verification | +| SysDes-110 | Change Control / Traceability Rule | P0 / MVP | System Engineering, Software Requirements Engineering, Change Control, Verification | Review, Inspection | System Engineering / Verification | SRS, SAD, SDD, Verification | + +## Appendix A — Complete SysRS to SysDes Allocation Matrix + +This matrix provides explicit allocation for every SysRS requirement. It is the primary bidirectional traceability record for this SysDes. + +| SysRS ID | SysRS Requirement Summary | Allocated System Elements | Primary SysDes Design Items | +|---|---|---|---| + +| SysRS-001 | The Chanora application shall be a cross-platform client application for channel-based voice communication. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-14 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-002 | The Chanora application shall support Windows, macOS, Linux, iOS, and Android as target client platforms. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-03 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-003 | The Chanora application shall use Flutter for the user-facing client interface. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-08 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-004 | The Chanora application shall use Rust Core for protocol handling, connection management, state synchronization, audio processing, storage coordination, diagnostics, and business logic. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-05 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-005 | The Chanora application shall use `tsclientlib` as the TeamSpeak-compatible protocol client library. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-05 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-006 | The Chanora application shall operate as an independent client and shall not present itself as an official TeamSpeak product. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-007 | The Chanora application shall allow users to connect to TeamSpeak 3-compatible servers reachable from the client device network. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-05 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-008 | The Chanora application shall allow users to participate in channel-based voice communication when the external server and user permissions allow it. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-14 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-009 | The Chanora application shall allow users to send and receive supported text messages when the external server and user permissions allow it. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-010 | The Chanora application shall provide local bookmark, recent server, identity reference, UI setting, and audio setting management on the client device. | SE-06, SE-07, SE-10, SE-11, SE-13, SE-15, SE-16, SE-14 | SysDes-018, SysDes-024, SysDes-025, SysDes-028, SysDes-042 | + +| SysRS-011 | The Chanora application shall support end users who manually connect to compatible voice servers. | SE-01, SE-07, SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-012 | The Chanora application shall support regular users who rely on saved bookmarks, persistent identity, audio settings, and common voice controls. | SE-01, SE-07, SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-013 | The Chanora application shall support testers and support operators who export diagnostics for troubleshooting. | SE-01, SE-07, SE-17, SE-19 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-014 | The SysRS shall provide requirements traceability suitable for engineering, QA, system administration, and release operations. | SE-01, SE-07, SE-17, SE-19 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-015 | The SysRS shall document external environment dependencies that may need administrator configuration, including network reachability and OS-level audio permissions. | SE-01, SE-07, SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-018, SysDes-019, SysDes-025, SysDes-035, SysDes-042 | + +| SysRS-016 | The Chanora application shall treat external TeamSpeak 3-compatible servers as external systems outside Chanora control. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-11 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-017 | The Chanora application shall not require a Chanora-operated central server for MVP voice, channel, or text operation. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-13, SE-02 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-018 | The Chanora application shall not host or operate TeamSpeak-compatible server functionality in the MVP. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-11 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-019 | The Chanora application shall rely on operating system services for microphone permission, secure storage, audio routing, notifications, and mobile lifecycle behavior. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-13, SE-02, SE-15 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-020 | The Chanora application shall treat app stores, package repositories, installers, and update services as deployment environment components. | SE-03, SE-04, SE-05, SE-14, SE-18 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-021 | The Chanora application shall treat physical microphones, speakers, wired headsets, USB audio devices, and Bluetooth audio devices as external hardware interfaces. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-13, SE-02 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-022 | The Chanora application shall treat routers, firewalls, VPNs, NAT devices, and ISPs as external network environment components. | SE-03, SE-04, SE-05, SE-14, SE-18, SE-17 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-023 | The Chanora application shall expose user-safe errors when external dependencies prevent successful operation. | SE-03, SE-04, SE-05, SE-14, SE-18 | SysDes-018, SysDes-021, SysDes-022, SysDes-023, SysDes-042 | + +| SysRS-024 | The Chanora application shall include a Flutter UI component responsible for rendering screens, receiving user input, and presenting application state. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-025 | The Chanora application shall include a Flutter State Layer responsible for UI state derived from Rust Core events. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-026 | The Chanora application shall include a Bridge Layer responsible for commands, DTOs, asynchronous calls, and event streams between Flutter and Rust Core. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-027 | The Chanora application shall include a Rust Core component responsible for authoritative connection, protocol, state, audio, storage, settings, and diagnostics behavior. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-028 | The Chanora application shall include a protocol adapter component that isolates direct `tsclientlib` usage. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-029 | The Chanora application shall include a state synchronization component that implements snapshot + delta state handling. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-030 | The Chanora application shall include an audio subsystem component that coordinates capture, processing, encoding, decoding, jitter buffering, mixing, and playback. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-031 | The Chanora application shall include a local storage component for non-secret data such as bookmarks, recent servers, UI settings, and audio settings. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-032 | The Chanora application shall include a secure storage adapter for private identities, passwords, and future sensitive tokens. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-033 | The Chanora application shall include a diagnostics component for structured logging, redaction, event recording, event replay, audio diagnostics, network diagnostics, and user-initiated export. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-034 | The Chanora application shall include platform adapter components for desktop and mobile platform services. | SE-06, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-024, SysDes-025, SysDes-026, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-035 | The client device shall use a CPU architecture supported by Flutter, Rust, and the selected target platform. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-07, SE-08 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-036 | The client device shall provide sufficient CPU capacity to run the Chanora application, Opus-compatible voice processing, and enabled audio processing features in real time. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-037 | The client device shall provide sufficient memory for the Chanora application to run without unbounded growth in logs, chat history, audio buffers, or event queues. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-17 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-038 | The client device shall provide persistent local storage for Chanora application data, settings, logs, and cached metadata. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-039 | The client device shall provide a microphone or supported audio input device for voice transmission. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-040 | The client device shall provide speakers, headphones, or a supported audio output device for voice playback. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-041 | The client device shall provide network connectivity to the selected compatible voice server. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-17 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-042 | The desktop client environment should be validated on devices with at least 4 GB RAM for MVP operation. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-043 | The desktop client environment should be validated with at least 500 MB free local storage for installation, settings, logs, and diagnostic bundle creation. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-044 | The client device should provide stable audio device identifiers where the target platform supports persistent device selection. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-18 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-045 | The client device should provide hardware or OS support for low-latency audio capture and playback. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-17 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-046 | The client device should provide Bluetooth audio support where the target operating system supports it. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-047 | The project shall document platform-specific hardware limitations discovered during compatibility testing. | SE-02, SE-03, SE-04, SE-13, SE-14, SE-19, SE-18 | SysDes-020, SysDes-021, SysDes-022, SysDes-042, SysDes-045 | + +| SysRS-048 | The Windows runtime environment shall support native desktop window integration for the Chanora application. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-049 | The Windows runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure credential storage to the Chanora application. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-15, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-050 | The macOS runtime environment shall support native desktop window integration for the Chanora application. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-051 | The macOS runtime environment shall provide microphone permission prompts, microphone capture, speaker/headphone playback, audio device selection, and Keychain access to the Chanora application. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-052 | The Linux runtime environment shall support the desktop environments targeted by the selected release package. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-053 | The Linux runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure storage through Secret Service, libsecret, or equivalent where available. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-15, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-054 | The iOS runtime environment shall provide microphone permissions, foreground voice session capability, audio route change handling, audio interruption recovery, Keychain access, and AVAudioSession behavior to the Chanora application. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-055 | The Android runtime environment shall provide microphone permissions, foreground voice session capability, foreground service behavior, audio focus, Bluetooth route handling, Android Keystore access, and production audio integration through AAudio, Oboe, or equivalent. | SE-03, SE-14, SE-02, SE-18, SE-13, SE-16, SE-17 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-056 | The project shall define minimum supported operating system versions for each target platform before beta release. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-057 | The project shall document OS-level permissions required by each target platform before public release. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-058 | The Chanora application shall fail safely with a user-safe message when a required OS service is unavailable. | SE-03, SE-14, SE-02, SE-18 | SysDes-020, SysDes-021, SysDes-032, SysDes-042, SysDes-045 | + +| SysRS-059 | The Chanora application shall support microphone input for voice transmission. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-060 | The Chanora application shall support speaker or headphone output for voice playback. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-061 | The Chanora application shall support audio input and output device selection where the target platform exposes selectable devices. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-062 | The Chanora application shall handle audio route changes where the target platform reports them. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-063 | The Chanora application shall recover gracefully from audio device changes where possible. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-064 | The Chanora application shall support Echo Canceller for reducing playback audio leaking into microphone input. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-065 | The Chanora application shall support Automatic Gain Control for normalizing microphone input level. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-066 | The Chanora application shall support Noise Suppression for reducing stationary background noise. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-067 | The Chanora application shall support High-Pass Filter for reducing low-frequency rumble and handling noise. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-068 | The Chanora application shall support an audio processing backend abstraction so platform-native and Rust-based processing can be selected per platform. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-069 | The Chanora application shall allow Echo Canceller to use playback reference audio when the selected implementation requires it. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-070 | The Chanora application shall expose audio processing settings to Rust Core and persist them locally. | SE-02, SE-03, SE-13, SE-14, SE-10, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-071 | The Chanora application shall provide conservative default settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. | SE-02, SE-03, SE-13, SE-14, SE-15, SE-16 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-072 | The Chanora application shall allow platform-specific disabling of audio processing features when a feature is unstable or incompatible with a device configuration. | SE-02, SE-03, SE-13, SE-14, SE-18 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-073 | The project shall provide an audio loopback test tool for development and compatibility testing. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-074 | The project shall provide an audio processing test tool for development and compatibility testing. | SE-02, SE-03, SE-13, SE-14 | SysDes-020, SysDes-021, SysDes-031, SysDes-041, SysDes-042 | + +| SysRS-075 | The client network environment shall provide IP network connectivity from the client device to the selected compatible voice server. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-076 | The Chanora application shall allow the user to configure the server host or IP address. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-077 | The Chanora application shall allow the user to configure the server port. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-078 | The Chanora application should support a default TeamSpeak 3-compatible voice port when the user does not provide an explicit port. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-079 | The client network environment shall permit the protocol traffic required by `tsclientlib` and the selected compatible server. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-080 | The client network environment shall support latency suitable for real-time voice communication under expected operating conditions. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-081 | The client network environment should minimize packet loss for acceptable voice quality. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-13, SE-14 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-082 | The Chanora application shall detect recoverable network failures where possible. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-083 | The Chanora application shall enter reconnect behavior after recoverable network failures. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-084 | The Chanora application shall rebuild server state from a fresh snapshot after reconnect. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-085 | The Chanora application shall not require VPN connectivity unless the target server or user environment requires it. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-086 | The Chanora application shall present network failures through user-safe error messages. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-087 | The Chanora application should include network diagnostics in user-initiated diagnostic exports. | SE-04, SE-05, SE-10, SE-11, SE-12, SE-17, SE-19 | SysDes-022, SysDes-023, SysDes-028, SysDes-042, SysDes-045 | + +| SysRS-088 | The external voice server shall be TeamSpeak 3-compatible for Chanora MVP operation. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-089 | The external voice server shall be reachable from the client device network. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03, SE-04 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-090 | The external voice server shall permit client connection using the identity, nickname, password, and permissions supplied by the user. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03, SE-16 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-091 | The external voice server shall expose server information required for initial synchronization. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-092 | The external voice server shall expose channel listing required for the channel tree. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-093 | The external voice server shall expose client listing required for the online client view. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-094 | The external voice server shall support channel join operations for accessible channels. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-095 | The external voice server shall emit channel movement events required for state synchronization. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-096 | The external voice server shall emit client join and leave events required for state synchronization. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-097 | The external voice server shall emit channel create, update, and delete events required for state synchronization where those events occur. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-098 | The external voice server shall support channel text message send and receive where user permissions allow. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-099 | The external voice server shall support voice packet send and receive where user permissions allow. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03, SE-04 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-100 | The external voice server shall expose disconnect behavior or connection failure signals that can be mapped by the protocol adapter. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-101 | The project shall document server-side permissions that can affect channel join, voice transmission, and text messaging. | SE-05, SE-11, SE-12, SE-13, SE-14, SE-02, SE-03 | SysDes-023, SysDes-029, SysDes-030, SysDes-042, SysDes-045 | + +| SysRS-102 | The Chanora application shall allow the user to manually connect to a compatible server. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-103 | The Chanora application shall allow the user to provide hostname or IP address, port, nickname, and optional server password before connection. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-104 | The Chanora application shall support persistent local identity for compatible server authentication. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-105 | The Chanora application shall display connection status to the user. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-106 | The Chanora application shall allow the user to disconnect from the active server connection. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-107 | The Chanora application shall display the server channel tree after synchronization. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-108 | The Chanora application shall display online clients after synchronization. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-109 | The Chanora application shall allow the user to join an accessible voice channel. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-110 | The Chanora application shall allow the user to send and receive channel text messages where permitted. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-111 | The Chanora application shall capture and transmit voice where permitted. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-112 | The Chanora application shall receive and play voice where permitted. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-113 | The Chanora application shall provide microphone mute control. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-114 | The Chanora application shall provide output deaf control. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-115 | The Chanora application shall provide push-to-talk control. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-116 | The Chanora application shall display microphone input level where available. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-117 | The Chanora application shall display speaking indicators where available. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-118 | The Chanora application shall allow users to save and reuse server bookmarks. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-119 | The Chanora application shall allow users to configure audio processing features. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-120 | The Chanora application shall allow users to export redacted diagnostics. | SE-01, SE-07, SE-08, SE-09, SE-10, SE-11, SE-12, SE-13 | SysDes-019, SysDes-025, SysDes-026, SysDes-042, SysDes-044 | + +| SysRS-121 | The Chanora application shall use `tsclientlib` inside the protocol subsystem. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-122 | The Chanora application shall isolate direct `tsclientlib` calls inside the `chanora_protocol` component. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-123 | The Chanora application shall prevent raw `tsclientlib` types from crossing into Flutter UI or Flutter State Layer. | SE-11, SE-19, SE-07, SE-08, SE-09, SE-05 | SysDes-025, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-124 | The Chanora application shall convert `tsclientlib` errors into Chanora protocol errors. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-125 | The Chanora application shall convert `tsclientlib` events into internal protocol events. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-126 | The Chanora application shall support future patching, replacement, or forking of protocol implementation without changing Flutter UI contracts. | SE-11, SE-19, SE-07, SE-08, SE-09, SE-05 | SysDes-025, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-127 | The project shall provide protocol compatibility test coverage for MVP features. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-128 | The project shall include a protocol probe tool for validating target server compatibility. | SE-11, SE-19, SE-05 | SysDes-023, SysDes-029, SysDes-037, SysDes-040, SysDes-042 | + +| SysRS-129 | The Chanora application shall maintain one authoritative connection state per active server connection. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-130 | The Chanora application shall synchronize state using a snapshot + delta model. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-131 | The Chanora application shall emit a full snapshot after initial synchronization. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-132 | The Chanora application shall emit delta events after live server-side changes. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-133 | The Chanora application shall apply protocol events through deterministic reducers. | SE-10, SE-12, SE-09, SE-19, SE-11, SE-05 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-134 | The Chanora application shall preserve event ordering per connection. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-135 | The Chanora application shall rebuild state from a fresh snapshot after reconnect. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-136 | The Chanora application shall prevent Flutter from directly mutating server state. | SE-10, SE-12, SE-09, SE-19, SE-07, SE-08 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-137 | The Chanora application shall implement the defined connection state machine from Disconnected through Connecting, Synchronizing, Connected, and Reconnecting. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-138 | The Chanora application shall not automatically reconnect after user-triggered disconnect. | SE-10, SE-12, SE-09, SE-19 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-139 | The project shall include an event replay tool for development and debugging of state synchronization. | SE-10, SE-12, SE-09, SE-19, SE-17 | SysDes-027, SysDes-028, SysDes-030, SysDes-042 | + +| SysRS-140 | The Chanora application shall store server bookmarks locally. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-141 | The Chanora application shall store recent servers locally. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-142 | The Chanora application shall store audio settings locally. | SE-15, SE-16, SE-17, SE-14, SE-13, SE-02, SE-03 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-143 | The Chanora application shall store UI settings locally. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-144 | The Chanora application shall store per-user volume preferences locally where applicable. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-145 | The Chanora application shall store muted user preferences locally where applicable. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-146 | The Chanora application shall use SQLite or an equivalent embedded database for non-secret local data. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-147 | The Chanora application shall use platform secure storage for sensitive data. | SE-15, SE-16, SE-17, SE-14, SE-03, SE-18 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-148 | The Chanora application shall store identity private keys using platform secure storage. | SE-15, SE-16, SE-17, SE-14, SE-03, SE-18 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-149 | The Chanora application shall store server passwords using platform secure storage. | SE-15, SE-16, SE-17, SE-14, SE-03, SE-18 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-150 | The Chanora application shall not store private keys in plaintext files. | SE-15, SE-16, SE-17, SE-14 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-151 | The Chanora application shall not write passwords to logs. | SE-15, SE-16, SE-17, SE-14, SE-19 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-152 | The Chanora application shall redact secrets from diagnostic exports. | SE-15, SE-16, SE-17, SE-14, SE-19 | SysDes-033, SysDes-034, SysDes-035, SysDes-042, SysDes-046 | + +| SysRS-153 | The Chanora application shall store sensitive data using platform secure storage. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-154 | The Chanora application shall redact secrets from logs. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-155 | The Chanora application shall redact secrets from diagnostic bundles. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-156 | The Chanora application shall avoid exposing internal stack traces to normal users. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-157 | The Chanora application shall validate user input before passing it to protocol operations. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-11, SE-05 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-158 | The Windows runtime environment shall support Windows Credential Manager, DPAPI, or equivalent secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-159 | The macOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-160 | The iOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-161 | The Android runtime environment shall support Android Keystore or equivalent secure credential storage for the Chanora application. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-162 | The Linux runtime environment shall support Secret Service, libsecret, or equivalent secure storage where available. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-163 | The Chanora application shall minimize collection of personal data. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-164 | The Chanora application shall require user action before exporting diagnostics. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-165 | The Chanora application shall explain microphone permission usage before requesting permission where platform guidelines allow. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-13, SE-14 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-166 | The Chanora application shall explain notification permission usage before requesting permission where platform guidelines allow. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19, SE-14, SE-18 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-167 | The Chanora application shall not automatically upload diagnostics in MVP. | SE-03, SE-07, SE-15, SE-16, SE-17, SE-19 | SysDes-021, SysDes-025, SysDes-033, SysDes-042, SysDes-046 | + +| SysRS-168 | The Chanora application shall produce structured diagnostic logs. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-169 | The Chanora application shall support log redaction. | SE-17, SE-19, SE-16 | SysDes-034, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-170 | The Chanora application shall support protocol event recording in development or diagnostics mode. | SE-17, SE-19, SE-11, SE-05 | SysDes-029, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-171 | The Chanora application shall support event replay for debugging state synchronization. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-172 | The Chanora application shall support audio diagnostics. | SE-17, SE-19, SE-13, SE-14, SE-02, SE-03 | SysDes-031, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-173 | The Chanora application shall support network diagnostics. | SE-17, SE-19, SE-04 | SysDes-022, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-174 | The Chanora application shall support user-initiated diagnostic export. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-175 | Diagnostic export shall exclude or redact sensitive data. | SE-17, SE-19, SE-16 | SysDes-034, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-176 | The project shall document the expected support workflow for diagnostic bundle collection. | SE-17, SE-19 | SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-177 | The project shall include compatibility test tracking for supported platforms. | SE-17, SE-19, SE-03, SE-14, SE-18 | SysDes-021, SysDes-035, SysDes-037, SysDes-042 | + +| SysRS-178 | The Chanora application shall keep the UI responsive during connection, synchronization, and reconnect. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-179 | The Chanora application shall avoid visible UI freezes longer than 100 ms during normal operation. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-180 | The Chanora application shall minimize local audio pipeline latency. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-181 | The Chanora application should target local audio pipeline latency under 100 ms where platform conditions permit. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-182 | The Chanora application shall avoid unbounded memory growth in chat history. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-183 | The Chanora application shall avoid unbounded memory growth in logs. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-17 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-184 | The Chanora application shall avoid unbounded memory growth in audio buffers. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-185 | The Chanora application shall avoid unbounded memory growth in event queues. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-186 | The Chanora application shall perform required audio processing without sustained underruns on supported devices. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-187 | The Chanora application shall keep reconnect processing non-blocking for UI interaction. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-188 | The Chanora application shall recover from transient network loss where possible. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-17 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-189 | The Chanora application shall recover gracefully from audio device changes where possible. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-14 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-190 | The Chanora application shall isolate connection failures to the affected connection. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-191 | The Chanora application shall avoid crashing on malformed or unexpected protocol events. | SE-02, SE-04, SE-07, SE-10, SE-11, SE-12, SE-13, SE-05 | SysDes-020, SysDes-022, SysDes-025, SysDes-039, SysDes-041, SysDes-042 | + +| SysRS-192 | The project shall support Windows installer packaging for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-193 | The project shall support macOS signed and notarized builds for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-194 | The project shall support Linux packaging through AppImage, Flatpak, deb, rpm, or a selected subset. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-195 | The project shall support Android AAB release builds for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-196 | The project shall support iOS TestFlight and App Store release builds for the Chanora application. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-197 | The project shall document platform signing, packaging, and release requirements before public release. | SE-18, SE-19, SE-03, SE-14 | SysDes-021, SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-198 | The project shall ensure release metadata does not imply official TeamSpeak affiliation. | SE-18, SE-19 | SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-199 | The project shall define release channels for internal, beta, and production builds before external testing. | SE-18, SE-19 | SysDes-036, SysDes-037, SysDes-042 | + +| SysRS-200 | The Chanora application shall provide a user interface for manual server connection. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-201 | The Chanora application shall provide a user interface for bookmark management. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-202 | The Chanora application shall provide a user interface for channel tree navigation. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-203 | The Chanora application shall provide a user interface for chat. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-204 | The Chanora application shall provide a user interface for voice controls. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-205 | The Chanora application shall provide a user interface for audio processing settings. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-206 | The Chanora application shall provide a bridge interface between Flutter and Rust Core. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-207 | The Chanora application shall provide a protocol interface between Rust Core and `tsclientlib`. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-208 | The Chanora application shall provide an audio hardware interface through platform capture and playback adapters. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-209 | The Chanora application shall provide secure storage interfaces through platform-specific secure storage mechanisms. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-210 | The Chanora application shall provide a network interface to external TeamSpeak 3-compatible servers through `tsclientlib`. | SE-01, SE-03, SE-04, SE-05, SE-07, SE-09, SE-10, SE-11 | SysDes-019, SysDes-021, SysDes-022, SysDes-038, SysDes-039, SysDes-042 | + +| SysRS-211 | The Chanora application shall not directly expose raw `tsclientlib` types to Flutter. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-08 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-212 | The Chanora application shall not store private keys in plaintext files. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-213 | The Chanora application shall not write passwords to logs. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-214 | The Chanora application shall not imply official TeamSpeak affiliation in UI, documentation, or release metadata. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-215 | The Chanora application shall not automatically upload diagnostic information in MVP. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-216 | The Chanora application shall comply with iOS background execution policies. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-03 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-217 | The Chanora application shall comply with Android foreground service requirements for active voice sessions. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-13 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-218 | The MVP shall not require Chanora-operated backend infrastructure for voice, channels, or text. | SE-07, SE-11, SE-15, SE-16, SE-17, SE-18, SE-19, SE-13 | SysDes-025, SysDes-029, SysDes-033, SysDes-040, SysDes-042, SysDes-046 | + +| SysRS-219 | The selected `tsclientlib` version can support or be extended to support required MVP protocol features. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-220 | Required audio processing features can be implemented through a combination of platform-native APIs, Rust DSP, and external audio processing libraries. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-02, SE-03 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-221 | Mobile foreground voice behavior is sufficient for MVP. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-02, SE-03 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-222 | Background voice behavior will remain constrained by iOS and Android platform policies. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-02, SE-03 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-223 | External compatible server administrators are responsible for server availability, permissions, and configuration. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-224 | End users are responsible for providing valid server connection details and network access. | SE-04, SE-05, SE-11, SE-13, SE-14, SE-19, SE-17 | SysDes-022, SysDes-023, SysDes-029, SysDes-037, SysDes-042 | + +| SysRS-225 | The MVP shall not include TeamSpeak-compatible server hosting functionality. | SE-06, SE-13, SE-19, SE-11, SE-05 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-226 | The MVP shall not include full server administration functionality. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-227 | The MVP shall not include a complete permission editor. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-228 | The MVP shall not include a plugin system. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-229 | The MVP shall not include 3D positional audio unless explicitly reprioritized. | SE-06, SE-13, SE-19, SE-14, SE-02, SE-03 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-230 | The MVP shall not include advanced whisper list management unless explicitly reprioritized. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-231 | The MVP shall not include Server Query administration tools. | SE-06, SE-13, SE-19 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-232 | The MVP shall not include automatic cloud sync of bookmarks, identities, settings, or diagnostics. | SE-06, SE-13, SE-19, SE-15, SE-16, SE-17 | SysDes-024, SysDes-031, SysDes-037, SysDes-042 | + +| SysRS-233 | The project shall maintain a requirements traceability matrix from SysRS requirements through SysDes, SRS, SAD, SDD, and Verification evidence. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-234 | The project shall verify protocol compatibility through a protocol probe tool. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-05 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-235 | The project shall verify state synchronization through reducer tests and event replay tests. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-236 | The project shall verify audio capture, processing, encode/decode, and playback through audio loopback and processing tests. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-14 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-237 | The project shall verify secure storage behavior on every target platform before public release. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-15 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-238 | The project shall verify diagnostic redaction before enabling diagnostic export for external testers. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-239 | The project shall verify release packaging on every target platform before production release. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19, SE-03 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-240 | The project shall verify that public wording does not imply official TeamSpeak affiliation. | SE-11, SE-12, SE-13, SE-16, SE-17, SE-18, SE-19 | SysDes-029, SysDes-030, SysDes-031, SysDes-037, SysDes-042, SysDes-108, SysDes-109, SysDes-110 | + +| SysRS-241 | The MVP shall connect to a TeamSpeak 3-compatible server using `tsclientlib`. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-242 | The MVP shall display the server channel tree. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-243 | The MVP shall display online clients. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-244 | The MVP shall allow the user to join a voice channel. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-245 | The MVP shall send voice. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-246 | The MVP shall receive voice. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-247 | The MVP shall support microphone mute. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-248 | The MVP shall support output deaf. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-249 | The MVP shall support push-to-talk. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-250 | The MVP shall support Echo Canceller. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-251 | The MVP shall support Automatic Gain Control. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-252 | The MVP shall support Noise Suppression. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-253 | The MVP shall support High-Pass Filter. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-254 | The MVP shall send and receive channel text messages. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-255 | The MVP shall save and reuse server bookmarks. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-256 | The MVP shall use secure storage for sensitive data. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + +| SysRS-257 | The MVP shall export redacted diagnostic logs. | SE-07, SE-10, SE-11, SE-12, SE-13, SE-15, SE-16, SE-17 | SysDes-025, SysDes-028, SysDes-029, SysDes-042, SysDes-047 | + + +## Appendix B — ASPICE SYS.3 Base Practice Coverage + +| ASPICE SYS.3 area | Evidence in this SysDes | +|---|---| +| BP1 Static aspects of system architecture | Sections 4, 5, 6 and Appendix A define system boundary, system elements, relationships, and interfaces. | +| BP2 Dynamic aspects of system architecture | Section 7 defines states, modes, and major interaction flows. | +| BP3 Analyze system architecture | Sections 3, 8, and 9 define criteria, rationale, special characteristics, performance, reliability, security, privacy, and deployment analysis. | +| BP4 Consistency and bidirectional traceability | Sections 5 and 10 plus Appendix A allocate every SysRS requirement to system elements and design items; Section 1.5 and SysDes-108 through SysDes-110 define the downstream SRS derivation rule. | +| BP5 Communicate agreed system architecture | Section 11 defines review, agreement, communication, baselining, and affected parties. | + +--- + +## Appendix C — Open Architecture Issues + +| Issue ID | Issue | Owner | Target Resolution | +|---|---|---|---| +| OAI-001 | Confirm selected `tsclientlib` version and feature coverage. | Protocol owner | Before SRS baseline | +| OAI-002 | Decide audio processing backend per platform. | Audio owner | Before SAD baseline | +| OAI-003 | Decide minimum supported iOS and Android versions. | Platform owner | Before SRS baseline | +| OAI-004 | Decide whether multiple simultaneous server connections are in MVP. | Product owner | Before SRS baseline | +| OAI-005 | Confirm legal wording for compatible server claims. | Product/legal owner | Before release verification | +| OAI-006 | Confirm secure storage implementation details per platform. | Security/platform owner | Before SDD baseline | + +--- + +## Appendix D — Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-13 | Initial SysDes draft from SysRS | +| 0.2.0 | 2026-05-13 | Updated IDs to SysDes-XXX | +| 0.3.0 | 2026-05-13 | Reworked to follow ASPICE SYS.3 System Architectural Design structure and cover all SysRS IDs | +| 0.4.0 | 2026-05-13 | Added Type, Stage, Allocation, Downstream Artifact, Verification Method, and Verification Owner attributes to all SysDes design items | +| 0.5.0 | 2026-05-13 | Added downstream SRS derivation rule: SRS shall trace directly to SysDes only; if software needs cannot be derived from SysDes, update SysDes first | + + +--- + +## 14. UI/UX, Platform Adaptation, and Internationalization Architecture Addendum + +The following `SysDes-XXX` items extend the SYS.3 System Architectural Design baseline. They allocate `SysRS-258` through `SysRS-285` to system elements and define the downstream software-design handoff. This addendum preserves the strict lifecycle traceability chain: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +SRS items shall derive from `SysDes-XXX` only. SAD items shall derive from `SRS-XXX` only. SDD items shall derive from `SAD-XXX` only. + +**SysDes-111**: The system architecture shall adopt Material 3 as the baseline UI design system for the Flutter client and shall define Chanora-specific UI semantics above it. + +- Status: Baseline +- Type: Architecture Decision / Rationale +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Architecture analysis, static architecture +- Allocated SysRS: SysRS-258, SysRS-259 + +**SysDes-112**: The system architecture shall allocate Material 3 theming to a dedicated Design System element rather than to feature screens. + +- Status: Baseline +- Type: Allocation Rule +- Stage: P0 / MVP +- Allocated to: Design System, Flutter UI +- Downstream artifact: SRS, SAD, SDD +- Verification method: Review, Inspection +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, consistency +- Allocated SysRS: SysRS-258, SysRS-259, SysRS-284 + +**SysDes-113**: The Design System element shall own `ThemeData`, `ColorScheme`, typography mapping, shape mapping, elevation mapping, motion mapping, and product semantic token mapping. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Design System +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture +- Allocated SysRS: SysRS-258, SysRS-259, SysRS-284 + +**SysDes-114**: The system architecture shall define Chanora semantic tokens for connection state, voice state, latency state, channel state, diagnostics state, and accessibility state. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Design System +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection, Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, analysis +- Allocated SysRS: SysRS-259, SysRS-263, SysRS-284 + +**SysDes-115**: The system architecture shall allocate compact, medium, and expanded layout selection to an Adaptive Shell element. + +- Status: Baseline +- Type: Static Architecture Design +- Stage: P0 / MVP +- Allocated to: Flutter UI, Adaptive Shell +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture +- Allocated SysRS: SysRS-260, SysRS-261 + +**SysDes-116**: The Adaptive Shell shall keep connection status and primary voice controls visible or directly reachable across compact, medium, and expanded layouts. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Flutter UI, Adaptive Shell, Voice UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: System Test, Demo +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Dynamic architecture +- Allocated SysRS: SysRS-260, SysRS-261 + +**SysDes-117**: The system architecture shall allocate accessibility semantics, non-color-only state expression, text scaling, and focus visibility to the Flutter UI and Design System elements. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Accessibility Test, Review +- Verification owner: Software QA / Accessibility QA +- ASPICE SYS.3 alignment: Architecture analysis, consistency +- Allocated SysRS: SysRS-262, SysRS-263, SysRS-264, SysRS-265, SysRS-282 + +**SysDes-118**: The platform architecture shall allocate safe areas, display cutouts, system bars, virtual keyboards, desktop insets, Android back behavior, and iOS navigation behavior to Platform Adapter and Flutter Shell elements. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Platform Adapter, Flutter Shell +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Platform Test, Integration Test +- Verification owner: Platform QA +- ASPICE SYS.3 alignment: Interface definition, dynamic architecture +- Allocated SysRS: SysRS-266, SysRS-267, SysRS-268 + +**SysDes-119**: The system architecture shall allocate user-visible string localization to a Localization Service used by Flutter UI and diagnostics presentation. + +- Status: Baseline +- Type: System Element Allocation +- Stage: P0 / MVP +- Allocated to: Localization Service, Flutter UI, Diagnostics +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, interface definition +- Allocated SysRS: SysRS-269, SysRS-270, SysRS-271, SysRS-272, SysRS-279, SysRS-280, SysRS-282 + +**SysDes-120**: The system architecture shall allocate server-provided names and messages to a Content Text path that is displayed without product localization or translation. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core, Flutter UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test, System Test +- Verification owner: Protocol / Software QA +- ASPICE SYS.3 alignment: Interface definition, dynamic architecture +- Allocated SysRS: SysRS-273, SysRS-281 + +**SysDes-121**: The system architecture shall standardize UTF-8 as the internal text representation across Flutter, Rust Core, storage, diagnostics, and protocol-facing adapter DTOs. + +- Status: Baseline +- Type: Architectural Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Bridge, Rust Core, Storage, Diagnostics, Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Software QA / Protocol QA +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-274, SysRS-276 + +**SysDes-122**: The system architecture shall isolate non-UTF-8 or platform-specific string conversion at explicit boundary adapters. + +- Status: Baseline +- Type: Interface Design +- Stage: P1 / Beta +- Allocated to: Protocol Adapter, Platform Adapter, Bridge +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Integration Test +- Verification owner: Protocol / Platform QA +- ASPICE SYS.3 alignment: Interface definition, architecture analysis +- Allocated SysRS: SysRS-275 + +**SysDes-123**: The system architecture shall allocate bidirectional text rendering and locale-aware formatting to Flutter UI and Localization Service components. + +- Status: Baseline +- Type: Non-functional Architecture Design +- Stage: P1 / Beta +- Allocated to: Flutter UI, Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture +- Allocated SysRS: SysRS-277, SysRS-278 + +**SysDes-124**: The diagnostics architecture shall keep machine-readable diagnostic keys language-neutral while allowing user-facing descriptions to be localized. + +- Status: Baseline +- Type: Interface Design +- Stage: P1 / Beta +- Allocated to: Diagnostics, Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Inspection, Test +- Verification owner: Diagnostics QA +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-276, SysRS-280 + +**SysDes-125**: The system architecture shall define UI/UX guideline, design token, component catalog, adaptive layout, and platform behavior documents as downstream design baselines. + +- Status: Baseline +- Type: Process / Description +- Stage: P1 / Beta +- Allocated to: System Engineering, UX, Software Team +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review +- Verification owner: System Engineering +- ASPICE SYS.3 alignment: Communication of agreed architecture +- Allocated SysRS: SysRS-283, SysRS-284 + +**SysDes-126**: The system architecture shall enforce lifecycle traceability so that SysDes covers SysRS, SRS covers software-related SysDes, SAD covers SRS, and SDD covers SAD. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: System Engineering, Software Engineering, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Inspection +- Verification owner: System Engineering / Verification +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-127**: The system architecture shall prevent SRS requirements from linking directly to SysRS IDs; SRS shall use `Source SysDes` only. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: Software Engineering, System Engineering +- Downstream artifact: SRS +- Verification method: Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-128**: The system architecture shall prevent SAD architecture items from linking directly to SysRS or SysDes IDs; SAD shall use `Source SRS` only. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: Software Architecture, System Engineering +- Downstream artifact: SAD +- Verification method: Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-129**: The system architecture shall prevent SDD detailed design items from linking directly to SysRS, SysDes, or SRS IDs; SDD shall use `Source SAD` only. + +- Status: Baseline +- Type: Traceability / Consistency Rule +- Stage: P0 / MVP +- Allocated to: Software Design, System Engineering +- Downstream artifact: SDD +- Verification method: Inspection +- Verification owner: System Engineering / Software QA +- ASPICE SYS.3 alignment: Traceability and consistency +- Allocated SysRS: SysRS-285 + +**SysDes-130**: The system architecture shall allocate localized accessibility labels for icon-only controls to the Design System and Localization Service. + +- Status: Baseline +- Type: Interface Design +- Stage: P0 / MVP +- Allocated to: Design System, Localization Service, Flutter UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Accessibility Test, Inspection +- Verification owner: Software QA / Accessibility QA +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-262, SysRS-269, SysRS-282 + +**SysDes-131**: The system architecture shall allocate language fallback behavior to the Localization Service and require deterministic fallback to the baseline product language. + +- Status: Baseline +- Type: Functional Dynamic Design +- Stage: P0 / MVP +- Allocated to: Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Dynamic architecture +- Allocated SysRS: SysRS-271, SysRS-279 + +**SysDes-132**: The system architecture shall allocate theme and localization initialization to application startup before feature screens render user-visible content. + +- Status: Baseline +- Type: Dynamic Architecture +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Design System, Localization Service +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Integration Test +- Verification owner: Software QA +- ASPICE SYS.3 alignment: Dynamic architecture +- Allocated SysRS: SysRS-258, SysRS-269, SysRS-270, SysRS-279 + +## 15. Updated SysRS to SysDes Coverage Statement + +This SysDes version covers all known SysRS requirements from `SysRS-001` through `SysRS-285`. + +| SysRS Range | SysDes Coverage | +|---|---| +| SysRS-001 through SysRS-257 | Covered by inherited SysDes baseline `SysDes-001` through `SysDes-110` | +| SysRS-258 through SysRS-285 | Covered by `SysDes-111` through `SysDes-132` | + +## Appendix E — Change History + +| Version | Date | Description | +|---|---|---| +| 0.6.0 | 2026-05-14 | Added Material 3, Chanora Design System, adaptive layout, accessibility, platform UI behavior, localization, Unicode, and strict layer-by-layer traceability architecture items. | + +--- + +## 16. Platform Baseline and Product Decision Architecture Addendum + +**SysDes-133**: The system architecture shall allocate iOS runtime minimum version policy to platform configuration, platform verification, release readiness, and iOS platform services. + +- Status: Baseline Candidate +- Type: Platform Architecture Decision +- Stage: P0 / MVP +- Allocated to: Platform Adapter, Release / Operations, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Platform Test +- Verification owner: Platform QA +- ASPICE SYS.3 alignment: Static architecture, consistency +- Allocated SysRS: SysRS-286 + +**SysDes-134**: The system architecture shall allocate Apple App Store Connect upload SDK compliance to release engineering and release readiness rather than runtime feature logic. + +- Status: Baseline Candidate +- Type: Release Architecture Decision +- Stage: P0 / MVP +- Allocated to: Release / Operations, iOS Build Configuration, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Release Inspection +- Verification owner: Release Manager +- ASPICE SYS.3 alignment: Architecture constraints, communication +- Allocated SysRS: SysRS-287 + +**SysDes-135**: The system architecture shall allocate Android minimum runtime version policy and Google Play target SDK compliance to Android platform configuration, platform verification, and release readiness. + +- Status: Baseline Candidate +- Type: Platform Architecture Decision +- Stage: P0 / MVP +- Allocated to: Platform Adapter, Android Build Configuration, Release / Operations, Verification +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, Platform Test, Release Inspection +- Verification owner: Android Owner / Release Manager +- ASPICE SYS.3 alignment: Architecture constraints, consistency +- Allocated SysRS: SysRS-288, SysRS-289 + +**SysDes-136**: The system architecture shall constrain MVP runtime state, UI, audio routing, and protocol orchestration to one active server connection per client instance. + +- Status: Baseline Candidate +- Type: Functional Architecture Decision +- Stage: P0 / MVP +- Allocated to: Rust Core, Flutter UI, State Sync, Audio Subsystem, Protocol Adapter +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Review, System Test +- Verification owner: System Engineering / QA +- ASPICE SYS.3 alignment: Static architecture, dynamic architecture +- Allocated SysRS: SysRS-290 + +**SysDes-137**: The system architecture shall allocate AEC, AGC, Noise Suppression, and High-Pass Filter default enablement to the audio subsystem with platform capability detection and user-setting control. + +- Status: Baseline Candidate +- Type: Audio Architecture Decision +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Audio, Settings UI +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Audio Test, Review +- Verification owner: Audio / Platform QA +- ASPICE SYS.3 alignment: Dynamic architecture, architecture analysis +- Allocated SysRS: SysRS-291 + +**SysDes-138**: The system architecture shall prefer platform-native audio processing for MVP and isolate any Rust/WebRTC-style fallback behind the audio subsystem boundary. + +- Status: Baseline Candidate +- Type: Audio Architecture Decision +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Audio Adapter, Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Architecture Review, Audio Test +- Verification owner: Software Architect / Audio Owner +- ASPICE SYS.3 alignment: Architecture analysis, interface definition +- Allocated SysRS: SysRS-292 + +**SysDes-139**: The system architecture shall allocate non-secret local state to SQLite or an equivalent embedded database and secrets to platform secure storage. + +- Status: Baseline Candidate +- Type: Storage Architecture Decision +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage, Security +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Storage Test, Security Audit +- Verification owner: Storage Owner / Security +- ASPICE SYS.3 alignment: Static architecture, interface definition +- Allocated SysRS: SysRS-293 + +**SysDes-140**: The system architecture shall allocate Flutter/Rust communication to a stable typed bridge with generated or schema-controlled DTOs. + +- Status: Baseline Candidate +- Type: Interface Architecture Decision +- Stage: P0 / MVP +- Allocated to: Bridge, Flutter State, Rust Core +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Architecture Review, Integration Test +- Verification owner: Software Architect +- ASPICE SYS.3 alignment: Interface definition, consistency +- Allocated SysRS: SysRS-294 + +**SysDes-141**: The system architecture shall exclude automatic diagnostic upload, telemetry upload, and automatic crash reporting from MVP runtime behavior unless a later approved decision updates privacy, security, legal, release, and verification baselines. + +- Status: Baseline Candidate +- Type: Privacy Architecture Decision +- Stage: P0 / MVP +- Allocated to: Diagnostics, Privacy, Release / Operations, Security +- Downstream artifact: SRS, SAD, SDD, Verification +- Verification method: Privacy Review, Security Audit +- Verification owner: Security / Privacy Reviewer +- ASPICE SYS.3 alignment: Architecture constraints, communication +- Allocated SysRS: SysRS-295 + +## 17. Updated SysRS Coverage Statement + +This SysDes version covers all known SysRS requirements from `SysRS-001` through `SysRS-295`. + +| 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` | + + +## 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. | diff --git a/docs/governance/baseline-approval-record.md b/docs/governance/baseline-approval-record.md new file mode 100644 index 0000000..5b81205 --- /dev/null +++ b/docs/governance/baseline-approval-record.md @@ -0,0 +1,65 @@ + +# CHANORA_CFG_Baseline_Approval_Record_v0.9.2.2.1 + +**Document type:** Configuration / Baseline Approval Record +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/baseline-approval-record.md` --- + +## 1. Baseline + +| Field | Value | +|---|---| +| Baseline name | Chanora MVP Baseline Candidate | +| Baseline version | 0.9.0 | +| Package | `CHANORA_Documentation_Baseline_Candidate_v0.9.2.2.1.zip` | +| Approval target | Promote to `v1.0 Final / Approved Baseline` after review approval | + +## 2. Approval Decision + +| Decision | Value | +|---|---| +| Approved | Pending | +| Approved with conditions | Pending | +| Rejected | Pending | + +## 3. Approvers + +| Role | Name | Decision | Date | Signature / Evidence | +|---|---|---|---|---| +| Product owner | TBD | Pending | TBD | TBD | +| System architect | TBD | Pending | TBD | TBD | +| Software architect | TBD | Pending | TBD | TBD | +| Software lead | TBD | Pending | TBD | TBD | +| QA / verification owner | TBD | Pending | TBD | TBD | +| Security reviewer | TBD | Pending | TBD | TBD | +| UX owner | TBD | Pending | TBD | TBD | +| Platform owner | TBD | Pending | TBD | TBD | + +## 4. Open Issues + +| Issue ID | Description | Disposition | +|---|---|---| +| TBD | TBD | TBD | + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Baseline approval record template for normalized package. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/governance/baseline-candidate-validation-report.md b/docs/governance/baseline-candidate-validation-report.md new file mode 100644 index 0000000..a0739dd --- /dev/null +++ b/docs/governance/baseline-candidate-validation-report.md @@ -0,0 +1,73 @@ +# Cfg Baseline Candidate Validation Report + +**Document type:** Configuration / Validation Report +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/baseline-candidate-validation-report.md` --- + +## 1. Package + +```text +chanora-docs-repo-format-v0.9.2.zip +``` + +## 2. File Count + +| Type | Count | +|---|---:| +| Markdown files | 36 | + +## 3. Defined ID Counts + +| ID family | Defined IDs | +|---|---:| +| SysRS | 295 | +| SysDes | 141 | +| SRS | 194 | +| SAD | 70 | +| SDD | 80 | + +## 4. Undefined Reference Check + +| ID family | Undefined references | +|---|---:| +| SysRS | 0 | +| SysDes | 0 | +| SRS | 0 | +| SAD | 0 | +| SDD | 0 | + +## 5. Direct-Layer Rule Check + +| Rule | Result | +|---|---:| +| SRS direct SysRS references | 0 | +| SAD direct SysRS references | 0 | +| SAD direct SysDes references | 0 | +| SDD direct SysRS references | 0 | +| SDD direct SysDes references | 0 | +| SDD direct SRS references | 0 | + +## 6. Language Check + +| Check | Result | +|---|---:| +| CJK characters found | 0 | + +## 7. Apple Gate Coverage Check + +| Item | Coverage | +|---|---| +| Runtime deployment target | iOS 13+ remains separate runtime policy | +| App Store Connect upload SDK gate | Xcode 26+ and iOS 26 / iPadOS 26 SDK+ for upload on or after 2026-04-28 | +| Link chain | SysRS-287 -> SysDes-134 -> SRS-186 -> SAD-062 -> SDD-072 | +| Internal Alpha / local development distinction | Captured in Platform Release Policy | +| TestFlight / App Store upload distinction | Captured in Platform Release Policy | + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Validation report for Apple App Store Connect upload SDK gate correction, full file update, and coverage check. | diff --git a/docs/governance/decision-impact-assessment.md b/docs/governance/decision-impact-assessment.md new file mode 100644 index 0000000..5e004e6 --- /dev/null +++ b/docs/governance/decision-impact-assessment.md @@ -0,0 +1,79 @@ + +# CHANORA_CFG_Decision_Impact_Assessment_v0.9.2.2.1 + +**Document type:** Configuration / Decision Impact Assessment +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/decision-impact-assessment.md` --- + +## 1. Purpose + +This document records how key unresolved product and architecture decisions affect requirements, architecture, detailed design, verification, release readiness, security, privacy, and legal work products. + +## 2. High-Impact Decision Assessment + +| Decision | Recommended decision | Impact if changed later | +|---|---|---| +| Minimum iOS version | iOS 13 | Test matrix, platform support policy, app store build configuration, platform behavior tests. | +| Minimum Android version | API 24 | Device support, permissions, audio routing, Google Play compatibility, platform tests. | +| Android target SDK | Google Play-required API level on upload date; current release gate uses API 35+ unless newer policy applies | +| Apple App Store SDK gate | Xcode 26+ with iOS 26 / iPadOS 26 SDK+ for App Store Connect upload on or after 2026-04-28 unless newer Apple upload policy applies | Google Play submission eligibility and platform permission behavior. | +| Multiple active connections | Exclude from MVP | If added later, affects state model, audio routing, UI layout, reconnection logic, storage, verification. | +| AEC/AGC/NS/HPF defaults | Enabled by default where supported | Affects UX, CPU, platform-specific audio settings, verification matrix. | +| Audio processing path | Platform-native first; fallback later | Affects audio architecture, Rust/native dependencies, latency, CPU, platform compatibility. | +| Trademark/legal review | Required before public/store release | Blocks public release if unresolved. | +| Local DB | SQLite or equivalent | Affects storage schema, migrations, backup/delete policy, tests. | +| Bridge | Stable typed generated/schema-controlled bridge | Affects API stability, async event flow, maintainability, code generation, tests. | +| Diagnostics upload | No automatic upload in MVP | Affects privacy policy, security review, support process. | +| Crash reporting | Disabled unless later approved | Affects privacy/legal docs, dependency and supply-chain review. | + +## 3. Document Update Rules + +| If decision changes | Update required | +|---|---| +| Minimum iOS/Android version changes | SysRS, SysDes, SRS, SAD, SDD, SYS.4, SWE.6, Release Readiness | +| Apple SDK submission gate changes | SysRS, SysDes, SRS, SAD, SDD, SWE.6, Release Readiness | +| Android target SDK changes | SRS, SWE.6, Release Readiness, Platform Guide | +| Multiple connections added to MVP | SysRS, SysDes, SRS, SAD, SDD, SWE.4, SWE.5, SWE.6, SYS.4 | +| Audio defaults change | SysRS, SysDes, SRS, SAD, SDD, SWE.4, SWE.5, SWE.6 | +| Audio implementation path changes | SysDes, SAD, SDD, SWE.4, SWE.5, SYS.4 | +| Legal/trademark policy changes | Release Readiness, Legal Review, Privacy Policy, External References | +| DB choice changes | SysDes, SRS, SAD, SDD, SWE.4, SWE.5 | +| Bridge choice changes | SysDes, SAD, SDD, SWE.4, SWE.5 | +| Diagnostics upload enabled | SysRS, SysDes, SRS, SAD, SDD, Threat Model, Privacy Policy, Redaction Audit, Release Readiness | +| Crash reporting enabled | SysRS, SysDes, SRS, SAD, SDD, Privacy Policy, Dependency Report, Release Readiness | + +## 4. Recommended Decision Closure Sequence + +1. Confirm release type and staged platform policy. +2. Confirm mobile minimum versions and Android target SDK policy. +3. Confirm one active server connection for MVP. +4. Confirm audio processing defaults. +5. Confirm audio implementation path. +6. Confirm diagnostics/crash reporting privacy policy. +7. Confirm SQLite/equivalent local database. +8. Confirm bridge choice. +9. Confirm legal/trademark/public wording review requirement. +10. Confirm license model before public release. + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial decision impact assessment for key product and architecture decisions. | + + +## 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+ for App Store Connect upload on or after 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/governance/development-environment.md b/docs/governance/development-environment.md new file mode 100644 index 0000000..06fd6f7 --- /dev/null +++ b/docs/governance/development-environment.md @@ -0,0 +1,60 @@ +# Development Environment + +**Document type:** Governance / Development Environment +**Version:** 0.1.0 +**Status:** Draft +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/development-environment.md` + +--- + +## 1. Purpose + +This document records the intended local development environment for Chanora. + +## 2. Required Toolchains + +The exact versions shall be finalized when the Flutter and Rust workspaces are created. + +Expected tools: + +| Tool | Purpose | +|---|---| +| Flutter SDK | Cross-platform UI | +| Dart SDK | Flutter development | +| Rust toolchain | Core, protocol, audio, storage, diagnostics | +| Cargo | Rust package/build tool | +| just | Local command runner | +| Python 3 | Documentation validation scripts | +| Xcode | iOS/iPadOS/macOS development and App Store Connect upload builds | +| Android Studio / Android SDK | Android development | +| CMake / native build tools | Native dependencies if required | + +## 3. Platform Notes + +| Platform | Notes | +|---|---| +| iOS / iPadOS | App Store Connect upload on or after 2026-04-28 requires Xcode 26+ and iOS 26 / iPadOS 26 SDK+. | +| Android | Store upload must target the Google Play-required API level on upload date. | +| Desktop | Windows, macOS, and Linux build requirements shall be finalized during scaffold and release planning. | + +## 4. Local Commands + +Local commands are defined in `justfile`. + +Initial commands: + +```bash +just format +just lint +just test +just verify-docs +just security-scan +``` + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial development environment document. | diff --git a/docs/governance/document-index.md b/docs/governance/document-index.md new file mode 100644 index 0000000..c8fba6b --- /dev/null +++ b/docs/governance/document-index.md @@ -0,0 +1,86 @@ +# Document Index + +**Document type:** Configuration / Documentation Control +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/document-index.md` + +--- + +## 1. Purpose + +This document lists the normalized latest files included in the Chanora repository documentation package. + +## 2. Current Baseline Candidate Files + +| File | Status | +|---|---| +| `docs/architecture/sad.md` | Baseline Candidate | +| `docs/architecture/sdd.md` | Baseline Candidate | +| `docs/architecture/sysdes.md` | Baseline Candidate | +| `docs/governance/baseline-approval-record.md` | Baseline Candidate | +| `docs/governance/baseline-candidate-validation-report.md` | Baseline Candidate | +| `docs/governance/decision-impact-assessment.md` | Baseline Candidate | +| `docs/governance/document-naming-convention.md` | Baseline Candidate | +| `docs/governance/document-review-report.md` | Baseline Candidate | +| `docs/governance/git-commit-message-convention.md` | Baseline Candidate | +| `docs/governance/path-migration-map.md` | Baseline Candidate | +| `docs/governance/product-decision-register.md` | Baseline Candidate | +| `docs/governance/repo-format-validation-report.md` | Baseline Candidate | +| `docs/governance/traceability-matrix.md` | Baseline Candidate | +| `docs/i18n/localization-architecture.md` | Baseline Candidate | +| `docs/legal/trademark-and-attribution-review.md` | Baseline Candidate | +| `docs/privacy/privacy-policy.md` | Baseline Candidate | +| `docs/references/aspice-swe2-swe3-integration-note.md` | Baseline Candidate | +| `docs/references/external-references.md` | Baseline Candidate | +| `docs/release/platform-release-policy.md` | Baseline Candidate | +| `docs/release/release-readiness-go-nogo-record.md` | Baseline Candidate | +| `docs/requirements/srs.md` | Baseline Candidate | +| `docs/requirements/sysrs.md` | Baseline Candidate | +| `docs/security/dependency-and-supply-chain-report.md` | Baseline Candidate | +| `docs/security/diagnostic-redaction-audit-report.md` | Baseline Candidate | +| `docs/security/secure-storage-audit-report.md` | Baseline Candidate | +| `docs/security/security-privacy-legal-guideline.md` | Baseline Candidate | +| `docs/security/threat-model.md` | Baseline Candidate | +| `docs/ui-ux/adaptive-layout-platform-guide.md` | Baseline Candidate | +| `docs/ui-ux/material3-component-catalog.md` | Baseline Candidate | +| `docs/ui-ux/material3-design-tokens.md` | Baseline Candidate | +| `docs/ui-ux/material3-guideline.md` | Baseline Candidate | +| `docs/verification/swe4-unit-verification-plan.md` | Baseline Candidate | +| `docs/verification/swe5-software-integration-verification-plan.md` | Baseline Candidate | +| `docs/verification/swe6-software-verification-plan.md` | Baseline Candidate | +| `docs/verification/sys4-system-integration-verification-plan.md` | Baseline Candidate | +| `docs/verification/verification-master-plan.md` | Baseline Candidate | + +## 3. Core Engineering Hierarchy + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +## 4. Verification Work Product Mapping + +```text +SDD -> SWE.4 +SAD + SDD -> SWE.5 +SRS -> SWE.6 +SysDes -> SYS.4 +``` + +## 5. Repo File Naming Rules + +| Rule | Decision | +|---|---| +| Product prefix in file names | Not used under `docs/` | +| Case style | lowercase kebab-case | +| Version in file name | Not used | +| Version location | Inside document metadata | +| Release package version | Used in ZIP/package name | + +## 6. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Converted documentation package to repository-oriented docs folder structure and updated internal filename references. | diff --git a/docs/governance/document-naming-convention.md b/docs/governance/document-naming-convention.md new file mode 100644 index 0000000..1039ac8 --- /dev/null +++ b/docs/governance/document-naming-convention.md @@ -0,0 +1,66 @@ +# Document Naming Convention + +**Document type:** Configuration / Documentation Control +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/document-naming-convention.md` + +--- + +## 1. Purpose + +This document defines the official repository documentation naming convention for Chanora. + +## 2. Repository Path Pattern + +Markdown documents under the repository shall use this pattern: + +```text +docs//.md +``` + +Examples: + +```text +docs/requirements/sysrs.md +docs/architecture/sad.md +docs/verification/swe4-unit-verification-plan.md +docs/release/release-readiness-go-nogo-record.md +docs/security/threat-model.md +``` + +## 3. Rules + +| Rule | Decision | +|---|---| +| Product prefix | Do not use `CHANORA_` inside repo file names. | +| Version in filename | Do not include document version in repo file names. | +| Filename style | Use lowercase kebab-case. | +| Directory style | Use lowercase kebab-case. | +| Version metadata | Keep version inside the Markdown document. | +| Status metadata | Keep status inside the Markdown document. | +| Release artifacts | ZIP/package names may include project name and version. | + +## 4. Top-Level Documentation Categories + +| Directory | Purpose | +|---|---| +| `docs/requirements/` | SysRS and SRS | +| `docs/architecture/` | SysDes, SAD, SDD | +| `docs/verification/` | SWE.4, SWE.5, SWE.6, SYS.4, verification master plan | +| `docs/release/` | Release readiness and platform release policy | +| `docs/security/` | Threat model, secure storage, redaction, dependency/supply-chain, security guidelines | +| `docs/privacy/` | Privacy policy | +| `docs/legal/` | Trademark and attribution review | +| `docs/ui-ux/` | UI/UX, Material 3, design tokens, component catalog, adaptive layout | +| `docs/i18n/` | Localization architecture | +| `docs/governance/` | Index, traceability, approval, validation, review, decisions, commit convention | +| `docs/references/` | External references and research notes | + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Replaced release-package naming convention with repository docs naming convention. | diff --git a/docs/governance/document-review-report.md b/docs/governance/document-review-report.md new file mode 100644 index 0000000..ca08c65 --- /dev/null +++ b/docs/governance/document-review-report.md @@ -0,0 +1,90 @@ +# Cfg Document Review Report V0.9.2.2.1 + +**Document type:** Configuration / Review Report +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/document-review-report.md` --- + +## 1. Executive Summary + +The normalized package is suitable as a **Baseline Candidate v0.9** for human review. + +The package fixes the earlier draft-package issues: + +- superseded original filenames are not included in the normalized package; +- all filenames follow a consistent naming convention; +- the package contains only baseline-candidate files; +- non-English text from the earlier draft metadata has been removed; +- undefined system-design references have been removed from the verification planning package; +- a naming convention, approval record template, document index, and validation report are included. + +The package is still **not Final** until human review and approval are completed. + +## 2. Recommended Status + +| Decision | Result | +|---|---| +| Ready for Final / Approved Baseline | No | +| Ready for Baseline Candidate review | Yes | +| Recommended current status | Baseline Candidate v0.9 | +| Next target status after approval | Final / Approved Baseline v1.0 | + +## 3. Positive Review Findings + +| Area | Result | +|---|---| +| File naming | Normalized | +| Package scope | Latest baseline-candidate files only | +| Core hierarchy | `SysRS -> SysDes -> SRS -> SAD -> SDD` | +| Verification mapping | `SDD -> SWE.4`, `SAD + SDD -> SWE.5`, `SRS -> SWE.6`, `SysDes -> SYS.4` | +| SRS direct-source rule | SRS does not directly link to system-requirement IDs | +| SAD direct-source rule | SAD links directly to SRS only | +| SDD direct-source rule | SDD links directly to SAD only | +| English-only baseline | Passed automated CJK check | +| Approval metadata | Approval record template included | + +## 4. Remaining Review Actions Before Final + +| ID | Severity | Action | +|---|---|---| +| REV-ACT-001 | Major | Human stakeholders must review and approve the baseline candidate. | +| REV-ACT-002 | Major | Review comments must be recorded and dispositioned. | +| REV-ACT-003 | Major | Open issues must be accepted, deferred, or resolved. | +| REV-ACT-004 | Major | Approval record must be completed with names, roles, dates, and decisions. | +| REV-ACT-005 | Major | After approval, promote package and documents from `v0.9.2` to `v1.0`. | + +## 5. Finalization Recommendation + +Do not call this package Final until the approval record is completed. + +Recommended workflow: + +```text +Baseline Candidate v0.9.1 + -> Human review + -> Review comment disposition + -> Approval record completed + -> Promote to v1.0 Final / Approved Baseline +``` + +## 6. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Review report for normalized baseline candidate package. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/governance/git-commit-message-convention.md b/docs/governance/git-commit-message-convention.md new file mode 100644 index 0000000..887d31f --- /dev/null +++ b/docs/governance/git-commit-message-convention.md @@ -0,0 +1,185 @@ + +# CHANORA_CFG_Git_Commit_Message_Convention_v0.9.2.2.1 + +**Document type:** Configuration / Engineering Convention +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/git-commit-message-convention.md` --- + +## 1. Purpose + +This document defines the Git commit message convention for Chanora. + +Chanora shall use a Conventional Commits style format with project-specific scopes. + +## 2. Commit Format + +```text +(): +``` + +Optional body: + +```text +(): + + + +Refs: +``` + +Breaking change format: + +```text +()!: + +BREAKING CHANGE: +``` + +## 3. Commit Types + +| Type | Meaning | +|---|---| +| `feat` | New user-visible or system-visible capability | +| `fix` | Bug fix | +| `docs` | Documentation-only change | +| `style` | Formatting change without behavior change | +| `refactor` | Code restructuring without intended behavior change | +| `perf` | Performance improvement | +| `test` | Test addition or test update | +| `build` | Build system, dependency, packaging, CI artifact change | +| `ci` | CI/CD pipeline change | +| `chore` | Maintenance task | +| `revert` | Revert a previous commit | +| `release` | Release preparation, version bump, release metadata | +| `sec` | Security-specific change | +| `i18n` | Localization, internationalization, Unicode, locale behavior | +| `ux` | UI/UX behavior or interaction change | + +## 4. Recommended Scopes + +| Scope | Area | +|---|---| +| `flutter` | Flutter app in general | +| `ui` | UI components and screens | +| `theme` | Material 3, design tokens, theme extensions | +| `adaptive` | Adaptive layout and window classes | +| `voice` | Voice UI or voice control behavior | +| `audio` | Audio capture, playback, processing, DSP | +| `core` | Rust Core orchestration | +| `protocol` | `tsclientlib` integration and protocol adapter | +| `bridge` | Flutter/Rust bridge and DTOs | +| `state` | State synchronization, reducers, snapshots, events | +| `storage` | Local database or non-secret persistence | +| `secure-storage` | Keychain/Keystore/secret storage | +| `diagnostics` | Logs, redaction, diagnostic export | +| `i18n` | Localization, Unicode, locale formatting, RTL | +| `android` | Android-specific behavior | +| `ios` | iOS-specific behavior | +| `windows` | Windows-specific behavior | +| `macos` | macOS-specific behavior | +| `linux` | Linux-specific behavior | +| `build` | Build tooling | +| `ci` | CI pipeline | +| `release` | Release packaging and release metadata | +| `docs` | Documentation | +| `req` | Requirements documents | +| `sysdes` | System architectural design | +| `srs` | Software requirements | +| `sad` | Software architecture | +| `sdd` | Software detailed design | +| `ver` | Verification documents | + +## 5. Examples + +```text +feat(voice): add push-to-talk state handling +``` + +```text +fix(protocol): recover channel tree after reconnect snapshot +``` + +```text +docs(sad): add interface catalog and performance view +``` + +```text +i18n(ui): add fallback behavior for missing localization keys +``` + +```text +sec(diagnostics): redact server password from export bundle +``` + +```text +test(audio): add unit tests for audio meter level clamping +``` + +```text +release(android): prepare internal alpha build metadata +``` + +## 6. Requirement and Document References + +When relevant, the commit body should reference affected IDs. + +Allowed examples: + +```text +Refs: SRS-156, SAD-013, SDD-017 +``` + +```text +Refs: SWE4-UV-011 +``` + +Do not force every commit to reference a requirement. Use references when the change affects requirements, architecture, detailed design, verification, release, security, or traceability. + +## 7. Pull Request Title Rule + +Pull request titles should follow the same format as commit messages when possible: + +```text +feat(voice): add persistent VoiceBar controls +``` + +## 8. Branch Naming + +Recommended branch format: + +```text +/ +``` + +Examples: + +```text +feature/voicebar-controls +fix/reconnect-state-sync +docs/baseline-candidate-v09 +release/internal-alpha-001 +hotfix/diagnostic-redaction +``` + +## 9. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial Git commit message convention for Chanora. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/governance/path-migration-map.md b/docs/governance/path-migration-map.md new file mode 100644 index 0000000..cdea2c8 --- /dev/null +++ b/docs/governance/path-migration-map.md @@ -0,0 +1,60 @@ +# Documentation Path Migration Map + +**Document type:** Configuration / Migration Map +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/path-migration-map.md` + +--- + +## 1. Purpose + +This document maps the previous package-style filenames to the new repository documentation paths. + +## 2. Migration Map + +| Previous package filename | New repo path | +|---|---| +| `CHANORA_SAD_ASPICE_SWE2_Software_Architecture_Description_v0.9.2.md` | `docs/architecture/sad.md` | +| `CHANORA_SDD_ASPICE_SWE3_Software_Detailed_Design_v0.9.2.md` | `docs/architecture/sdd.md` | +| `CHANORA_SYSDES_ASPICE_SYS3_System_Architectural_Design_v0.9.2.md` | `docs/architecture/sysdes.md` | +| `CHANORA_CFG_Baseline_Approval_Record_v0.9.2.md` | `docs/governance/baseline-approval-record.md` | +| `CHANORA_CFG_Baseline_Candidate_Validation_Report_v0.9.2.md` | `docs/governance/baseline-candidate-validation-report.md` | +| `CHANORA_CFG_Decision_Impact_Assessment_v0.9.2.md` | `docs/governance/decision-impact-assessment.md` | +| `CHANORA_CFG_Document_Index_v0.9.2.md` | `docs/governance/document-index.md` | +| `CHANORA_CFG_Document_Naming_Convention_v0.9.2.md` | `docs/governance/document-naming-convention.md` | +| `CHANORA_CFG_Document_Review_Report_v0.9.2.md` | `docs/governance/document-review-report.md` | +| `CHANORA_CFG_Git_Commit_Message_Convention_v0.9.2.md` | `docs/governance/git-commit-message-convention.md` | +| `CHANORA_CFG_Product_Decision_Register_v0.9.2.md` | `docs/governance/product-decision-register.md` | +| `CHANORA_CFG_Traceability_Matrix_v0.9.2.md` | `docs/governance/traceability-matrix.md` | +| `CHANORA_I18N_Localization_Architecture_v0.9.2.md` | `docs/i18n/localization-architecture.md` | +| `CHANORA_LEGAL_Trademark_And_Attribution_Review_v0.9.2.md` | `docs/legal/trademark-and-attribution-review.md` | +| `CHANORA_PRIV_Privacy_Policy_v0.9.2.md` | `docs/privacy/privacy-policy.md` | +| `CHANORA_REFS_ASPICE_SWE2_SWE3_Integration_Note_v0.9.2.md` | `docs/references/aspice-swe2-swe3-integration-note.md` | +| `CHANORA_CFG_External_References_v0.9.2.md` | `docs/references/external-references.md` | +| `CHANORA_REL_Platform_Release_Policy_v0.9.2.md` | `docs/release/platform-release-policy.md` | +| `CHANORA_REL_Release_Readiness_Go_NoGo_Record_v0.9.2.md` | `docs/release/release-readiness-go-nogo-record.md` | +| `CHANORA_SRS_ASPICE_SWE1_Software_Requirements_Specification_v0.9.2.md` | `docs/requirements/srs.md` | +| `CHANORA_SYSRS_System_Requirements_Specification_v0.9.2.md` | `docs/requirements/sysrs.md` | +| `CHANORA_SEC_Dependency_And_Supply_Chain_Report_v0.9.2.md` | `docs/security/dependency-and-supply-chain-report.md` | +| `CHANORA_SEC_Diagnostic_Redaction_Audit_Report_v0.9.2.md` | `docs/security/diagnostic-redaction-audit-report.md` | +| `CHANORA_SEC_Secure_Storage_Audit_Report_v0.9.2.md` | `docs/security/secure-storage-audit-report.md` | +| `CHANORA_SEC_Security_Privacy_Legal_Guideline_v0.9.2.md` | `docs/security/security-privacy-legal-guideline.md` | +| `CHANORA_SEC_Threat_Model_v0.9.2.md` | `docs/security/threat-model.md` | +| `CHANORA_UIUX_Adaptive_Layout_Platform_Guide_v0.9.2.md` | `docs/ui-ux/adaptive-layout-platform-guide.md` | +| `CHANORA_UIUX_Material3_Component_Catalog_v0.9.2.md` | `docs/ui-ux/material3-component-catalog.md` | +| `CHANORA_UIUX_Material3_Design_Tokens_v0.9.2.md` | `docs/ui-ux/material3-design-tokens.md` | +| `CHANORA_UIUX_Material3_Guideline_v0.9.2.md` | `docs/ui-ux/material3-guideline.md` | +| `CHANORA_VER_ASPICE_SWE4_Unit_Verification_Plan_v0.9.2.md` | `docs/verification/swe4-unit-verification-plan.md` | +| `CHANORA_VER_ASPICE_SWE5_Software_Integration_Verification_Plan_v0.9.2.md` | `docs/verification/swe5-software-integration-verification-plan.md` | +| `CHANORA_VER_ASPICE_SWE6_Software_Verification_Plan_v0.9.2.md` | `docs/verification/swe6-software-verification-plan.md` | +| `CHANORA_VER_ASPICE_SYS4_System_Integration_Verification_Plan_v0.9.2.md` | `docs/verification/sys4-system-integration-verification-plan.md` | +| `CHANORA_VER_Master_Plan_v0.9.2.md` | `docs/verification/verification-master-plan.md` | + +## 3. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Initial migration map from package filenames to repo docs paths. | diff --git a/docs/governance/product-decision-register.md b/docs/governance/product-decision-register.md new file mode 100644 index 0000000..cfb568a --- /dev/null +++ b/docs/governance/product-decision-register.md @@ -0,0 +1,145 @@ + +# CHANORA_CFG_Product_Decision_Register_v0.9.2.2.1 + +**Document type:** Configuration / Product Decision Register +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/product-decision-register.md` --- + +## 1. Purpose + +This document records key product, architecture, release, legal, and engineering decisions that affect Chanora scope, testing, architecture, app store eligibility, and release readiness. + +A decision marked **Proposed / Owner Confirmation Required** is a recommended decision that should be confirmed by the owner before Final / Approved Baseline. + +## 2. Decision Status Legend + +| Status | Meaning | +|---|---| +| Proposed / Owner Confirmation Required | Recommended decision; owner must confirm before Final. | +| Accepted | Confirmed and part of baseline. | +| Deferred | Not decided for this release; must not block scope if explicitly deferred. | +| Rejected | Not selected. | + +## 3. Key Blocking Decisions + +| Decision ID | Decision | Recommended decision | Status | Owner | Why it matters | +|---|---|---|---|---|---| +| DEC-001 | Release type | Internal Alpha first, then External Beta, then MVP Public / Store Release | Proposed / Owner Confirmation Required | Product Owner | Controls release gate, verification bar, legal/privacy requirements, and platform scope. | +| DEC-002 | MVP platform scope | MVP target remains Windows, macOS, Linux, Android, and iOS; first release may be staged by channel/platform | Proposed / Owner Confirmation Required | Product Owner + Engineering Owner | Controls verification matrix, build artifacts, store readiness, and support load. | +| DEC-003 | Minimum iOS version | iOS 13 minimum for Flutter support baseline; test latest iOS release separately | Proposed / Owner Confirmation Required | Product Owner + iOS Owner | Controls iOS compatibility, test devices, and app store eligibility. | +| DEC-004 | Minimum Android version | Android API 24 minimum; target API level must satisfy current Google Play policy | Proposed / Owner Confirmation Required | Product Owner + Android Owner | Controls Android device support, runtime permissions, and Play Store eligibility. | +| DEC-005 | Android target SDK | Target the Google Play-required API level on the upload date; current release gate uses API 35+ unless newer Google policy applies | Proposed / Owner Confirmation Required | Android Owner + Release Manager | Required for new apps and updates submitted to Google Play after the current policy date. | +| DEC-006 | Multiple server connections in MVP | Not in MVP; support one active server connection per client instance | Proposed / Owner Confirmation Required | Product Owner + Software Architect | Reduces state synchronization, audio routing, UI complexity, and verification scope. | +| DEC-007 | AEC default state | Enabled by default on platforms/audio backends where supported and stable | Proposed / Owner Confirmation Required | Audio Owner + Product Owner | Affects echo quality, CPU usage, platform behavior, and user experience. | +| DEC-008 | AGC default state | Enabled by default, with user setting to disable | Proposed / Owner Confirmation Required | Audio Owner + Product Owner | Affects perceived loudness consistency and may affect advanced user preference. | +| DEC-009 | Noise suppression default state | Enabled by default, with user setting to disable | Proposed / Owner Confirmation Required | Audio Owner + Product Owner | Improves typical voice quality but may affect voice naturalness and CPU usage. | +| DEC-010 | High-pass filter default state | Enabled by default | Proposed / Owner Confirmation Required | Audio Owner | Removes low-frequency rumble and usually improves speech capture. | +| DEC-011 | Audio processing implementation path | Use platform-native audio processing first where available; use Rust/WebRTC-style processing as controlled fallback or later architecture option | Proposed / Owner Confirmation Required | Software Architect + Audio Owner | Controls architecture, latency, CPU use, platform compatibility, and testing. | +| DEC-012 | Official SDK / trademark / licensing review | Public/store release is blocked until legal confirms TeamSpeak non-affiliation wording, trademark usage, OSS licenses, and `tsclientlib` license posture | Proposed / Owner Confirmation Required | Legal / Compliance + Product Owner | Public release risk and store metadata risk. | +| DEC-013 | Local database choice | Use SQLite or equivalent embedded local database for non-secret local state; secrets remain in platform secure storage | Proposed / Owner Confirmation Required | Software Architect + Storage Owner | Controls storage schema, migrations, backup/delete policy, and portability. | +| DEC-014 | Bridge choice | Use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs; default to `flutter_rust_bridge` unless prototype proves a better option | Proposed / Owner Confirmation Required | Software Architect | Controls API stability, maintainability, async event flow, and long-term code generation. | +| DEC-015 | Product language for MVP | English-only product UI for MVP; i18n-ready architecture; server-provided content preserved and not translated | Proposed / Owner Confirmation Required | Product Owner | Controls localization scope and release schedule. | +| DEC-016 | Diagnostics upload policy | No automatic upload for MVP; user-initiated local diagnostic export only | Proposed / Owner Confirmation Required | Product Owner + Legal + Security | Controls privacy policy, support workflow, and security review scope. | +| DEC-017 | Crash reporting | Disabled for MVP unless explicit opt-in provider and privacy policy are approved | Proposed / Owner Confirmation Required | Product Owner + Legal + Security | Avoids privacy/legal complexity before public release. | +| DEC-018 | Public product name | Chanora | Proposed / Owner Confirmation Required | Product Owner | Branding and legal identity. | +| DEC-019 | Public non-affiliation statement | Use legal-approved wording; draft: “Chanora is independent and is not affiliated with, endorsed by, sponsored by, or officially associated with TeamSpeak.” | Proposed / Legal Confirmation Required | Legal / Compliance | Required for public release and store metadata. | +| DEC-021 | Apple App Store submission SDK | Use Xcode 26 or later and the iOS 26 / iPadOS 26 SDK or later for App Store submission on or after 2026-04-28, unless Apple publishes a newer applicable requirement before upload | Proposed / Owner Confirmation Required | iOS Owner + Release Manager | Controls App Store Connect upload eligibility and release pipeline. | +| DEC-020 | License model | TBD by owner; no public release until license model and OSS obligations are confirmed | Open | Product Owner + Legal | Business and OSS compliance decision. | + +## 4. Recommended MVP Defaults + +| Area | Recommended MVP default | +|---|---| +| Active connections | One active server connection | +| UI design system | Material 3 + Chanora Design System | +| Product language | English UI; i18n-ready | +| Server content | Preserve and display Unicode; do not translate | +| Diagnostics | Local, user-initiated export only | +| Telemetry | None | +| Crash reporting | None unless later approved | +| Secret storage | Platform secure storage | +| Non-secret local storage | SQLite or equivalent | +| Audio processing | Platform-native first; fallback strategy documented | +| AEC | Enabled by default where supported | +| AGC | Enabled by default | +| Noise suppression | Enabled by default | +| High-pass filter | Enabled by default | +| Android minimum | API 24 | +| Android target | API 35 or newer for Google Play policy | +| iOS minimum | iOS 13 | +| Bridge | Stable typed Flutter/Rust bridge; default candidate `flutter_rust_bridge` | + +## 5. Decision Impact Matrix + +| Decision | Affects SysRS | Affects SysDes | Affects SRS | Affects SAD | Affects SDD | Affects Verification | Affects Release | +|---|---|---|---|---|---|---|---| +| Minimum iOS / Android versions | Yes | Yes | Yes | Yes | Yes | Yes | Yes | +| Android target SDK | No | No | Yes | No | No | Yes | Yes | +| Multiple active connections | Yes | Yes | Yes | Yes | Yes | Yes | Yes | +| AEC/AGC/NS/HPF defaults | Yes | Yes | Yes | Yes | Yes | Yes | Yes | +| Audio implementation path | No if behavior unchanged | Yes | Possibly | Yes | Yes | Yes | Yes | +| SDK/trademark/legal review | Yes | No | No | No | No | Yes | Yes | +| SQLite/equivalent choice | Possibly | Yes | Yes | Yes | Yes | Yes | Yes | +| Bridge choice | No if API behavior unchanged | Yes | Possibly | Yes | Yes | Yes | Yes | +| Apple App Store SDK gate | Yes | Yes | Yes | Yes | Yes | Yes | Yes | +| Diagnostics upload policy | Yes | Yes | Yes | Yes | Yes | Yes | Yes | +| Crash reporting | Yes if included | Yes if included | Yes if included | Yes if included | Yes if included | Yes | Yes | + +## 6. Decisions That Must Be Confirmed By You + +| Priority | Decision | +|---|---| +| P0 | Confirm Apple App Store submission SDK gate: Xcode 26+ and iOS 26 / iPadOS 26 SDK+ for App Store Connect upload on or after 2026-04-28. | +| P0 | Confirm release type sequence: Internal Alpha first? | +| P0 | Confirm MVP platform strategy: all platforms as product target, staged release allowed? | +| P0 | Confirm no automatic telemetry / no automatic diagnostic upload for MVP. | +| P0 | Confirm one active server connection for MVP. | +| P0 | Confirm audio processing defaults: AEC, AGC, noise suppression, high-pass filter enabled by default where supported. | +| P0 | Confirm legal/trademark review required before any public/store release. | +| P1 | Confirm SQLite/equivalent local DB choice. | +| P1 | Confirm bridge default candidate. | +| P1 | Confirm English-only MVP UI with i18n-ready architecture. | +| P1 | Confirm crash reporting disabled unless later explicitly approved. | + +## 7. Open Decision Log + +| Decision ID | Owner | Decision | Status | Date | Notes | +|---|---|---|---|---|---| +| DEC-001 | Product Owner | Release type sequence | Proposed / Owner Confirmation Required | TBD | Recommended: Internal Alpha first. | +| DEC-002 | Product Owner / Engineering | MVP platform strategy | Proposed / Owner Confirmation Required | TBD | Recommended: all platforms as target, staged release allowed. | +| DEC-003 | Product Owner / iOS Owner | Minimum iOS version | Proposed / Owner Confirmation Required | TBD | Recommended: iOS 13. | +| DEC-004 | Product Owner / Android Owner | Minimum Android version | Proposed / Owner Confirmation Required | TBD | Recommended: Android API 24. | +| DEC-005 | Android Owner / Release Manager | Android target SDK | Proposed / Owner Confirmation Required | TBD | Recommended: API 35 or newer for Play submission. | +| DEC-006 | Product Owner / Software Architect | Multiple server connections in MVP | Proposed / Owner Confirmation Required | TBD | Recommended: not in MVP. | +| DEC-007 | Audio Owner / Product Owner | AEC default | Proposed / Owner Confirmation Required | TBD | Recommended: enabled where supported. | +| DEC-008 | Audio Owner / Product Owner | AGC default | Proposed / Owner Confirmation Required | TBD | Recommended: enabled. | +| DEC-009 | Audio Owner / Product Owner | Noise suppression default | Proposed / Owner Confirmation Required | TBD | Recommended: enabled. | +| DEC-010 | Audio Owner | High-pass filter default | Proposed / Owner Confirmation Required | TBD | Recommended: enabled. | +| DEC-011 | Software Architect / Audio Owner | Audio processing path | Proposed / Owner Confirmation Required | TBD | Recommended: platform-native first. | +| DEC-012 | Legal / Compliance | SDK/trademark/licensing review | Proposed / Owner Confirmation Required | TBD | Required before public/store release. | +| DEC-013 | Software Architect / Storage Owner | Local database | Proposed / Owner Confirmation Required | TBD | Recommended: SQLite or equivalent. | +| DEC-014 | Software Architect | Bridge choice | Proposed / Owner Confirmation Required | TBD | Recommended: typed bridge; default candidate `flutter_rust_bridge`. | +| DEC-020 | Product Owner / Legal | License model | Open | TBD | Must be decided before public release. | + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Updated decision register with proposed decisions for mobile minimum versions, audio defaults, audio implementation path, legal review, local database, bridge choice, diagnostics policy, and MVP release scope. | + + +## 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+ for App Store Connect upload on or after 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/governance/repo-format-validation-report.md b/docs/governance/repo-format-validation-report.md new file mode 100644 index 0000000..e58c6f9 --- /dev/null +++ b/docs/governance/repo-format-validation-report.md @@ -0,0 +1,75 @@ +# Repo Documentation Format Validation Report + +**Document type:** Configuration / Validation Report +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/repo-format-validation-report.md` + +--- + +## 1. Package + +```text +chanora-docs-repo-format-v0.9.2.zip +``` + +## 2. File Count + +| Type | Count | +|---|---:| +| Markdown files under docs/ | 37 | +| README files | 1 | + +## 3. Naming Check + +| Check | Result | +|---|---:| +| Old `CHANORA_*_v*.md` filename references outside migration map | 0 | +| Old `CHANORA_*_v*.zip` package references outside migration map | 0 | +| CJK characters found | 0 | + +## 4. Defined ID Counts + +| ID family | Defined IDs | +|---|---:| +| SysRS | 295 | +| SysDes | 141 | +| SRS | 194 | +| SAD | 70 | +| SDD | 80 | + +## 5. Undefined Reference Check + +| ID family | Undefined references | +|---|---:| +| SysRS | 0 | +| SysDes | 0 | +| SRS | 0 | +| SAD | 0 | +| SDD | 0 | + +## 6. Direct-Layer Rule Check + +| Rule | Result | +|---|---:| +| SRS direct SysRS references | 0 | +| SAD direct SysRS references | 0 | +| SAD direct SysDes references | 0 | +| SDD direct SysRS references | 0 | +| SDD direct SysDes references | 0 | +| SDD direct SRS references | 0 | + +## 7. Old Reference Details + +| Type | Values | +|---|---| +| Old markdown filename references outside migration map | None | +| Old ZIP filename references outside migration map | None | + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Validated repository-format documentation package and internal filename reference updates. | diff --git a/docs/governance/repository-bootstrap-plan.md b/docs/governance/repository-bootstrap-plan.md new file mode 100644 index 0000000..e35fe16 --- /dev/null +++ b/docs/governance/repository-bootstrap-plan.md @@ -0,0 +1,72 @@ +# Repository Bootstrap Plan + +**Document type:** Governance / Repository Bootstrap Plan +**Version:** 0.1.0 +**Status:** Draft +**Language:** English +**Product:** Chanora +**Repo path:** `docs/governance/repository-bootstrap-plan.md` + +--- + +## 1. Purpose + +This document defines the files and directories that should exist before product implementation begins. + +## 2. Bootstrap Scope + +This bootstrap package intentionally excludes CI workflow files. + +The goal is to establish: + +- repository metadata; +- contributor guidance; +- security policy; +- changelog; +- license placeholder; +- notice placeholder; +- editor and ignore rules; +- local command placeholders; +- documentation validation script; +- future scaffold plan. + +## 3. Required Root Files + +| File | Purpose | +|---|---| +| `README.md` | App/project overview | +| `CONTRIBUTING.md` | Contribution rules | +| `SECURITY.md` | Security reporting and security gates | +| `CHANGELOG.md` | Release/change history | +| `LICENSE` | License placeholder until final license decision | +| `NOTICE` | Non-affiliation and attribution placeholder | +| `.editorconfig` | Editor formatting baseline | +| `.gitignore` | Ignore rules | +| `.env.example` | Safe local environment template | +| `justfile` | Local command entrypoint | + +## 4. Required Tooling Files + +| File | Purpose | +|---|---| +| `tools/validate_docs.py` | Local documentation and traceability validation | + +## 5. Future Work + +CI workflow files should be added later after this bootstrap is committed and the repo structure is accepted. + +Recommended later CI files: + +```text +.github/workflows/docs.yml +.github/workflows/repo-health.yml +.github/workflows/flutter.yml +.github/workflows/rust.yml +.github/workflows/security.yml +``` + +## 6. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial repository bootstrap plan excluding CI. | diff --git a/docs/governance/traceability-matrix.md b/docs/governance/traceability-matrix.md new file mode 100644 index 0000000..94aa50b --- /dev/null +++ b/docs/governance/traceability-matrix.md @@ -0,0 +1,190 @@ + +# Chanora Requirements and Design Traceability Matrix + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Lifecycle hierarchy:** `SysRS -> SysDes -> SRS -> SAD -> SDD` + +**Repo path:** `docs/governance/traceability-matrix.md` --- + +## 1. Strict Hierarchy + +The Chanora documentation hierarchy shall follow this structure strictly: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +Direct-source rules: + +| Document | Direct upstream source allowed | +|---|---| +| SysDes | SysRS | +| SRS | SysDes only | +| SAD | SRS only | +| SDD | SAD only | + +Prohibited direct links: + +| Document | Prohibited direct source | +|---|---| +| SRS | SysRS | +| SAD | SysRS, SysDes | +| SDD | SysRS, SysDes, SRS | + +## 2. Current Baseline Documents + +| Layer | Current baseline | ID range | +|---|---|---| +| SysRS | `chanora_SysRS_v0.7.md` | SysRS-001 through SysRS-285 | +| SysDes | `chanora_SysDes_ASPICE_SYS3_v0.6.md` | SysDes-001 through SysDes-132 | +| SRS | `chanora_SRS_ASPICE_SWE1_v0.5.md` | SRS-001 through SRS-184 | +| SAD | `chanora_SAD_ASPICE_SWE2_v0.3.md` | SAD-001 through SAD-060 | +| SDD | `chanora_SDD_ASPICE_SWE3_v0.3.md` | SDD-001 through SDD-070 | + +## 3. Coverage Rules + +| Upstream layer | Downstream layer | Coverage rule | +|---|---|---| +| SysRS | SysDes | SysRS shall be fully covered by SysDes. | +| SysDes | SRS | Software-team-related SysDes items shall be fully covered by SRS. | +| SRS | SAD | SAD shall cover all SRS items. | +| SAD | SDD | SDD shall cover all SAD items. | + +## 4. Baseline Coverage Summary + +| Source | Target | +|---|---| +| SysRS-001 through SysRS-257 | SysDes-001 through SysDes-110 | +| SysRS-258 through SysRS-285 | SysDes-111 through SysDes-132 | +| SysDes-001 through SysDes-110 | SRS-001 through SRS-143 | +| SysDes-111 through SysDes-132 | SRS-144 through SRS-184 | +| SRS-001 through SRS-030 | SAD-032, SAD-039, SAD-040, SAD-041 | +| SRS-031 through SRS-060 | SAD-033, SAD-039, SAD-041 | +| SRS-061 through SRS-090 | SAD-034, SAD-039, SAD-041 | +| SRS-091 through SRS-110 | SAD-035 | +| SRS-111 through SRS-124 | SAD-036, SAD-050 | +| SRS-125 through SRS-134 | SAD-037, SAD-049 | +| SRS-135 through SRS-143 | SAD-038 | +| SRS-144 through SRS-184 | SAD-001 through SAD-031, SAD-039 through SAD-060 | +| SAD-001 through SAD-007 | SDD-001 through SDD-010 | +| SAD-008 through SAD-011 | SDD-011 through SDD-015 | +| SAD-012 through SAD-016 | SDD-016 through SDD-026 | +| SAD-017 through SAD-019 | SDD-027 through SDD-030 | +| SAD-020 through SAD-027 | SDD-031 through SDD-041 | +| SAD-028 through SAD-031 | SDD-042 through SDD-045 | +| SAD-032 through SAD-038 | SDD-046 through SDD-050 | +| SAD-039 through SAD-045 | SDD-046 through SDD-050, SDD-055, SDD-056 | +| SAD-046 through SAD-050 | SDD-051 through SDD-058, SDD-061 | +| SAD-051 through SAD-060 | SDD-057 through SDD-070 | + +## 5. Change Impact Rules + +| Changed layer | Required impact analysis | +|---|---| +| SysRS | Review SysDes coverage; update SRS only through updated SysDes. | +| SysDes | Review affected SRS requirements; SRS shall not bypass SysDes. | +| SRS | Review affected SAD items; SAD shall link only to SRS. | +| SAD | Review affected SDD items; SDD shall link only to SAD. | +| SDD | Review implementation, unit construction, and verification evidence. | + +## 6. Traceability Verification Checklist + +| Check | Expected result | +|---|---| +| SysDes references SysRS | Allowed | +| SRS references SysRS | Not allowed | +| SRS references SysDes | Required | +| SAD references SRS | Required | +| SAD references SysRS or SysDes | Not allowed | +| SDD references SAD | Required | +| SDD references SysRS, SysDes, or SRS | Not allowed | +| Latest SAD ID range | SAD-001 through SAD-060 | +| Latest SDD ID range | SDD-001 through SDD-070 | + + +## 8. Verification Work Product Traceability + +Verification work products are downstream evidence-producing artifacts. They do not change the strict engineering hierarchy. + +| Verification document | Direct verification source | Coverage | +|---|---|---| +| `chanora_SWE4_Unit_Verification_Plan_v0.1.md` | SDD | SDD-001 through SDD-070 | +| `chanora_SWE5_Software_Integration_Verification_Plan_v0.1.md` | SAD and SDD | SAD-001 through SAD-060 and SDD-001 through SDD-070 | +| `chanora_SWE6_Software_Verification_Plan_v0.1.md` | SRS | SRS-001 through SRS-184 | +| `chanora_SYS4_System_Integration_Verification_Plan_v0.1.md` | SysDes | SysDes-001 through SysDes-132 | +| `chanora_Verification_Master_Plan_v0.1.md` | Verification planning baseline | SWE.4, SWE.5, SWE.6, SYS.4 | + +## 9. Verification Change Impact + +| Changed artifact | Verification impact | +|---|---| +| SDD | Re-select SWE.4 unit verification measures and affected SWE.5 integration measures. | +| SAD | Update SDD if needed and re-select affected SWE.5 integration measures. | +| SRS | Update SAD/SDD if needed and re-select affected SWE.6 verification measures. | +| SysDes | Update downstream engineering artifacts if needed and re-select affected SYS.4 measures. | +| SysRS | Update SysDes and downstream artifacts if requirements intent changes. | + + +## 10. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial strict traceability matrix. | +| 0.2.0 | 2026-05-14 | Updated current baseline to SAD v0.3 and SDD v0.3, with SAD-001 through SAD-060 and SDD-001 through SDD-070 coverage. | +| 0.3.0 | 2026-05-14 | Added downstream verification work product traceability for SWE.4, SWE.5, SWE.6, and SYS.4. | + +--- + +## 11. Product Decision Traceability Addendum + +| Source | Target | +|---|---| +| SysRS-286 through SysRS-295 | SysDes-133 through SysDes-141 | +| SysDes-133 through SysDes-141 | SRS-185 through SRS-194 | +| SRS-185 through SRS-194 | SAD-061 through SAD-070 | +| SAD-061 through SAD-070 | SDD-071 through SDD-080 | +| SDD-071 through SDD-080 | SWE.4 addendum SWE4-UV-031 through SWE4-UV-034 | +| SAD-061 through SAD-070 and SDD-071 through SDD-080 | SWE.5 addendum SWE5-IV-014 | +| SRS-185 through SRS-194 | SWE.6 addendum SWE6-SV-016 | +| SysDes-133 through SysDes-141 | SYS.4 addendum SYS4-SIV-015 | + + +## 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. | + +--- + +## 12. Platform Release Policy Traceability + +| Policy document | Covered decisions | +|---|---| +| `docs/release/platform-release-policy.md` | iOS runtime target, Apple App Store Connect upload SDK gate, Android runtime target, Google Play target API gate | + +The Apple App Store Connect upload gate remains linked through: + +```text +SysRS-287 -> SysDes-134 -> SRS-186 -> SAD-062 -> SDD-072 +``` + +The corrected effective date is: + +```text +Since 2026-04-28: +App Store Connect upload builds require Xcode 26 or later +using iOS 26 / iPadOS 26 SDK or later. +``` + +This build-SDK gate is separate from the iOS runtime deployment target. + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/i18n/localization-architecture.md b/docs/i18n/localization-architecture.md new file mode 100644 index 0000000..99eff48 --- /dev/null +++ b/docs/i18n/localization-architecture.md @@ -0,0 +1,87 @@ + +# Chanora Internationalization and Localization Architecture + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English + +**Repo path:** `docs/i18n/localization-architecture.md` --- + +## 1. Purpose + +This document defines Chanora's i18n architecture. Chanora is expected to operate in multilingual environments where product UI language, server-provided names, user nicknames, channel names, chat messages, and diagnostics may contain different languages. + +## 2. i18n Principles + +| Principle | Rule | +|---|---| +| Product strings are localizable | UI copy, labels, settings, errors, and accessibility labels use localization resources. | +| Server content is not translated | Server names, channel names, client nicknames, and chat messages are displayed as content. | +| UTF-8 internal text | Cross-layer DTOs and storage use UTF-8-compatible strings. | +| Boundary conversion only | Non-UTF-8 conversion occurs only at explicit protocol or platform boundaries. | +| Diagnostics are stable | Machine-readable diagnostic keys remain language-neutral. | +| User-facing diagnostics may be localized | Diagnostic descriptions can be localized independently. | +| Fallback is deterministic | Missing translations fall back to English or configured baseline locale. | + +## 3. Text Categories + +| Category | Example | Handling | +|---|---|---| +| Product UI string | "Connect", "Settings" | Localized | +| Accessibility string | "Mute microphone" | Localized | +| Protocol/server content | Server name, channel name | Preserve and display | +| User content | Chat message, nickname | Preserve and display | +| Machine diagnostic key | `audio.device.route_changed` | Stable, not localized | +| Diagnostic description | "Audio route changed" | Localizable | + +## 4. Encoding Architecture + +```text +External server text + -> Protocol Adapter boundary conversion if required + -> UTF-8-compatible Rust DTO + -> Bridge DTO + -> Flutter ViewModel + -> Flutter Text rendering + +Product string key + -> Localization Service + -> Locale resource lookup + -> Fallback if missing + -> Flutter rendering +``` + +## 5. Bidi and Mixed-Language Handling + +The UI shall not assume that all text is left-to-right. Product strings and content strings should be rendered using platform text widgets capable of bidirectional text rendering where supported. + +## 6. Testing + +| Test | Purpose | +|---|---| +| Missing-key fallback | Ensure fallback locale works | +| Unicode server name | Ensure names survive protocol -> UI | +| Mixed-language chat | Ensure multilingual content displays | +| RTL smoke test | Ensure basic RTL strings render | +| Diagnostics Unicode export | Ensure multilingual diagnostics survive redaction | +| Machine-key stability | Ensure diagnostic keys are language-neutral | + +## 7. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial i18n and localization architecture baseline. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/legal/trademark-and-attribution-review.md b/docs/legal/trademark-and-attribution-review.md new file mode 100644 index 0000000..1288d82 --- /dev/null +++ b/docs/legal/trademark-and-attribution-review.md @@ -0,0 +1,107 @@ +# Legal Trademark And Attribution Review V0.9.2.2.1 + +**Document type:** Legal / Trademark and Attribution Review +**Version:** 0.9.2 +**Status:** Baseline Candidate / Legal Review Required +**Language:** English +**Product:** Chanora +**Repo path:** `docs/legal/trademark-and-attribution-review.md` --- + +## 1. Purpose + +This document records trademark, attribution, non-affiliation, and OSS notice review for Chanora. + +This document must be reviewed by a qualified legal/compliance reviewer before public release or store submission. + +## 2. Non-Affiliation Requirement + +Chanora must not imply official affiliation, endorsement, sponsorship, or approval by TeamSpeak or any other third-party service provider unless such approval exists in writing. + +## 3. Required Public Wording + +The final wording must be approved by legal. + +Draft wording: + +> Chanora is an independent client application and is not affiliated with, endorsed by, sponsored by, or officially associated with TeamSpeak. + +Legal reviewer shall confirm whether the wording is sufficient for: + +- website; +- app store description; +- in-app About screen; +- documentation; +- release notes; +- support pages. + +## 4. Trademark Usage Review + +| Location | Uses third-party mark? | Wording reviewed? | Approved? | Notes | +|---|---|---|---|---| +| App name | TBD | TBD | TBD | TBD | +| App subtitle | TBD | TBD | TBD | TBD | +| App description | TBD | TBD | TBD | TBD | +| Website | TBD | TBD | TBD | TBD | +| In-app About screen | TBD | TBD | TBD | TBD | +| Documentation | TBD | TBD | TBD | TBD | +| Release notes | TBD | TBD | TBD | TBD | +| Store metadata | TBD | TBD | TBD | TBD | + +## 5. Attribution Review + +| Dependency / product | Attribution required? | License / basis | Attribution text | Status | +|---|---|---|---|---| +| Flutter | TBD | TBD | TBD | TBD | +| Rust dependencies | TBD | TBD | TBD | TBD | +| `tsclientlib` | TBD | TBD | TBD | TBD | +| Native audio libraries | TBD | TBD | TBD | TBD | +| Icons/fonts/assets | TBD | TBD | TBD | TBD | + +## 6. OSS Notice Requirements + +| Requirement | Status | Evidence | +|---|---|---| +| OSS dependency inventory complete | TBD | Dependency report | +| License compatibility reviewed | TBD | Legal review | +| Required notices included | TBD | OSS notices file | +| Source offer obligations checked if applicable | TBD | Legal review | +| App store metadata license claims reviewed | TBD | Store review | + +## 7. Release Gate + +| Gate | Required result | +|---|---| +| Non-affiliation wording | Approved | +| Trademark usage | Approved | +| OSS notices | Complete | +| License review | Complete | +| Store metadata | Approved if applicable | +| Website/legal pages | Approved if applicable | + +## 8. Approval + +| Role | Name | Decision | Date | +|---|---|---|---| +| Legal / Compliance Reviewer | TBD | Pending | TBD | +| Product Owner | TBD | Pending | TBD | +| Release Manager | TBD | Pending | TBD | + +## 9. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial trademark and attribution review template; legal review required before public release. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/privacy/privacy-policy.md b/docs/privacy/privacy-policy.md new file mode 100644 index 0000000..d835064 --- /dev/null +++ b/docs/privacy/privacy-policy.md @@ -0,0 +1,108 @@ +# Priv Privacy Policy V0.9.2.2.1 + +**Document type:** Privacy / Public Policy Draft +**Version:** 0.9.2 +**Status:** Baseline Candidate / Legal Review Required +**Language:** English +**Product:** Chanora +**Repo path:** `docs/privacy/privacy-policy.md` --- + +## 1. Important Notice + +This is a draft privacy policy template for review. It must be reviewed by a qualified legal/privacy reviewer before public release or store submission. + +## 2. Overview + +Chanora is a client application for connecting to compatible voice communication servers. Chanora is designed to operate primarily on the user's device. + +## 3. Data Processed by the App + +Depending on how the user configures and uses the app, Chanora may process: + +- server address and port; +- server password if provided by the user; +- user nickname; +- identity information needed for server connection; +- channel names and server-provided names; +- chat messages displayed in the app; +- audio input and output during voice sessions; +- local application settings; +- audio device settings; +- diagnostic information generated by the app. + +## 4. Local Storage + +Chanora may store local settings, bookmarks, recent server information, audio preferences, and related configuration on the user's device. + +Sensitive secrets such as server passwords or identity secrets are intended to be stored using platform secure storage mechanisms where supported. + +## 5. Diagnostics + +Chanora may allow the user to generate diagnostic bundles for troubleshooting. + +Diagnostic export is intended to be user-initiated. Diagnostic bundles should be redacted to avoid including passwords, identity secrets, and other sensitive information. + +Chanora should not automatically upload diagnostic bundles unless a future version explicitly introduces an opt-in upload feature and updates this policy. + +## 6. Audio and Microphone + +Chanora uses microphone access to provide voice communication features. Audio is processed for voice communication and may include echo cancellation, automatic gain control, noise suppression, and high-pass filtering. + +Chanora should not record or persist voice audio unless a future feature explicitly states otherwise and receives user consent where required. + +## 7. Permissions + +Chanora may request permissions required for voice communication, notifications, audio routing, local storage access, or platform-specific behavior. + +Permission requirements vary by platform. + +## 8. Data Sharing + +This draft policy assumes: + +- Chanora does not sell user data. +- Chanora does not automatically upload diagnostics. +- Chanora does not include automatic telemetry unless later approved and documented. +- User-initiated sharing of diagnostic bundles is controlled by the user. + +These assumptions must be confirmed before public release. + +## 9. Third-Party Servers + +When the user connects to a compatible external server, the server may receive connection information, nickname, voice data, text messages, or other information necessary for communication. The operation of external servers is outside Chanora's control. + +## 10. Third-Party Dependencies + +Chanora may use third-party software dependencies. The dependency and license list should be published or made available where required by applicable licenses. + +## 11. Children's Privacy + +TBD by legal/privacy reviewer. + +## 12. Regional Requirements + +TBD by legal/privacy reviewer. Public release may require region-specific privacy disclosures. + +## 13. Contact + +TBD. + +## 14. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial privacy policy draft template; legal review required before public release. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/references/aspice-swe2-swe3-integration-note.md b/docs/references/aspice-swe2-swe3-integration-note.md new file mode 100644 index 0000000..324a656 --- /dev/null +++ b/docs/references/aspice-swe2-swe3-integration-note.md @@ -0,0 +1,87 @@ + +# Chanora SWE.2 / SWE.3 Reference Integration Note + +**Version:** 0.9.2 +**Status:** Baseline Candidate note +**Language:** English + +**Repo path:** `docs/references/aspice-swe2-swe3-integration-note.md` --- + +## 1. Purpose + +This note records the refinements applied to Chanora SAD and SDD after reviewing additional software architecture and detailed design references. + +## 2. SAD Updates + +The SAD was updated to include: + +- SWE.2 architecture completeness and evaluation criteria +- Interface catalog +- Performance and resource view +- Assumptions and dependencies +- Architecture glossary +- Additional SAD design items covering: + - architecture evaluation + - interface catalog + - performance/resource views + - assumptions/dependencies + - glossary + - SDD refinement requirements + - SAD/SDD communication and baseline expectations + +## 3. SDD Updates + +The SDD was updated to include: + +- SWE.3 detailed-design completeness criteria +- Unit interface detail catalog +- Detailed design evaluation checklist +- Additional SDD detailed design items covering: + - ArchitectureViewDocs + - ADR record structure + - InterfaceDetailCatalog + - PerformanceDesignNotes + - AssumptionRegister + - ArchitectureGlossary + - SoftwareUnitDesignTemplate + - UnitConstructionGuideline + - SoftwareUnitTraceChecker + - DetailedDesignReviewRecord + - UnitVerificationHandoff + - SoftwareUnitRegistry + +## 4. Traceability Rule Preserved + +The updated documents preserve the strict traceability chain: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +Direct source rules: + +| Document | Direct source | +|---|---| +| SAD | SRS only | +| SDD | SAD only | + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial research note for expanding SAD structure and updating SDD coverage. | +| 0.2.0 | 2026-05-14 | Added SWE.2 and SWE.3 reference integration summary. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/references/external-references.md b/docs/references/external-references.md new file mode 100644 index 0000000..116e97d --- /dev/null +++ b/docs/references/external-references.md @@ -0,0 +1,112 @@ + +# Chanora External Reference Collection + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora + +**Repo path:** `docs/references/external-references.md` --- + +## 1. Material 3 and Flutter References + +| Reference | Purpose | +|---|---| +| https://m3.material.io/ | Material 3 design system baseline | +| https://m3.material.io/foundations/design-tokens/overview | Material 3 design tokens | +| https://m3.material.io/styles/color/system/how-the-system-works | Material 3 color system | +| https://m3.material.io/styles/typography | Material 3 typography | +| https://m3.material.io/foundations/adaptive-design | Material 3 adaptive design | +| https://m3.material.io/components | Material 3 components | +| https://docs.flutter.dev/ui/design/material | Material Design in Flutter | +| https://docs.flutter.dev/ui/widgets/material | Flutter Material widget catalog | +| https://docs.flutter.dev/release/breaking-changes/material-3-default | Flutter Material 3 default behavior | +| https://docs.flutter.dev/release/breaking-changes/material-3-migration | Flutter Material 3 migration guidance | +| https://api.flutter.dev/flutter/material/ThemeData-class.html | Flutter ThemeData API | +| https://api.flutter.dev/flutter/material/ColorScheme-class.html | Flutter ColorScheme API | +| https://api.flutter.dev/flutter/material/ThemeExtension-class.html | Flutter ThemeExtension API | + +## 2. Android and iOS Platform References + +| Reference | Purpose | +|---|---| +| https://developer.android.com/develop/ui/compose/layouts/adaptive/use-window-size-classes | Android window size classes and adaptive layout reference | +| https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture | Android predictive back behavior | +| https://developer.android.com/develop/connectivity/bluetooth/bt-permissions | Android Bluetooth permissions | +| https://developer.apple.com/design/human-interface-guidelines/ | Apple Human Interface Guidelines | +| https://developer.apple.com/documentation/avfaudio/avaudiosession/category-swift.struct | AVAudioSession category reference | + +## 3. ASPICE and Requirements / Design Process References + +| Reference | Purpose | +|---|---| +| `Automotive-SPICE-PAM-v40.pdf` | Automotive SPICE process model | +| https://www.ul.com/sis/resources/process-swe-1 | UL SWE.1 Software Requirements Analysis guidance | +| https://www.ul.com/sis/resources/process-swe-2 | UL SWE.2 Software Architectural Design guidance | +| https://www.ul.com/sis/resources/process-swe-3 | UL SWE.3 Software Detailed Design and Unit Construction guidance | +| https://www.ul.com/sis/resources/process-swe-4 | UL SWE.4 Software Unit Verification guidance | +| https://www.ul.com/sis/resources/process-swe-5 | UL SWE.5 Software Component Verification and Integration Verification guidance | +| https://www.ul.com/sis/resources/process-swe-6 | UL SWE.6 Software Verification guidance | +| https://www.ul.com/sis/insights/system-integration-and-integration-test-sys4-automotive-spice | UL SYS.4 System Integration and Integration Test guidance | +| https://polarion.code.blog/2021/11/10/swe-2-software-architectural-design/ | Polarion SWE.2 Software Architectural Design notes | +| https://polarion.code.blog/2022/04/21/swe-3-software-detailed-design-and-unit-construction/ | Polarion SWE.3 Software Detailed Design and Unit Construction notes | +| https://polarion.code.blog/2023/01/18/swe-4-software-unit-verification/ | Polarion SWE.4 Software Unit Verification notes | +| https://polarion.code.blog/2023/06/28/swe-5-software-integration-and-integration-test/ | Polarion SWE.5 Software Integration and Integration Test notes | +| https://polarion.code.blog/2025/06/05/swe-6-software-qualification-test/ | Polarion SWE.6 Software Qualification Test notes | +| https://polarion.code.blog/2025/08/06/sys-4-system-integration-and-integration-verification-a-spice-4-0/ | Polarion SYS.4 System Integration and Integration Verification notes | + +## 4. Software Architecture and Design Document References + +| Reference | Purpose | +|---|---| +| https://medium.com/codex/what-goes-in-a-software-architecture-document-e97d808d5cec | Software Architecture Document content and architecture views | +| https://www.atlassian.com/work-management/knowledge-sharing/documentation/software-design-document | Software Design Document structure, including overview, architecture, data design, interface design, component design, UI design, assumptions, dependencies, and glossary | + +## 5. Use in Chanora Documentation + +| Reference category | Applied to | +|---|---| +| Material 3 and Flutter | UI/UX guideline, design tokens, component catalog, adaptive layout, SysDes, SRS, SAD, SDD | +| Android and iOS platform references | Platform behavior guide, SysRS, SysDes, SRS, SAD, SDD | +| ASPICE references | SysDes, SRS, SAD, SDD, SWE.4, SWE.5, SWE.6, SYS.4, traceability matrix | +| Software architecture/design document references | SAD v0.3, SDD v0.3 | + +## 6. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial reference collection. | +| 0.2.0 | 2026-05-14 | Added Atlassian software design document reference, UL SWE.2, UL SWE.3, Polarion SWE.2, Polarion SWE.3, and Medium SAD article reference. | +| 0.3.0 | 2026-05-14 | Added UL and Polarion references for SWE.4, SWE.5, SWE.6, and SYS.4 verification planning. | + +--- + +## 7. Platform Release Policy Reference Addendum + +| Reference | Purpose | +|---|---| +| Apple Developer - Upcoming Requirements | Apple App Store Connect SDK submission requirement; current baseline uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ on or after 2026-04-28 unless newer Apple policy applies. | +| Flutter supported platforms | Runtime platform support baseline; current decision uses iOS 13+ and Android API 24+ unless project constraints raise them. | +| Google Play target API level requirements | Android target SDK release gate; target the Google Play-required API level on upload date. | + + +## 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. | + +--- + +## 8. Apple SDK Gate Reference Correction + +| Reference | Purpose | +|---|---| +| https://developer.apple.com/news/upcoming-requirements/?id=02032026a | Apple Upcoming Requirements page defining the App Store Connect upload build gate: since April 28, 2026, uploaded apps must be built with Xcode 26 or later using the applicable platform 26 SDK or later. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/release/platform-release-policy.md b/docs/release/platform-release-policy.md new file mode 100644 index 0000000..448d2e7 --- /dev/null +++ b/docs/release/platform-release-policy.md @@ -0,0 +1,63 @@ +# Rel Platform Release Policy + +**Document type:** Release / Platform Release Policy +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/release/platform-release-policy.md` --- + +## 1. Purpose + +This document separates runtime deployment targets from app-store upload build-SDK gates. + +## 2. iOS / iPadOS Policy + +| Policy item | Decision | +|---|---| +| Runtime deployment target | iOS 13 or later unless Flutter, plugin, audio, or product constraints require raising it. | +| App Store Connect upload build-SDK gate | For upload on or after 2026-04-28, use Xcode 26 or later and the iOS 26 / iPadOS 26 SDK or later, unless Apple publishes a newer applicable requirement before upload. | +| Internal Alpha / local development | May use development toolchains suitable for internal testing if no App Store Connect upload is performed. | +| TestFlight / App Store upload | Must satisfy the active Apple App Store Connect upload requirement. | + +## 3. Android Policy + +| Policy item | Decision | +|---|---| +| Runtime minimum | Android API 24 or later unless Flutter, plugin, audio, or product constraints require raising it. | +| Store upload target API | Target the Google Play-required API level on the upload date. | +| Internal Alpha / sideload testing | May use internal build configuration suitable for internal testing, but release readiness must state whether Google Play rules apply. | + +## 4. Release Readiness Rule + +The Go/No-Go record shall record: + +- runtime minimum versions; +- store upload build/toolchain gates; +- build number; +- commit SHA; +- tag; +- artifact hashes; +- platform-specific release status; +- whether the release is internal-only or store-uploaded. + +## 5. Traceability + +| Policy | Traceability | +|---|---| +| iOS runtime minimum | SysRS-286 -> SysDes-133 -> SRS-185 -> SAD-061 -> SDD-071 | +| Apple App Store Connect upload SDK gate | SysRS-287 -> SysDes-134 -> SRS-186 -> SAD-062 -> SDD-072 | +| Android runtime and target API policy | SysRS-288/289 -> SysDes-135 -> SRS-187/188 -> SAD-063 -> SDD-073 | + +## 6. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Initial platform release policy separating runtime targets from store upload build-SDK gates. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/release/release-artifact-policy.md b/docs/release/release-artifact-policy.md new file mode 100644 index 0000000..586c7c5 --- /dev/null +++ b/docs/release/release-artifact-policy.md @@ -0,0 +1,51 @@ +# Release Artifact Policy + +**Document type:** Release / Artifact Policy +**Version:** 0.1.0 +**Status:** Draft +**Language:** English +**Product:** Chanora +**Repo path:** `docs/release/release-artifact-policy.md` + +--- + +## 1. Purpose + +This document defines the expected release artifact metadata before a release is approved. + +## 2. Required Artifact Metadata + +| Field | Required | +|---|---| +| Release version | Yes | +| Build number | Yes | +| Git commit SHA | Yes | +| Git tag | Yes | +| Build timestamp | Yes | +| Build environment | Yes | +| Platform | Yes | +| Artifact filename | Yes | +| SHA-256 hash | Yes | +| Signing status | Required for public/store release | +| Notarization status | Required for macOS public release | +| Store upload status | Required for store release | + +## 3. Artifact Types + +| Platform | Expected artifact | +|---|---| +| Windows | Installer or packaged app artifact | +| macOS | Signed/notarized app bundle or installer | +| Linux | AppImage, Flatpak, deb, rpm, or selected package | +| Android | AAB/APK | +| iOS / iPadOS | App Store Connect/TestFlight upload artifact | + +## 4. Rule + +Release artifacts shall not be treated as approved until the Release Readiness / Go-No-Go record is completed. + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial release artifact policy. | diff --git a/docs/release/release-readiness-go-nogo-record.md b/docs/release/release-readiness-go-nogo-record.md new file mode 100644 index 0000000..ce50f6f --- /dev/null +++ b/docs/release/release-readiness-go-nogo-record.md @@ -0,0 +1,210 @@ + +# CHANORA_REL_Release_Readiness_Go_NoGo_Record_v0.9.2.2.1 + +**Document type:** Release Readiness Checklist / Go-No-Go Record +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/release/release-readiness-go-nogo-record.md` --- + +## 1. Purpose + +This document records the auditable release readiness decision for a Chanora release. + +Design documents alone do not authorize release. A release requires an explicit readiness decision based on scope, build identity, requirement completion, verification evidence, security review, platform readiness, legal/privacy readiness, known risks, and approval. + +## 2. Release Identity + +| Field | Value | +|---|---| +| Release name | TBD by Product Owner | +| Release type | TBD: Internal Alpha / External Beta / MVP Public / Store Release | +| Release version | TBD | +| Release candidate ID | TBD | +| Release date target | TBD | +| Release owner | TBD | +| Product owner | TBD | +| Engineering owner | TBD | +| QA / verification owner | TBD | +| Security reviewer | TBD | +| Legal / compliance reviewer | TBD | + +## 3. Build Identity + +| Field | Value | +|---|---| +| Git repository | TBD | +| Git branch | TBD | +| Git commit SHA | TBD | +| Git tag | TBD | +| iOS App Store Connect upload SDK gate | Xcode 26+ and iOS 26 / iPadOS 26 SDK+ for upload on or after 2026-04-28 | +| Platform release policy included | Yes | +| Build number | TBD | +| CI pipeline ID | TBD | +| Build timestamp | TBD | +| Windows artifact | TBD | +| macOS artifact | TBD | +| Linux artifact | TBD | +| Android artifact | TBD | +| iOS artifact | TBD | +| Artifact hash method | SHA-256 unless otherwise specified | +| Artifact hashes | TBD | + +## 4. Scope Readiness + +| Question | Answer | Evidence | Owner | +|---|---|---|---| +| Is this release scope defined? | TBD | Release scope statement | Product Owner | +| Is this release Internal Alpha, External Beta, MVP Public, or Store Release? | TBD | Release scope statement | Product Owner | +| Are included features listed? | TBD | Release notes / scope list | Product Owner | +| Are excluded/deferred features listed? | TBD | Deferred requirements list | Product Owner | +| Are target platforms listed? | TBD | Platform readiness table | Engineering Owner | +| Are known limitations documented? | TBD | Known issue register | Product Owner / QA | + +## 5. Requirements Readiness + +| Requirement group | Status | Evidence | Deferred items / waiver | +|---|---|---|---| +| P0 / MVP connection requirements | TBD | SRS/SWE.6 evidence | TBD | +| P0 / MVP channel and state requirements | TBD | SRS/SWE.6 evidence | TBD | +| P0 / MVP voice requirements | TBD | SRS/SWE.6 evidence | TBD | +| Audio processing requirements | TBD | SWE.4/SWE.5/SWE.6 evidence | TBD | +| Storage and secure storage requirements | TBD | SWE.4/SWE.5/SWE.6 evidence | TBD | +| Diagnostics and redaction requirements | TBD | SWE.4/SWE.5/SWE.6 evidence | TBD | +| Material 3 / UI requirements | TBD | SWE.6 evidence | TBD | +| Accessibility requirements | TBD | SWE.6 evidence | TBD | +| Platform behavior requirements | TBD | SYS.4/SWE.6 evidence | TBD | +| i18n / Unicode requirements | TBD | SWE.4/SWE.5/SWE.6 evidence | TBD | +| Traceability requirements | TBD | Validation report | TBD | + +## 6. Verification Readiness + +| Verification layer | Required evidence | Status | Failed items | Waivers | +|---|---|---|---|---| +| SWE.4 Unit Verification | Unit verification summary report | TBD | TBD | TBD | +| SWE.5 Software Integration Verification | Integration verification summary report | TBD | TBD | TBD | +| SWE.6 Software Verification | Software verification summary report | TBD | TBD | TBD | +| SYS.4 System Integration Verification | System integration verification summary report | TBD | TBD | TBD | +| Regression Verification | Regression report | TBD | TBD | TBD | +| Manual exploratory test | Test notes | TBD | TBD | TBD | + +## 7. Security Readiness + +| Question | Required answer | Status | Evidence | +|---|---|---|---| +| Is secure storage verified for supported platforms? | Yes / waived | TBD | Security test report | +| Are secrets excluded from plaintext logs? | Yes / waived | TBD | Redaction test result | +| Is diagnostic export redaction verified? | Yes / waived | TBD | Diagnostics audit | +| Is dependency/license scan completed? | Yes / waived | TBD | Dependency scan report | +| Are high/critical dependency issues resolved or waived? | Yes / waived | TBD | Security waiver record | +| Are user-facing errors safe and non-sensitive? | Yes / waived | TBD | Review record | +| Are platform permissions justified? | Yes / waived | TBD | Permission review | + +## 8. Platform Readiness + +| Platform | Release status | Build artifact | Verification status | Known blockers | Owner | +|---|---|---|---|---|---| +| Windows | TBD: Go / Conditional Go / No-Go / Not in scope | TBD | TBD | TBD | TBD | +| macOS | TBD: Go / Conditional Go / No-Go / Not in scope | TBD | TBD | TBD | TBD | +| Linux | TBD: Go / Conditional Go / No-Go / Not in scope | TBD | TBD | TBD | TBD | +| Android | TBD: Go / Conditional Go / No-Go / Not in scope | TBD | TBD | TBD | TBD | +| iOS | TBD: Go / Conditional Go / No-Go / Not in scope | TBD | TBD, including Apple App Store SDK gate | TBD | TBD | + +## 9. Legal, OSS, and Privacy Readiness + +| Question | Required answer | Status | Evidence | Owner | +|---|---|---|---|---| +| Is the app clearly identified as unofficial and not affiliated with TeamSpeak? | Yes | TBD | App copy / legal notice | Legal | +| Is the TeamSpeak trademark/non-affiliation wording reviewed? | Yes | TBD | Legal review record | Legal | +| Is OSS license review completed? | Yes | TBD | OSS notice / license report | Legal / Engineering | +| Are Rust, Flutter, tsclientlib, and platform dependencies included in OSS review? | Yes | TBD | OSS license report | Legal / Engineering | +| Is privacy policy completed for the release scope? | Yes | TBD | Privacy policy URL/file | Legal | +| Are diagnostics/logging disclosures complete? | Yes | TBD | Privacy policy / in-app notice | Legal / Product | +| Are App Store / Play Store metadata requirements complete if applicable? | Yes / N/A | TBD | Store metadata review | Product / Legal | + +## 10. Known Issues and Waivers + +| Issue ID | Description | Severity | Impact | Waiver? | Waiver owner | Expiry / follow-up | +|---|---|---|---|---|---|---| +| TBD | TBD | TBD | TBD | TBD | TBD | TBD | + +## 10A. Required Security, Privacy, and Legal Evidence + +| Evidence document | Required status before External Beta / Public release | +|---|---| +| `CHANORA_SEC_Threat_Model_v0.9.2.2.1.md` | Reviewed; v1.0 approved before public release | +| `CHANORA_SEC_Secure_Storage_Audit_Report_v0.9.2.2.1.md` | Completed for release-scope platforms | +| `CHANORA_SEC_Diagnostic_Redaction_Audit_Report_v0.9.2.2.1.md` | Completed and approved | +| `CHANORA_SEC_Dependency_And_Supply_Chain_Report_v0.9.2.2.1.md` | Completed with no unapproved critical/high risk | +| `CHANORA_PRIV_Privacy_Policy_v0.9.2.2.1.md` | Legal/privacy reviewed; v1.0 approved before public release | +| `CHANORA_LEGAL_Trademark_And_Attribution_Review_v0.9.2.2.1.md` | Legal reviewed; v1.0 approved before public release | + + +## 10B. Key Product Decision Gate + +| Decision | Required status before Go | +|---|---| +| Release type | Confirmed | +| Release platform scope | Confirmed | +| Minimum iOS version | Confirmed | +| Apple App Store SDK gate | Confirmed and release-inspected | +| Minimum Android version | Confirmed | +| Android target SDK policy | Confirmed | +| Multiple active connections in MVP | Confirmed | +| AEC/AGC/NS/HPF default states | Confirmed | +| Audio processing implementation path | Confirmed | +| Legal/trademark/licensing review requirement | Confirmed | +| Local database choice | Confirmed | +| Flutter/Rust bridge choice | Confirmed | +| Diagnostics upload policy | Confirmed | +| Crash reporting policy | Confirmed | +| Product license model | Confirmed or explicitly not required for release scope | + + +## 11. Release Decision + +| Decision | Meaning | +|---|---| +| Go | Release is approved for the stated scope and platforms. | +| Conditional Go | Release is approved only if listed conditions are satisfied. | +| No-Go | Release is not approved. | + +**Decision:** TBD: Go / Conditional Go / No-Go + +## 12. Conditional Go Conditions + +| Condition ID | Condition | Owner | Due date | Evidence required | +|---|---|---|---|---| +| TBD | TBD | TBD | TBD | TBD | + +## 13. Approval + +| Role | Name | Decision | Date | Evidence / Signature | +|---|---|---|---|---| +| Product Owner | TBD | TBD | TBD | TBD | +| Engineering Owner | TBD | TBD | TBD | TBD | +| QA / Verification Owner | TBD | TBD | TBD | TBD | +| Security Reviewer | TBD | TBD | TBD | TBD | +| Legal / Compliance Reviewer | TBD | TBD | TBD | TBD | +| Release Manager | TBD | TBD | TBD | TBD | + +## 14. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial release readiness and Go/No-Go record template. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/requirements/srs.md b/docs/requirements/srs.md new file mode 100644 index 0000000..3b0f841 --- /dev/null +++ b/docs/requirements/srs.md @@ -0,0 +1,2528 @@ +# Chanora SRS — Software Requirements Specification + +**Product name:** Chanora +**Document type:** SRS / Software Requirements Specification +**ASPICE process alignment:** SWE.1 Software Requirements Analysis +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Source baseline:** `chanora_SysDes_ASPICE_SYS3_v0.5.md` +**Architecture baseline:** Flutter + Rust Core + `tsclientlib` protocol adapter +**Target client platforms:** Windows, macOS, Linux, iOS, Android + +**Repo path:** `docs/requirements/srs.md` --- + +## 1. Purpose + +This SRS defines the software requirements for the Chanora client application. It is derived from the approved SysDes baseline and is written in the style of ASPICE SWE.1 Software Requirements Analysis. + +The SRS covers all SysDes design items that require implementation or enablement by the software team, including software-facing constraints from hardware, operating system services, networks, external compatible servers, deployment, diagnostics, and verification. + +Chanora remains an application, not an operating system. The software requirements specify what the Chanora software shall do and what operating-environment assumptions or interfaces it shall handle. + +## 2. ASPICE SWE.1 Alignment + +This document addresses the following SWE.1 concerns: + +- Specify software requirements from system requirements and system architecture. +- Structure and prioritize software requirements. +- Analyze software requirements for correctness, technical feasibility, and operating-environment impact. +- Establish consistency and traceability to system architecture; system-requirement coverage is inherited through the SysDes allocation chain. +- Communicate the agreed software requirements and impact analysis to affected parties. + +## 3. Software Scope + +### 3.1 In Scope for Software Team + +The software team owns or implements the following software elements: + +- Chanora application container +- Flutter UI layer +- Flutter state layer +- Flutter-Rust bridge layer +- Rust Core and connection manager +- Protocol adapter using `tsclientlib` +- State synchronization engine +- Audio subsystem +- Platform adapter software layer +- Local data store integration +- Secure storage integration layer +- Diagnostics and observability subsystem +- Software-facing deployment scripts and release metadata +- Software verification hooks and test-support tooling + +### 3.2 Out of Scope for Software Implementation + +- Implementing or operating external TeamSpeak 3-compatible servers +- Controlling user-managed network infrastructure, routers, VPNs, NAT devices, or ISPs +- Manufacturing or controlling physical audio hardware +- Changing operating system vendor policies for permissions, secure storage, background execution, or app-store review +- Providing a Chanora-operated backend for MVP voice, channels, or text + +Software shall still handle these items as external interfaces, constraints, assumptions, degraded states, or error conditions where applicable. + +## 4. Requirement Attribute Model + +Each SRS requirement uses the following attributes. + +| Attribute | Meaning | +|---|---| +| SRS ID | Unique software requirement identifier, formatted as `SRS-XXX` | +| Type | Functional, non-functional, interface, platform, security, diagnostics, packaging, analysis, or process classification | +| Stage | Delivery stage: `P0 / MVP`, `P1 / Beta`, `P2 / Production`, or `P3 / Future` | +| Allocated to | Software component or software engineering responsibility | +| Source SysDes | System design item(s) from which the software requirement is directly derived | +| Verification method | Review, inspection, unit test, integration test, system test, platform test, security audit, performance test, demo, or release audit | +| Acceptance criteria | Objective condition for acceptance | +| Analysis | Technical feasibility and impact note | + + +## 4.1 Traceability Policy + +This SRS uses `Source SysDes` as the only direct upstream source field for individual `SRS-XXX` requirements. + +The approved lifecycle chain is: + +```text +System requirements baseline -> SysDes -> SRS +``` + +Therefore: + +- System-level requirements are allocated and justified in SysDes. +- SRS requirements are derived from SysDes design items. +- Individual SRS requirements shall cite `Source SysDes` only. +- Individual SRS requirements shall not directly cite upstream system requirement IDs. +- A missing software need shall be fixed by correcting SysDes first, then deriving or updating SRS. + +## 5. Software Requirements + +### 5.1 SWE.1 Process, Traceability, and Baseline Requirements + +**SRS-001**: The software requirements specification shall define software requirements derived from the approved Chanora SysDes baseline. + +- Type: Process / SWE.1 +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-001 through SysDes-003 +- Verification method: Review +- Acceptance criteria: SRS contains requirement statements, attributes, and source links to SysDes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-002**: Each software requirement shall have a unique `SRS-XXX` identifier, type, stage, software allocation, source SysDes link, verification method, acceptance criteria, and feasibility analysis. + +- Type: Process / Requirement Attribute +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-004 through SysDes-009, SysDes-092 through SysDes-097 +- Verification method: Inspection +- Acceptance criteria: Every SRS item contains the mandatory attribute fields. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-003**: The software requirements shall be structured by software component and cross-cutting concern to support allocation to the software team. + +- Type: Process / Structuring +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039 +- Verification method: Review +- Acceptance criteria: Document sections map to UI, state, bridge, Rust Core, protocol, audio, storage, diagnostics, platform adapters, packaging, and verification hooks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-004**: The software requirements shall be prioritized using P0 / MVP, P1 / Beta, P2 / Production, and P3 / Future stage labels. + +- Type: Process / Prioritization +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110 +- Verification method: Inspection +- Acceptance criteria: Each SRS item contains a stage value. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-005**: The software requirements shall maintain bidirectional traceability to SysDes design items only; upstream system-requirement coverage shall be inherited through the approved SysDes allocation baseline. + +- Type: Process / Traceability +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110 +- Verification method: Inspection +- Acceptance criteria: Coverage matrix shows SysDes-to-SRS and SRS-to-SysDes mappings, without direct links from SRS requirements to upstream system requirement IDs. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-006**: The software requirements shall analyze impact on the operating environment for OS services, audio hardware, network connectivity, external compatible servers, secure storage, deployment, and mobile lifecycle constraints. + +- Type: Process / Operating Environment Analysis +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101 +- Verification method: Review +- Acceptance criteria: Operating environment section identifies software impacts and external dependencies. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-007**: The agreed SRS baseline shall be communicated to SAD, SDD, implementation, and verification authors. + +- Type: Process / Communication +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-003, SysDes-098 through SysDes-100 +- Verification method: Review +- Acceptance criteria: Revision history and communication section identify affected parties and downstream use. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.2 Software Boundary and Architecture Requirements + +**SRS-008**: The software shall be implemented as a cross-platform client application and shall not be implemented or described as an operating system. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Application Container +- Source SysDes: SysDes-002, SysDes-024 +- Verification method: Review +- Acceptance criteria: App metadata, documentation, and architecture describe Chanora as an application. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-009**: The software shall operate without requiring Chanora-operated backend infrastructure for MVP voice, channel, and text operation. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Application Container, Rust Core +- Source SysDes: SysDes-016, SysDes-083 +- Verification method: Review, System Test +- Acceptance criteria: MVP operation connects directly to user-provided compatible servers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-010**: The software shall not implement TeamSpeak-compatible server hosting functionality in MVP. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Application Container, Protocol Adapter +- Source SysDes: SysDes-023, SysDes-082, SysDes-083 +- Verification method: Inspection +- Acceptance criteria: No server-hosting module or process exists in the MVP software. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-011**: The software shall use a layered structure that separates Flutter UI, Flutter State, Bridge, Rust Core, Protocol Adapter, State Sync, Audio, Storage, Diagnostics, and Platform Adapters. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: All Software Components +- Source SysDes: SysDes-010, SysDes-038, SysDes-039, SysDes-041 +- Verification method: Inspection +- Acceptance criteria: Repository and dependency graph show separate modules/crates/layers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-012**: The software shall keep real-time audio processing outside Flutter UI. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Audio Subsystem +- Source SysDes: SysDes-014, SysDes-040, SysDes-071, SysDes-072 +- Verification method: Inspection, Performance Test +- Acceptance criteria: Flutter UI does not process PCM frames or execute real-time DSP. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-013**: The software shall support Windows, macOS, Linux, iOS, and Android through shared Flutter UI, shared Rust Core, and platform-specific adapters. + +- Type: Platform Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Platform Adapters +- Source SysDes: SysDes-012, SysDes-032, SysDes-041 +- Verification method: Build Test +- Acceptance criteria: Target platform builds compile with shared core and platform adapter boundaries. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-014**: The software shall isolate OS-specific permissions, audio routing, lifecycle, secure storage, notification, and packaging behavior behind platform adapter interfaces. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Platform Adapters +- Source SysDes: SysDes-032, SysDes-050, SysDes-080 +- Verification method: Inspection, Integration Test +- Acceptance criteria: Platform-specific code is not embedded directly in core protocol or state modules. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-015**: The software shall provide verification hooks for protocol, state, audio, security, packaging, and platform behavior. + +- Type: Verification Hook +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters +- Source SysDes: SysDes-017, SysDes-102 through SysDes-107 +- Verification method: Inspection, Demo +- Acceptance criteria: Tools, logs, and tests expose evidence for each verification area. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.3 Application Container and Flutter UI Requirements + +**SRS-016**: The software shall provide an application container that initializes Flutter UI, Bridge, Rust Core, platform adapters, storage, and diagnostics in a deterministic startup sequence. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Application Container +- Source SysDes: SysDes-024, SysDes-038, SysDes-041 +- Verification method: Integration Test +- Acceptance criteria: Application startup reaches idle/home state without race-condition crashes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-017**: The software shall provide a home or entry screen for manual connection, recent servers, and saved bookmarks. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SysDes: SysDes-025, SysDes-055, SysDes-059 +- Verification method: UI Test +- Acceptance criteria: User can open connection and bookmark flows from the entry screen. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-018**: The software shall provide a manual connection UI that accepts host or IP address, port, nickname, and optional server password. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SysDes: SysDes-025, SysDes-055, SysDes-059, SysDes-065 +- Verification method: UI Test +- Acceptance criteria: Connection request can be submitted with all required fields and validated before dispatch. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-019**: The software shall display connection states including Disconnected, Connecting, Synchronizing, Connected, Reconnecting, and Failed or equivalent user-safe states. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066 +- Verification method: UI Test, System Test +- Acceptance criteria: UI state follows Rust Core connection events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-020**: The software shall display a server channel tree derived from the Rust Core snapshot and delta events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068 +- Verification method: UI Test, System Test +- Acceptance criteria: Channel tree updates after initial sync and live channel events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-021**: The software shall display online clients in their channels and update the display after client join, leave, and move events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068 +- Verification method: UI Test, System Test +- Acceptance criteria: Client list reflects snapshot and live delta changes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-022**: The software shall visually identify the current user and current channel when the data is available from Rust Core. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-025, SysDes-026, SysDes-030, SysDes-067 +- Verification method: UI Test +- Acceptance criteria: Current user and current channel receive distinct UI state markers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-023**: The software shall provide a channel join interaction that sends a join command through the Bridge and waits for Rust Core or protocol confirmation before treating the join as authoritative. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Bridge, Rust Core +- Source SysDes: SysDes-055, SysDes-069 +- Verification method: System Test +- Acceptance criteria: UI does not finalize current-channel state until confirmation or failure event is received. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-024**: The software shall provide channel text chat UI for message display and message input. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Bridge, Rust Core +- Source SysDes: SysDes-025, SysDes-055, SysDes-070 +- Verification method: UI Test, System Test +- Acceptance criteria: User can send text and receive displayed messages through core events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-025**: The software shall provide a persistent voice control surface for microphone mute, output deaf, push-to-talk state, input level, and current channel. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Audio Subsystem +- Source SysDes: SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072 +- Verification method: UI Test, System Test +- Acceptance criteria: Voice controls are visible and correctly update Rust Core/audio state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-026**: The software shall provide an audio settings UI for input device, output device, Echo Canceller, Automatic Gain Control, Noise Suppression, High-Pass Filter, and related defaults. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter UI, Audio Subsystem, Storage +- Source SysDes: SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086 +- Verification method: UI Test +- Acceptance criteria: Settings can be changed and persist across application restart where supported. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-027**: The software shall provide permission explanation UI before requesting microphone, notification, or mobile foreground-service related permissions where platform guidelines allow. + +- Type: Functional / Privacy +- Stage: P0 / MVP +- Allocated to: Flutter UI, Platform Adapters +- Source SysDes: SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 +- Verification method: UI Test, Privacy Review +- Acceptance criteria: Permission explainers appear before or with OS permission prompts as appropriate. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-028**: The software shall provide a diagnostics UI that allows user-initiated diagnostic export and displays user-safe diagnostic status. + +- Type: Functional / Diagnostics +- Stage: P1 / Beta +- Allocated to: Flutter UI, Diagnostics +- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105 +- Verification method: UI Test, Security Audit +- Acceptance criteria: User can export diagnostics only by explicit action, and export is redacted. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-029**: The Flutter UI shall not directly invoke `tsclientlib`, access raw protocol types, or own authoritative server state. + +- Type: Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Flutter State +- Source SysDes: SysDes-040, SysDes-052 through SysDes-054, SysDes-057 +- Verification method: Inspection +- Acceptance criteria: Static dependency analysis shows no UI dependency on protocol library types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-030**: The Flutter UI shall subscribe to UI-safe core events and reduce them into presentation state only. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Flutter State +- Source SysDes: SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068 +- Verification method: Inspection, UI Test +- Acceptance criteria: State providers/stores are driven by event DTOs and do not mutate Rust-owned server state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-031**: The software shall provide a typed Flutter-Rust Bridge API for connection, channel, chat, voice, settings, storage, and diagnostics commands. + +- Type: Interface +- Stage: P0 / MVP +- Allocated to: Bridge Layer +- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056 +- Verification method: Integration Test +- Acceptance criteria: Flutter can call each command group through generated or native bindings. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.4 Bridge Requirements + +**SRS-032**: The Bridge shall expose long-lived event streams from Rust Core to Flutter for connection, snapshot, delta, chat, voice, audio device, error, and diagnostic events. + +- Type: Interface +- Stage: P0 / MVP +- Allocated to: Bridge Layer, Rust Core +- Source SysDes: SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068 +- Verification method: Integration Test +- Acceptance criteria: Flutter receives ordered events and handles stream lifecycle without UI blocking. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-033**: The Bridge shall serialize and deserialize only bridge-safe DTOs and shall not expose Rust internal references or raw protocol library objects. + +- Type: Interface / Safety +- Stage: P0 / MVP +- Allocated to: Bridge Layer +- Source SysDes: SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057 +- Verification method: Inspection, Integration Test +- Acceptance criteria: Generated bindings contain DTOs and value objects only. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-034**: The Bridge shall map Rust Core errors into user-safe Flutter error DTOs. + +- Type: Interface / Error Handling +- Stage: P0 / MVP +- Allocated to: Bridge Layer, Rust Core +- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089 +- Verification method: Integration Test +- Acceptance criteria: Known error cases produce category, message, and recovery hint fields. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-035**: The Bridge shall execute commands asynchronously and shall not block the Flutter UI thread during network, storage, or audio operations. + +- Type: Non-functional +- Stage: P0 / MVP +- Allocated to: Bridge Layer, Rust Core +- Source SysDes: SysDes-027, SysDes-042, SysDes-046, SysDes-085 +- Verification method: Performance Test +- Acceptance criteria: UI remains responsive during connect, reconnect, sync, and diagnostic export. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-036**: The Rust Core shall own authoritative connection lifecycle and server state for each active connection. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Connection state transitions and snapshots are managed in Rust Core. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.5 Rust Core and Connection Management Requirements + +**SRS-037**: The Rust Core shall manage connection actors or equivalent isolated execution contexts for connection-specific commands and events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066 +- Verification method: Inspection, Unit Test +- Acceptance criteria: Each connection has an isolated command/event path. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-038**: The Rust Core shall expose connect, disconnect, reconnect, join channel, send message, audio control, settings, bookmark, identity, and diagnostics commands to the Bridge. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core, Bridge +- Source SysDes: SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076 +- Verification method: Integration Test +- Acceptance criteria: Bridge command suite calls corresponding Rust Core operations. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-039**: The Rust Core shall coordinate protocol, state synchronization, audio, storage, diagnostics, and platform adapter interfaces without leaking implementation details to Flutter. + +- Type: Functional / Architecture +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077 +- Verification method: Inspection +- Acceptance criteria: Core public API exposes stable DTOs and not internal crate types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-040**: The Rust Core shall emit connection status events for Connecting, Synchronizing, Connected, Reconnecting, Disconnected, and failure states. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core, State Sync +- Source SysDes: SysDes-060, SysDes-064, SysDes-066, SysDes-074 +- Verification method: Unit Test, System Test +- Acceptance criteria: Status event sequence matches connection state machine under normal and failure flows. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-041**: The Rust Core shall suppress automatic reconnect after user-triggered disconnect. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Rust Core +- Source SysDes: SysDes-064, SysDes-073, SysDes-074, SysDes-088 +- Verification method: System Test +- Acceptance criteria: User disconnect results in Disconnected state and no reconnect attempt. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-042**: The Rust Core shall apply reconnect policy after recoverable network or protocol failures. + +- Type: Functional / Reliability +- Stage: P0 / MVP +- Allocated to: Rust Core, Protocol Adapter, State Sync +- Source SysDes: SysDes-064, SysDes-066, SysDes-074, SysDes-088 +- Verification method: System Test +- Acceptance criteria: Recoverable failure enters Reconnecting and either recovers or reports safe failure. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-043**: The Rust Core shall rebuild server state from a fresh snapshot after reconnect succeeds. + +- Type: Functional / Reliability +- Stage: P0 / MVP +- Allocated to: Rust Core, State Sync +- Source SysDes: SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088 +- Verification method: System Test, Event Replay Test +- Acceptance criteria: Post-reconnect state is produced from new snapshot, not patched from stale state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-044**: The Protocol Adapter shall be the only software component that directly depends on `tsclientlib`. + +- Type: Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Protocol Adapter +- Source SysDes: SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078 +- Verification method: Inspection +- Acceptance criteria: Dependency graph shows `tsclientlib` dependency only in protocol adapter crate/module. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.6 Protocol Adapter Requirements + +**SRS-045**: The Protocol Adapter shall connect to TeamSpeak 3-compatible servers through `tsclientlib` using user-provided host, port, nickname, identity, and optional password. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core +- Source SysDes: SysDes-029, SysDes-043, SysDes-065, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Protocol probe and app can establish a session to a compatible test server. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-046**: The Protocol Adapter shall fetch server information, channel list, client list, and current-user information needed to build the initial snapshot. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, State Sync +- Source SysDes: SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Initial snapshot has server, channel, client, and self-client data. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-047**: The Protocol Adapter shall translate raw `tsclientlib` events into internal protocol events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, State Sync +- Source SysDes: SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Known client, channel, message, voice, and disconnect events map to internal events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-048**: The Protocol Adapter shall translate protocol errors into normalized Chanora protocol errors. + +- Type: Functional / Error Handling +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core +- Source SysDes: SysDes-029, SysDes-043, SysDes-045, SysDes-088 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Known network, authentication, permission, and protocol failures produce normalized errors. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-049**: The Protocol Adapter shall implement channel join commands and report success or failure to Rust Core. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter +- Source SysDes: SysDes-029, SysDes-043, SysDes-069, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Accessible channel join succeeds; denied join reports user-safe failure. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-050**: The Protocol Adapter shall implement channel text message send and receive paths. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter +- Source SysDes: SysDes-029, SysDes-043, SysDes-070, SysDes-102 +- Verification method: Protocol Integration Test +- Acceptance criteria: Text sent from UI reaches server and incoming text reaches core events. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-051**: The Protocol Adapter shall implement voice packet send and receive paths required by the audio subsystem. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Audio Subsystem +- Source SysDes: SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104 +- Verification method: Protocol Integration Test, Audio Test +- Acceptance criteria: Encoded outgoing frames are sent and incoming voice packets are delivered to audio pipeline. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-052**: The Protocol Adapter shall expose protocol-probe diagnostics for connection, snapshot, event, text, and voice compatibility. + +- Type: Verification Hook +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Diagnostics +- Source SysDes: SysDes-017, SysDes-035, SysDes-102 +- Verification method: Demo +- Acceptance criteria: Protocol probe produces compatibility output for test servers. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-053**: The Protocol Adapter shall support future patching, forking, or replacement of protocol implementation without changing Flutter UI contracts. + +- Type: Maintainability +- Stage: P1 / Beta +- Allocated to: Protocol Adapter, Bridge +- Source SysDes: SysDes-011, SysDes-029, SysDes-043, SysDes-078 +- Verification method: Architecture Review +- Acceptance criteria: Protocol adapter trait/API boundary isolates library-specific types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-054**: The State Synchronization Engine shall maintain a connection state model containing connection status, server info, current user, channels, clients, channel tree, permissions, chat state, and voice state where available. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068 +- Verification method: Unit Test +- Acceptance criteria: State object can represent required snapshot and runtime states. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.7 State Synchronization Requirements + +**SRS-055**: The State Synchronization Engine shall produce a full snapshot event after initial synchronization. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-067 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: SnapshotReady event is emitted after server, channel, and client data are available. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-056**: The State Synchronization Engine shall apply live server events as deterministic deltas. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-061, SysDes-068 +- Verification method: Unit Test +- Acceptance criteria: Same event sequence produces same final state and emitted deltas. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-057**: The State Synchronization Engine shall preserve per-connection event ordering. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync, Rust Core +- Source SysDes: SysDes-030, SysDes-044, SysDes-047, SysDes-068 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Out-of-order processing is prevented or deterministically handled per connection. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-058**: The State Synchronization Engine shall use reducer functions or equivalent deterministic logic for snapshot, channel, client, chat, voice, and connection events. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103 +- Verification method: Unit Test +- Acceptance criteria: Reducer tests cover snapshot and major delta event types. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-059**: The State Synchronization Engine shall replace stale server state with a fresh snapshot after reconnect. + +- Type: Functional / Reliability +- Stage: P0 / MVP +- Allocated to: State Sync +- Source SysDes: SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103 +- Verification method: Event Replay Test, System Test +- Acceptance criteria: Reconnect tests confirm old channel/client state is replaced. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-060**: The State Synchronization Engine shall tolerate malformed or unexpected protocol events without crashing the application. + +- Type: Reliability +- Stage: P0 / MVP +- Allocated to: State Sync, Rust Core +- Source SysDes: SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103 +- Verification method: Unit Test, Fuzz/Negative Test +- Acceptance criteria: Malformed event tests produce safe error or ignored event behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-061**: The State Synchronization Engine shall provide replayable event recording hooks for debugging state synchronization. + +- Type: Verification Hook +- Stage: P1 / Beta +- Allocated to: State Sync, Diagnostics +- Source SysDes: SysDes-030, SysDes-035, SysDes-079, SysDes-103 +- Verification method: Demo +- Acceptance criteria: Recorded event stream can be replayed to reproduce state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-062**: The Audio Subsystem shall coordinate audio capture, preprocessing, audio processing, Opus-compatible encoding, voice packet handoff, receive decoding, jitter buffering, per-user controls, mixing, and playback. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104 +- Verification method: Audio Integration Test +- Acceptance criteria: End-to-end voice send and receive operate through the audio subsystem. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.8 Audio Subsystem Requirements + +**SRS-063**: The Audio Subsystem shall process outgoing microphone PCM frames before encoding. + +- Type: Functional +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Capture pipeline accepts PCM frames and outputs encoded voice frames when gate allows. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-064**: The Audio Subsystem shall apply a High-Pass Filter before voice encoding when enabled. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: Low-frequency attenuation is measurable in HPF test cases. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-065**: The Audio Subsystem shall apply Noise Suppression before voice encoding when enabled. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: Stationary-noise reduction is measurable or verified by backend tests. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-066**: The Audio Subsystem shall apply Echo Canceller before voice encoding when enabled and when playback reference audio is available or the selected backend provides equivalent behavior. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: Echo cancellation backend can use playback reference or platform equivalent. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-067**: The Audio Subsystem shall apply Automatic Gain Control before voice encoding when enabled. + +- Type: Functional / Audio Processing +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 +- Verification method: Audio Processing Test +- Acceptance criteria: AGC normalizes input gain without unacceptable clipping under test cases. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-068**: The Audio Subsystem shall expose enable/disable settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. + +- Type: Functional / Settings +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI, Storage +- Source SysDes: SysDes-031, SysDes-033, SysDes-056, SysDes-081 +- Verification method: UI Test, Unit Test +- Acceptance criteria: Changing each setting updates Rust Core/audio configuration and persists locally. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-069**: The Audio Subsystem shall support conservative default audio processing configuration per platform. + +- Type: Non-functional / Audio +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-013, SysDes-031, SysDes-081, SysDes-086 +- Verification method: Review, Audio Test +- Acceptance criteria: Default configuration is documented and validated for each supported platform. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-070**: The Audio Subsystem shall provide an audio processing backend abstraction supporting platform-native and Rust-based implementations. + +- Type: Architecture / Audio +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-031, SysDes-032, SysDes-058, SysDes-081 +- Verification method: Inspection +- Acceptance criteria: Backend trait/interface allows substitution without Flutter UI changes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-071**: The Audio Subsystem shall encode outgoing voice using an Opus-compatible encoder. + +- Type: Functional / Audio Codec +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-071, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: PCM input produces decodable Opus-compatible encoded frames. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-072**: The Audio Subsystem shall decode incoming voice using an Opus-compatible decoder. + +- Type: Functional / Audio Codec +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Incoming encoded frames produce expected PCM output. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-073**: The Audio Subsystem shall use jitter buffering for incoming voice packets. + +- Type: Functional / Audio Playback +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Packet jitter test produces continuous playback without buffer instability within defined limits. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-074**: The Audio Subsystem shall support per-user mute during playback. + +- Type: Functional / Audio Playback +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI +- Source SysDes: SysDes-031, SysDes-058, SysDes-072 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Muted remote user is not mixed into output. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-075**: The Audio Subsystem shall support per-user volume during playback. + +- Type: Functional / Audio Playback +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Flutter UI, Storage +- Source SysDes: SysDes-031, SysDes-033, SysDes-058, SysDes-072 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Remote user gain changes affect only that user and persist where applicable. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-076**: The Audio Subsystem shall mix decoded incoming voice streams before playback. + +- Type: Functional / Audio Playback +- Stage: P0 / MVP +- Allocated to: Audio Subsystem +- Source SysDes: SysDes-031, SysDes-058, SysDes-072, SysDes-104 +- Verification method: Audio Test +- Acceptance criteria: Multiple incoming streams are mixed into a playback stream without clipping beyond defined limits. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-077**: The Audio Subsystem shall implement microphone mute as a gate that prevents local voice transmission. + +- Type: Functional / Voice Control +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Rust Core, Flutter UI +- Source SysDes: SysDes-031, SysDes-063, SysDes-071 +- Verification method: System Test +- Acceptance criteria: When muted, no outgoing voice packets are sent. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-078**: The Audio Subsystem shall implement output deaf as a gate that prevents incoming voice playback. + +- Type: Functional / Voice Control +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Rust Core, Flutter UI +- Source SysDes: SysDes-031, SysDes-063, SysDes-072 +- Verification method: System Test +- Acceptance criteria: When deafened, incoming voice is not played. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-079**: The Audio Subsystem shall implement push-to-talk gating before outgoing voice packet transmission. + +- Type: Functional / Voice Control +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI +- Source SysDes: SysDes-031, SysDes-063, SysDes-071 +- Verification method: System Test +- Acceptance criteria: Outgoing voice is sent only when push-to-talk is active unless configured otherwise. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-080**: The Audio Subsystem shall provide input level metering to Rust Core or Flutter through UI-safe events. + +- Type: Functional / Voice Metering +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Flutter UI +- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-071 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Input level meter changes with microphone input. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-081**: The Audio Subsystem shall provide speaking indicator events for local and remote users where available. + +- Type: Functional / Voice Metering +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, State Sync, Flutter UI +- Source SysDes: SysDes-025, SysDes-031, SysDes-063, SysDes-072 +- Verification method: Audio Test, UI Test +- Acceptance criteria: Speaking indicators activate according to local gate and remote voice activity. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-082**: The Audio Subsystem shall recover from audio route or device changes by reconfiguring audio streams or entering a user-safe blocked/degraded state. + +- Type: Reliability / Audio +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-032, SysDes-050, SysDes-075, SysDes-086 +- Verification method: Platform Integration Test +- Acceptance criteria: Device disconnect/change does not crash the app and reports clear status. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-083**: The Audio Subsystem shall provide audio loopback and processing test hooks for verification. + +- Type: Verification Hook +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Diagnostics +- Source SysDes: SysDes-017, SysDes-035, SysDes-104 +- Verification method: Demo +- Acceptance criteria: Audio test tools can exercise capture, processing, encode/decode, jitter, mixer, and playback paths. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-084**: The software shall persist bookmarks in local non-secret storage. + +- Type: Functional / Storage +- Stage: P0 / MVP +- Allocated to: Storage +- Source SysDes: SysDes-033, SysDes-036, SysDes-049 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Bookmark create, update, delete, and list operations persist across restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.9 Storage and Secure Storage Requirements + +**SRS-085**: The software shall persist recent servers in local non-secret storage. + +- Type: Functional / Storage +- Stage: P1 / Beta +- Allocated to: Storage +- Source SysDes: SysDes-033, SysDes-036, SysDes-049 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Recent server entries are stored and displayed after restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-086**: The software shall persist audio settings in local non-secret storage. + +- Type: Functional / Storage +- Stage: P0 / MVP +- Allocated to: Storage, Audio Subsystem +- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: Audio settings survive application restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-087**: The software shall persist UI settings in local non-secret storage. + +- Type: Functional / Storage +- Stage: P1 / Beta +- Allocated to: Storage, Flutter UI +- Source SysDes: SysDes-033, SysDes-036, SysDes-049 +- Verification method: Unit Test, Integration Test +- Acceptance criteria: UI settings survive application restart. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-088**: The software shall persist per-user volume and per-user mute preferences where applicable. + +- Type: Functional / Storage +- Stage: P1 / Beta +- Allocated to: Storage, Audio Subsystem +- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-072 +- Verification method: Unit Test +- Acceptance criteria: Preferences are stored by server/user identity keys where available. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-089**: The software shall use SQLite or an equivalent embedded data store for non-secret local data. + +- Type: Architecture / Storage +- Stage: P0 / MVP +- Allocated to: Storage +- Source SysDes: SysDes-033, SysDes-036, SysDes-049, SysDes-091 +- Verification method: Inspection +- Acceptance criteria: Storage implementation uses an embedded local data store and migration mechanism. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-090**: The software shall access platform secure storage only through a secure storage provider abstraction. + +- Type: Interface / Security +- Stage: P0 / MVP +- Allocated to: Storage, Platform Adapters +- Source SysDes: SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105 +- Verification method: Inspection, Security Audit +- Acceptance criteria: Secrets are read/written through secure storage interface only. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-091**: The software shall store identity private keys using platform secure storage and shall not persist them in plaintext files. + +- Type: Security +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage +- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Filesystem and database inspection shows no plaintext private keys. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-092**: The software shall store server passwords using platform secure storage and shall not persist them in plaintext logs or non-secret database fields. + +- Type: Security +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage, Diagnostics +- Source SysDes: SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Password values are redacted from logs and absent from non-secret storage. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-093**: The software shall redact secrets before writing diagnostic logs or diagnostic exports. + +- Type: Security / Diagnostics +- Stage: P0 / MVP +- Allocated to: Diagnostics, Storage +- Source SysDes: SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Diagnostic redaction tests cover private keys, passwords, tokens, and known secret fields. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-094**: The software shall validate user input before passing values to protocol operations or storage operations. + +- Type: Security +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage +- Source SysDes: SysDes-045, SysDes-065, SysDes-089, SysDes-105 +- Verification method: Unit Test, Security Test +- Acceptance criteria: Invalid host, port, nickname, password, and path-like values are rejected or sanitized safely. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-095**: The software shall produce structured diagnostic logs for connection, protocol, state, audio, storage, platform, and release-relevant events. + +- Type: Diagnostics +- Stage: P0 / MVP +- Allocated to: Diagnostics +- Source SysDes: SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105 +- Verification method: Inspection, Demo +- Acceptance criteria: Logs contain structured fields and categories without secrets. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.10 Diagnostics, Security, and Privacy Requirements + +**SRS-096**: The software shall support user-initiated diagnostic export. + +- Type: Diagnostics +- Stage: P1 / Beta +- Allocated to: Diagnostics, Flutter UI +- Source SysDes: SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105 +- Verification method: Demo, Security Audit +- Acceptance criteria: Export is available only after user action and output is redacted. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-097**: The software shall provide protocol event recording in development or diagnostics mode. + +- Type: Diagnostics / Verification Hook +- Stage: P1 / Beta +- Allocated to: Diagnostics, Protocol Adapter, State Sync +- Source SysDes: SysDes-035, SysDes-079, SysDes-102, SysDes-103 +- Verification method: Demo +- Acceptance criteria: Recorded protocol/core event file can be generated in diagnostics mode. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-098**: The software shall provide event replay support for state synchronization debugging. + +- Type: Diagnostics / Verification Hook +- Stage: P1 / Beta +- Allocated to: Diagnostics, State Sync +- Source SysDes: SysDes-035, SysDes-079, SysDes-103 +- Verification method: Demo +- Acceptance criteria: Event replay can rebuild expected state from a recorded sequence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-099**: The software shall provide audio diagnostics for capture, processing backend, codec, jitter buffer, mixer, playback, and route/device status. + +- Type: Diagnostics / Verification Hook +- Stage: P1 / Beta +- Allocated to: Diagnostics, Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-035, SysDes-075, SysDes-086, SysDes-104 +- Verification method: Demo +- Acceptance criteria: Audio diagnostics report current pipeline and device status. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-100**: The software shall provide network diagnostics for connection status, reconnect attempts, latency where available, and protocol-relevant network failures. + +- Type: Diagnostics / Reliability +- Stage: P1 / Beta +- Allocated to: Diagnostics, Rust Core, Protocol Adapter +- Source SysDes: SysDes-035, SysDes-074, SysDes-088, SysDes-102 +- Verification method: Demo +- Acceptance criteria: Diagnostics include network and reconnect evidence without secrets. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-101**: The software shall minimize personal data collection in MVP. + +- Type: Privacy +- Stage: P0 / MVP +- Allocated to: All Software Components +- Source SysDes: SysDes-090, SysDes-105 +- Verification method: Privacy Review +- Acceptance criteria: MVP does not collect telemetry or upload personal diagnostics automatically. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-102**: The software shall not automatically upload diagnostics in MVP. + +- Type: Privacy / Constraint +- Stage: P0 / MVP +- Allocated to: Diagnostics +- Source SysDes: SysDes-090, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: No automatic diagnostic upload endpoint or job is present. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-103**: The software shall display user-safe errors without raw internal stack traces. + +- Type: Security / Error Handling +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Bridge, Diagnostics +- Source SysDes: SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089 +- Verification method: UI Test, Security Review +- Acceptance criteria: Runtime errors displayed to users contain safe message and recovery hint only. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-104**: The software shall provide a platform adapter interface for microphone capture. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071 +- Verification method: Platform Integration Test +- Acceptance criteria: Each supported platform can provide captured PCM frames to the audio pipeline. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.11 Platform Adapter Requirements + +**SRS-105**: The software shall provide a platform adapter interface for speaker/headphone playback. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072 +- Verification method: Platform Integration Test +- Acceptance criteria: Each supported platform can play mixed PCM frames from the audio pipeline. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-106**: The software shall provide a platform adapter interface for audio device enumeration and selection where supported. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem, Flutter UI +- Source SysDes: SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075 +- Verification method: Platform Integration Test +- Acceptance criteria: Input/output device lists are exposed and selection changes are applied or reported as unsupported. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-107**: The software shall provide a platform adapter interface for audio route changes. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086 +- Verification method: Platform Integration Test +- Acceptance criteria: Route changes are emitted to Rust Core/Flutter and handled safely. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-108**: The software shall provide a platform adapter interface for microphone permission requests. + +- Type: Interface / Platform +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Flutter UI +- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 +- Verification method: Platform Integration Test +- Acceptance criteria: Permission state is queryable and request flow triggers platform permission behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-109**: The software shall provide a platform adapter interface for notification permission requests where required. + +- Type: Interface / Platform +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Flutter UI +- Source SysDes: SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 +- Verification method: Platform Integration Test +- Acceptance criteria: Notification permission flow is available on platforms requiring it. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-110**: The iOS software shall integrate with AVAudioSession or equivalent platform audio session behavior for foreground voice sessions. + +- Type: Platform / iOS +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 +- Verification method: iOS Integration Test +- Acceptance criteria: iOS foreground voice session handles capture, playback, route change, and interruption callbacks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-111**: The Android software shall integrate with foreground service behavior for active voice sessions. + +- Type: Platform / Android +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 +- Verification method: Android Integration Test +- Acceptance criteria: Android active voice session uses foreground service behavior according to platform rules. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-112**: The Android software shall handle audio focus and Bluetooth route changes where platform APIs expose them. + +- Type: Platform / Android +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 +- Verification method: Android Integration Test +- Acceptance criteria: Audio focus loss/gain and Bluetooth route events are handled safely. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-113**: The desktop software shall support validated audio backends for Windows, macOS, and Linux. + +- Type: Platform / Desktop +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 +- Verification method: Desktop Integration Test +- Acceptance criteria: Desktop audio capture/playback works on representative Windows, macOS, and Linux systems. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-114**: The software shall provide platform adapter lifecycle events for foreground/background, app resume, app suspend, audio interruption, and shutdown where supported. + +- Type: Interface / Platform +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Rust Core, Audio Subsystem +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 +- Verification method: Platform Integration Test +- Acceptance criteria: Lifecycle events reach Rust Core and do not corrupt connection/audio state. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-115**: The software shall document unsupported or degraded platform behaviors through user-safe status and diagnostics. + +- Type: Platform / Diagnostics +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Diagnostics, Flutter UI +- Source SysDes: SysDes-050, SysDes-075, SysDes-084, SysDes-090 +- Verification method: Review, Demo +- Acceptance criteria: Unsupported device/permission/lifecycle cases are visible in UI or diagnostics. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-116**: The software shall produce build artifacts for Windows installer packaging. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: Windows installer artifact is generated from configured CI or release script. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.12 Packaging and Release Requirements + +**SRS-117**: The software shall produce signed and notarized macOS release builds for production release. + +- Type: Packaging +- Stage: P2 / Production +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build/Release Audit +- Acceptance criteria: macOS release process includes signing and notarization evidence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-118**: The software shall produce Linux release packages using the selected supported package formats. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: At least one selected Linux package format is generated. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-119**: The software shall produce Android AAB release builds. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: Android AAB build succeeds with release configuration. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-120**: The software shall produce iOS TestFlight and App Store release builds when signing assets are available. + +- Type: Packaging +- Stage: P1 / Beta +- Allocated to: Application Container, Deployment Scripts +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test +- Acceptance criteria: iOS archive/export succeeds on supported macOS build environment. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-121**: The software release metadata and in-app wording shall not imply official TeamSpeak affiliation. + +- Type: Legal / Product Constraint +- Stage: P0 / MVP +- Allocated to: Application Container, Flutter UI, Deployment Scripts +- Source SysDes: SysDes-005, SysDes-036, SysDes-091, SysDes-106 +- Verification method: Legal Review, Inspection +- Acceptance criteria: App metadata, UI copy, README, and store text use independent compatibility wording. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-122**: The software shall provide release-build configuration that disables development-only diagnostic capture unless explicitly enabled for test builds. + +- Type: Security / Release +- Stage: P1 / Beta +- Allocated to: Application Container, Diagnostics, Deployment Scripts +- Source SysDes: SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106 +- Verification method: Inspection, Security Review +- Acceptance criteria: Production configuration does not enable protocol recording or verbose logs by default. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-123**: The software shall include or support a protocol probe tool for validating `tsclientlib` adapter behavior against compatible test servers. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Diagnostics +- Source SysDes: SysDes-017, SysDes-035, SysDes-102 +- Verification method: Demo +- Acceptance criteria: Protocol probe reports connection, snapshot, event, text, and voice compatibility evidence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.13 Verification Support Requirements + +**SRS-124**: The software shall include reducer tests and event replay tests for state synchronization. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: State Sync, Diagnostics +- Source SysDes: SysDes-030, SysDes-035, SysDes-103 +- Verification method: Unit Test, Demo +- Acceptance criteria: Reducer and replay tests cover snapshot, delta, reconnect, and malformed-event behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-125**: The software shall include audio loopback and audio processing tests for capture, playback, codec, jitter buffer, mixer, Echo Canceller, AGC, Noise Suppression, and High-Pass Filter. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Diagnostics +- Source SysDes: SysDes-031, SysDes-035, SysDes-104 +- Verification method: Audio Test, Demo +- Acceptance criteria: Audio verification tools execute required audio processing checks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-126**: The software shall include security verification support for secure storage, private-key handling, password handling, input validation, and diagnostic redaction. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: Storage, Diagnostics, Platform Adapters +- Source SysDes: SysDes-034, SysDes-035, SysDes-089, SysDes-105 +- Verification method: Security Audit +- Acceptance criteria: Security checklist and tests cover required sensitive data behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-127**: The software shall include release verification support for package creation, signing, notarization, app-store builds, and release metadata wording. + +- Type: Verification Support +- Stage: P1 / Beta +- Allocated to: Deployment Scripts, Application Container +- Source SysDes: SysDes-036, SysDes-091, SysDes-106 +- Verification method: Build Test, Release Audit +- Acceptance criteria: Release verification checklist covers each target platform and metadata review. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-128**: The software shall support MVP acceptance verification demonstrating connection, channel tree, online clients, channel join, send/receive voice, mute, deaf, push-to-talk, required audio processing, channel text, bookmarks, secure storage, and redacted diagnostics. + +- Type: Verification Support +- Stage: P0 / MVP +- Allocated to: All Software Components +- Source SysDes: SysDes-017, SysDes-035, SysDes-102 through SysDes-107 +- Verification method: System Test, Demo +- Acceptance criteria: MVP acceptance test run passes all acceptance checks. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-129**: The software shall expose clear user-facing errors when client hardware lacks a usable microphone, output device, CPU capacity, storage, or network interface required for the requested operation. + +- Type: Operating Environment Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-020, SysDes-045, SysDes-086, SysDes-089 +- Verification method: System Test +- Acceptance criteria: Missing hardware/resource conditions produce non-crashing user-safe errors. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.14 Operating Environment and External Interface Requirements + +**SRS-130**: The software shall expose clear user-facing errors when network connectivity prevents server connection or real-time voice operation. + +- Type: Operating Environment Constraint +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Protocol Adapter +- Source SysDes: SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088 +- Verification method: System Test +- Acceptance criteria: Network failures produce reconnect or safe error behavior. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-131**: The software shall handle external compatible server permissions, availability, and event behavior as external dependencies and shall not assume administrative control. + +- Type: Operating Environment Constraint +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Rust Core, Flutter UI +- Source SysDes: SysDes-023, SysDes-043, SysDes-082, SysDes-102 +- Verification method: System Test +- Acceptance criteria: Permission denied and server unavailable cases produce user-safe outcomes. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-132**: The software shall allow server details, credentials, and identity selection to be supplied by the user rather than hardcoding a server environment. + +- Type: Functional / Environment +- Stage: P0 / MVP +- Allocated to: Flutter UI, Rust Core, Protocol Adapter, Storage +- Source SysDes: SysDes-019, SysDes-023, SysDes-055, SysDes-065 +- Verification method: UI Test, System Test +- Acceptance criteria: User can provide and save server details without Chanora backend dependency. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-133**: The software shall integrate with OS-level secure storage, permission, audio, network, notification, lifecycle, and app sandboxing policies through platform adapters. + +- Type: Operating Environment Interface +- Stage: P0 / MVP +- Allocated to: Platform Adapters, Rust Core, Flutter UI +- Source SysDes: SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090 +- Verification method: Platform Integration Test +- Acceptance criteria: Platform services are used through approved adapter APIs. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-134**: The software team shall analyze `tsclientlib` feasibility for all MVP protocol features and document unsupported or risky features before MVP acceptance. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Software Requirements Engineering +- Source SysDes: SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102 +- Verification method: Review, Protocol Probe +- Acceptance criteria: Protocol compatibility matrix identifies pass/fail/unknown state for MVP protocol features. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +### 5.15 Technical Feasibility and Impact Analysis Requirements + +**SRS-135**: The software team shall analyze real-time audio feasibility on each target platform for capture, playback, required audio processing, and latency. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Platform Adapters +- Source SysDes: SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104 +- Verification method: Review, Audio Test +- Acceptance criteria: Audio feasibility report exists per platform with known limitations and mitigations. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-136**: The software team shall analyze memory growth and define limits for event queues, chat history, logs, audio buffers, and diagnostic bundles. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage +- Source SysDes: SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087 +- Verification method: Review, Performance Test +- Acceptance criteria: Resource limit configuration and tests exist for queues, buffers, and logs. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-137**: The software team shall analyze security and privacy impacts of local secrets, logs, diagnostics, permissions, and release configuration. + +- Type: Analysis Requirement +- Stage: P0 / MVP +- Allocated to: Storage, Diagnostics, Platform Adapters, Flutter UI +- Source SysDes: SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 +- Verification method: Security Review, Privacy Review +- Acceptance criteria: Security/privacy analysis documents risks, mitigations, and verification evidence. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-138**: The software team shall analyze operating-environment impacts of mobile lifecycle, foreground service behavior, AVAudioSession behavior, route changes, and app store policies. + +- Type: Analysis Requirement +- Stage: P1 / Beta +- Allocated to: Platform Adapters, Audio Subsystem, Deployment Scripts +- Source SysDes: SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106 +- Verification method: Review, Platform Test +- Acceptance criteria: Mobile lifecycle analysis documents behavior and limitations. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-139**: The software requirements baseline shall account for SysDes-037: SE-19 Engineering Process and Evidence shall be a defined system element in the Chanora architecture with responsibility for: Architecture reviews, traceability records, verification evidence, compatibility matrix, open decisions, and downstream SRS/SAD/SDD/Verification artifacts. + +- Type: Traceability / Coverage +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-037 +- Verification method: Review +- Acceptance criteria: SysDes-037 is represented in SRS traceability and downstream software analysis. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-140**: The software requirements baseline shall account for SysDes-062: The permission-blocked mode shall prevent unsafe voice operations while preserving user visibility into corrective actions. + +- Type: Traceability / Coverage +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-062 +- Verification method: Review +- Acceptance criteria: SysDes-062 is represented in SRS traceability and downstream software analysis. +- Analysis: Feasible with current Flutter + Rust Core architecture; refine in SAD/SDD as needed. +- Owner: Software Team + +**SRS-141**: The SRS shall use SysDes design items as the mandatory architectural allocation source for every software requirement. + +- Type: Process / Traceability +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering +- Source SysDes: SysDes-108, SysDes-109 +- Verification method: Review, Inspection +- Acceptance criteria: Every SRS requirement has a `Source SysDes` field and no individual SRS requirement uses an upstream system-requirement ID as its direct source. +- Analysis: Feasible because SysDes v0.5 defines the downstream derivation rule and software-impacting allocation layer. +- Owner: Software Team + +**SRS-142**: If the software team identifies a required software behavior, constraint, or interface that cannot be derived from an existing SysDes design item, the SRS shall not be baselined until the SysDes is revised. + +- Type: Process / Change Control +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering, Change Control +- Source SysDes: SysDes-110 +- Verification method: Review, Inspection +- Acceptance criteria: Change-control records show SysDes-first correction for any new software requirement source gap. +- Analysis: Feasible through requirements review and change-control workflow before SRS baseline. +- Owner: Software Team + +**SRS-143**: The SRS shall maintain a SysDes-to-SRS coverage matrix for all SysDes items that require software implementation, software enablement, software-facing constraint handling, or software verification support. + +- Type: Process / Coverage +- Stage: P0 / MVP +- Allocated to: Software Requirements Engineering, Verification +- Source SysDes: SysDes-108, SysDes-109, SysDes-110 +- Verification method: Review, Inspection +- Acceptance criteria: Coverage matrix shows that each software-impacting SysDes item is covered by one or more SRS requirements, or explicitly identified as non-software-owned. +- Analysis: Feasible with the SysDes metadata register and SRS coverage matrix. +- Owner: Software Team + + +## 6. Operating Environment Impact Analysis + +| Environment element | Software impact | Related SRS | +|---|---|---| +| Client hardware | Software must detect or report missing microphone, output device, CPU/storage/network resource constraints. | SRS-130 | +| OS services | Software must integrate with permissions, secure storage, audio stack, lifecycle, notifications, and sandbox policies through platform adapters. | SRS-105 through SRS-116, SRS-134 | +| Network | Software must handle unreachable servers, recoverable failures, reconnect, and user-safe errors. | SRS-131 | +| External compatible server | Software must treat server permissions, availability, authentication, events, and protocol behavior as external dependencies. | SRS-132, SRS-133 | +| Audio devices | Software must handle input/output device selection, route changes, and degraded audio states. | SRS-107 through SRS-110 | +| Mobile lifecycle | Software must handle foreground voice sessions, audio interruption, route changes, and background policy limits. | SRS-111 through SRS-115, SRS-139 | +| Secure storage | Software must use platform secure storage through an abstraction and avoid plaintext secret persistence. | SRS-091 through SRS-095 | +| Deployment environment | Software must produce platform-specific release packages and safe release metadata. | SRS-117 through SRS-123 | + +## 7. Software Requirement Analysis Summary + +| Analysis area | Result | Follow-up artifact | +|---|---|---| +| Correctness | Requirements are derived from SysDes and structured by software component. | SAD / SDD | +| Technical feasibility | Feasibility checks are required for `tsclientlib`, audio processing, mobile lifecycle, resource limits, and security. | Analysis report, SAD, SDD | +| Testability | Each requirement contains verification method and acceptance criteria. | Verification plan | +| Operating environment impact | OS services, hardware, network, server, deployment, and mobile lifecycle impacts are captured. | Platform design, Verification plan | +| Traceability | Every SysDes design item is mapped to one or more SRS requirements; direct SRS-to-upstream-system-requirement links are intentionally not used. | Traceability matrix | +| Communication | SRS baseline shall be communicated downstream to SWE.2/SAD, SWE.3/SDD, and SWE.6/Verification. | Review evidence | + +## 8. SRS to SWE Lifecycle Handoff + +| Downstream process/artifact | SRS handoff content | +|---|---| +| SWE.2 / SAD | Software components, interfaces, static and dynamic architecture constraints, NFR allocation, security and platform boundaries | +| SWE.3 / SDD | DTOs, API contracts, state machines, reducers, storage schema, audio pipeline module design, protocol adapter interfaces, error models | +| SWE.4 | Unit verification needs for reducers, audio processors, protocol mappers, storage logic, redaction, validation, and utility functions | +| SWE.5 | Software integration verification for Flutter-Bridge-Core, protocol-state, audio-platform, storage-secure-store, diagnostics-export, and packaging flows | +| SWE.6 | Integrated software verification against this SRS including MVP acceptance and platform compatibility | + +## 9. SysDes to SRS Coverage Matrix + +Coverage summary: 110 / 110 SysDes design items are covered by one or more SRS requirements. + +Software-impacting SysDes items: 95 / 110. All software-impacting SysDes items are represented in the SRS coverage below. Non-software design items are covered as software assumptions, external-interface constraints, verification hooks, or process controls when they affect software work. + +Missing SysDes coverage: None. + +| SysDes ID | SysDes allocation | Covered by SRS | +|---|---|---| +| SysDes-001 | System Engineering | SRS-001 | +| SysDes-002 | System Engineering | SRS-001, SRS-008 | +| SysDes-003 | System Engineering | SRS-001, SRS-007 | +| SysDes-004 | System Engineering, Verification | SRS-002 | +| SysDes-005 | System Engineering | SRS-002, SRS-003, SRS-121 | +| SysDes-006 | Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-002, SRS-003, SRS-004 | +| SysDes-007 | System Engineering | SRS-002 | +| SysDes-008 | System Engineering, Verification | SRS-002, SRS-005 | +| SysDes-009 | System Engineering, Verification | SRS-002, SRS-005 | +| SysDes-010 | Software: Flutter UI, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011 | +| SysDes-011 | Software: Protocol Adapter | SRS-044, SRS-053, SRS-134 | +| SysDes-012 | Software: Flutter UI, Software: Rust Core | SRS-013 | +| SysDes-013 | Software: Audio Subsystem | SRS-062, SRS-064, SRS-065, SRS-066, SRS-067, SRS-069, SRS-135 | +| SysDes-014 | Software: Flutter UI, Software: Audio Subsystem | SRS-012, SRS-135 | +| SysDes-015 | Software: Diagnostics, Verification | SRS-093, SRS-095, SRS-137 | +| SysDes-016 | System Engineering | SRS-009 | +| SysDes-017 | Software: Protocol Adapter, Software: Audio Subsystem, Deployment / Operations | SRS-004, SRS-015, SRS-052, SRS-083, SRS-095, SRS-123, SRS-128, SRS-134 | +| SysDes-018 | External Server, Software: Audio Subsystem, Deployment / Operations | SRS-006 | +| SysDes-019 | User / Operator, Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-096, SRS-132 | +| SysDes-020 | Hardware, Software: Audio Subsystem | SRS-006, SRS-062, SRS-106, SRS-129, SRS-135 | +| SysDes-021 | Platform, Software: Audio Subsystem, Platform Secure Storage | SRS-006, SRS-027, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-137, SRS-138 | +| SysDes-022 | Network | SRS-006, SRS-130 | +| SysDes-023 | External Server, Software: Audio Subsystem, Platform | SRS-006, SRS-010, SRS-131, SRS-132 | +| SysDes-024 | Software, Platform | SRS-008, SRS-016 | +| SysDes-025 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-017, SRS-018, SRS-019, SRS-020, SRS-021, SRS-022, SRS-024, SRS-025, SRS-026, SRS-027, SRS-028, SRS-080, SRS-081, SRS-096, SRS-108, SRS-109 | +| SysDes-026 | Software: Flutter State, Software: Rust Core, Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030 | +| SysDes-027 | Software: Bridge, Software: Rust Core | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-103 | +| SysDes-028 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-036, SRS-037, SRS-038, SRS-039, SRS-136 | +| SysDes-029 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-134 | +| SysDes-030 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-036, SRS-043, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060, SRS-061, SRS-124, SRS-136 | +| SysDes-031 | Software: Audio Subsystem | SRS-025, SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081, SRS-125, SRS-135, SRS-136 | +| SysDes-032 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-013, SRS-014, SRS-027, SRS-070, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-135, SRS-138 | +| SysDes-033 | Software: Audio Subsystem, Software: Storage | SRS-026, SRS-068, SRS-075, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-136 | +| SysDes-034 | Platform Secure Storage | SRS-006, SRS-090, SRS-091, SRS-092, SRS-126, SRS-137 | +| SysDes-035 | Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-028, SRS-052, SRS-061, SRS-083, SRS-093, SRS-095, SRS-096, SRS-097, SRS-098, SRS-099, SRS-100, SRS-122, SRS-123, SRS-124, SRS-125, SRS-126, SRS-128, SRS-136, SRS-137 | +| SysDes-036 | Software: Storage, Deployment / Operations | SRS-006, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-127 | +| SysDes-037 | System Engineering, Verification | SRS-139 | +| SysDes-038 | Software: Flutter UI, Software: Flutter State, Software: Bridge, Software: Rust Core | SRS-003, SRS-011, SRS-016, SRS-031, SRS-032 | +| SysDes-039 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-003, SRS-011, SRS-039 | +| SysDes-040 | Software: Flutter UI, Software: Flutter State, Software: Protocol Adapter | SRS-012, SRS-029, SRS-033, SRS-044 | +| SysDes-041 | Software: Flutter UI, Software: Rust Core, Software: Audio Subsystem | SRS-011, SRS-013, SRS-016 | +| SysDes-042 | System Engineering | SRS-031, SRS-032, SRS-033, SRS-034, SRS-035, SRS-038, SRS-039, SRS-103 | +| SysDes-043 | External Server, Deployment / Operations, System Engineering, Verification | SRS-044, SRS-045, SRS-046, SRS-047, SRS-048, SRS-049, SRS-050, SRS-051, SRS-053, SRS-131, SRS-134 | +| SysDes-044 | Software: Flutter UI, Software: Rust Core | SRS-036, SRS-037, SRS-054, SRS-057 | +| SysDes-045 | Hardware, Platform, Network | SRS-031, SRS-034, SRS-048, SRS-094, SRS-103, SRS-129, SRS-130 | +| SysDes-046 | Platform, Platform Secure Storage, Software: Diagnostics, Verification, System Engineering | SRS-020, SRS-032, SRS-035 | +| SysDes-047 | System Engineering | SRS-030, SRS-032, SRS-054, SRS-055, SRS-056, SRS-057, SRS-058, SRS-059, SRS-060 | +| SysDes-048 | Software: Flutter UI, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification | SRS-090, SRS-091, SRS-092 | +| SysDes-049 | Software: Bridge, Software: Protocol Adapter | SRS-031, SRS-084, SRS-085, SRS-086, SRS-087, SRS-088, SRS-089 | +| SysDes-050 | Software: Rust Core, Software: State Sync, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-014, SRS-027, SRS-082, SRS-090, SRS-104, SRS-105, SRS-106, SRS-107, SRS-108, SRS-109, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-133 | +| SysDes-051 | Software: Protocol Adapter | SRS-036, SRS-037 | +| SysDes-052 | External Server, Software: Protocol Adapter | SRS-029, SRS-033, SRS-039, SRS-047 | +| SysDes-053 | Software: Audio Subsystem | SRS-029, SRS-044 | +| SysDes-054 | Software: Audio Subsystem | SRS-029 | +| SysDes-055 | Software: Storage, Platform Secure Storage | SRS-017, SRS-018, SRS-023, SRS-024, SRS-031, SRS-038, SRS-132 | +| SysDes-056 | Software: Storage | SRS-025, SRS-026, SRS-028, SRS-031, SRS-032, SRS-068, SRS-086, SRS-095, SRS-103, SRS-106 | +| SysDes-057 | Software: Diagnostics, Verification | SRS-029, SRS-030, SRS-033, SRS-037, SRS-044, SRS-047 | +| SysDes-058 | Software: Diagnostics, Verification | SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-070, SRS-071, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-104, SRS-105 | +| SysDes-059 | Software: Audio Subsystem, Platform | SRS-017, SRS-018 | +| SysDes-060 | Software: Rust Core | SRS-019, SRS-036, SRS-037, SRS-038, SRS-040 | +| SysDes-061 | Software: Protocol Adapter, Software: Audio Subsystem, Platform | SRS-019, SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-046, SRS-054, SRS-055, SRS-056 | +| SysDes-062 | Software: Audio Subsystem, Platform | SRS-140 | +| SysDes-063 | Software: State Sync | SRS-025, SRS-062, SRS-077, SRS-078, SRS-079, SRS-080, SRS-081 | +| SysDes-064 | Software: Diagnostics, Verification | SRS-019, SRS-036, SRS-040, SRS-041, SRS-042, SRS-130 | +| SysDes-065 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-018, SRS-038, SRS-045, SRS-094, SRS-132 | +| SysDes-066 | Software: Rust Core, Software: Protocol Adapter | SRS-019, SRS-036, SRS-037, SRS-040, SRS-042, SRS-059 | +| SysDes-067 | Software: State Sync | SRS-020, SRS-021, SRS-022, SRS-030, SRS-032, SRS-036, SRS-043, SRS-046, SRS-054, SRS-055 | +| SysDes-068 | Software: State Sync | SRS-020, SRS-021, SRS-030, SRS-032, SRS-036, SRS-047, SRS-054, SRS-056, SRS-057, SRS-058, SRS-060 | +| SysDes-069 | Software: Rust Core, Software: Protocol Adapter | SRS-023, SRS-038, SRS-049 | +| SysDes-070 | Software: Rust Core, Software: Protocol Adapter | SRS-024, SRS-038, SRS-050 | +| SysDes-071 | Software: Protocol Adapter, Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-077, SRS-079, SRS-080, SRS-104 | +| SysDes-072 | Software: Audio Subsystem | SRS-012, SRS-025, SRS-051, SRS-062, SRS-072, SRS-073, SRS-074, SRS-075, SRS-076, SRS-078, SRS-081, SRS-088, SRS-105 | +| SysDes-073 | Software | SRS-038, SRS-041 | +| SysDes-074 | Software: State Sync | SRS-038, SRS-040, SRS-041, SRS-042, SRS-043, SRS-059, SRS-100, SRS-130 | +| SysDes-075 | Software: Audio Subsystem, Platform | SRS-026, SRS-082, SRS-099, SRS-106, SRS-107, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-115, SRS-135, SRS-138 | +| SysDes-076 | Software: Storage, Platform Secure Storage, Software: Diagnostics, Verification | SRS-028, SRS-038, SRS-090, SRS-091, SRS-092, SRS-093, SRS-095, SRS-096, SRS-137 | +| SysDes-077 | Software: Rust Core, Software: Protocol Adapter, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-039 | +| SysDes-078 | Software: Protocol Adapter | SRS-044, SRS-047, SRS-053, SRS-134 | +| SysDes-079 | Software: State Sync, System Engineering, Verification | SRS-043, SRS-058, SRS-059, SRS-061, SRS-097, SRS-098 | +| SysDes-080 | Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations | SRS-006, SRS-014, SRS-090, SRS-110, SRS-111, SRS-112, SRS-113, SRS-114, SRS-133, SRS-138 | +| SysDes-081 | Software: Audio Subsystem | SRS-026, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-068, SRS-069, SRS-070, SRS-086, SRS-135 | +| SysDes-082 | Platform | SRS-006, SRS-010, SRS-131 | +| SysDes-083 | Software: Audio Subsystem | SRS-009, SRS-010 | +| SysDes-084 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Software: Diagnostics, Verification, Deployment / Operations | SRS-006, SRS-115, SRS-122, SRS-134, SRS-138 | +| SysDes-085 | Software: Flutter UI, Software: Bridge, Software: Rust Core | SRS-035 | +| SysDes-086 | Hardware, Network, Software: Audio Subsystem, Platform | SRS-006, SRS-026, SRS-062, SRS-066, SRS-069, SRS-073, SRS-082, SRS-099, SRS-107, SRS-112, SRS-113, SRS-129, SRS-135 | +| SysDes-087 | Software: Rust Core, Software: Audio Subsystem, Software: Diagnostics, Verification | SRS-095, SRS-136 | +| SysDes-088 | Software: Rust Core, Software: Protocol Adapter, Software: State Sync, Software: Audio Subsystem | SRS-034, SRS-041, SRS-042, SRS-043, SRS-048, SRS-059, SRS-060, SRS-100, SRS-130 | +| SysDes-089 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-034, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-103, SRS-126, SRS-129, SRS-137 | +| SysDes-090 | Platform, Software: Diagnostics, Verification | SRS-006, SRS-027, SRS-028, SRS-093, SRS-095, SRS-096, SRS-101, SRS-102, SRS-108, SRS-109, SRS-115, SRS-122, SRS-133, SRS-137 | +| SysDes-091 | Software: Storage, Deployment / Operations, System Engineering, Verification | SRS-004, SRS-006, SRS-089, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-138 | +| SysDes-092 | System Engineering | SRS-002, SRS-005 | +| SysDes-093 | System Engineering | SRS-002, SRS-005 | +| SysDes-094 | System Engineering | SRS-002, SRS-005 | +| SysDes-095 | System Engineering | SRS-002, SRS-005 | +| SysDes-096 | System Engineering | SRS-002, SRS-005 | +| SysDes-097 | System Engineering, Verification | SRS-002, SRS-005 | +| SysDes-098 | Software: Rust Core, Software: Audio Subsystem, Deployment / Operations, System Engineering, Verification | SRS-007, SRS-095 | +| SysDes-099 | System Engineering, Verification | SRS-007 | +| SysDes-100 | System Engineering | SRS-007 | +| SysDes-101 | Software: Protocol Adapter, Software: Audio Subsystem, Platform, Platform Secure Storage, Deployment / Operations, System Engineering, Verification | SRS-006 | +| SysDes-102 | External Server, Software: Protocol Adapter | SRS-004, SRS-015, SRS-045, SRS-046, SRS-049, SRS-050, SRS-051, SRS-052, SRS-097, SRS-100, SRS-123, SRS-128, SRS-131, SRS-134 | +| SysDes-103 | Software: State Sync | SRS-004, SRS-015, SRS-058, SRS-059, SRS-060, SRS-061, SRS-097, SRS-098, SRS-124, SRS-128 | +| SysDes-104 | Software: Audio Subsystem | SRS-004, SRS-015, SRS-051, SRS-062, SRS-063, SRS-064, SRS-065, SRS-066, SRS-067, SRS-071, SRS-072, SRS-073, SRS-076, SRS-083, SRS-099, SRS-125, SRS-128, SRS-135 | +| SysDes-105 | Platform Secure Storage, Software: Diagnostics, Verification | SRS-004, SRS-015, SRS-028, SRS-090, SRS-091, SRS-092, SRS-093, SRS-094, SRS-095, SRS-096, SRS-101, SRS-102, SRS-126, SRS-128, SRS-137 | +| SysDes-106 | Software: Storage, Deployment / Operations | SRS-004, SRS-015, SRS-116, SRS-117, SRS-118, SRS-119, SRS-120, SRS-121, SRS-122, SRS-127, SRS-128, SRS-138 | +| SysDes-107 | Verification | SRS-004, SRS-015, SRS-128 | +| SysDes-108 | System Engineering, Software Requirements Engineering, Verification | SRS-004, SRS-005, SRS-141, SRS-143 | +| SysDes-109 | System Engineering, Software Requirements Engineering | SRS-004, SRS-005, SRS-141, SRS-143 | +| SysDes-110 | System Engineering, Software Requirements Engineering, Change Control, Verification | SRS-004, SRS-005, SRS-142, SRS-143 | + +## 10. SRS Requirement Register + +| SRS ID | Type | Stage | Allocated to | Verification method | Source SysDes | +|---|---|---|---|---|---| +| SRS-001 | Process / SWE.1 | P0 / MVP | Software Requirements Engineering | Review | SysDes-001 through SysDes-003 | +| SRS-002 | Process / Requirement Attribute | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-004 through SysDes-009, SysDes-092 through SysDes-097 | +| SRS-003 | Process / Structuring | P0 / MVP | Software Requirements Engineering | Review | SysDes-005, SysDes-006, SysDes-010, SysDes-038, SysDes-039 | +| SRS-004 | Process / Prioritization | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-006, SysDes-017, SysDes-091, SysDes-102 through SysDes-110 | +| SRS-005 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Inspection | SysDes-008, SysDes-009, SysDes-092 through SysDes-097, SysDes-108 through SysDes-110 | +| SRS-006 | Process / Operating Environment Analysis | P0 / MVP | Software Requirements Engineering | Review | SysDes-018 through SysDes-023, SysDes-032, SysDes-034, SysDes-036, SysDes-080, SysDes-082, SysDes-084, SysDes-086, SysDes-090, SysDes-091, SysDes-101 | +| SRS-007 | Process / Communication | P0 / MVP | Software Requirements Engineering | Review | SysDes-003, SysDes-098 through SysDes-100 | +| SRS-008 | Constraint | P0 / MVP | Application Container | Review | SysDes-002, SysDes-024 | +| SRS-009 | Constraint | P0 / MVP | Application Container, Rust Core | Review, System Test | SysDes-016, SysDes-083 | +| SRS-010 | Constraint | P0 / MVP | Application Container, Protocol Adapter | Inspection | SysDes-023, SysDes-082, SysDes-083 | +| SRS-011 | Architecture Constraint | P0 / MVP | All Software Components | Inspection | SysDes-010, SysDes-038, SysDes-039, SysDes-041 | +| SRS-012 | Architecture Constraint | P0 / MVP | Flutter UI, Audio Subsystem | Inspection, Performance Test | SysDes-014, SysDes-040, SysDes-071, SysDes-072 | +| SRS-013 | Platform Requirement | P0 / MVP | Flutter UI, Rust Core, Platform Adapters | Build Test | SysDes-012, SysDes-032, SysDes-041 | +| SRS-014 | Architecture Constraint | P0 / MVP | Platform Adapters | Inspection, Integration Test | SysDes-032, SysDes-050, SysDes-080 | +| SRS-015 | Verification Hook | P0 / MVP | Protocol Adapter, State Sync, Audio, Diagnostics, Platform Adapters | Inspection, Demo | SysDes-017, SysDes-102 through SysDes-107 | +| SRS-016 | Functional | P0 / MVP | Application Container | Integration Test | SysDes-024, SysDes-038, SysDes-041 | +| SRS-017 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059 | +| SRS-018 | Functional | P0 / MVP | Flutter UI | UI Test | SysDes-025, SysDes-055, SysDes-059, SysDes-065 | +| SRS-019 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-060, SysDes-061, SysDes-064, SysDes-066 | +| SRS-020 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-046, SysDes-061, SysDes-067, SysDes-068 | +| SRS-021 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test, System Test | SysDes-025, SysDes-026, SysDes-030, SysDes-061, SysDes-067, SysDes-068 | +| SRS-022 | Functional | P0 / MVP | Flutter UI, Flutter State | UI Test | SysDes-025, SysDes-026, SysDes-030, SysDes-067 | +| SRS-023 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | System Test | SysDes-055, SysDes-069 | +| SRS-024 | Functional | P0 / MVP | Flutter UI, Bridge, Rust Core | UI Test, System Test | SysDes-025, SysDes-055, SysDes-070 | +| SRS-025 | Functional | P0 / MVP | Flutter UI, Audio Subsystem | UI Test, System Test | SysDes-025, SysDes-031, SysDes-056, SysDes-063, SysDes-071, SysDes-072 | +| SRS-026 | Functional | P0 / MVP | Flutter UI, Audio Subsystem, Storage | UI Test | SysDes-025, SysDes-031, SysDes-033, SysDes-056, SysDes-075, SysDes-081, SysDes-086 | +| SRS-027 | Functional / Privacy | P0 / MVP | Flutter UI, Platform Adapters | UI Test, Privacy Review | SysDes-019, SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 | +| SRS-028 | Functional / Diagnostics | P1 / Beta | Flutter UI, Diagnostics | UI Test, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-056, SysDes-076, SysDes-090, SysDes-105 | +| SRS-029 | Constraint | P0 / MVP | Flutter UI, Flutter State | Inspection | SysDes-040, SysDes-052 through SysDes-054, SysDes-057 | +| SRS-030 | Functional | P0 / MVP | Flutter State | Inspection, UI Test | SysDes-026, SysDes-030, SysDes-047, SysDes-057, SysDes-061, SysDes-067, SysDes-068 | +| SRS-031 | Interface | P0 / MVP | Bridge Layer | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-045, SysDes-049, SysDes-055, SysDes-056 | +| SRS-032 | Interface | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-038, SysDes-042, SysDes-046, SysDes-047, SysDes-056, SysDes-061, SysDes-067, SysDes-068 | +| SRS-033 | Interface / Safety | P0 / MVP | Bridge Layer | Inspection, Integration Test | SysDes-027, SysDes-040, SysDes-042, SysDes-052, SysDes-057 | +| SRS-034 | Interface / Error Handling | P0 / MVP | Bridge Layer, Rust Core | Integration Test | SysDes-027, SysDes-042, SysDes-045, SysDes-088, SysDes-089 | +| SRS-035 | Non-functional | P0 / MVP | Bridge Layer, Rust Core | Performance Test | SysDes-027, SysDes-042, SysDes-046, SysDes-085 | +| SRS-036 | Functional | P0 / MVP | Rust Core | Unit Test, Integration Test | SysDes-028, SysDes-030, SysDes-044, SysDes-051, SysDes-060, SysDes-061, SysDes-064, SysDes-066 through SysDes-068 | +| SRS-037 | Functional | P0 / MVP | Rust Core | Inspection, Unit Test | SysDes-028, SysDes-044, SysDes-051, SysDes-057, SysDes-060, SysDes-066 | +| SRS-038 | Functional | P0 / MVP | Rust Core, Bridge | Integration Test | SysDes-028, SysDes-042, SysDes-055, SysDes-060, SysDes-065, SysDes-069, SysDes-070, SysDes-073, SysDes-074, SysDes-076 | +| SRS-039 | Functional / Architecture | P0 / MVP | Rust Core | Inspection | SysDes-028, SysDes-039, SysDes-042, SysDes-052, SysDes-077 | +| SRS-040 | Functional | P0 / MVP | Rust Core, State Sync | Unit Test, System Test | SysDes-060, SysDes-064, SysDes-066, SysDes-074 | +| SRS-041 | Functional | P0 / MVP | Rust Core | System Test | SysDes-064, SysDes-073, SysDes-074, SysDes-088 | +| SRS-042 | Functional / Reliability | P0 / MVP | Rust Core, Protocol Adapter, State Sync | System Test | SysDes-064, SysDes-066, SysDes-074, SysDes-088 | +| SRS-043 | Functional / Reliability | P0 / MVP | Rust Core, State Sync | System Test, Event Replay Test | SysDes-030, SysDes-067, SysDes-074, SysDes-079, SysDes-088 | +| SRS-044 | Architecture Constraint | P0 / MVP | Protocol Adapter | Inspection | SysDes-011, SysDes-029, SysDes-040, SysDes-043, SysDes-053, SysDes-057, SysDes-078 | +| SRS-045 | Functional | P0 / MVP | Protocol Adapter, Rust Core | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-065, SysDes-102 | +| SRS-046 | Functional | P0 / MVP | Protocol Adapter, State Sync | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-061, SysDes-067, SysDes-102 | +| SRS-047 | Functional | P0 / MVP | Protocol Adapter, State Sync | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-052, SysDes-057, SysDes-068, SysDes-078 | +| SRS-048 | Functional / Error Handling | P0 / MVP | Protocol Adapter, Rust Core | Unit Test, Integration Test | SysDes-029, SysDes-043, SysDes-045, SysDes-088 | +| SRS-049 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-069, SysDes-102 | +| SRS-050 | Functional | P0 / MVP | Protocol Adapter | Protocol Integration Test | SysDes-029, SysDes-043, SysDes-070, SysDes-102 | +| SRS-051 | Functional | P0 / MVP | Protocol Adapter, Audio Subsystem | Protocol Integration Test, Audio Test | SysDes-029, SysDes-043, SysDes-058, SysDes-071, SysDes-072, SysDes-102, SysDes-104 | +| SRS-052 | Verification Hook | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 | +| SRS-053 | Maintainability | P1 / Beta | Protocol Adapter, Bridge | Architecture Review | SysDes-011, SysDes-029, SysDes-043, SysDes-078 | +| SRS-054 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-044, SysDes-047, SysDes-061, SysDes-067, SysDes-068 | +| SRS-055 | Functional | P0 / MVP | State Sync | Unit Test, Integration Test | SysDes-030, SysDes-047, SysDes-061, SysDes-067 | +| SRS-056 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-061, SysDes-068 | +| SRS-057 | Functional | P0 / MVP | State Sync, Rust Core | Unit Test, Integration Test | SysDes-030, SysDes-044, SysDes-047, SysDes-068 | +| SRS-058 | Functional | P0 / MVP | State Sync | Unit Test | SysDes-030, SysDes-047, SysDes-068, SysDes-079, SysDes-103 | +| SRS-059 | Functional / Reliability | P0 / MVP | State Sync | Event Replay Test, System Test | SysDes-030, SysDes-047, SysDes-066, SysDes-074, SysDes-079, SysDes-088, SysDes-103 | +| SRS-060 | Reliability | P0 / MVP | State Sync, Rust Core | Unit Test, Fuzz/Negative Test | SysDes-030, SysDes-047, SysDes-068, SysDes-088, SysDes-103 | +| SRS-061 | Verification Hook | P1 / Beta | State Sync, Diagnostics | Demo | SysDes-030, SysDes-035, SysDes-079, SysDes-103 | +| SRS-062 | Functional | P0 / MVP | Audio Subsystem | Audio Integration Test | SysDes-013, SysDes-020, SysDes-031, SysDes-058, SysDes-063, SysDes-071, SysDes-072, SysDes-081, SysDes-086, SysDes-104 | +| SRS-063 | Functional | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-064 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-065 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-066 | Functional / Audio Processing | P0 / MVP | Audio Subsystem, Platform Adapters | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-086, SysDes-104 | +| SRS-067 | Functional / Audio Processing | P0 / MVP | Audio Subsystem | Audio Processing Test | SysDes-013, SysDes-031, SysDes-058, SysDes-071, SysDes-081, SysDes-104 | +| SRS-068 | Functional / Settings | P0 / MVP | Audio Subsystem, Flutter UI, Storage | UI Test, Unit Test | SysDes-031, SysDes-033, SysDes-056, SysDes-081 | +| SRS-069 | Non-functional / Audio | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-031, SysDes-081, SysDes-086 | +| SRS-070 | Architecture / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Inspection | SysDes-031, SysDes-032, SysDes-058, SysDes-081 | +| SRS-071 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-071, SysDes-104 | +| SRS-072 | Functional / Audio Codec | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 | +| SRS-073 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-086, SysDes-104 | +| SRS-074 | Functional / Audio Playback | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-031, SysDes-058, SysDes-072 | +| SRS-075 | Functional / Audio Playback | P1 / Beta | Audio Subsystem, Flutter UI, Storage | Audio Test, UI Test | SysDes-031, SysDes-033, SysDes-058, SysDes-072 | +| SRS-076 | Functional / Audio Playback | P0 / MVP | Audio Subsystem | Audio Test | SysDes-031, SysDes-058, SysDes-072, SysDes-104 | +| SRS-077 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 | +| SRS-078 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Rust Core, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-072 | +| SRS-079 | Functional / Voice Control | P0 / MVP | Audio Subsystem, Flutter UI | System Test | SysDes-031, SysDes-063, SysDes-071 | +| SRS-080 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-071 | +| SRS-081 | Functional / Voice Metering | P0 / MVP | Audio Subsystem, State Sync, Flutter UI | Audio Test, UI Test | SysDes-025, SysDes-031, SysDes-063, SysDes-072 | +| SRS-082 | Reliability / Audio | P1 / Beta | Audio Subsystem, Platform Adapters | Platform Integration Test | SysDes-032, SysDes-050, SysDes-075, SysDes-086 | +| SRS-083 | Verification Hook | P1 / Beta | Audio Subsystem, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-104 | +| SRS-084 | Functional / Storage | P0 / MVP | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 | +| SRS-085 | Functional / Storage | P1 / Beta | Storage | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 | +| SRS-086 | Functional / Storage | P0 / MVP | Storage, Audio Subsystem | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049, SysDes-056, SysDes-081 | +| SRS-087 | Functional / Storage | P1 / Beta | Storage, Flutter UI | Unit Test, Integration Test | SysDes-033, SysDes-036, SysDes-049 | +| SRS-088 | Functional / Storage | P1 / Beta | Storage, Audio Subsystem | Unit Test | SysDes-033, SysDes-036, SysDes-049, SysDes-072 | +| SRS-089 | Architecture / Storage | P0 / MVP | Storage | Inspection | SysDes-033, SysDes-036, SysDes-049, SysDes-091 | +| SRS-090 | Interface / Security | P0 / MVP | Storage, Platform Adapters | Inspection, Security Audit | SysDes-021, SysDes-032, SysDes-034, SysDes-048, SysDes-050, SysDes-076, SysDes-080, SysDes-089, SysDes-105 | +| SRS-091 | Security | P0 / MVP | Storage, Platform Secure Storage | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 | +| SRS-092 | Security | P0 / MVP | Storage, Platform Secure Storage, Diagnostics | Security Audit | SysDes-034, SysDes-048, SysDes-076, SysDes-089, SysDes-105 | +| SRS-093 | Security / Diagnostics | P0 / MVP | Diagnostics, Storage | Security Audit | SysDes-015, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 | +| SRS-094 | Security | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | Unit Test, Security Test | SysDes-045, SysDes-065, SysDes-089, SysDes-105 | +| SRS-095 | Diagnostics | P0 / MVP | Diagnostics | Inspection, Demo | SysDes-015, SysDes-017, SysDes-035, SysDes-056, SysDes-076, SysDes-087, SysDes-090, SysDes-098, SysDes-105 | +| SRS-096 | Diagnostics | P1 / Beta | Diagnostics, Flutter UI | Demo, Security Audit | SysDes-019, SysDes-025, SysDes-035, SysDes-076, SysDes-090, SysDes-105 | +| SRS-097 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Protocol Adapter, State Sync | Demo | SysDes-035, SysDes-079, SysDes-102, SysDes-103 | +| SRS-098 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, State Sync | Demo | SysDes-035, SysDes-079, SysDes-103 | +| SRS-099 | Diagnostics / Verification Hook | P1 / Beta | Diagnostics, Audio Subsystem, Platform Adapters | Demo | SysDes-035, SysDes-075, SysDes-086, SysDes-104 | +| SRS-100 | Diagnostics / Reliability | P1 / Beta | Diagnostics, Rust Core, Protocol Adapter | Demo | SysDes-035, SysDes-074, SysDes-088, SysDes-102 | +| SRS-101 | Privacy | P0 / MVP | All Software Components | Privacy Review | SysDes-090, SysDes-105 | +| SRS-102 | Privacy / Constraint | P0 / MVP | Diagnostics | Security Audit | SysDes-090, SysDes-105 | +| SRS-103 | Security / Error Handling | P0 / MVP | Flutter UI, Rust Core, Bridge, Diagnostics | UI Test, Security Review | SysDes-027, SysDes-042, SysDes-045, SysDes-056, SysDes-089 | +| SRS-104 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-071 | +| SRS-105 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-058, SysDes-072 | +| SRS-106 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem, Flutter UI | Platform Integration Test | SysDes-020, SysDes-021, SysDes-032, SysDes-050, SysDes-056, SysDes-075 | +| SRS-107 | Interface / Platform | P0 / MVP | Platform Adapters, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-086 | +| SRS-108 | Interface / Platform | P0 / MVP | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 | +| SRS-109 | Interface / Platform | P1 / Beta | Platform Adapters, Flutter UI | Platform Integration Test | SysDes-021, SysDes-025, SysDes-032, SysDes-050, SysDes-090 | +| SRS-110 | Platform / iOS | P0 / MVP | Platform Adapters, Audio Subsystem | iOS Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 | +| SRS-111 | Platform / Android | P0 / MVP | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 | +| SRS-112 | Platform / Android | P1 / Beta | Platform Adapters, Audio Subsystem | Android Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 | +| SRS-113 | Platform / Desktop | P1 / Beta | Platform Adapters, Audio Subsystem | Desktop Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080, SysDes-086 | +| SRS-114 | Interface / Platform | P1 / Beta | Platform Adapters, Rust Core, Audio Subsystem | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-075, SysDes-080 | +| SRS-115 | Platform / Diagnostics | P1 / Beta | Platform Adapters, Diagnostics, Flutter UI | Review, Demo | SysDes-050, SysDes-075, SysDes-084, SysDes-090 | +| SRS-116 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-117 | Packaging | P2 / Production | Application Container, Deployment Scripts | Build/Release Audit | SysDes-036, SysDes-091, SysDes-106 | +| SRS-118 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-119 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-120 | Packaging | P1 / Beta | Application Container, Deployment Scripts | Build Test | SysDes-036, SysDes-091, SysDes-106 | +| SRS-121 | Legal / Product Constraint | P0 / MVP | Application Container, Flutter UI, Deployment Scripts | Legal Review, Inspection | SysDes-005, SysDes-036, SysDes-091, SysDes-106 | +| SRS-122 | Security / Release | P1 / Beta | Application Container, Diagnostics, Deployment Scripts | Inspection, Security Review | SysDes-035, SysDes-084, SysDes-090, SysDes-091, SysDes-106 | +| SRS-123 | Verification Support | P0 / MVP | Protocol Adapter, Diagnostics | Demo | SysDes-017, SysDes-035, SysDes-102 | +| SRS-124 | Verification Support | P0 / MVP | State Sync, Diagnostics | Unit Test, Demo | SysDes-030, SysDes-035, SysDes-103 | +| SRS-125 | Verification Support | P0 / MVP | Audio Subsystem, Diagnostics | Audio Test, Demo | SysDes-031, SysDes-035, SysDes-104 | +| SRS-126 | Verification Support | P0 / MVP | Storage, Diagnostics, Platform Adapters | Security Audit | SysDes-034, SysDes-035, SysDes-089, SysDes-105 | +| SRS-127 | Verification Support | P1 / Beta | Deployment Scripts, Application Container | Build Test, Release Audit | SysDes-036, SysDes-091, SysDes-106 | +| SRS-128 | Verification Support | P0 / MVP | All Software Components | System Test, Demo | SysDes-017, SysDes-035, SysDes-102 through SysDes-107 | +| SRS-129 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Audio Subsystem, Platform Adapters | System Test | SysDes-020, SysDes-045, SysDes-086, SysDes-089 | +| SRS-130 | Operating Environment Constraint | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter | System Test | SysDes-022, SysDes-045, SysDes-064, SysDes-074, SysDes-088 | +| SRS-131 | Operating Environment Constraint | P0 / MVP | Protocol Adapter, Rust Core, Flutter UI | System Test | SysDes-023, SysDes-043, SysDes-082, SysDes-102 | +| SRS-132 | Functional / Environment | P0 / MVP | Flutter UI, Rust Core, Protocol Adapter, Storage | UI Test, System Test | SysDes-019, SysDes-023, SysDes-055, SysDes-065 | +| SRS-133 | Operating Environment Interface | P0 / MVP | Platform Adapters, Rust Core, Flutter UI | Platform Integration Test | SysDes-021, SysDes-032, SysDes-050, SysDes-080, SysDes-090 | +| SRS-134 | Analysis Requirement | P0 / MVP | Protocol Adapter, Software Requirements Engineering | Review, Protocol Probe | SysDes-011, SysDes-017, SysDes-029, SysDes-043, SysDes-078, SysDes-084, SysDes-102 | +| SRS-135 | Analysis Requirement | P0 / MVP | Audio Subsystem, Platform Adapters | Review, Audio Test | SysDes-013, SysDes-014, SysDes-020, SysDes-021, SysDes-031, SysDes-032, SysDes-075, SysDes-081, SysDes-086, SysDes-104 | +| SRS-136 | Analysis Requirement | P0 / MVP | Rust Core, State Sync, Audio Subsystem, Diagnostics, Storage | Review, Performance Test | SysDes-028, SysDes-030, SysDes-031, SysDes-033, SysDes-035, SysDes-087 | +| SRS-137 | Analysis Requirement | P0 / MVP | Storage, Diagnostics, Platform Adapters, Flutter UI | Security Review, Privacy Review | SysDes-015, SysDes-021, SysDes-034, SysDes-035, SysDes-076, SysDes-089, SysDes-090, SysDes-105 | +| SRS-138 | Analysis Requirement | P1 / Beta | Platform Adapters, Audio Subsystem, Deployment Scripts | Review, Platform Test | SysDes-021, SysDes-032, SysDes-075, SysDes-080, SysDes-084, SysDes-091, SysDes-106 | +| SRS-139 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-037 | +| SRS-140 | Traceability / Coverage | P0 / MVP | Software Requirements Engineering | Review | SysDes-062 | +| SRS-141 | Process / Traceability | P0 / MVP | Software Requirements Engineering | Review, Inspection | SysDes-108, SysDes-109 | +| SRS-142 | Process / Change Control | P0 / MVP | Software Requirements Engineering, Change Control | Review, Inspection | SysDes-110 | +| SRS-143 | Process / Coverage | P0 / MVP | Software Requirements Engineering, Verification | Review, Inspection | SysDes-108, SysDes-109, SysDes-110 | + +## 11. Revision History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-13 | Initial ASPICE SWE.1-style SRS derived from early SysDes baseline | +| 0.2.0 | 2026-05-13 | Added inherited upstream coverage via SysDes to show complete chained requirement traceability | +| 0.3.0 | 2026-05-13 | Removed all direct individual SRS-to-upstream-system-requirement links; SRS now traces only to SysDes as the system architectural allocation baseline | +| 0.4.0 | 2026-05-13 | Updated source baseline to SysDes v0.5 and added SRS requirements for SysDes-108 through SysDes-110 derivation and change-control rules | + + + + +--- + +## 13. UI/UX, Material 3, Platform, and Internationalization Software Requirements + +This section extends the ASPICE SWE.1 Software Requirements Specification. The source baseline for these requirements is **SysDes only**. This SRS does not link directly to system-requirement IDs. + +**SRS-144**: The software shall initialize the Flutter client theme using Material 3 as the baseline UI system. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Design System +- Source SysDes: SysDes-111, SysDes-112 +- Verification method: Review, Widget Test + +**SRS-145**: The software shall provide a Chanora Design System layer above Material 3 for product-specific semantic states. + +- Status: Baseline +- Type: Software Architecture Constraint +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-111, SysDes-112, SysDes-113 +- Verification method: Inspection, Widget Test + +**SRS-146**: The software shall define semantic tokens for connection states. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-114 +- Verification method: Unit Test + +**SRS-147**: The software shall define semantic tokens for voice states including speaking, muted, deafened, and push-to-talk active states. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-114 +- Verification method: Unit Test + +**SRS-148**: The software shall define semantic tokens for latency, packet loss, diagnostics, and error states. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-114 +- Verification method: Unit Test + +**SRS-149**: The software shall expose design tokens through `ThemeData`, `ColorScheme`, `TextTheme`, component themes, `ThemeExtension`, or equivalent Flutter theming mechanisms. + +- Status: Baseline +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Design System +- Source SysDes: SysDes-113, SysDes-114 +- Verification method: Inspection, Widget Test + +**SRS-150**: Feature screens shall not hardcode product semantic colors, spacing, shape, density, or motion values. + +- Status: Baseline +- Type: Software Constraint +- Stage: P0 / MVP +- Allocated to: Flutter Feature Screens +- Source SysDes: SysDes-112, SysDes-113, SysDes-114 +- Verification method: Review, Static Inspection + +**SRS-151**: The software shall provide an Adaptive Shell that resolves compact, medium, and expanded layout classes. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115 +- Verification method: Widget Test, Integration Test + +**SRS-152**: The compact layout shall use a single-column primary content structure and mobile-appropriate primary navigation. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115, SysDes-116 +- Verification method: Widget Test, Integration Test + +**SRS-153**: The medium layout shall support side navigation or equivalent navigation rail behavior where available display width permits. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P1 / Beta +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115, SysDes-116 +- Verification method: Widget Test, Integration Test + +**SRS-154**: The expanded layout shall support persistent side panes and persistent voice controls where available display width permits. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P2 / Production +- Allocated to: Flutter App Shell +- Source SysDes: SysDes-115, SysDes-116 +- Verification method: Integration Test, System Test + +**SRS-155**: The software shall keep connection status visible or directly reachable in compact, medium, and expanded layouts. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Connection UI +- Source SysDes: SysDes-116 +- Verification method: Integration Test + +**SRS-156**: The software shall keep primary voice controls visible or directly reachable in compact, medium, and expanded layouts. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Voice UI +- Source SysDes: SysDes-116 +- Verification method: Integration Test + +**SRS-157**: The software shall provide screen-reader semantics for critical connection, voice, channel, diagnostics, and settings controls. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System +- Source SysDes: SysDes-117, SysDes-130 +- Verification method: Accessibility Test + +**SRS-158**: The software shall provide localized accessibility labels for icon-only controls. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Localization Service +- Source SysDes: SysDes-117, SysDes-130 +- Verification method: Accessibility Test, Localization Test + +**SRS-159**: The software shall not express critical states by color alone; it shall also use text, iconography, shape, position, or semantic labeling. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Design System +- Source SysDes: SysDes-117 +- Verification method: Widget Test, Accessibility Test + +**SRS-160**: The software shall support visible focus indication and logical focus traversal for desktop and tablet keyboard use. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P1 / Beta +- Allocated to: Flutter UI +- Source SysDes: SysDes-117 +- Verification method: Widget Test, System Test + +**SRS-161**: The software shall keep critical actions reachable under increased text scaling. + +- Status: Baseline +- Type: Software Accessibility Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI +- Source SysDes: SysDes-117 +- Verification method: Accessibility Test + +**SRS-162**: The software shall apply platform safe area, display cutout, system bar, virtual keyboard, and desktop window inset constraints through shared shell behavior. + +- Status: Baseline +- Type: Software Platform Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Platform Adapter +- Source SysDes: SysDes-118 +- Verification method: Platform Test + +**SRS-163**: The software shall model Android back navigation as a platform back intent handled by the shell or platform service layer. + +- Status: Baseline +- Type: Software Platform Requirement +- Stage: P1 / Beta +- Allocated to: Flutter App Shell, Platform Adapter +- Source SysDes: SysDes-118 +- Verification method: Platform Test + +**SRS-164**: The software shall model iOS navigation gestures, safe areas, keyboard avoidance, and haptics through platform-aware UI services. + +- Status: Baseline +- Type: Software Platform Requirement +- Stage: P1 / Beta +- Allocated to: Flutter App Shell, Platform Adapter +- Source SysDes: SysDes-118 +- Verification method: Platform Test + +**SRS-165**: The software shall provide a Localization Service for product-owned user-visible strings. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119 +- Verification method: Unit Test, Integration Test + +**SRS-166**: The software shall externalize product-owned user-visible strings into localization resources or an equivalent mechanism. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119 +- Verification method: Inspection + +**SRS-167**: The software shall provide English as the baseline product locale. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119, SysDes-131 +- Verification method: Localization Test + +**SRS-168**: The software shall implement deterministic fallback behavior when a translation key is missing. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Localization Service +- Source SysDes: SysDes-119, SysDes-131 +- Verification method: Unit Test + +**SRS-169**: The software shall allow additional locales to be added without changing protocol, audio, state synchronization, or storage modules. + +- Status: Baseline +- Type: Software Maintainability Requirement +- Stage: P1 / Beta +- Allocated to: Localization Service, Flutter UI +- Source SysDes: SysDes-119 +- Verification method: Review, Inspection + +**SRS-170**: The software shall display server-provided server names, channel names, client nicknames, and text messages as content rather than translating them. + +- Status: Baseline +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Flutter UI, Protocol DTOs +- Source SysDes: SysDes-120 +- Verification method: Integration Test + +**SRS-171**: The software shall preserve Unicode text received from compatible servers through protocol adapter, bridge DTO, state store, and UI rendering paths. + +- Status: Baseline +- Type: Software Data Requirement +- Stage: P0 / MVP +- Allocated to: Protocol Adapter, Bridge, Rust Core, Flutter UI +- Source SysDes: SysDes-120, SysDes-121 +- Verification method: Integration Test + +**SRS-172**: The software shall use UTF-8 internally for cross-layer text DTOs unless a boundary adapter requires conversion. + +- Status: Baseline +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Bridge, Rust Core, Storage, Diagnostics, Protocol Adapter +- Source SysDes: SysDes-121 +- Verification method: Inspection, Integration Test + +**SRS-173**: The software shall isolate non-UTF-8 or platform-specific string conversion in boundary adapters. + +- Status: Baseline +- Type: Software Interface Requirement +- Stage: P1 / Beta +- Allocated to: Protocol Adapter, Platform Adapter, Bridge +- Source SysDes: SysDes-122 +- Verification method: Inspection, Integration Test + +**SRS-174**: The software shall not corrupt multilingual Unicode content in logs or diagnostic exports unless redaction intentionally removes sensitive content. + +- Status: Baseline +- Type: Software Data Integrity Requirement +- Stage: P0 / MVP +- Allocated to: Diagnostics, Storage +- Source SysDes: SysDes-121, SysDes-124 +- Verification method: Test, Audit + +**SRS-175**: The software shall support bidirectional text display where the Flutter platform text engine supports it. + +- Status: Baseline +- Type: Software Internationalization Requirement +- Stage: P2 / Production +- Allocated to: Flutter UI +- Source SysDes: SysDes-123 +- Verification method: Localization Test + +**SRS-176**: The software shall use locale-aware formatting for user-visible dates, times, numbers, and diagnostic timestamps. + +- Status: Baseline +- Type: Software Internationalization Requirement +- Stage: P1 / Beta +- Allocated to: Localization Service, Diagnostics UI +- Source SysDes: SysDes-123, SysDes-124 +- Verification method: Localization Test + +**SRS-177**: The software shall keep diagnostic event keys, codes, and machine-readable fields language-neutral. + +- Status: Baseline +- Type: Software Diagnostics Requirement +- Stage: P1 / Beta +- Allocated to: Diagnostics +- Source SysDes: SysDes-124 +- Verification method: Inspection, Test + +**SRS-178**: The software shall allow user-facing diagnostic descriptions to be localized independently of machine-readable diagnostic fields. + +- Status: Baseline +- Type: Software Diagnostics Requirement +- Stage: P1 / Beta +- Allocated to: Diagnostics, Localization Service +- Source SysDes: SysDes-124 +- Verification method: Inspection, Localization Test + +**SRS-179**: The software shall maintain UI/UX guideline, design token, component catalog, adaptive layout, and platform behavior documents as downstream design baselines. + +- Status: Baseline +- Type: Software Documentation Requirement +- Stage: P1 / Beta +- Allocated to: UX, Software Engineering +- Source SysDes: SysDes-125 +- Verification method: Review + +**SRS-180**: The software requirements baseline shall derive requirements only from `SysDes-XXX` sources. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Engineering +- Source SysDes: SysDes-126, SysDes-127 +- Verification method: Inspection + +**SRS-181**: The SRS shall not use direct upstream system-requirement source fields or direct system-requirement trace links. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Engineering +- Source SysDes: SysDes-127 +- Verification method: Inspection + +**SRS-182**: The software architecture shall derive architecture items only from `SRS-XXX` sources. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Architecture +- Source SysDes: SysDes-128 +- Verification method: Inspection + +**SRS-183**: The software detailed design shall derive detailed design items only from `SAD-XXX` sources. + +- Status: Baseline +- Type: Traceability Requirement +- Stage: P0 / MVP +- Allocated to: Software Design +- Source SysDes: SysDes-129 +- Verification method: Inspection + +**SRS-184**: Theme, localization, and initial platform adaptation shall be initialized before feature screens render user-visible content. + +- Status: Baseline +- Type: Software Dynamic Behavior Requirement +- Stage: P0 / MVP +- Allocated to: Flutter App Shell, Design System, Localization Service, Platform Adapter +- Source SysDes: SysDes-132 +- Verification method: Integration Test + +## 14. Updated SRS to SysDes Coverage Statement + +| SysDes Range | SRS Coverage | +|---|---| +| SysDes-001 through SysDes-110 | Covered by inherited SRS baseline `SRS-001` through `SRS-143` | +| SysDes-111 through SysDes-132 | Covered by `SRS-144` through `SRS-184` | + +## 15. Change History + +| Version | Date | Description | +|---|---|---| +| 0.5.0 | 2026-05-14 | Added Material 3, design system, adaptive layout, accessibility, platform behavior, localization, Unicode, diagnostics localization, and strict downstream traceability software requirements. | + +--- + +## 16. Platform Baseline and Product Decision Software Requirements + +**SRS-185**: The software shall define iOS 13 as the minimum iOS runtime deployment baseline unless approved platform constraints raise the minimum version. + +- Status: Baseline Candidate +- Type: Software Platform Requirement +- Stage: P0 / MVP +- Allocated to: iOS Build Configuration, Platform Adapter +- Source SysDes: SysDes-133 +- Verification method: Platform Test, Release Inspection + +**SRS-186**: The iOS/iPadOS release build process shall require Xcode 26 or later and the iOS 26 / iPadOS 26 SDK or later for App Store Connect upload on or after 2026-04-28, unless Apple publishes a newer applicable upload requirement before upload. + +- Status: Baseline Candidate +- Type: Software Release Requirement +- Stage: P0 / MVP +- Allocated to: iOS Build Configuration, Release Pipeline +- Source SysDes: SysDes-134 +- Verification method: Release Inspection + +**SRS-187**: The software shall define Android API 24 as the minimum Android runtime baseline unless approved platform constraints raise the minimum version. + +- Status: Baseline Candidate +- Type: Software Platform Requirement +- Stage: P0 / MVP +- Allocated to: Android Build Configuration, Platform Adapter +- Source SysDes: SysDes-135 +- Verification method: Platform Test + +**SRS-188**: The Android release build process shall target the Android API level required by Google Play on the upload date. + +- Status: Baseline Candidate +- Type: Software Release Requirement +- Stage: P0 / MVP +- Allocated to: Android Build Configuration, Release Pipeline +- Source SysDes: SysDes-135 +- Verification method: Release Inspection + +**SRS-189**: The software shall permit only one active server connection per client instance in MVP. + +- Status: Baseline Candidate +- Type: Software Functional Requirement +- Stage: P0 / MVP +- Allocated to: Rust Core, Flutter UI, Protocol Adapter, State Sync +- Source SysDes: SysDes-136 +- Verification method: System Test + +**SRS-190**: The software shall enable AEC, AGC, Noise Suppression, and High-Pass Filter by default where supported and stable, with user or platform control to disable supported processing where applicable. + +- Status: Baseline Candidate +- Type: Software Audio Requirement +- Stage: P0 / MVP +- Allocated to: Audio Subsystem, Settings UI, Platform Audio +- Source SysDes: SysDes-137 +- Verification method: Audio Test + +**SRS-191**: The software shall use platform-native audio processing first for MVP where available and stable, and shall isolate any Rust/WebRTC-style fallback behind the audio subsystem boundary. + +- Status: Baseline Candidate +- Type: Software Architecture Constraint +- Stage: P1 / Beta +- Allocated to: Audio Subsystem, Platform Audio Adapter +- Source SysDes: SysDes-138 +- Verification method: Architecture Review, Audio Test + +**SRS-192**: The software shall use SQLite or an equivalent embedded local database for non-secret local state and platform secure storage for secrets. + +- Status: Baseline Candidate +- Type: Software Storage Requirement +- Stage: P0 / MVP +- Allocated to: Storage, Platform Secure Storage +- Source SysDes: SysDes-139 +- Verification method: Storage Test, Security Audit + +**SRS-193**: The software shall use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs. + +- Status: Baseline Candidate +- Type: Software Interface Requirement +- Stage: P0 / MVP +- Allocated to: Bridge, Flutter State, Rust Core +- Source SysDes: SysDes-140 +- Verification method: Integration Test, Architecture Review + +**SRS-194**: The software shall not perform automatic diagnostic upload, automatic telemetry upload, or automatic crash reporting in MVP unless a later approved decision updates privacy, security, legal, release, and verification baselines. + +- Status: Baseline Candidate +- Type: Software Privacy Requirement +- Stage: P0 / MVP +- Allocated to: Diagnostics, Privacy, Release Pipeline +- Source SysDes: SysDes-141 +- Verification method: Privacy Review, Security Audit + +## 17. Updated SRS to SysDes Coverage Statement + +| SysDes Range | SRS Coverage | +|---|---| +| SysDes-001 through SysDes-132 | Covered by inherited SRS baseline `SRS-001` through `SRS-184` | +| SysDes-133 through SysDes-141 | Covered by `SRS-185` through `SRS-194` | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date and preserved SRS direct-source rule through SysDes only. | diff --git a/docs/requirements/sysrs.md b/docs/requirements/sysrs.md new file mode 100644 index 0000000..2d12409 --- /dev/null +++ b/docs/requirements/sysrs.md @@ -0,0 +1,1904 @@ +# Chanora SysRS — System Requirements Specification + +**Product name:** Chanora +**Document type:** SysRS / System Requirements Specification +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Product category:** Cross-platform voice client application +**Architecture:** Flutter + Rust Core +**Protocol library:** `tsclientlib` +**Target client platforms:** Windows, macOS, Linux, iOS, Android +**Source material:** Initial Chanora application-system requirements draft +**Supersedes:** Earlier mixed SYS/SRS draft + +**Repo path:** `docs/requirements/sysrs.md` --- + +## 1. Document Control + +### 1.1 Purpose + +This document is the **System Requirements Specification (SysRS)** for the **Chanora application system**. + +Chanora is an **application**, not an operating system. In this document, the word **system** means the complete application system and its runtime environment: + +- The Chanora client application +- The Flutter user interface +- The Rust Core +- The `tsclientlib` protocol adapter +- Platform adapters +- Local and secure storage +- Audio input/output devices used by the application +- Operating system services used by the application +- Network connectivity required by the application +- External TeamSpeak 3-compatible servers used by the application +- Deployment, diagnostics, and support processes + +The SysRS covers the whole environment required for the application to run correctly. It does not claim that Chanora is an operating system. + +--- + +### 1.2 SysRS vs Software SRS + +A software-only SRS would focus mainly on the application code. + +This SysRS includes both application requirements and runtime environment requirements, including: + +- Client device requirements +- Operating system service requirements +- Audio hardware requirements +- Network requirements +- External compatible server requirements +- Deployment requirements +- Security and privacy requirements +- Diagnostics and support requirements + +--- + +### 1.3 Requirement ID Convention + +Every normative requirement uses this format: + +```text +SysRS-XXX +``` + +Where `XXX` is a three-digit sequential number. + +Requirement keywords: + +| Keyword | Meaning | +|---|---| +| shall | Mandatory | +| should | Strongly recommended | +| may | Optional | +| shall not | Prohibited | + +Priority values: + +| Priority | Meaning | +|---|---| +| P0 | Required for MVP | +| P1 | Required for Beta | +| P2 | Required for Production | +| P3 | Future or optional | + +Verification methods: + +| Method | Meaning | +|---|---| +| Review | Verified by reviewing documentation, requirements, or design | +| Inspection | Verified by inspecting code, configuration, packaging, or environment setup | +| Test | Verified by automated or manual test | +| Demo | Verified through a working demonstration | +| Audit | Verified through security, privacy, legal, or compliance review | + +--- + +### 1.4 Input Reference Documents + +| Document | Description | +|---|---| +| Initial Chanora application-system requirements draft | Source material used to prepare this SysRS | + +### 1.5 Downstream Lifecycle Documents + +The downstream engineering documentation sequence shall be: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification +``` + +This SysRS is the system-level requirements baseline. Downstream documents shall be derived from this SysRS and shall not override it unless the SysRS is formally revised. + +| Order | Document | Purpose | +|---:|---|---| +| 1 | SysRS — System Requirements Specification | Defines whole application-system requirements, including client application behavior, runtime environment, devices, networks, external compatible servers, security, deployment, diagnostics, and operational constraints. | +| 2 | SysDes — System Design Specification | Defines system-level design and allocation of SysRS requirements to system elements such as Flutter UI, Rust Core, protocol adapter, audio subsystem, platform adapters, storage, diagnostics, external servers, and deployment environment. | +| 3 | SRS — Software Requirements Specification | Defines software-only requirements for the Chanora software components derived from the SysRS and SysDes. | +| 4 | SAD — Software Architecture Description | Defines software architecture views, major software components, interfaces, runtime flows, dependency rules, and architectural decisions. | +| 5 | SDD — Software Detailed Design | Defines detailed module design, APIs, data structures, state machines, database schemas, DTOs, bridge contracts, and implementation-level design details. | +| 6 | Verification | Defines verification plans, test cases, acceptance criteria, traceability matrices, platform compatibility tests, security checks, audio validation, and release validation. | + +Potential downstream file names: + +| Document | Suggested file | +|---|---| +| SysDes | `docs/chanora_SysDes.md` | +| SRS | `docs/chanora_SRS.md` | +| SAD | `docs/chanora_SAD.md` | +| SDD | `docs/chanora_SDD.md` | +| Verification | `docs/chanora_Verification.md` | + +--- + +## 2. System Overview + +### 2.1 Application Context + +```text +┌─────────────────────────────────────────────────────────────────────────────┐ +│ User Runtime Environment │ +│ │ +│ ┌────────────────────┐ ┌─────────────────────────────────────────┐ │ +│ │ Audio Hardware │<----->│ Chanora Client Application │ │ +│ │ Mic / Headset │ │ │ │ +│ │ Speakers / BT │ │ Flutter UI │ │ +│ └────────────────────┘ │ Flutter State Layer │ │ +│ │ Bridge Layer │ │ +│ ┌────────────────────┐ │ Rust Core │ │ +│ │ OS Services │<----->│ tsclientlib Protocol Adapter │ │ +│ │ Permissions │ │ Audio Processing Pipeline │ │ +│ │ Secure Storage │ │ Local Storage │ │ +│ │ Audio Session │ │ Diagnostics │ │ +│ │ Notifications │ └─────────────────────────────────────────┘ │ +│ └────────────────────┘ │ │ +│ │ Network │ +│ v │ +│ ┌─────────────────────────────────────────┐ │ +│ │ External TeamSpeak 3-compatible Server │ │ +│ │ Channels / Clients / Voice / Text │ │ +│ └─────────────────────────────────────────┘ │ +└─────────────────────────────────────────────────────────────────────────────┘ +``` + +### 2.2 System Boundary + +Inside the Chanora application system boundary: + +- Chanora client application +- Flutter UI +- Flutter state layer +- Rust Core +- Bridge layer +- `tsclientlib` adapter +- Audio processing pipeline +- Local database +- Secure storage adapter +- Diagnostics and export tools +- Platform service adapters + +Outside the Chanora application system boundary: + +- External TeamSpeak 3-compatible servers +- Server administration and server-side permissions +- Physical audio hardware +- Operating system vendor services +- App stores and package repositories +- User-managed routers, firewalls, VPNs, NAT devices, and ISPs + +### 2.3 Primary Runtime Flow + +```text +User action + -> Flutter UI + -> Bridge command + -> Rust Core + -> tsclientlib protocol adapter + -> External compatible voice server + -> Protocol event + -> Rust Core state reducer + -> Bridge event stream + -> Flutter UI update +``` + +### 2.4 Primary Audio Flow + +```text +Microphone + -> OS/platform capture + -> Audio preprocessing + -> High-Pass Filter + -> Noise Suppression + -> Echo Canceller + -> Automatic Gain Control + -> Push-to-talk / mute gate + -> Opus-compatible encoder + -> tsclientlib protocol adapter + -> External compatible server + +External compatible server + -> tsclientlib protocol adapter + -> Jitter buffer + -> Opus-compatible decoder + -> Per-user mute/volume + -> Mixer + -> OS/platform playback + -> Speaker/headphones +``` + + +## 3. Application System Scope Requirements + + +**SysRS-001**: The Chanora application shall be a cross-platform client application for channel-based voice communication. + +- Priority: P0 +- Verification: Review + +**SysRS-002**: The Chanora application shall support Windows, macOS, Linux, iOS, and Android as target client platforms. + +- Priority: P0 +- Verification: Review + +**SysRS-003**: The Chanora application shall use Flutter for the user-facing client interface. + +- Priority: P0 +- Verification: Inspection + +**SysRS-004**: The Chanora application shall use Rust Core for protocol handling, connection management, state synchronization, audio processing, storage coordination, diagnostics, and business logic. + +- Priority: P0 +- Verification: Inspection + +**SysRS-005**: The Chanora application shall use `tsclientlib` as the TeamSpeak-compatible protocol client library. + +- Priority: P0 +- Verification: Inspection + +**SysRS-006**: The Chanora application shall operate as an independent client and shall not present itself as an official TeamSpeak product. + +- Priority: P0 +- Verification: Audit + +**SysRS-007**: The Chanora application shall allow users to connect to TeamSpeak 3-compatible servers reachable from the client device network. + +- Priority: P0 +- Verification: Test + +**SysRS-008**: The Chanora application shall allow users to participate in channel-based voice communication when the external server and user permissions allow it. + +- Priority: P0 +- Verification: Test + +**SysRS-009**: The Chanora application shall allow users to send and receive supported text messages when the external server and user permissions allow it. + +- Priority: P0 +- Verification: Test + +**SysRS-010**: The Chanora application shall provide local bookmark, recent server, identity reference, UI setting, and audio setting management on the client device. + +- Priority: P0 +- Verification: Test + + +## 4. Stakeholder and User Environment Requirements + + +**SysRS-011**: The Chanora application shall support end users who manually connect to compatible voice servers. + +- Priority: P0 +- Verification: Demo + +**SysRS-012**: The Chanora application shall support regular users who rely on saved bookmarks, persistent identity, audio settings, and common voice controls. + +- Priority: P0 +- Verification: Demo + +**SysRS-013**: The Chanora application shall support testers and support operators who export diagnostics for troubleshooting. + +- Priority: P1 +- Verification: Demo + +**SysRS-014**: The SysRS shall provide requirements traceability suitable for engineering, QA, system administration, and release operations. + +- Priority: P1 +- Verification: Review + +**SysRS-015**: The SysRS shall document external environment dependencies that may need administrator configuration, including network reachability and OS-level audio permissions. + +- Priority: P1 +- Verification: Review + + +## 5. System Boundary and External Dependency Requirements + + +**SysRS-016**: The Chanora application shall treat external TeamSpeak 3-compatible servers as external systems outside Chanora control. + +- Priority: P0 +- Verification: Review + +**SysRS-017**: The Chanora application shall not require a Chanora-operated central server for MVP voice, channel, or text operation. + +- Priority: P0 +- Verification: Review + +**SysRS-018**: The Chanora application shall not host or operate TeamSpeak-compatible server functionality in the MVP. + +- Priority: P0 +- Verification: Review + +**SysRS-019**: The Chanora application shall rely on operating system services for microphone permission, secure storage, audio routing, notifications, and mobile lifecycle behavior. + +- Priority: P0 +- Verification: Review + +**SysRS-020**: The Chanora application shall treat app stores, package repositories, installers, and update services as deployment environment components. + +- Priority: P1 +- Verification: Review + +**SysRS-021**: The Chanora application shall treat physical microphones, speakers, wired headsets, USB audio devices, and Bluetooth audio devices as external hardware interfaces. + +- Priority: P0 +- Verification: Review + +**SysRS-022**: The Chanora application shall treat routers, firewalls, VPNs, NAT devices, and ISPs as external network environment components. + +- Priority: P1 +- Verification: Review + +**SysRS-023**: The Chanora application shall expose user-safe errors when external dependencies prevent successful operation. + +- Priority: P0 +- Verification: Test + + +## 6. Application Component Requirements + + +**SysRS-024**: The Chanora application shall include a Flutter UI component responsible for rendering screens, receiving user input, and presenting application state. + +- Priority: P0 +- Verification: Inspection + +**SysRS-025**: The Chanora application shall include a Flutter State Layer responsible for UI state derived from Rust Core events. + +- Priority: P0 +- Verification: Inspection + +**SysRS-026**: The Chanora application shall include a Bridge Layer responsible for commands, DTOs, asynchronous calls, and event streams between Flutter and Rust Core. + +- Priority: P0 +- Verification: Inspection + +**SysRS-027**: The Chanora application shall include a Rust Core component responsible for authoritative connection, protocol, state, audio, storage, settings, and diagnostics behavior. + +- Priority: P0 +- Verification: Inspection + +**SysRS-028**: The Chanora application shall include a protocol adapter component that isolates direct `tsclientlib` usage. + +- Priority: P0 +- Verification: Inspection + +**SysRS-029**: The Chanora application shall include a state synchronization component that implements snapshot + delta state handling. + +- Priority: P0 +- Verification: Inspection + +**SysRS-030**: The Chanora application shall include an audio subsystem component that coordinates capture, processing, encoding, decoding, jitter buffering, mixing, and playback. + +- Priority: P0 +- Verification: Inspection + +**SysRS-031**: The Chanora application shall include a local storage component for non-secret data such as bookmarks, recent servers, UI settings, and audio settings. + +- Priority: P0 +- Verification: Inspection + +**SysRS-032**: The Chanora application shall include a secure storage adapter for private identities, passwords, and future sensitive tokens. + +- Priority: P0 +- Verification: Inspection + +**SysRS-033**: The Chanora application shall include a diagnostics component for structured logging, redaction, event recording, event replay, audio diagnostics, network diagnostics, and user-initiated export. + +- Priority: P1 +- Verification: Inspection + +**SysRS-034**: The Chanora application shall include platform adapter components for desktop and mobile platform services. + +- Priority: P0 +- Verification: Inspection + + +## 7. Client Device and Hardware Environment Requirements + + +**SysRS-035**: The client device shall use a CPU architecture supported by Flutter, Rust, and the selected target platform. + +- Priority: P0 +- Verification: Inspection + +**SysRS-036**: The client device shall provide sufficient CPU capacity to run the Chanora application, Opus-compatible voice processing, and enabled audio processing features in real time. + +- Priority: P0 +- Verification: Test + +**SysRS-037**: The client device shall provide sufficient memory for the Chanora application to run without unbounded growth in logs, chat history, audio buffers, or event queues. + +- Priority: P0 +- Verification: Test + +**SysRS-038**: The client device shall provide persistent local storage for Chanora application data, settings, logs, and cached metadata. + +- Priority: P0 +- Verification: Inspection + +**SysRS-039**: The client device shall provide a microphone or supported audio input device for voice transmission. + +- Priority: P0 +- Verification: Test + +**SysRS-040**: The client device shall provide speakers, headphones, or a supported audio output device for voice playback. + +- Priority: P0 +- Verification: Test + +**SysRS-041**: The client device shall provide network connectivity to the selected compatible voice server. + +- Priority: P0 +- Verification: Test + +**SysRS-042**: The desktop client environment should be validated on devices with at least 4 GB RAM for MVP operation. + +- Priority: P1 +- Verification: Test + +**SysRS-043**: The desktop client environment should be validated with at least 500 MB free local storage for installation, settings, logs, and diagnostic bundle creation. + +- Priority: P1 +- Verification: Test + +**SysRS-044**: The client device should provide stable audio device identifiers where the target platform supports persistent device selection. + +- Priority: P1 +- Verification: Test + +**SysRS-045**: The client device should provide hardware or OS support for low-latency audio capture and playback. + +- Priority: P1 +- Verification: Test + +**SysRS-046**: The client device should provide Bluetooth audio support where the target operating system supports it. + +- Priority: P1 +- Verification: Test + +**SysRS-047**: The project shall document platform-specific hardware limitations discovered during compatibility testing. + +- Priority: P1 +- Verification: Review + + +## 8. Operating System Service Requirements + + +**SysRS-048**: The Windows runtime environment shall support native desktop window integration for the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-049**: The Windows runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure credential storage to the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-050**: The macOS runtime environment shall support native desktop window integration for the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-051**: The macOS runtime environment shall provide microphone permission prompts, microphone capture, speaker/headphone playback, audio device selection, and Keychain access to the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-052**: The Linux runtime environment shall support the desktop environments targeted by the selected release package. + +- Priority: P1 +- Verification: Test + +**SysRS-053**: The Linux runtime environment shall provide microphone capture, speaker/headphone playback, audio device selection, and secure storage through Secret Service, libsecret, or equivalent where available. + +- Priority: P1 +- Verification: Test + +**SysRS-054**: The iOS runtime environment shall provide microphone permissions, foreground voice session capability, audio route change handling, audio interruption recovery, Keychain access, and AVAudioSession behavior to the Chanora application. + +- Priority: P0 +- Verification: Test + +**SysRS-055**: The Android runtime environment shall provide microphone permissions, foreground voice session capability, foreground service behavior, audio focus, Bluetooth route handling, Android Keystore access, and production audio integration through AAudio, Oboe, or equivalent. + +- Priority: P0 +- Verification: Test + +**SysRS-056**: The project shall define minimum supported operating system versions for each target platform before beta release. + +- Priority: P1 +- Verification: Review + +**SysRS-057**: The project shall document OS-level permissions required by each target platform before public release. + +- Priority: P1 +- Verification: Review + +**SysRS-058**: The Chanora application shall fail safely with a user-safe message when a required OS service is unavailable. + +- Priority: P0 +- Verification: Test + + +## 9. Audio Hardware and Audio Processing Requirements + + +**SysRS-059**: The Chanora application shall support microphone input for voice transmission. + +- Priority: P0 +- Verification: Test + +**SysRS-060**: The Chanora application shall support speaker or headphone output for voice playback. + +- Priority: P0 +- Verification: Test + +**SysRS-061**: The Chanora application shall support audio input and output device selection where the target platform exposes selectable devices. + +- Priority: P0 +- Verification: Test + +**SysRS-062**: The Chanora application shall handle audio route changes where the target platform reports them. + +- Priority: P0 +- Verification: Test + +**SysRS-063**: The Chanora application shall recover gracefully from audio device changes where possible. + +- Priority: P1 +- Verification: Test + +**SysRS-064**: The Chanora application shall support Echo Canceller for reducing playback audio leaking into microphone input. + +- Priority: P0 +- Verification: Test + +**SysRS-065**: The Chanora application shall support Automatic Gain Control for normalizing microphone input level. + +- Priority: P0 +- Verification: Test + +**SysRS-066**: The Chanora application shall support Noise Suppression for reducing stationary background noise. + +- Priority: P0 +- Verification: Test + +**SysRS-067**: The Chanora application shall support High-Pass Filter for reducing low-frequency rumble and handling noise. + +- Priority: P0 +- Verification: Test + +**SysRS-068**: The Chanora application shall support an audio processing backend abstraction so platform-native and Rust-based processing can be selected per platform. + +- Priority: P1 +- Verification: Review + +**SysRS-069**: The Chanora application shall allow Echo Canceller to use playback reference audio when the selected implementation requires it. + +- Priority: P0 +- Verification: Test + +**SysRS-070**: The Chanora application shall expose audio processing settings to Rust Core and persist them locally. + +- Priority: P0 +- Verification: Test + +**SysRS-071**: The Chanora application shall provide conservative default settings for Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter. + +- Priority: P0 +- Verification: Review + +**SysRS-072**: The Chanora application shall allow platform-specific disabling of audio processing features when a feature is unstable or incompatible with a device configuration. + +- Priority: P0 +- Verification: Test + +**SysRS-073**: The project shall provide an audio loopback test tool for development and compatibility testing. + +- Priority: P1 +- Verification: Demo + +**SysRS-074**: The project shall provide an audio processing test tool for development and compatibility testing. + +- Priority: P1 +- Verification: Demo + + +## 10. Network Environment Requirements + + +**SysRS-075**: The client network environment shall provide IP network connectivity from the client device to the selected compatible voice server. + +- Priority: P0 +- Verification: Test + +**SysRS-076**: The Chanora application shall allow the user to configure the server host or IP address. + +- Priority: P0 +- Verification: Test + +**SysRS-077**: The Chanora application shall allow the user to configure the server port. + +- Priority: P0 +- Verification: Test + +**SysRS-078**: The Chanora application should support a default TeamSpeak 3-compatible voice port when the user does not provide an explicit port. + +- Priority: P1 +- Verification: Test + +**SysRS-079**: The client network environment shall permit the protocol traffic required by `tsclientlib` and the selected compatible server. + +- Priority: P0 +- Verification: Test + +**SysRS-080**: The client network environment shall support latency suitable for real-time voice communication under expected operating conditions. + +- Priority: P0 +- Verification: Test + +**SysRS-081**: The client network environment should minimize packet loss for acceptable voice quality. + +- Priority: P1 +- Verification: Test + +**SysRS-082**: The Chanora application shall detect recoverable network failures where possible. + +- Priority: P0 +- Verification: Test + +**SysRS-083**: The Chanora application shall enter reconnect behavior after recoverable network failures. + +- Priority: P0 +- Verification: Test + +**SysRS-084**: The Chanora application shall rebuild server state from a fresh snapshot after reconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-085**: The Chanora application shall not require VPN connectivity unless the target server or user environment requires it. + +- Priority: P1 +- Verification: Review + +**SysRS-086**: The Chanora application shall present network failures through user-safe error messages. + +- Priority: P0 +- Verification: Test + +**SysRS-087**: The Chanora application should include network diagnostics in user-initiated diagnostic exports. + +- Priority: P1 +- Verification: Inspection + + +## 11. External Compatible Server Requirements + + +**SysRS-088**: The external voice server shall be TeamSpeak 3-compatible for Chanora MVP operation. + +- Priority: P0 +- Verification: Test + +**SysRS-089**: The external voice server shall be reachable from the client device network. + +- Priority: P0 +- Verification: Test + +**SysRS-090**: The external voice server shall permit client connection using the identity, nickname, password, and permissions supplied by the user. + +- Priority: P0 +- Verification: Test + +**SysRS-091**: The external voice server shall expose server information required for initial synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-092**: The external voice server shall expose channel listing required for the channel tree. + +- Priority: P0 +- Verification: Test + +**SysRS-093**: The external voice server shall expose client listing required for the online client view. + +- Priority: P0 +- Verification: Test + +**SysRS-094**: The external voice server shall support channel join operations for accessible channels. + +- Priority: P0 +- Verification: Test + +**SysRS-095**: The external voice server shall emit channel movement events required for state synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-096**: The external voice server shall emit client join and leave events required for state synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-097**: The external voice server shall emit channel create, update, and delete events required for state synchronization where those events occur. + +- Priority: P0 +- Verification: Test + +**SysRS-098**: The external voice server shall support channel text message send and receive where user permissions allow. + +- Priority: P0 +- Verification: Test + +**SysRS-099**: The external voice server shall support voice packet send and receive where user permissions allow. + +- Priority: P0 +- Verification: Test + +**SysRS-100**: The external voice server shall expose disconnect behavior or connection failure signals that can be mapped by the protocol adapter. + +- Priority: P0 +- Verification: Test + +**SysRS-101**: The project shall document server-side permissions that can affect channel join, voice transmission, and text messaging. + +- Priority: P1 +- Verification: Review + + +## 12. Application Functional Requirements + + +**SysRS-102**: The Chanora application shall allow the user to manually connect to a compatible server. + +- Priority: P0 +- Verification: Demo + +**SysRS-103**: The Chanora application shall allow the user to provide hostname or IP address, port, nickname, and optional server password before connection. + +- Priority: P0 +- Verification: Demo + +**SysRS-104**: The Chanora application shall support persistent local identity for compatible server authentication. + +- Priority: P0 +- Verification: Demo + +**SysRS-105**: The Chanora application shall display connection status to the user. + +- Priority: P0 +- Verification: Demo + +**SysRS-106**: The Chanora application shall allow the user to disconnect from the active server connection. + +- Priority: P0 +- Verification: Demo + +**SysRS-107**: The Chanora application shall display the server channel tree after synchronization. + +- Priority: P0 +- Verification: Demo + +**SysRS-108**: The Chanora application shall display online clients after synchronization. + +- Priority: P0 +- Verification: Demo + +**SysRS-109**: The Chanora application shall allow the user to join an accessible voice channel. + +- Priority: P0 +- Verification: Demo + +**SysRS-110**: The Chanora application shall allow the user to send and receive channel text messages where permitted. + +- Priority: P0 +- Verification: Demo + +**SysRS-111**: The Chanora application shall capture and transmit voice where permitted. + +- Priority: P0 +- Verification: Demo + +**SysRS-112**: The Chanora application shall receive and play voice where permitted. + +- Priority: P0 +- Verification: Demo + +**SysRS-113**: The Chanora application shall provide microphone mute control. + +- Priority: P0 +- Verification: Demo + +**SysRS-114**: The Chanora application shall provide output deaf control. + +- Priority: P0 +- Verification: Demo + +**SysRS-115**: The Chanora application shall provide push-to-talk control. + +- Priority: P0 +- Verification: Demo + +**SysRS-116**: The Chanora application shall display microphone input level where available. + +- Priority: P0 +- Verification: Demo + +**SysRS-117**: The Chanora application shall display speaking indicators where available. + +- Priority: P0 +- Verification: Demo + +**SysRS-118**: The Chanora application shall allow users to save and reuse server bookmarks. + +- Priority: P0 +- Verification: Demo + +**SysRS-119**: The Chanora application shall allow users to configure audio processing features. + +- Priority: P0 +- Verification: Demo + +**SysRS-120**: The Chanora application shall allow users to export redacted diagnostics. + +- Priority: P1 +- Verification: Demo + + +## 13. Protocol Integration Requirements + + +**SysRS-121**: The Chanora application shall use `tsclientlib` inside the protocol subsystem. + +- Priority: P0 +- Verification: Inspection + +**SysRS-122**: The Chanora application shall isolate direct `tsclientlib` calls inside the `chanora_protocol` component. + +- Priority: P0 +- Verification: Inspection + +**SysRS-123**: The Chanora application shall prevent raw `tsclientlib` types from crossing into Flutter UI or Flutter State Layer. + +- Priority: P0 +- Verification: Inspection + +**SysRS-124**: The Chanora application shall convert `tsclientlib` errors into Chanora protocol errors. + +- Priority: P0 +- Verification: Test + +**SysRS-125**: The Chanora application shall convert `tsclientlib` events into internal protocol events. + +- Priority: P0 +- Verification: Test + +**SysRS-126**: The Chanora application shall support future patching, replacement, or forking of protocol implementation without changing Flutter UI contracts. + +- Priority: P1 +- Verification: Review + +**SysRS-127**: The project shall provide protocol compatibility test coverage for MVP features. + +- Priority: P1 +- Verification: Test + +**SysRS-128**: The project shall include a protocol probe tool for validating target server compatibility. + +- Priority: P0 +- Verification: Demo + + +## 14. State Synchronization Requirements + + +**SysRS-129**: The Chanora application shall maintain one authoritative connection state per active server connection. + +- Priority: P0 +- Verification: Test + +**SysRS-130**: The Chanora application shall synchronize state using a snapshot + delta model. + +- Priority: P0 +- Verification: Test + +**SysRS-131**: The Chanora application shall emit a full snapshot after initial synchronization. + +- Priority: P0 +- Verification: Test + +**SysRS-132**: The Chanora application shall emit delta events after live server-side changes. + +- Priority: P0 +- Verification: Test + +**SysRS-133**: The Chanora application shall apply protocol events through deterministic reducers. + +- Priority: P0 +- Verification: Test + +**SysRS-134**: The Chanora application shall preserve event ordering per connection. + +- Priority: P0 +- Verification: Test + +**SysRS-135**: The Chanora application shall rebuild state from a fresh snapshot after reconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-136**: The Chanora application shall prevent Flutter from directly mutating server state. + +- Priority: P0 +- Verification: Inspection + +**SysRS-137**: The Chanora application shall implement the defined connection state machine from Disconnected through Connecting, Synchronizing, Connected, and Reconnecting. + +- Priority: P0 +- Verification: Test + +**SysRS-138**: The Chanora application shall not automatically reconnect after user-triggered disconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-139**: The project shall include an event replay tool for development and debugging of state synchronization. + +- Priority: P1 +- Verification: Demo + + +## 15. Data and Storage Requirements + + +**SysRS-140**: The Chanora application shall store server bookmarks locally. + +- Priority: P0 +- Verification: Test + +**SysRS-141**: The Chanora application shall store recent servers locally. + +- Priority: P1 +- Verification: Test + +**SysRS-142**: The Chanora application shall store audio settings locally. + +- Priority: P0 +- Verification: Test + +**SysRS-143**: The Chanora application shall store UI settings locally. + +- Priority: P1 +- Verification: Test + +**SysRS-144**: The Chanora application shall store per-user volume preferences locally where applicable. + +- Priority: P1 +- Verification: Test + +**SysRS-145**: The Chanora application shall store muted user preferences locally where applicable. + +- Priority: P1 +- Verification: Test + +**SysRS-146**: The Chanora application shall use SQLite or an equivalent embedded database for non-secret local data. + +- Priority: P0 +- Verification: Inspection + +**SysRS-147**: The Chanora application shall use platform secure storage for sensitive data. + +- Priority: P0 +- Verification: Audit + +**SysRS-148**: The Chanora application shall store identity private keys using platform secure storage. + +- Priority: P0 +- Verification: Audit + +**SysRS-149**: The Chanora application shall store server passwords using platform secure storage. + +- Priority: P0 +- Verification: Audit + +**SysRS-150**: The Chanora application shall not store private keys in plaintext files. + +- Priority: P0 +- Verification: Audit + +**SysRS-151**: The Chanora application shall not write passwords to logs. + +- Priority: P0 +- Verification: Audit + +**SysRS-152**: The Chanora application shall redact secrets from diagnostic exports. + +- Priority: P0 +- Verification: Audit + + +## 16. Security and Privacy Requirements + + +**SysRS-153**: The Chanora application shall store sensitive data using platform secure storage. + +- Priority: P0 +- Verification: Audit + +**SysRS-154**: The Chanora application shall redact secrets from logs. + +- Priority: P0 +- Verification: Audit + +**SysRS-155**: The Chanora application shall redact secrets from diagnostic bundles. + +- Priority: P0 +- Verification: Audit + +**SysRS-156**: The Chanora application shall avoid exposing internal stack traces to normal users. + +- Priority: P0 +- Verification: Test + +**SysRS-157**: The Chanora application shall validate user input before passing it to protocol operations. + +- Priority: P0 +- Verification: Test + +**SysRS-158**: The Windows runtime environment shall support Windows Credential Manager, DPAPI, or equivalent secure credential storage for the Chanora application. + +- Priority: P1 +- Verification: Inspection + +**SysRS-159**: The macOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. + +- Priority: P1 +- Verification: Inspection + +**SysRS-160**: The iOS runtime environment shall support Keychain-based secure credential storage for the Chanora application. + +- Priority: P0 +- Verification: Inspection + +**SysRS-161**: The Android runtime environment shall support Android Keystore or equivalent secure credential storage for the Chanora application. + +- Priority: P0 +- Verification: Inspection + +**SysRS-162**: The Linux runtime environment shall support Secret Service, libsecret, or equivalent secure storage where available. + +- Priority: P2 +- Verification: Inspection + +**SysRS-163**: The Chanora application shall minimize collection of personal data. + +- Priority: P0 +- Verification: Audit + +**SysRS-164**: The Chanora application shall require user action before exporting diagnostics. + +- Priority: P0 +- Verification: Test + +**SysRS-165**: The Chanora application shall explain microphone permission usage before requesting permission where platform guidelines allow. + +- Priority: P0 +- Verification: Test + +**SysRS-166**: The Chanora application shall explain notification permission usage before requesting permission where platform guidelines allow. + +- Priority: P1 +- Verification: Test + +**SysRS-167**: The Chanora application shall not automatically upload diagnostics in MVP. + +- Priority: P0 +- Verification: Audit + + +## 17. Diagnostics and Operations Requirements + + +**SysRS-168**: The Chanora application shall produce structured diagnostic logs. + +- Priority: P0 +- Verification: Inspection + +**SysRS-169**: The Chanora application shall support log redaction. + +- Priority: P0 +- Verification: Audit + +**SysRS-170**: The Chanora application shall support protocol event recording in development or diagnostics mode. + +- Priority: P1 +- Verification: Demo + +**SysRS-171**: The Chanora application shall support event replay for debugging state synchronization. + +- Priority: P1 +- Verification: Demo + +**SysRS-172**: The Chanora application shall support audio diagnostics. + +- Priority: P1 +- Verification: Demo + +**SysRS-173**: The Chanora application shall support network diagnostics. + +- Priority: P1 +- Verification: Demo + +**SysRS-174**: The Chanora application shall support user-initiated diagnostic export. + +- Priority: P1 +- Verification: Demo + +**SysRS-175**: Diagnostic export shall exclude or redact sensitive data. + +- Priority: P0 +- Verification: Audit + +**SysRS-176**: The project shall document the expected support workflow for diagnostic bundle collection. + +- Priority: P2 +- Verification: Review + +**SysRS-177**: The project shall include compatibility test tracking for supported platforms. + +- Priority: P1 +- Verification: Inspection + + +## 18. Non-Functional Requirements + + +**SysRS-178**: The Chanora application shall keep the UI responsive during connection, synchronization, and reconnect. + +- Priority: P0 +- Verification: Test + +**SysRS-179**: The Chanora application shall avoid visible UI freezes longer than 100 ms during normal operation. + +- Priority: P0 +- Verification: Test + +**SysRS-180**: The Chanora application shall minimize local audio pipeline latency. + +- Priority: P0 +- Verification: Test + +**SysRS-181**: The Chanora application should target local audio pipeline latency under 100 ms where platform conditions permit. + +- Priority: P1 +- Verification: Test + +**SysRS-182**: The Chanora application shall avoid unbounded memory growth in chat history. + +- Priority: P0 +- Verification: Test + +**SysRS-183**: The Chanora application shall avoid unbounded memory growth in logs. + +- Priority: P0 +- Verification: Test + +**SysRS-184**: The Chanora application shall avoid unbounded memory growth in audio buffers. + +- Priority: P0 +- Verification: Test + +**SysRS-185**: The Chanora application shall avoid unbounded memory growth in event queues. + +- Priority: P0 +- Verification: Test + +**SysRS-186**: The Chanora application shall perform required audio processing without sustained underruns on supported devices. + +- Priority: P0 +- Verification: Test + +**SysRS-187**: The Chanora application shall keep reconnect processing non-blocking for UI interaction. + +- Priority: P0 +- Verification: Test + +**SysRS-188**: The Chanora application shall recover from transient network loss where possible. + +- Priority: P0 +- Verification: Test + +**SysRS-189**: The Chanora application shall recover gracefully from audio device changes where possible. + +- Priority: P1 +- Verification: Test + +**SysRS-190**: The Chanora application shall isolate connection failures to the affected connection. + +- Priority: P1 +- Verification: Test + +**SysRS-191**: The Chanora application shall avoid crashing on malformed or unexpected protocol events. + +- Priority: P0 +- Verification: Test + + +## 19. Deployment and Release Environment Requirements + + +**SysRS-192**: The project shall support Windows installer packaging for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-193**: The project shall support macOS signed and notarized builds for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-194**: The project shall support Linux packaging through AppImage, Flatpak, deb, rpm, or a selected subset. + +- Priority: P1 +- Verification: Demo + +**SysRS-195**: The project shall support Android AAB release builds for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-196**: The project shall support iOS TestFlight and App Store release builds for the Chanora application. + +- Priority: P1 +- Verification: Demo + +**SysRS-197**: The project shall document platform signing, packaging, and release requirements before public release. + +- Priority: P1 +- Verification: Review + +**SysRS-198**: The project shall ensure release metadata does not imply official TeamSpeak affiliation. + +- Priority: P0 +- Verification: Audit + +**SysRS-199**: The project shall define release channels for internal, beta, and production builds before external testing. + +- Priority: P1 +- Verification: Review + + +## 20. Interface Requirements + + +**SysRS-200**: The Chanora application shall provide a user interface for manual server connection. + +- Priority: P0 +- Verification: Demo + +**SysRS-201**: The Chanora application shall provide a user interface for bookmark management. + +- Priority: P0 +- Verification: Demo + +**SysRS-202**: The Chanora application shall provide a user interface for channel tree navigation. + +- Priority: P0 +- Verification: Demo + +**SysRS-203**: The Chanora application shall provide a user interface for chat. + +- Priority: P0 +- Verification: Demo + +**SysRS-204**: The Chanora application shall provide a user interface for voice controls. + +- Priority: P0 +- Verification: Demo + +**SysRS-205**: The Chanora application shall provide a user interface for audio processing settings. + +- Priority: P0 +- Verification: Demo + +**SysRS-206**: The Chanora application shall provide a bridge interface between Flutter and Rust Core. + +- Priority: P0 +- Verification: Inspection + +**SysRS-207**: The Chanora application shall provide a protocol interface between Rust Core and `tsclientlib`. + +- Priority: P0 +- Verification: Inspection + +**SysRS-208**: The Chanora application shall provide an audio hardware interface through platform capture and playback adapters. + +- Priority: P0 +- Verification: Test + +**SysRS-209**: The Chanora application shall provide secure storage interfaces through platform-specific secure storage mechanisms. + +- Priority: P0 +- Verification: Audit + +**SysRS-210**: The Chanora application shall provide a network interface to external TeamSpeak 3-compatible servers through `tsclientlib`. + +- Priority: P0 +- Verification: Test + + +## 21. System Constraints + + +**SysRS-211**: The Chanora application shall not directly expose raw `tsclientlib` types to Flutter. + +- Priority: P0 +- Verification: Inspection + +**SysRS-212**: The Chanora application shall not store private keys in plaintext files. + +- Priority: P0 +- Verification: Audit + +**SysRS-213**: The Chanora application shall not write passwords to logs. + +- Priority: P0 +- Verification: Audit + +**SysRS-214**: The Chanora application shall not imply official TeamSpeak affiliation in UI, documentation, or release metadata. + +- Priority: P0 +- Verification: Audit + +**SysRS-215**: The Chanora application shall not automatically upload diagnostic information in MVP. + +- Priority: P0 +- Verification: Audit + +**SysRS-216**: The Chanora application shall comply with iOS background execution policies. + +- Priority: P0 +- Verification: Audit + +**SysRS-217**: The Chanora application shall comply with Android foreground service requirements for active voice sessions. + +- Priority: P0 +- Verification: Audit + +**SysRS-218**: The MVP shall not require Chanora-operated backend infrastructure for voice, channels, or text. + +- Priority: P0 +- Verification: Review + + +## 22. Assumptions + + +**SysRS-219**: The selected `tsclientlib` version can support or be extended to support required MVP protocol features. + +- Priority: P0 +- Verification: Review + +**SysRS-220**: Required audio processing features can be implemented through a combination of platform-native APIs, Rust DSP, and external audio processing libraries. + +- Priority: P0 +- Verification: Review + +**SysRS-221**: Mobile foreground voice behavior is sufficient for MVP. + +- Priority: P0 +- Verification: Review + +**SysRS-222**: Background voice behavior will remain constrained by iOS and Android platform policies. + +- Priority: P0 +- Verification: Review + +**SysRS-223**: External compatible server administrators are responsible for server availability, permissions, and configuration. + +- Priority: P0 +- Verification: Review + +**SysRS-224**: End users are responsible for providing valid server connection details and network access. + +- Priority: P0 +- Verification: Review + + +## 23. Out of Scope for MVP + + +**SysRS-225**: The MVP shall not include TeamSpeak-compatible server hosting functionality. + +- Priority: P0 +- Verification: Review + +**SysRS-226**: The MVP shall not include full server administration functionality. + +- Priority: P0 +- Verification: Review + +**SysRS-227**: The MVP shall not include a complete permission editor. + +- Priority: P0 +- Verification: Review + +**SysRS-228**: The MVP shall not include a plugin system. + +- Priority: P0 +- Verification: Review + +**SysRS-229**: The MVP shall not include 3D positional audio unless explicitly reprioritized. + +- Priority: P1 +- Verification: Review + +**SysRS-230**: The MVP shall not include advanced whisper list management unless explicitly reprioritized. + +- Priority: P1 +- Verification: Review + +**SysRS-231**: The MVP shall not include Server Query administration tools. + +- Priority: P0 +- Verification: Review + +**SysRS-232**: The MVP shall not include automatic cloud sync of bookmarks, identities, settings, or diagnostics. + +- Priority: P1 +- Verification: Review + + +## 24. Verification and Validation Requirements + + +**SysRS-233**: The project shall maintain a requirements traceability matrix from SysRS requirements through SysDes, SRS, SAD, SDD, and Verification evidence. + +- Priority: P1 +- Verification: Review + +**SysRS-234**: The project shall verify protocol compatibility through a protocol probe tool. + +- Priority: P0 +- Verification: Demo + +**SysRS-235**: The project shall verify state synchronization through reducer tests and event replay tests. + +- Priority: P1 +- Verification: Test + +**SysRS-236**: The project shall verify audio capture, processing, encode/decode, and playback through audio loopback and processing tests. + +- Priority: P1 +- Verification: Test + +**SysRS-237**: The project shall verify secure storage behavior on every target platform before public release. + +- Priority: P1 +- Verification: Audit + +**SysRS-238**: The project shall verify diagnostic redaction before enabling diagnostic export for external testers. + +- Priority: P1 +- Verification: Audit + +**SysRS-239**: The project shall verify release packaging on every target platform before production release. + +- Priority: P1 +- Verification: Demo + +**SysRS-240**: The project shall verify that public wording does not imply official TeamSpeak affiliation. + +- Priority: P0 +- Verification: Audit + + +## 25. MVP Acceptance Requirements + + +**SysRS-241**: The MVP shall connect to a TeamSpeak 3-compatible server using `tsclientlib`. + +- Priority: P0 +- Verification: Demo + +**SysRS-242**: The MVP shall display the server channel tree. + +- Priority: P0 +- Verification: Demo + +**SysRS-243**: The MVP shall display online clients. + +- Priority: P0 +- Verification: Demo + +**SysRS-244**: The MVP shall allow the user to join a voice channel. + +- Priority: P0 +- Verification: Demo + +**SysRS-245**: The MVP shall send voice. + +- Priority: P0 +- Verification: Demo + +**SysRS-246**: The MVP shall receive voice. + +- Priority: P0 +- Verification: Demo + +**SysRS-247**: The MVP shall support microphone mute. + +- Priority: P0 +- Verification: Demo + +**SysRS-248**: The MVP shall support output deaf. + +- Priority: P0 +- Verification: Demo + +**SysRS-249**: The MVP shall support push-to-talk. + +- Priority: P0 +- Verification: Demo + +**SysRS-250**: The MVP shall support Echo Canceller. + +- Priority: P0 +- Verification: Demo + +**SysRS-251**: The MVP shall support Automatic Gain Control. + +- Priority: P0 +- Verification: Demo + +**SysRS-252**: The MVP shall support Noise Suppression. + +- Priority: P0 +- Verification: Demo + +**SysRS-253**: The MVP shall support High-Pass Filter. + +- Priority: P0 +- Verification: Demo + +**SysRS-254**: The MVP shall send and receive channel text messages. + +- Priority: P0 +- Verification: Demo + +**SysRS-255**: The MVP shall save and reuse server bookmarks. + +- Priority: P0 +- Verification: Demo + +**SysRS-256**: The MVP shall use secure storage for sensitive data. + +- Priority: P0 +- Verification: Audit + +**SysRS-257**: The MVP shall export redacted diagnostic logs. + +- Priority: P1 +- Verification: Demo + + +--- + +## 30. UI/UX, Material 3, Platform, and Internationalization Requirements + +This section extends the system requirement baseline for the Chanora application system. These requirements are system-level because they define externally observable application behavior, accessibility behavior, platform behavior, multilingual behavior, deployment-region behavior, and interoperability constraints. + +**SysRS-258**: The Chanora application system shall use Material 3 as the baseline design system for the Flutter client user interface. + +- Priority: P0 +- Verification: Review, Inspection + +**SysRS-259**: The Chanora application system shall define a Chanora-specific design system above Material 3 for voice, connection, channel, latency, diagnostics, accessibility, and platform-adaptive states. + +- Priority: P0 +- Verification: Review, Inspection + +**SysRS-260**: The Chanora application system shall support compact, medium, and expanded window classes for responsive client layout. + +- Priority: P0 +- Verification: Test, Demo + +**SysRS-261**: The Chanora application system shall preserve visibility of connection status and primary voice controls across compact, medium, and expanded layouts. + +- Priority: P0 +- Verification: Test, Demo + +**SysRS-262**: The Chanora application system shall provide screen-reader semantics for critical interactive controls and critical status indicators. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-263**: The Chanora application system shall not communicate critical connection, voice, latency, permission, or error states by color alone. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-264**: The Chanora application system shall support keyboard focus traversal and visible focus indication on desktop-class and tablet keyboard environments. + +- Priority: P1 +- Verification: Test + +**SysRS-265**: The Chanora application system shall keep critical controls reachable when the user increases text size using platform accessibility settings. + +- Priority: P0 +- Verification: Test + +**SysRS-266**: The Chanora application system shall respect platform safe areas, display cutouts, system bars, virtual keyboards, and desktop window insets. + +- Priority: P0 +- Verification: Test + +**SysRS-267**: The Chanora application system shall provide platform-appropriate handling for Android system back navigation, including predictive-back-compatible behavior where supported by the platform. + +- Priority: P1 +- Verification: Test + +**SysRS-268**: The Chanora application system shall provide platform-appropriate handling for iOS navigation gestures, safe areas, keyboard avoidance, haptics, and system permission presentation. + +- Priority: P1 +- Verification: Test + +**SysRS-269**: The Chanora application system shall support localization of user-visible client application strings. + +- Priority: P0 +- Verification: Inspection, Test + +**SysRS-270**: The Chanora application system shall externalize user-visible strings from source code into localization resources or an equivalent localization mechanism. + +- Priority: P0 +- Verification: Inspection + +**SysRS-271**: The Chanora application system shall support English as the baseline product language. + +- Priority: P0 +- Verification: Review, Test + +**SysRS-272**: The Chanora application system shall support adding additional product languages without changing protocol, audio, state synchronization, or storage architecture. + +- Priority: P1 +- Verification: Review, Inspection + +**SysRS-273**: The Chanora application system shall preserve and display Unicode server names, channel names, client nicknames, and text messages received from compatible servers. + +- Priority: P0 +- Verification: Test + +**SysRS-274**: The Chanora application system shall use UTF-8 internally for text exchanged between Flutter, Rust Core, local storage, diagnostics, and protocol-facing adapters unless a platform API requires conversion at the boundary. + +- Priority: P0 +- Verification: Inspection, Test + +**SysRS-275**: The Chanora application system shall perform encoding conversion at explicit boundary adapters when external server, operating system, or platform APIs use a different text representation. + +- Priority: P1 +- Verification: Inspection, Test + +**SysRS-276**: The Chanora application system shall not corrupt or drop multilingual Unicode content in logs or diagnostic exports, except where redaction intentionally removes sensitive content. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-277**: The Chanora application system shall support bidirectional text display for user-visible localized strings and server-provided text where the platform text engine supports it. + +- Priority: P2 +- Verification: Test + +**SysRS-278**: The Chanora application system shall support locale-aware formatting for dates, times, numbers, and diagnostic timestamps where those values are user-visible. + +- Priority: P1 +- Verification: Test + +**SysRS-279**: The Chanora application system shall support fallback behavior when a translation key is missing. + +- Priority: P0 +- Verification: Test + +**SysRS-280**: The Chanora application system shall keep machine-readable diagnostic fields stable and language-neutral while allowing user-facing diagnostic descriptions to be localized. + +- Priority: P1 +- Verification: Inspection, Test + +**SysRS-281**: The Chanora application system shall separate product localization from server-provided content; server-provided names and messages shall be displayed as content, not translated by the client. + +- Priority: P0 +- Verification: Review, Test + +**SysRS-282**: The Chanora application system shall support accessibility labels and localization for icon-only controls. + +- Priority: P0 +- Verification: Test, Audit + +**SysRS-283**: The Chanora application system shall define a UI/UX guideline document as a downstream non-normative design baseline derived from this SysRS and SysDes. + +- Priority: P1 +- Verification: Review + +**SysRS-284**: The Chanora application system shall define design tokens for color, typography, spacing, shape, elevation, motion, density, connection state, voice state, latency state, and diagnostics state. + +- Priority: P1 +- Verification: Review, Inspection + +**SysRS-285**: The Chanora application system shall maintain traceability across the hierarchy `SysRS -> SysDes -> SRS -> SAD -> SDD` without allowing SRS, SAD, or SDD to bypass the immediately preceding lifecycle layer. + +- Priority: P0 +- Verification: Review, Inspection + + +## 26. Glossary + +| Term | Definition | +|---|---| +| Chanora | Cross-platform voice client application | +| Application system | The Chanora application plus runtime environment elements required for operation | +| Client device | User device running the Chanora application | +| Runtime environment | OS services, hardware, network, and external dependencies used by the application | +| External compatible server | TeamSpeak 3-compatible voice server not operated by Chanora | +| `tsclientlib` | Rust protocol library used for TeamSpeak-compatible protocol integration | +| Rust Core | Shared Rust layer for protocol, state, audio, storage, diagnostics, and business logic | +| Flutter UI | Cross-platform UI layer | +| Platform adapter | OS-specific integration layer for audio, permissions, secure storage, lifecycle, and packaging | +| Echo Canceller | Audio processing feature that reduces playback audio leaking into microphone input | +| Automatic Gain Control | Audio processing feature that normalizes microphone input gain | +| Noise Suppression | Audio processing feature that reduces background noise | +| High-Pass Filter | Audio processing feature that reduces low-frequency noise | + +--- + +## 27. SysRS Coverage Matrix + +| SysRS Area | Requirement Coverage | +|---|---| +| Product and application-system scope | SysRS-001 through SysRS-010 | +| Stakeholder and user environment | SysRS-011 through SysRS-015 | +| System boundary and external dependencies | SysRS-016 through SysRS-023 | +| Application components | SysRS-024 through SysRS-034 | +| Client device and hardware environment | SysRS-035 through SysRS-047 | +| Operating system services | SysRS-048 through SysRS-058 | +| Audio hardware and audio processing | SysRS-059 through SysRS-074 | +| Network environment | SysRS-075 through SysRS-087 | +| External compatible servers | SysRS-088 through SysRS-101 | +| Application functional behavior | SysRS-102 through SysRS-120 | +| Protocol integration | SysRS-121 through SysRS-128 | +| State synchronization | SysRS-129 through SysRS-139 | +| Data and storage | SysRS-140 through SysRS-152 | +| Security and privacy | SysRS-153 through SysRS-167 | +| Diagnostics and operations | SysRS-168 through SysRS-177 | +| Non-functional requirements | SysRS-178 through SysRS-191 | +| Deployment and release environment | SysRS-192 through SysRS-199 | +| Interfaces | SysRS-200 through SysRS-210 | +| Constraints | SysRS-211 through SysRS-218 | +| Assumptions | SysRS-219 through SysRS-224 | +| Out of scope for MVP | SysRS-225 through SysRS-232 | +| Verification and validation | SysRS-233 through SysRS-240 | +| MVP acceptance requirements | SysRS-241 through SysRS-257 | +| UI/UX, Material 3, platform, i18n, and strict traceability | SysRS-258 through SysRS-285 | + + +--- + +## 28. Open Decisions + +| Decision ID | Area | Question | Default Recommendation | +|---|---|---|---| +| SysRS-DEC-001 | Mobile | Minimum supported iOS version | Decide before iOS implementation | +| SysRS-DEC-002 | Mobile | Minimum supported Android version | Decide before Android implementation | +| SysRS-DEC-003 | Connection | Multiple simultaneous server connections in MVP | Defer unless required | +| SysRS-DEC-004 | Audio | Default Echo Canceller state per platform | Enable only after validation | +| SysRS-DEC-005 | Audio | Default AGC state per platform | Enable with conservative settings | +| SysRS-DEC-006 | Audio | Default Noise Suppression state per platform | Enable if quality is acceptable | +| SysRS-DEC-007 | Audio | Default High-Pass Filter cutoff frequency | 80 Hz initial default | +| SysRS-DEC-008 | Audio | Platform-native vs Rust audio processing per platform | Prefer best quality and lowest latency | +| SysRS-DEC-009 | Legal | Official SDK licensing review before public distribution | Recommended | +| SysRS-DEC-010 | Storage | Embedded database choice | SQLite or equivalent | +| SysRS-DEC-011 | Bridge | Rust/Flutter bridge choice | `flutter_rust_bridge` initially | + +--- + +## 29. Revision History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-13 | Initial application-system requirements draft | +| 0.2.0 | 2026-05-13 | Converted software-only direction into application-system SysRS | +| 0.3.0 | 2026-05-13 | Corrected terminology: Chanora is an application; SysRS covers the application system and runtime environment | +| 0.4.0 | 2026-05-13 | Removed old SYS requirement references and standardized requirement IDs as SysRS-XXX | +| 0.5.0 | 2026-05-13 | Moved implementation and design documents out of input references into downstream non-normative documents | +| 0.6.0 | 2026-05-13 | Corrected downstream documentation lifecycle to SysRS -> SysDes -> SRS -> SAD -> SDD -> Verification | +| 0.7.0 | 2026-05-14 | Added Material 3, adaptive UI, accessibility, platform behavior, internationalization, Unicode, and strict lifecycle traceability requirements | + +--- + +## 31. Platform Baseline, Release Policy, and Architecture Decision Requirements + +This section converts the baseline product decisions into auditable system-level requirements. + +**SysRS-286**: The Chanora application system shall support iOS runtime deployment on iOS 13 or later unless Flutter, plugin, audio, or platform constraints require raising the minimum version. + +- Priority: P0 +- Verification: Review, Platform Test + +**SysRS-287**: For Apple App Store Connect upload on or after 2026-04-28, the Chanora iOS/iPadOS build shall be produced with Xcode 26 or later using the iOS 26 / iPadOS 26 SDK or later, unless Apple publishes a newer applicable upload requirement before upload. + +- Priority: P0 +- Verification: Release Inspection + +**SysRS-288**: The Chanora Android application shall support Android API 24 or later as the minimum runtime baseline unless Flutter, plugin, audio, or platform constraints require raising the minimum version. + +- Priority: P0 +- Verification: Review, Platform Test + +**SysRS-289**: For Google Play submission, the Chanora Android build shall target the Android API level required by Google Play on the upload date. + +- Priority: P0 +- Verification: Release Inspection + +**SysRS-290**: The Chanora MVP shall support one active server connection per client instance; multiple simultaneous active server connections shall be deferred outside MVP scope. + +- Priority: P0 +- Verification: Review, System Test + +**SysRS-291**: The Chanora MVP shall enable Echo Canceller, Automatic Gain Control, Noise Suppression, and High-Pass Filter by default where supported and stable, while allowing user or platform policy to disable supported processing where applicable. + +- Priority: P0 +- Verification: Audio Test, Review + +**SysRS-292**: The Chanora application system shall prefer platform-native audio processing for MVP where available and stable, with Rust/WebRTC-style audio processing retained as a controlled fallback or later architecture option. + +- Priority: P1 +- Verification: Architecture Review, Audio Test + +**SysRS-293**: The Chanora application system shall use SQLite or an equivalent embedded local database for non-secret local state, while storing secrets only through platform secure storage. + +- Priority: P0 +- Verification: Storage Test, Security Audit + +**SysRS-294**: The Chanora application system shall use a stable typed Flutter/Rust bridge with generated or schema-controlled DTOs; `flutter_rust_bridge` is the default candidate unless prototype evidence selects a better option. + +- Priority: P0 +- Verification: Architecture Review, Integration Test + +**SysRS-295**: The Chanora MVP shall not perform automatic diagnostic upload, automatic telemetry upload, or automatic crash reporting unless a later approved decision updates privacy, security, legal, release, and verification documents. + +- Priority: P0 +- Verification: Privacy Review, Security Audit + + +## 32. Change History Addendum + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Added platform runtime baselines, Apple SDK submission gate, Android Play target gate, MVP connection scope, audio defaults, audio implementation path, local database, bridge, and diagnostics/crash reporting policy requirements. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate effective date to 2026-04-28 and propagated distinction between runtime deployment target and build-SDK upload gate. | diff --git a/docs/security/dependency-and-supply-chain-report.md b/docs/security/dependency-and-supply-chain-report.md new file mode 100644 index 0000000..c7ef25e --- /dev/null +++ b/docs/security/dependency-and-supply-chain-report.md @@ -0,0 +1,126 @@ +# Sec Dependency And Supply Chain Report V0.9.2.2.1 + +**Document type:** Security / Dependency and Supply Chain Report +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/security/dependency-and-supply-chain-report.md` --- + +## 1. Purpose + +This report records Chanora dependency inventory, license review, vulnerability review, SBOM status, and supply-chain release readiness. + +## 2. Dependency Scope + +| Ecosystem | In scope | +|---|---| +| Flutter / Dart | `pubspec.yaml`, transitive packages, Flutter SDK version | +| Rust | `Cargo.toml`, `Cargo.lock`, crates, features | +| Protocol library | `tsclientlib` and related crates/dependencies | +| Native audio | Platform audio libraries, native build dependencies, bindings | +| Build tooling | CI actions, build scripts, code generators | +| Packaging | Platform packaging tools and signing tools | + +## 3. Required Outputs + +| Output | Required before external release | +|---|---| +| Dependency inventory | Yes | +| License report | Yes | +| Vulnerability scan report | Yes | +| SBOM | Yes | +| Critical/high vulnerability disposition | Yes | +| Unknown license disposition | Yes | +| Build provenance record | Yes | +| Artifact hash record | Yes | + +## 4. Dependency Inventory + +| Component | Ecosystem | Version | License | Source | Risk | Notes | +|---|---|---|---|---|---|---| +| Flutter SDK | Flutter | TBD | TBD | TBD | TBD | TBD | +| Dart packages | Dart | TBD | TBD | TBD | TBD | TBD | +| Rust toolchain | Rust | TBD | TBD | TBD | TBD | TBD | +| Rust crates | Rust | TBD | TBD | TBD | TBD | TBD | +| `tsclientlib` | Rust/protocol | TBD | TBD | TBD | TBD | TBD | +| Native audio dependencies | Native | TBD | TBD | TBD | TBD | TBD | +| CI actions/tools | Build | TBD | TBD | TBD | TBD | TBD | + +## 5. License Review + +| License category | Policy | +|---|---| +| Permissive licenses | Generally acceptable after review | +| Copyleft licenses | Requires legal review before release | +| Unknown licenses | Release blocker until resolved | +| Proprietary dependencies | Requires explicit approval | +| Incompatible licenses | Release blocker unless removed or legal waiver approved | + +## 6. Vulnerability Review + +| Finding ID | Dependency | Severity | CVE / advisory | Status | Disposition | +|---|---|---|---|---|---| +| TBD | TBD | TBD | TBD | TBD | TBD | + +## 7. SBOM + +| Field | Value | +|---|---| +| SBOM format | TBD: SPDX / CycloneDX / other | +| SBOM tool | TBD | +| SBOM file | TBD | +| SBOM generation date | TBD | +| SBOM reviewer | TBD | + +## 8. Build Provenance + +| Field | Value | +|---|---| +| Git commit SHA | TBD | +| Git tag | TBD | +| CI pipeline ID | TBD | +| Build environment | TBD | +| Artifact hashes | TBD | +| Signing identity | TBD | +| Reproducibility status | TBD | + +## 9. Release Gate + +| Gate | Required result | +|---|---| +| Critical vulnerabilities | None open without approved waiver | +| High vulnerabilities | None open without approved waiver | +| Unknown licenses | None open without approved waiver | +| SBOM | Generated and archived | +| License report | Reviewed | +| Dependency report | Approved | + +## 10. Approval + +| Role | Name | Decision | Date | +|---|---|---|---| +| Security Reviewer | TBD | Pending | TBD | +| Legal Reviewer | TBD | Pending | TBD | +| Engineering Owner | TBD | Pending | TBD | +| Release Manager | TBD | Pending | TBD | + +## 11. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial dependency and supply-chain report template. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/security/diagnostic-redaction-audit-report.md b/docs/security/diagnostic-redaction-audit-report.md new file mode 100644 index 0000000..ae7628b --- /dev/null +++ b/docs/security/diagnostic-redaction-audit-report.md @@ -0,0 +1,103 @@ +# Sec Diagnostic Redaction Audit Report V0.9.2.2.1 + +**Document type:** Security / Diagnostic Redaction Audit Report +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/security/diagnostic-redaction-audit-report.md` --- + +## 1. Purpose + +This report records evidence that Chanora logs and diagnostic exports do not leak sensitive information. + +## 2. Sensitive Data Redaction Policy + +| Data category | Default diagnostic behavior | +|---|---| +| Server password | Must redact | +| Identity private key / identity secret | Must redact | +| Authentication tokens if later added | Must redact | +| Secure-storage keys | Must redact | +| Server address | Redact or minimize according to release policy | +| Channel names | Redact or include only with explicit user consent | +| Client nicknames | Redact or include only with explicit user consent | +| Chat messages | Exclude by default unless a future explicit opt-in policy is approved | +| Local file paths | Minimize or redact user-identifying segments | +| Device IDs | Redact or hash if collected | +| IP addresses | Redact or minimize according to release policy | + +## 3. Diagnostic Surfaces + +| Surface | Risk | Required control | +|---|---|---| +| Application log | Secret leakage | Redaction filter and structured logging discipline | +| Protocol log | Hostile or sensitive server content | Redaction and length limits | +| Audio diagnostics | Device privacy | Device name minimization if needed | +| Export bundle | Aggregated sensitive data | Redaction audit before release | +| Error report | Stack trace or secret context | User-safe error mapping | +| User support copy/paste | Over-sharing | Explicit review and confirmation | + +## 4. Redaction Test Matrix + +| Test ID | Input | Expected output | Status | Evidence | +|---|---|---|---|---| +| REDACT-TC-001 | Server password in connection data | Password replaced by `[REDACTED]` | TBD | TBD | +| REDACT-TC-002 | Identity secret in storage error | Secret absent | TBD | TBD | +| REDACT-TC-003 | Server URL with password-like field | Secret part redacted | TBD | TBD | +| REDACT-TC-004 | Chat text in diagnostic export | Excluded by default | TBD | TBD | +| REDACT-TC-005 | Channel name with Unicode | Preserved only if permitted; otherwise redacted safely | TBD | TBD | +| REDACT-TC-006 | Nickname with Unicode | Preserved only if permitted; otherwise redacted safely | TBD | TBD | +| REDACT-TC-007 | Local file path | User-identifying segments redacted or minimized | TBD | TBD | +| REDACT-TC-008 | Diagnostic bundle with mixed sensitive fields | All sensitive fields redacted | TBD | TBD | +| REDACT-TC-009 | Long hostile protocol string | Truncated or safely escaped | TBD | TBD | +| REDACT-TC-010 | Multilingual safe diagnostic text | Unicode preserved | TBD | TBD | + +## 5. Export Bundle Contents + +| Bundle item | Included? | Redaction rule | Status | +|---|---|---|---| +| App version | Yes | None | TBD | +| Build number | Yes | None | TBD | +| Platform info | Yes | Minimize device details | TBD | +| Connection state | Yes | No secrets | TBD | +| Server address | TBD | Redact/minimize | TBD | +| Channel tree | TBD | Redact/minimize | TBD | +| Chat history | No by default | Exclude unless explicit policy changes | TBD | +| Logs | Yes | Redacted | TBD | +| Audio diagnostics | Yes | No audio content | TBD | +| Secure storage data | No | Never include | TBD | + +## 6. Findings + +| Finding ID | Severity | Description | Status | Owner | +|---|---|---|---|---| +| TBD | TBD | TBD | TBD | TBD | + +## 7. Approval + +| Role | Name | Decision | Date | +|---|---|---|---| +| Security Reviewer | TBD | Pending | TBD | +| Privacy Reviewer | TBD | Pending | TBD | +| QA / Verification Owner | TBD | Pending | TBD | + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial diagnostic redaction audit report template. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/security/secure-storage-audit-report.md b/docs/security/secure-storage-audit-report.md new file mode 100644 index 0000000..88b5e4f --- /dev/null +++ b/docs/security/secure-storage-audit-report.md @@ -0,0 +1,88 @@ +# Sec Secure Storage Audit Report V0.9.2.2.1 + +**Document type:** Security / Secure Storage Audit Report +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/security/secure-storage-audit-report.md` --- + +## 1. Purpose + +This report records evidence that Chanora stores secrets using platform secure storage mechanisms and does not store sensitive secrets in plaintext local storage. + +## 2. Secret Classification + +| Secret ID | Secret | Required storage | +|---|---|---| +| SEC-STORE-001 | Identity private key / identity secret | Platform secure storage | +| SEC-STORE-002 | Server password | Platform secure storage | +| SEC-STORE-003 | Authentication tokens if later added | Platform secure storage | +| SEC-STORE-004 | Encryption keys if later added | Platform secure storage | + +## 3. Platform Audit Matrix + +| Platform | Secure storage mechanism | Test status | Evidence | Result | +|---|---|---|---|---| +| Windows | TBD | TBD | TBD | TBD | +| macOS | TBD | TBD | TBD | TBD | +| Linux | TBD | TBD | TBD | TBD | +| Android | TBD | TBD | TBD | TBD | +| iOS | TBD | TBD | TBD | TBD | + +## 4. Audit Checks + +| Check ID | Check | Expected result | Status | Evidence | +|---|---|---|---|---| +| SS-AUD-001 | Identity secret is not stored in local DB. | Pass | TBD | TBD | +| SS-AUD-002 | Server password is not stored in local DB. | Pass | TBD | TBD | +| SS-AUD-003 | Secret values are not written to application logs. | Pass | TBD | TBD | +| SS-AUD-004 | Secret values are not included in diagnostic export. | Pass | TBD | TBD | +| SS-AUD-005 | Secure storage failure returns safe error. | Pass | TBD | TBD | +| SS-AUD-006 | Secret deletion removes secure-storage entry. | Pass | TBD | TBD | +| SS-AUD-007 | Platform-specific secure storage is documented. | Pass | TBD | TBD | +| SS-AUD-008 | Migration or import path does not expose secrets. | Pass | TBD | TBD | + +## 5. Test Cases + +| Test ID | Platform | Procedure | Expected result | Actual result | Status | +|---|---|---|---|---|---| +| SS-TC-001 | Windows | Save identity secret, inspect local DB/logs/export. | Secret absent from DB/logs/export. | TBD | TBD | +| SS-TC-002 | macOS | Save identity secret, inspect local DB/logs/export. | Secret absent from DB/logs/export. | TBD | TBD | +| SS-TC-003 | Linux | Save identity secret, inspect local DB/logs/export. | Secret absent from DB/logs/export. | TBD | TBD | +| SS-TC-004 | Android | Save identity secret, inspect app storage/logs/export. | Secret absent from DB/logs/export. | TBD | TBD | +| SS-TC-005 | iOS | Save identity secret, inspect app storage/logs/export. | Secret absent from DB/logs/export. | TBD | TBD | + +## 6. Findings + +| Finding ID | Severity | Description | Status | Owner | +|---|---|---|---|---| +| TBD | TBD | TBD | TBD | TBD | + +## 7. Approval + +| Role | Name | Decision | Date | +|---|---|---|---| +| Security Reviewer | TBD | Pending | TBD | +| Platform Owner | TBD | Pending | TBD | +| QA / Verification Owner | TBD | Pending | TBD | + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial secure storage audit report template. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/security/security-privacy-legal-guideline.md b/docs/security/security-privacy-legal-guideline.md new file mode 100644 index 0000000..2209ea2 --- /dev/null +++ b/docs/security/security-privacy-legal-guideline.md @@ -0,0 +1,89 @@ +# Sec Security Privacy Legal Guideline V0.9.2.2.1 + +**Document type:** Security / Privacy / Legal Guideline +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/security/security-privacy-legal-guideline.md` --- + +## 1. Purpose + +This guideline defines the required security, privacy, and legal review documents that must be completed before Chanora is released outside a controlled internal engineering environment. + +A public or external release shall not rely only on SysRS, SysDes, SRS, SAD, SDD, and verification documents. It also requires security, privacy, dependency, and legal evidence. + +## 2. Required Pre-Release Documents + +| Document | Required before | Purpose | +|---|---|---| +| `docs/security/threat-model.md` | External Beta or public release | Identify attack surfaces, assets, trust boundaries, threats, and mitigations. | +| `docs/security/secure-storage-audit-report.md` | Any release storing secrets | Prove platform secure storage behavior. | +| `docs/security/diagnostic-redaction-audit-report.md` | Any release with diagnostics export/logs | Prove diagnostics and logs do not leak sensitive information. | +| `docs/security/dependency-and-supply-chain-report.md` | Any external release | Prove dependency inventory, licenses, vulnerability status, and SBOM readiness. | +| `docs/privacy/privacy-policy.md` | Any public or store release | Explain data handling, local storage, permissions, diagnostics, and upload behavior. | +| `docs/legal/trademark-and-attribution-review.md` | Any public or store release | Confirm non-affiliation wording, OSS attribution, and trademark risk review. | + +## 3. Release Gate Rule + +| Release type | Required security/privacy/legal gate | +|---|---| +| Internal Alpha | Security and privacy draft checklist acceptable if not publicly distributed. | +| External Beta | Threat model, secure storage audit, diagnostic redaction audit, dependency report, privacy draft, legal review draft required. | +| MVP Public | All listed documents must be completed and approved. | +| Store Release | All listed documents must be completed, approved, and aligned with store metadata. | + +## 4. Security Review Principles + +| Principle | Required behavior | +|---|---| +| Secret minimization | Store only secrets needed for user-approved functionality. | +| Local-first diagnostics | Diagnostic export requires explicit user action unless a future policy says otherwise. | +| Redaction by default | Secrets and sensitive server/user data are redacted before export. | +| Boundary validation | Protocol, platform, and file boundaries validate or sanitize external input. | +| Least privilege | Platform permissions are requested only when needed and explained to users. | +| Dependency accountability | Flutter packages, Rust crates, native libraries, and protocol libraries are inventoried. | +| Release evidence | Security and privacy claims require evidence, not only design intent. | + +## 5. Required Product Owner Decisions + +| Decision | Owner | +|---|---| +| Whether diagnostics are local-only or upload-capable | Product Owner + Legal | +| Whether crash reporting is included | Product Owner + Legal + Security | +| Which release channels are used | Product Owner | +| Public wording for non-affiliation statement | Legal / Compliance | +| Whether any telemetry is collected | Product Owner + Legal | +| Minimum supported platforms for secure storage audit | Product Owner + Engineering | + +## 6. Required Engineering Evidence + +| Evidence | Owner | +|---|---| +| Secure storage test results per platform | Platform / Security | +| Diagnostic redaction test results | Security / QA | +| Dependency inventory and license output | Engineering / Legal | +| SBOM output | Engineering / Security | +| Vulnerability scan result | Security / Engineering | +| Permission list and justification | Platform / Product | +| Threat model review result | Security / Architecture | + +## 7. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial security, privacy, and legal pre-release guideline. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/security/threat-model.md b/docs/security/threat-model.md new file mode 100644 index 0000000..0d407b1 --- /dev/null +++ b/docs/security/threat-model.md @@ -0,0 +1,138 @@ +# Sec Threat Model V0.9.2.2.1 + +**Document type:** Security / Threat Model +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Repo path:** `docs/security/threat-model.md` --- + +## 1. Purpose + +This document identifies Chanora security assets, trust boundaries, attack surfaces, threat scenarios, mitigations, and residual risks. + +This document must be completed and approved before public or external release. + +## 2. Security Scope + +In scope: + +- Identity private keys and identity material +- Server passwords +- Saved bookmarks and recent server entries +- Local database +- Secure storage +- Diagnostic logs and export bundles +- Protocol input from compatible servers +- Text messages, channel names, server names, and nicknames +- Audio device access and microphone permission +- Platform permission flows +- Dependency and supply-chain risks +- Flutter/Rust bridge boundary +- Local file export/import surfaces + +Out of scope unless later added: + +- Cloud account sync +- Server hosting infrastructure operated by Chanora +- Telemetry backend +- Crash reporting backend +- Payment processing + +## 3. Assets + +| Asset ID | Asset | Sensitivity | Required protection | +|---|---|---|---| +| SEC-ASSET-001 | Identity private key / identity secret | Critical | Store only in platform secure storage; never log. | +| SEC-ASSET-002 | Server password | Critical | Store only in platform secure storage; redact from diagnostics. | +| SEC-ASSET-003 | Server address / bookmark | Sensitive | Store locally; redact or minimize in diagnostic export. | +| SEC-ASSET-004 | Nickname / user identity display name | Personal / user-provided | Preserve Unicode; avoid unnecessary upload. | +| SEC-ASSET-005 | Channel names and server names | Potentially sensitive | Treat as user/server content; redact where configured. | +| SEC-ASSET-006 | Chat text | Sensitive user/server content | Do not upload automatically; redact from diagnostics by default unless user explicitly includes. | +| SEC-ASSET-007 | Diagnostic bundle | Sensitive aggregate | Redact secrets; user-initiated export only. | +| SEC-ASSET-008 | Local database | Sensitive | Protect via OS file permissions; avoid plaintext secrets. | +| SEC-ASSET-009 | Logs | Sensitive | Redact secrets and avoid verbose sensitive content. | +| SEC-ASSET-010 | Audio stream | Sensitive real-time data | Do not persist audio unless explicitly designed later. | +| SEC-ASSET-011 | Dependency graph | Supply-chain-sensitive | Track licenses, vulnerabilities, and source integrity. | + +## 4. Trust Boundaries + +| Boundary ID | Boundary | Risk | +|---|---|---| +| TB-001 | User input to Flutter UI | Malformed or hostile input. | +| TB-002 | Flutter to Rust bridge | DTO validation and error mapping required. | +| TB-003 | Rust Core to protocol adapter | Protocol events and external inputs must be normalized. | +| TB-004 | Protocol adapter to external compatible server | Untrusted network/server input. | +| TB-005 | Rust/Flutter to platform secure storage | Platform-specific failure modes. | +| TB-006 | App to local database/file system | File tampering, data leakage, permissions. | +| TB-007 | Diagnostics export to user-controlled destination | Sensitive data leakage. | +| TB-008 | Audio device boundary | Permission and device-route privacy. | +| TB-009 | Dependency supply chain | Vulnerable or malicious dependencies. | + +## 5. Attack Surfaces + +| Surface ID | Attack surface | Example threats | +|---|---|---| +| AS-001 | Connection form | Credential capture in logs, malformed host input. | +| AS-002 | Protocol input | Malformed packets, hostile names/messages, state desync. | +| AS-003 | Bridge DTOs | Invalid commands, unexpected event payloads. | +| AS-004 | Local database | Tampering, unauthorized read. | +| AS-005 | Secure storage | Platform fallback failure or incorrect secret classification. | +| AS-006 | Diagnostics export | Secret leakage, excessive server/user information. | +| AS-007 | Logs | Password or identity leakage. | +| AS-008 | Audio permissions | Unclear microphone use or unintended capture. | +| AS-009 | Dependency ecosystem | Vulnerable packages or license incompatibility. | +| AS-010 | Store/package distribution | Tampered artifacts or signing issues. | + +## 6. Threat Scenarios and Mitigations + +| Threat ID | Scenario | Impact | Mitigation | Verification | +|---|---|---|---|---| +| THR-001 | Server password is logged during connection failure. | Credential leakage. | Redaction filters; never log secret fields. | Diagnostic redaction audit. | +| THR-002 | Identity private key is stored in local DB. | Identity compromise. | Secure storage classification and audit. | Secure storage audit. | +| THR-003 | Diagnostic export includes server password or identity secret. | Credential leakage. | Export redaction and denylist/allowlist design. | Redaction audit. | +| THR-004 | Hostile server sends malformed Unicode or extremely long names. | Crash, UI corruption, log injection. | Boundary validation, length limits, safe rendering. | Protocol fuzz/sanitization tests. | +| THR-005 | Protocol event causes inconsistent UI state. | Wrong user/channel state. | State reducer validation and snapshot recovery. | SWE.5/SWE.6 tests. | +| THR-006 | Dependency has known critical vulnerability. | Compromise or exploit risk. | Dependency scan and release gate. | Supply-chain report. | +| THR-007 | OSS license is incompatible with release model. | Legal/compliance risk. | License inventory and legal review. | Dependency/license report. | +| THR-008 | Microphone permission is unclear to user. | Privacy risk. | Permission explanation and privacy policy. | Privacy/legal review. | +| THR-009 | Logs contain private channel or nickname data by default. | Privacy leakage. | Minimize logs; redact or hash sensitive content. | Diagnostics audit. | +| THR-010 | Build artifact is not traceable to commit. | Supply-chain/release integrity risk. | Release record with commit, tag, build number, hashes. | Go/No-Go record. | + +## 7. Residual Risks + +| Risk ID | Risk | Disposition | +|---|---|---| +| RISK-001 | External compatible servers may expose untrusted content. | Accept with boundary validation and safe rendering. | +| RISK-002 | Platform secure storage behavior differs by OS/version. | Mitigate with per-platform audit. | +| RISK-003 | Dependency vulnerabilities may appear after release. | Mitigate with recurring scan and patch policy. | +| RISK-004 | Diagnostic bundles may contain contextual sensitive data even after redaction. | Mitigate with user confirmation and privacy notice. | + +## 8. Approval + +| Role | Name | Decision | Date | +|---|---|---|---| +| Security Reviewer | TBD | Pending | TBD | +| Software Architect | TBD | Pending | TBD | +| Platform Owner | TBD | Pending | TBD | +| QA / Verification Owner | TBD | Pending | TBD | + +## 9. Change History + +| Version | Date | Description | +|---|---|---| +| 0.9.0 | 2026-05-14 | Initial threat model template and baseline candidate. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/ui-ux/adaptive-layout-platform-guide.md b/docs/ui-ux/adaptive-layout-platform-guide.md new file mode 100644 index 0000000..e7b4f22 --- /dev/null +++ b/docs/ui-ux/adaptive-layout-platform-guide.md @@ -0,0 +1,84 @@ + +# Chanora Adaptive Layout and Platform Behavior Guide + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English + +**Repo path:** `docs/ui-ux/adaptive-layout-platform-guide.md` --- + +## 1. Purpose + +This guide defines adaptive layout and platform behavior for the Chanora Flutter application. + +## 2. Window Classes + +| Class | Width | Layout | +|---|---:|---| +| Compact | `< 600dp` | Single-column content with mobile navigation | +| Medium | `600dp - 839dp` | Navigation rail or side navigation with main content | +| Expanded | `>= 840dp` | Persistent side pane, main pane, and persistent VoiceBar | + +## 3. Compact Layout + +- Use one primary content area. +- Keep VoiceBar visible or directly reachable. +- Keep connection status visible. +- Use bottom navigation for primary destinations. +- Avoid multi-pane assumptions. + +## 4. Medium Layout + +- Use navigation rail or equivalent side navigation. +- Keep primary content and VoiceBar available. +- Use dialogs or side panels depending on width. + +## 5. Expanded Layout + +- Use persistent side pane for server/channel navigation. +- Use main pane for chat, details, or current feature content. +- Keep VoiceBar persistent. +- Support pointer, keyboard, hover, and context menus. + +## 6. Android Platform Behavior + +- Runtime permissions must be explained before request where appropriate. +- System back behavior is handled as a back intent. +- Predictive back compatibility should be considered where supported. +- Bluetooth and audio routing are handled by platform services. +- Foreground voice behavior is handled according to Android platform rules. + +## 7. iOS Platform Behavior + +- Microphone permission must be explained before request where platform guidelines allow. +- Safe area, home indicator, keyboard avoidance, and route changes must be respected. +- Audio session behavior must be handled through platform audio services. +- Haptics should be restrained and meaningful. + +## 8. Desktop Platform Behavior + +- Keyboard traversal is required for primary controls. +- Tooltips and hover states should be supported. +- Context menus should be supported for channel tree, client rows, and bookmarks. +- Window resizing must not break critical controls. +- Diagnostics export must use platform-appropriate file handling. + +## 9. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial adaptive layout and platform behavior guide. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/ui-ux/material3-component-catalog.md b/docs/ui-ux/material3-component-catalog.md new file mode 100644 index 0000000..f401c6c --- /dev/null +++ b/docs/ui-ux/material3-component-catalog.md @@ -0,0 +1,105 @@ + +# Chanora Component Catalog — Material 3 Baseline + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English + +**Repo path:** `docs/ui-ux/material3-component-catalog.md` --- + +## 1. Purpose + +This catalog defines Chanora UI components that sit above Material 3 widgets. Components shall consume design tokens and expose accessible, testable APIs. + +## 2. Core Components + +| Component | Stage | Responsibility | +|---|---|---| +| `ChanoraAdaptiveShell` | P0 | Layout and navigation shell for compact, medium, expanded classes | +| `ChanoraVoiceBar` | P0 | Persistent voice controls | +| `ChanoraChannelTree` | P0 | Hierarchical channel and client browser | +| `ChanoraClientTile` | P0 | Client display row | +| `ChanoraStatusBadge` | P0 | Connection, voice, latency, and diagnostic status | +| `ChanoraAudioMeter` | P0 | Input audio level indicator | +| `ChanoraConnectionBanner` | P0 | Connection, reconnect, and error feedback | +| `ChanoraSettingsSection` | P0 | Settings grouping | +| `ChanoraDiagnosticPanel` | P0 | Diagnostics status and export entry | +| `ChanoraContextMenuAnchor` | P1 | Desktop and tablet context menu behavior | + +## 3. Component API Requirements + +### `ChanoraVoiceBar` + +Required properties: + +- connected status +- current channel name +- microphone muted state +- output deafened state +- push-to-talk active state +- input level +- latency summary +- localized labels +- callbacks for mute, deaf, push-to-talk, and settings + +### `ChanoraChannelTree` + +Required properties: + +- root channel nodes +- expanded channel IDs +- selected channel ID +- current voice channel ID +- client node list +- speaking client IDs +- join-channel callback +- context-menu callback +- keyboard traversal support + +### `ChanoraStatusBadge` + +Required properties: + +- state +- label +- icon +- semantic label +- optional severity +- optional tooltip + +### `ChanoraAudioMeter` + +Required properties: + +- level +- disabled state +- semantic value +- reduced-motion mode + +## 4. Accessibility Rules + +- Icon-only controls require semantic labels. +- Status components must not rely on color only. +- Components must support focus where interactive. +- Components must preserve touch target size where practical. +- Components must be testable through widget tests. + +## 5. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial Chanora component catalog. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/ui-ux/material3-design-tokens.md b/docs/ui-ux/material3-design-tokens.md new file mode 100644 index 0000000..843c978 --- /dev/null +++ b/docs/ui-ux/material3-design-tokens.md @@ -0,0 +1,120 @@ + +# Chanora Design Tokens — Material 3 Baseline + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English + +**Repo path:** `docs/ui-ux/material3-design-tokens.md` --- + +## 1. Token Strategy + +Chanora uses Material 3 tokens as the foundation and adds Chanora semantic tokens for voice-client-specific states. + +```text +Material 3 ColorScheme / TextTheme / Shape / Motion + -> Chanora Semantic Tokens + -> Chanora Components + -> Feature Screens +``` + +## 2. Token Groups + +| Group | Purpose | +|---|---| +| `chanora.color.connection.*` | Connection status | +| `chanora.color.voice.*` | Voice states | +| `chanora.color.latency.*` | Latency and packet-loss status | +| `chanora.color.diagnostics.*` | Diagnostic severity | +| `chanora.spacing.*` | Layout spacing | +| `chanora.shape.*` | Corners and component shapes | +| `chanora.motion.*` | Motion duration and reduced-motion behavior | +| `chanora.density.*` | Mobile, tablet, desktop density | +| `chanora.typography.*` | Product role mapping to Material type roles | + +## 3. Color Tokens + +| Token | Purpose | +|---|---| +| `chanora.color.connection.connected` | Connected state | +| `chanora.color.connection.connecting` | Connection in progress | +| `chanora.color.connection.reconnecting` | Recovering connection | +| `chanora.color.connection.disconnected` | Disconnected state | +| `chanora.color.connection.error` | Connection failure | +| `chanora.color.voice.speaking` | User is speaking | +| `chanora.color.voice.muted` | Microphone muted | +| `chanora.color.voice.deafened` | Output deafened | +| `chanora.color.voice.pttActive` | Push-to-talk active | +| `chanora.color.latency.good` | Good latency | +| `chanora.color.latency.warning` | Warning latency | +| `chanora.color.latency.bad` | Bad latency | +| `chanora.color.diagnostics.info` | Informational diagnostic | +| `chanora.color.diagnostics.warning` | Warning diagnostic | +| `chanora.color.diagnostics.error` | Error diagnostic | + +## 4. Typography Mapping + +| Product role | Material 3 type role | +|---|---| +| App title | `headlineSmall` | +| Server name | `titleLarge` | +| Channel name | `bodyLarge` | +| Client nickname | `bodyLarge` | +| Status secondary text | `bodyMedium` | +| Diagnostic metadata | `bodySmall` | +| Button label | `labelLarge` | +| Badge label | `labelMedium` | + +## 5. Spacing Tokens + +| Token | Value | +|---|---:| +| `chanora.spacing.xs` | 4 | +| `chanora.spacing.sm` | 8 | +| `chanora.spacing.md` | 12 | +| `chanora.spacing.lg` | 16 | +| `chanora.spacing.xl` | 24 | +| `chanora.spacing.2xl` | 32 | + +## 6. Shape Tokens + +| Token | Use | +|---|---| +| `chanora.shape.sm` | Small chips, compact controls | +| `chanora.shape.md` | Cards and list containers | +| `chanora.shape.lg` | Panels and navigation surfaces | +| `chanora.shape.xl` | Dialogs and sheets | +| `chanora.shape.full` | Pills, badges, icon buttons | + +## 7. Motion Tokens + +| Token | Purpose | +|---|---| +| `chanora.motion.quick` | Small feedback | +| `chanora.motion.standard` | Normal UI transition | +| `chanora.motion.emphasized` | Major layout transition | +| `chanora.motion.reduced` | Reduced-motion fallback | + +## 8. Flutter Implementation Requirement + +Tokens should be exposed through `ThemeData`, `ColorScheme`, component themes, and `ThemeExtension`. Feature screens shall not hardcode product semantic token values. + +## 9. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial design token baseline. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/ui-ux/material3-guideline.md b/docs/ui-ux/material3-guideline.md new file mode 100644 index 0000000..38b93db --- /dev/null +++ b/docs/ui-ux/material3-guideline.md @@ -0,0 +1,93 @@ + +# Chanora UI/UX Guideline — Material 3 Baseline + +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Lifecycle support:** Supports SysDes, SRS, SAD, SDD, and Verification +**Design baseline:** Material 3 + Chanora Design System + +**Repo path:** `docs/ui-ux/material3-guideline.md` --- + +## 1. Purpose + +This guideline defines the UI and UX baseline for the Chanora Flutter application. Chanora shall use Material 3 as the foundation, but product-specific voice, channel, connection, latency, diagnostics, platform, and accessibility semantics shall be expressed through Chanora Design System components and tokens. + +## 2. Core UI Principles + +| Principle | Requirement | +|---|---| +| Voice-first control | Mute, deaf, push-to-talk, current channel, and input status must be visible or directly reachable. | +| Connection awareness | Connected, connecting, reconnecting, disconnected, and error states must be visible. | +| Adaptive layout | Layout must adapt by window class rather than hardcoding behavior by platform name. | +| Accessibility baseline | Critical controls must have semantics, focus behavior, text scaling support, and non-color-only status expression. | +| Platform respect | Permission, safe area, keyboard, back, haptic, and audio-route behavior must follow platform expectations. | +| Localization-ready | Product-owned strings must be localized; server-provided content must be displayed as content. | + +## 3. Primary Screens + +| Screen | Stage | Purpose | +|---|---|---| +| Home | P0 | Recent servers, bookmarks, manual connect entry | +| Connect | P0 | Host, port, nickname, password, identity selection | +| Server | P0 | Channel tree, clients, connection status, current channel | +| Voice | P0 | Voice controls, input level, device summary | +| Chat | P1 | Channel text messages | +| Settings | P0 | Audio, UI, localization, platform behavior, shortcuts | +| Diagnostics | P0 | Status, redacted export, troubleshooting information | + +## 4. Interaction Rules + +| Area | Rule | +|---|---| +| Channel tree | Select, expand/collapse, join, context menu, keyboard traversal | +| Client tile | Show speaking, mute/deaf, volume, latency when available | +| Voice controls | Must be reachable with touch, mouse, and keyboard | +| Diagnostics | Export must require explicit user action and show redaction notice | +| Settings | Destructive or permission-changing actions require clear confirmation or explanation | +| Text entry | Chat input must respect IME and keyboard safe areas | + +## 5. Motion Rules + +| Scenario | Allowed behavior | +|---|---| +| Page transition | Minimal fade or shared-axis style transition | +| Speaking indicator | Subtle pulse, disabled or simplified under reduced motion | +| Reconnect banner | Clear state transition without disruptive animation | +| Layout change | Resize/reflow smoothly where possible | +| Error state | Immediate, clear, non-color-only feedback | + +## 6. Accessibility Rules + +| Rule | Baseline | +|---|---| +| Minimum target | Critical controls should meet a 48dp target where practical. | +| Semantics | Icon-only controls require labels. | +| Focus | Desktop and tablet keyboard use require visible focus. | +| State expression | Critical states require more than color. | +| Text scale | Critical controls remain reachable under increased text size. | +| Reduced motion | Non-essential animation is reduced or disabled. | + +## 7. Internationalization UX + +Product strings are localized. Server-provided server names, channel names, nicknames, and messages are not translated. Mixed-language and bidirectional text must be rendered as text content and preserved through diagnostics unless redacted. + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial UI/UX guideline for Material 3, adaptive layout, accessibility, platform behavior, and i18n. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/verification/swe4-unit-verification-plan.md b/docs/verification/swe4-unit-verification-plan.md new file mode 100644 index 0000000..450a57f --- /dev/null +++ b/docs/verification/swe4-unit-verification-plan.md @@ -0,0 +1,375 @@ + +# Chanora SWE.4 Software Unit Verification Plan + +**Document type:** Software Unit Verification Plan +**Process alignment:** ASPICE SWE.4 Software Unit Verification +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Verification object:** Software units defined by SDD +**Direct source layer:** SDD only + +**Repo path:** `docs/verification/swe4-unit-verification-plan.md` --- + +## 1. Purpose + +This document defines the software unit verification strategy for Chanora. It verifies that software units implement the Software Detailed Design. + +This document is downstream of SDD and shall not bypass the document hierarchy. + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD -> SWE.4 Unit Verification +``` + +Direct source rule: + +```text +SWE.4 unit verification items shall link directly to SDD only. +``` + +## 2. Verification Scope + +In scope: + +- Flutter unit tests +- Flutter widget-level unit verification where a widget is treated as a software unit +- Dart static analysis +- Dart code review +- Rust unit tests +- Rust static analysis +- Rust code review +- Unit-level regression verification +- Unit-level interface boundary tests +- Unit-level localization, Unicode, design-token, and diagnostics verification + +Out of scope: + +- Software integration verification across components; handled by SWE.5. +- Fully integrated software verification against SRS; handled by SWE.6. +- System integration verification against SysDes; handled by SYS.4. + +## 3. Unit Verification Strategy + +| Verification type | Applies to | Purpose | +|---|---|---| +| Static analysis | Dart, Rust | Detect structural, lint, safety, style, and maintainability issues | +| Code review | Dart, Rust, build scripts | Confirm design compliance and maintainability | +| Unit tests | Dart, Rust | Verify individual units against SDD behavior | +| Widget tests | Flutter widgets | Verify component rendering, semantics, and state behavior | +| Golden tests | Design-system components | Verify stable UI rendering where appropriate | +| Localization tests | Localization service and accessibility labels | Verify fallback, keys, and localized display strings | +| Unicode tests | Protocol/bridge/text-boundary units | Verify UTF-8 and multilingual content handling | +| Regression tests | Changed units | Confirm unchanged behavior remains valid after modifications | + +## 4. Entry Criteria + +| Criterion | Description | +|---|---| +| SDD baseline available | Unit design items and source SAD links are available. | +| Unit implementation available | The unit exists in source code or executable test double form. | +| Unit test environment available | Flutter and/or Rust test infrastructure is configured. | +| Verification measure defined | Test, review, or static analysis objective is defined. | +| Pass/fail criteria defined | Expected result is objective and reviewable. | + +## 5. Exit Criteria + +| Criterion | Description | +|---|---| +| Selected unit verification measures executed | Tests, reviews, and analyses required for the release scope are complete. | +| Results recorded | Verification results are stored in test reports or review records. | +| Nonconformances recorded | Failures are recorded for problem resolution. | +| Traceability complete | Each unit verification item traces to SDD and result evidence. | +| Regression scope complete | Changed units have selected regression measures executed. | + +## 6. Unit Verification Measures + +**SWE4-UV-001**: Verify `ChanoraApp` initialization order. + +- Source SDD: SDD-001, SDD-045 +- Verification method: Flutter unit/integration test +- Pass criteria: Theme, localization, platform services, routing, and adaptive shell initialize before feature rendering. +- Evidence: Test result + +**SWE4-UV-002**: Verify `ChanoraThemeFactory` Material 3 theme creation. + +- Source SDD: SDD-002, SDD-003 +- Verification method: Dart unit test +- Pass criteria: Light and dark Material 3 ThemeData objects are created with valid ColorScheme and TextTheme values. +- Evidence: Test result + +**SWE4-UV-003**: Verify `ChanoraSemanticColors` connection token behavior. + +- Source SDD: SDD-004, SDD-006 +- Verification method: Dart unit test +- Pass criteria: All connection semantic roles are present and do not require feature-screen hardcoding. +- Evidence: Test result + +**SWE4-UV-004**: Verify voice semantic token behavior. + +- Source SDD: SDD-005, SDD-006 +- Verification method: Dart unit test +- Pass criteria: Speaking, muted, deafened, and push-to-talk active states are available through semantic tokens. +- Evidence: Test result + +**SWE4-UV-005**: Verify feature widgets use theme accessors rather than hardcoded semantic values. + +- Source SDD: SDD-010 +- Verification method: Static inspection +- Pass criteria: Feature widgets do not construct product semantic token values directly. +- Evidence: Review record + +**SWE4-UV-006**: Verify adaptive shell window classification. + +- Source SDD: SDD-011, SDD-012 +- Verification method: Dart unit test +- Pass criteria: Compact, medium, and expanded classes are selected deterministically. +- Evidence: Test result + +**SWE4-UV-007**: Verify `CompactShell` layout behavior. + +- Source SDD: SDD-013 +- Verification method: Flutter widget test +- Pass criteria: Compact shell renders a single-column layout and mobile navigation entry points. +- Evidence: Test result + +**SWE4-UV-008**: Verify `MediumShell` layout behavior. + +- Source SDD: SDD-014 +- Verification method: Flutter widget test +- Pass criteria: Medium shell renders side navigation or navigation rail behavior. +- Evidence: Test result + +**SWE4-UV-009**: Verify `ExpandedShell` persistent pane behavior. + +- Source SDD: SDD-015 +- Verification method: Flutter widget test +- Pass criteria: Expanded shell renders persistent side pane and VoiceBar slot. +- Evidence: Test result + +**SWE4-UV-010**: Verify connection status presentation uses non-color-only cues. + +- Source SDD: SDD-016, SDD-022 +- Verification method: Dart unit test, widget test +- Pass criteria: The presenter exposes label, icon, semantic label, and severity token. +- Evidence: Test result + +**SWE4-UV-011**: Verify `ChanoraVoiceBar` exposed properties. + +- Source SDD: SDD-017, SDD-018 +- Verification method: Flutter widget test +- Pass criteria: Mute, deaf, push-to-talk, input meter, current channel, and latency properties render correctly. +- Evidence: Test result + +**SWE4-UV-012**: Verify `ChanoraChannelTree` data and interaction behavior. + +- Source SDD: SDD-019, SDD-020 +- Verification method: Flutter widget test +- Pass criteria: Channel hierarchy, selected state, expansion state, join intent, and context-menu intent operate as designed. +- Evidence: Test result + +**SWE4-UV-013**: Verify `ChanoraClientTile` state semantics. + +- Source SDD: SDD-021 +- Verification method: Widget test, accessibility test +- Pass criteria: Client status is available through text/icon/semantic cues and not color alone. +- Evidence: Test result + +**SWE4-UV-014**: Verify localized semantic labels for icon-only buttons. + +- Source SDD: SDD-024, SDD-031, SDD-032 +- Verification method: Accessibility test, localization unit test +- Pass criteria: Icon-only controls expose localized semantic labels with fallback. +- Evidence: Test result + +**SWE4-UV-015**: Verify keyboard focus traversal. + +- Source SDD: SDD-025 +- Verification method: Widget test +- Pass criteria: Primary interactive controls can be traversed in a logical order. +- Evidence: Test result + +**SWE4-UV-016**: Verify text-scale resilience of critical controls. + +- Source SDD: SDD-026 +- Verification method: Accessibility widget test +- Pass criteria: Critical controls remain reachable under increased text scale. +- Evidence: Test result + +**SWE4-UV-017**: Verify platform inset service unit behavior. + +- Source SDD: SDD-027, SDD-030 +- Verification method: Unit test with platform test doubles +- Pass criteria: Insets are normalized and exposed to the shell. +- Evidence: Test result + +**SWE4-UV-018**: Verify back intent service behavior. + +- Source SDD: SDD-028 +- Verification method: Unit test with platform test doubles +- Pass criteria: Platform back events map to expected route-level intents. +- Evidence: Test result + +**SWE4-UV-019**: Verify localization fallback. + +- Source SDD: SDD-031, SDD-032, SDD-033 +- Verification method: Unit test +- Pass criteria: Missing localized strings fall back deterministically. +- Evidence: Test result + +**SWE4-UV-020**: Verify server-content pass-through. + +- Source SDD: SDD-034 +- Verification method: Unit test +- Pass criteria: Server-provided content is not translated by product localization. +- Evidence: Test result + +**SWE4-UV-021**: Verify Unicode text boundary behavior. + +- Source SDD: SDD-035, SDD-036, SDD-037 +- Verification method: Unit test +- Pass criteria: Valid multilingual Unicode content is preserved; invalid external encodings are handled at boundaries. +- Evidence: Test result + +**SWE4-UV-022**: Verify diagnostic Unicode preservation and redaction behavior. + +- Source SDD: SDD-038, SDD-041, SDD-050, SDD-054 +- Verification method: Unit test, security review +- Pass criteria: Secrets are redacted while multilingual content is preserved. +- Evidence: Test result, review record + +**SWE4-UV-023**: Verify locale-aware formatting. + +- Source SDD: SDD-040 +- Verification method: Unit test +- Pass criteria: Dates, times, numbers, and timestamps format through localization utilities. +- Evidence: Test result + +**SWE4-UV-024**: Verify traceability checker behavior. + +- Source SDD: SDD-043, SDD-044, SDD-055, SDD-056, SDD-066, SDD-067 +- Verification method: Unit test / script test +- Pass criteria: Invalid direct-layer references are detected. +- Evidence: Test result + +**SWE4-UV-025**: Verify bridge DTO safety. + +- Source SDD: SDD-046 +- Verification method: Unit test, static inspection +- Pass criteria: Bridge DTOs do not expose internal Rust implementation types. +- Evidence: Test result, review record + +**SWE4-UV-026**: Verify Rust core event mapping. + +- Source SDD: SDD-047 +- Verification method: Rust unit test +- Pass criteria: Core events map deterministically to view model deltas. +- Evidence: Test result + +**SWE4-UV-027**: Verify voice view model separation from DSP. + +- Source SDD: SDD-048 +- Verification method: Code review, unit test +- Pass criteria: Voice UI receives status values and does not perform audio DSP. +- Evidence: Review record, test result + +**SWE4-UV-028**: Verify storage facade isolation. + +- Source SDD: SDD-049 +- Verification method: Static inspection, unit test +- Pass criteria: Feature widgets do not directly call database APIs. +- Evidence: Review record, test result + +**SWE4-UV-029**: Verify interface detail catalog completeness. + +- Source SDD: SDD-059, SDD-060 +- Verification method: Review +- Pass criteria: Unit-level interface entries include required details where applicable. +- Evidence: Review record + +**SWE4-UV-030**: Verify unit construction and review records. + +- Source SDD: SDD-064, SDD-065, SDD-068, SDD-069, SDD-070 +- Verification method: Review +- Pass criteria: Unit construction, review, verification handoff, and registry records exist for release scope units. +- Evidence: Review record + +## 7. Traceability Matrix + +| SDD Range | SWE.4 Coverage | +|---|---| +| SDD-001 through SDD-010 | SWE4-UV-001 through SWE4-UV-005 | +| SDD-011 through SDD-018 | SWE4-UV-006 through SWE4-UV-011 | +| SDD-019 through SDD-026 | SWE4-UV-012 through SWE4-UV-016 | +| SDD-027 through SDD-037 | SWE4-UV-017 through SWE4-UV-021 | +| SDD-038 through SDD-050 | SWE4-UV-022 through SWE4-UV-028 | +| SDD-051 through SDD-070 | SWE4-UV-029 through SWE4-UV-030 | + +## 8. Result Reporting + +Unit verification results shall be summarized in a unit verification summary report including: + +- verification scope +- selected verification measures +- skipped measures and rationale +- pass/fail result +- nonconformances +- regression scope +- residual risks +- release recommendation + +## 9. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial SWE.4 unit verification plan derived from SDD v0.3. | + +--- + +## 10. Platform Decision Unit Verification Addendum + +**SWE4-UV-031**: Verify iOS and Android build configuration units. + +- Source SDD: SDD-071, SDD-072, SDD-073 +- Verification method: Static inspection, platform test +- Pass criteria: iOS minimum runtime, Apple SDK gate, Android minimum runtime, and Android target SDK configuration are inspectable and match release policy. +- Evidence: Test result, release inspection + +**SWE4-UV-032**: Verify single active connection enforcement. + +- Source SDD: SDD-074 +- Verification method: Unit test +- Pass criteria: Attempting to create a second active MVP connection is rejected or routed through a controlled disconnect/switch policy. +- Evidence: Test result + +**SWE4-UV-033**: Verify audio processing defaults and backend selection. + +- Source SDD: SDD-075, SDD-076 +- Verification method: Unit test, audio test +- Pass criteria: AEC, AGC, Noise Suppression, and High-Pass Filter default to enabled where supported and stable; backend selector prefers platform-native processing. +- Evidence: Test result + +**SWE4-UV-034**: Verify local database, secret storage, bridge, and diagnostics privacy gate units. + +- Source SDD: SDD-077, SDD-078, SDD-079, SDD-080 +- Verification method: Unit test, security inspection +- Pass criteria: Non-secret storage, secret storage, typed bridge DTOs, and disabled automatic upload/crash behavior match detailed design. +- Evidence: Test result, security review + +| SDD Range | SWE.4 Coverage | +|---|---| +| SDD-071 through SDD-080 | SWE4-UV-031 through SWE4-UV-034 | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/verification/swe5-software-integration-verification-plan.md b/docs/verification/swe5-software-integration-verification-plan.md new file mode 100644 index 0000000..987f465 --- /dev/null +++ b/docs/verification/swe5-software-integration-verification-plan.md @@ -0,0 +1,225 @@ + +# Chanora SWE.5 Software Integration and Integration Verification Plan + +**Document type:** Software Integration Verification Plan +**Process alignment:** ASPICE SWE.5 Software Component Verification and Integration Verification +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Verification object:** Integrated software elements +**Direct source layer:** SAD and SDD verification objects + +**Repo path:** `docs/verification/swe5-software-integration-verification-plan.md` --- + +## 1. Purpose + +This document defines the software integration and integration verification strategy for Chanora. It verifies that software elements integrate correctly and interact according to the software architecture and detailed design. + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD + -> SWE.5 Software Integration Verification +``` + +SWE.5 verifies architecture interfaces, dynamic behavior, component behavior, and selected detailed-design interactions. + +## 2. Integration Strategy + +| Integration step | Integrated elements | Purpose | +|---|---|---| +| SWE5-INT-001 | Flutter App Shell + Design System | Confirm theme initialization and token availability | +| SWE5-INT-002 | Design System + UI Components | Confirm components consume tokens and expose semantics | +| SWE5-INT-003 | Adaptive Shell + Feature Modules | Confirm compact/medium/expanded layouts integrate with features | +| SWE5-INT-004 | Localization Service + UI Components | Confirm product strings and accessibility labels integrate | +| SWE5-INT-005 | Protocol Adapter + Rust Core | Confirm protocol events and errors integrate with core state | +| SWE5-INT-006 | Rust Core + Bridge Facade | Confirm commands, results, and event streams integrate | +| SWE5-INT-007 | Bridge Facade + Flutter State | Confirm event mapping and view model updates | +| SWE5-INT-008 | Audio Subsystem + Platform Audio | Confirm capture, processing, encode/decode, and playback interface behavior | +| SWE5-INT-009 | Diagnostics + Storage + Localization | Confirm diagnostics event keys, localized descriptions, redaction, and export integration | +| SWE5-INT-010 | Full Flutter UI + Rust Core | Confirm end-to-end software behavior before software qualification testing | + +## 3. Integration Verification Measures + +**SWE5-IV-001**: Verify Flutter App Shell and Design System integration. + +- Source SAD: SAD-001, SAD-002, SAD-007 +- Source SDD: SDD-001, SDD-002, SDD-003 +- Verification method: Flutter integration test +- Pass criteria: App initializes Material 3 theme and Chanora semantic tokens before rendering feature screens. +- Evidence: Integration test result + +**SWE5-IV-002**: Verify Design System and UI Component integration. + +- Source SAD: SAD-002, SAD-003, SAD-014 +- Source SDD: SDD-004 through SDD-010, SDD-021 through SDD-024 +- Verification method: Widget integration test +- Pass criteria: Components consume design tokens and expose required accessibility semantics. +- Evidence: Integration test result + +**SWE5-IV-003**: Verify adaptive shell and feature module integration. + +- Source SAD: SAD-008 through SAD-011 +- Source SDD: SDD-011 through SDD-015 +- Verification method: Integration test +- Pass criteria: Compact, medium, and expanded layouts render correct feature regions and preserve critical voice/connection access. +- Evidence: Integration test result + +**SWE5-IV-004**: Verify connection status and VoiceBar integration. + +- Source SAD: SAD-012, SAD-013, SAD-016 +- Source SDD: SDD-016, SDD-017, SDD-018, SDD-026 +- Verification method: Integration test +- Pass criteria: Connection status and primary voice controls are visible or directly reachable across layout classes. +- Evidence: Integration test result + +**SWE5-IV-005**: Verify localization and accessibility integration. + +- Source SAD: SAD-014, SAD-020, SAD-026 +- Source SDD: SDD-024, SDD-031, SDD-032, SDD-040 +- Verification method: Integration test, accessibility test +- Pass criteria: Localized strings, semantic labels, fallback behavior, and locale-aware formatting work together. +- Evidence: Integration test result + +**SWE5-IV-006**: Verify server-content text path integration. + +- Source SAD: SAD-021, SAD-022, SAD-023 +- Source SDD: SDD-034, SDD-035, SDD-036, SDD-037 +- Verification method: Integration test +- Pass criteria: Server names, channel names, nicknames, and messages preserve Unicode and are not translated. +- Evidence: Integration test result + +**SWE5-IV-007**: Verify Platform Services and App Shell integration. + +- Source SAD: SAD-017, SAD-018, SAD-019 +- Source SDD: SDD-027, SDD-028, SDD-029, SDD-030 +- Verification method: Platform integration test +- Pass criteria: Insets, back intent, haptics, and keyboard avoidance integrate with shell behavior. +- Evidence: Platform test result + +**SWE5-IV-008**: Verify Bridge Facade and Rust Core integration. + +- Source SAD: SAD-040, SAD-041 +- Source SDD: SDD-046, SDD-047 +- Verification method: Integration test +- Pass criteria: Flutter commands and Rust events flow through stable DTOs and deterministic event mapping. +- Evidence: Integration test result + +**SWE5-IV-009**: Verify Rust Core and Protocol Adapter integration. + +- Source SAD: SAD-032, SAD-033, SAD-041 +- Source SDD: SDD-046, SDD-047 +- Verification method: Integration test with protocol test server or protocol test double +- Pass criteria: Connection, snapshot, delta events, and protocol errors integrate with core state. +- Evidence: Integration test result + +**SWE5-IV-010**: Verify Audio Subsystem and Platform Audio integration. + +- Source SAD: SAD-034 +- Source SDD: SDD-048 +- Verification method: Audio integration test +- Pass criteria: Audio status reaches UI while DSP remains isolated from UI units. +- Evidence: Audio integration test result + +**SWE5-IV-011**: Verify Diagnostics integration. + +- Source SAD: SAD-036, SAD-050 +- Source SDD: SDD-038, SDD-041, SDD-050, SDD-054 +- Verification method: Integration test, audit +- Pass criteria: Diagnostic keys, localized descriptions, redaction, Unicode preservation, and export flow operate together. +- Evidence: Integration test result, audit record + +**SWE5-IV-012**: Verify storage and secure-storage integration boundaries. + +- Source SAD: SAD-035 +- Source SDD: SDD-049 +- Verification method: Integration test, security review +- Pass criteria: Non-secret data uses storage facade and secrets use secure storage boundaries. +- Evidence: Integration test result, review record + +**SWE5-IV-013**: Verify architecture-view and traceability-tooling integration. + +- Source SAD: SAD-046 through SAD-060 +- Source SDD: SDD-051 through SDD-070 +- Verification method: Documentation/tooling integration check +- Pass criteria: Architecture views, ADRs, interface detail catalog, and traceability checker are mutually consistent. +- Evidence: Review record + +## 4. Regression Strategy + +Regression selection shall consider: + +- changed software unit +- changed interface +- changed architecture item +- changed DTO +- changed localization resource +- changed audio pipeline behavior +- changed protocol adapter behavior +- changed diagnostics redaction behavior +- changed platform behavior + +## 5. Traceability Matrix + +| Architecture / Design Area | SWE.5 Coverage | +|---|---| +| SAD-001 through SAD-016 | SWE5-IV-001 through SWE5-IV-005 | +| SAD-017 through SAD-027 | SWE5-IV-005 through SWE5-IV-007, SWE5-IV-011 | +| SAD-028 through SAD-031 | SWE5-IV-013 | +| SAD-032 through SAD-041 | SWE5-IV-008 through SWE5-IV-012 | +| SAD-042 through SAD-050 | SWE5-IV-001, SWE5-IV-011, SWE5-IV-013 | +| SAD-051 through SAD-060 | SWE5-IV-013 | +| SDD-001 through SDD-030 | SWE5-IV-001 through SWE5-IV-007 | +| SDD-031 through SDD-050 | SWE5-IV-005 through SWE5-IV-012 | +| SDD-051 through SDD-070 | SWE5-IV-013 | + +## 6. Result Reporting + +Software integration verification results shall be summarized in an integration verification summary report including: + +- integrated elements +- selected integration sequence +- selected verification measures +- regression scope +- test environment +- pass/fail result +- nonconformances +- interface issues +- residual risks +- release recommendation + +## 7. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial SWE.5 software integration and integration verification plan. | + +--- + +## 8. Platform Decision Integration Verification Addendum + +**SWE5-IV-014**: Verify platform baseline, build configuration, single connection, audio defaults, storage, bridge, and diagnostics privacy integration. + +- Source SAD: SAD-061 through SAD-070 +- Source SDD: SDD-071 through SDD-080 +- Verification method: Integration test, release inspection, security review +- Pass criteria: New product decisions integrate across build configuration, runtime behavior, audio, storage, bridge, diagnostics, and release readiness. +- Evidence: Integration verification result + +| Architecture / Design Area | SWE.5 Coverage | +|---|---| +| SAD-061 through SAD-070 | SWE5-IV-014 | +| SDD-071 through SDD-080 | SWE5-IV-014 | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/verification/swe6-software-verification-plan.md b/docs/verification/swe6-software-verification-plan.md new file mode 100644 index 0000000..e30024a --- /dev/null +++ b/docs/verification/swe6-software-verification-plan.md @@ -0,0 +1,224 @@ + +# Chanora SWE.6 Software Verification Plan + +**Document type:** Software Verification / Software Qualification Test Plan +**Process alignment:** ASPICE SWE.6 Software Verification +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Verification object:** Fully integrated Chanora software +**Direct source layer:** SRS + +**Repo path:** `docs/verification/swe6-software-verification-plan.md` --- + +## 1. Purpose + +This document defines the software verification strategy for Chanora. It verifies that the fully integrated software satisfies the Software Requirements Specification. + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD + -> SWE.6 Software Verification +``` + +SWE.6 verifies against SRS. It does not replace SWE.4 unit verification or SWE.5 software integration verification. + +## 2. Software Verification Strategy + +| Verification type | Purpose | +|---|---| +| Functional software tests | Verify integrated software behavior against SRS | +| Non-functional software tests | Verify performance, accessibility, security, diagnostics, localization, and reliability requirements | +| Platform software tests | Verify integrated software behavior on target platforms | +| Regression tests | Confirm changes did not break previously verified software requirements | +| Release-scope test selection | Select tests according to target release content | +| Summary reporting | Communicate software verification status | + +## 3. Software Verification Measures + +**SWE6-SV-001**: Verify server connection flow. + +- Source SRS: SRS-001 through SRS-030 +- Verification method: End-to-end software test +- Pass criteria: User can connect to a compatible server with configured connection data. +- Evidence: Software verification result + +**SWE6-SV-002**: Verify channel tree, client list, and server state display. + +- Source SRS: SRS-031 through SRS-060 +- Verification method: End-to-end software test +- Pass criteria: Channel and client state is displayed and updates after server events. +- Evidence: Software verification result + +**SWE6-SV-003**: Verify voice send and receive. + +- Source SRS: SRS-061 through SRS-090 +- Verification method: Audio software verification test +- Pass criteria: User can transmit and receive voice under supported conditions. +- Evidence: Software verification result + +**SWE6-SV-004**: Verify push-to-talk, mute, deaf, and voice status. + +- Source SRS: SRS-061 through SRS-090, SRS-156 +- Verification method: End-to-end software test +- Pass criteria: Voice controls perform expected software behavior and display correct state. +- Evidence: Software verification result + +**SWE6-SV-005**: Verify local storage and secure storage behavior. + +- Source SRS: SRS-091 through SRS-110 +- Verification method: Software security and persistence test +- Pass criteria: Non-secret data persists through approved storage and secrets use secure storage boundaries. +- Evidence: Software verification result + +**SWE6-SV-006**: Verify diagnostics and redacted export behavior. + +- Source SRS: SRS-111 through SRS-124, SRS-177, SRS-178 +- Verification method: Software verification test, audit +- Pass criteria: Diagnostic export requires user action and redacts sensitive data while preserving safe Unicode content. +- Evidence: Software verification result, audit record + +**SWE6-SV-007**: Verify deployment-sensitive software behavior. + +- Source SRS: SRS-125 through SRS-134 +- Verification method: Release build verification +- Pass criteria: Release build metadata, packaging behavior, and platform declarations are consistent with software requirements. +- Evidence: Release verification result + +**SWE6-SV-008**: Verify traceability and documentation controls. + +- Source SRS: SRS-135 through SRS-143, SRS-180 through SRS-183 +- Verification method: Documentation verification +- Pass criteria: SRS, SAD, and SDD direct-source rules pass validation. +- Evidence: Traceability report + +**SWE6-SV-009**: Verify Material 3 and Chanora Design System behavior. + +- Source SRS: SRS-144 through SRS-150 +- Verification method: UI software verification, review +- Pass criteria: Integrated app uses Material 3 baseline and Chanora semantic tokens without feature-screen hardcoding. +- Evidence: Software verification result + +**SWE6-SV-010**: Verify adaptive layouts. + +- Source SRS: SRS-151 through SRS-156 +- Verification method: UI software verification +- Pass criteria: Compact, medium, and expanded layouts preserve connection status and primary voice controls. +- Evidence: Software verification result + +**SWE6-SV-011**: Verify accessibility behavior. + +- Source SRS: SRS-157 through SRS-161 +- Verification method: Accessibility verification +- Pass criteria: Critical controls expose semantics, non-color-only state cues, focus behavior, and text-scale resilience. +- Evidence: Accessibility verification result + +**SWE6-SV-012**: Verify platform behavior. + +- Source SRS: SRS-162 through SRS-164 +- Verification method: Platform software verification +- Pass criteria: Insets, safe areas, keyboard, Android back behavior, and iOS platform behavior operate as specified. +- Evidence: Platform verification result + +**SWE6-SV-013**: Verify localization and fallback behavior. + +- Source SRS: SRS-165 through SRS-169 +- Verification method: Localization software verification +- Pass criteria: Product strings are externalized, English baseline exists, additional locales can be added, and fallback is deterministic. +- Evidence: Localization verification result + +**SWE6-SV-014**: Verify Unicode and server-content behavior. + +- Source SRS: SRS-170 through SRS-176 +- Verification method: Internationalization software verification +- Pass criteria: Server content is preserved, displayed without translation, UTF-8 is used internally, and locale-aware formatting works. +- Evidence: Internationalization verification result + +**SWE6-SV-015**: Verify software architecture and detailed design traceability controls. + +- Source SRS: SRS-180 through SRS-184 +- Verification method: Documentation/tooling verification +- Pass criteria: SAD derives from SRS and SDD derives from SAD; initialization sequence is verified. +- Evidence: Traceability validation result + +## 4. Regression Strategy + +Regression test selection shall consider: + +- changed SRS item +- changed feature +- changed architecture component +- changed detailed design unit +- changed platform behavior +- changed localization or Unicode handling +- changed diagnostics or redaction +- changed audio behavior +- changed protocol adapter behavior + +## 5. Traceability Matrix + +| SRS Range | SWE.6 Coverage | +|---|---| +| SRS-001 through SRS-030 | SWE6-SV-001 | +| SRS-031 through SRS-060 | SWE6-SV-002 | +| SRS-061 through SRS-090 | SWE6-SV-003, SWE6-SV-004 | +| SRS-091 through SRS-110 | SWE6-SV-005 | +| SRS-111 through SRS-124 | SWE6-SV-006 | +| SRS-125 through SRS-134 | SWE6-SV-007 | +| SRS-135 through SRS-143 | SWE6-SV-008 | +| SRS-144 through SRS-150 | SWE6-SV-009 | +| SRS-151 through SRS-156 | SWE6-SV-010 | +| SRS-157 through SRS-161 | SWE6-SV-011 | +| SRS-162 through SRS-164 | SWE6-SV-012 | +| SRS-165 through SRS-169 | SWE6-SV-013 | +| SRS-170 through SRS-176 | SWE6-SV-014 | +| SRS-177 through SRS-184 | SWE6-SV-006, SWE6-SV-015 | + +## 6. Result Reporting + +Software verification results shall be summarized in a software verification summary report including: + +- release scope +- selected software verification measures +- skipped measures and rationale +- platform/environment used +- pass/fail status +- nonconformances +- regression scope +- residual risks +- release recommendation + +## 7. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial SWE.6 software verification plan derived from SRS v0.5. | + +--- + +## 8. Platform Decision Software Verification Addendum + +**SWE6-SV-016**: Verify platform baseline, release SDK gates, single connection MVP scope, audio defaults, storage/bridge policy, and diagnostics/crash reporting policy. + +- Source SRS: SRS-185 through SRS-194 +- Verification method: Software verification, release inspection, security/privacy review +- Pass criteria: Integrated software and release configuration satisfy the accepted product decisions. +- Evidence: Software verification result, release inspection record + +| SRS Range | SWE.6 Coverage | +|---|---| +| SRS-185 through SRS-194 | SWE6-SV-016 | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/verification/sys4-system-integration-verification-plan.md b/docs/verification/sys4-system-integration-verification-plan.md new file mode 100644 index 0000000..4b686e4 --- /dev/null +++ b/docs/verification/sys4-system-integration-verification-plan.md @@ -0,0 +1,241 @@ + +# Chanora SYS.4 System Integration and Integration Verification Plan + +**Document type:** System Integration and Integration Verification Plan +**Process alignment:** ASPICE SYS.4 System Integration and Integration Verification +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora +**Verification object:** Integrated application system elements +**Direct source layer:** SysDes + +**Repo path:** `docs/verification/sys4-system-integration-verification-plan.md` --- + +## 1. Purpose + +This document defines the system integration and integration verification strategy for the Chanora application system. It verifies that the system elements defined by SysDes are integrated and interact according to the system architecture. + +```text +SysRS -> SysDes -> SYS.4 System Integration Verification +``` + +SYS.4 verifies system architecture integration. It does not replace SWE.4, SWE.5, or SWE.6. + +## 2. System Integration Scope + +System elements include: + +- User/operator interaction +- Client device hardware +- Operating system services +- Network environment +- External compatible voice server +- Chanora application container +- Flutter UI +- Rust Core +- Protocol adapter +- Audio subsystem +- Platform adapters +- Storage +- Secure storage +- Diagnostics +- Deployment environment +- Localization and UI/UX architecture elements + +## 3. System Integration Strategy + +| Integration step | System elements | Purpose | +|---|---|---| +| SYS4-INT-001 | Chanora app + OS permissions | Verify microphone, notification, secure storage, lifecycle, and permission integration | +| SYS4-INT-002 | Chanora app + audio hardware | Verify input/output device integration and route changes | +| SYS4-INT-003 | Chanora app + network environment | Verify connection behavior, reconnect, and failure presentation | +| SYS4-INT-004 | Chanora app + external compatible server | Verify channels, clients, voice, and text behavior with real or representative server | +| SYS4-INT-005 | Flutter UI + platform services | Verify safe areas, system bars, keyboard, and platform navigation behavior | +| SYS4-INT-006 | Rust Core + external protocol server | Verify protocol integration at system level | +| SYS4-INT-007 | Diagnostics + user export target | Verify diagnostic export workflow at system level | +| SYS4-INT-008 | Deployment artifact + target OS | Verify packaged application launches and uses required services | +| SYS4-INT-009 | Localization + server multilingual content | Verify multilingual product UI and server-provided content handling | +| SYS4-INT-010 | Full application system | Verify integrated behavior across supported platform classes | + +## 4. System Integration Verification Measures + +**SYS4-SIV-001**: Verify OS permission integration. + +- Source SysDes: SysDes-048 through SysDes-058, SysDes-118 +- Verification method: Platform system integration test +- Pass criteria: Required permissions, lifecycle behavior, safe areas, keyboard behavior, and platform navigation behavior integrate with the application. +- Evidence: System integration test result + +**SYS4-SIV-002**: Verify audio hardware integration. + +- Source SysDes: SysDes-059 through SysDes-074 +- Verification method: Audio system integration test +- Pass criteria: Audio capture, playback, route change handling, and processing feature availability work with supported devices. +- Evidence: System integration test result + +**SYS4-SIV-003**: Verify network environment integration. + +- Source SysDes: SysDes-075 through SysDes-087 +- Verification method: Network system integration test +- Pass criteria: Connection, recoverable network loss, reconnect, and user-safe errors work under defined network conditions. +- Evidence: System integration test result + +**SYS4-SIV-004**: Verify external compatible server integration. + +- Source SysDes: SysDes-088 through SysDes-101 +- Verification method: Server system integration test +- Pass criteria: Server connection, channel list, client list, voice, text, and disconnect behavior integrate correctly. +- Evidence: System integration test result + +**SYS4-SIV-005**: Verify application functional system integration. + +- Source SysDes: SysDes-102 through SysDes-120 +- Verification method: System integration test +- Pass criteria: User-visible workflows operate across UI, Rust Core, protocol, state, audio, storage, and diagnostics elements. +- Evidence: System integration test result + +**SYS4-SIV-006**: Verify protocol system integration. + +- Source SysDes: SysDes-121 through SysDes-128 +- Verification method: System integration test with compatible server +- Pass criteria: Protocol adapter integrates with Rust Core and external compatible server without exposing protocol internals to UI. +- Evidence: System integration test result + +**SYS4-SIV-007**: Verify state synchronization system integration. + +- Source SysDes: SysDes-129 through SysDes-132 +- Verification method: System integration test +- Pass criteria: Snapshot, delta, reconnect, event ordering, and UI update behavior operate together. +- Evidence: System integration test result + +**SYS4-SIV-008**: Verify storage and security system integration. + +- Source SysDes: SysDes-001 through SysDes-132 +- Verification method: Security and system integration test +- Pass criteria: Bookmarks, settings, secure storage, redaction, and privacy constraints integrate correctly. +- Evidence: System integration test result, audit record + +**SYS4-SIV-009**: Verify diagnostics and operations system integration. + +- Source SysDes: SysDes-001 through SysDes-132 +- Verification method: System integration test +- Pass criteria: Logs, redaction, diagnostics, export, and support workflow operate as an integrated capability. +- Evidence: System integration test result + +**SYS4-SIV-010**: Verify non-functional system behavior. + +- Source SysDes: SysDes-001 through SysDes-132 +- Verification method: Performance and reliability system integration test +- Pass criteria: Responsiveness, audio latency, memory growth controls, reconnect, and malformed-event behavior meet defined expectations. +- Evidence: System integration test result + +**SYS4-SIV-011**: Verify deployment and release environment integration. + +- Source SysDes: SysDes-001 through SysDes-132 +- Verification method: Deployment system integration test +- Pass criteria: Target platform packages install, launch, and access required OS services as expected. +- Evidence: Deployment integration result + +**SYS4-SIV-012**: Verify interface integration. + +- Source SysDes: SysDes-001 through SysDes-132 +- Verification method: Interface system integration test +- Pass criteria: User, bridge, protocol, audio, storage, secure storage, network, and diagnostic interfaces integrate correctly. +- Evidence: Interface integration result + +**SYS4-SIV-013**: Verify constraints and assumptions integration impact. + +- Source SysDes: SysDes-001 through SysDes-132 +- Verification method: Review, inspection, system integration test +- Pass criteria: Constraints and assumptions are respected or deviations are documented. +- Evidence: Review record, system integration test result + +**SYS4-SIV-014**: Verify UI/UX, Material 3, platform, and i18n system integration. + +- Source SysDes: SysDes-111 through SysDes-132 +- Verification method: System integration test +- Pass criteria: Material 3 design system, adaptive shell, accessibility, platform behavior, localization, Unicode, diagnostics localization, and traceability controls integrate correctly. +- Evidence: System integration test result + +## 5. Regression Strategy + +Regression selection shall consider: + +- changed system element +- changed software release +- changed platform adapter +- changed audio hardware support +- changed compatible server behavior +- changed network behavior +- changed deployment package +- changed localization or Unicode handling +- changed diagnostics export behavior +- changed system architecture item + +## 6. Traceability Matrix + +| SysDes Range | SYS.4 Coverage | +|---|---| +| SysDes-001 through SysDes-034 | SYS4-SIV-005, SYS4-SIV-006, SYS4-SIV-007 | +| SysDes-035 through SysDes-058 | SYS4-SIV-001 | +| SysDes-059 through SysDes-074 | SYS4-SIV-002 | +| SysDes-075 through SysDes-087 | SYS4-SIV-003 | +| SysDes-088 through SysDes-101 | SYS4-SIV-004 | +| SysDes-102 through SysDes-110 | SYS4-SIV-005 | +| SysDes-111 through SysDes-132 | SYS4-SIV-014 | +| SysDes-121 through SysDes-128 | SYS4-SIV-006 | +| SysDes-129 through SysDes-132 | SYS4-SIV-007 | +| SysDes-above-current-baseline and above | Not applicable; no such IDs exist in current SysDes baseline. | + +## 7. Result Reporting + +System integration verification results shall be summarized in a system integration verification summary report including: + +- release scope +- integrated system elements +- integration sequence +- selected verification measures +- regression scope +- platform/environment used +- pass/fail status +- nonconformances +- interface issues +- dynamic behavior issues +- residual risks +- release recommendation + +## 8. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial SYS.4 system integration and integration verification plan derived from SysDes v0.6. | + +--- + +## 9. Platform Decision System Integration Verification Addendum + +**SYS4-SIV-015**: Verify platform baseline, Apple SDK gate, Android target gate, MVP single connection, audio defaults, storage, bridge, and diagnostics privacy system integration. + +- Source SysDes: SysDes-133 through SysDes-141 +- Verification method: System integration test, release inspection, security/privacy review +- Pass criteria: System-level integration reflects accepted product decisions and release gates. +- Evidence: System integration result, release readiness evidence + +| SysDes Range | SYS.4 Coverage | +|---|---| +| SysDes-133 through SysDes-141 | SYS4-SIV-015 | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/docs/verification/verification-master-plan.md b/docs/verification/verification-master-plan.md new file mode 100644 index 0000000..fed024d --- /dev/null +++ b/docs/verification/verification-master-plan.md @@ -0,0 +1,83 @@ + +# Chanora Verification Master Plan + +**Document type:** Verification Master Plan +**Version:** 0.9.2 +**Status:** Baseline Candidate +**Language:** English +**Product:** Chanora + +**Repo path:** `docs/verification/verification-master-plan.md` --- + +## 1. Purpose + +This document defines how Chanora verification documents relate to the engineering hierarchy. + +Core engineering hierarchy: + +```text +SysRS -> SysDes -> SRS -> SAD -> SDD +``` + +Verification work products are downstream evidence-producing artifacts and do not replace the hierarchy. + +## 2. Verification Layers + +| Process | Verification target | Direct verification source | Purpose | +|---|---|---|---| +| SWE.4 | Software units | SDD | Verify software units against detailed design | +| SWE.5 | Integrated software elements | SAD and SDD | Verify software architecture integration, interfaces, dynamic behavior, and component interaction | +| SWE.6 | Fully integrated software | SRS | Verify integrated software satisfies software requirements | +| SYS.4 | Integrated application system elements | SysDes | Verify system elements integrate according to system architecture | + +## 3. Verification Flow + +```text +SDD -> SWE.4 Unit Verification +SAD + SDD -> SWE.5 Software Integration Verification +SRS -> SWE.6 Software Verification +SysDes -> SYS.4 System Integration Verification +``` + +## 4. Regression Rule + +A change in any design or requirement artifact shall trigger impact analysis for the corresponding verification layer: + +| Changed artifact | Verification impact | +|---|---| +| SDD | SWE.4 and SWE.5 impact analysis | +| SAD | SDD, SWE.5, and possibly SWE.4 impact analysis | +| SRS | SAD, SDD, SWE.6, and related lower-level verification impact analysis | +| SysDes | SRS/SAD/SDD impact analysis and SYS.4 impact analysis | +| SysRS | SysDes/SRS/SAD/SDD impact analysis and system/software verification impact analysis | + +## 5. Required Verification Reports + +| Report | Source | +|---|---| +| Unit Verification Summary Report | SWE.4 | +| Software Integration Verification Summary Report | SWE.5 | +| Software Verification Summary Report | SWE.6 | +| System Integration Verification Summary Report | SYS.4 | +| Regression Verification Report | Any affected verification layer | +| Problem Resolution Report | Failed verification requiring defect handling | + +## 6. Change History + +| Version | Date | Description | +|---|---|---| +| 0.1.0 | 2026-05-14 | Initial verification master plan covering SWE.4, SWE.5, SWE.6, and SYS.4. | + + +## Baseline Candidate 0.9.1 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.1 | 2026-05-14 | Updated baseline after product decision closure: Apple App Store SDK gate uses Xcode 26+ and iOS 26 / iPadOS 26 SDK+ since 2026-04-28, platform baselines and decision traceability propagated across the document set. | + + +## Baseline Candidate 0.9.2 Update + +| Version | Date | Description | +|---|---|---| +| 0.9.2 | 2026-05-14 | Corrected Apple App Store Connect upload gate to 2026-04-28 and checked full-package naming, references, and coverage. | diff --git a/tools/validate_docs.py b/tools/validate_docs.py new file mode 100644 index 0000000..c4cc8f5 --- /dev/null +++ b/tools/validate_docs.py @@ -0,0 +1,90 @@ +#!/usr/bin/env python3 +from __future__ import annotations + +import re +import sys +from pathlib import Path + +ROOT = Path(__file__).resolve().parents[1] +DOCS = ROOT / "docs" + +ID_FILES = { + "SysRS": DOCS / "requirements" / "sysrs.md", + "SysDes": DOCS / "architecture" / "sysdes.md", + "SRS": DOCS / "requirements" / "srs.md", + "SAD": DOCS / "architecture" / "sad.md", + "SDD": DOCS / "architecture" / "sdd.md", +} + +def read(path: Path) -> str: + if not path.exists(): + return "" + return path.read_text(encoding="utf-8") + +def defined_ids(prefix: str, text: str) -> set[str]: + return set(re.findall(rf"\*\*({prefix}-\d{{3}})\*\*:", text)) + +def all_refs(prefix: str, text: str) -> set[str]: + return set(re.findall(rf"{prefix}-\d{{3}}", text)) + +def main() -> int: + if not DOCS.exists(): + print("docs/ does not exist; skipping documentation validation.") + return 0 + + all_text = "\n".join(p.read_text(encoding="utf-8") for p in DOCS.rglob("*.md")) + + defined = { + prefix: defined_ids(prefix, read(path)) + for prefix, path in ID_FILES.items() + } + + failed = False + + for prefix, ids in defined.items(): + refs = all_refs(prefix, all_text) + undefined = sorted(refs - ids) + if undefined: + failed = True + print(f"[FAIL] Undefined {prefix} references: {', '.join(undefined)}") + else: + print(f"[OK] {prefix}: {len(ids)} defined, 0 undefined references") + + srs = read(DOCS / "requirements" / "srs.md") + sad = read(DOCS / "architecture" / "sad.md") + sdd = read(DOCS / "architecture" / "sdd.md") + + checks = [ + ("SRS direct SysRS references", re.findall(r"SysRS-\d{3}", srs)), + ("SAD direct SysRS references", re.findall(r"SysRS-\d{3}", sad)), + ("SAD direct SysDes references", re.findall(r"SysDes-\d{3}", sad)), + ("SDD direct SysRS references", re.findall(r"SysRS-\d{3}", sdd)), + ("SDD direct SysDes references", re.findall(r"SysDes-\d{3}", sdd)), + ("SDD direct SRS references", re.findall(r"SRS-\d{3}", sdd)), + ] + + for name, matches in checks: + if matches: + failed = True + print(f"[FAIL] {name}: {len(matches)}") + else: + print(f"[OK] {name}: 0") + + old_names = re.findall(r"CHANORA_[A-Za-z0-9_]+_v\d+\.\d+(?:\.\d+)?\.md", all_text) + if old_names: + failed = True + print(f"[FAIL] Old package-style filenames found: {len(set(old_names))}") + else: + print("[OK] No old package-style filenames found") + + cjk = re.findall(r"[\u4e00-\u9fff]", all_text) + if cjk: + failed = True + print(f"[FAIL] CJK characters found: {len(cjk)}") + else: + print("[OK] English-only CJK check passed") + + return 1 if failed else 0 + +if __name__ == "__main__": + sys.exit(main())