Files
chanora/docs/verification/sys4-system-integration-verification-plan.md
T
EdisonJwa 02ffadfa52 docs(ptt): land Baseline Candidate v0.9.3 — capability-based desktop PTT
Applies the gen2 desktop-PTT review summary
(`gen2/chanora-desktop-ptt-review-summary-v0.9.2.md`) to our doc set
with the owner rulings PTT-OPEN-001 through PTT-OPEN-006 resolved as
accepted decisions DEC-023 through DEC-028:

  * DEC-023 Windows Global PTT P0 / MVP
  * DEC-024 macOS Global PTT P0 / MVP with permission UX
  * DEC-025 Linux officially-tested env: GNOME on Wayland only
  * DEC-026 Mouse side buttons supported (Win + macOS; Linux portal)
  * DEC-027 PTT diagnostics: capability + availability only, no
            raw key codes ever
  * DEC-028 Missed-key-up watchdog: P0

Requirements (SysRS / SRS) and architecture (SysDes / SAD / SDD)
gain the desktop-PTT ID set the gen2 summary describes:

  SysRS-296..302  -> SysDes-142..148
                  -> SRS-195..203
                  -> SAD-071..079
                  -> SDD-081..092

ID totals advance from 295 / 141 / 194 / 70 / 80 to 302 / 148 / 203
/ 79 / 92. The strict layered sourcing rule (`SRS -> SysDes` only,
`SAD -> SRS` only, `SDD -> SAD` only) is preserved; the
`tools/validate_docs.py` validator reports zero undefined refs and
zero direct-layer-rule violations.

New document:

  * `docs/architecture/desktop-ptt-architecture.md` — capability
    ladder (L0Focused, L1GlobalShortcut, L2GlobalHoldToTalk,
    L3GlobalWithMouseButtons, L4DeviceAware reserved), Windows /
    macOS / Linux strategies, privacy rule, audio-gate rule,
    missed-key-up watchdog, release-readiness evidence requirement,
    traceability summary.

Doc addenda (Baseline Candidate 0.9.3):

  * `privacy/privacy-policy.md` — no raw key history, capability-
    dependent Global PTT, UI reflects actual runtime capability
  * `security/threat-model.md` — THREAT-PTT-001..006
  * `security/diagnostic-redaction-audit-report.md` —
    REDACT-PTT-001..006 banned field list enforced by `PttSanitizer`
  * `release/platform-release-policy.md` — per-platform evidence
    fields, no over-claim on untested Linux compositors
  * `release/release-readiness-go-nogo-record.md` — RR-PTT-001..008
    release-readiness items
  * `verification/swe4-unit-verification-plan.md` —
    SWE4-UV-035..039
  * `verification/swe5-software-integration-verification-plan.md` —
    SWE5-IV-015
  * `verification/swe6-software-verification-plan.md` — SWE6-SV-017
  * `verification/sys4-system-integration-verification-plan.md` —
    SYS4-SIV-016
  * `governance/traceability-matrix.md` — full PTT trace rows +
    verification map
  * `governance/decision-impact-assessment.md` — DEC-023..028
    impact matrix
  * `governance/product-decision-register.md` v0.9.9 entry
    recording DEC-023..028 in the decision table and the status
    table at §7
  * `governance/document-index.md` — adds
    `desktop-ptt-architecture.md` to the controlled set
  * `architecture/proof-of-concept-plan.md` —
    PoC-PTT-001..005 platform items
  * `references/external-references.md` — Windows Raw Input,
    macOS event-tap, Linux GlobalShortcuts portal references
  * Both validation reports
    (`baseline-candidate-validation-report.md`,
    `repo-format-validation-report.md`) bumped to v0.9.3 with the
    new ID totals (302 / 148 / 203 / 79 / 92).

README §"Desktop Push-to-Talk" added between Architecture Overview
and Repository Layout: capability levels, per-platform strategy,
privacy posture, missed-key-up watchdog.

Tooling:

  * `tools/validate_docs.py` copied from the gen2 zip into the
    repo tree (was previously available only inside the zip).
    Reports zero undefined refs, zero direct-layer-rule violations,
    English-only CJK check passes. The 35 "old package-style
    filename" hits are pre-existing and identical to the gen2
    baseline (they live in `path-migration-map.md` and config-ID
    headers of governance docs and are intentional per the path
    migration policy).
  * `.gitignore` adds `/gen2/` so the externally-provided review
    package does not enter the repo.

No code changes in this commit; B (the implementation split into
`transmit_active` / `capture_active`, `PttCapabilityLevel`
reporting, `PttSanitizer` diagnostics rule, and the UI capability
badge) follows in a separate commit.
2026-05-15 14:51:22 +08:00

11 KiB

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.

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

SYS4-SIV-016: Verify integrated system-level desktop Push-to-Talk behaviour against SysDes-142 through SysDes-148.

  • Source SysDes: SysDes-142, SysDes-143, SysDes-144, SysDes-145, SysDes-146, SysDes-147, SysDes-148
  • Verification method: System integration verification on Windows, macOS, GNOME-on-Wayland reference hosts
  • Pass criteria: Platform PTT Backend layer is the only surface generating PTT state transitions; PttCapabilityLevel and backend_id propagate from backend through Rust Core through bridge to Flutter UI without modification; transmit_active and capture_active are observably independent at the system boundary; diagnostics sanitizer rejects raw key payloads; UI capability badge matches the active capability; release readiness record carries the live-measurement evidence per RR-PTT-001..008.
  • Evidence: SYS.4 verification report
SysDes Range SYS.4 Coverage
SysDes-133 through SysDes-141 SYS4-SIV-015
SysDes-142 through SysDes-148 SYS4-SIV-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.

Baseline Candidate 0.9.3 Update

Version Date Description
0.9.3 2026-05-15 Added desktop PTT system-integration verification item SYS4-SIV-016 covering SysDes-142..148 across Windows, macOS, and GNOME-on-Wayland Linux reference hosts.