chanora/docs/superpowers/specs/2026-06-08-maintainability-continuation-design.md

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.