Phase 2b — Every mountain range downloads from a list, across the border, delivered by Play

Partly undone by phase-2c.md, 2026-10-22: every Region became a fast-follow pack, and § 5’s Regions screen, welcome screen and camera arrival rule were deleted. The rest stands.

Sequence lives in PLAN.md; the live worklist lives in DOD.md. This phase builds on ADR-0007 and owns the second decision it leaves to “the map phase”: the list of Regions, with each one’s polygon. It reopens one of ADR-0007’s premises, that the data is Poland’s extract alone, and amends the ADR in this file’s commit. It works inside ADR-0008 and takes over phase 1’s checkpoint E, whose brief is phase-1.md § 5. CONTEXT.md owes one change: a Region no longer stops at the state border.

What closing this phase means. Today the release map says “No Regions downloaded yet.” and nothing can change that: the asset-delivery library is in the debug build only, and only the Tatry exists, cut at the border. After this phase nine Regions are built in CI from Poland’s, Slovakia’s and Czechia’s extracts, each an on-demand pack, and a Regions screen downloads any of them, or all of them, and removes them. The difference a device can be asked about: a release build installed from Play downloads the Tatry, draws the Slovak side’s Trails beside the Polish ones, and a one-pin data refresh arrives as a patch Play reports at a fraction of the pack.

Closed on 2026-11-10 with the owner, the Tatry’s patch not shown. Every reading is in. The Tatry came whole in R10–R12; Play patched six other Regions once, in R10, and sent every pack whole otherwise, and § 1’s verdict 3, taken on 2026-11-01, keeps the format (DOD.md).

PLAN.md’s paragraph changed in one place, decided with the owner on 2026-10-20 before this file was written, and is amended with it. It asks “whether a polygon follows the state border exactly”. The answer is that no polygon follows it: Regions cross into Slovakia and Czechia, where the ranges do. Half the Tatry’s Trails are Slovak, and the Karkonosze’s main ridge Trail walks the border. That is pipeline work with a cost of its own, so it is a checkpoint, C, not a footnote.

0. What this phase inherits

• A provisional strip. Phase 1 § 3 took verdict 3: under bundletool --local-testing the Tatry pack arrived but ExtractionWorker never ran, so whether extraction survives ACCESS_NETWORK_STATE stripped is unknown. JobScheduler checks that permission only from API 34 (phase 1, R8’s reading). The test phone is API 30 and cannot answer it; the owner’s phone, API 36, can.
• A proxy, not a reading. Phase 1’s R6 put a week of churn at 0.36 % of the Tatry archive by bsdiff. Play’s algorithm for packs is undocumented. E1, the update size Play reports, is the reading that counts, and it moves into this file’s table.
• The Region seam, half built. data/regions/Regions.kt in main/ holds the states and reads a PMTiles header. RegionSource.kt is the seam: the debug half wraps RegionFiles, which knows one pack, region_tatry, by name; the release half emits an empty list. The map already draws every ready Region, by layer and not by Region, and shows the oldest one’s OSM date (phase 2 § 2).
• One pack module, gated. region_tatry/ joins the build only with -PmapPacks, which no CI job passes yet. app/build.gradle.kts names it by hand.
• One pin, one extract. scripts/osm-data.pin holds one Geofabrik sequence number; build-map-data.py brings Poland’s extract to it and checks its header.
• The tile schema is final for now. Phase 2 fixed it, and the Tatry archive it builds is 7.3 MB at pin 4942 (region_tatry/src/main/assets/tatry.pmtiles, 7,274,738 bytes).
• A public repository and a GitHub release per release-please tag, which the ODbL offer rides.
• The test phone has Play and a Google account, read 2026-10-20 with dumpsys account, but sits in airplane mode. Its Wi-Fi stays on, which a reading through Play needs; CLAUDE.md’s test-phone bullet says why.

What is in, and what is deliberately not

