docs(p0): SysRS/SysDes/SRS/SAD/SDD/Verification + traceability for Android P0 reconciliation

Full P0 Android documentation chain:

- SysRS: API 24 → API 28 reconciliation per DEC-004 (SysRS-288);
  add SysRS-305 (Android in-call audio mode), SysRS-306
  (RECORD_AUDIO runtime timing).
- SysDes: SysDes-152 (in-call audio mode subsystem), SysDes-153
  (RECORD_AUDIO permission flow), SysDes-154 (Android voice audio
  backend), SysDes-155 (macOS runtime baseline).
- SRS: SRS-187 → API 28; add SRS-208 (in-call audio mode), SRS-209
  (RECORD_AUDIO + listen-only fallback), SRS-210..215 (Android voice
  audio backend latency/preset/AEC/usage/sharing/foreground service);
  retarget SysDes anchors from generic SysDes-135 to SysDes-152/153/154.
- SAD: SAD-063 refreshed (API 28); add SAD-084 (audio mode
  controller), SAD-085 (permission adapter with listen-only),
  SAD-086 (foreground service), SAD-087 (macOS runtime baseline);
  formalize cross-cutting + platform-specific allocation pattern
  in §24.1.
- SDD: expand SDD-028 (BackIntentService); refresh SDD-073 (build
  config); add SDD-105 (JNI bootstrap), SDD-106 (permission
  requester), SDD-107 (foreground service), SDD-108 (audio mode
  controller), SDD-109 (AAB pipeline), SDD-110 (PTT capability),
  SDD-111..116 (Android voice audio backend), SDD-118 (Android
  bridge build automation), SDD-119 (iOS/macOS bridge build
  automation back-fill).
- Verification: create android-p0-acceptance.md TC-1..TC-18; add
  SWE4-UV-040..052, SWE5-IV-016..026, SWE6-SV-018..030,
  SYS4-SIV-015 strengthened + SYS4-SIV-017/018.
- Governance: traceability matrix v0.9.9 with end-to-end chain
  closure; DEC-032 documents the temporary abiFilters reduction to
  arm64-v8a only and its restore-by gate.

Trace: full chain SysRS → SysDes → SRS → SAD → SDD → Code → Verification.

docs/architecture/sad.md

@@ -3,7 +3,7 @@
 
 **Document type:** SAD / Software Architecture Description  
 **Process alignment:** ASPICE SWE.2 Software Architectural Design  
-**Version:** 0.9.2
+**Version:** 0.9.8
 **Status:** Baseline Candidate  
 **Language:** English  
 **Product:** Chanora  
@@ -1161,13 +1161,19 @@ Communication evidence is maintained through change history and baseline approva
 
 ## 24. SRS-to-SAD Coverage Matrix
 
+### 24.1 Cross-cutting + platform-specific allocations
+
+A single SRS item may be intentionally allocated to more than one SAD item when it has both a cross-cutting concern (logging, diagnostics, lifecycle, error handling, redaction, permission policy) and a platform-specific architectural realization (Android foreground service, iOS background audio session, macOS permission gating, Linux portal binding, etc.). In that case the SAD records both anchors: the cross-cutting anchor covers the concern at the architecture level, and the platform-specific anchor covers the realization on a particular OS. This is a deliberate dual allocation, not a duplication, and the §24.2 matrix marks affected rows explicitly. Worked example: SRS-111 (foreground voice-session behaviour) is allocated both to SAD-036 (cross-cutting diagnostics / lifecycle isolation across SRS-111..124) and to SAD-086 (Android `AndroidVoiceForegroundService` realization). The cross-cutting anchor is the right place to refine concern-wide rules; the platform-specific anchor is the right place to refine the OS-bound element.
+
+### 24.2 SRS-to-SAD coverage matrix
+
 | SRS Range | SAD Coverage |
 |---|---|
 | SRS-001 through SRS-030 | SAD-032, SAD-039, SAD-040, SAD-041 |
 | SRS-031 through SRS-060 | SAD-033, SAD-039, SAD-041 |
 | SRS-061 through SRS-090 | SAD-034, SAD-039, SAD-041 |
 | SRS-091 through SRS-110 | SAD-035 |
