deaf36f688
Takes the projects line, the chapter uploads, the tablet room selection and the adoption fixes -- thirty-eight commits, 204 tests. **Renumbered, for the third time in this window.** `mantra` reached 22 with the projects tables, having itself renumbered from 21 after the parentage table took that; this branch had already written 22 and 23. So the ritual keying becomes 22->23 and the membership split 23->24, by the rule in docs/curated-to-mantra-profiles.md that a version belongs to whichever tree lands first. Nothing had shipped on either. Schema 23 had to be regenerated rather than kept: the old 22.json described `mantra@21 + the ritual keying`, and the intermediate shape is now `mantra@22 + the ritual keying`, which includes the three project tables. Exported by putting the entities briefly back to that shape, since Room only ever emits the current version. **Projects added three more cascading children, so ChatRoom now has twenty-two.** All three of `MantraProject`, `MantraProjectArtifactVersion` and `MantraProjectTranslationArtifactVersion` reference the room `ON DELETE CASCADE`. The split's migration never enumerated them -- it depends on Room disabling foreign keys, which is asserted rather than assumed -- so it needed no change, but every count in its prose did. `ChatRoomSplitThroughRoomJvmTest` is better for it: starting from a v22 file now runs both of this branch's migrations in one upgrade, which is what a device coming off the projects release will actually do. Conflicts resolved toward mantra's shape with this branch's change applied inside it: `roomDerivedBy` keeps its new extracted helper and reads the ceremony's own threshold key through `getCeremonyThresholdPublicKey`, and `ChatRoomDetailViewModel` keeps the `parents` rename with the per-profile MLS read. The new projects and chapters fixtures needed the same membership seeding as the rest. 1212 tests, 0 failures.
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…