In: the asset-delivery library in the release build, with the Console’s foreground-service declaration and the documents that say Kozica schedules nothing. Nine Regions, each a polygon and an on-demand pack. Slovakia’s and Czechia’s extracts merged into the build at one moment. The data build in publish-play.yml, and the archives attached to each GitHub release as the ODbL offer. The Regions screen: every Region’s state and size, Download, Remove, and “Download all”. A button for it on the map and in the empty state. The readings through Play that phase 1 could not take.

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

• Ukraine’s side of the Bieszczady. Its trails are few and its extract is large against what it adds. The polygon stops at the border there.
• Germany’s side of the Góry Izerskie. The same, and smaller still. Sudety Zachodnie stops at that border.
• Translated Region names. Decided with the owner: a Region’s name is Polish in every language, translatable="false", as on the signposts and the map’s own labels. Most of the nine have no exonym, and a name that changes between the picker and the ground costs more than one that does not match the UI language.
• Showing a Region’s outline on the map before it is downloaded. It would need the polygons in the app as geometry, and a picker that draws. A row with a name and a size is enough to choose by; the names are the ones on every guidebook’s cover.
• A refresh outside a release. ADR-0007 ties data to releases, and nothing here reopens that.

The tempting one is drawing the polygons along the state border “properly”, or along each range’s watershed. It looks like care. But a Region’s edge is never seen: the map draws a Region’s tiles, not its outline, and two ready Regions that overlap draw as one (phase 2 § 2). What the edge decides is only whether a Trail near it is in the pack. So polygons are generous, overlap their neighbours by a few kilometres, and are drawn coarsely, in tens of points, not hundreds.

Checkpoints

A reads B’s branch before B merges. The question is whether the release build may carry the library at all, and the only apparatus that answers it is that build, delivered by Play. So B is written on a branch, bundled locally with the Tatry pack, and given to Play through internal app sharing. A local bundle is allowed here: ADR-0007 forbids local data only in a release, and an internal-sharing link reaches the owner alone. If A takes verdict 2, B does not merge.

C needs no gate and runs beside A. It is local pipeline work and puts nothing in front of a user. It goes before D so the nine polygons are drawn once, already across the border, rather than drawn to the border and redrawn.

B, C and D cut no release; E and F cut one together. B puts the library into the release while the release still carries no pack, so a user sees nothing. E is the first thing a user sees, and on its own it shows nine Regions whose every Download fails, because no pack is in the bundle until F. So release-please’s release PR stays unmerged from E’s merge until F’s, and E and F reach Play in one release. F is the first release that conveys OSM-derived data, so the ODbL offer ships in F’s commit, not after it.

1. The gate: does Play deliver a pack to a build that cannot read network state?

The question, in the form that can be measured

On the owner’s phone (132bc856, API 36, asked first), a release-variant bundle from B’s branch, with asset-delivery as implementation, ACCESS_NETWORK_STATE removed from the merged manifest by tools:node="remove" and the Tatry pack included, is uploaded to internal app sharing and installed from its link. Asked for the Tatry, does the app reach Ready with the OSM date, draw the map from the pack’s path, and log no SecurityException? And did ExtractionWorker run, or did the Play Store hand the pack over already extracted?

Then a second bundle, one pin newer, is uploaded to internal app sharing and installed over the first from its link. What download size does Play report, and does the Tatry reach Ready again without being asked? An internal-track install was taken not to update in place, so it was not used here; it does (RELEASING.md), and R10 reads the refresh through it.

The apparatus

