chore: restore product scaffold to rollback baseline
This commit is contained in:
Edison Jwa
@@ -0,0 +1,35 @@
|
||||
# Chanora DV Waiver Register
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
**Applies to:** DV review and internal candidate validation only
|
||||
|
||||
## 1. Waiver Policy
|
||||
|
||||
A waiver records a known gap that reviewers may accept for a limited decision scope. A waiver does not delete the underlying requirement and does not approve public/store release unless the release owner explicitly accepts that scope.
|
||||
|
||||
## 2. Active Waivers and Deferrals
|
||||
|
||||
| ID | Gap | Source evidence | Impact | Accepted DV scope | Unblock condition |
|
||||
|---|---|---|---|---|---|
|
||||
| DV-WVR-001 | DEC-012 legal/trademark/OSS review remains open | `docs/implementation-status-2026-05-28.md` | Blocks public/store release and final compatible-server wording approval | Documentation review and internal validation only | Legal/trademark/OSS owner signs off and required notices/reports are complete |
|
||||
| DV-WVR-002 | Android Keystore-backed DEK deferred to v1.1 | `docs/implementation-status-2026-05-28.md` | Limits Android secure-storage claim; file-fallback DEK remains a release risk | Internal validation only with limitation stated | Android Keystore-backed DEK implemented or product/security owner accepts release waiver |
|
||||
| DV-WVR-003 | iOS `AVAudioSession.Mode.voiceChat` status was recorded as a prior blocker but recent commit history indicates follow-up implementation | `docs/implementation-status-2026-05-28.md`, recent commit `feat(ios): use AVAudioSession .voiceChat mode` | Requires updated validation so documents and implementation status do not conflict | DV may proceed if treated as evidence-needs-validation, not as a closed release gate | Run iOS device audio verification and update implementation status |
|
||||
| DV-WVR-004 | Standalone event replay and runtime reducer-integration evidence not yet complete | `docs/implementation-status-2026-05-28.md`, local `cargo test -p chanora_state --locked` evidence | Reducer unit coverage supports state synchronization, but file-based replay evidence and live-event integration evidence remain open | DV documentation pass and internal validation | Event replay tooling implemented or requirement reprioritized; runtime reducer integration evidence attached |
|
||||
| DV-WVR-005 | Event replay tool not found | `docs/implementation-status-2026-05-28.md` | Limits P1 state verification hooks SRS-061/SRS-098 | Accepted as P1 deferral | Event replay tooling implemented or requirement reprioritized |
|
||||
| DV-WVR-006 | Desktop and iOS artifacts are source-buildable or unsigned only | `docs/implementation-status-2026-05-28.md`, `docs/release/ios-build.md` | Blocks packaged public release claims | Internal validation from source/unsigned builds only | Signed/notarized/package artifacts exist and hashes are recorded |
|
||||
| DV-WVR-007 | Silero VAD asset bundled while `VoiceActivity` is deferred | `docs/implementation-status-2026-05-28.md` | Risk that UI/release wording overstates VAD availability | DV may pass if VoiceActivity remains disabled/coming-soon | VAD implementation allocated in a later baseline or asset/wording reconciled |
|
||||
| DV-WVR-008 | Artifact hashes, tag, and candidate run IDs are not recorded in release record | `docs/release/release-readiness-go-nogo-record.md` | Blocks final release approval and reproducibility | DV documentation review only | Candidate build run records, tag, commit SHA, and artifact hashes are recorded |
|
||||
|
||||
## 3. Waiver Review Rules
|
||||
|
||||
| Rule | Required behavior |
|
||||
|---|---|
|
||||
| Scope control | Waivers in this file apply to DV/internal validation unless explicitly promoted by release owner approval |
|
||||
| User-visible claims | Release notes, UI, and marketing wording must not claim unsupported capabilities |
|
||||
| Security/legal claims | Security, privacy, legal, and OSS claims require owner sign-off before public release |
|
||||
| Closure | A waiver closes only when the unblock condition is satisfied and the release-readiness record is updated |
|
||||
|
||||
## 4. DV Meeting Recommendation
|
||||
|
||||
Accept the waiver register for DV documentation pass. Do not accept these waivers as public/store release approval.
|
||||
@@ -1,102 +0,0 @@
|
||||
# Chanora Linux build notes
|
||||
|
||||
This document covers the current Linux desktop build and packaging flow for
|
||||
`apps/chanora_flutter`.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Linux host with desktop Flutter support enabled
|
||||
- Rust stable
|
||||
- Flutter stable on `PATH`
|
||||
- CMake 3.13+
|
||||
- `pkg-config`
|
||||
- GTK3 development headers
|
||||
- Opus development headers that expose the `opus` pkg-config module used by
|
||||
tsclientlib/audiopus for Linux audio encode/decode
|
||||
- PipeWire development headers that expose the `libpipewire-0.3` and
|
||||
`libspa-0.2` pkg-config modules used by the primary Linux voice backend
|
||||
- PulseAudio development headers for the fallback Linux voice backend
|
||||
- `clang` and `gcc`
|
||||
- sibling checkout of `oboe-rs` at `../oboe-rs`
|
||||
|
||||
Install `opus-devel` on Fedora-style hosts or `libopus-dev` on Debian/Ubuntu.
|
||||
The workspace does not vendor or patch Opus for Linux; the normal Linux build
|
||||
links the system `libopus` through `pkg-config`.
|
||||
|
||||
For Linux audio specifically, the product uses PipeWire directly as the primary
|
||||
backend and PulseAudio directly as the fallback. If you want a fast preflight,
|
||||
these are the package checks that matter:
|
||||
|
||||
```bash
|
||||
pkg-config --modversion gtk+-3.0
|
||||
pkg-config --modversion opus
|
||||
pkg-config --modversion libpipewire-0.3
|
||||
pkg-config --modversion libspa-0.2
|
||||
pkg-config --modversion libpulse
|
||||
pkg-config --modversion libpulse-simple
|
||||
```
|
||||
|
||||
Use `libpipewire-0.3`, not `pipewire-0.3`. The latter probe will fail even on a
|
||||
correctly provisioned host because it is not the module name exported by the
|
||||
PipeWire development package.
|
||||
|
||||
## Bundled ONNX Runtime
|
||||
|
||||
Linux release builds include ONNX Runtime for Silero VAD by default. The build
|
||||
helper downloads the official Linux CPU archive into `.cache/onnxruntime/` for
|
||||
the current target architecture and stages `libonnxruntime.so` into the app
|
||||
bundle.
|
||||
|
||||
To pin a specific ONNX Runtime release, export:
|
||||
|
||||
```bash
|
||||
export CHANORA_ONNXRUNTIME_VERSION=1.26.0
|
||||
```
|
||||
|
||||
To use a local shared library instead of downloading the archive, export:
|
||||
|
||||
```bash
|
||||
export CHANORA_ONNXRUNTIME_SHARED_LIB=/absolute/path/to/libonnxruntime.so
|
||||
```
|
||||
|
||||
When set, the Flutter Linux bundle will include:
|
||||
|
||||
```text
|
||||
build/linux/x64/<mode>/bundle/lib/libonnxruntime.so
|
||||
```
|
||||
|
||||
and the Linux runner will set `ORT_DYLIB_PATH` to that bundled file at app
|
||||
startup when the variable is not already present.
|
||||
|
||||
## Build helper
|
||||
|
||||
From the repository root:
|
||||
|
||||
```bash
|
||||
./tools/build-linux.sh
|
||||
```
|
||||
|
||||
The Flutter Linux CMake bundle now owns staging `libchanora_bridge.so` into
|
||||
`bundle/lib/`. A plain `flutter build linux` will build the host-profile Rust
|
||||
bridge automatically; `tools/build-linux.sh` exports
|
||||
`CHANORA_BRIDGE_SHARED_LIB` so release bundles use the already-built targeted
|
||||
artifact instead of duplicating the copy logic in shell.
|
||||
|
||||
Useful variants:
|
||||
|
||||
```bash
|
||||
./tools/build-linux.sh --no-rust
|
||||
./tools/build-linux.sh --regenerate-bindings
|
||||
./tools/build-linux.sh --version v0.2.0-beta.1
|
||||
```
|
||||
|
||||
## Debian package helper
|
||||
|
||||
To build a `.deb` package:
|
||||
|
||||
```bash
|
||||
./tools/build-linux-deb.sh
|
||||
```
|
||||
|
||||
The Debian helper verifies that `libonnxruntime.so` was actually bundled before
|
||||
packaging.
|
||||
@@ -0,0 +1,26 @@
|
||||
# Chanora Platform Release Policy
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This policy defines platform release expectations for Chanora candidate builds.
|
||||
|
||||
## 2. Platform Policy
|
||||
|
||||
| Platform | Minimum release requirement | Current DV state |
|
||||
|---|---|---|
|
||||
| Android | Signed release or internal test artifact, target SDK compliance, permission/foreground-service validation | Internal validation only; Android DEK waiver active |
|
||||
| iOS | Signed TestFlight/App Store build or explicitly unsigned verification build | Unsigned verification build only |
|
||||
| Windows | Packaged build, smoke result, PTT capability evidence, signing decision | Source-buildable only |
|
||||
| macOS | Universal build, signing/notarization, PTT capability evidence | Source-buildable only |
|
||||
| Linux | Packaged build or documented source-build path, portal/fallback PTT evidence | Source-buildable only |
|
||||
|
||||
## 3. Release Claim Rule
|
||||
|
||||
Release notes and public wording must match the actual artifact and platform capability. A source-buildable platform must not be described as having a finished public binary release.
|
||||
|
||||
## 4. DV Conclusion
|
||||
|
||||
The platform policy is defined. Current candidate scope remains internal validation and documentation review.
|
||||
@@ -0,0 +1,102 @@
|
||||
# Chanora Release Readiness Go/No-Go Record
|
||||
|
||||
**Document status:** DV meeting baseline candidate
|
||||
**Date:** 2026-05-29
|
||||
**Candidate:** `v1.0.0-rc.1` evidence over workspace version `0.2.0-beta.1`
|
||||
**Decision:** No-Go for public/store release; Conditional Go only for documentation review and continued internal DV validation
|
||||
|
||||
## 1. Decision Summary
|
||||
|
||||
Chanora has enough documented structure for DV review and continued internal release-candidate validation. It is not ready for public, store, or broad external release because legal/trademark/OSS sign-off, platform release artifacts, signing/notarization, and several verification evidence items remain open.
|
||||
|
||||
The phrase `Conditional Go` in this record is restricted to document-baseline review and internal validation planning. It is not a product release approval, not a public beta approval, and not a store-distribution approval.
|
||||
|
||||
| Decision scope | Result | Rationale |
|
||||
|---|---|---|
|
||||
| Documentation baseline for DV meeting | Conditional Go | SysRS, SysDes, SRS, verification plans, traceability summary, and waiver register are available |
|
||||
| Internal candidate validation | Conditional Go | Core product paths are implemented enough to continue targeted validation with recorded limitations |
|
||||
| Public release | No-Go | DEC-012 and platform release gates remain open |
|
||||
| Store release | No-Go | Signing, app-store build, legal/privacy/security evidence, and artifact records are incomplete |
|
||||
|
||||
## 2. Candidate Metadata
|
||||
|
||||
| Field | Value |
|
||||
|---|---|
|
||||
| Workspace version | `0.2.0-beta.1` |
|
||||
| CHANGELOG latest candidate | `v1.0.0-rc.1` |
|
||||
| Build number | `76` from `apps/chanora_flutter/pubspec.yaml` |
|
||||
| Commit SHA | To be recorded from the candidate build job before release approval |
|
||||
| Git tag | To be recorded if `v1.0.0-rc.1` is tagged for release validation |
|
||||
| Artifact hashes | Not recorded in current workspace; required before release approval |
|
||||
| Release owner | Product / Release Operations |
|
||||
| Verification owner | Software QA with System Engineering support |
|
||||
|
||||
## 3. Current Implementation Readiness
|
||||
|
||||
Current implementation status is summarized in `docs/implementation-status-2026-05-28.md`.
|
||||
|
||||
| Area | Readiness statement |
|
||||
|---|---|
|
||||
| Core product path | Connect, channel/voice/chat/bookmark/storage/diagnostics paths are substantially implemented |
|
||||
| CI baseline | Rust and Flutter automated checks are defined in `.github/workflows/ci.yml` |
|
||||
| Audio benchmarks | Advisory workflow exists in `.github/workflows/bench-advisory.yml` |
|
||||
| Platform coverage | Android and iOS platform work exists; desktop/iOS release artifacts are not ready for public distribution |
|
||||
| Documentation | Verification plan set and DV gate summaries now exist for review |
|
||||
|
||||
## 4. Release Gates
|
||||
|
||||
| Gate | Status | Decision impact |
|
||||
|---|---|---|
|
||||
| Requirements/design baseline | Passed for DV | SysRS/SysDes/SRS available |
|
||||
| Verification plan baseline | Passed for DV | `docs/verification/` plan set available |
|
||||
| Traceability summary | Passed for DV | `docs/governance/traceability-matrix.md` available |
|
||||
| Legal/trademark/OSS review DEC-012 | Blocked / open | Blocks public/store release |
|
||||
| Privacy policy baseline | Baseline candidate | Requires owner/legal review before public/store release |
|
||||
| Security/privacy evidence | Partial | Blocks strong secure-storage and diagnostic claims until audits attach evidence |
|
||||
| Android secure-storage DEK | Deferred to v1.1 | Requires waiver for internal testing; limits release claim |
|
||||
| iOS release build/signing | Unsigned verification only | Blocks TestFlight/App Store release |
|
||||
| macOS signing/notarization | Not complete | Blocks macOS public binary release |
|
||||
| Windows/Linux packaging | Source-buildable only for candidate | Blocks packaged public desktop release claims |
|
||||
| Artifact hashes | Not recorded | Blocks final release approval |
|
||||
|
||||
## 5. Verification Evidence Status
|
||||
|
||||
| Evidence | Current status | Required action before public/store release |
|
||||
|---|---|---|
|
||||
| Rust workspace check/test | CI defined | Attach latest passing candidate run |
|
||||
| Flutter analyze/test | CI defined | Attach latest passing candidate run |
|
||||
| Cargo deny and cargo-about | CI defined | Attach latest passing candidate run and inventory records |
|
||||
| Flutter license inventory | CI defined | Attach latest passing candidate run and inventory records |
|
||||
| iOS unsigned build | CI defined | Attach latest passing candidate run; add signing evidence before release |
|
||||
| Compatible-server demo | Evidence not attached in this record | Run and attach demo notes/logs |
|
||||
| Audio send/receive and processing demo | Evidence not attached in this record | Run and attach platform evidence |
|
||||
| Diagnostics redaction/export demo | Evidence not attached in this record | Run and attach export review |
|
||||
| Platform secure-storage audit | Partial | Attach per-platform audit or waiver |
|
||||
| PTT capability evidence | Partial | Attach per-platform `PttCapabilityLevel` and backend record |
|
||||
|
||||
## 6. Platform Readiness
|
||||
|
||||
| Platform | Current readiness | Release decision |
|
||||
|---|---|---|
|
||||
| Android | Core platform implementation present; Android Keystore-backed DEK deferred | Conditional internal validation only |
|
||||
| iOS | Unsigned build path present; signing and store pipeline incomplete | No-Go for store release |
|
||||
| Windows | Source-buildable; smoke procedure exists | No-Go for packaged release until smoke/signing evidence exists |
|
||||
| macOS | Source-buildable; public artifact not in candidate | No-Go for packaged release until signing/notarization evidence exists |
|
||||
| Linux | Source-buildable; packaging not confirmed | No-Go for packaged release until artifact evidence exists |
|
||||
|
||||
## 7. Waivers and Deferrals
|
||||
|
||||
All current waivers and deferrals are controlled by `docs/release/dv-waiver-register.md`. A release approver may accept a waiver for internal validation, but public/store release waivers require explicit product, legal/security, and release-owner approval where applicable.
|
||||
|
||||
## 8. Final DV Recommendation
|
||||
|
||||
Recommended DV meeting outcome:
|
||||
|
||||
| Question | Recommendation |
|
||||
|---|---|
|
||||
| Can the document baseline pass DV review? | Yes, with recorded limitations |
|
||||
| Can internal release-candidate validation continue? | Yes, with the waiver register attached |
|
||||
| Can Chanora be publicly released now? | No |
|
||||
| Can store release proceed now? | No |
|
||||
|
||||
The release decision remains **No-Go** until current candidate run evidence, legal/trademark/OSS approval, privacy/security approval, platform signing, and artifact records are complete.
|
||||
Reference in New Issue
Block a user