planeMapper/_bmad-output/implementation-artifacts/deferred-work.md

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.