• B’s branch, built with ./gradlew bundleRelease -PmapPacks and the upload key, twice: at the pin on main and at the newest pin Geofabrik serves on the day, each with the Tatry archive built by build-map-data.py --region tatry at that pin. Whether they cross the border depends on whether C has merged; A does not wait for C, and C does not wait for A. The second carries a higher versionCode by hand on the branch, never committed.
• Two more hand edits on the branch, never committed, because a release bundle has neither the debug section nor E’s screen: tapping the empty state’s line fetches the Tatry, and RegionFiles logs every AssetPackState under the tag KozicaPack, with its status, bytesDownloaded() and totalBytesToDownload(). Neither touches the manifest or a dependency, so the build stays release-shaped where the gate looks.
• Internal app sharing, enabled in the Console with the owner as an uploader. Each bundle goes up on the Console’s page through Claude in Chrome; two uploads do not earn a script.
• Each phone set up for the links. The Play Store’s Internal app sharing switch on (Settings › About, the Play Store version tapped seven times). Play re-signs every internal-sharing upload with its own test certificate, not the app-signing key, so a link cannot install over the internal-track copy: that copy is uninstalled first, which deletes its data, so anything in the owner’s install that matters is exported first (ADR-0005). Going back to the internal track after A is another uninstall. Who may open a link is set on the Console’s Internal app sharing page, Uploaders and testers tab: “Anyone you shared the link with can download”, the default, or an email list, which then names the test phone’s Google account for R2. Google’s help also says a tester needs access to the app’s store listing, and Kozica is on no track but testing ones, so if R2’s link refuses that account, it goes on the internal testers’ list too.
• The owner’s phone on Wi-Fi, because internal app sharing installs through the Play Store app. The test phone stands in for nothing here except R2, the second API level.
• Logcat filtered for WM-WorkerWrapper, ExtractionWorker, AssetPack, KozicaPack and SecurityException; dumpsys jobscheduler for the app’s jobs; for the refresh, the bytes the Play Store app’s UID receives, from dumpsys netstats detail read before the second link is tapped and after the Tatry is Ready again, with the Play Store’s auto-update off for that window so no other app’s update is counted.

The verdicts, decided now rather than argued about later

Verdicts 1 and 2 are taken across both installs, R1 and R3. The first install can pass with ExtractionWorker never having run, and the refresh, where Play patches the pack while the app may be closed, is where it is most likely to.

1. On API 36, the Tatry reaches Ready and the map draws from the pack after the first install and again after the refresh, and no SecurityException is logged in either, whether or not ExtractionWorker ran. → The strip stands, and B merges. Which of the two paths delivered the pack each time is recorded, because it says whether this question can return with a later library version.
2. Extraction fails for want of ACCESS_NETWORK_STATE, in either install. → Phase 1 § 3’s verdict 2, unchanged: no workaround in code. The owner chooses between a narrow ADR-0008 amendment that allows ACCESS_NETWORK_STATE alone, since it opens no connection and changes no Data safety answer, and a different delivery for map data. B does not merge until then; C and D go on.

And for the refresh’s size, R3:

1. The pack arrives, but the refresh costs close to the whole pack. → The format question goes back to the owner before F, as phase 1 § 4’s verdict 2 says: determinism first (--check-determinism at both pins), then the layout. A refresh that costs the whole pack every release is not a reason to stop the phase, but it is a reason to know before the first user pays it.

The number that decides is the Play Store app’s received bytes across the second install, from dumpsys netstats. The update sheet may show the APK’s update alone, and a completed pack’s bytesDownloaded() may count the whole pack rather than the patch; both are recorded beside it. The netstats figure includes the APK’s patch, so it overstates the pack’s, which errs towards verdict 3.

“Close to the whole pack” is above 25 % of the Tatry pack’s compressed size. The baseline is a bsdiff between the two archives actually uploaded, build-map-data.py --region tatry --patch-from <the first bundle's pin file> at the second bundle’s pin: phase 1’s R6 measured the thin schema of 1 MB, and phase 2’s 7.3 MB schema has never had one. Play is free to do worse than bsdiff; it is not free to do forty times worse without that being the finding. Internal app sharing is not documented to patch as a track does, so a number above 25 % goes to the owner with that said. Confirming it on the closed track, where an install updates in place, needs a release that carries packs, which is F; so the owner chooses between reopening the format now and reading F’s first data refresh there before reopening it.

The verdict, taken (date)

Verdict 1, 2026-10-20 (R1, the owner’s phone, API 36): Play delivered the Tatry to the release build with ACCESS_NETWORK_STATE stripped, extracted it through the library’s own services, and the map drew it; nothing was thrown. B merges. What else the day found, R2 and R3 on the test phone among it:

