Files

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

10 KiB

Raw Blame History

Chanora SWE.6 Software Verification Plan

Document type: Software Verification / Software Qualification Test Plan
Process alignment: ASPICE SWE.6 Software Verification
Version: 0.9.2 Status: Baseline Candidate
Language: English
Product: Chanora
Verification object: Fully integrated Chanora software
Direct source layer: SRS

Repo path: docs/verification/swe6-software-verification-plan.md ---

1. Purpose

This document defines the software verification strategy for Chanora. It verifies that the fully integrated software satisfies the Software Requirements Specification.

SysRS -> SysDes -> SRS -> SAD -> SDD
                 -> SWE.6 Software Verification

SWE.6 verifies against SRS. It does not replace SWE.4 unit verification or SWE.5 software integration verification.

2. Software Verification Strategy

Verification type	Purpose
Functional software tests	Verify integrated software behavior against SRS
Non-functional software tests	Verify performance, accessibility, security, diagnostics, localization, and reliability requirements
Platform software tests	Verify integrated software behavior on target platforms
Regression tests	Confirm changes did not break previously verified software requirements
Release-scope test selection	Select tests according to target release content
Summary reporting	Communicate software verification status

3. Software Verification Measures

SWE6-SV-001: Verify server connection flow.

Source SRS: SRS-001 through SRS-030
Verification method: End-to-end software test
Pass criteria: User can connect to a compatible server with configured connection data.
Evidence: Software verification result

SWE6-SV-002: Verify channel tree, client list, and server state display.

Source SRS: SRS-031 through SRS-060
Verification method: End-to-end software test
Pass criteria: Channel and client state is displayed and updates after server events.
Evidence: Software verification result

SWE6-SV-003: Verify voice send and receive.

Source SRS: SRS-061 through SRS-090
Verification method: Audio software verification test
Pass criteria: User can transmit and receive voice under supported conditions.
Evidence: Software verification result

SWE6-SV-004: Verify push-to-talk, mute, deaf, and voice status.

Source SRS: SRS-061 through SRS-090, SRS-156
Verification method: End-to-end software test
Pass criteria: Voice controls perform expected software behavior and display correct state.
Evidence: Software verification result

SWE6-SV-005: Verify local storage and secure storage behavior.

Source SRS: SRS-091 through SRS-110
Verification method: Software security and persistence test
Pass criteria: Non-secret data persists through approved storage and secrets use secure storage boundaries.
Evidence: Software verification result

SWE6-SV-006: Verify diagnostics and redacted export behavior.

Source SRS: SRS-111 through SRS-124, SRS-177, SRS-178
Verification method: Software verification test, audit
Pass criteria: Diagnostic export requires user action and redacts sensitive data while preserving safe Unicode content.
Evidence: Software verification result, audit record

SWE6-SV-007: Verify deployment-sensitive software behavior.

Source SRS: SRS-125 through SRS-134
Verification method: Release build verification
Pass criteria: Release build metadata, packaging behavior, and platform declarations are consistent with software requirements.
Evidence: Release verification result

SWE6-SV-008: Verify traceability and documentation controls.

Source SRS: SRS-135 through SRS-143, SRS-180 through SRS-183
Verification method: Documentation verification
Pass criteria: SRS, SAD, and SDD direct-source rules pass validation.
Evidence: Traceability report

SWE6-SV-009: Verify Material 3 and Chanora Design System behavior.

Source SRS: SRS-144 through SRS-150
Verification method: UI software verification, review
Pass criteria: Integrated app uses Material 3 baseline and Chanora semantic tokens without feature-screen hardcoding.
Evidence: Software verification result

SWE6-SV-010: Verify adaptive layouts.

Source SRS: SRS-151 through SRS-156
Verification method: UI software verification
Pass criteria: Compact, medium, and expanded layouts preserve connection status and primary voice controls.
Evidence: Software verification result

SWE6-SV-011: Verify accessibility behavior.

Source SRS: SRS-157 through SRS-161
Verification method: Accessibility verification
Pass criteria: Critical controls expose semantics, non-color-only state cues, focus behavior, and text-scale resilience.
Evidence: Accessibility verification result

SWE6-SV-012: Verify platform behavior.

