chanora/docs/verification/swe5-software-integration-verification-plan.md

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.

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).