chore(repo): initial baseline import (docs v0.9.2 + bootstrap)

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.
This commit is contained in:
EdisonJwa
2026-05-14 12:25:33 +08:00
commit f1bc9a6c85
51 changed files with 14510 additions and 0 deletions
+18
View File
@@ -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
+12
View File
@@ -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=
+83
View File
@@ -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
+28
View File
@@ -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.
+64
View File
@@ -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
<type>(<scope>): <summary>
```
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.
+9
View File
@@ -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
+10
View File
@@ -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
+384
View File
@@ -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
<type>(<scope>): <summary>
```
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
```
+51
View File
@@ -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.
@@ -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. |
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
@@ -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. |
@@ -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. |
@@ -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. |
@@ -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. |
+86
View File
@@ -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. |
@@ -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/<category>/<lowercase-kebab-case-title>.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. |
+90
View File
@@ -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. |
@@ -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
<type>(<scope>): <summary>
```
Optional body:
```text
<type>(<scope>): <summary>
<body>
Refs: <issue or requirement IDs>
```
Breaking change format:
```text
<type>(<scope>)!: <summary>
BREAKING CHANGE: <description>
```
## 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
<type>/<short-topic>
```
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. |
+60
View File
@@ -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. |
@@ -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. |
@@ -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. |
@@ -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. |
+190
View File
@@ -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. |
+87
View File
@@ -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. |
@@ -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. |
+108
View File
@@ -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. |
@@ -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. |
+112
View File
@@ -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. |
+63
View File
@@ -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. |
+51
View File
@@ -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. |
@@ -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. |
File diff suppressed because it is too large Load Diff
File diff suppressed because it is too large Load Diff
@@ -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. |
@@ -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. |
@@ -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. |
@@ -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. |
+138
View File
@@ -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. |
@@ -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. |
+105
View File
@@ -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. |
+120
View File
@@ -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. |
+93
View File
@@ -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. |
@@ -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. |
@@ -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. |
@@ -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. |
@@ -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. |
@@ -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. |
+90
View File
@@ -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())