build: migrate Kotlin/Gradle Android app to gossamer (clears banned-language CI)

[hyperpolymath]

Debt: Banned-language (the two perpetual CI reds)

The android/ app is built in Kotlin + Gradle, which the Hyperpolymath language policy bans for mobile.

This trips two CI checks red on every PR and on main (e.g. PR #81):

• Check for Banned Languages — find . -name "*.kt" -o -name "*.kts" -o -name "*.java" matches the Android sources.
• governance / Language / package anti-pattern policy — same banned-language presence via the standards reusable.

Files in scope

• Gradle: android/settings.gradle.kts, android/build.gradle.kts, android/app/build.gradle.kts
• Kotlin (7): MainActivity.kt, NeurophoneService.kt, BootReceiver.kt, NativeLib.kt, widget/NeurophoneAppWidget.kt, widget/NeurophoneWidgetActions.kt, widget/NeurophoneWidgetConfigureActivity.kt

Target: gossamer (NOT Tauri/Dioxus)

Migrate the UI to hyperpolymath/gossamer — the estate's own resource-safe Tauri/Electron alternative (Idris2 + Zig, with linear-typed memory/handle safety via the Ephapax region-calculus backend). This keeps the migration inside the estate's verified stack rather than adopting an external framework.

⚠️ To confirm: gossamer is currently described as a desktop shell. Verify its Android/mobile support (or the plan for it) before committing to the migration path — this may need coordination with the gossamer repo.

Notes

• Until migrated, the two checks above stay red — they are not introduced by any given PR; pre-existing/structural.
• Large epic; decompose into sub-tasks (service, widgets, boot receiver, NativeLib/FFI boundary).

(Corrected 2026-06-02: target was previously mis-stated as Tauri/Dioxus; the estate is standardising on gossamer.)

[hyperpolymath]

Gossamer migration assessment (Tauri RFC #96 was closed; gossamer is the target)

What gossamer covers

• Android support = Android WebView via a JNI bridge (gossamer src/interface/abi/Types.idr); mobile is Phase 5 ≈ 70% per gossamer STATE.a2ml. So gossamer can host the UI (an Activity hosting a WebView) and the Rust/JNI boundary.

The gap to design around

gossamer is a webview shell — it does not provide neurophone's non-UI Android components:

• NeurophoneService (foreground Service)
• BootReceiver (BroadcastReceiver)
• the widget triple (AppWidgetProvider + actions + configure Activity)

These are instantiated by Android by class name (JVM-bytecode surface) and are out of scope for a UI shell.

Recommended approach (gossamer-hosted, mirrors the rejected RFC's Path A but on gossamer not Tauri)

Component	Target
MainActivity + activity_main.xml	gossamer WebView + AffineScript UI
NativeLib.kt (JNI)	crates/neurophone-android (Rust), via gossamer's JNI bridge
NeurophoneService / BootReceiver / widgets	minimal generated Java shims under a gen/-style dir → JNI into Rust, with a CI banned-language exemption for that generated dir (coordinated with standards)
*.gradle.kts	generated under the gossamer Android dir

Blocking decisions (owner / gossamer coordination)

1. Is gossamer mobile production-ready enough to depend on now (Phase 5 at ~70%)? If not, build: migrate Kotlin/Gradle Android app to gossamer (clears banned-language CI) #83 waits on gossamer.
2. Service + Widget host: accept generated Java shims + CI exemption, or grow component support in gossamer itself?
3. CI exemption for the generated dir — needs the standards anti-pattern reusable to honour an exclusion (the standards hand-off prompt covers this).

Decomposition (once 1–3 are settled)

CI exemption for generated dir → gossamer Android init → port NativeLib → Service shim → BootReceiver shim → widget triple → AffineScript UI → delete legacy android/ (both CI gates green).

I can split this into sub-issues and/or draft the gossamer RFC doc on the owner's go — but the code migration is blocked on (1) and (2), and gossamer itself is out of this session's edit scope.

---

Generated by Claude Code