Pilot's Toolkit — Working Roadmap

Last updated: March 4, 2026 For completed milestones, see COMPLETED.md

RC1 locked — February 28, 2026. Seven modules, both platforms, data externalized. RC2 planning — March 2026. FBO Contact and Passdown Audit Trail targeted for next release.

Phase I — Web & Android Apps

RC2 Targets

FBO Contact — New module: outbound communication tab for contacting FBOs ahead of arrival. FBO autocomplete (learned from usage, auto-populates email), request details field with placeholder prompts (purpose of visit, transportation, services, ETA/ETD, catering), saveable/editable signature block (pilot name, registration, contact info, FBO loyalty program numbers). Email compose on send. Rewards numbers excluded from bulk exports.
Passdown Audit Trail — Diffs stored as a history array inline in the passdown JSON object. Each save captures timestamp, changed fields, and previous values. Compresses naturally inside existing .ptz gzip. Accessible from the passdown detail view only, via a disclosure element — main form and history list show only the final version. Retention policy on snapshots to keep record size bounded.

Future Revisions

Crew Rest Calculator — Simplified rest period calculator for augmented crews (3–4 pilots). Equal division of en route rest after 30-minute all-hands blocks at departure and arrival. Potential paid add-on. Timer/alarm deferred (Android foreground services, notification channels). Full Part 117 compliance may not be attainable — regulatory liability is a fundamentally different risk profile than the rest of the toolkit.
Crosswind Limits Overlay — Per-aircraft wind limitations. Placeholder field exists in aircraft JSON. Blocked by data sourcing complexity (OEM vs operator limits, angle-dependent calculations).
Room/SQLite Migration (Android) — Migrate passdown storage from SharedPreferences to Room for better query/filter scalability.

Removed from Consideration

~~Unit Converter~~ — Duplicates existing EFB tools and web searches.
~~Pressure Conversion~~ — Marginal standalone value.
~~Density Altitude Calculator~~ — Covered by existing fleet performance tools.

Phase II — Docker Deployment

Single Docker container hosting the full stack: nginx (static Vite frontend + API proxy) + Node/Express (thin REST API, session-based auth) + SQLite (single-file database). Designed for homelab or small-group hosting. Doubles as an iOS demonstrator — iOS users access the web app through a browser before native iOS is built.

Multi-user requirement: User accounts with data partitioning. Each user's passdowns, lookups, and settings are isolated — no cross-visibility. Initial auth model: email + provided password, user changes password at first login. Managed by a small trusted group; more sophisticated auth layered on later if the user base grows.
Frontend migration: Storage calls swap from IndexedDB/localStorage to fetch('/api/...'). Data model, UI, and module logic stay untouched.
API routes: Auth (login/logout/session), passdowns CRUD, lookups CRUD, settings, .ptz import/export.
Deployment: Single docker-compose.yml, one volume for the SQLite database file. Exposed on port 38911 (no registered IANA service, low bot visibility). Runs on homelab HPC server.
Security posture (proof of concept):
- nginx rate limiting on login endpoint (e.g., 5 attempts/min/IP → 429).
- fail2ban monitoring nginx logs for 429s/401s — auto-bans offending IPs via iptables (e.g., 5 failures in 10 min → 1 hour ban, escalating for repeat offenders).
- Session-based auth: user logs in once, stays logged in until explicit logout or token expiry (controlled server-side). No per-login OTP friction.
- High port number provides minor obscurity benefit (not a security measure, but reduces noise from common-port scanners).
Security upgrades (post-approval): Cloudflare Tunnel (no open ports, email OTP gatekeeper, free tier, nothing to install on user devices — runs on server only) or VPN (Tailscale/WireGuard) if users can install software on their devices. Both are future options, not proof-of-concept requirements. Cloudflare session windows are configurable (24h to 30 days) but still require periodic re-auth, which adds friction for frequent daily use.
Data security (future — managed device deployment): Current .ptz files are plain-text gzipped JSON — readable by anyone with gunzip. Acceptable for a hand-selected beta group, but operationally sensitive data (maintenance squawks, crew schedules, tail numbers) must be protected on managed devices. Planned approach: when the Docker backend is live, passdown sync goes through the authenticated API — no .ptz files over email as the primary flow. The server controls who sees what; unmanaged/unauthorized devices simply can't authenticate. For offline/disconnected scenarios where .ptz file transfer is still needed, options include symmetric encryption (AES with operator-level shared passphrase) or per-user keys issued by the server. Key management complexity scales with the auth model — keep it simple until the user base demands otherwise. The goal: make it difficult for an individual to exfiltrate company operational data from a managed device.
Mobile apps: Stay local-only unless API sync is added later. Manual .ptz import/export provides a sync path for small groups in the meantime.