• Play delivers a pack to the release build with ACCESS_NETWORK_STATE stripped. The Play Store extracts through the app’s own AssetPackExtractionService; no ExtractionWorker ran. Below API 34 that is not the gate’s answer; R1 read the same path on API 36, with the dataSync ExtractionForegroundService beside it. Neither phone ran an ExtractionWorker, so WorkManager’s missing network-state permission is never asked for on this path.
• A Region that arrives while the map shows the overview is not seen. The camera stays where it was, and at the overview’s zoom the archive draws nothing, so the map looks empty until a restart fits it to the Region. E moves the camera to a Region on its first download.
• The refresh: verdict 3, decided by the owner the same day. Internal app sharing downloaded the refreshed pack whole, and the app’s own APKs whole with it, so its number says how internal sharing delivers rather than how the format patches. The format stands; the refresh is read again on F’s first data refresh through the closed track (§ 6), and the format is reopened only if it is whole there too. R10 is that reading, taken on the internal track rather than the closed one: the Tatry came whole again, six Regions as patches, 33 minutes after the upload. R11 read the next one two hours after its upload, at the first request, and every pack came whole. The owner reopened nothing on 2026-11-01: the format stays (DOD.md).

2. The library in main/

Phase 1 § 5’s first two bullets are this checkpoint, and stand as written there. What this phase adds:

• RegionFiles stops knowing the Tatry. It takes the list of pack names and exposes one Flow of every Region’s state, from one AssetPackStateUpdateListener and one getPackStates call over the whole list. fetch and removePack take a Region. It moves to main/’s data/regions/. RegionSource.kt stays a seam with two halves, as the position override’s is: the release half passes RegionFiles through, and the debug half wraps it with the fallback to a hand-pushed files/regions/<id>.pmtiles.
• The Region list is the polygons. scripts/regions/<id>.poly names every Region. Gradle reads that directory: settings.gradle.kts includes one pack module per polygon, region_<id>, from one shared build script rather than nine copies, and app/build.gradle.kts adds them all to assetPacks under -PmapPacks. The app’s list is generated from the same directory into a Kotlin source, in the order a hiker reads the mountains, § 4’s table: west to east, with Góry Świętokrzyskie last, each entry naming R.string.region_<id>. One list, so a Region cannot exist in the build and not in the app, and one without a name does not compile. The order is a list of ids in the generator, not a field in the polygon, and the build fails when that list and the polygons disagree.
• WaitingForConfirmation splits in two, with one handler. RegionFiles maps two Play statuses to it today, and they mean different things: WAITING_FOR_WIFI holds a large download over mobile data for the user’s yes; REQUIRES_USER_CONFIRMATION means the installed app did not come from Play. So they become WaitingForWifi and NeedsConfirmation, each with its own copy in § 5. AssetPackManager.showConfirmationDialog answers both and needs an ActivityResultLauncher, so the Regions screen registers one; the map’s state row only names the state. Confirming NeedsConfirmation may make Play reinstall the app and cancel every request, so the row falls back to Download.
• The Console declaration for FOREGROUND_SERVICE_DATA_SYNC: the library’s extraction service, started by the Play Store’s delivery, user-initiated by a download. The Console offers the form only once a bundle declaring the permission reaches a track, so it is filled, through Claude in Chrome with the owner’s OK, when E and F’s release is uploaded, and recorded in play-app-content.md.

3. Across the border