-| SRS-111 through SRS-124 | SAD-036, SAD-050 |
+| SRS-111 through SRS-124 | SAD-036, SAD-050 (cross-cutting). SRS-111 additionally allocated to SAD-086 (Android-specific realization) per §24.1 dual-allocation pattern. |
 | SRS-125 through SRS-134 | SAD-037, SAD-049 |
 | SRS-135 through SRS-143 | SAD-038 |
 | SRS-144 through SRS-184 | SAD-001 through SAD-031, SAD-039 through SAD-060 |
@@ -1202,7 +1208,7 @@ Communication evidence is maintained through change history and baseline approva
 - Source SRS: SRS-186
 - Verification method: Release Inspection
 
-**SAD-063**: The software architecture shall isolate Android runtime minimum version and Play target API compliance in Android build configuration and platform services.
+**SAD-063**: The software architecture shall isolate Android runtime minimum version and Play target API compliance in Android build configuration and platform services. The Android minimum runtime baseline is API 28 (Android 9.0) per DEC-004 (Accepted 2026-05-14), which superseded the earlier API 24 recommendation. The `minSdkVersion` / `minSdk` value, the Play target API value, and any conditional platform-capability branching that depends on the minimum baseline shall be expressed in a single Android build-configuration location and consumed by platform services rather than by feature screens; this isolation allows the minimum baseline to be raised, when Flutter, plugin, audio, or platform constraints require it, without touching feature code.
 
 - Status: Baseline Candidate
 - Type: Software Architecture Item
@@ -1391,6 +1397,43 @@ Communication evidence is maintained through change history and baseline approva
 - Source SRS: SRS-205, SRS-207
 - Verification method: Unit Test, Integration Test
 
