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

SWE.5 Software Integration Verification Plan

Document status: DV meeting baseline candidate
Date: 2026-05-29
Scope: Integration verification across Chanora software components

1. Purpose

This plan defines how Chanora verifies that independently tested software components work together. It covers the integration paths identified by SRS section 8 and SysDes verification handoff items.

2. Integration Paths

Integration path	Covered components	Primary requirements	Evidence method
Flutter to bridge to Rust core	Flutter UI/state, generated FRB bindings, chanora_bridge, chanora_core	SRS-031 through SRS-035, SRS-103	Flutter integration tests, Rust bridge tests, manual candidate smoke
Core to protocol adapter	chanora_core, chanora_protocol, tsclientlib	SRS-044 through SRS-053, SRS-131, SRS-134	Protocol integration tests and compatible-server demo
Protocol to state	Protocol events, Rust core state handling, chanora_state, Flutter snapshot mapper	SRS-054 through SRS-061, SRS-124	Reducer tests, snapshot mapper tests, reconnect/error tests
Audio to platform	chanora_audio, OS audio APIs, Flutter voice controls, platform permissions	SRS-062 through SRS-083, SRS-104 through SRS-115, SRS-135	Audio loopback tests, platform smoke, mobile device tests
Storage to platform secure storage	chanora_storage, keyring adapters, Flutter bookmark/identity UI	SRS-084 through SRS-095, SRS-126, SRS-137	Storage tests, platform secure-storage audit
Diagnostics export	Diagnostics crate, Flutter diagnostics UI, redaction, share/export surface	SRS-095 through SRS-102, SRS-126, SRS-128	Redaction tests, diagnostic export review, manual export demo
Server resolution prefetch	Flutter host-field debouncer, chanora_prefetch, chanora_resolver, connect path	Resolver/prefetch design specs and connection requirements	Unit tests, Android connect smoke, manual connect demo
Packaging and release build	Flutter build, Rust cdylib/framework/DLL/SO packaging, CI workflows	SRS-116 through SRS-123, SRS-127	CI build evidence, unsigned iOS build, platform-specific smoke

3. Required Integration Evidence

Evidence	Current state	DV conclusion
CI Rust workspace test run	Defined in .github/workflows/ci.yml	Accept as automated baseline when latest run is attached
CI Flutter analyze/test run	Defined in .github/workflows/ci.yml	Accept as automated baseline when latest run is attached
iOS unsigned release build	Defined in .github/workflows/ci.yml and docs/release/ios-build.md	Accept for unsigned build verification only
Audio benchmark advisory	Defined in .github/workflows/bench-advisory.yml	Accept as advisory performance evidence, not a release blocker
Windows smoke procedure	Defined in tools/windows-smoke.md	Accept only when an executed result is attached
Android connect and permission smoke	Referenced by implementation status and tests	Requires executed evidence for release decision

4. Integration Acceptance Criteria

An integration path passes when:

Criterion	Requirement
Buildability	Integrated components compile in CI or on the declared target build host
Data contract stability	DTOs and bridge boundaries preserve required fields and error states
Error behavior	Integration failures produce user-safe errors, not crashes or secret leakage
Platform behavior	Platform-specific permission, audio, and lifecycle behavior matches the target platform policy
Evidence attachment	Test logs, CI run IDs, smoke records, or manual demo notes are referenced in the release-readiness record

5. Known SWE.5 Gaps

Gap	Impact	Required DV handling
Desktop release artifacts are source-buildable only for current candidate	Blocks binary distribution readiness for Windows/macOS/Linux	Release record must state source-build-only scope
iOS build is unsigned	Blocks App Store/TestFlight release approval	Release record must state unsigned verification only
Android Keystore-backed DEK deferred	Limits secure-storage integration claim on Android	Waiver required for internal testing; public release claim blocked
Event replay infrastructure not found	Limits protocol-state integration stress evidence	Mark P1 gap
Android target compile/runtime blocked during local review	Missing NDK compiler aarch64-linux-android-clang and no attached authorized target block device/emulator verification of Android audio, permission, lifecycle, and storage fail-safe behaviour	Fix/install the NDK toolchain, connect a device/emulator, confirm with adb devices -l, then run Android build/install/smoke before claiming Android success

6. Android Runtime Verification Gate

Android integration changes require a working Android target toolchain and a connected device or emulator. The minimum local gate is:

1. The Android NDK compiler needed by the target build, including aarch64-linux-android-clang for arm64, is available.
2. adb devices -l shows one authorized target.
3. Android app builds for that target.
4. The app installs and launches.
5. Permission, connect-screen, audio-start/stop, and diagnostic-export smoke paths are exercised or explicitly marked not applicable to the change.

If the NDK compiler is unavailable or no target is connected and authorized, Android verification is blocked rather than passed.

7. SWE.5 DV Decision Rule

SWE.5 can pass for DV documentation readiness if every integration path has an identified evidence method and every incomplete path has a waiver or follow-up. SWE.5 does not pass for public release until current candidate integration runs are attached to the release-readiness record.