• Three extracts, one moment. scripts/osm-data.pin becomes one line per extract, <geofabrik name> <sequence>, for poland, slovakia and czech-republic. Geofabrik numbers each extract’s replication on its own: on 2026-10-18 at 20:25:06Z Poland and Slovakia were at 4942 and Czechia at 4943. So a pin is three numbers, and the build fails unless all three updated headers carry the same osmosis_replication_timestamp. That timestamp is the data’s date, and the one the map shows.
• Each extract is brought to its sequence as Poland’s is today, from the newest dated extract before it that Geofabrik still serves with its md5, by pyosmium-up-to-date --end-id, then checked against its line of the pin; the build fails when Geofabrik keeps no such extract, or not the diffs from it (ADR-0007’s 2026-10-26 amendment). Sizes read 2026-10-20: Poland 2.11 GB, Czechia 0.95 GB, Slovakia 0.35 GB, so a release build downloads about 3.4 GB, not 2.1.
• Each country is cut into every Region before anything is merged, one osmium extract pass per Region, each keeping the country’s replication header. Not one --config pass for all nine: osmium keeps ID sets per polygon sized to OSM’s largest IDs, and Poland cut for nine Regions in one pass peaked at 29.4 GB (smart; 17.8 GB even with simple), against 4.0 GB for one and 11.7 GB for three, read 2026-10-20 with /usr/bin/time -f %M. A hosted runner has 16 GB. The nine passes over Poland cost about 80 s more than one, and Slovakia’s and Czechia’s smaller extracts add little: a full build of all nine Regions at the current pin took 198 s, with a 4.1 GB memory peak. With --discard-extracts, which publish-play.yml passes, the country’s dated and updated extracts are deleted as soon as its cuts are written, so the build’s disk peak is Poland’s two, about 4.2 GB, not three countries’ full extracts and a merged copy. On a workstation they stay, as today, a cache re-verified on every run.
• osmium merge then joins each Region’s three cuts. Geofabrik’s extracts overlap a little at the borders, and merge keeps one copy of an object present in two.
• The merged file carries the shared timestamp, and no sequence. The three sequences differ, so no one of them is the data’s. osmosis_replication_timestamp is written with --output-header, as phase 1 § 4’s edit does, or planetiler would read no date, and the app reads only that (planetiler:osm:osmosisreplicationtime in Regions.kt). tile()’s check that the cut kept the extract’s header moves from the sequence to the timestamp.
• Determinism is re-read. --check-determinism builds twice from the merged cuts. A merge whose output order depended on input order would be the stray timestamp ADR-0007 warns of.
• A data refresh is still one fix: commit that moves the pin: now three numbers, one moment.
• The profile is unchanged. Slovakia’s and Czechia’s Trails use the same four colours and the same osmc:symbol grammar; R5 reads the Tatry’s Slovak side off the screen to prove it.

4. Nine Regions

Decided with the owner, 2026-10-20. Ids are the pack names, ASCII and underscores; names are Polish, translatable="false".

• Polygons are coarse and generous: tens of points, a few kilometres past each range’s last Trail, overlapping their neighbours by about as much. Each is drawn on the range’s own map, not derived from OSM boundaries, and committed as scripts/regions/<id>.poly.
• tatry.poly is redrawn, across the border. Phase 1’s R5 found its Slovak half empty because the extract stopped there; after C it is not.
• Each Region’s archive is measured (R6) and must stay under ADR-0007’s 1.5 GB; at the Tatry’s 7.3 MB none is expected near it, and the build’s check stays the guard.
• The debug map row “Download Tatry” becomes the Regions screen, in E. The debug section keeps the pack states as text, for readings.

5. The Regions screen

