Phase 2 — The map draws the mountains as the signposts mark them, and shows where you are

Sequence lives in PLAN.md; the live worklist lives in DOD.md. This phase builds on ADR-0007 and owns one of the two decisions that ADR leaves to “the map phase”: the filter. It works inside ADR-0008. CONTEXT.md is owed nothing: Trail, Path, Hut, Shelter and Region already name everything the map draws.

What closing this phase means. Today the release build opens on a placeholder, and only a debug screen draws the Tatry, as plain lines. After this phase the app opens on the map, in the release build too. It draws every Trail in its signpost colour and symbol, with two Trails on one way drawn side by side, Paths apart from them, and Huts, Shelters, peaks, passes, springs, viewpoints, the way in and out, the land, national-park boundaries and the state border, in light and dark. One tap shows where the user is, with accuracy and heading. The difference a device can be asked about: a debug build with the Tatry on the phone shows a yellow and a black Trail sharing a way, both drawn, and the position dot over them, with no network permission in the merged manifest. The dot gets there by § 4’s PositionReceiver broadcast, not a walk; R9 is that reading.

PLAN.md’s paragraph is split, and amended with this file. It bundled the map with every Region and the picker that downloads them. The two halves are blocked by different things: the map can be built and read against the Tatry archive already on the developer’s machine, but a picker that reaches users needs the asset-delivery library in the release build, which is phase 1’s checkpoint E and waits on Play work. By PLAN.md rule 2 they are two phases. This one draws; phase 2b builds every Region, owns the Region list, and brings the picker and “Download all”.

Phase 2b owns three things the split would otherwise leave with two owners or none:

• Every Region’s polygon, tatry.poly included. Phase 1’s R5 found its Slovak half draws nothing, because the extract stops at the state border; whether a polygon follows that border exactly is 2b’s question too. This phase draws the Tatry from the polygon as it stands.
• Checkpoint E. 2b takes it over, and phase 1 closes on its phone readings alone. Phase 1 § 5 stays E’s brief, and E1 and E2 move into 2b’s file when it opens.
• ADR-0007’s list of Regions, fixed when 2b opens. This phase fixes the filter. ADR-0007’s amendment of 2026-10-19 records the split.

0. What this phase inherits

• A gate nobody has read. Phase 1’s R1, whether MapLibre draws with every network permission stripped, was deferred on 2026-10-19 with R8, R9 and R10’s screen. DOD.md makes them due before this phase builds on MapLibre, and phase 1’s § 1 holds their verdicts. This phase’s A is those readings.
• A thin tile schema. scripts/map/KozicaProfile.java emits water, ways with a sorted list of Trail colours, and named peaks: what phase 1’s gate and readings needed and nothing else. Phase 1 left the full schema to this phase, under three rules that stand: no compression inside the file, deterministic output, one archive per Region.
• Trail colours read the way the profile reads them. A Trail’s colour is the first field of its relation’s osmc:symbol, and colour= only when there is no symbol. 140 ways in the Tatry archive carry two or more colours (phase 1, R10).
• A debug map, not a map. DebugMapActivity, the gate style and Noto Sans glyphs live under app/src/debug/. RegionFiles there reads the Tatry pack’s state, falling back to a hand-pushed archive in files/regions/.
• The palette is waiting for a map. Phase 0 § 3 fixed four seeds on the condition that nothing the app paints over the map reads as a Trail colour, and left the reading to this phase.
• Rule 4’s location row is this phase’s. Precise location, asked on the first tap on “show me where I am”, never at launch; fine and coarse together; and from API 31 a third answer, approximate only.
• MapLibre merges the fine and coarse location pair with its three network permissions (ADR-0008). The network three stay stripped; the location pair becomes the ask.

What is in, and what is deliberately not

In: the map screen in main/, replacing Home’s placeholder, drawn by MapLibre with every network permission stripped from the release build. The full tile schema, which is the filter, and the style that draws it, in light and dark. The position: the ask, the dot, accuracy, heading, and what the user sees for each answer. The OSM credit and data date on the map. ODbL and the font’s OFL on the licences screen. The palette reading. The camera remembered across launches, as one stored key in AppPreferences: it lands before the door freezes keys (PLAN.md rule 1), and a wrong value costs one bad first frame.

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

