feat: refine file-code confirmation and prepare 0.4.1

The receive-code design introduced in 0.4.0 made file transfers much
simpler by removing the receiver-side Accept/Decline wait. This
follow-up makes the sender experience and the surrounding source code
match that simpler direction more clearly.

Replace the centered file receive-code alert with a modal bottom sheet.
Show the target device, four clear digit positions, and the number of
selected files. Keep confirmation explicit: entering four digits enables
the Send button, but the transfer does not start until the sender taps it.

Simplify the idle Receive presentation and clarify the wording around
the temporary file code on both Send and Receive. Keep the same
application-session code and do not remember codes on the sender.

Rename the outgoing raw file-stream abstraction from FileTransferSender
to FileTransmitter across common code, Android, JVM, iOS, Koin bindings,
and the outgoing controller. Rename the HTTP helper so it clearly says
that it sends a file-offer request. These are readability changes and do
not alter socket ownership, cancellation, streaming, framing, progress,
timeouts, or receiver preparation.

Prepare release 0.4.1 across all supported package targets:

- Android version 0.4.1 with version code 5
- Desktop package version 0.4.1
- iOS marketing version 0.4.1 with build number 5
- Preview protocol version remains 1

Update the changelog, README, architecture, development guide, and
project context. Clarify that 0.4.0 and 0.4.1 retain the same wire format,
while the receive-code file flow remains incompatible with 0.3.0 and
older builds.

Author: CodePandaaAI

CHANGELOG.md

@@ -6,6 +6,16 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.4.1] - 2026-08-28
+
+### Changed
+
+- Replaced the centered file receive-code alert with a modal bottom sheet that shows the target device, four clear digit slots, and the selected file count.
+- Kept file sending explicit: entering four digits enables the Send button, and the transfer starts only after the sender confirms.
+- Simplified the idle Receive presentation and clarified the temporary file-code wording on Send and Receive.
+- Renamed the outgoing raw file-stream abstraction to `FileTransmitter` and made the HTTP file-offer helper name more explicit. These are internal readability changes and do not change the `0.4.0` wire format.
+- Prepared Android, Desktop, and iOS packages as `0.4.1`; Android and iOS build numbers are `5`. Preview protocol metadata remains version `1`.
+
 ## [0.4.0] - 2026-08-28
 
 ### Changed
@@ -14,7 +24,7 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 - Displayed the same session receive code on both the Send and Receive screens so it is visible from the default screen.
 - File offers now include the entered code and receive an immediate accepted, invalid-code, busy, or preparation-failed response.
 - Removed file `UserDecision`, `CompletableDeferred`, incoming-offer state, decision timeout, and Accept/Cancel race while retaining operation IDs, TCP preparation timeout, cancellation, progress, framing, and cleanup.
-- Changed the file-offer wire format, so matching builds are required; preview protocol metadata intentionally remains version `1` for now.
+- Changed the file-offer wire format, making `0.4.0` incompatible with `0.3.0` and older builds; preview protocol metadata intentionally remains version `1` for now.
 
 ### Security
 

README.md

@@ -130,15 +130,15 @@ Platform file picker
   -> sender enters the receiver's temporary four-digit code
   -> POST /sync360/file/offer sends metadata and code
   -> idle receiver checks the code and prepares its TCP receiver immediately
