# Deferred Work Manifest Tracks blocked, deferred, and tech-debt items across sprints. --- ## Infrastructure / environment setup ### [1-1] systemd unit installation Story: `1-1-project-scaffold-and-verified-entry-points` Task: 7.1, 7.2 Description: Unit files created at `systemd/`. Must be symlinked or copied to `/etc/systemd/system/` on the Pi and `systemctl daemon-reload` run before they take effect. Cannot be automated without root access to target device. ### [1-1] Pi Zero 2W runtime verification Story: `1-1-project-scaffold-and-verified-entry-points` Task: 9.1, 9.2 Description: Entry points verified on host (Pi 5, Linux). Full AC1 verification on Pi Zero 2W hardware requires physical deployment. --- ## Story 1.2 review — no new deferred items Story `1-2-configuration-read-write-wipe` reviewed 2026-04-22. All 4 ACs pass, all 7 tests pass, ruff check and format clean. No deferred items required: `config.write()` already handles directory creation via `mkdir(parents=True, exist_ok=True)`, so deployment to a fresh device with no `/etc/planemapper/` directory is covered at runtime. --- ## Story 1.3: WiFi Hotspot & Captive Portal Form ### [1-3] hostapd and dnsmasq system packages Story: `1-3-wifi-hotspot-and-captive-portal-form` Category: Infrastructure/environment Description: `hostapd` and `dnsmasq` require system packages installed on the Pi; AP mode requires `wlan0` in AP-capable state. Cannot be verified without hardware. ### [1-3] Captive portal device testing Story: `1-3-wifi-hotspot-and-captive-portal-form` Category: Runtime verification Description: Actual captive portal detection behaviour (iOS/Android/Windows triggering) requires physical device testing. Automated tests confirm redirect routes are correct but cannot simulate OS-level captive portal probe behaviour. ### [1-3] Provisioning loop placeholder Story: `1-3-wifi-hotspot-and-captive-portal-form` Category: Infrastructure/environment Description: `provision.py` provisioning loop currently exits after one iteration (placeholder `provisioned = True`) — full sequence wired in Story 1.5. --- ## Story 1.4: Location Resolution (ICAO & Address) ### [1-4] Nominatim geocoding runtime verification Story: `1-4-location-resolution-icao-and-address` Category: Runtime verification Description: Nominatim geocoding verified in tests with mocks only; real geocoding requires internet access and can only be confirmed on device at provisioning time. No automated test covers live HTTP to Nominatim. ### [1-4] ICAO heuristic false-positive risk Story: `1-4-location-resolution-icao-and-address` Category: Technical debt Description: ICAO heuristic (`len(query) == 4 and query.isalpha()`) may misclassify 4-letter words (e.g. "BATH", "YORK") as ICAO codes, causing them to be looked up in `airports.csv` before falling back to Nominatim. Acceptable for MVP given the provisioning context, but noted for future hardening (e.g. validate against a known ICAO prefix list). --- ## Story 1.5: Provisioning Execution — Tile Download, Cache Validation & WiFi Kill ### [1-5] nmcli / NetworkManager dependency Story: `1-5-provisioning-execution-tile-download-cache-validation-and-wifi-kill` Category: Infrastructure/environment Description: `nmcli` requires NetworkManager to be installed and running on the Pi; the `wlan0` interface must support managed mode. Raspberry Pi OS Lite uses `dhcpcd` by default — NetworkManager must be installed and enabled before `join_home_wifi()` will work. ### [1-5] rfkill permission requirement Story: `1-5-provisioning-execution-tile-download-cache-validation-and-wifi-kill` Category: Infrastructure/environment Description: `rfkill block wifi` requires the process to have permission to block the WiFi interface. The user running the provisioning service must be root or have the `CAP_NET_ADMIN` capability. The systemd unit must be configured accordingly. ### [1-5] OSM tile download and OpenAIP API runtime verification Story: `1-5-provisioning-execution-tile-download-cache-validation-and-wifi-kill` Category: Runtime verification Description: OSM tile download, OpenAIP API call, and the full provisioning sequence (WiFi join → tile download → airspace download → validate → write config → rfkill) can only be end-to-end verified on device with real network access. All tests use mocks only. ### [1-5] provision.py port 80 requires root Story: `1-5-provisioning-execution-tile-download-cache-validation-and-wifi-kill` Category: Infrastructure/environment Description: `provision.py` calls `app.run(port=80)` which requires root privileges or the `CAP_NET_BIND_SERVICE` capability to bind to a port below 1024. The systemd unit for the provisioning service must run as root or be granted the appropriate capability. ### [1-5] Synchronous POST /submit — browser waits during provisioning Story: `1-5-provisioning-execution-tile-download-cache-validation-and-wifi-kill` Category: Technical debt Description: The `POST /submit` handler is fully synchronous — the browser connection stays open while tile download, airspace download, and cache validation complete (potentially 2–5 minutes). This is acceptable for MVP but a streaming response (using `flask.stream_with_context` or a background thread with server-sent events) would improve UX by allowing the browser to render progress feedback without holding an open connection. --- ## Story 2.1: Aircraft Data Model & Fetcher ### [2-1] HttpFetcher live dump1090 runtime verification Story: `2-1-aircraft-data-model-and-fetcher` Category: Runtime verification Description: `HttpFetcher` is tested with mocks only. Live feed at `http://localhost:8080/data/aircraft.json` can only be verified on device with an RTL-SDR dongle connected and dump1090 running. No automated test covers the real HTTP path to dump1090. --- ## Story 2.2: Coordinate Projection & Base Map Loading ### [2-2] Equirectangular projection distortion at high latitudes or large radius Story: `2-2-coordinate-projection-and-base-map-loading` Category: Technical debt Description: The equirectangular projection corrects only for longitude convergence at the home latitude (`cos(home_lat)`). For large radius values (e.g. >150nm) or locations above ~60°N, distortion accumulates toward the display edges. Aircraft positions at the map boundary can be displaced by several pixels from their true screen location. Acceptable for a ~100nm display centred on a UK airfield, but worth revisiting if radius or latitude range is extended. ### [2-2] basemap.load() does not verify image dimensions Story: `2-2-coordinate-projection-and-base-map-loading` Category: Technical debt Description: `basemap.load()` opens and returns whatever image is at `BACKGROUND_PATH` without asserting it is 800×480. A mismatched tile composite (e.g. from a re-provisioning at a different zoom level) will be silently accepted and the rendered output will be corrupted. Future hardening: add a dimension assertion and raise `ValueError` if the image does not match `DISPLAY_WIDTH × DISPLAY_HEIGHT`.