• Any Region in the release build. The release map draws whatever Region is on the phone, and in this phase nothing can put one there: the asset-delivery library stays debug-only until phase 2b. The release map therefore shows its empty state, “no Regions downloaded”, which ADR-0007 requires anyway. No OSM-derived data is conveyed, so the ODbL offer is not yet owed.
• The Region list, every Region’s polygon, and the picker. Phase 2b’s. One Region is enough to draw and read every layer; building nine would only multiply the readings.
• Search, tapping a feature for its details, and route planning. Phase 5 brings search and routes, and a details sheet needs the copy and layout decisions that come with them.
• Contours and hillshading. Phase 4: a DEM pipeline with its own licence.
• Following the user as they move. One tap centres the map on the position once; the map does not then chase the dot. A camera that moves itself under a finger is a fault report in waiting, and recording a hike is phase 6.

The tempting one is drawing Trails from a ready-made outdoor style, such as OpenTopoMap’s look or an OpenMapTiles schema with a hiking overlay. It looks like a week saved. But those schemas carry hiking routes as separate relation geometry or not at all, and none of them offsets two Trails on one way, which is the thing a Polish trail map has to get right: a junction where a red and a blue Trail share a way for a kilometre is where people take the wrong one. The schema stays ours, small, and shaped around that.

Checkpoints

A goes first because B is a bet otherwise. Phase 1 built B–D on the assumption that MapLibre draws offline. This phase would put that assumption into the release build. If R1 takes phase 1’s verdict 2, the renderer changes, and B–D here are rewritten for Mapsforge before any of them is built.

B is small on purpose. It moves the debug map into main/ and makes it the app’s first screen, with the style phase 1 already has. Everything the release artifact gains in this phase — MapLibre’s native code, the stripped permissions and feature, the licences — lands in that one commit, so one aab-permissions.py run reads all of it.

C and D are independent. C changes the profile, the archive and the style; D changes the screen and the manifest. Either can merge first. E reads both, so it comes last.

1. The gate

Phase 1 § 1, unchanged: the question, the apparatus and the four verdicts are written there and are not re-argued here. R8 and R9 are phase 1’s too, with their verdicts in phase 1 § 3. The readings are recorded in phase 1’s table, where their rows are; this phase’s R1 points to them.

If R1 takes verdict 1, this phase goes ahead as written. If it takes verdict 2, this file stops at A and is rewritten for Mapsforge/VTM before B. If it takes verdict 3, MapLibre draws only with the location pair kept: B keeps the pair rather than stripping it, and D’s document and allowlist changes move into B, because the release then declares the pair before the ask exists. Those are the EXPECTED rows, the two location features, and the lines in privacy-policy.md and play-app-content.md.

2. The map in main/