+**SAD-084**: The software architecture shall allocate Android in-call audio-mode management to an `AndroidAudioModeController` element inside the Android platform audio adapter, owned by the audio subsystem and bound to the voice-session lifecycle rather than to any UI screen lifecycle. The controller shall engage Android's voice-communication audio mode (for example `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) no later than the moment a voice session becomes connected — driven from the same audio-engine lifecycle hook that opens the input/output streams per SAD-081 — so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The controller shall snapshot the prior audio mode on engage and restore it on the last voice-session leave. The controller shall be the only writer of the Android audio mode within the application; feature screens, the Flutter UI layer, and the bridge surface shall not reach Android `AudioManager` mode APIs directly.
+
+- Status: Baseline Candidate
+- Type: Software Architecture Item
+- Stage: P0 / MVP
+- Allocated to: Audio Subsystem, Platform Audio Adapter (Android)
+- Source SRS: SRS-208
+- Verification method: Platform Test (Android), Audio Test, Architecture Review
+
+**SAD-085**: The software architecture shall extend the Android platform permission adapter (within Platform Services) to own the runtime `RECORD_AUDIO` permission flow on behalf of the audio subsystem, and shall recognise listen-only operation (`capture_active = false` while the output stream remains open, consistent with SAD-081 / SRS-204) as a first-class audio operating mode at the architecture layer rather than as an error or degraded state. The permission adapter shall request `RECORD_AUDIO` at or before voice-session activation, shall expose the current permission state to the audio engine and to the Flutter UI through the existing bridge event stream, and shall block microphone capture (`capture_active` shall remain false) when the permission is not granted, revoked, or undecided. In that case, the `TransmitModeSelector` defined in SAD-083 shall remain clamped such that `transmit_active = false` regardless of PTT or Continuous-mode inputs, while the output mix path defined in SAD-081 continues to operate. The Flutter UI shall surface a user-visible path to grant `RECORD_AUDIO` before retrying transmit; the permission adapter shall not auto-retry beyond Android platform conventions.
+
+- Status: Baseline Candidate
+- Type: Software Architecture Item
+- Stage: P0 / MVP
+- Allocated to: Platform Services (Android Permission Adapter), Audio Subsystem, Flutter UI, Bridge
+- Source SRS: SRS-209
+- Verification method: Platform Test (Android), Integration Test, Privacy Review
+
+**SAD-086**: The software architecture shall allocate Android foreground-service behaviour for active voice sessions to an `AndroidVoiceForegroundService` element owned by the Android platform services container, bound to the voice-session lifecycle (start on first `voice_join`, stop on last `voice_leave`, consistent with SAD-081) rather than to any UI screen lifecycle. The service shall declare the appropriate Android foreground-service type for voice communication, post the required ongoing notification, and coordinate with the `AndroidAudioModeController` (SAD-084) and the Android permission adapter (SAD-085) so that microphone capture and Bluetooth SCO routing survive UI backgrounding and process trimming under Android background-execution restrictions. Feature screens shall not start, stop, or interrogate the foreground service directly; they shall observe voice-session state through `BridgeEvent::VoiceState`.
+
+- Status: Baseline Candidate
+- Type: Software Architecture Item
+- Stage: P0 / MVP
+- Allocated to: Platform Services (Android), Audio Subsystem
+- Source SRS: SRS-111
+- Verification method: Platform Test (Android), Integration Test
+
+**SAD-087**: The software architecture shall isolate macOS runtime baseline configuration, universal-binary packaging, framework layout, and CocoaPods integration in macOS build configuration and platform services, parallel to SAD-061 (iOS runtime) and SAD-063 (Android runtime). Specifically: (a) the macOS deployment target shall be expressed in a single macOS build-configuration location (currently `10.15`, declared in `apps/chanora_flutter/macos/chanora_bridge.podspec`) and consumed by platform services rather than feature screens, so the minimum macOS version can be raised without touching feature code; (b) the macOS Rust bridge artifact shall be packaged as a universal binary covering both `arm64` and `x86_64` slices, combined via `lipo` into a single dylib so a single signed framework runs on Apple-silicon and Intel Macs; (c) the bridge shall be delivered as a `.framework` bundle using the macOS `Versions/A` layout convention expected by the system loader and code-signing tools; (d) CocoaPods integration shall be driven by a hand-rolled podspec (the same `chanora_bridge.podspec`) maintained and regenerated through release-pipeline build automation rather than authored ad hoc per release. Feature screens, the Flutter UI layer, and the bridge surface shall not reach macOS build settings or framework layout details directly. This item is the macOS counterpart to SAD-061 / SAD-063 and is the proper SAD anchor for downstream detailed-design items concerning macOS bridge build automation, framework layout, and podspec maintenance.
+
+- Status: Baseline Candidate
+- Type: Software Architecture Item
+- Stage: P0 / MVP
+- Allocated to: macOS Build Configuration, Platform Services (macOS), Release Pipeline
+- Source SRS: SRS-013
+- Source SysDes: SysDes-155 (macOS runtime baseline — deployment target, universal-binary packaging, `.framework` `Versions/A` layout, CocoaPods podspec automation)
+- Verification method: Platform Test (macOS), Release Inspection, Architecture Review
+
 ## 27. Updated SRS-to-SAD Coverage Matrix
 
 | SRS Range | SAD Coverage |
@@ -1400,6 +1443,10 @@ Communication evidence is maintained through change history and baseline approva
 | SRS-195 through SRS-199, SRS-201 through SRS-203 | Covered by `SAD-071` through `SAD-079` |
 | SRS-200 | Covered by `SAD-080` |
 | SRS-204 through SRS-207 | Covered by `SAD-081` through `SAD-083` |
+| SRS-208 | Covered by `SAD-084` |
+| SRS-209 | Covered by `SAD-085` |
+| SRS-111 (Android foreground voice service) | Covered by `SAD-086` (Android-specific allocation; SAD-036 retains the cross-cutting diagnostics allocation for the SRS-111–124 range per §24.1 dual-allocation pattern) |
+| SRS-013 (multi-platform support — macOS runtime baseline aspect) | Covered by `SAD-087` (macOS runtime baseline; counterpart to SAD-061 / SAD-063) |
 
 
 ## Baseline Candidate 0.9.1 Update
@@ -1435,3 +1482,18 @@ Communication evidence is maintained through change history and baseline approva
 | Version | Date | Description |
 |---|---|---|
 | 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle architecture items SAD-081 through SAD-083 sourced from SRS-204..207: dropped the `start_audio` / `stop_audio` bridge calls and replaced them with `voice_join(channel_id)` / `voice_leave()` keyed off implicit engine init plus `BridgeEvent::VoiceState`; added the `ReleaseTailTimer` adapter on the `DesktopPttBackend` → `AudioTransmitGate` path (default 200 ms, range 0–500 ms, key-down within window cancels the pending close); added the `TransmitModeSelector` element as the sole writer of `transmit_active` (other than the SAD-079 watchdog) with hard-mute applied as a final clamp and `VoiceActivity` mapped to `Continuous` until DEC-030 resolves. Strict layered sourcing preserved (`SAD -> SRS` only). |
