edison/chanora
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: restore product scaffold to rollback baseline

Browse Source
This commit is contained in:
Edison Jwa
2026-05-29 14:02:04 +09:00
parent 2896f14ec9
commit fe6e07353e
434 changed files with 27278 additions and 63230 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/verification/swe4-unit-verification-plan.md
+57
View File
@@ -0,0 +1,57 @@
# SWE.4 Unit Verification Plan
**Document status:** DV meeting baseline candidate
**Date:** 2026-05-29
**Scope:** Unit-level verification for Chanora software components
## 1. Purpose
This plan defines unit verification coverage for the software modules that implement Chanora behavior. The plan is based on the current repository state and the SRS verification hooks. It is acceptable for DV only when open unit gaps remain visible in the waiver register.
## 2. Unit Verification Scope
| Area | Components | Verification method | Current evidence |
|---|---|---|---|
| Rust core orchestration | `core/chanora_core` | Cargo unit tests, integration-oriented crate tests | `cargo test --workspace --locked --no-fail-fast` in CI |
| Protocol adapter | `crates/chanora_protocol` | Protocol DTO and error mapping tests | Workspace tests; protocol compatibility still needs SWE.5/SYS.4 evidence |
| State sync | `crates/chanora_state` | Snapshot, delta, reducer, malformed-event, reconnect, deterministic ordering, unknown-client, and channel-delete/client cleanup unit tests | Local `cargo test -p chanora_state --locked` passes with 27 tests |
| Audio subsystem | `crates/chanora_audio` | DSP, Opus, mixer, gate, PTT logic, baseline examples, benches | Workspace tests and benchmark harnesses; platform loopback evidence is integration/system scope |
| Storage | `crates/chanora_storage` | Bookmark repository, identity store, encryption behavior, keyring-disabled CI mode | Workspace tests with `CHANORA_DISABLE_KEYRING=1` in CI |
| Diagnostics | `crates/chanora_diagnostics` | Redaction, known-secret registry, diagnostic export JSON, log sink | Workspace tests and security audit plan |
| Resolver and prefetch | `crates/chanora_resolver`, `crates/chanora_server_prefetch`, Flutter prefetch debouncer | Resolver fallback, cache TTL, generation safety, debouncer tests | Workspace tests and `apps/chanora_flutter/test/services/prefetch_debouncer_test.dart` |
| Flutter services | `apps/chanora_flutter/lib/services` | Dart unit tests | Service tests under `apps/chanora_flutter/test/services/` |
| Flutter widgets | `apps/chanora_flutter/lib/widgets` and screen widgets | Widget tests | Widget tests under `apps/chanora_flutter/test/widgets/` |
## 3. Required CI Commands
| Command | Owner | Expected use |
|---|---|---|
| `cargo check --workspace --locked` | Software | Rust compile verification |
| `CHANORA_DISABLE_KEYRING=1 cargo test --workspace --locked --no-fail-fast` | Software / QA | Rust unit and crate tests without host keyring dependency |
| `cargo clippy --workspace --all-targets -- -D warnings` | Software | Advisory static analysis in current CI |
| `flutter analyze` in `apps/chanora_flutter` | Software | Dart static analysis |
| `flutter test --exclude-tags e2e` in `apps/chanora_flutter` | Software / QA | Flutter unit and widget tests |
## 4. SRS Unit Coverage Focus
| SRS group | Unit focus | Status for DV |
|---|---|---|
| SRS-036 through SRS-043 | Rust core and state behavior | Reducer unit evidence present; candidate CI/run ID still required for release record |
| SRS-054 through SRS-061 | State sync reducers and replay support | Reducer unit coverage present; standalone event replay support remains P1/not complete |
| SRS-062 through SRS-083 | Audio capture, processing, codec, playback, controls | Partial; unit and benchmark evidence exists, full platform loopback is SWE.5/SYS.4 |
| SRS-084 through SRS-095 | Storage, secure storage, diagnostics | Partial; CI avoids real keyring and must be supplemented by platform audits |
| SRS-165 through SRS-178 | Localization and Unicode handling | Partial; generated localization exists and targeted tests should be reviewed |
| SRS-184 and platform behavior items | App initialization and platform services | Partial; service tests exist for back intent, permissions, bootstrap, and lifecycle |
## 5. Known SWE.4 Gaps
| Gap | Impact | Required DV handling |
|---|---|---|
| Standalone event replay tool is not yet complete | Limits P1 replay-based state-sync verification claims | Keep event replay waiver; reducer unit evidence is available |
| Event replay tool not found | P1 verification hook is incomplete | Mark deferred/P1 in SWE.6 and waiver register if discussed |
| Platform keyring behavior not exercised in CI | Secure-storage unit evidence is incomplete for real OS services | Cover through platform audit/SYS.4, not CI-only claims |
| Audio device hot-plug recovery follow-up exists | Limits reliability evidence for SRS-082 | Mark as P1 gap |
## 6. SWE.4 DV Decision Rule
SWE.4 can pass for documentation readiness if all existing unit commands are identified and open unit gaps are listed as limitations. SWE.4 cannot be used to approve public release until required unit evidence is executed on the release candidate and attached to the release-readiness record.
docs/verification/swe5-software-integration-verification-plan.md
+58
View File
@@ -0,0 +1,58 @@
# 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_server_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 |
## 6. 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.
docs/verification/swe6-software-verification-plan.md
+62
View File
@@ -0,0 +1,62 @@
# SWE.6 Software Verification Plan
**Document status:** DV meeting baseline candidate
**Date:** 2026-05-29
**Scope:** Integrated software verification against `docs/srs.md`
## 1. Purpose
This plan verifies the integrated Chanora software against the SRS. It focuses on SRS-128 and the MVP acceptance requirements inherited from SysRS-241 through SysRS-257.
## 2. SRS Verification Strategy
| SRS area | Verification approach | Evidence source |
|---|---|---|
| Software process and traceability | Review and inspection | `docs/srs.md`, `docs/governance/traceability-matrix.md` |
| UI and app shell | Flutter widget/service tests and demo | `apps/chanora_flutter/test/` |
| Bridge and Rust core | Workspace tests and integration smoke | CI Rust job, bridge/core tests |
| Protocol and connection | Protocol integration and compatible-server demo | Protocol tests, manual server demo |
| State sync | Reducer tests, snapshot mapper tests, reconnect/error scenarios, and runtime integration evidence | Rust state tests, Flutter mapper tests, compatible-server runtime evidence |
| Audio | Audio tests, processing tests, benchmark advisory, platform demo | `chanora_audio` tests/benches and manual platform evidence |
| Storage and secure storage | Storage tests and platform secure-storage audit | Rust storage tests, platform audit |
| Diagnostics and redaction | Redaction tests, diagnostic export demo, security review | Diagnostics tests, export review |
| Platform and release | Platform smoke and release build inspection | CI, platform smoke docs, release record |
## 3. MVP Acceptance Matrix
| SysRS | Acceptance requirement | SRS coverage | Required evidence | Current DV status |
|---|---|---|---|---|
| SysRS-241 | Connect to TeamSpeak 3-compatible server using `tsclientlib` | SRS-045, SRS-046, SRS-049, SRS-050, SRS-128, SRS-134 | Compatible-server connection demo and protocol integration evidence | Passed with limitation when demo log is attached; not sufficient for public release alone |
| SysRS-242 | Display server channel tree | SRS-019 through SRS-022, SRS-054 through SRS-058, SRS-128 | UI demo, snapshot/state tests | Reducer unit evidence present; candidate UI/demo and runtime reducer-integration evidence must still be attached |
| SysRS-243 | Display online clients | SRS-019 through SRS-022, SRS-054 through SRS-058, SRS-128 | UI demo, snapshot/state tests | Reducer unit evidence present; candidate UI/demo and runtime reducer-integration evidence must still be attached |
| SysRS-244 | Allow user to join a voice channel | SRS-023, SRS-024, SRS-045 through SRS-051, SRS-128 | Channel join demo, error mapper tests | Passed with limitation when candidate demo is attached |
| SysRS-245 | Send voice | SRS-062 through SRS-071, SRS-077, SRS-079, SRS-128 | Audio loopback/platform demo | Partial; platform evidence must be attached |
| SysRS-246 | Receive voice | SRS-071 through SRS-076, SRS-078, SRS-081, SRS-128 | Audio loopback/platform demo | Partial; platform evidence must be attached |
| SysRS-247 | Support microphone mute | SRS-025, SRS-077, SRS-079, SRS-128 | UI/audio gate demo or test | Passed with limitation when candidate demo is attached |
| SysRS-248 | Support output deaf | SRS-025, SRS-078, SRS-128 | UI/audio gate demo or test | Passed with limitation when candidate demo is attached |
| SysRS-249 | Support push-to-talk | SRS-077 through SRS-079, SRS-197 through SRS-200, SRS-128 | PTT backend tests, platform capability evidence | Partial; release record must state platform capability level |
| SysRS-250 | Support Echo Canceller | SRS-064 through SRS-067, SRS-125, SRS-128 | Audio processing test/demo | Partial; attach audio evidence |
| SysRS-251 | Support Automatic Gain Control | SRS-064 through SRS-067, SRS-125, SRS-128 | Audio processing test/demo | Partial; attach audio evidence |
| SysRS-252 | Support Noise Suppression | SRS-064 through SRS-067, SRS-125, SRS-128 | Audio processing test/demo | Partial; attach audio evidence |
| SysRS-253 | Support High-Pass Filter | SRS-064 through SRS-067, SRS-125, SRS-128 | Audio processing test/demo | Partial; attach audio evidence |
| SysRS-254 | Send and receive channel text messages | SRS-019, SRS-036 through SRS-038, SRS-170 through SRS-174, SRS-128 | Chat UI tests and compatible-server demo | Passed with limitation when candidate demo is attached |
| SysRS-255 | Save and reuse server bookmarks | SRS-084 through SRS-089, SRS-128 | Storage tests and UI demo | Passed with limitation when candidate demo is attached |
| SysRS-256 | Use secure storage for sensitive data | SRS-090 through SRS-095, SRS-126, SRS-137 | Security audit and platform storage evidence | Partial; Android Keystore-backed DEK deferred |
| SysRS-257 | Export redacted diagnostic logs | SRS-028, SRS-093 through SRS-102, SRS-126, SRS-128 | Redaction tests and export demo | Passed with limitation when redaction/export evidence is attached |
## 4. Candidate Software Verification Runs
For a release decision, the following run records must be attached or linked from `docs/release/release-readiness-go-nogo-record.md`:
| Run record | Command or method | Required for |
|---|---|---|
| Rust workspace CI | `cargo check --workspace --locked` and `cargo test --workspace --locked --no-fail-fast` | All Rust-backed SRS behavior |
| Flutter CI | `flutter analyze` and `flutter test --exclude-tags e2e` | UI, service, and widget SRS behavior |
| Candidate compatible-server demo | Manual or scripted demo against a controlled TeamSpeak-compatible server | SysRS-241 through SysRS-246, SysRS-254 |
| Candidate audio demo | Manual or scripted loopback/platform run | SysRS-245 through SysRS-253 |
| Candidate diagnostics demo | Export and inspect redacted diagnostic bundle | SysRS-257, SRS-093 through SRS-102 |
| Candidate secure-storage audit | Platform inspection for Windows, macOS, Linux, iOS, Android | SysRS-256, SRS-090 through SRS-095 |
## 5. SWE.6 DV Decision Rule
SWE.6 can pass the DV meeting if the acceptance matrix is accepted as the controlling checklist and each partial item is carried into the release-readiness record. SWE.6 cannot approve public release while DEC-012, Android secure-storage limitation, platform signing, and incomplete candidate evidence remain open.
docs/verification/sys4-system-integration-verification-plan.md
+57
View File
@@ -0,0 +1,57 @@
# SYS.4 System Integration Verification Plan
**Document status:** DV meeting baseline candidate
**Date:** 2026-05-29
**Scope:** System integration verification against `docs/sysdes.md`
## 1. Purpose
This plan verifies Chanora as an integrated application system, including software, operating-system services, hardware, network dependencies, external compatible servers, diagnostics, and release operations.
## 2. System Elements Under Verification
| Element | Integration concern | Verification method |
|---|---|---|
| External TeamSpeak 3-compatible server | Connection, authentication, channel tree, clients, voice, channel text, server permissions | Compatible-server demo and protocol compatibility matrix |
| OS audio services | Capture, playback, route changes, permissions, mobile audio session, foreground behavior | Platform audio tests and manual device smoke |
| Audio hardware | Microphone/headset/speaker availability and failure handling | Platform smoke and user-safe error checks |
| Platform secure storage | Keychain/Credential Manager/Secret Service/mobile key stores and fallback behavior | Platform security audit |
| Network | DNS/SRV/TSDNS resolution, unreachable server behavior, reconnect | Resolver tests and network failure smoke |
| Platform packaging | Android, iOS, Windows, macOS, Linux build and packaging behavior | CI build, unsigned iOS build, platform smoke, release inspection |
| Diagnostics export | User-initiated export and secret redaction | Export demo and security review |
| Public wording | Non-affiliation and compatible-server claims | Legal/trademark review |
## 3. SysDes Verification Handoff Coverage
| SysDes item | Handoff | SYS.4 handling |
|---|---|---|
| SysDes-102 | Protocol verification via protocol probe and compatibility matrix | Requires compatible-server evidence and protocol adapter review |
| SysDes-103 | State verification via reducer and event replay tests | Reducer evidence handled in SWE.4/SWE.5; event replay remains P1 gap |
| SysDes-104 | Audio loopback and processing tests | Requires platform audio evidence and processing tests |
| SysDes-105 | Security audit for storage, keys, passwords, validation, redaction | Requires security/privacy/legal gate review |
| SysDes-106 | Deployment package, signing, notarization, app-store build, metadata | Release-readiness record controls final decision |
| SysDes-107 | MVP acceptance verification for SysRS-241 through SysRS-257 | SWE.6 acceptance matrix controls software evidence; SYS.4 adds environment evidence |
## 4. Platform Matrix
| Platform | Current candidate status | Required SYS.4 evidence before public/store release |
|---|---|---|
| Android | Implemented features include permissions, foreground service, Oboe audio, MODE_IN_COMMUNICATION; Android Keystore-backed DEK deferred | Device smoke, permission flow, foreground voice, secure-storage limitation waiver, Play target SDK inspection |
| iOS | Source-buildable and unsigned; AVAudioSession work exists; public artifact not ready | Unsigned build evidence, device audio session smoke, signing/TestFlight evidence before release |
| Windows | Source-buildable; smoke procedure exists | Executed smoke result, PTT capability evidence, packaging/signing evidence before release |
| macOS | Source-buildable; not in current release artifacts | Build evidence, PTT capability evidence, signing/notarization evidence before release |
| Linux | Source-buildable; GlobalShortcuts portal behavior depends on environment | Build/smoke evidence, portal/focused fallback capability evidence, packaging evidence before release |
## 5. SYS.4 Acceptance Criteria
| Criterion | Required result |
|---|---|
| External server compatibility | Candidate connects to a controlled compatible server and exercises connection, channel, voice, and text flows |
| Platform behavior transparency | Release notes and UI do not overstate platform PTT, packaging, or secure-storage capabilities |
| Security/privacy/legal readiness | DEC-012 and privacy/security gates are signed off or explicitly block release |
| Release artifact integrity | Build number, commit SHA, tag, artifact hashes, and signing status are recorded |
| Environmental limitations | Source-build-only, unsigned, or platform-specific limitations are listed in release readiness |
## 6. SYS.4 DV Decision Rule
SYS.4 can pass the documentation baseline if system integration responsibilities, platform evidence needs, and release blockers are explicit. SYS.4 cannot pass for public/store release until platform-specific evidence and legal/signing gates are complete.
docs/verification/verification-master-plan.md
+90
View File
@@ -0,0 +1,90 @@
# Chanora Verification Master Plan
**Document status:** DV meeting baseline candidate
**Date:** 2026-05-29
**Applies to:** Chanora `0.2.0-beta.1` workspace / `v1.0.0-rc.1` release-candidate evidence
**Primary upstream documents:** `docs/sysrs.md`, `docs/sysdes.md`, `docs/srs.md`, `docs/architecture/sad.md`, `docs/architecture/sdd.md`, `docs/implementation-status-2026-05-28.md`
## 1. Purpose
This plan defines the verification evidence Chanora must present at the DV meeting. It does not approve release by itself. It gives reviewers a single route from requirements and design baselines to available tests, demos, audits, waivers, and release gates.
The DV meeting may approve the verification posture for continued internal candidate work if the open gates are accepted as explicit waivers. Public or store release remains blocked until the release-readiness record reaches `Go`.
## 2. Verification Lifecycle Mapping
| Lifecycle level | Plan | Primary input | Verification focus |
|---|---|---|---|
| SWE.4 | `docs/verification/swe4-unit-verification-plan.md` | `docs/architecture/sdd.md` module behavior plus current crate and Flutter tests | Unit behavior of reducers, protocol mappers, audio processors, storage, diagnostics, UI services, and utility logic |
| SWE.5 | `docs/verification/swe5-software-integration-verification-plan.md` | `docs/architecture/sad.md` component interfaces and `docs/architecture/sdd.md` module integration hooks | Integration across Flutter, bridge, Rust core, protocol, audio, storage, diagnostics, resolver, and packaging boundaries |
| SWE.6 | `docs/verification/swe6-software-verification-plan.md` | `docs/srs.md` | Integrated software verification against SRS, especially SRS-128 MVP acceptance |
| SYS.4 | `docs/verification/sys4-system-integration-verification-plan.md` | `docs/sysdes.md` and external environment assumptions | System integration with compatible servers, OS services, hardware, network, app stores, diagnostics, and release operations |
## 3. Verification Policy
Verification evidence shall be recorded as one of these states:
| State | Meaning | DV handling |
|---|---|---|
| Passed | Evidence exists and satisfies the stated criterion | Accept as supporting evidence |
| Passed with limitation | Evidence exists, but scope is narrower than final release scope | Accept only with documented limitation |
| Not run | Criterion is defined but no run is recorded for the candidate | Requires waiver or follow-up action |
| Failed | Evidence exists and does not satisfy the criterion | Blocks the covered release scope unless waived by the release owner |
| Deferred | Requirement is intentionally outside current candidate scope | Requires requirement stage or waiver reference |
| Blocked | External decision, platform access, legal sign-off, or environment prevents completion | Requires owner and unblock condition |
No document in this pack may convert an implementation gap into a pass. Gaps must be represented as `Not run`, `Deferred`, or `Blocked`.
## 4. Current Evidence Sources
| Evidence source | Current content | DV use |
|---|---|---|
| `.github/workflows/ci.yml` | Rust workspace check/test, advisory clippy, cargo-deny, cargo-about inventory check, Flutter analyze/test, unsigned iOS release build | Build, unit, static-analysis, supply-chain, Flutter test, and iOS unsigned build evidence |
| `.github/workflows/bench-advisory.yml` | Advisory-only realtime audio benchmark workflow for PR/push events | Performance trend evidence, not a hard quality gate |
| `docs/implementation-status-2026-05-28.md` | Current implementation status, blockers, partial areas, and P1/P2 gaps | Primary readiness and waiver input |
| `apps/chanora_flutter/test/` | Flutter widget/service/e2e-labeled tests | SWE.4/SWE.5/SWE.6 evidence depending on test type |
| Rust crate tests and benches | Workspace tests plus audio benchmark harnesses | SWE.4/SWE.5 performance and component evidence |
| `tools/windows-smoke.md` | Windows source-build smoke procedure | SYS.4/SWE.5 manual platform evidence when executed |
| `docs/release/ios-build.md` | Unsigned iOS verification build note | Release and platform build evidence |
## 5. Entry Criteria for DV Review
| Criterion | Status | Evidence |
|---|---|---|
| SysRS baseline available | Met | `docs/sysrs.md` |
| SysDes baseline available | Met | `docs/sysdes.md` |
| SRS baseline available | Met | `docs/srs.md` |
| SAD baseline available | Met | `docs/architecture/sad.md` |
| SDD baseline available | Met | `docs/architecture/sdd.md` |
| Verification plans available | Met by this pack | `docs/verification/` |
| Traceability summary available | Met by this pack | `docs/governance/traceability-matrix.md` |
| Release decision record available | Met by this pack | `docs/release/release-readiness-go-nogo-record.md` |
| Open gates represented as waivers or blockers | Met by this pack | `docs/release/dv-waiver-register.md` |
## 6. Exit Criteria for DV Meeting
The DV meeting can pass the documentation baseline if reviewers agree that:
| Exit criterion | Required result |
|---|---|
| Requirements-to-verification route is reviewable | SysRS/SysDes/SRS items map to verification plans and acceptance evidence |
| MVP acceptance criteria are explicit | SysRS-241 through SysRS-257 appear in SWE.6 with evidence status |
| Verification scope is honest | Known gaps are not marked as passed |
| Waivers are explicit | Each release-affecting gap has owner, impact, mitigation, and unblock condition |
| Release recommendation is clear | Current candidate is not represented as public-release-ready while DEC-012 and other gates remain open |
## 7. Open Gates Affecting Release
| Gate | Status | Release impact | Owning document |
|---|---|---|---|
| DEC-012 legal/trademark/OSS sign-off | Blocked / open | Blocks public or store release | `docs/legal/trademark-and-attribution-review.md`, `docs/release/dv-waiver-register.md` |
| Android Keystore-backed DEK | Deferred to v1.1 | Blocks claim that Android secrets use hardware-backed DEK protection | `docs/release/dv-waiver-register.md` |
| Full state reducer test suite | Partial | Blocks full claim for SysRS-235/SysDes-103/SRS-059 through SRS-061 | `docs/release/dv-waiver-register.md` |
| Desktop and iOS release artifacts | Source-buildable / unsigned only | Blocks broad binary distribution claims | `docs/release/release-readiness-go-nogo-record.md` |
| Store signing and notarization | Not complete for candidate | Blocks production release | `docs/release/release-readiness-go-nogo-record.md` |
## 8. DV Recommendation
Recommended DV outcome: **Pass documentation baseline with release waivers recorded**.
This means the project has enough document structure to conduct DV review and continue internal candidate validation, but it does not mean the candidate is approved for public release. The release decision remains **No-Go for public/store release** until legal, signing, platform, and evidence gates are closed or formally waived by the accountable owners.