• MapLibre becomes implementation, still android-sdk-opengl (phase 1 § 1: the default android-sdk is Vulkan, and its uses-feature would be a Play device filter). The release artifact gains about 13 MB of native code per ABI, which phase 1 named as a known gap for this phase to decide. It is decided: the map is the app.
• The main manifest strips the three network permissions with tools:node="remove", moved from the debug manifest. aab-permissions.py already forbids them, so its run on the release bundle is the proof. The location pair is also stripped in B and returns in D, with its ask, unless R1 takes verdict 3 (§ 1).
• It strips MapLibre’s <uses-feature android:name="android.hardware.wifi"> too, with tools:node="remove". Phase 1’s R2 read it merged at required="false". The app never uses Wi-Fi (ADR-0008), so the feature is removed rather than allowed, and EXPECTED_FEATURES stays empty in B. aab-permissions.py fails on any feature missing from that map, whatever its required.
• MapLibre.setConnected(false) runs in MainApplication.onCreate, before any MapView can exist (ADR-0008’s consequence).
• ui/map/MapScreen.kt replaces Home’s placeholder. It is an AndroidView around MapView, as in the gate: maplibre-compose is still out for the Kotlin pin (phase 1, the tempting one). MapViewModel holds one immutable UI state: every Region’s state, the camera and the position.
• Which Regions are on the phone is a seam with two halves. data/regions/Regions.kt in main/ defines a Flow of every Region’s state, not only the ready ones, with the states RegionFiles already has: not downloaded, downloading, waiting for confirmation, update in progress, ready (a path and an OSM date), failed. ADR-0007 requires an “update in progress” state, and a list of ready Regions alone would show “No Regions downloaded yet.” to a user whose Region Play is patching. The map draws the ready ones. The debug half is RegionFiles, pack or hand-pushed. The release half, in src/release/, emits an empty list until phase 2b gives it the library. Same shape as DebugSettings.kt’s seam.
• The style is a template the app expands, in src/main/assets/map/ with its glyphs. A style layer binds to one source id, so two static files cannot hold layers for Regions not yet on the phone. The app adds one source per ready Region, pmtiles://file://<path>, and repeats each layer of the template per Region, with the Region in its id. The order is by layer, not by Region: every Region’s land, then every Region’s water, and so on up to the labels, so where two Regions’ tiles overlap one Region’s land never paints over the other’s Trails.
• A light/dark switch or a change in the ready Regions rebuilds the whole style. setStyle drops every source and layer added at runtime, and the LocationComponent with them, so the expanded style is set as a whole and the component is activated again, with the last fix, in the style-loaded callback. R6 reads it.
• The camera is stored in AppPreferences (latitude, longitude, zoom) when the screen stops, and a launch opens on it. With none stored, a launch opens on the ready Regions’ bounds; with no Region ready, on a fixed view over southern Poland’s mountains, from the Karkonosze to the Bieszczady: 49.0° N 14.8° E to 50.9° N 23.0° E. Process death keeps the camera through saved state as well.
• The empty state is the map’s own background with one line and no button, because in this phase there is nothing to press. With no Region ready, the line depends on the states: “Map data is being updated.” when any Region is in “update in progress”, and “No Regions downloaded yet.” otherwise. Play invalidates every pack in one app update, so a Region updating beside a ready one is not drawn and not named here; 2b’s picker shows it. Phase 2b adds the button.
• The credit and the date. “© OpenStreetMap contributors” sits on the map, linked to the copyright page through ui/common/Intents.kt, and beside it “OSM data: " for the oldest ready Region. Every Region in a release comes from one pin, so the dates differ only while one pack is patched and another not yet; then the map is no fresher than its stalest part, and that is the date a hiker needs. MapLibre's own attribution control and logo are turned off. The control is an (i) icon whose dialog, titled "MapLibre Android", lists each source's attribution and opens its link; for planetiler's archive that is OSM's credit, but the house rule wants the credit itself visible on the map and linked, not behind a tap.
• Licences. app.cash.licensee picks up MapLibre’s BSD-2-Clause by itself, but supplies no text. BSD-2-Clause.txt moves from src/debug/assets/licences/ to src/main/assets/licences/, and OFL.txt from beside the debug glyphs to the same directory, and the licensee block’s “debug only in phase 1” comment goes with them. ODbL and Noto Sans’s OFL are not dependencies, so they become two hand-written entries beside the generated list, and ODbL’s text joins them.
• The debug map goes. DebugMapActivity and its Settings row are removed; the debug section keeps “Download Tatry”, “Remove Tatry” and the pack state.

Copy: “No Regions downloaded yet.”, “Map data is being updated.”, “© OpenStreetMap contributors”, “OSM data: %1$s”.

3. The schema and the style

The filter is the profile. ADR-0007 has osmium tags-filter drop what nothing in the app reads. But planetiler emits only what the profile names, so a second list in a filter step would only have to be kept in step with the first. The cut goes straight to planetiler, and the layer table below is the filter. ADR-0007’s amendment written with C records that.