Phase III — iOS (SwiftUI)

Status: Planning only. Architecture mapped out (SwiftUI + UserDefaults for persistence).
Prerequisite: Apple Developer Program ($99/year). Docker deployment (Phase II) provides a web-based stopgap for iOS users in the meantime.
Approach: Incremental migration in small, manageable chunks mirroring the Android module structure. Each module ported and tested independently before moving to the next. Allows troubleshooting at each step without large-scale rework.
Migration order (tentative):
1. App shell — navigation, tab bar, hamburger menu, aircraft selector, dark mode, theme
2. Fuel Order Calculator — simplest module, validates the SwiftUI patterns and data flow
3. Crosswind Calculator — standalone, no data dependencies
4. Pavement Strength — aircraft-dependent, tests data model integration
5. Fuel Buckets — slider, interpolation, CSV import, named profiles
6. Flight Level ↔ Meters — static data tables, lookup search, FLAS direction filter
7. HF Frequencies — network fetch, HTML parsing
8. Passdown Module — most complex, all CRUD + storage + export
Storage: Core Data or SwiftData for structured records, UserDefaults for preferences.
Notable differences: iOS will need its own .ptz export mechanism (likely via share sheet using UIActivityViewController), and HF fetch should work natively (no CORS restriction).

Phase IV — Future Enhancements

Ride Report / Turbulence Sensing

Use phone accelerometer hardware to detect and classify turbulence intensity in real time.

v1 (near-term, once core stable): Simple vertical g-meter with real-time display, min/max peak hold, color-coded intensity gauge (light/moderate/severe/extreme bands).
v2 (requires research): Filtered intensity classification with time history graph. Key challenge is signal processing — low-pass/high-pass filter design, possibly Kalman filter for orientation fusion (accelerometer + gyroscope), windowing functions to separate turbulence from handling noise. This is a signal processing problem, not just linear math.
v3 (ambitious, far future): Crowd-sourced ride reports with GPS location, altitude, and intensity. Essentially a mini Turbulence Aware / PIREP system.
APIs: Web — DeviceMotion API. Android — SensorManager. iOS — CoreMotion.
Status: Wish list. Filtering approach needs dedicated research before implementation.

App Icon

Ideas discussed: compass rose, PT monogram, stylized wing/chevron, wrench+propeller hybrid, flight instrument silhouette. Compass rose and PT monogram scale best to small sizes (favicon, 48px Android icon).

Aircraft Data (Suspended)

Resumed when source data becomes available.

G650 — ESWL formula working, max ramp weight needs confirmation (100,000 vs 104,000 lbs). ACN/ACR formulas not yet started (charts need deciphering).
G700 fuel buckets — Data not available for an indefinite period.
G500 — Placeholder only. No pavement, weight, or bucket data yet.
G450 — Updated pavement calculations pending integration of corrected data.

Known Issues

BlueMail (Android): Send button uses ACTION_SEND with message/rfc822 (.ptz attachment + plain text body + TO/CC). BlueMail receives the attachment but may not populate recipient fields or body text. Works correctly with Gmail and other standard email clients. BlueMail not presently supported; investigating.

8.8 KiB Raw Blame History Unescape Escape