Source SRS: SRS-162 through SRS-164
Verification method: Platform software verification
Pass criteria: Insets, safe areas, keyboard, Android back behavior, and iOS platform behavior operate as specified.
Evidence: Platform verification result

SWE6-SV-013: Verify localization and fallback behavior.

Source SRS: SRS-165 through SRS-169
Verification method: Localization software verification
Pass criteria: Product strings are externalized, English baseline exists, additional locales can be added, and fallback is deterministic.
Evidence: Localization verification result

SWE6-SV-014: Verify Unicode and server-content behavior.

Source SRS: SRS-170 through SRS-176
Verification method: Internationalization software verification
Pass criteria: Server content is preserved, displayed without translation, UTF-8 is used internally, and locale-aware formatting works.
Evidence: Internationalization verification result

SWE6-SV-015: Verify software architecture and detailed design traceability controls.

Source SRS: SRS-180 through SRS-184
Verification method: Documentation/tooling verification
Pass criteria: SAD derives from SRS and SDD derives from SAD; initialization sequence is verified.
Evidence: Traceability validation result

4. Regression Strategy

Regression test selection shall consider:

changed SRS item
changed feature
changed architecture component
changed detailed design unit
changed platform behavior
changed localization or Unicode handling
changed diagnostics or redaction
changed audio behavior
changed protocol adapter behavior

5. Traceability Matrix

SRS Range	SWE.6 Coverage
SRS-001 through SRS-030	SWE6-SV-001
SRS-031 through SRS-060	SWE6-SV-002
SRS-061 through SRS-090	SWE6-SV-003, SWE6-SV-004
SRS-091 through SRS-110	SWE6-SV-005
SRS-111 through SRS-124	SWE6-SV-006
SRS-125 through SRS-134	SWE6-SV-007
SRS-135 through SRS-143	SWE6-SV-008
SRS-144 through SRS-150	SWE6-SV-009
SRS-151 through SRS-156	SWE6-SV-010
SRS-157 through SRS-161	SWE6-SV-011
SRS-162 through SRS-164	SWE6-SV-012
SRS-165 through SRS-169	SWE6-SV-013
SRS-170 through SRS-176	SWE6-SV-014
SRS-177 through SRS-184	SWE6-SV-006, SWE6-SV-015

6. Result Reporting

Software verification results shall be summarized in a software verification summary report including:

release scope
selected software verification measures
skipped measures and rationale
platform/environment used
pass/fail status
nonconformances
regression scope
residual risks
release recommendation

7. Change History

Version	Date	Description
0.1.0	2026-05-14	Initial SWE.6 software verification plan derived from SRS v0.5.

8. Platform Decision Software Verification Addendum

SWE6-SV-016: Verify platform baseline, release SDK gates, single connection MVP scope, audio defaults, storage/bridge policy, and diagnostics/crash reporting policy.

Source SRS: SRS-185 through SRS-194
Verification method: Software verification, release inspection, security/privacy review
Pass criteria: Integrated software and release configuration satisfy the accepted product decisions.
Evidence: Software verification result, release inspection record

SRS Range	SWE.6 Coverage
SRS-185 through SRS-194	SWE6-SV-016

SWE6-SV-017: Verify integrated software behaviour for desktop Push-to-Talk against SRS-195 through SRS-203.

Source SRS: SRS-195, SRS-196, SRS-197, SRS-198, SRS-199, SRS-200, SRS-201, SRS-202, SRS-203
Verification method: Software verification test (end-to-end) on Windows, macOS, GNOME-on-Wayland reference hosts
Pass criteria: PTT trait abstraction is platform-agnostic from the caller's perspective; reported capability level equals live runtime behaviour; Windows ladder degrades correctly when Raw Input is denied; macOS Global ↔ Focused toggles with permission state changes; Linux honours portal availability; mouse-side-button binding works where the backend exposes it; capture_active and transmit_active are independently observable; diagnostic export contains zero raw key data; missed-key-up watchdog clears transmit_active after the configured timeout.
Evidence: SWE.6 test report

SRS Range	SWE.6 Coverage
SRS-185 through SRS-194	SWE6-SV-016
SRS-195 through SRS-203	SWE6-SV-017

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-verification item SWE6-SV-017 covering end-to-end SRS-195..203 verification across Windows, macOS, and GNOME-on-Wayland Linux reference hosts.

10 KiB Raw Blame History