• A Trail is one feature per Trail per way, not a list on the way. R10’s sorted list cannot be drawn: a style cannot loop over it. So the profile emits a way that count Trails share count times, each with its own colour, symbol and index in that sorted order. The style offsets each by (index - (count - 1) / 2) × width, so two Trails sit side by side and three keep the middle one on the way. Sorting by colour, then by relation id, keeps the order stable between builds. Phase 7a adds the union: the Trails, then Touring, then MTB Bike routes, each sorted that way, one order over both layers, in union_index/union_count on a Trail and index/count on a Bike route. The first of them is the reference relation below.
• A shared way’s direction follows the stretch, not the compass. line-offset is signed against the line’s direction, and OSM does not orient the ways of a relation consistently: where two ways of one shared stretch point opposite ways, red and blue would swap sides at the node between them and draw an X. A compass rule such as “west first” fixes that only while the stretch keeps running one way in longitude; on a serpentine, or a stretch that bends from north-east to north-west, two meeting ways get opposite directions and the X comes back. So the profile orients each way by a reference relation: of the Trails sharing it, the one that sorts first by colour, then by relation id, the same order as index. The way is oriented to continue from the previous member of that relation, by the relation’s member order and the ways’ end node ids. If neither end connects to it (a gap in the relation, or the first member), the way is oriented to lead into the next member. If neither applies, it falls back to west first, or south first when its ends share a longitude. Along a stretch whose set of Trails does not change, the reference relation stays the same, so index keeps its side. A tile post-process that merges lines must keep the direction.
• The orientation needs each way’s end node ids and each relation’s ordered members. planetiler 0.10.2’s first pass hands the profile both: preprocessOsmWay gets each way’s node ids, and preprocessOsmRelation each relation’s members in order, ways before relations. So the profile keeps every way’s two end nodes, and no pre-pass or sidecar is needed. The pass runs on several threads, so the map is concurrent, and nothing read from it depends on their order.
• A Trail may change side at a junction, and that is accepted. index is per way, so a blue Trail beside a green one is index 0, and becomes index 1 where a red Trail joins. Paper trail maps do the same; a fixed slot per Trail would leave gaps where its companions are absent.
• The symbol is the osmc:symbol foreground, such as red_bar, red_dot, red_cross, red_triangle, red_corner. It is drawn as an icon repeated along the line from zoom 14. A foreground the sprite sheet does not hold falls back to the bar in the Trail’s colour, never to nothing. A symbol-placement: line layer ignores line-offset, so the symbol layer takes the same expression as a data-driven icon-offset perpendicular to the line, with icon-keep-upright off so a symbol does not flip to the other side, and overlap allowed so two Trails’ symbols on one way do not hide each other. The sprites are generated by scripts/map/sprites.py from the shapes × the five Trail colours, plus the fallback colour and the POI icons (Hut, Shelter, peak, pass, spring, viewpoint, parking, stop, station), and committed with the style, so the build needs no network.
• A hiking relation is a Trail whatever its colour says. Today’s profile returns no Trail for a route=hiking relation with neither osmc:symbol nor colour=, so its ways draw as Paths: a marked Trail shown as unmarked, which CONTEXT.md forbids. C changes phase 1’s profile to emit every hiking relation. A colour missing or outside the five is drawn at Trail width in a neutral that reads as none of them, never as a Path; its symbol falls back to the bar in that neutral. Polish names (czerwony, niebieski, zielony, żółty, czarny) and the five pure hex values (#ff0000 and so on) map to their colour first; nothing else is guessed, so orange is not red. R4 counts the relations that reach the fallback.
• Boundaries are lines from the relations’ member ways. A Region’s cut holds the state border’s relation and a national park’s only in part: build-map-data.py cuts with osmium’s smart strategy, which completes multipolygon relations only, and these are type=boundary. So their polygons cannot be assembled, and their member ways are mostly untagged. The profile reads the relations in preprocessOsmRelation, as it does Trails, and emits each member way through relationInfo with the relation’s kind. admin_level=2 is matched with boundary=administrative, because alone it also matches other things. A park mapped as one closed way is drawn from that way’s own tags. R5 reads the border along the Tatry ridge.
• POIs mapped as areas are points too. Huts are often a building polygon, and parking far more often an area than a node, so the profile emits pointOnSurface() for areas in pois; a point-only layer would drop them with nothing to say so. amenity=shelter excludes shelter_type=public_transport, or a village bus stop would show as a Shelter; a picnic shelter on a Trail is still a roof a hiker can use. POIs are drawn with their sprite icon and their name. R4 counts Huts in the cut and in the archive.
• Paths are drawn so they can never pass for a Trail (CONTEXT.md): thin, dashed, in a neutral, never in a Trail colour, and drawn under Trails.
• Both style files are generated by one script, scripts/map/gen_style.py, from one source: style-light.json and style-dark.json, the templates § 2’s app expands, committed and picked by the app’s own night mode (theme/NightMode.kt), not by the system’s alone. Two hand-kept files would drift, and a seed change would not reach them.
• Trail colours are the signposts’ red, blue, green, yellow and black, the same in light and dark. This is the exception to “colours come from MaterialTheme” that phase 0 § 3 promised to record, and CLAUDE.md records it with C. They are the only literal colours in the style.
• Every other colour of the style comes from the scheme. The base colours (land, water, roads, labels, Paths, casings, the fallback neutral) are read from the scheme scripts/gen_scheme.py generates, as roles or tones of its palettes, so the house rule’s “edit the seeds and regenerate” stays true for the map, and E’s seed change reaches it. gen_scheme.py runs main() on import today, so it gains a __main__ guard for gen_style.py to import it.
• Casings keep the two hard Trail colours visible: yellow gets a dark casing in the light style, black a light one in the dark style. Phase 0 § 3’s rule holds in both modes, and yellow on light land is the usual failure.
• Labels are Polish names, the name tag, in Noto Sans with the glyph ranges 0–255, 256–511 (Latin Extended-A: ł, ś, ż, ą) and 8192–8447 („ ” – ’, which hut and shelter names carry). A missing range draws nothing, silently, so R6 derives the ranges from the archive’s names rather than trusting this list, and reads a label with each.
• Determinism is re-read. The schema change rebuilds the archive, so phase 1’s R4 is taken again, and the archive’s size and the one-Trail patch are re-read against R5 and R7.

4. You are here

The ask, and every answer to it, in one table (PLAN.md rule 4):

• Fine and coarse are asked together, with RequestMultiplePermissions, as Android requires from API 31 for the approximate option to be offered.
• Every state but “not asked” is re-read on each ON_RESUME, and the switch also on LocationManager.MODE_CHANGED_ACTION while Home is started, because the quick-settings tile flips it without pausing the activity: checkSelfPermission and LocationManagerCompat.isLocationEnabled can both be read back reliably, so the banners use WarningBanner (ui/common/Surfaces.kt). The compat call, because LocationManager.isLocationEnabled is API 28 and minSdk is 26.
• Re-asking after a denial is decided by shouldShowRequestPermissionRationale. From API 30 a second denial makes the request return denied with no dialog, and nothing reports that directly. So after a denied result, the next tap asks again while the rationale call is true, and otherwise opens the app’s settings. The first tap of each launch always asks: at launch “never asked” and “permanently denied” both read false, and telling them apart would take a stored key. A permanently denied user therefore gets one silent tap per launch before Settings opens. That is accepted, rather than a key added to “fix” it.
• Approximate only re-asks for precise in the app first. On API 31+, with coarse granted, asking for fine and coarse again shows the system’s precise-upgrade dialog, so the banner’s action is that ask, and Settings only once it is refused. Opening Settings first is the heavier hand-off.
• The app reads location itself, through LocationManagerCompat: the platform’s fused provider where the phone has one, else GPS, or NETWORK_PROVIDER with approximate only, because GPS needs the fine permission. R8’s SecurityException grep catches a provider asked for without its permission. None of them is Play services. MapLibre’s LocationComponent is activated with useDefaultLocationEngine(false) and fed each fix with forceLocationUpdate, so there is one reader of location, not two. The assistance that speeds a first fix is Android’s, not ours (ADR-0008).
• The dot is that LocationComponent, in RenderMode.COMPASS. Its own stale state is off: its timer restarts when a fix is received, never reads the fix’s age, and on activation an hour-old last-known fix would draw as fresh for 30 s. The grey look is applied from PositionAge instead.
• The position button centres the map once. It does not follow, and a pan does not need to be undone.
• A position outside every ready Region is still drawn, over the empty background, because “you are outside the map” is the information.
• The stale line’s age is a safety value. A position shown as current when it is minutes old puts a hiker on the wrong side of a ridge, so its age and its threshold are a pure function with a test (below). The age is the fix’s elapsedRealtimeNanos against SystemClock.elapsedRealtimeNanos(), a clock no user or network change can move, so a clock change cannot happen rather than needing a case.

• Approximate only has its own threshold, 15 minutes. Android throttles a coarse-only client to fixes minutes apart, about ten on current releases, so at 30 s “stale” would be the steady state and the banner would always say so. 15 minutes clears that interval with room for a late fix and still marks a position from the previous valley as old. The threshold lives in PositionAge with the other, and R7 reads the real coarse interval on the phone; a reading longer than 15 minutes moves the threshold.

• A debug build can put “you are here” anywhere. Reading the dot, its accuracy circle, the stale state and a position outside every Region should not need a hike. So the real reader stays in main/, and a variant seam, the same shape as DebugSettings.kt, decides only what wraps it: the release half passes it through, and the debug half adds an override that can swap its fix for a chosen one. A long press on the map puts the position there; a debug row returns it to the real reader; PositionReceiver, an adb broadcast in SeedReceiver’s pattern, sets latitude, longitude and accuracy for scripted readings:

  adb shell am broadcast -n io.github.srednimax.kozica.debug/app.kozica.debug.PositionReceiver \
    -f 0x00000020 --ef lat <lat> --ef lon <lon> --ef accuracy 10
  

  A chosen fix takes the same path as a real one, forceLocationUpdate and PositionAge, with its elapsedRealtimeNanos stamped at the moment it is set, so going stale is also testable. It carries no bearing: in RenderMode.COMPASS the heading cone follows MapLibre’s CompassEngine, the phone’s real compass, and the debug half does not fake it, so the cone is read by turning the phone. The chosen position lives in memory only, so process death or the debug row clears it; backing out and reopening the app usually keeps the process, and the chosen fix with it. It replaces only the fix, and only in the states that draw one, precise and approximate only: “not asked”, “denied” and “location off” behave exactly as without it. Android’s mock-location test provider is the later way to exercise the real provider without walking.

Copy: “Show my position”, “Approximate location only. Allow precise location to see where you are on a Trail.”, “Allow”, “Location is turned off.”, “Last position %1$s ago.”, “Settings”.

5. The palette

Phase 0 § 3’s reading, now that there is a map: the position dot, the accuracy circle, the heading cone, the position button and the banners, over a yellow and a black Trail, in light and dark. If any of them reads as a Trail colour, or a Trail disappears under one, a seed changes in scripts/gen_scheme.py, the scheme is regenerated, and the reading is taken again.

Tests

One, for D’s stale position: PositionAge, a pure function from a fix’s elapsedRealtimeNanos, now’s SystemClock.elapsedRealtimeNanos() and whether the grant is approximate only, to fresh or stale and the age shown. It fails in the direction the app exists to prevent: a fix that is old reported as fresh. The test covers the 30 s boundary on both sides, the 15 min approximate boundary on both sides, a fix whose stamp is 0, which Location returns when a provider never set it and which must read stale, never fresh, and an age that crosses an hour.

Nothing in C is a safety value. A Trail drawn in the wrong colour is a real fault, but it is the profile reading OSM, and a reading on the phone and in the tile catches it, not a unit test.

Documents this phase amends

• PLAN.md: phase 2’s paragraph and status line, split into 2 and 2b, with this file.
• ADR-0007: two dated amendments. The first is written with this file: the map phase was split, phase 2 fixes the filter and phase 2b the list of Regions. The second comes with C: the profile is the filter, and no tags-filter step runs. It stays with C rather than joining the first because an ADR records what was built, and C’s schema can still move under the build and R4.
• CLAUDE.md: with B, the stack table’s MapLibre row loses “debug only”, and the layout changes: app/src/debug/ loses the offline map gate, main/ gains ui/map/ and data/regions/, and app/src/release/ gains the Regions seam. With C, the colour house rule gains the map style’s Trail colours as its one exception, and says the style’s other colours are generated from the scheme by scripts/map/gen_style.py. With D, the layout gains the position seam’s two halves around the real reader in main/: the override, the long press, the debug row and PositionReceiver in app/src/debug/, and the pass-through in app/src/release/.
• scripts/aab-permissions.py: with D, ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION move into EXPECTED, each naming the position button. D also declares <uses-feature android:name="android.hardware.location"> and android.hardware.location.gps, both required="false", so Play’s device filtering never depends on what it derives from the permissions: the position is optional to the map. Both join EXPECTED_FEATURES as False, the map’s value for required, its “Empty on purpose” comment is rewritten, and play-app-content.md gets their reason, since EXPECTED_FEATURES holds none.
• docs/privacy-policy.md and docs/play-app-content.md, in the same commit as D: the app reads the phone’s location to draw it on the map, on the phone only, and never stores or sends it. Data safety stays “no data collected”, because collection means leaving the device. The line “Would change any of it: location of any kind” is rewritten to say what does: storing it, which phase 6 does.
• DOD.md: phase 1’s phone readings item closes with A. Its checkpoint E item names phase 2b as E’s owner, written with this file.

Known gaps, deliberately

• The release map is empty until phase 2b. A release from this phase reaches only the owner on internal testing, and its map says “No Regions downloaded yet.” That is honest, and it keeps OSM data out of the release until the ODbL offer ships with it.
• No feature can be tapped. A Hut’s name is on the map; its opening times, phone number and everything else in its tags are not reachable until a details sheet exists.
• The compass is the phone’s. A heading cone from an uncalibrated magnetometer points wrong, and the app cannot tell. Android’s own calibration prompt is the remedy.

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 that drives the phone waits until the owner says it is free.