• A Regions NavKey and ui/regions/, one ViewModel, one immutable UI state: every Region with its state and its download size. Reached from a download button on the map, beside Settings, and from the empty state, which gains the button phase 2 left for this phase (“Choose Regions”), and from a “Regions” row in a new Map section at the top of Settings (decided with the owner, 2026-10-20).
• A row is the Region’s name, then its state: the size to download; downloading with a percent; waiting for Wi-Fi, with the button that opens Play’s confirmation; needing confirmation, with the same button; update in progress; ready, with its OSM date, phase 2’s “OSM data: %1$s”; failed, with Retry. Download or Remove sits at the row’s end. The size is AssetPackState.totalBytesToDownload(), which Play reports before anything is fetched; a build with no Play session (installDebug) has none, and the row shows the name alone.
• “Confirm” when nothing awaits confirmation asks for the Region again: the state shown was stale, and the tap meant “download it”.
• “Download all” fetches every Region neither ready nor already on its way (not downloaded, or failed), in one fetch call, and says how many and how large: “Download all — %1$d Regions, %2$s”. While any of their sizes is unknown it drops the size rather than show a partial sum. It is absent when nothing is left to fetch.
• The map goes to a Region on its first download (§ 1’s verdict): it remembers which Regions it has taken in, and a Region ready since is an arrival, whether the download ended on this screen or while the app was closed. The camera moves only when its centre lies outside every Region that was already ready, so the user is not looking at downloaded data, and then fits one arrival, the first in REGION_NAMES order, never their union: the union of two Regions is the overview that draws nothing. “Fits” means the arrival’s middle at its fitted zoom but never below zoom 10, the Trails’ minimum: a whole Region fits at about 7.3 to 8.1 on a phone, where R7 found the archive draws borders and little else. So “Download all” on screen moves once, to the first Region that finishes, and stays, because the centre is now inside a ready Region; off screen it fits one Region. An arrival is remembered once the camera has moved to it, or straight away when the camera stays, so a process killed before the map returns still moves it. Only a Region not downloaded is forgotten, at once, so one downloaded again moves the camera again and an update passing through “Updating” is no arrival.
• The first launch asks which Regions to download (decided with the owner, 2026-10-20, after E shipped): a welcome screen in the map’s place, every Region with a box and its size, “All Regions” over them, nothing ticked. A Region already ready or on its way, as after an update from 0.3.0, shows ticked and fixed. “Download” fetches the ticked ones in one call and opens the Regions screen, which shows their progress and Play’s confirmation; “Not now” opens the map. Either answer stores onboarding_done, so the screen never returns; one line names the map’s button and Settings’ row as the places to change it later. With every Region already ready or on its way there is nothing to ask: once the Regions are read, onboarding_done is stored and the map opens.
• Remove asks first. A Region removed on a ridge with no signal does not come back until there is signal. The dialog says that, in one line, and Remove is its confirming button. Download asks nothing: Play’s own confirmation covers mobile data.
• The map’s button and the empty state read the same RegionSource, so the empty state’s line is still phase 2’s: “Map data is being updated.” during an update, “No Regions downloaded yet.” otherwise, now with the button under it.

Copy: “Regions”, “Map” (the Settings section), “Choose Regions”, “Download”, “Remove”, “Retry”, “Download all — %1$d Regions, %2$s” (a plural) and its sizeless twin “Download all — %1$d Regions”, “Downloading — %1$d%%”, “Waiting for Wi-Fi”, “Download over mobile data”, “Play needs your confirmation”, “Confirm”, “Updating”, “Remove %1$s?”, “You won’t see this Region’s map until you download it again, which needs a connection.”, “Download failed”. The welcome screen’s: “Welcome to Kozica”, “Download the mountains you need before you go. After that the map works with no signal.”, “All Regions”, “You can change this any time with the download button on the map, or in Settings → Regions.”, “Download %1$d Regions, %2$s” (a plural) and its sizeless twin, “Not now”. The Region names are not copy.

6. Play delivers it

Phase 1 § 5’s last three bullets are this checkpoint, with C’s three extracts and D’s nine packs:

