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

**SWE5-IV-015**: Verify integrated desktop PTT subsystem (audio engine, Rust core PTT controller, bridge, Flutter UI, diagnostics).

- Source SAD: SAD-071 through SAD-079
- Source SDD: SDD-081 through SDD-092
- Verification method: Software integration test on every supported desktop reference host (Windows, macOS, GNOME-on-Wayland Linux)
- Pass criteria: For each platform the live measurement of `PttCapabilityLevel` and `backend_id` matches the design expectation; pressing the bound input toggles `transmit_active` end-to-end; the missed-key-up watchdog clears `transmit_active` after the configured timeout; the user-initiated diagnostic export does not contain raw key data; the UI capability badge matches the active capability.
- Evidence: Integration test trace, diagnostic-export inspection, UI screenshot

| Architecture / Design Area | SWE.5 Coverage |
|---|---|
| SAD-061 through SAD-070 | SWE5-IV-014 |
| SDD-071 through SDD-080 | SWE5-IV-014 |
| SAD-071 through SAD-079 | SWE5-IV-015 |
| SDD-081 through SDD-092 | SWE5-IV-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. |


## Baseline Candidate 0.9.3 Update

| Version | Date | Description |
|---|---|---|
| 0.9.3 | 2026-05-15 | Added desktop PTT software-integration verification item SWE5-IV-015 covering the integrated audio engine + Rust core PTT controller + bridge + Flutter UI + diagnostics path on Windows, macOS, and GNOME-on-Wayland Linux reference hosts. |


## 9. Android P0 Software Integration Verification Addendum

**SWE5-IV-016**: Verify Android JNI bootstrap → foreground service lifecycle integration.

- Source SAD: SAD-077, SAD-081
- Source SDD: SDD-105, SDD-107
- Verification method: Instrumented integration test on a physical API 28 device
- Pass criteria: `Application.onCreate` loads `libchanora_bridge.so`, `JNI_OnLoad` captures the `JavaVM`, the bridge is initialized, and `AndroidVoiceForegroundService` can be started by the Rust core (via JNI callback) without re-loading the library or racing init. Service start completes before the first audio frame is produced.
- Evidence: Integration test result + logcat trace

**SWE5-IV-017**: Verify permission denial → foreground service not started → listen-only stream open integration.

- Source SAD: SAD-077
- Source SDD: SDD-106, SDD-107
- Source SRS: SRS-209
- Verification method: Integration test using permission-state test double + real audio stack
- Pass criteria: When `RECORD_AUDIO` is denied (or revoked mid-session) the FGS is NOT started for capture; the playback stream remains open so the user hears other participants (listen-only fallback per SRS-209); UI surfaces the degraded state; re-granting permission re-enables capture without process restart.
- Evidence: Integration test result

**SWE5-IV-018**: Verify foreground service start triggers audio mode acquisition; service stop triggers mode restore.

- Source SAD: SAD-081, SAD-085
- Source SDD: SDD-107, SDD-108
- Source SRS: SRS-208
- Source SysRS: SysRS-305
- Verification method: Integration test on a physical device with `dumpsys audio` snapshots before / during / after
- Pass criteria: Before voice channel join, `AudioManager.mode` is the device baseline. After FGS start and join, mode is `MODE_IN_COMMUNICATION`. After leave/disconnect, FGS stops and the controller restores the snapshotted prior mode. Refcount holds across rapid join/leave/join cycles.
- Evidence: Integration test result + `dumpsys audio` traces

**SWE5-IV-019**: Verify `BackIntentService` integration with the Flutter Navigator route stack.

- Source SAD: SAD-018
- Source SDD: SDD-028 (expanded)
- Source SRS: SRS-163
- Verification method: Flutter integration test on Android with a non-trivial route stack (home → channel → settings → modal)
- Pass criteria: System back closes modal first (does not pop the route); subsequent back pops one route per press; at the home route system back backgrounds the activity. PTT-active-ignore: while the test driver asserts `transmit_active`, back is consumed. API 33+ and pre-33 code paths both produce identical end states (verified on at least one device per branch).
- Evidence: Integration test result

**SWE5-IV-020**: Verify AAB build pipeline integration (`SDD-109`).

