9430396e5a
Phase 4 of docs/project-feature.md. Three branches in `ProposedEvent.summarize`, or members would be asked to sign "Event of kind 30330". The project's branch shows the creator, and that is not decoration. The creator tag is the group attesting that X started this; the creator signs nothing, the room does, so a member could propose a project crediting somebody else and a quorum that does not read would sign it. Nothing checks this and nothing can -- the only mitigation is that the claim is in front of the person agreeing to it. `summarize` gains two optional parameters. `chatRoomId` is read by one branch and only to leave something out: a project owned by the room it is in is the ordinary case, and saying "owned by this group" every time is how a member learns to stop reading the line that matters when somebody else is on it. All four call sites already had the room, so this is threaded rather than plumbed -- including through `WhatIsBeingSigned`, which took the events and not the state. `resolve` is the seam for turning keys and ids into names, synchronous because two of the four call sites are composables and cannot await a database. It defaults to resolving nothing, which is honest rather than finished: a membership event carries two 64-character ids, so without it the summary is a truncated hash. That is tolerable in the batch that founds a project -- the project's own line says what is happening and the memberships read as its continuation, and the project id is unresolvable there anyway since nothing has applied it yet. It is not tolerable for a membership proposed on its own, which is Phase 7's second screen, and that is where the resolver gets filled in. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This is a Kotlin Multiplatform project targeting Android, iOS, Desktop (JVM).
-
/composeApp is for code that will be shared across your Compose Multiplatform applications. It contains several subfolders:
- commonMain is for code that’s common for all targets.
- Other folders are for Kotlin code that will be compiled for only the platform indicated in the folder name. For example, if you want to use Apple’s CoreCrypto for the iOS part of your Kotlin app, the iosMain folder would be the right place for such calls. Similarly, if you want to edit the Desktop (JVM) specific part, the jvmMain folder is the appropriate location.
-
/iosApp contains iOS applications. Even if you’re sharing your UI with Compose Multiplatform, you need this entry point for your iOS app. This is also where you should add SwiftUI code for your project.
Build and Run Android Application
To build and run the development version of the Android app, use the run configuration from the run widget in your IDE’s toolbar or build it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:assembleDebug - on Windows
.\gradlew.bat :composeApp:assembleDebug
Build and Run Desktop (JVM) Application
To build and run the development version of the desktop app, use the run configuration from the run widget in your IDE’s toolbar or run it directly from the terminal:
- on macOS/Linux
./gradlew :composeApp:run - on Windows
.\gradlew.bat :composeApp:run
Build and Run iOS Application
To build and run the development version of the iOS app, use the run configuration from the run widget in your IDE’s toolbar or open the /iosApp directory in Xcode and run it from there.
Learn more about Kotlin Multiplatform…