• The data build joins publish-play.yml before bundleRelease: osmium-tool from apt and pyosmium 4.2 or newer from pip, then build-map-data.py --discard-extracts for every Region at the pin, --check-determinism on one of them (the Tatry, which changes in every refresh), then bundleRelease -PmapPacks, which fails when an archive is missing. A release whose inputs match the last version’s record skips the build and its check (ADR-0007’s 2026-10-25 amendment). A hosted ubuntu-latest runner guarantees 14 GB of SSD and a job may run six hours, so the build logs the runner’s free disk after each country’s cut, and R9 records the peak and the minutes.
• The refresh size is read here, on the closed track, where an install updates in place: the first release after F that only moves the pin, installed over F’s, read as R3 was (§ 1’s verdict). R10 and R11 read it on the internal track instead, which updates in place too, 0.14.1 → 0.14.2 and 0.14.2 → 0.14.3; the owner took their verdict on 2026-11-01: the format stays. Gate A’s CI run spent 1 h 46 min on the data alone (R9), most of it fetching Poland. No cache, decided with the owner on 2026-10-20: ADR-0007’s reasons stand, and two hours inside a six-hour limit, unattended, is cheaper than a second workflow keeping a cache warm. Narrowed on 2026-10-25 by ADR-0007’s amendment: a release with unchanged inputs reuses the last version’s archives, and a full build now takes about 40 minutes.
• The ODbL offer is the database itself. Decided with the owner, 2026-10-20: the workflow attaches the nine .pmtiles to the release-please GitHub release, under ODbL, with scripts/map/MAP-DATA-LICENCE.txt beside them saying so, and the licences screen’s ODbL entry links to the release page for the app’s own version. That offers the derivative database (ODbL §4.6) without licensing the code, whose LICENSE stays all rights reserved. The archives are attached before Upload to internal testing, with gh release upload --clobber so a retry can attach them again, and the job gains contents: write, which a release upload needs and the workflow’s contents: read refuses. A failed attach then stops the run before Play sees the bundle: a release on Play without its offer on GitHub is the one outcome the house rule exists to prevent.
• The listing and the policy say where the data comes from. The privacy policy gains one sentence: map data is downloaded by the Play Store app, under Google’s terms; Kozica opens no connection. The listing’s description names both sides of the border.

Tests

None for a safety value: nothing in this phase computes one (PLAN.md rule 3). Two guards that are not unit tests stand where tests might be expected:

• The pin’s one moment is build-map-data.py’s check that three headers carry one timestamp. A build at three different moments would draw a border where Trails end on one side a day early.
• The Region list’s one source is Gradle reading scripts/regions/. A Region with a polygon and no name string fails to compile, not at runtime.

Documents this phase amends

• PLAN.md: phase 2b’s paragraph, with this file: the polygons cross the border, and C exists.
• ADR-0007: a dated amendment with this file: the nine Regions, the three extracts at one moment and their pin, and the archives on the GitHub release as the ODbL offer.
• CONTEXT.md: Region’s definition, with this file: it crosses the state border where the ranges do, and stops at Ukraine’s and Germany’s.
• DOD.md: checkpoint E’s item points here, with this file.
• With B, as phase 1 § 5 lists: CLAUDE.md’s stack rows for Play Asset Delivery and “Nothing scheduled”, ADR-0003’s amendment, PLAN.md’s “Reminders and scheduled work”, play-app-content.md § Foreground service permissions, and aab-permissions.py’s four EXPECTED rows. CLAUDE.md’s layout: region_tatry/ becomes one region_<id>/ per polygon, and data/regions/ loses “each variant supplies the states”. ADR-0008’s list of libraries known to merge a forbidden permission gains a third, the asset-delivery library with WorkManager, naming A’s verdict.
• With D: .gitignore’s two /region_tatry/ lines become /region_*/src/main/assets/ and /region_*/build/, so no Region’s archive can be committed (ADR-0007).
• With F: CLAUDE.md’s OSM house rule names the offer this phase chose; docs/privacy-policy.md and docs/store-listing.md per § 6; RELEASING.md gains the data build and the release assets.

Known gaps, deliberately

• The test phone cannot answer the gate. API 30 is below the level where JobScheduler checks ACCESS_NETWORK_STATE, so A is the owner’s phone’s, and waits until it is free.
• A release that moves the pin downloads 3.4 GB from Geofabrik. ADR-0007’s alternative of a cache still fails for the same reason, a tag ref; a release with unchanged inputs reuses the last version’s archives instead (its 2026-10-25 amendment).
• Ukraine’s and Germany’s sides are missing. Named above, with their reasons.

Readings

PLAN.md rule 3: filled in as the phase runs, from the device or the build, with the command that read it. A reading on the owner’s phone waits until the owner says it is free. A reading through Play needs Wi-Fi on; the test phone’s stays on, per CLAUDE.md’s test-phone bullet.