- Source SAD: SAD-063
- Source SDD: SDD-073, SDD-109
- Source SRS: SRS-119, SRS-188
- Verification method: CI build job + `bundletool` validation
- Pass criteria: `flutter build appbundle --release` produces an AAB; `bundletool validate` reports no errors; `bundletool build-apks --connected-device` produces per-ABI splits for `{arm64-v8a, armeabi-v7a, x86_64}`; signing key fingerprint matches the CI release-key reference; `targetSdkVersion` matches the SRS-188 declared target; `minSdkVersion` == 28 (DEC-004); manifest contains `FOREGROUND_SERVICE` + `FOREGROUND_SERVICE_MICROPHONE` (API 34+) + `RECORD_AUDIO` permissions and no others outside the allow-list.
- Evidence: CI artifact + bundletool report

| Architecture / Design Area | SWE.5 Coverage |
|---|---|
| SAD-018, SAD-063, SAD-077, SAD-081, SAD-084, SAD-085, SAD-086 | SWE5-IV-016 through SWE5-IV-020 |
| SDD-028 (expanded), SDD-073 (refreshed), SDD-105, SDD-106, SDD-107, SDD-108, SDD-109, SDD-110 | SWE5-IV-016 through SWE5-IV-020 |


### Android voice audio backend integration items (SDD-111..SDD-116 wave)

**SWE5-IV-021**: Verify `MobileVoiceAudioBackend` trait + audio engine integration on voice_join / voice_leave.

- Source SAD: SAD-077, SAD-081
- Source SDD: SDD-111 (trait surface), SDD-112 (config), SDD-115 (lifecycle)
- Source SRS: SRS-210, SRS-211, SRS-213, SRS-214
- Verification method: Rust integration test on a physical Android device (API 31 mid-tier minimum) driving the engine through `voice_join` / `voice_leave` against the real `AndroidVoiceUnit`
- Pass criteria: `voice_join` constructs `AndroidVoiceStreamConfig` from engine state, calls `AndroidVoiceUnit::open(...)`, opens BOTH input and output streams (verified by `session_id()` being `Some(_)` and the output-stream handle being non-null), then calls `start()`. Engine state transitions are observed in order: `Idle → Opening → Running`. `voice_leave` calls `stop()` then `close()` in that order; engine state returns to `Idle`. No stream is left open after `voice_leave` (verified by a follow-up `voice_join` succeeding with a fresh session id).
- Evidence: Integration test result + logcat with engine state transition lines
- SDD-116 matrix rows satisfied: all (open/close path exercised on every matrix device)

**SWE5-IV-022**: Verify SDD-108 audio-mode engagement precedes SDD-113 effect binding (forward) and effects release precedes mode restore (reverse).

- Source SAD: SAD-077, SAD-081, SAD-085
- Source SDD: SDD-108, SDD-113, SDD-115 (sequencing)
- Source SRS: SRS-208, SRS-212
- Verification method: Integration test instrumented with ordered event sink (timestamped events for `mode_engage`, `stream_open`, `effect_attach`, `start`, `stop`, `effect_release`, `stream_close`, `mode_restore`)
- Pass criteria: On `voice_join`, the recorded order is exactly `FGS_start → stream_open → mode_engage → effect_attach → start`. On `voice_leave`, the recorded order is exactly `stop → effect_release → mode_restore → stream_close → FGS_stop` per SDD-115 item 3 (reverse-order teardown). Any deviation fails the case. Test repeats 3 rapid join/leave cycles to surface refcount or sequencing races.
- Evidence: Integration test result + event-sink dump
- SDD-116 matrix rows satisfied: all

**SWE5-IV-023**: Verify SDD-115 full lifecycle sequencing forward and reverse.

- Source SAD: SAD-077, SAD-081
- Source SDD: SDD-107, SDD-108, SDD-111, SDD-113, SDD-115
- Source SRS: SRS-208, SRS-210, SRS-212, SRS-215
- Verification method: Instrumented integration test on physical device
- Pass criteria: Forward sequence: `FGS_start → streams_open → mode_engage → effects_bind → start_capture+playback`. Reverse sequence: `stop → effects_release → mode_restore → streams_close → FGS_stop`. Test asserts strict ordering AND that no event from one step occurs before the previous step completes (no overlap). Test re-runs across at least one API 28 device and one API 34 device to cover the FGS-type tightening branch.
- Evidence: Integration test result + ordered event log
- SDD-116 matrix rows satisfied: API 28 row, API 31 row, API 34 row

**SWE5-IV-024**: Verify audio-focus loss handling.

