Phase 2c — Every Region arrives with the app, and nobody has to pick one

Sequence lives in PLAN.md; the live worklist lives in DOD.md. This phase amends ADR-0007’s delivery decision, each Region an on-demand pack, in this file’s commit, and undoes the user-facing half of phase-2b.md § 5. CONTEXT.md’s Region was redefined with it: the unit the map data is built and delivered in, which the user never picks.

What closing this phase means. Today a fresh install opens on a welcome screen asking which of nine Regions to download, and the map draws nothing until the user has chosen and Play has fetched them; a Regions screen downloads and removes them one by one or all at once. After this phase every Region is a fast-follow pack: Play fetches all nine by itself right after the install, without the app being opened, and the app has no screen for choosing. The difference a device can be asked about: a build installed from Play and never opened has had all nine packs downloaded by Play a few minutes later, its first launch finds each one COMPLETED or TRANSFERRING rather than NOT_INSTALLED, and it opens on the Tatry’s Trails. The library enables its extraction services only at runtime, so moving a pack into the app’s storage may wait for that launch.

Decided with the owner on 2026-10-22, while phase 4 was being planned: relief for every Region would grow the downloads by about 200 MB, and the owner chose to ship everything to everyone rather than add relief to a per-Region choice. Kozica is on the internal track only, so nothing a stranger installed loses a screen.

0. What this phase inherits

• Phase 2b’s packs and library stay as they are. Nine region_<id> modules built by gradle/region-pack.gradle.kts, the asset-delivery library in main/, its four permissions and the dataSync extraction service. Only the pack’s deliveryType changes, in one line.
• RegionFiles already reads every state a fast-follow pack passes through. Play reports a fast-follow pack with the same AssetPackStatus values as an on-demand one, and fetch accepts one that has not arrived, so the Retry and Play’s confirmation dialog keep their code.
• What a device has proven and what it has not. R7 proved Play delivers all nine on-demand packs to a Play install. Nothing has yet read a fast-follow pack, on either phone, or what an install that holds on-demand packs does when the update turns them fast-follow.
• The map’s camera is stored (phase 2), and phase 2b § 5 moves it to a Region on its first download, remembered in AppPreferences.readyRegions.

What is in, and what is deliberately not

In: deliveryType fast-follow for every Region pack. The map’s progress line while any Region has not arrived, with Retry and Play’s confirmation. The first launch’s camera on the Tatry. Deleting the Regions screen, the welcome screen, the map’s download button, Settings’ Map section, the camera’s arrival rule and both stored keys that served them. The listing, the privacy policy and the foreground-service answers that described a Region the user chose.

Not in, and each with a reason rather than a phase:

• Removing a Region to free space. About 560 MB on the phone is real on a small one, but a Remove brings back the per-Region choice this phase removes, and a map with holes in it. If support mail asks for it, it returns as its own change.
• Install-time packs. The data would be there before the first launch, but the store listing would show about 485 MB, Android wants about twice that free to install or update, and the difference over fast-follow is the minute after install.
• A read-only list of Regions and their states. It answers a question few users will ask, and the debug build’s Settings already lists every pack’s state.

The tempting one is keeping the Regions screen “for later”, behind the progress line’s Retry or in Settings. It costs nothing to leave in, it seems. But every string on it stays inside the translation gate, its states have to stay true to a delivery mode that no longer asks, and a later phase adding Remove back would start from a screen built for choosing rather than freeing space.

Checkpoints

No gate. Nothing here can veto the phase: if Play fetched nothing by itself, the app’s own fetch on the first launch (§ 1) still brings every Region, as phase 2b’s did. R1 reads which of the two did it, and R2 the update from 0.5.0’s on-demand packs.

A and B ship in one release. B’s listing describes A’s behaviour, so its notes are written on A’s branch, as phase 3’s were, and the release PR waits for B.

1. Every Region arrives by itself

• deliveryType.set("fast-follow") in gradle/region-pack.gradle.kts. Nothing else in the build changes: -PmapPacks, the data build and the archives on the GitHub release are as phase 2b left them.
• The app asks only for what was never asked for. On the map’s first collection of the Regions, a Region Play reports NOT_INSTALLED is fetched, all of them in one fetch call, as “Download all” did. That covers a fast-follow download Play has not started and a Region added to a later build, which Play fetches unprompted as part of the install anyway. A failed Region, or one the user cancelled in the Play Store (FAILED, CANCELED), is not fetched again behind the user’s back: it waits for Retry, and Retry shows what it will download, “Retry — %1$s”, once Play has reported the size of every failed Region.

• The progress line replaces the empty state, “No Regions downloaded yet.” and its button, which go with MapEmpty. It shows while any Region is not ready, over the map rather than instead of it, since the Regions already ready draw beneath it:

  State of the Regions not ready	Line	Action
  Any downloading, pending or not yet asked for	“Downloading maps — %1$d of %2$d” (ready of all)	—
  Any waiting for Wi-Fi	“Waiting for Wi-Fi”	“Download over mobile data”, Play’s dialog
  Any needing confirmation	“Play needs your confirmation”	“Confirm”, Play’s dialog
  Any failed or cancelled, none of the above	“Download failed”	“Retry — 68 MB” (or “Retry” while a size is unknown), one fetch for every failed Region
  Any updating	“Map data is being updated.” (phase 2’s)	—

  The first matching row wins, in that order: the line names what the user is waiting on, so a download still moving is reported before one that failed, and Play’s dialog before a Retry, because the dialog may be what the failure waits on. A Region not yet asked for counts as downloading: the first launch’s fetch is already asking for it. With every Region ready the line is gone.