+
+
+## Baseline Candidate 0.9.6 Update
+
+| Version | Date | Description |
+|---|---|---|
+| 0.9.6 | 2026-05-17 | Propagated reconciled P0 Android SRS updates into SAD. SAD-063 text extended in place (ID preserved) to record the API 28 minimum runtime baseline per DEC-004 (Accepted 2026-05-14, superseding the earlier API 24 recommendation), while keeping the existing SRS-187 / SRS-188 trace. Added SAD-084 (Android in-call audio mode controller in the platform audio adapter, bound to the voice-session lifecycle, sourced from SRS-208). Added SAD-085 (Android `RECORD_AUDIO` runtime permission flow on the existing Android permission adapter, naming listen-only — `capture_active = false` with output stream open per SAD-081 — as a first-class operating mode at the architecture layer, sourced from SRS-209). Added SAD-086 (`AndroidVoiceForegroundService` allocation for SRS-111, bound to `voice_join` / `voice_leave` lifecycle rather than UI lifecycle, coordinating with SAD-084 and SAD-085). SAD-018 (Android back intent, SRS-163) and the existing Android AAB allocation in §9 / SAD-037 (SRS-119) were re-read and left unchanged because they remain coherent with the reconciled SRS. Strict layered sourcing preserved (`SAD -> SRS` only). |
+
+
+## Baseline Candidate 0.9.7 Update
+
+| Version | Date | Description |
+|---|---|---|
+| 0.9.7 | 2026-05-18 | Formalized the cross-cutting + platform-specific SAD allocation pattern flagged by the traceability-auditor: added §24.1 narrative subsection describing the deliberate dual-allocation rule (cross-cutting concern + platform-specific realization both recorded), with SRS-111 / SAD-036 / SAD-086 as the worked example, and annotated the §24.2 matrix row for SRS-111..124 accordingly. Added SAD-087 (macOS runtime baseline: deployment target isolation, universal-binary `lipo` packaging, `.framework` `Versions/A` layout, hand-rolled CocoaPods podspec automation), parallel to SAD-061 (iOS runtime) and SAD-063 (Android runtime), closing the macOS-runtime anchor gap flagged by the SDD-119 detailed-designer. SAD-087 traces upward through SRS-013 (multi-platform support); a parallel macOS-runtime SysDes derivation does not yet exist and is recorded as an open follow-up for the system-architect (SysDes-133 covers iOS, SysDes-135 covers Android, macOS has no counterpart yet). §27 matrix updated with the SAD-087 row. Strict layered sourcing preserved (`SAD -> SRS` only). |
+| 0.9.8 | 2026-05-18 | Retargeted SAD-087's `Source SysDes` field from the "open follow-up — no dedicated macOS-runtime SysDes anchor exists" placeholder to `SysDes-155` (macOS runtime baseline — deployment target, universal-binary `lipo` packaging, `.framework` `Versions/A` layout, CocoaPods podspec automation), authored by the system-architect in SysDes v0.9.7 as the parallel macOS-runtime anchor to SysDes-133 (iOS) / SysDes-135 (Android). This closes the open follow-up that SAD-087 carried at its 0.9.7 authoring, giving SAD-087 a proper upward SysDes trace. Surgical single-field edit: no behavioral content of SAD-087 changed; `Source SRS` retained as `SRS-013` (multi-platform support — Windows, macOS, Linux, iOS, Android), which remains the correct SRS anchor (the SRS-013 vs alternate-anchor question raised during SysDes-155 authoring referred to SysRS-013 / SysRS-002 at the system-requirements layer, not to SRS at the software-requirements layer). §27 SRS-to-SAD coverage matrix row for SRS-013 unchanged because it already cites SAD-087 and remains textually accurate. Strict layered sourcing preserved (`SAD -> SRS`, with SysDes cross-reference now resolved). |