James RichandClaude Sonnet 5 bcc1413be2 feat(webApp): add the v0 web executable module (not yet wired into the build) ...

Compose Multiplatform entry point for the browser, using ComposeViewport
(confirmed as the current, non-deprecated bootstrap for the pinned 1.12.0
against JetBrains' own compose-multiplatform example repo and the 1.12.0
CHANGELOG, since hosted docs didn't carry the exact signature). Wires in
every wasmJs-specific Koin module this whole effort left unregistered
(CorePrefsWasmJsModule, CoreDatastoreWasmJsModule, CoreNetworkWasmJsModule,
CoreBleWasmJsModule) alongside the v0 feature slice per the workpad's AC9:
connections, messaging, node, settings. Map and every other feature module
are absent by dependency-list omission, not a runtime flag.

Shaped directly on desktopApp's module: same DatabaseManager/MessageQueue/
process-lifecycle/BuildConfigProvider platform-stub pattern, with
browser-native replacements (localStorage-backed prefs/datastore, OPFS/Web
Worker Room persistence, Web Bluetooth, WebSocket-only MQTT) instead of
no-ops wherever a real implementation exists, and honest no-ops (TAK,
widgets, notifications, phone location/compass, bundled-asset seeding)
wherever the browser sandbox genuinely can't provide the platform concept.

This module is NOT included in settings.gradle.kts yet. Adding `:webApp`
to the include list breaks root-level Gradle configuration for every
other module: KotlinRootNpmResolver throws "IllegalStateException:
:core:common is not configured for JS usage" before any task runs.
Isolated experimentally: the trigger is specifically `binaries.executable()`,
not `browser()` — with `:webApp` included and only `binaries.executable()`
removed, `./gradlew :core:common:help --dry-run` and `./gradlew projects`
both configure cleanly. So this is inherent to declaring an executable
Kotlin/Wasm binary anywhere in a multi-project build that also contains
other wasmJs-target subprojects, not something scoped to this module's
own config. The likely fix is a Gradle composite build (webApp as its own
build via includeBuild(), consuming the libraries through dependency
substitution instead of as a subproject) — not attempted here: it needs
build-logic's convention plugins and the version catalog shared across a
build boundary, plus substitution rules for webApp's ~15 transitive
project() dependencies, which is a real restructuring that deserves its
own pass rather than a blind attempt at the tail of this one.

:webApp:compileKotlinWasmJs and :webApp:compileTestKotlinWasmJs both pass
in isolation (verified via an ad-hoc temporary settings.gradle.kts include
plus a scoped gradle-runner pass); :webApp:wasmJsBrowserDistribution has
not been made to succeed even in isolation, a second, separate packaging
gap. See .agent_plans/web-target-workpad.md's webApp milestone entry for
the full diagnosis.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-08-31 04:42:56 -05:00

..

src/wasmJsMain

feat(webApp): add the v0 web executable module (not yet wired into the build)

2026-08-31 04:42:56 -05:00

webpack.config.d

feat(webApp): add the v0 web executable module (not yet wired into the build)

2026-08-31 04:42:56 -05:00

build.gradle.kts

feat(webApp): add the v0 web executable module (not yet wired into the build)

2026-08-31 04:42:56 -05:00