• Without a Play session the line says “Download failed”. installDebug has none, so the first launch’s fetch fails and every Region not hand-pushed to files/regions/ is Failed: a debug build without all nine archives pushed shows “Download failed” and Retry over the map. That is true of that build, and accepted. scripts/edge-to-edge.py’s scenes show the line as it is; phase 4’s gate reading pushes all nine archives, so it has none.
• The first launch opens on the Tatry. With no stored camera, the map centres on the Tatry at about zoom 11, where Trails, Huts and peaks draw, instead of phase 2’s overview from the Karkonosze to the Bieszczady, which draws borders and park outlines only. After that the stored camera applies, as it does now.
• The camera never moves by itself. Phase 2b § 5’s arrival rule goes, with AppPreferences.readyRegions: nine Regions landing within a minute of the install would otherwise move the map under a finger that is already panning it.
• Deleted:
  • ui/regions/, its screen, ViewModel and RegionsUiStateTest, and the Regions NavKey.
  • ui/welcome/ with WelcomeUiStateTest and WelcomeViewModelTest. The welcome screen has no NavKey: what shows it is Navigation.kt’s onboardingDone gate and MainApplication.onboardingDone, and both go, with the onboarding_done key.
  • The map’s empty state and download button: MapEmpty, MapStart and ic_download.
  • Settings’ Map section and its row.
  • The camera’s arrival rule: MapUiState.arrival, MapScreen’s arrival LaunchedEffect, MapViewModelTest’s arrival tests and AppPreferences.readyRegions.
  • RegionFiles.remove.
  • In every locale, every regions_* and welcome_* string, map_no_regions, map_choose_regions and settings_map; TranslationTest.quotedPairs is left empty. The strings the progress line keeps are renamed map_retry, map_waiting_for_wifi, map_mobile_data, map_needs_confirmation, map_confirm and map_download_failed, beside the new map_downloading.
  • In scripts/edge-to-edge.py, the welcome scene; home-empty becomes the wipe alone, and SEED_WALK loses its “Not now”. Every seeded cell walks SEED_WALK, so without that edit the whole matrix breaks, not one scene.

  A stored key nothing reads any more is harmless on the internal track’s installs, so neither key gets a removal step. REGION_NAMES and the Region name strings stay: the debug build’s pack list and the progress line’s count read them.

• The first launch’s pack states are logged, under KozicaPack: each pack’s state as the map first reads it, and each fetch the app sends with the packs it names. R1 reads a release installed from Play, which has neither a debug build’s log nor its pack list, so the line is in main/; it carries no string and no screen.
• The map’s buttons are Safety and Settings.

Copy: “Downloading maps — %1$d of %2$d”. The other lines are phase 2b’s, kept under new names: “Waiting for Wi-Fi”, “Download over mobile data”, “Play needs your confirmation”, “Confirm”, “Download failed”, “Retry”. New: “Retry — %1$s”, with the size. “Map data is being updated.” is phase 2’s.

2. What the documents say

• The listing’s description loses “Download the ranges you need before you go”: every range arrives with the app. The 0.6.0 notes say the map now arrives with the app, all nine Regions, with nothing to choose, and that the Regions screen is gone.
• The website’s front page, docs/index.md, loses “once you have downloaded the ranges you need” from its opening line.
• The privacy policy says the map data is downloaded by the Play Store app after Kozica is installed, rather than “when you choose a Region”.
• play-app-content.md’s foreground-service answers, all three, since each rested on a Region the user asked for and with fast-follow nobody asks. The declaration is still checkpoint E’s, owed in the Console, and is filed with these:
  • What the user sees: the maps that come with the app, which the Play Store downloads right after the install, being made ready to use offline, with the system’s foreground-service notification while it runs.
  • Why it cannot wait: the map has to be on the phone before the user goes where there is no signal, and Play delivers it while the app may be in the background; left for later, the map is missing on the trail.
  • Type: dataSync, which covers transferring to the device the data the app needs to work.

Tests

• The progress line’s state is a pure function from the Regions’ states to one line and its action, with the order in § 1’s table. A test per row, and one with a downloading and a failed Region proving downloading wins: the line names what the user is waiting on, and a Retry shown while a download is still moving misreports it.
• What the first launch fetches: not-installed Regions only, never one ready, downloading, updating, failed or cancelled. A cancelled one fetched unasked would undo the user’s own decision, with no size shown.

Documents this phase amends

• ADR-0007, with an amendment dated 2026-10-22: every Region a fast-follow pack.
• phase-2b.md, at its head: § 5’s screens and the camera’s arrival rule are undone here.
• CONTEXT.md: Region, already amended.
• docs/store-listing.md, docs/index.md, docs/privacy-policy.md, docs/play-app-content.md: § 2.
• PLAN.md: this phase’s line and paragraph.
• CLAUDE.md: the Stack’s Play Asset Delivery row and the Layout’s region_<id>/ line (“one on-demand asset pack per polygon”), with A.

Known gaps, deliberately

• Every install carries every Region, about 275 MB from Play and 351 MB on the phone, before phase 4’s relief. Someone who hikes only the Tatry pays for the Sudety. Accepted for an app with nothing to choose.
• A data refresh reaches everyone’s nine packs. Before, it reached only the Regions a user had chosen. What a refresh costs through a track was phase 2b § 6’s reading to take: 2b read it on the internal track (R10–R12), and the owner kept the format on 2026-11-01.
• Opening the app in the first minute shows a part-drawn map. The progress line says why.

Readings

PLAN.md rule 3. A reading through Play needs Wi-Fi on the test phone, which stays on: CLAUDE.md’s test-phone bullet says why.