-  -> platform FileTransferSender opens an InputStream
+  -> platform FileTransmitter opens an InputStream
   -> one raw TCP connection streams the accepted file batch
   -> platform DownloadsWriter saves each file
   -> receiver returns final success and completed-file count
 ```
 
 The receive code is generated in memory when a fresh application session starts. The same code is shown on the Send and Receive screens, so it is available from the default screen without switching tabs. It is not persisted, advertised, or remembered by the sender. It is a convenience check, not authentication or encryption.
 
-This changes the file-offer request and response format. Builds containing this flow are not file-transfer compatible with `0.3.0` or older builds, even though the advertised preview protocol version intentionally remains `1` for now. Use matching builds on both devices.
+The receive-code file-offer format is not file-transfer compatible with `0.3.0` or older builds. Version `0.4.1` does not change the `0.4.0` wire format, so `0.4.0` and `0.4.1` can transfer files with each other. The advertised preview protocol version intentionally remains `1` for now, and discovery does not yet enforce this compatibility boundary.
 
 One TCP socket is opened for the complete accepted batch. It begins with the operation ID as 16 raw UUID bytes; each file then begins with its index and promised byte count, followed by exactly that many bytes. The receiver checks the operation ID, index, and size before saving. The sender writes every file sequentially, flushes once after the complete batch, then reads one final success flag and completed-file count from the receiver. The count increases only after the platform Downloads writer successfully returns. The current shared payload buffer is 512 KiB; exact byte counts define file boundaries, so correctness does not depend on `flush()` calls or matching sender and receiver read chunks.
 

androidApp/build.gradle.kts

@@ -36,8 +36,8 @@ android {
         applicationId = "com.liftley.sync360"
         minSdk = libs.versions.android.minSdk.get().toInt()
         targetSdk = libs.versions.android.targetSdk.get().toInt()
-        versionCode = 4
-        versionName = "0.4.0"
+        versionCode = 5
+        versionName = "0.4.1"
     }
 
     buildFeatures {

context.md

@@ -77,7 +77,7 @@ Current shared transfer constants use a 512 KiB payload buffer, 5-second connect
 
 ## Important limitations
 
-Sync360 currently uses cleartext local HTTP and raw TCP. Direct text has no receiver approval or operation ID. File operation IDs correlate protocol messages and sockets but do not authenticate a peer. A temporary four-digit receive code replaces file Accept/Decline, but it has no attempt throttling and is not authentication, encryption, or a checksum. The new file-offer format is incompatible with `0.3.0` and older builds while preview protocol metadata intentionally remains version `1`, so both devices must run matching builds. The current target-SDK-37 Android build also lacks Android 17's required local-network runtime-permission flow. Windows receiving depends on Windows Firewall allowing the application. Use development builds only on private networks you control.
+Sync360 currently uses cleartext local HTTP and raw TCP. Direct text has no receiver approval or operation ID. File operation IDs correlate protocol messages and sockets but do not authenticate a peer. A temporary four-digit receive code replaces file Accept/Decline, but it has no attempt throttling and is not authentication, encryption, or a checksum. The receive-code file-offer format is incompatible with `0.3.0` and older builds, while `0.4.0` and `0.4.1` share the same wire format. Preview protocol metadata intentionally remains version `1`, so discovery does not yet enforce this boundary. The current target-SDK-37 Android build also lacks Android 17's required local-network runtime-permission flow. Windows receiving depends on Windows Firewall allowing the application. Use development builds only on private networks you control.
 
 For detailed and current information, read:
 

desktopApp/build.gradle.kts

@@ -37,7 +37,7 @@ compose.desktop {
         nativeDistributions {
             targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
             packageName = "Sync360"
-            packageVersion = "0.4.0"
+            packageVersion = "0.4.1"
             appResourcesRootDir.set(
                 project.layout.projectDirectory.dir("packaging/app-resources")
             )

docs/ARCHITECTURE.md

@@ -112,7 +112,7 @@ A file offer contains the sender-entered four-digit receive code, operation iden
 
 The receive code is generated once when the singleton incoming controller is created for a fresh application session. The Send and Receive ViewModels both read that same controller-owned value and render the same shared code card. It remains only in memory, is not advertised, and is not remembered by the sender. It is a convenience check rather than authentication because it has only 9,000 possible values and is sent over cleartext HTTP.
 
-The added request field and structured response statuses change the file-offer wire format. This implementation is not file-transfer compatible with `0.3.0` or older builds. Protocol metadata intentionally remains version `1` during the current preview stage, so matching application builds are required even though discovery does not yet reject an older peer.
+The added request field and structured response statuses changed the file-offer wire format in `0.4.0`. This implementation is not file-transfer compatible with `0.3.0` or older builds. Version `0.4.1` keeps the `0.4.0` wire format, so those two versions can transfer files with each other. Protocol metadata intentionally remains version `1` during the current preview stage, and discovery does not yet reject an incompatible older peer.
 
 A random operation ID still correlates the accepted file offer, explicit cancellation, and TCP connection. Cancellation succeeds only when both the operation ID and sender device ID match the active file state. Every platform receiver retains its 30-second timeout waiting for the first TCP connection, so an accepted offer cannot leave the receiver busy forever if the sender disappears. File contents remain in platform file readers and are not placed in the HTTP request.
 

docs/DEVELOPMENT.md

@@ -56,7 +56,7 @@ Windows:
 
 ## Preparing public packages
 
-The current package version is `0.4.0`.
+The current package version is `0.4.1`.
 
 Android release APKs must use the maintainer's permanent private signing key. Copy `keystore.properties.example` to the ignored `keystore.properties` file and set:
 
@@ -89,7 +89,7 @@ The Windows `upgradeUuid` must remain unchanged for the lifetime of Sync360, and
 2. Open Sync360 on both devices and keep it in the foreground during current testing.
 3. Wait for the other device to appear on the Send screen.
 4. Test direct text delivery while idle and busy, the 100,000/100,001 boundaries, sender name, Copy, and Clear.
-5. Test the file receive-code dialog with correct, incorrect, incomplete, and non-numeric input.
+5. Test the file receive-code bottom sheet with correct, incorrect, incomplete, and non-numeric input.
 6. Confirm Send and Receive show the same code, and that a fresh application start creates a new code while navigation and recomposition do not change it.
 7. Test one file, multiple files, receiver-busy behavior, the first-connection timeout, and cancellation.
 8. Confirm completed files appear in Downloads.
@@ -125,7 +125,7 @@ Useful source locations:
 - `JvmNetworkServices` — current macOS/Linux JmDNS registration, discovery, repair cleanup, and IPv4/IPv6 LAN-interface selection.
 - `Sync360HttpServer` / `Sync360HttpClient` — direct text delivery and file control routes.
 - `OutgoingRequestsController` / `IncomingServerRequestsController` — send/receive coordination.
-- platform `FileTransferSender`, `FileTransferReceiver`, and `DownloadsWriter` implementations — file bytes and storage.
+- platform `FileTransmitter`, `FileTransferReceiver`, and `DownloadsWriter` implementations — file bytes and storage.
 
 The Windows backend currently requires a 64-bit Desktop JVM, matching the project's Windows packaging target and the native ABI used by the binding.
 

iosApp/Configuration/Config.xcconfig

@@ -3,5 +3,5 @@ TEAM_ID=
 PRODUCT_NAME=Sync360
 PRODUCT_BUNDLE_IDENTIFIER=com.liftley.sync360.Sync360$(TEAM_ID)
 
-CURRENT_PROJECT_VERSION=4
-MARKETING_VERSION=0.4.0
+CURRENT_PROJECT_VERSION=5
+MARKETING_VERSION=0.4.1

shared/src/androidMain/kotlin/com/liftley/sync360/core/di/koin.android.kt

@@ -10,9 +10,9 @@ import com.liftley.sync360.data.file.DownloadsWriter
 import com.liftley.sync360.data.file.SelectedFileReader
 import com.liftley.sync360.data.network.discovery.AndroidNetworkServices
 import com.liftley.sync360.data.network.tcp.AndroidFileTransferReceiver
-import com.liftley.sync360.data.network.tcp.AndroidFileTransferSender
+import com.liftley.sync360.data.network.tcp.AndroidFileTransmitter
 import com.liftley.sync360.data.network.tcp.FileTransferReceiver
-import com.liftley.sync360.data.network.tcp.FileTransferSender
+import com.liftley.sync360.data.network.tcp.FileTransmitter
 import com.liftley.sync360.domain.local.LocalDeviceIdentityStore
 import com.liftley.sync360.domain.local.LocalDeviceInfoProvider
 import com.liftley.sync360.domain.repository.ClipboardProvider
@@ -30,8 +30,8 @@ val androidModule = module {
     single<SelectedFileReader> { AndroidSelectedFileReader(androidContext()) }
     single<DownloadsWriter<InputStream>> { AndroidDownloadsWriter(androidContext()) }
 
-    single<FileTransferSender> {
-        AndroidFileTransferSender(
+    single<FileTransmitter> {
+        AndroidFileTransmitter(
             context = androidContext()
         )
     }

…network/tcp/AndroidFileTransferSender.kt …ta/network/tcp/AndroidFileTransmitter.ktshared/src/androidMain/kotlin/com/liftley/sync360/data/network/tcp/AndroidFileTransferSender.kt renamed to shared/src/androidMain/kotlin/com/liftley/sync360/data/network/tcp/AndroidFileTransmitter.kt shared/src/androidMain/kotlin/com/liftley/sync360/data/network/tcp/AndroidFileTransferSender.kt renamed to shared/src/androidMain/kotlin/com/liftley/sync360/data/network/tcp/AndroidFileTransmitter.kt

@@ -18,9 +18,9 @@ import java.net.Socket
 import java.util.concurrent.atomic.AtomicReference
 import kotlin.uuid.Uuid
 
-class AndroidFileTransferSender(
+class AndroidFileTransmitter(
     private val context: Context
-) : FileTransferSender {
+) : FileTransmitter {
     private val activeSocket = AtomicReference<Socket?>(null)
 
     override fun cancelCurrentFileTransfer() {