docs: add maintainability continuation design
This commit is contained in:
Edison Jwa
@@ -0,0 +1,119 @@
|
|||||||
|
# Maintainability Continuation Design
|
||||||
|
|
||||||
|
**Date:** 2026-06-08
|
||||||
|
**Status:** Approved design for implementation planning
|
||||||
|
**Scope:** Continue the current working-branch maintainability pass without broad rewrites.
|
||||||
|
|
||||||
|
## Purpose
|
||||||
|
|
||||||
|
This design continues the project review already present in the working tree. The goal is to simplify the project where changes are low-risk, testable, and documented, while avoiding speculative architecture churn.
|
||||||
|
|
||||||
|
The work covers unnecessary functions, structs, files, modules, duplicated custom implementations, built-in replacement opportunities, outdated documents, fail-safe gaps, and Android runtime verification requirements.
|
||||||
|
|
||||||
|
## Recommended Approach
|
||||||
|
|
||||||
|
Use a targeted continuation of the current maintainability pass.
|
||||||
|
|
||||||
|
The existing branch already contains a first slice of simplification: core event DTO extraction, network diagnostics locality, `VecDeque` queue improvements, derived PTT backend errors, render downmix helper reuse, state reducer reuse, workspace metadata cleanup, and documentation updates. This design treats those changes as the baseline and adds only small, provable follow-up changes.
|
||||||
|
|
||||||
|
Rejected alternatives:
|
||||||
|
|
||||||
|
- Documentation-only audit: safer, but leaves clear simplifications unimplemented.
|
||||||
|
- Broad architectural cleanup: may produce long-term wins, but is too risky for this pass because bridge, protocol, audio, and Android behavior have high regression cost.
|
||||||
|
|
||||||
|
## Architecture Boundaries
|
||||||
|
|
||||||
|
The existing responsibilities remain intact:
|
||||||
|
|
||||||
|
- Flutter owns presentation, navigation, Material 3 behavior, accessibility, localization presentation, and platform UI behavior.
|
||||||
|
- Flutter Rust Bridge owns typed DTO/API glue and generated bindings.
|
||||||
|
- Rust Core owns session orchestration, cross-crate coordination, bridge-facing public events, and stable public APIs.
|
||||||
|
- Protocol owns TeamSpeak-compatible protocol isolation behind `tsclientlib`.
|
||||||
|
- Audio owns capture, render, processing, PTT backends, platform audio behavior, and voice packet handling where explicitly documented.
|
||||||
|
- Diagnostics owns redaction, logs, export records, and bounded diagnostic history.
|
||||||
|
|
||||||
|
Public interfaces should stay stable unless a change clearly removes duplicated or unnecessary code and has direct verification.
|
||||||
|
|
||||||
|
## Review Targets
|
||||||
|
|
||||||
|
The implementation review should inspect these areas first:
|
||||||
|
|
||||||
|
- `core/chanora_core/src/lib.rs`, `events.rs`, `network_diagnostics.rs`, and `ptt.rs`
|
||||||
|
- `crates/chanora_audio`, especially duplicated render, capture, PTT, and platform-audio helpers
|
||||||
|
- `crates/chanora_state` reducer paths
|
||||||
|
- `crates/chanora_protocol` adapter ordering, event, and DTO mapping paths
|
||||||
|
- `crates/chanora_bridge/src/api.rs`, excluding generated bridge files unless regeneration is intentionally part of a change
|
||||||
|
- `crates/chanora_diagnostics/src/lib.rs`
|
||||||
|
- `crates/chanora_prefetch` and `crates/chanora_resolver` as a documented follow-up seam decision unless a trivial cleanup appears
|
||||||
|
- `apps/chanora_flutter/lib`, excluding generated localization and bridge files unless an API change requires updates
|
||||||
|
- governance, architecture, implementation-status, and verification documents affected by the code review
|
||||||
|
|
||||||
|
## Simplification Rules
|
||||||
|
|
||||||
|
Every code change must satisfy these rules:
|
||||||
|
|
||||||
|
- Prefer deletion, built-in APIs, derives, or reuse of existing helpers over new abstractions.
|
||||||
|
- Merge files or modules only when the merged unit has a clearer single responsibility.
|
||||||
|
- Split files only when it improves locality around a stable responsibility and preserves public API shape.
|
||||||
|
- Do not manually edit generated files unless the generation process is part of the verified change.
|
||||||
|
- Do not introduce backward-compatibility shims unless there is a persisted-data, shipped-API, external-consumer, or explicit product need.
|
||||||
|
- Record larger architectural opportunities in the maintainability review instead of forcing them into this pass.
|
||||||
|
|
||||||
|
## Testing Design
|
||||||
|
|
||||||
|
Verification is tied to change type:
|
||||||
|
|
||||||
|
- Rust-only changes require `cargo fmt --all`, `cargo check --workspace`, and `cargo test --workspace`.
|
||||||
|
- Flutter changes require `flutter analyze` and `flutter test --exclude-tags e2e` from `apps/chanora_flutter`.
|
||||||
|
- Bridge DTO/API changes require Rust verification, bridge generation check, Flutter analyze, and Flutter tests.
|
||||||
|
- Android platform, permission, lifecycle, or audio changes require Rust and Flutter verification plus `adb devices -l`, Android build/install, and a device or emulator smoke test.
|
||||||
|
- Documentation-only changes require affected docs and cross-links to be read and checked; code tests are not required unless the docs describe a code change just made.
|
||||||
|
|
||||||
|
If no ADB target is connected, Android runtime verification must be recorded as blocked. The implementation must not claim Android runtime success without device or emulator evidence.
|
||||||
|
|
||||||
|
## Fail-Safe Review
|
||||||
|
|
||||||
|
The review must identify fail-safe gaps and either verify them, fix them, or record the missing evidence.
|
||||||
|
|
||||||
|
Priority fail-safe areas:
|
||||||
|
|
||||||
|
- Android secure storage and Keystore-backed data-encryption-key handling
|
||||||
|
- Android permission and audio lifecycle behavior
|
||||||
|
- Stuck PTT prevention and missed-key-up recovery
|
||||||
|
- Diagnostic redaction and privacy-sensitive event export
|
||||||
|
- Bridge DTO drift between Core, Bridge, and Dart generated bindings
|
||||||
|
- Protocol isolation exceptions for voice packet handling
|
||||||
|
- Runtime behavior gaps not covered by unit tests
|
||||||
|
|
||||||
|
No release-readiness or production-safety claim should be made without matching evidence.
|
||||||
|
|
||||||
|
## Documentation Design
|
||||||
|
|
||||||
|
The working review record remains `docs/governance/maintainability-review-2026-06-08.md`.
|
||||||
|
|
||||||
|
Documents to update when affected:
|
||||||
|
|
||||||
|
- `docs/governance/document-index.md`
|
||||||
|
- `docs/architecture/sad.md`
|
||||||
|
- `docs/architecture/sdd.md`
|
||||||
|
- `docs/implementation-status-2026-05-28.md`
|
||||||
|
- `docs/verification/swe4-unit-verification-plan.md`
|
||||||
|
- `docs/verification/swe5-software-integration-verification-plan.md`
|
||||||
|
- release or fail-safe records if verification status changes
|
||||||
|
|
||||||
|
Documentation should distinguish completed changes, follow-up opportunities, blocked verification, and release limitations.
|
||||||
|
|
||||||
|
## Commit Policy
|
||||||
|
|
||||||
|
No commit is created automatically. A commit happens only when explicitly requested, after inspecting `git status`, `git diff`, and recent commits.
|
||||||
|
|
||||||
|
## Success Criteria
|
||||||
|
|
||||||
|
This work is successful when:
|
||||||
|
|
||||||
|
- Safe simplifications are implemented or recorded as follow-up opportunities.
|
||||||
|
- Built-in replacement opportunities are applied only when behavior remains covered by tests.
|
||||||
|
- Fail-safe gaps are documented with required evidence or fixed with verification.
|
||||||
|
- Rust and Flutter verification are run as required by the touched files.
|
||||||
|
- Android ADB runtime verification is run when a target is available or explicitly recorded as blocked.
|
||||||
|
- Documents reflect the final code and verification state.
|
||||||
Reference in New Issue
Block a user