5f2414dcb5
The upstream moved the day the first pull landed: ten commits on curated/curated, 86cb876b..29027f2b, that let a device hold several profiles and move between them, and with them the fork's first schema migration, version 20. The first plan named them the next pull and said the schema change earned a decision of its own. This is that plan, and unlike the first it was written after the dry run rather than before it, so its numbers are measured: rewrite from the fork point in 103 s, ten commits replayed onto776455ecwith nine clean and one resolved by rule, both compilers clean, jvmTest 826 -> 868 and testDebugUnitTest 413 -> 420 with no failures, every audit budget met, and 20.json regenerated byte-identical after a full build. The verdict is all ten, because the line is one feature and seven fixes braided together and four of the fixes are live on Mantra today with one profile: the relay observer that is never all cancelled, the read-only inbox that stays closed after its nsec is pasted, the DataStore race on desktop, and the startup screen's wallet-worded literals. Four decisions: take the whole line rather than carve the fixes out of five commits; take upstream's version 20 verbatim and adopt the rule that whichever tree migrates first owns the number; the one conflict is Mantra's own import from39fb64b6, resolved theirs, which closes one of the first plan's owed reverse-pulls; and two of the device's profiles in one group is a Mantra follow-up before release, since ChatRoom is keyed by the group id alone. What changed in the method: Mantra's tree is no longer a superset of the fork's, so the exactness check becomes "the residual between the trees is the same before and after the pull, file for file", and the plan gives the commands. The replay driver gains the one rule the dry run needed, with its reason. The README gets the row and a reading-order sentence, and the first plan points forward from the paragraph that predicted this one. 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…