- Source SAD: SAD-077, SAD-081, SAD-085
- Source SDD: SDD-115 (audio focus event response)
- Source SRS: SRS-208, SRS-215
- Verification method: Integration test using a controllable secondary audio source (test app that requests focus with the three loss kinds)
- Pass criteria: `AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK` → capture and playback continue at unchanged level (Chanora does not duck itself; voice content is exempt per SDD-115). `AUDIOFOCUS_LOSS_TRANSIENT` → capture is paused (no frames produced upstream) and playback is paused; on focus regain, both resume without `voice_leave`/`voice_join`. `AUDIOFOCUS_LOSS` (permanent) → the session is left cleanly (effects released, mode restored, streams closed) and the user is surfaced an "audio focus lost" state; no auto-rejoin.
- Evidence: Integration test result + logcat
- SDD-116 matrix rows satisfied: at least API 31 + API 34 rows

**SWE5-IV-025**: Verify `ErrorDisconnected` callback marshals to tokio task and triggers reopen without blocking the callback thread.

- Source SAD: SAD-077, SAD-081
- Source SDD: SDD-111 (error/disconnect callback via bounded channel/watch), SDD-115 (recovery on disconnect)
- Source SRS: SRS-210, SRS-215
- Verification method: Integration test injecting a forced disconnect (e.g. unplug Bluetooth headset mid-session, or invoke an Oboe error-callback fault injection point)
- Pass criteria: The Oboe `onErrorBeforeClose` / `onErrorAfterClose` callback path enqueues a message onto the bounded channel and returns within the callback's documented latency budget (assert: callback returns in < 5 ms). Reopen is performed on a tokio task on the engine runtime, not on the callback thread (verified by thread-id capture in test). Reopen completes (`voice_join` round-trip on the new device route) within 2 s. The callback never holds a lock during reopen.
- Evidence: Integration test result + thread-id capture log
- SDD-116 matrix rows satisfied: all (regression surface)

**SWE5-IV-026**: Verify permission-denied `voice_join` reports listen-only and does NOT start the foreground service for capture.

- Source SAD: SAD-077
- Source SDD: SDD-106, SDD-107, SDD-111, SDD-115
- Source SRS: SRS-209, SRS-215
- Verification method: Integration test with `RECORD_AUDIO` denied via permission test double
- Pass criteria: `voice_join` opens the output (playback) stream and engine state becomes `RunningListenOnly`. `AndroidVoiceForegroundService` is NOT started with `foregroundServiceType="microphone"` for capture (the service may still run as a non-mic FGS for playback longevity per SDD-107 policy — if SDD-107 declines this, the FGS is not started at all). Backend reports `capture_state = ListenOnly`. No `AndroidVoiceUnit` input stream is opened. UI badge reflects listen-only. On runtime permission grant, the engine performs an internal upgrade to full duplex without process restart and without losing the playback stream. Cross-link: builds on SWE5-IV-017.
- Evidence: Integration test result + logcat + UI screenshot
- SDD-116 matrix rows satisfied: API 28 row, API 34 row (FGS-type tightening branch)

| Architecture / Design Area | SWE.5 Coverage |
|---|---|
| SAD-077, SAD-081 (mobile voice audio backend allocation) | SWE5-IV-021 through SWE5-IV-026 |
| SDD-111, SDD-112, SDD-113, SDD-115 | SWE5-IV-021 through SWE5-IV-026 |
| SDD-116 (device matrix coverage entry points) | SWE5-IV-021, SWE5-IV-023 |


## Baseline Candidate 0.9.4 Update

| Version | Date | Description |
|---|---|---|
| 0.9.4 | 2026-05-18 | Added Android P0 software-integration items SWE5-IV-016..SWE5-IV-020 covering JNI+FGS, permission+FGS+listen-only fallback, FGS+audio-mode round-trip, BackIntentService + Flutter route stack, and AAB build pipeline (bundletool + ABI splits). |
| 0.9.5 | 2026-05-18 | Added Android voice audio backend integration items SWE5-IV-021..SWE5-IV-026 covering MobileVoiceAudioBackend trait + engine wiring (SDD-111), SDD-108↔SDD-113 ordering and reverse-order teardown (SDD-115), full lifecycle sequencing across SDD-107/108/111/113, audio-focus loss handling, ErrorDisconnected callback marshaling, and permission-denied listen-only fallback. Cross-links: SWE5-IV-017 extended by SWE5-IV-026 (listen-only fallback). |