72 lines
5.7 KiB
Markdown
72 lines
5.7 KiB
Markdown
# 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.
|